7424 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

DEPARTMENT OF HEALTH AND Mary E. Switzer Building, Mail Stop: birth; driver’s license number; state HUMAN SERVICES 7033A, 330 C Street SW, Washington, identification number or foreign country DC 20201. Please submit one original equivalent; passport number; financial Office of the Secretary and two copies. account number; credit or debit card • Hand Delivery or Courier: Office of number; any personal health 45 CFR Parts 170 and 171 the National Coordinator for Health information; or any business Information Technology, Attention: 21st information that could be considered RIN 0955–AA01 Century Cures Act: Interoperability, proprietary. We will post all comments 21st Century Cures Act: Information Blocking, and the ONC that are received before the close of the Interoperability, Information Blocking, Health IT Certification Program comment period at http:// and the ONC Health IT Certification Proposed Rule, Mary E. Switzer www.regulations.gov. Program Building, Mail Stop: 7033A, 330 C Docket: For access to the docket to Street SW, Washington, DC 20201. read background documents or AGENCY: Office of the National Please submit one original and two comments received, go to http:// Coordinator for Health Information copies. (Because access to the interior of www.regulations.gov or the Department Technology (ONC), Department of the Mary E. Switzer Building is not of Health and Human Services, Office of Health and Human Services (HHS). readily available to persons without the National Coordinator for Health ACTION: Proposed rule. federal government identification, Information Technology, Mary E. commenters are encouraged to leave Switzer Building, Mail Stop: 7033A, 330 SUMMARY: This proposed rule would their comments in the mail drop slots C Street SW, Washington, DC 20201 implement certain provisions of the 21st located in the main lobby of the (call ahead to the contact listed below Century Cures Act, including conditions building.) to arrange for inspection). Enhancing the Public Comment and maintenance of certification FOR FURTHER INFORMATION CONTACT: requirements for health information Experience: To facilitate public comment on this proposed rule, a copy Michael Lipinski, Office of Policy, technology (health IT) developers under Office of the National Coordinator for the ONC Health IT Certification Program will be made available in Microsoft Word format on ONC’s website (http:// Health Information Technology, 202– (Program), the voluntary certification of 690–7151. health IT for use by pediatric health care www.healthit.gov). We believe this providers, and reasonable and necessary version will make it easier for SUPPLEMENTARY INFORMATION: activities that do not constitute commenters to access and copy portions Table of Contents information blocking. The of the proposed rule for use in their individual comments. Additionally, a I. Executive Summary implementation of these provisions A. Purpose of Regulatory Action would advance interoperability and separate document (‘‘public comment template’’) will also be made available B. Summary of Major Provisions and support the access, exchange, and use of Clarifications electronic health information. The on ONC’s website (http:// 1. Deregulatory Actions for Previous proposed rule would also modify the www.healthit.gov) for the public to use Rulemakings 2015 Edition health IT certification in providing comments on the proposed 2. Updates to the 2015 Edition Certification criteria and Program in additional ways rule. This document is meant to provide Criteria to advance interoperability, enhance the public with a simple and organized a. Adoption of the United States Core Data health IT certification, and reduce way to submit comments on proposals for Interoperability as a Standard b. Electronic Prescribing burden and costs. and respond to specific questions posed in the preamble of the proposed rule. c. Clinical Quality Measures—Report DATES: To be assured consideration, While use of this document is entirely d. Electronic Health Information Export written or electronic comments must be voluntary, we encourage commenters to e. Application Programming Interfaces received at one of the addresses f. Privacy and Security Transparency consider using the document in lieu of Attestations provided below, no later than 5 p.m. on unstructured comments, or to use it as May 3, 2019. g. Data Segmentation for Privacy and an addendum to narrative cover pages. Consent Management ADDRESSES: You may submit comments, We believe that use of the document 3. Modifications to the ONC Health IT identified by RIN 0955–AA01, by any of may facilitate our review and Certification Program the following methods (please do not understanding of the comments 4. Health IT for the Care Continuum submit duplicate comments). Because of received. The public comment template 5. Conditions and Maintenance of staff and resource limitations, we cannot will be available shortly after the Certification accept comments by facsimile (FAX) proposed rule publishes in the Federal 6. Information Blocking transmission. Register. This short delay will permit C. Costs and Benefits • Federal eRulemaking Portal: Follow II. Background the appropriate citation in the public A. Statutory Basis the instructions for submitting comment template to pages of the 1. Standards, Implementation comments. Attachments should be in published version of the proposed rule. Specifications, and Certification Criteria Microsoft Word, Microsoft Excel, or Inspection of Public Comments: All 2. Health IT Certification Program(s) Adobe PDF; however, we prefer comments received before the close of B. Regulatory History Microsoft Word. http:// the comment period will be available for 1. Standards, Implementation www.regulations.gov. public inspection, including any Specifications, and Certification Criteria • Regular, Express, or Overnight Mail: personally identifiable or confidential Rules Department of Health and Human business information that is included in 2. ONC Health IT Certification Program Services, Office of the National a comment. Please do not include Rules III. Deregulatory Actions for Previous Coordinator for Health Information anything in your comment submission Rulemakings Technology, Attention: 21st Century that you do not wish to share with the A. Background Cures Act: Interoperability, Information general public. Such information 1. History of Burden Reduction and Blocking, and the ONC Health IT includes, but is not limited to: A Regulatory Flexibility Certification Program Proposed Rule, person’s social security number; date of 2. Executive Orders 13771 and 13777

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00002 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7425

B. Proposed Deregulatory Actions b. Implementation With FHIR Standard 6. Attestations 1. Removal of Randomized Surveillance C. Unchanged 2015 Edition Criteria— 7. EHR Reporting Criteria Submission Requirements Promoting Interoperability Programs C. Compliance 2. Removal of the 2014 Edition From the Reference Alignment D. Enforcement Code of Federal Regulations V. Modifications to the ONC Health IT 1. ONC Direct Review of the Conditions 3. Removal of the ONC-Approved Certification Program and Maintenance of Certification Accreditor From the Program A. Corrections Requirements 4. Removal of Certain 2015 Edition 1. Auditable Events and Tamper Resistance 2. Review and Enforcement Only by ONC Certification Criteria and Standards 2. Amendments 3. Review Processes a. 2015 Edition Base EHR Definition 3. View, Download, and Transmit to 3rd a. Initiating Review and Health IT Certification Criteria Party Developer Notice b. Drug-Formulary and Preferred Drug Lists 4. Integrating Revised and New b. Relationship with ONC–ACBs and ONC– c. Patient-Specific Education Resources Certification Criteria Into the 2015 ATLs d. Common Clinical Data Set Summary Edition Privacy and Security c. Records Access Record—Create; and Common Clinical Certification Framework d. Corrective Action Data Set Summary Record—Receive B. Principles of Proper Conduct for ONC– e. Certification Ban and Termination e. Secure Messaging ACBs f. Appeal 5. Removal of Certain ONC Health IT 1. Records Retention g. Suspension Certification Program Requirements 2. Conformance Methods for Certification h. Proposed Termination a. Limitations Disclosures Criteria 4. Public Listing of Certification Ban and b. Transparency and Mandatory 3. ONC-ACBs to Accept Test Results From Terminations Disclosures Requirements Any ONC-ATL in Good Standing 5. Effect on Existing Program Requirements 6. Recognition of Food and Drug 4. Mandatory Disclosures and and Processes Administration Processes Certifications 6. Concurrent Enforcement by the Office of a. FDA Software Pre-Certification Pilot C. Principles of Proper Conduct for ONC– Inspector General Program ATLs—Records Retention 7. Applicability of Conditions and b. Development of Similar Independent VI. Health IT for the Care Continuum Maintenance of Certification Program Processes—Request for A. Health IT for Pediatric Setting Requirements for Self-Developers Information 1. Background and Stakeholder Convening VIII. Information Blocking IV. Updates to the 2015 Edition Certification 2. Recommendations for the Voluntary A. Statutory Basis B. Legislative Background and Policy Criteria Certification of Health IT for Use in Considerations A. Standards and Implementation Pediatric Care 1. Purpose of the Information Blocking Specifications a. 2015 Edition Certification Criteria Provision 1. National Technology Transfer and b. New or Revised Certification Criteria in 2. Policy Considerations and Approach to Advancement Act This Proposed Rule the Information Blocking Provisions 2. Compliance with Adopted Standards B. Health IT and Opioid Use Disorder C. Relevant Statutory Terms and Provisions and Implementation Specifications Prevention and Treatment—Request for 1. ‘‘Required by Law’’ 3. ‘‘Reasonably Available’’ to Interested Information 2. Health Care Providers, Health IT Parties 1. 2015 Edition Certification Criteria Developers, Exchanges, and Networks B. Revised and New 2015 Edition Criteria 2. Revised or New 2015 Edition a. Health Care Providers 1. The United States Core Data for Certification Criteria in This Proposed b. Health IT Developers of Certified Health Interoperability Standard (USCDI) Rule IT a. USCDI 2015 Edition Certification 3. Emerging Standards and Innovations c. Networks and Exchanges Criteria 4. Additional Comment Areas 3. Electronic Health Information b. USCDI Standard—Data Classes Included VII. Conditions and Maintenance of 4. Interests Promoted by the Information c. USCDI Standard—Relationship to Certification Blocking Provision Content Exchange Standards and A. Implementation a. Access, Exchange, and Use of EHI Implementation Specifications B. Provisions b. Interoperability Elements d. Clinical Notes C–CDA Implementation 1. Information Blocking 5. Practices That May Implicate the Specification 2. Assurances Information Blocking Provision 2. Electronic Prescribing Criterion a. Full Compliance and Unrestricted a. Prevention, Material Discouragement, 3. Clinical Quality Measures—Report Implementation of Certification Criteria and Other Interference Criterion Capabilities b. Likelihood of Interference 4. Electronic Health Information Export b. Certification to the ‘‘Electronic Health c. Examples of Practices Likely To Interfere Criterion Information Export’’ Criterion With Access, Exchange, or Use of EHI a. Patient Access c. Records and Information Retention 6. Applicability of Exceptions b. Transitions Between Health IT Systems d. Trusted Exchange Framework and the a. Reasonable and Necessary Activities c. Scope of EHI Common Agreement—Request for b. Treatment of Different Types of Actors d. Export Format Information c. Establishing That Activities and e. Initial Step to Persistent Access to All of 3. Communications Practices Meet the Conditions of an a Patient’s EHI a. Background and Purpose Exception f. Timeframes b. Condition of Certification Requirements D. Proposed Exceptions to the Information g. Replaces the 2015 Edition ‘‘Data Export’’ c. Maintenance of Certification Blocking Provision Criterion in the 2015 Edition Base EHR Requirements 1. Preventing Harm Definition 4. Application Programming Interfaces 2. Promoting the Privacy of EHI 5. Standardized API for Patient and a. Statutory Interpretation and API Policy 3. Promoting the Security of EHI Population Services Criterion Principles 4. Recovering Costs Reasonably Incurred 6. Privacy and Security Transparency b. Key Terms 5. Responding to Requests That Are Attestations Criteria c. Proposed API Standards, Infeasible a. Background Implementation Specifications, and 6. Licensing of Interoperability Elements b. Encrypt Authentication Credentials Certification Criterion on Reasonable and Non-discriminatory c. Multi-factor Authentication d. Condition of Certification Requirements Terms 7. Data Segmentation for Privacy and e. Maintenance of Certification 7. Maintaining and Improving Health IT Consent Management Criteria Requirements Performance a. Implementation With the Consolidated f. 2015 Edition Base EHR Definition E. Additional Exceptions—Request for CDA Release 2.1 5. Real World Testing Information

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00003 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7426 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

1. Exception for Complying With Common In addition to fulfilling the Cures appropriate, taken measures to reduce Agreement for Trusted Exchange Act’s requirements, the proposed rule burden within the Program and make 2. New Exceptions would contribute to fulfilling Executive the Program more effective, flexible, and F. Complaint Process Order (E.O.) 13813. The President streamlined. G. Disincentives for Health Care issued E.O. 13813 on October 12, 2017, ONC has reviewed and evaluated Providers—Request for Information existing regulations to identify ways to IX. Registries Request for Information to promote health care choice and X. Patient Matching Request for Information competition across the United States. administratively reduce burden and XI. Incorporation by Reference Section 1(c) of the E.O., in relevant part, implement deregulatory actions through XII. Response to Comments states that government rules affecting guidance. In this proposed rule, we also XIII. Collection of Information Requirements the United States health care system propose potential new deregulatory A. ONC–ACBs should re-inject competition into the actions that will reduce burden for B. Health IT Developers health care markets by lowering barriers health IT developers, providers, and XIV. Regulatory Impact Analysis to entry and preventing abuses of other stakeholders. We propose six A. Statement of Need market power. Section 1(c) also states deregulatory actions in section III.B: (1) B. Alternatives Considered that government rules should improve Removal of a threshold requirement C. Overall Impact related to randomized surveillance 1. Executive Orders 12866 and 13563— access to and the quality of information Regulatory Planning and Review that Americans need to make informed which allows ONC-Authorized Analysis health care decisions. For example, as Certification Bodies (ONC–ACBs) more 2. Executive Order 13771—Reducing mentioned above, the proposed rule flexibility to identify the right approach Regulation and Controlling Regulatory focuses on establishing Application for surveillance actions, (2) removal of Costs Programming Interfaces (APIs) for the 2014 Edition from the Code of a. Costs and Benefits several interoperability purposes, Federal Regulations (CFR), (3) removal b. Accounting Statement and Table including patient access to their health of the ONC-Approved Accreditor (ONC– 3. Regulatory Flexibility Act AA) from the Program, (4) removal of 4. Executive Order 13132—Federalism information without special effort. The API approach also supports health care certain 2015 Edition certification 5. Unfunded Mandates Reform Act of 1995 criteria, (5) removal of certain Program 6. Executive Order 13771 Reducing providers having the sole authority and Regulation and Controlling Regulatory autonomy to unilaterally permit requirements, and (6) recognition of Costs connections to their health IT through relevant Food and Drug Administration Regulation Text certified API technology the health care certification processes with a request for comment on the potential development I. Executive Summary providers have acquired. In addition, the proposed rule provides ONC’s of new processes for the Program. A. Purpose of Regulatory Action interpretation of the information 2. Updates to the 2015 Edition ONC is responsible for the blocking definition as established in the Certification Criteria Cures Act and the application of the implementation of key provisions in This rule proposes to update the 2015 information blocking provision by Title IV of the 21st Century Cures Act Edition by not only proposing criteria identifying reasonable and necessary (Cures Act) that are designed to advance for removal, but by proposing to revise activities that would not constitute interoperability; support the access, and add new certification criteria that information blocking. Many of these exchange, and use of electronic health would establish the capabilities and activities focus on improving patient information; and address occurrences of related standards and implementation and health care provider access to information blocking. This proposed specifications for the certification of electronic health information and rule would implement certain health IT. provisions of the Cures Act, including promoting competition. a. Adoption of the United States Core Conditions and Maintenance of B. Summary of Major Provisions and Data for Interoperability (USCDI) as a Certification requirements for health Clarifications information technology (health IT) Standard developers, the voluntary certification 1. Deregulatory Actions for Previous As part of ONC’s continued efforts to of health IT for use by pediatric health Rulemakings assure the availability of a minimum providers, and reasonable and necessary Since the inception of the Program, baseline of data classes that could be activities that do not constitute we have aimed to implement and commonly available for interoperable information blocking. In addition, the administer the Program in the least exchange, we adopted the 2015 Edition proposed rule would implement parts of burdensome manner that supports our ‘‘Common Clinical Data Set’’ (CCDS) section 4006(a) of the Cures Act to policy goals. Throughout the years, we definition and used the CCDS shorthand support patient access to their electronic have worked to improve the Program in several certification criteria. health information (EHI), such as with a focus on ways to reduce burden, However, the CCDS definition also making a patient’s EHI more offer flexibility to both developers and began to be colloquially used for many electronically accessible through the providers, and support innovation. This different purposes. As the CCDS adoption of standards and certification approach has been consistent with the definition’s relevance grew outside of its criteria and the implementation of principles of Executive Order 13563 on regulatory context, it became a symbolic information blocking policies that Improving Regulation and Regulatory and practical limit to the industry’s support patient electronic access to their Review (February 2, 2011), which collective interests to go beyond the health information at no cost. instructs agencies to ‘‘determine CCDS data for access, exchange, and Additionally, the proposed rule would whether any [agency] regulations should use. In addition, as we move further modify the 2015 Edition health IT be modified, streamlined, expanded, or towards value-based care, the need for certification criteria and ONC Health IT repealed so as to make the agency’s the inclusion of additional data classes Certification Program (Program) in other regulatory program more effective or that go beyond clinical data is ways to advance interoperability, less burdensome in achieving the necessary. In order to advance enhance health IT certification, and regulatory objectives.’’ To that end, we interoperability, we propose to remove reduce burden and costs. have historically, where feasible and the CCDS definition and its references

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00004 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7427

from the 2015 Edition and replace it c. Clinical Quality Measures—Report e. Application Programming Interfaces with the ‘‘United States Core Data for (APIs) Interoperability.’’ We propose to adopt We propose to remove the HL7 Quality Reporting Document We propose to adopt a new API the USCDI as a standard, naming USCDI criterion in § 170.315(g)(10), which Architecture (QRDA) standard Version 1 (USCDI v1) in § 170.213 and would replace the ‘‘application access— requirements from the 2015 Edition incorporating it by reference in data category request’’ certification § 170.299. The USCDI standard, if ‘‘CQMs—report’’ criterion in criterion (§ 170.315(g)(8)) and become adopted, would establish a set of data § 170.315(c)(3) and, in their place, part of the 2015 Edition Base EHR classes and constituent data elements require Health IT Modules to support definition. This new ‘‘standardized API that would be required to be exchanged the CMS QRDA Implementation Guide for patient and population services’’ 1 in support of interoperability (IGs). This would reduce the burden for certification criterion would require the nationwide. To achieve the goals set health IT developers by only having to use of Health Level 7 (HL7®) Fast forth in the Cures Act, ONC intends to support one form of the QRDA standard Healthcare Interoperability Resources ® establish and follow a predictable, rather than two forms (i.e., the HL7 and (FHIR ) standards 2 and several transparent, and collaborative process to CMS forms). implementation specifications. The new criterion would focus on supporting two expand the USCDI, including providing d. Electronic Health Information Export stakeholders with the opportunity to types of API-enabled services: (1) comment on the USCDI’s expansion. We propose a new 2015 Edition Services for which a single patient’s Once the USCDI is adopted in certification criterion for ‘‘electronic data is the focus and (2) services for which multiple patients’ data are the regulation naming USCDI v1, health IT health information (EHI) export’’ in focus. developers would be allowed to take § 170.315(b)(10), which would replace advantage of a flexibility under the the 2015 Edition ‘‘data export’’ f. Privacy and Security Transparency Maintenance of Certification real world certification criterion (§ 170.315(b)(6)) Attestations testing requirements, which we refer to and become part of the 2015 Edition We propose to adopt two new privacy as the ‘‘Standards Version Advancement Base EHR definition. The proposed and security transparency attestation Process’’ (described in section VII.B.5 of criterion supports situations in which certification criteria, which would this proposed rule). The Standards we believe that all EHI produced and identify whether certified health IT Version Advancement Process would electronically managed by a developer’s supports encrypting authentication permit health IT developers to health IT should be made readily credentials and/or multi-factor voluntarily implement and use a new available for export as a standard authentication. In order to be issued a version of an adopted standard, such as capability of certified health IT. certification, we propose to require that the USCDI, so long as the newer version Specifically, this criterion would: (1) a Health IT Module developer attest to was approved by the National Enable the export of EHI for a single whether the Health IT Module encrypts Coordinator through the Standards patient upon a valid request from that authentication credentials and whether Version Advancement Process for use in patient or a user on the patient’s behalf, the Health IT Module supports multi- certification. and (2) support the export of EHI when factor authentication. These criteria are a health care provider chooses to not expected to place additional burden b. Electronic Prescribing on health IT developers since they do transition or migrate information to not require net new development or another health IT system. This criterion We propose to update the electronic implementation to take place in order to prescribing (e-Rx) SCRIPT standard in would also require that the export be met. However, certification to these 45 CFR 170.205(b) to NCPDP SCRIPT include the data format, made publicly proposed criteria would provide 2017071, which would result in a new available, to facilitate the receiving increased transparency and potentially e-Rx standard eventually becoming the health IT system’s interpretation and motivate health IT developers to encrypt baseline for certification. We also use of the EHI to the extent reasonably authentication credentials and support propose to adopt a new certification practicable using the developer’s multi- factor authentication, which criterion in § 170.315(b)(11) for e-Rx to existing technology. could help prevent exposure to reflect these updated proposals. ONC This criterion provides developers unauthorized persons/entities. and CMS have historically maintained with the ability to create innovative g. Data Segmentation for Privacy and complementary policies of maintaining export capabilities according to their Consent Management aligned e-Rx and medical history (MH) systems and data practices. We do not In the 2015 Edition, we adopted two standards to ensure that the current propose that the export must be ‘‘data segmentation for privacy’’ (DS4P) standard for certification to the executed according to any particular electronic prescribing criterion permits certification criteria, one for creating a standard, but propose to require that the summary record according to the DS4P use of the current Part D e-Rx and MH export must be accompanied by the data standards. This proposal is made to standard and one for receiving a format, including its structure and summary record according to the DS4P ensure such alignment as CMS recently syntax, to facilitate interpretation of the standard. Certification to the 2015 finalized its Part D standards to NCPDP EHI therein. Overall, this new criterion Edition DS4P criteria focus on data SCRIPT 2017071 for e-RX and MH, is intended to provide patients and segmentation only at the document effective January 1, 2020 (83 FR 16440). health IT users, including providers, a level. As noted in the 2015 Edition final In addition to continuing to reference means to efficiently export the entire rule (80 FR 62646)—and to our the current transactions included in electronic health record for a single knowledge still an accurate § 170.315(b)(3), in keeping with CMS’ patient or all patients in a computable, assessment—certification to these final rule, we also propose to require all electronic format. criteria is currently not required to meet of the NCPDP SCRIPT 2017071 standard the Certified EHR Technology definition transactions CMS adopted at 42 CFR 1 https://ecqi.healthit.gov/qrda-quality-reporting- 423.160(b)(2)(iv). document-architecture. 2 https://www.hl7.org/fhir/overview.html.

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00005 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7428 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

(CEHRT) or required by any other HHS Programs) and provide other necessary sites of service. Through the information program. Since the 2015 Edition final clarifications. learned at this listening session and our rule, the health care industry has We propose to revise a PoPC for analysis of the health IT landscape for engaged in additional field testing and ONC–ATLs. We propose to clarify that pediatric settings, we have identified implementation of the DS4P standard. the records retention provision includes existing 2015 Edition criteria, as well as In addition, stakeholders shared with the ‘‘life of the edition’’ as well as after new and revised 2015 Edition criteria ONC—through public forums, listening the retirement of an edition related to proposed in this rule, that we believe sessions, and correspondence—that the certification of Complete EHRs and could benefit providers of pediatric care focusing certification on segmentation Health IT Modules. and pediatric settings. In this proposed to only the document level does not 4. Health IT for the Care Continuum rule, we seek comment on our analysis permit providers the flexibility to and the correlated certification criteria address more granular segmentation Section 4001(b) of the Cures Act that we believe would support the needs. Therefore, we propose to remove includes two provisions related to health care of children. the current 2015 Edition DS4P criteria. supporting health IT across the care We also recognize the significance of We propose to replace these two criteria continuum. The first instructs the the opioid epidemic confronting our with three new 2015 Edition ‘‘DS4P’’ National Coordinator to encourage, keep nation and the importance of helping to certification criteria (two for C–CDA and or recognize through existing support the health IT needs of health one for a FHIR-based API) that would authorities, the voluntary certification of care providers committed to preventing support a more granular approach to health IT for use in medical specialties inappropriate access to prescription privacy tagging data consent and sites of service where more opioids and to providing safe, management for health information technological advancement or appropriate treatment. We believe integration is needed. The second exchange supported by either the health IT offers promising strategies to outlines a provision related to the C–CDA- or FHIR-based exchange help assist medical specialties and sites voluntary certification of health IT for standards. of services impacted by the opioid use by pediatric health providers to epidemic. Therefore, we request public 3. Modifications to the ONC Health IT support the health care of children. comment on how our existing Program Certification Program These provisions align closely with requirements and the proposals in this ONC’s core purpose to promote rulemaking may support use cases We propose to make corrections to the interoperability to support care 2015 Edition privacy and security related to Opioid Use Disorder (OUD) coordination, patient engagement, and prevention and treatment and if there certification framework (80 FR 62705) health care quality improvement and relevant regulatory provisions. are additional areas that ONC should initiatives. Advancing health IT that consider for effective implementation of These corrections have already been promotes and supports patient care incorporated in the relevant health IT to help address OUD when and where it is needed continues prevention and treatment. Certification Companion Guides (CCGs). to be a primary goal of the Program. We propose new and revised This means health IT should support 5. Conditions and Maintenance of principles of proper conduct (PoPC) for patient populations, specialized care, Certification ONC-Authorized Certification Bodies transitions of care, and practice settings We propose to establish certain (ONC–ACBs). We propose to clarify that across the care continuum. Conditions and Maintenance of the records retention provision includes ONC has explored how we might Certification requirements for health IT the ‘‘life of the edition’’ as well as after work with the health IT industry and developers based on the conditions and the retirement of an edition related to with specialty organizations to maintenance of certification the certification of Complete EHRs and collaboratively develop and promote requirements outlined in section 4002 of Health IT Modules. We also propose to health IT that supports medical the Cures Act. We propose an approach revise the PoPC in § 170.523(h) to clarify specialties and sites of service. Over whereby the Conditions and the basis for certification, including to time, ONC has taken steps to make the Maintenance of Certification express permit a certification decision to be Program modular, more open and both initial requirements for health IT based on an evaluation conducted by accessible to different types of health IT, developers and their certified Health IT the ONC–ACB for Health IT Modules’ and able to advance functionality that is Module(s) as well as ongoing compliance with certification criteria by generally applicable to a variety of care requirements that must be met by both use of conformity methods approved by and practice settings. Specific to the health IT developers and their certified the National Coordinator for Health provisions in the Cures Act to support Health IT Module(s) under the Program. Information Technology (National providers of health care for children, we In this regard, we propose to implement Coordinator). We also propose to update considered a wide range of factors. the Cures Act Conditions of § 170.523(h) to require ONC–ACBs to These include: The evolution of health Certification with further specificity as accept test results from any ONC–ATL IT across the care continuum, the costs it applies to the Program and propose to that is in good standing under the and benefits associated with health IT, implement any accompanying Program and is compliant with its ISO the potential regulatory burden and Maintenance of Certification 17025 accreditation requirements. We compliance timelines, and the need to requirements as standalone believe these proposed new and revised help advance health IT that benefits requirements to ensure that not only are PoPCs would provide necessary multiple medical specialties and sites of the Conditions of Certification met, but clarifications for ONC–ACBs and would service involved in the care of children. that they are continually being met promote stability among the ONC– In consideration of these factors, and to through the Maintenance of ACBs. We also propose to update advance implementation of Sections Certification requirements. For ease of § 170.523(k) to broaden the 4001(b) of the Cures Act specific to reference and to distinguish from other requirements beyond just the Medicare pediatric care, we held a listening conditions, we propose to capitalize and Medicaid Electronic Health Record session where stakeholders could share ‘‘Conditions of Certification’’ and (EHR) Incentive Programs (now their clinical knowledge and technical ‘‘Maintenance of Certification’’ when renamed the Promoting Interoperability expertise in pediatric care and pediatric referring to Conditions and Maintenance

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00006 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7429

of Certification requirements established communications—such as standards updates for widespread and under the Cures Act. communications required by law, made continued interoperability. to a government agency, or made to a We propose to limit the applicability Information Blocking defined category of safety of this Condition of Certification to The Cures Act requires that a health organization—would receive health IT developers with Health IT IT developer, as a Condition and ‘‘unqualified protection,’’ meaning that Modules certified to one or more 2015 Maintenance of Certification under the developers would be absolutely Edition certification criteria focused on Program, not take any action that prohibited from imposing any interoperability and data exchange constitutes information blocking as prohibitions or restrictions on such specified in section VII.B.5. We propose defined in section 3022(a) of the Public protected communications. Maintenance of Certification Health Service Act (PHSA). We propose We propose that to maintain requirements that would require health to establish this information blocking compliance with this Condition of IT developers to submit publicly Condition of Certification in § 170.401. Certification, a health IT developer must available annual real world testing plans The Condition of Certification would not impose or enforce any contractual as well as annual real world testing prohibit any health IT developer under requirement or legal right that results for certified health IT products the Program from taking any action that contravenes this Condition of focused on interoperability. We also constitutes information blocking as Certification. Furthermore, we propose propose a Maintenance of Certification defined by section 3022(a) of the PHSA that if a health IT developer has flexibility we have named the Standards and proposed in § 171.103. contracts/agreements in existence that Version Advancement Process, under Assurances contravene this condition, the developer which health IT developers with health IT certified to the criteria specified for Section 3001(c)(5)(D)(ii) of the Cures must notify all affected customers or other persons or entities that the interoperability and data exchange Act requires that a health IT developer, would have the option to update their as a Condition of Certification under the prohibition or restriction will not be enforced by the health IT developer. health IT to a more advanced version(s) Program, provide assurances to the of the standard(s) or implementation Going forward, health IT developers Secretary that, unless for legitimate specification(s) included in the criteria would be required to amend their purposes specified by the Secretary, the once such versions are approved by the contracts/agreements to remove or make developer will not take any action that National Coordinator through the void the provisions that contravene this constitutes information blocking as Standards Version Advancement Condition of Certification within a defined in section 3022(a) of the PHSA, Process for use in health IT certified reasonable period of time, but not later or any other action that may inhibit the under the Program. Similarly, we than two years from the effective date of appropriate exchange, access, and use of propose that health IT developers a subsequent final rule for this proposed EHI. We propose to implement this presenting new health IT for rule. provision through several Conditions of certification to one of the criteria Certification and accompanying Application Programming Interfaces specified in Section VII.B.5 would have Maintenance requirements, which are (APIs) the option to certify to a National set forth in proposed § 170.402. We also Coordinator-approved more advanced propose to establish more specific The Cures Act’s API Condition of version of the adopted standards or Conditions and Maintenance of Certification includes several key implementation specifications included Certification requirements to provide phrases (including, for example, in the criteria. We propose that health assurances that a health IT developer ‘‘without special effort’’) and IT developers voluntarily opting to avail does not take any other action that may requirements for health IT developers themselves of the Standards Version inhibit the appropriate exchange, that indicate the Cures Act’s focus on Advancement Process must address access, and use of EHI. These proposed the technical requirements as well as their planned and actual timelines for requirements serve to provide further the actions and practices of health IT implementation and rollout of standards clarity under the Program as to how developers in implementing the updates in their annual real world health IT developers can provide such certified API. In section VII.B.4 of the testing plans and real world testing broad assurances with more specific preamble, we outline our proposals to results submissions. We also propose actions. implement the Cures Act’s API that health IT developers of products Condition of Certification. These Communications with existing certifications who plan to proposals include new standards, new avail themselves of the Standards As a Condition and Maintenance of implementation specifications, a new Version Advancement Process Certification under the Program, the certification criterion, as well as flexibility notify both their ONC–ACB Cures Act requires that health IT detailed Conditions and Maintenance of and their affected customers of their developers do not prohibit or restrict Certification requirements. intention and plans to update their communications about certain aspects Real World Testing certified health IT and its anticipated of the performance of health IT and the impact on their existing certified health developers’ related business practices. The Cures Act adds a new Condition IT and customers, specifically including We propose that developers will be and Maintenance of Certification but not limited to whether, and if so for permitted to impose certain kinds of requirement that health IT developers how long, the health IT developer limited prohibitions and restrictions successfully test the real world use of intends to continue to support the that we believe strike a reasonable the technology for interoperability in certificate for the health IT certified to balance between the need to promote the type of setting in which such the prior version of the standard. open communication about health IT technology would be marketed. In this We propose a new PoPC for ONC– and related developer business practices proposed rule, we outline what ACBs that would require ONC–ACBs to and the need to protect the legitimate successful ‘‘real world testing’’ means review and confirm that applicable interests of health IT developers and for the purpose of this Condition of health IT developers submit real world other entities. However, certain Certification, as well as proposed testing plans and real world results in narrowly-defined types of Maintenance requirements—including accordance with our proposals. Once

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00007 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7430 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

completeness is confirmed, ONC–ACBs PHSA, as added by the Cures Act. We We identify several reasonable and would upload the plans and results via have not yet established an EHR necessary activities as exceptions to the hyperlinks to the Certified Health IT reporting program. Once ONC information blocking definition, each of Product List (CHPL). We propose to establishes such program, we will which we propose would not constitute revise the PoPC in § 170.523(m) to undertake rulemaking to propose and information blocking for purposes of require ONC–ACBs to collect, no less implement the associated Condition and section 3022(a)(1) of the PHSA. The than quarterly, all updates successfully Maintenance of Certification exceptions would extend to certain made to standards in certified health IT requirement(s) for health IT developers. activities that interfere with the access, pursuant to the developers having exchange, or use of EHI but that may be Enforcement voluntarily opted to avail themselves of reasonable and necessary if certain the Standards Version Advancement Section 4002 of the Cures Act adds conditions are met. Process flexibility under the real world Program requirements aimed at In developing the proposed testing Condition of Certification. We addressing health IT developer actions exceptions, we were guided by three propose in § 170.523(t), a new PoPC for and business practices through the overarching policy considerations. First, ONC–ACBs requiring them to ensure Conditions and Maintenance of the exceptions would be limited to that developers seeking to take Certification requirements, which certain activities that clearly advance advantage of the Standards Version expands the current focus of the the aims of the information blocking Advancement Process flexibility in Program requirements beyond the provision; promoting public confidence § 170.405(b)(5) comply with the certified health IT itself. Equally in health IT infrastructure by supporting applicable requirements. important, section 4002 also provides the privacy and security of EHI, and Attestations that the Secretary of HHS may protecting patient safety; and promoting encourage compliance with the competition and innovation in health IT The Cures Act requires that a health Conditions and Maintenance of and its use to provide health care IT developer, as a Condition and Certification requirements and take services to consumers. Second, each Maintenance of Certification under the action to discourage noncompliance. exception is intended to address a Program, provide to the Secretary an We, therefore, propose a general significant risk that regulated attestation to all the Conditions of enforcement approach to encourage individuals and entities (i.e., health care Certification specified in the Cures Act, consistent compliance with the providers, health IT developers of except for the ‘‘EHR reporting criteria certified health IT, health information submission’’ Condition of Certification. requirements. The proposed rule We propose to implement the Cures Act outlines a corrective action process for networks, and health information ‘‘attestations’’ Condition of Certification ONC to review potential or known exchanges) will not engage in these in § 170.406. Health IT developers instances where a Condition or reasonable and necessary activities would attest twice a year to compliance Maintenance of Certification because of potential uncertainty with the Conditions and Maintenance of requirement has not been or is not being regarding whether they would be Certification requirements (except for met by a health IT developer under the considered information blocking. Third, the EHR reporting criteria requirement, Program. We propose, with minor and last, each exception is intended to which would be metrics reporting modifications, to utilize the processes be tailored, through appropriate requirements separately implemented previously established for ONC direct conditions, so that it is limited to the through a future rulemaking). The review of certified health IT and reasonable and necessary activities that 6-month attestation period we propose codified in §§ 170.580 and 170.581 for it is designed to exempt. in § 170.406(b)(2) would properly the enforcement of the Conditions and The seven proposed exceptions are set balance the need to support appropriate Maintenance of Certification forth in section VIII.D below. The first enforcement with the attestation burden requirements. Where noncompliance is three exceptions, set forth in VIII.D.1– placed on health IT developers. In this identified, our first priority would be to D.3 address activities that are reasonable regard, the proposed rule includes work with the health IT developer to and necessary to promote public provisions to make the process as remedy the matter through a corrective confidence in the use of health IT and simple and efficient for health IT action process. However, we propose the exchange of EHI. These exceptions developers as possible (e.g., 14-day that, under certain circumstances, ONC are intended to protect patient safety; grace period, web-based form may ban a health IT developer from the promote the privacy of EHI; and submissions, and attestation alert Program or terminate the certification of promote the security of EHI. The next reminders). one or more of its Health IT Modules. three exceptions, set forth in VIII.D.4– We propose that attestations would be 6. Information Blocking D.6, address activities that are submitted to ONC–ACBs on behalf of reasonable and necessary to promote ONC and the Secretary. We propose a Section 4004 of the Cures Act added competition and consumer welfare. new PoPC in § 170.523(q) that an ONC– section 3022 of the PHSA (42 U.S.C. These exceptions would allow for the ACB must review and submit the health 300jj–52, ‘‘the information blocking recovery of costs reasonably incurred; IT developers’ attestations to ONC. ONC provision’’), which defines conduct by excuse an actor from responding to would then make the attestations health care providers, and health IT requests that are infeasible; and permit publicly available through the CHPL. developers of certified health IT, the licensing of interoperability exchanges, and networks that elements on reasonable and non- EHR Reporting Criteria Submission constitutes information blocking. discriminatory terms. The last The Cures Act specifies that health IT Section 3022(a)(1) of the PHSA defines exception, set forth in VIII.D.7, developers be required, as a Condition information blocking in broad terms, addresses activities that are reasonable and Maintenance of Certification under while section 3022(a)(3) authorizes and and necessary to promote the the Program, to submit reporting criteria charges the Secretary to identify performance of health IT. This proposed on certified health IT in accordance reasonable and necessary activities that exception recognizes that actors may with the EHR reporting program do not constitute information blocking make health IT temporarily unavailable established under section 3009A of the (section 3022(a)(3) of the PHSA). for maintenance or improvements that

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00008 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7431

benefit the overall performance and consistently. We also note that we did provisions to the PHSA relating to usability of health IT. not have adequate data to quantify some health IT. To qualify for any of these exceptions, of the costs and benefits within this 1. Standards, Implementation we propose that an individual or entity RIA. In those situations, we have Specifications, and Certification Criteria would, for each relevant practice and at described the qualitative costs and all relevant times, have to satisfy all of benefits of our proposals; however, such The HITECH Act established two new the applicable conditions of the qualitative costs and benefits have not federal advisory committees, the HIT exception. Additionally, we propose (in been accounted for in the monetary cost Policy Committee (HITPC) and the HIT section VIII.C of this preamble) to define and benefit totals below. Standards Committee (HITSC). Each or interpret terms that are present in We estimate that the total annual cost was responsible for advising the section 3022 of the PHSA (such as the for this proposed rule for the first year National Coordinator for Health types of individuals and entities after it is finalized (including one-time Information Technology (National Coordinator) on different aspects of covered by the information blocking costs), based on the cost estimates standards, implementation provision). We also propose certain new outlined above and throughout this RIA, terms and definitions that are necessary specifications, and certification criteria. would, on average, range from $365 Section 3002 of the Cures Act to implement the information blocking million to $919 million with an average provisions. We propose to codify the amended the PHSA by replacing the annual cost of $642 million. We HITPC and HITSC with one committee, proposed exceptions and other estimate that the total perpetual cost for information blocking proposals in a new the Health Information Technology this proposed rule (starting in year two), Advisory Committee (HIT Advisory part of title 45 of the Code of Federal based on the cost estimates outlined Regulations, part 171. Committee or HITAC). Section 3002(a) above, would, on average, range from establishes that the HITAC shall advise C. Costs and Benefits $228 million to $452 million with an and recommend to the National Executive Orders 12866 on Regulatory average annual cost of $340 million. Coordinator on different aspects of Planning and Review (September 30, We estimate the total annual benefit standards, implementation 1993) and 13563 on Improving for this proposed rule would range from specifications, and certification criteria, Regulation and Regulatory Review $3.08 billion to $9.15 billion with an relating to the implementation of a (February 2, 2011) direct agencies to average annual benefit of $6.1 billion. health IT infrastructure, nationally and assess all costs and benefits of available We estimate the total annual net locally, that advances the electronic regulatory alternatives and, if regulation benefit for this proposed rule for the access, exchange, and use of health is necessary, to select regulatory first year after it is finalized (including information. Further described in approaches that maximize net benefits one-time costs), based on the cost and section 3002(b)(1)(A) of the PHSA, this (including potential economic, benefit estimates outlined above, would includes providing to the National environmental, public health and safety range from $2.7 billion to $8.2 billion Coordinator recommendations on a effects, distributive impacts, and with an average net benefit of $5.5 policy framework to advance equity). A regulatory impact analysis billion. We estimate the total perpetual interoperable health IT infrastructure, (RIA) must be prepared for major rules annual net benefit for this proposed rule updating recommendations to the policy with economically significant effects (starting in year two), based on the cost- framework, and making new ($100 million or more in any one year). benefit estimates outlined above, would recommendations, as appropriate. OMB has determined that this proposed range from $2.9 billion to $8.7 billion Section 3002(b)(2)(A) identifies that in rule is an economically significant rule with an average net benefit of $5.8 general, the HITAC shall recommend to as the potential costs associated with billion. the National Coordinator for purposes of this proposed rule could be greater than adoption under section 3004, standards, $100 million per year. Accordingly, we II. Background implementation specifications, and have prepared an RIA that to the best of A. Statutory Basis certification criteria and an order of our ability presents the costs and priority for the development, benefits of this proposed rule. The Health Information Technology harmonization, and recognition of such We have estimated the potential for Economic and Clinical Health standards, specifications, and monetary costs and benefits of this (HITECH) Act, Title XIII of Division A certification criteria. Like the process proposed rule for health IT developers, and Title IV of Division B of the previously required of the former HITPC health care providers, patients, ONC– American Recovery and Reinvestment and HITSC, the HITAC will develop a ACBs, ONC–ATLs, and the federal Act of 2009 (the Recovery Act) (Pub. L. schedule for the assessment of policy government (i.e., ONC), and have 111–5), was enacted on February 17, recommendations for the Secretary to broken those costs and benefits out into 2009. The HITECH Act amended the publish in the Federal Register. the following categories: (1) Public Health Service Act (PHSA) and Section 3004 of the PHSA identifies a Deregulatory actions (no associated created ‘‘Title XXX—Health Information process for the adoption of health IT costs); (2) updates to the updates to the Technology and Quality’’ (Title XXX) to standards, implementation 2015 Edition health IT certification improve health care quality, safety, and specifications, and certification criteria criteria; (3) Conditions and Maintenance efficiency through the promotion of and authorizes the Secretary to adopt of Certification for a health IT health IT and electronic health such standards, implementation developer; (4) oversight for the information (EHI) exchange. specifications, and certification criteria. Conditions and Maintenance of The Cures Act was enacted on As specified in section 3004(a)(1), the Certification; and (5) information December 13, 2016, to accelerate the Secretary is required, in consultation blocking. discovery, development, and delivery of with representatives of other relevant We note that we have rounded all 21st century cures, and for other federal agencies, to jointly review estimates to the nearest dollar and all purposes. The Cures Act, through Title standards, implementation estimates are expressed in 2016 dollars IV—Delivery, amended the HITECH Act specifications, and certification criteria as it is the most recent data available to (Title XIII of Division A of Pub. L. 111– endorsed by the National Coordinator address all cost and benefit estimates 5) by modifying or adding certain under section 3001(c) and subsequently

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00009 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7432 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

determine whether to propose the technology is available or where more specified the related standards and adoption of any grouping of such technological advancement or implementation specifications that standards, implementation integration is needed. Section CEHRT would need to include to, at a specifications, or certification criteria. 3001(c)(5)(C)(iii) identifies that the minimum, support the achievement of The Secretary is required to publish all Secretary, in consultation with relevant ‘‘meaningful use’’ by eligible clinicians, determinations in the Federal Register. stakeholders, shall make eligible hospitals, and critical access Section 3004(b)(3) of the PHSA titled, recommendations for the voluntary hospitals under the Medicare and Subsequent Standards Activity, certification of health IT for use by Medicaid EHR Incentive Programs (EHR provides that the Secretary shall adopt pediatric health providers to support the Incentive Programs) (now referred to as additional standards, implementation care of children, as well as adopt the Promoting Interoperability specifications, and certification criteria certification criteria under section 3004 Programs) 3 when the 2015 Edition is as necessary and consistent with the to support the voluntary certification of required for use under these and other schedule published by the HITAC. We health IT for use by pediatric health programs referencing the CEHRT consider this provision in the broader providers. The Cures Act further definition. The 2015 Edition final rule context of the HITECH Act and Cures amended section 3001(c)(5) of the PHSA also made changes to the Program. The Act to grant the Secretary the authority by adding section 3001(c)(5)(D), which final rule adopted a proposal to change and discretion to adopt standards, provides the Secretary with the the Program’s name to the ‘‘ONC Health implementation specifications, and authority, through notice and comment IT Certification Program’’ from the ONC certification criteria that have been rulemaking, to require conditions and HIT Certification Program, modified the recommended by the HITAC and maintenance of certification Program to make it more accessible to endorsed by the National Coordinator, requirements for the Program. other types of health IT beyond EHR as well as other appropriate and technology and for health IT that B. Regulatory History necessary health IT standards, supports care and practice settings implementation specifications, and The Secretary issued an interim final beyond the ambulatory and inpatient certification criteria. rule with request for comments (75 FR settings, and adopted new and revised 2014, Jan. 13, 2010), which adopted an 2. Health IT Certification Program(s) Principles of Proper Conduct (PoPC) for initial set of standards, implementation ONC–ACBs. Under the HITECH Act, section specifications, and certification criteria. After issuing a proposed rule on 3001(c)(5) of the PHSA provides the On March 10, 2010, ONC published a March 2, 2016 (81 FR 11056), ONC National Coordinator with the authority proposed rule (75 FR 11328) that published a final rule titled, ‘‘ONC to establish a certification program or proposed both a temporary and Health IT Certification Program: programs for the voluntary certification permanent certification program for the Enhanced Oversight and of health IT. Specifically, section purposes of testing and certifying health Accountability’’ (81 FR 72404) (‘‘EOA 3001(c)(5)(A) specifies that the National IT. A final rule establishing the final rule’’) on October 19, 2016. The Coordinator, in consultation with the temporary certification program was final rule finalized modifications and Director of the National Institute of published on June 24, 2010 (75 FR new requirements under the Program, Standards and Technology (NIST), shall 36158) and a final rule establishing the including provisions related to ONC’s keep or recognize a program or permanent certification program was role in the Program. The final rule programs for the voluntary certification published on January 7, 2011 (76 FR created a regulatory framework for of health IT that is in compliance with 1262). ONC issued multiple ONC’s direct review of health IT applicable certification criteria adopted rulemakings since these initial certified under the Program, including, under this subtitle (i.e., certification rulemaking to update standards, when necessary, requiring the criteria adopted by the Secretary under implementation specifications, and correction of non-conformities found in section 3004 of the PHSA). The certification criteria and the certification health IT certified under the Program certification program(s) must also program, a history of which can be and suspending and terminating include, as appropriate, testing of the found in the final rule titled, ‘‘2015 certifications issued to Complete EHRs technology in accordance with section Edition Health Information (Health IT) and Health IT Modules. The final rule 13201(b) of the HITECH Act. Overall, Certification Criteria, 2015 Edition Base also sets forth processes for ONC to section 13201(b) of the HITECH Act Electronic Health Record (EHR) authorize and oversee accredited testing requires that with respect to the Definition, and ONC Health IT laboratories under the Program. In development of standards and Certification Program Modifications’’ addition, it includes provisions for implementation specifications, the (Oct. 16, 2015, 80 FR 62602) (‘‘2015 expanded public availability of certified Director of NIST shall support the Edition final rule’’). A correction notice health IT surveillance results. establishment of a conformance testing was published for the 2015 Edition final infrastructure, including the rule on December 11, 2015 (80 FR III. Deregulatory Actions for Previous development of technical test beds. The 76868) to correct preamble and Rulemakings HITECH Act also indicates that the regulatory text errors and clarify A. Background development of this conformance requirements of the Common Clinical testing infrastructure may include a Data Set (CCDS), the 2015 Edition 1. History of Burden Reduction and program to accredit independent, non- privacy and security certification Flexibility federal laboratories to perform testing. framework, and the mandatory Since the inception of the ONC Health Section 3001(c)(5) of the PHSA was disclosures for health IT developers. IT Certification Program (Program), we amended by the Cures Act, which The 2015 Edition final rule have aimed to implement and instructs the National Coordinator to established a new edition of administer the Program in the least encourage, keep, or recognize, through certification criteria (‘‘2015 Edition burdensome manner that supports our existing authorities, the voluntary health IT certification criteria’’ or ‘‘2015 policy goals. Throughout the years, we certification of health IT under the Edition’’) and a new 2015 Edition Base Program for use in medical specialties EHR definition. The 2015 Edition 3 https://www.federalregister.gov/d/2018-16766/ and sites of service for which no such established the capabilities and p-4.

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00010 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7433

have worked to improve the Program In the 2015 Edition final rule, we did guidance, and to propose potential new with a focus on ways to reduce burden, not ‘‘carry forward’’ certain 2014 deregulatory actions in this proposed offer flexibility to both developers and Edition certification criteria into the rule that will reduce burden for health providers, and support innovation. This 2015 Edition, such as the ‘‘image IT developer, providers, and other approach has been consistent with the results,’’ ‘‘patient list creation,’’ and stakeholders. principles of Executive Order 13563 on ‘‘electronic medication administration On August 21, 2017, ONC issued Improving Regulation and Regulatory record’’ criteria. We determined that Relied Upon Software Program Review (February 2, 2011), which these criteria did not advance Guidance.5 Health IT developers are instructs agencies to ‘‘determine functionality or support interoperability permitted to use ‘‘relied upon software’’ whether any [agency] regulations should (80 FR 62682–84). We also did not (76 FR 1276) to demonstrate compliance be modified, streamlined, expanded, or require all health IT to be certified to the with certification criteria adopted at 45 repealed so as to make the agency’s ‘‘meaningful use measurement’’ CFR part 170, subpart C. Historically, in regulatory program more effective or certification criteria for ‘‘automated cases where a Health IT Module is less burdensome in achieving the numerator recording’’ and ‘‘automated paired with multiple ‘‘relied upon regulatory objectives.’’ To that end, we measure calculation’’ (80 FR 62605), software’’ products for the same have historically, where feasible and which had been previously required for capability, health IT developers were appropriate, taken measures to reduce the 2014 Edition. Based on stakeholder required to demonstrate compliance for burden within the Program and make feedback and Program administration the same certification criterion with the Program more effective, flexible, and observations, we also permitted testing each of those ‘‘relied upon software’’ streamlined. efficiencies for the 2015 Edition products in order for the products to be For example, in the 2014 Edition final ‘‘automated numerator recording’’ and listed on the Certified Health IT Product rule (77 FR 54164), we revised the ‘‘automated measure calculation’’ List (CHPL). With the issued guidance, certified electronic health record criteria by removing the live health IT developers may now technology (CEHRT) definition to demonstration requirement of recording demonstrate compliance with only one provide flexibility and create regulatory data and generating reports. Health IT ‘‘relied upon software’’ product for a efficiencies by narrowing required developers may now self-test their criterion/capability. Once the health IT functionality to a core set of capabilities Health IT Modules(s) and submit the developer demonstrates compliance (i.e., the Base EHR definition) plus the resulting reports to the ONC- with a minimum of one ‘‘relied upon additional capabilities each eligible Authorized Testing Laboratory (ONC– software’’ product, the developer can clinician, eligible hospital, and critical ATL) to verify compliance with the have multiple, additional ‘‘relied upon access hospital needed to successfully criterion.4 In order to further reduce software’’ products for the same achieve the applicable objective and burden for health IT developers, we criterion/capability listed on the CHPL measures under the EHR Incentive adopted a simpler, straight-forward (https://chpl.healthit.gov/). This Programs (now referred to as the approach to privacy and security approach reduces burden for health IT Promoting Interoperability Programs). certification requirements, which developers, ONC–ATLs, and ONC- ONC has also supported more efficient clarified which requirements are Authorized Certification Bodies (ONC– testing and certification methods and applicable to each criterion within the ACBs). On September 21, 2017, ONC reduced reduced regulatory burden through the regulatory functional areas (80 FR the overall burden for testing health IT adoption of a gap certification policy. 62605). As explained in the 2014 Edition final to the 2015 Edition.6 ONC reviewed the rule (77 FR 54254) and the 2015 Edition 2. Executive Orders 13771 and 13777 2015 Edition test procedures, which final rule (80 FR 62681), where On January 30, 2017, the President identify minimum testing requirements applicable, gap certification allows for issued Executive Order 13771 on ONC–ATLs must evaluate during the use of a previously certified health Reducing Regulation and Controlling testing. ONC changed 30 of the 2015 IT product’s test results to certification Regulatory Costs, which requires Edition test procedures to attestation criteria identified as unchanged. agencies to identify deregulatory only (i.e., a ‘‘yes’’ self-declaration by the Developers have been able to use gap actions. This order was followed by health IT developer that their product certification for the more efficient Executive Order 13777, titled has capabilities conformant with those certification of their health IT when ‘‘Enforcing the Regulatory Reform specified in the associated certification updating from the 2011 Edition to the 7 Agenda’’ (February 24, 2017). Executive criterion/criteria). This deregulatory 2014 Edition and from the 2014 Edition Order 13777 provides further direction action reduced burden and costs to the 2015 Edition. on implementing regulatory reform by program-wide, while still maintaining ONC introduced further means to the Program’s high level of integrity and reduce regulatory burden, increase identifying a process by which agencies must review and evaluate existing assurances. Health IT developers now regulatory flexibility, and promote have reduced preparation and testing innovation in the 2014 Edition Release regulations and make recommendations for repeal or simplification. costs for testing to these criteria. 2 final rule (79 FR 54430). The 2014 Specifically, the cost savings for health Edition Release 2 final rule established In order to implement these regulatory reform initiatives and IT developers have been estimated a set of optional 2014 Edition between $8.34 and $9.26 million. ONC– certification criteria that provided policies, over the past year ONC reviewed and evaluated existing ATLs also benefit by having more time flexibility and alternative certification and resources to focus on tool-based pathways for health IT developers and regulations. During our review, we sought to identify ways to further providers based on their specific 5 https://www.healthit.gov/sites/default/files/ circumstances. The 2014 Edition reduce administrative burden, to relieduponsoftwareguidance.pdf. Release 2 final rule also simplified the implement deregulatory actions through 6 https://www.healthit.gov/buzz-blog/healthit- Program by discontinuing the use of the certification/certification-program-updates-support- 4 https://www.healthit.gov/test-method/ efficiency-reduce-burden/. ‘‘Complete EHR’’ certification concept automated-numerator-recording and https:// 7 https://www.healthit.gov/sites/default/files/ beginning with the 2015 Edition (79 FR www.healthit.gov/test-method/automated-measure- policy/selfdeclarationapproachprogramguidance17- 54443). calculation. 04.pdf.

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00011 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7434 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

testing (for interoperability-oriented products per year. We also propose to providers would lead to the estimated criteria) and being responsive to any remove the requirements in costs savings in this proposed rule retesting requirements that may arise § 170.556(c)(5) regarding the exclusion through improved interoperability from ONC–ACB surveillance activities. and exhaustion of selected locations for supporting the access, exchange, and Furthermore, providers and users of randomized surveillance. Additionally, use of electronic health information. certified health IT do not lose we propose to remove the requirements Removal of the 2014 Edition would confidence in the Program because this in § 170.556(c)(6) regarding the eliminate inconsistencies and costs burden reduction effort in no way alters consecutive selection of certified health caused by health IT certification and the expectations of conformance and IT for randomized surveillance. Without implementation of two different responsibilities of Program participants. these regulatory requirements, ONC– editions with different functionalities Health IT developers are still required to ACBs would still be required to perform and versions of standards. Patient care meet certification criteria requirements reactive surveillance, and would be could improve through the reduced risk and maintain their products’ permitted to conduct randomized of error that comes with the health care conformance to the full scope of the surveillance of their own accord, using system’s consistent implementation and associated criteria, including when the methodology identified by ONC use of health IT certified to the 2015 implemented in the field and in with respect to scope (§ 170.556(c)(1)), Edition. Innovation could also improve production use. Similarly, ONC and selection method (§ 170.556(c)(3)), and with health IT developers (including ONC–ACBs continue to conduct the number and types of locations for third-party software developers) surveillance activities and respond to in-the-field surveillance developing to only one set of newer end-user complaints. (§ 170.556(c)(4)). standards and implementation Stakeholders have expressed concern specifications, which would be more B. Proposed Deregulatory Actions that the benefits of in-the-field, predictable and less costly. We propose six deregulatory actions randomized surveillance may not Removal of the 2014 Edition would below. We welcome comments on these outweigh the time commitment required also reduce regulatory burden by no potential deregulatory actions and any by providers, particularly if no non- longer requiring the maintenance and other potential deregulatory actions we conformities are found. In general, support of the 2014 Edition. should consider. We also refer readers providers have expressed that reactive Maintaining compliance with only the to section XIV (Regulatory Impact surveillance (e.g., surveillance based on 2015 Edition would reduce the cost and Analysis) of this proposed rule for a user complaints) is a more logical and burden for health IT developers, ONC– discussion of the estimated cost savings economical approach to surveillance. ACBs, and ONC–ATLs because they from these proposed deregulatory The removal of randomized surveillance would no longer have to support two actions. requirements would also give ONC– increasingly distinct sets of ACBs the flexibility and time to focus requirements as is the case now with 1. Removal of Randomized Surveillance on other priorities, such as the certification to both the 2014 and 2015 Requirements certification of health IT to the 2015 Editions. More specifically, health IT ONC–ACBs are required to conduct Edition. Therefore, as discussed above, developers would not have to support surveillance of certified health IT under we propose to eliminate certain two maintenance infrastructures and the Program to ensure that health IT regulatory randomized surveillance updating for their customers; nor would continues to conform and function as requirements. ONC–ATLs and ONC–ACBs have to required by the full scope of the 2. Removal of the 2014 Edition From the support testing, certification, and certification requirements. Surveillance Code of Federal Regulations surveillance for two separate editions of is categorized as either reactive certified health IT. surveillance (for example, complaint- We propose to remove the 2014 As referenced by the HHS Office of based surveillance) or randomized Edition from the Code of Federal Inspector General (OIG) and Centers for surveillance, which, by regulation, Regulations (CFR). The 2014 Edition Medicare & Medicaid Services (CMS) in requires ONC–ACBs to proactively was the result of rulemaking completed their rulemakings regarding donations surveil 2% of the certificates they issue in 2012 and includes standards and of EHR items and services, we annually. On September 21, 2017, we functionality that are now significantly committed to retiring certification exercised enforcement discretion with outmoded. Removal of the 2014 Edition criteria editions that are no longer would make the 2015 Edition the respect to the implementation of applicable.9 We first did this with the baseline for health IT certification. The randomized surveillance by ONC– removal of the 2011 Edition (79 FR 2015 Edition, including the additional ACBs.8 Consistent with this exercise of 54447). Accordingly, our proposal to certification criteria, standards, and enforcement discretion, we now remove the outdated 2014 Edition for requirements proposed in this proposed propose to eliminate certain regulatory the reasons discussed above would also rule, better enables interoperability and randomized surveillance requirements. streamline Program compliance the access, exchange, and use of We propose to revise § 170.556(c) by requirements and ensure there is no electronic health information. Adoption changing the requirement that ONC– regulatory confusion between ONC’s and implementation of the 2015 Edition, ACBs must conduct in-the-field, rules and other HHS rules. including the proposals in this proposed randomized surveillance to specify that To implement the removal of the 2014 rule, would also lead to the benefits ONC–ACBs may conduct in-the- field, Edition from the CFR, we propose to outlined in the 2015 Edition final rule randomized surveillance. We further remove the 2014 Edition certification (80 FR 62602–62603, 62605–62606, propose to remove § 170.556(c)(2), 62740) and in this proposed rule (see, which specifies that ONC–ACBs must 9 CMS final rule ‘‘Medicare Program; Physicians’ for example, the Executive Summary conduct randomized surveillance for a Referrals to Health Care Entities With Which They and the ‘‘Assurances,’’ ‘‘API’’, and ‘‘Real Have Financial Relationships: Exception for Certain minimum of 2% of certified health IT World Testing’’ Conditions and Electronic Health Records Arrangements’’ (78 FR 78751).OIG final rule ‘‘Medicare and State Health 8 https://www.healthit.gov/sites/default/files/ Maintenance of Certification sections). Care Programs: Fraud and Abuse; Electronic Health ONC_Enforcement_Discretion_Randomized_ Equally important, adoption and Records Safe Harbor Under the Anti-Kickback Surveillance_8-30-17.pdf. implementation of the 2015 Edition by Statute’’ (78 FR 79202).

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00012 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7435

criteria (§ 170.314) and related CEHRT definition starting with the CY solely to the role and removal of the standards, terms, and requirements from 2019 program year. ONC–AA, we propose its removal and the CFR. In regard to terms, we propose Therefore, we propose that the § 170.575, which codified the final rule to retire the 2014 Edition-related effective date of removal of the 2014 in the CFR. definitions found in § 170.102, Edition certification criteria and related These proposed deregulatory actions including the ‘‘2014 Edition Base EHR,’’ standards, terms, and requirements from would also provide an additional ‘‘2014 Edition EHR certification the CFR would be the effective date of benefit for ONC–ACBs. ONC–ACBs criteria,’’ and ‘‘Complete EHR, 2014 a subsequent final rule for this proposed would be able to obtain and maintain Edition.’’ As explained in the 2015 rule, which we expect will be issued in accreditation to ISO/IEC 17065, with an Edition final rule (80 FR 62719), the the latter half of 2019. We note that we appropriate scope, from any ability to maintain Complete EHR will continue to support Medicare and accreditation body that is a signatory to certification is only permitted with Medicaid program attestations by the Multilateral Recognition health IT certified to the 2014 Edition maintaining an archive on the CHPL Arrangement (MLA) with the certification criteria. Because this allowing the public to access historic International Accreditation Forum concept was discontinued for the 2015 information on a product certified to the (IAF). Accordingly, we propose to revise Edition, we propose to remove § 170.545 2014 Edition. the application process for ONC–ACB status in § 170.520(a)(3) to require and any references to Complete EHR 3. Removal of the ONC-Approved documentation that confirms that the from the regulation text in conjunction Accreditor From the Program with the removal of the 2014 Edition. applicant has been accredited to ISO/ We also propose to remove references to We propose to remove the ONC- IEC 17065, with an appropriate scope, the 2014 Edition from the Common Approved Accreditor (ONC–AA) from by any accreditation body that is a the Program. The ONC–AA’s role is to Clinical Data Set (CCDS) definition. signatory to the Multilateral Recognition accredit certification bodies for the However, as discussed later in section Arrangement (MLA) with the Program and to oversee the ONC–ACBs. IV.B.1 (‘‘United States Core Data for International Accreditation Forum However, years of experience and Interoperability’’) of this proposed rule, (IAF), in place of the ONC–AA changes with the Program have led ONC we propose to remove the CCDS accreditation documentation to conclude that, in many respects, the definition from the CFR and effectively requirements. Similarly, instead of role of the ONC–AA to oversee ONC– replace it with a new government- requiring the ONC–AA to evaluate the ACBs is now duplicative of ONC’s unique standard, the United States Core conformance of ONC–ACBs to ISO/IEC oversight. More specifically, ONC’s Data for Interoperability (USCDI), 17065, we propose to revise § 170.523(a) experience with administering the to simply require ONC–ACBs to proposing to adopt Version 1 (v1) in Principles of Proper Conduct for ONC– § 170.213. The new standard would be maintain accreditation in good standing ACBs as well as issuing necessary to ISO/IEC 17065 for the Program. This applicable to certain 2015 Edition regulatory changes (e.g., ONC–ACB certification criteria that currently means that ONC–ACBs would need to surveillance and reporting requirements continue to comply with ISO/IEC 17065 reference the CCDS, subject to any of in the 2015 Edition final rule) has these criteria being removed through and requirements specific to the ONC demonstrated that ONC on its own has Health IT Certification Program scheme. this rulemaking). the capacity to provide the appropriate We propose to remove the standards oversight of ONC–ACBs. Therefore, we 4. Removal of Certain 2015 Edition and implementation specifications believe removal of the ONC–AA would Certification Criteria and Standards found in §§ 170.200, 170.202, 170.204, reduce the Program’s administrative We have reviewed and analyzed the 170.205, 170.207, 170.210, and 170.299 complexity and burden. 2015 Edition to determine whether there that are only referenced in the 2014 To implement this proposed are certification criteria we could Edition certification criteria. Adopted deregulatory action, we propose to remove. We have identified both criteria standards that are also referenced in the remove the definition for ‘‘ONC- and standards for removal as proposed 2015 Edition would remain. We propose Approved Accreditor or ONC–AA’’ below. We believe the removal of these to remove requirements in § 170.550(f) found in § 170.502. We also propose to criteria and standards will reduce and any other requirements in subpart remove processes related to ONC–AAs burden and costs for health IT E, §§ 170.500 through 170.599, which found in §§ 170.501(c), 170.503, and developers and health care providers by are specific to the 2014 Edition and do 170.504 regarding requests for ONC–AA eliminating the need to: Design and not apply to the 2015 Edition. status, ONC–AA ongoing meet specific certification In order to avoid regulatory conflicts, responsibilities, and reconsideration for functionalities; prepare, test, and certify we are taking into consideration the requests for ONC–AA status. Regarding health IT in certain instances; adhere to final rule released by CMS on November correspondence and communication associated reporting and disclosure 2, 2017, which makes payment and with ONC, we propose to remove requirements; maintain and update policy changes to the second year of the specific references to the ‘‘ONC–AA’’ certifications for certified Quality Payment Program (QPP). The and ‘‘accreditation organizations functionalities; and participate in CMS’s final rule, titled ‘‘Medicare requesting ONC–AA status’’ by revising surveillance of certified health IT. To Program; CY 2018 Updates to the § 170.505. We also propose to remove these points, if our proposals are Quality Payment Program: Extreme and the final rule titled ‘‘Permanent finalized in a subsequent final rule, we Uncontrollable Circumstance Policy for Certification Program for Health would expect any already issued 2015 the Transition Year’’ (82 FR 53568), Information Technology; Revisions to Edition certificates to be updated to permits eligible clinicians to use health ONC-Approved Accreditor Processes’’ reflect the removal of applicable 2015 IT certified to either the 2014 or 2015 (76 FR 72636) which established a Edition certification criteria. We Edition certification criteria, or a process for addressing instances where welcome comment on the proposed combination of the two for the CY 2018 the ONC–AA engages in improper removal of the identified criteria and performance period. The QPP final rule conduct or does not perform its standards below and any other 2015 also states that the 2015 Edition will be responsibilities under the Program. Edition criteria and standards we the sole edition permitted to meet the Because this prior final rule relates should consider for removal.

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00013 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7436 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

a. 2015 Edition Base EHR Definition ii. Medication List objective and measure for recording this Criteria We propose to remove the 2015 information. The criterion does not Edition ‘‘medication list’’ certification require use of a vocabulary standard to We propose the removal of certain record medication allergies. This 2015 certification criteria from the 2015 criterion (§ 170.315(a)(7)). The functionality in this criterion was first Edition ‘‘medication allergy list’’ Edition that are included in the 2015 adopted as a 2011 Edition certification criterion remains functionally the same Edition Base EHR definition. The criterion to support the associated as the 2011 Edition and 2014 Edition removal of these criteria would support meaningful use Stage 1 objective and ‘‘medication allergy list’’ criteria. We propose to remove this criterion burden and cost reductions for health IT measure for recording medication list for multiple reasons. First, this criterion developers and health care providers as information. The criterion does not no longer supports a ‘‘recording’’ noted above. require use of a vocabulary standard to objective and measure of the CMS i. Problem List record medications. This 2015 Edition Promoting Interoperability Programs as ‘‘medication list’’ criterion remains such objective and measure no longer We propose to remove the 2015 functionally the same as the 2011 exist. Second, the functionality is Edition ‘‘problem list’’ certification Edition and 2014 Edition ‘‘medication sufficiently widespread among health criterion (§ 170.315(a)(6)). The list’’ criteria. care providers since it has been part of functionality in this criterion was first We propose to remove this criterion certification and the Certified EHR adopted as a 2011 Edition certification for multiple reasons. First, this criterion Technology definition since the 2011 criterion to support the associated no longer supports a ‘‘recording’’ Edition and has not substantively meaningful use Stage 1 objective and objective and measure of the CMS changed with the 2015 Edition. Third, measure for recording problem list Promoting Interoperability Programs as we do not believe this functionality information. In this regard, SNOMED such objective and measure no longer would be removed from EHR systems CT® was adopted specifically to support exist. Second, the functionality is because of our proposal to remove it the measure. This 2015 Edition sufficiently widespread among health from the 2015 Edition Base EHR ‘‘problem list’’ criterion remains care providers since it has been part of definition. This functionality is relatively functionally the same as the certification and the Certified EHR essential to clinical care and would be 2011 Edition and has exactly the same Technology definition since the 2011 in EHR systems absent certification, functionally as the 2014 Edition Edition and has not substantively particularly considering the limited changed with the 2015 Edition. Third, ‘‘problem list’’ criterion. certification requirements. Fourth, this we do not believe this functionality functionality does not directly support We propose to remove this criterion would be removed from EHR systems interoperability as the capabilities are for multiple reasons. First, this criterion because of our proposal to remove it focused on internally recording EHI. In no longer supports the ‘‘recording’’ from the 2015 Edition Base EHR this regard, this criterion does not even objective and measure of the CMS definition. This functionality is require representation of medication Promoting Interoperability Programs as essential to clinical care and would be allergies in standardized nomenclature. such objective and measure no longer in EHR systems absent certification, Fifth, medication allergies are included exist. Second, the functionality is particularly considering the limited in the USCDI and must be represented sufficiently widespread among health certification requirements. Fourth, this in RxNorm as part of the USCDI. This care providers since it has been part of functionality does not directly support approach better supports certification and the Certified EHR interoperability as the capabilities are interoperability through medication Technology definition since the 2011 focused on internally recording EHI. In allergy information being availability for Edition and has not substantively this regard, this criterion does not even access and exchange in a structured changed with the 2015 Edition. Third, require representation of medications in format. Accordingly, we propose to we do not believe this functionality standardized nomenclature. Fifth, remove the ‘‘medication allergy list’’ would be removed from health IT medications are included in the USCDI criterion from the 2015 Edition, systems because of our proposal to and must be represented in RxNorm as including the 2015 Edition Base EHR remove it from the 2015 Edition Base part of the USCDI. This approach better definition. We note that once removed EHR definition. This functionality is supports interoperability through from the 2015 Edition, the criterion essential to clinical care and would be medication information being would also no longer be included in the in EHR systems absent certification, availability for access and exchange in 2015 Edition ‘‘safety- enhanced design’’ particularly considering the limited a structured format. Accordingly, we criterion. propose to remove the ‘‘medications certification requirements. Fourth, this iv. Smoking Status functionality does not directly support list’’ criterion from the 2015 Edition, including the 2015 Edition Base EHR We propose to remove the 2015 interoperability as the capabilities are definition. We note that once removed Edition ‘‘smoking status’’ criterion focused on internally recording EHI. In from the 2015 Edition, the criterion (§ 170.315(a)(11)), which would include this regard, representing problems with ® would also no longer be included in the removing it from the 2015 Edition Base SNOMED CT is part of the USCDI and, 2015 Edition ‘‘safety-enhanced design’’ EHR definition. We previously adopted thus, better supports interoperability criterion. a 2015 Edition ‘‘smoking status’’ through its availability for access and certification criterion that does not exchange. Accordingly, we propose to iii. Medication Allergy List reference a standard. However, the remove the ‘‘problem list’’ criterion We propose to remove the 2015 CCDS definition requires smoking status from the 2015 Edition, including the Edition ‘‘medication allergy list’’ to be coded in accordance with 2015 Edition Base EHR definition. We certification criterion (§ 170.315(a)(8)). SNOMED CT®. While we continue to note that once removed from the 2015 The functionality in this criterion was believe that the capture of a patient’s Edition, the criterion would also no first adopted as a 2011 Edition smoking status has significant value in longer be included in the 2015 Edition certification criterion to support the assisting providers with addressing the ‘‘safety-enhanced design’’ criterion. associated meaningful use Stage 1 number one cause of preventable death

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00014 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7437

and disease in the United States, we no removal of this criterion could reduce proposed rule, there appears to be little longer believe that a criterion that health IT developer and health care market demand for certification to them. simply ensures this functionality exists provider burden. This outcome is likely attributable to the in health IT presented for certification is fact mentioned above regarding their c. Patient-Specific Education Resources the right focus. As with other 2014 relationship to the 2015 Edition Edition functionality, we believe this We propose to remove the 2015 ‘‘transition of care’’ criterion, that they functionality is fairly ubiquitous now Edition ‘‘patient-specific education are not included in the 2015 Edition with the widespread adoption of health resources’’ certification criterion Base EHR definition, and that no HHS IT certified to the 2014 Edition. Further, (§ 170.315(a)(13)). ONC continues to program specifically requires the use of we continue to believe that, for the support patient and provider health IT certified to the criteria. purposes of certification, having interaction, and the identification and Therefore, we propose to remove these smoking status available for access and dissemination of patient-specific certification criteria from the 2015 exchange via the USCDI is ultimately educational materials to promote Edition. the key requirement for supporting positive health outcomes. However, we e. Secure Messaging interoperability. no longer believe that certification focused on a health IT’s ability to We propose to remove the 2015 Removal of Specific USCDI Smoking identifying the existence of patient- Edition ‘‘secure messaging’’ criterion Status Code Sets specific education materials encourages (§ 170.315(e)(2)). ONC strongly supports As mentioned above, we believe the advancement of this functionality or patient and provider communication, as having smoking status available for interoperability. First, this criterion well as protecting the privacy and USCDI purposes is fundamentally would no longer be associated with an security of patient information. important for supporting objective or measure under the However, we no longer believe that interoperability. We propose, however, Promoting Interoperability Programs separate certification focused on a to remove the requirement to code based on proposals and determinations health IT’s ability to send and receive smoking status according to the adopted in recent CMS rulemakings (83 FR secure messages between health care eight smoking status SNOMED CT® 35928; 83 FR 41664). Second, based on providers and patients is necessary. codes as referenced in the value set in the number of health IT products that First, this criterion would no longer be § 170.207(h). These eight codes reflect have been certified for this functionality associated with an objective or measure an attempt to capture smoking status in as part of 2014 Edition certification and under the Promoting Interoperability a consistent manner. Stakeholder already for 2015 Edition certification, Programs based on proposals and feedback has, however, indicated that we believe that health IT’s ability to determinations in recent CMS these eight codes do not appropriately identify appropriate patient education rulemakings (83 FR 41664; 83 FR and accurately capture all applicable materials is widespread now among 35929). Second, there are multiple other patients’ smoking statuses. Accordingly, health IT developers and their 2015 Edition certification criteria that we propose to no longer require use of customers (e.g., health care providers). support patient engagement, such as the only the specific eight SNOMED CT® Third, we have recently seen innovative 2015 Edition ‘‘view, download, and codes for representing smoking status advancements in this field, including transmit to 3rd party,’’ ‘‘API,’’ and (and remove the standard from the use of automation and algorithms to ‘‘patient health information capture’’ § 170.207). Rather, to continue to provide appropriate educations certification criteria. Third, we have promote interoperability while also materials to patients in a timely manner. seen developers integrate this granting providers with flexibility to These advancements help limit clinical functionality as part of other patient better support clinical care, we propose workflow interruptions and demonstrate engagement features, such as patient that health IT would simply be required the use and promise of health IT to portals. With these considerations in to be capable of representing smoking create efficiencies and improve patient mind and the lack of a negative impact ® status in SNOMED CT when such care. As such, removal of this criterion on health IT interoperability, we believe information is exchanged as part of the would prevent certification from that the removal of this criterion will USCDI. creating an unnecessary burden for help reduce burden and costs, while developers and providers and an b. Drug-Formulary and Preferred Drug also spurring further innovations in impediment to innovation. Lists patient engagement. We propose to remove the 2015 d. CCDS Summary Record—Create; and 5. Removal of Certain ONC Health IT Edition ‘‘drug formulary and preferred CCDS Summary Record—Receive Certification Program Requirements drug list checks’’ criterion in We assessed the number of products We propose to remove certain § 170.315(a)(10). We adopted a 2015 certified to the 2015 Edition ‘‘Common mandatory disclosure requirements and Edition ‘‘drug-formulary and preferred Clinical Data Set summary record— a related attestation requirement under drug list checks’’ criterion that separates create’’ (§ 170.315(b)(4)) and ‘‘Common the Program. We believe removal of drug formulary and preferred drug list Clinical Data Set summary record— these requirements will reduce costs functionality, but does not require any receive’’ (§ 170.315(b)(5)) criteria that and burden for Program stakeholders, standards or functionality beyond that have not also been certified to the 2015 particularly health IT developers and included in the 2014 Edition ‘‘drug- Edition ‘‘transitions of care’’ criterion ONC–ACBs. We welcome comment on formulary checks’’ criterion. First, we (§ 170.315(b)(1)). We did this because the proposed removal of these believe this functionality is fairly the 2015 Edition ‘‘CCDS summary requirements and any other certification ubiquitous now with the widespread record’’ criteria include the same or Program requirements we should adoption of health IT certified to the functionality as the 2015 Edition consider for removal. 2014 Edition, which included this ‘‘transitions of care’’ criterion, except for general functionality. Second, without Direct-related transport functionality. a. Limitations Disclosures standards, this criterion does not Based on our findings of only two We propose to remove support or facilitate the critical goal of unique products certified to these § 170.523(k)(1)(iii)(B), which requires health IT interoperability. Therefore, criteria at the time of the drafting of this ONC–ACBs to ensure that certified

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00015 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7438 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

health IT includes a detailed description Certification and the statutory provision promotes innovation, protects patient of all known material information that it implements. Based on these safety, and avoids regulatory concerning limitations that a user may Conditions of Certification, we believe duplication. Public comments, received encounter in the course of that disclosures of limitations by health prior to the report and after,12 implementing and using the certified IT developers would be unlikely and recommended that health IT health IT, whether to meet ‘‘meaningful unnecessary given their prohibition. developers/manufacturers apply a single process that satisfies the requirements of use’’ objectives and measures or to b. Transparency and Mandatory all agencies and that existing safety and achieve any other use within the scope Disclosures Requirements of the health IT’s certification. We also quality-related processes, systems, and propose to remove § 170.523(k)(1)(iv)(B) We propose to remove the Principle of standards should be leveraged for and (C), which state that the types of Proper Conduct (PoPC) in patient safety in health IT. On July 27, information required to be disclosed § 170.523(k)(2), which requires a health 2017, FDA announced a voluntary include, but are not limited to: (B) IT developer to submit an attestation Software Precertification (Pre-Cert) Pilot Limitations, whether by contract or that it will disclose all of the Program as part of a broader Digital otherwise, on the use of any capability information in its mandatory Health Innovation Action Plan.13 It was to which technology is certified for any disclosures per § 170.523(k)(1) to developed in order to create a tailored purpose within the scope of the specified parties (e.g., potential approach toward recognizing the unique technology’s certification; or in customers or anyone inquiring about a characteristics of digital technology by connection with any data generated in product quote or description of looking first at the firm, rather than the course of using any capability to services). We propose that this primarily at each product of the firm, as which health IT is certified; (C) provision is no longer necessary and is currently done for traditional medical Limitations, including but not limited to that its removal is appropriate to further products. The FDA plans to explore technical or practical limitations of reduce administrative burden for health whether and how pre-certified technology or its capabilities, that could IT developers and ONC–ACBs. First, our companies that have demonstrated a prevent or impair the successful experience with developer attestations culture of quality, patient safety, and implementation, configuration, to this requirement is that over 90% of organizational excellence could bring customization, maintenance, support, or developers with certified health IT have certain types of digital health products use of any capabilities to which attested that they will provide to market either without FDA premarket ‘‘transparency information.’’ Second, technology is certified; or that could review or with a more streamlined FDA the information that developers would prevent or limit the use, exchange, or premarket review. be asked to attest to, whether our portability of any data generated in the proposal above to remove certain a. FDA Software Pre-Certification Pilot course of using any capability to which disclosure requirements is finalized or Program technology is certified. not, is now readily available on health ONC believes that health IT These disclosure requirements IT developers’ websites as the developers that hold precertification regarding certified health IT limitations mandatory disclosure requirements under the FDA Digital Health Software are superseded by the Cures Act were implemented almost three years Precertification Program (FDA Software information blocking provision and ago. Therefore, we believe removal of Precertification Program) when they Conditions of Certification, which we this requirement is appropriate. present health IT for certification under are implementing with this proposed the Program could qualify for, and 6. Recognition of Food and Drug rule. In particular, section benefit from, further efficiencies under Administration Processes 3001(c)(5)(D)(ii) of the Cures Act the Program. Title IV of the Cures Act requires that a health IT developer, as a Section 618 of the Food and Drug provides ONC with authority under the Condition of Certification under the Administration Safety and Innovation Program to oversee health IT developers Program, provide assurances to the Act (FDASIA), Public Law 112–144, through Conditions and Maintenance of Secretary that, unless for legitimate required that the Food and Drug Certification requirements (see section purposes specified by the Secretary, the Administration (FDA), in consultation VII Conditions and Maintenance of developer will not take any action that with ONC and the Federal Certification of this proposed rule). constitutes information blocking as Communications Commission (FCC) With this new authority and our defined in section 3022(a) of the PHSA, (collectively referred to as ‘‘the authority over health IT developers’ or any other action that may inhibit the Agencies’’ 10 for this proposal), develop health IT certified under the Program, appropriate exchange, access, and use of a report that contains a proposed we propose to establish processes that electronic health information. These strategy and recommendations on an would provide health IT developers that assurances specifically focus on appropriate, risk-based regulatory can document holding precertification preventing information blocking and framework pertaining to health IT, under the FDA Software Precertification promoting appropriate exchange, access, including mobile medical applications, Program with exemptions to the ONC and use of electronic health that promotes innovation, protects Health IT Certification Program’s information. We further propose adding patient safety, and avoids regulatory requirements for testing and as a complementary Condition of duplication. The FDASIA Health IT certification of its health IT to the 2015 Certification that developers would be Report of April 2014 11 contains a prohibited from taking any action that proposed strategy and recommendations 12 https://www.federalregister.gov/documents/ could interfere with a user’s ability to on an appropriate, risk-based regulatory 2013/05/30/2013-12817/food-and-drug- framework pertaining to health IT that administration-safety-and-innovation-act-fdasia- access or use certified capabilities for request-for-comments-on-the; https://blogs.fda.gov/ any purpose within the scope of the fdavoice/index.php/2014/04/fda-seeks-comment- technology’s certification. Such actions 10 ONC is not an agency, but an Office, within the on-proposed-health-it-strategy-that-aims-to- may inhibit the appropriate access, Department of Health and Human Services. promote-innovation/; and https://www.regulations 11 exchange, or use of electronic health https://www.fda.gov/downloads/AboutFDA/ .gov/document?D=FDA-2014-N-0339-0001. CentersOffices/OfficeofMedical 13 https://www.fda.gov/MedicalDevices/ information and are therefore contrary ProductsandTobacco/CDRH/CDRHReports/ DigitalHealth/DigitalHealthPreCertProgram/ to this proposed Condition of UCM391521.pdf. Default.htm.

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00016 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7439

Edition ‘‘quality management systems’’ concerns. Accordingly, we welcome IV. Updates to the 2015 Edition criterion (§ 170.315(g)(4)) and the 2015 comments on these and other aspects of Certification Criteria Edition ‘‘safety-enhanced design’’ our proposed ‘‘recognition’’ approach, This rule proposes to update the 2015 criterion (§ 170.315(g)(3)), as these including the 2015 Edition certification Edition by revising and adding criteria are applicable to the health IT criteria that should be eligible for certification criteria that would developer’s health IT presented for ‘‘recognition.’’ establish the capabilities and related certification. We also believe that such b. Development of Similar Independent standards and implementation a ‘‘recognition’’ could, depending on the Program Processes—Request for specifications for the certification of final framework of the FDA Software Information health IT. The updates to the 2015 Precertification Program (e.g., the key Edition would enhance interoperability performance indicators used to Recognition of the FDA Software Pre- and improve the accessibility of patient demonstrate performance and outcomes Certification Program for purposes of records consistent with section 4006(a) of excellence), be applicable to the our Program, as noted above, may of the Cures Act. functionally-based 2015 Edition eventually be determined to be ‘‘clinical’’ certification criteria infeasible or insufficient to meet our A. Standards and Implementation (§ 170.315(a)). More specifically, this goals of reducing burden and promoting Specifications could address the ‘‘computerized innovation. With this in mind, we 1. National Technology Transfer and provider order entry (CPOE)’’ request comment on whether ONC Advancement Act (§ 170.315(a)(1), (2), and (3)), ‘‘drug- should establish new regulatory drug, drug-allergy interaction checks for The National Technology Transfer processes tailored towards recognizing and Advancement Act (NTTAA) of 1995 CPOE’’ (§ 170.315(a)(4)), ‘‘clinical the unique characteristics of health IT decision support’’ (§ 170.315(a)(9)), and (15 U.S.C. 3701 et seq.) and the Office (e.g., EHR software) by looking first at of Management and Budget (OMB) ‘‘implantable device list’’ the health IT developer, rather than Circular A–119 14 require the use of, (§ 170.315(a)(14)) certification criteria. primarily at the health IT presented for wherever practical, technical standards Such ‘‘recognition’’ could also be certification, as is currently done under that are developed or adopted by appropriate to address any or all of the the Program. For example, ONC could voluntary consensus standards bodies to following functionally-based 2015 possibly establish Conditions and carry out policy objectives or activities, Edition criteria in the event their Maintenance of Certification with certain exceptions. The NTTAA proposed removal is not finalized: requirements, through rulemaking, that and OMB Circular A–119 provide ‘‘problem list’’ (§ 170.315(a)(6)), facilitate the deeming of all of a health exceptions to electing only standards ‘‘medication list’’ (§ 170.315(a)(7)), IT developer’s health IT as ‘‘certified’’ developed or adopted by voluntary ‘‘medication allergy list’’ under the Program for certification consensus standards bodies, namely (§ 170.315(a)(8)), ‘‘drug-formulary and criteria identified by ONC as solely when doing so would be inconsistent preferred drug list checks’’ ‘‘functionally-based’’ criteria (i.e., not with applicable law or otherwise (§ 170.315(a)(10)),’’ and ‘‘smoking essential to interoperability, such as the impractical. Agencies have the status’’ (§ 170.315(a)(11)). ‘‘CPOE’’ criteria) or possibly broader in discretion to decline the use of existing Our proposed ‘‘recognition’’ would scope. This approach could rely on, but voluntary consensus standards if align with both Executive Orders 13563 not be limited to, one or a combination determined that such standards are and 13771 regarding deregulatory, less of the following: (1) Certain inconsistent with applicable law or burdensome, and more effective demonstrated health IT developer otherwise impractical, and instead use a initiatives. It would also serve as a processes or health IT functionality; (2) government-unique standard or other regulatory relief for those health IT prior successful certification of a health standard. In addition to the developers qualifying as small IT developer’s health IT under the consideration of voluntary consensus businesses under the Regulatory Program; (3) results of real world testing standards, the OMB Circular A–119 Flexibility Act (see section XIV.C.3 for interoperability as required by the recognizes the contributions of Regulatory Flexibility Act of this Cures Act and the proposed standardization activities that take place proposed rule). Furthermore, it would implementing regulatory Condition of outside of the voluntary consensus closely align with FDASIA’s instruction Certification (see section VII.B.5 of this standards process. Therefore, in to promote innovation, protect patient proposed rule); and/or (4) the results of instances where use of voluntary safety, and avoid regulatory duplication. the EHR Reporting Program once consensus standards would be However, despite these proffered implemented (see section VII.B.7 of this inconsistent with applicable law or benefits, there may be reasons not to proposed rule). No matter the specifics, otherwise impracticable, other adopt such a ‘‘recognition’’ approach. we are most interested in whether standards should be considered that For example, stakeholders may not stakeholders believe this is an approach meet the agency’s regulatory, agree that the FDA Software we should pursue in conjunction with, procurement or program needs, deliver Precertification Program (and/or or in lieu of, the proposed approach of favorable technical and economic subsequent finalized program) recognizing the FDA Software Pre- outcomes, and are widely utilized in the sufficiently aligns with our Program. Certification Pilot Program. We also marketplace. In this proposed rule, we Developers and providers may have welcome more specific comments on use voluntary consensus standards varying and divergent views about the the health IT developer criteria for such except for: benefits and detriments of such an an approach and what the Conditions approach. Further, while we believe that and/or Maintenance of Certification • The standard we propose to adopt in we could properly operationalize such requirements should be to support such § 170.213. We propose to remove the an approach by ensuring certifications an approach within the framework of Common Clinical Data Set (CCDS) definition and effectively replace it with a government indicate which criteria have been the proposed Conditions and Maintenance of Certification ‘‘deemed certified’’ by ONC (but still 14 https://www.whitehouse.gov/sites/ subject to ONC–ACB surveillance), requirements discussed in section VII of whitehouse.gov/files/omb/circulars/A119/revised_ stakeholders may have other operational this proposed rule. circular_a-119_as_of_1_22.pdf.

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00017 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7440 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

unique standard, the United States Core Data specifications) that agencies propose to several certification criteria (77 FR for Interoperability (USCDI), Version 1(v1); incorporate by reference in the Code of 54170). • The standard we propose to adopt in Federal Regulations (79 FR 66267; 1 The 2015 Edition final rule modified § 170.215(a)(2). We propose the government CFR 51.5(a)). To comply with these the Program to make it open and unique API Resource Collection in Health accessible to more types of health IT, (ARCH) Version 1 implementation requirements, in section XI specification; (‘‘Incorporation by Reference’’) of this and health IT that supports various care • The standards we propose to adopt in preamble, we provide summaries of, and practice settings beyond those § 170.215(a)(3) through (5) for application and uniform resource locators (URLs) to, included in the Promoting programming interfaces (APIs). These market the standards and implementation Interoperability Programs (80 FR 62604). driven consortia standards have been specifications we propose to adopt and In comparison to the previous editions, developed through a streamlined process that subsequently incorporate by reference the 2015 Edition focused on identifying does not meet the full definition of voluntary in the Code of Federal Regulations. To health IT components necessary to consensus standards development but still note, we also provide relevant establish an interoperable nationwide includes representation from those interested health information infrastructure, in the use cases supported by the standards information about these standards and (e.g., health IT developers and health care implementation specifications fostering innovation and open new providers). In the absence of available throughout the relevant sections of the market opportunities, and allowing for voluntary consensus standards that would proposed rule. more health care provider and patient meet our needs, these standards deliver choices in electronic health information favorable technical and economic outcomes, B. Revised and New 2015 Edition access and exchange. In order to align particularly improved interoperability. Criteria with this approach, we revised the Further, some of these standards may In order to capture and share patient concept of the ‘‘Common MU Data Set’’ eventually proceed through a standards data efficiently, health care providers definition and changed the name to the development organization for approval; and • need health IT that store data in ‘‘Common Clinical Data Set’’ (CCDS) The standards we propose to adopt in structured formats. Structured data § 170.205(h)(3) and (k)(3). We propose to definition. The CCDS definition was replace the current HL7 QRDA standards allows health care providers to easily further revised in the 2015 Edition with government unique standards that more retrieve and transfer patient rulemaking to account for new and effectively support the associated information, and use health IT in ways updated vocabulary and content certification criterion’s use case, which is that can aid patient care. We propose to standards in order to improve and reporting eCQM data to CMS. adopt revised and new 2015 Edition advance interoperability and health certification criteria, including new 2. Compliance With Adopted Standards information exchange (80 FR 62604). It standards, to support these objectives. and Implementation Specifications further expanded accessibility and Some of these criteria and standards are availability of data exchanged by In accordance with Office of the included in the Certified EHR updating the definition of Base Federal Register regulations related to Technology (CEHRT) definition used for Electronic Health Record (EHR) (2015 ‘‘incorporation by reference,’’ 1 CFR participation in HHS Programs, such as Edition Base EHR definition) to include part 51, which we follow when we the Promoting Interoperability Programs enhanced data export, transitions of adopt proposed standards and/or (formerly the EHR Incentive Programs), care, and application programming implementation specifications in any some are required to be met for interface (API) capabilities, all of which subsequent final rule, the entire participation in the ONC Health IT required that at a minimum the CCDS be standard or implementation Certification Program, and some, though available (80 FR 62602–62604). specification document is deemed beneficial, are unassociated with the The regulatory approach to use and published in the Federal Register when CEHRT definition and not required for reference a ‘‘definition’’ to identify incorporated by reference therein with participating in any HHS program, electronic health information, including the approval of the Director of the including the ONC Health IT with associated vocabulary codes, for Federal Register. Once published, Certification Program. access, exchange and use has had its compliance with the standard and drawbacks. While the CCDS definition 1. The United States Core Data for implementation specification includes served its designed purpose, to cut Interoperability Standard (USCDI) the entire document unless we specify down on repetitive text in each of the otherwise. For example, if we adopted The initial focus of the Program was certification criteria in which it is the Argonaut Data Query to support the Medicare and Medicaid referenced, it also began to be Implementation Guide (IG) proposed in EHR Incentive Programs (76 FR 1294) colloquially used for many different this proposed rule (see section now referred to as the Promoting purposes. As the CCDS definition’s VII.B.4.b), health IT certified to Interoperability Programs (and relevance grew outside of its regulatory certification criteria referencing this IG referenced as such hereafter). As such, context it became a symbolic and would need to demonstrate compliance the 2014 Edition certification criteria practical limit to the industry’s with all mandatory elements and mirrored those functions specified by collective interests to go beyond the requirements of the IG. If an element of Promoting Interoperability Programs’ CCDS data for access, exchange, and the IG is optional or permissive in any objectives and measures. In order to use. As we move towards value-based way, it would remain that way for improve efficiency and streamline the care and the inclusion of data classes testing and certification unless we common data within our Program’s that go beyond clinical data, and as part specified otherwise in regulation. In certification criteria, we created a single of ONC’s continued efforts to evaluate such cases, the regulatory text would definition for all the required data the availability of a minimum baseline preempt the permissiveness of the IG. which could be referenced for all of data classes that must be commonly applicable certification criteria. We available for interoperable exchange, we 3. ‘‘Reasonably Available’’ to Interested created the term ‘‘Common MU Data acknowledge the need to change and Parties Set’’ to encompass the common set of improve our regulatory approach to the The Office of the Federal Register has MU data types/elements (and associated CCDS. Therefore, in order to advance established requirements for materials vocabulary standards) for which interoperability by ensuring compliance (e.g., standards and implementation certification would be required across with new data and vocabulary codes

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00018 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7441

sets that support the data, we propose all certification criteria affected by this Process16 published in January 2018 as to remove the ‘‘Common Clinical Data proposed change. We propose to revise well as initial feedback from the Health Set’’ definition and its references from the following CCDS dependent 2015 IT Advisory Committee. The standard as the 2015 Edition and replace it with the Edition certification criteria to we propose to adopt it in § 170.213 also ‘‘United States Core Data for incorporate the USCDI standard: reflects and acknowledges the burden Interoperability’’ (USCDI) standard. The • ‘‘Transitions of care’’ that rapidly expanding the USCDI v1 USCDI standard aims to achieve the (§ 170.315(b)(1)); beyond the CCDS could cause. As a goals set forth in the Cures Act by • ‘‘view, download, and transmit to result, the USCDI v1 is a modest specifying a common set of data classes 3rd party’’ (§ 170.315(e)(1)); expansion of the CCDS, which we for interoperable exchange. believe most health IT developers • ‘‘consolidated CDA creation We propose to adopt the USCDI as a already support, were already working standard as such term is defined in performance’’ (§ 170.315(g)(6)); • toward, or should be capable of § 170.102. In § 170.102, a ‘‘standard’’ is ‘‘transmission to public health updating their health IT to support in a defined as a ‘‘technical, functional, or agencies—electronic case reporting’’ timely manner. The following describes performance-based rule, condition, (§ 170.315(f)(5)); and only the delta between the CCDS and • requirement, or specification that ‘‘application access—all data the USCDI v1. For the overall structure stipulates instructions, fields, codes, request’’ (§ 170.315(g)(9)). and organization of the USCDI standard, data, materials, characteristics, or We note that we did not include the please consult www.healthIT.gov/ actions.’’ The USCDI standard would ‘‘data export’’ criterion (§ 170.315(b)(6)) USCDI. comprise data classes, which may be as we are proposing to remove it and further delineated into groupings of adopt instead the ‘‘EHI export’’ criterion i. Updated Versions of Vocabulary specific data element(s). For example, (§ 170.315(b)(10)). For similar reasons, Standard Code Sets ‘‘patient demographics’’ is a data class we did not include the ‘‘application We propose that the USCDI Version 1 and within that data class there is access—data category request’’ criterion (USCDI v1) include the newest versions ‘‘patient name,’’ which is a data (§ 170.315(g)(8)) because we are of the ‘‘minimum standard’’ code sets element. As noted in section IV.B.1.b, proposing to replace it with the API included in the CCDS available at for the overall structure and certification criterion (§ 170.315(g)(10)), publication of a subsequent final rule. organization of the USCDI, please which derives its data requirements We request comment on this proposal consult www.healthIT.gov/USCDI. from the USCDI. and on whether this could result in any ONC intends to establish and follow We propose, as a Maintenance of interoperability concerns. To note, a predictable, transparent, and Certification requirement for the real criteria such as the 2015 Edition ‘‘family collaborative process to expand the world testing Condition of Certification, health history’’ criterion USCDI, including providing that health IT developers with health IT (§ 170.315(a)(12)), the 2015 Edition stakeholders with the opportunity to certified to the five above-identified ‘‘transmission to immunization comment on the USCDI’s expansion. certification criteria prior to the registries’’ criterion (§ 170.315(f)(1)), Once the Secretary adopts the first effective date of a subsequent final rule and the 2015 Edition ‘‘transmission to version of the USCDI through would have to update such certified public health agencies—syndromic rulemaking, which we propose in this health IT to the proposed revisions. We surveillance’’ criterion (§ 170.315(f)(2)) rulemaking, health IT developers would further propose, as a Maintenance of reference ‘‘minimum standard’’ code be allowed to take advantage of the Certification requirement for the real sets; however, we are considering ‘‘Standards Version Advancement world testing Condition of Certification, changing the certification baseline Process’’ flexibility. The Standards that health IT developers must provide versions of the code set for these criteria Version Advancement Process, the updated certified health IT to all from the versions adopted in the 2015 proposed in Section VII.B.5 (below), their customers with health IT Edition final rule to ensure complete would permit health IT developers to previously certified to the identified interoperability alignment. We welcome voluntarily implement and use a new comment on whether we should adopt version of an adopted standard (e.g., the criteria no later than 24 months after the effective date of a final rule for this such an approach. USCDI), subject to certain conditions We also note, for purposes of clarity, including a requirement that the new proposed rule. For the purposes of meeting this compliance timeline, we that consistent with § 170.555, unless version is approved for use by the the Secretary prohibits the use of a National Coordinator. expect health IT developers to update their certified health IT without new newer version of an identified minimum a. USCDI 2015 Edition Certification mandatory testing and notify their standard code set for certification, Criteria ONC–ACB on the date at which they health IT could continue to be certified or upgraded to a newer version of an We propose to adopt the USCDI have reached compliance. Developers identified minimum standard code set Version 1 (USCDI v1) in § 170.213. 15 would also need to factor these updates than that included in USCDI v1 or the The USCDI is a standardized set of into their next real world testing plan as most recent USCDI version that the health data classes and constituent data discussed in section VII.B.5 of this National Coordinator has approved for elements that would be required to proposed rule. Further, we refer health use in the Program via the Standards support nationwide electronic health IT developer to the next section, which information exchange. Once adopted in describes how the USCDI differs from Version Advancement Process. a final rule, health IT developers would the current CCDS. ii. Address and Phone Number be required to update their certified b. USCDI Standard—Data Classes The USCDI v1 includes new data health IT to support the USCDI v1 for Included elements for ‘‘address’’ and ‘‘phone number.’’ The inclusion of ‘‘address’’ (to 15 We note that USCDI v1is an updated version The USCDI Version 1 (USCDI v1) and represent the postal location for the and distinguished from the Draft United States Core its constituent data elements account for Data for Interoperability (USCDI) previously made available for public review and comment in the the public comments we received on the 16 https://www.healthit.gov/sites/default/files/ course of its development as a prospective standard. Draft USCDI and Proposed Expansion draft-uscdi.pdf.

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00019 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7442 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

patient) and ‘‘phone number’’ (to stemming from its inclusion in the (5) Imaging Narrative; (6) Laboratory represent the patient’s telephone USCDI v1. Report Narrative; (7) Pathology Report number) would improve the Narrative; and (8) Procedures Note. We iv. Clinical Notes comprehensiveness of health seek comment on whether to include information for patient care. The The USCDI v1 includes a new data additional note types as part of the inclusion of these data elements is also class, titled ‘‘clinical notes.’’ ‘‘Clinical USCDI v1. consistent with the list of patient notes’’ is included in the USCDI v1 v. Provenance matching data elements already based on significant feedback from the specified in the 2015 Edition industry since the 2015 Edition final The USCDI v1 also includes a new ‘‘transitions of care’’ certification rule. We also received feedback during data class, titled ‘‘provenance.’’ criterion (§ 170.315(b)(1)(iii)(G)), which the Trusted Exchange Framework and ‘‘Provenance’’ has been identified by supports the exchange of patient health Common Agreement (TEFCA) stakeholders 18 as valuable for information between providers of stakeholder sessions and public interoperable exchange. The provenance patient care. comment period. It has been identified of data was also referenced by by stakeholders as highly desirable data stakeholders as a fundamental need to iii. Pediatric Vital Signs for interoperable exchange. The free text improve the trustworthiness and portion of the clinical notes was most The USCDI v1 includes the pediatric reliability of the data being exchanged. often relayed by clinicians as the data Provenance describes the metadata, or vital sign data elements, which are they sought, but were often missing specified as optional health information extra information about data, that can during electronic health information help answer questions such as when in the 2015 Edition CCDS definition. exchange. Clinical notes can be Pediatric vital signs include: Head and who created the data. composed of text generated from The inclusion of ‘‘provenance’’ as a occipital-frontal circumference for structured (pick-list and/or check the data class in the USCDI v1 would also children less than 3 years of age, BMI box) fields as well as unstructured (free complement the Cures Act requirement percentile per age and sex for youth 2– text) data. A clinical note may include to support the exchange of data through 20 years of age, weight for age per length the assessment, diagnosis, plan of care the use of APIs. This approach differs and sex for children less than 3 years of and evaluation of plan, patient teaching, from the exchange of data via the C– age, and the reference range/scale or and other relevant data points. CDA. While C–CDAs are often critiqued growth curve, as appropriate. As We recognize that a number of due to their relative ‘‘length,’’ the C– explained in section VI.A.2 of this different clinical notes could be useful CDA represents the output of a clinical proposed rule, the inclusion of pediatric for stakeholders. It is our understanding encounter and includes relevant vital sign data elements in the draft that work is being done in the context. The same will not always be USCDI v1 would align with the community to focus on a subset of true in an API context. APIs facilitate provisions of the Cures Act related to clinical notes. We considered three the granular exchange of data and, as health IT to support the health care of options for identifying the different noted in the 2015 Edition final rule, children. Stakeholders emphasized the ‘‘note types’’ to adopt in USCDI v1. The offer the potential to aggregate data from value of pediatric vital sign data first option we considered would allow multiple sources in a web or mobile elements to better support the safety and for the community to offer any and all application (80 FR 62675). The quality of care delivered to children. We recommended notes. The second option inclusion of provenance would help also note that, as discussed in the 2015 we considered would set a minimum retain the relevant context so the Edition proposed rule, the Centers for standard of eight note types. This option recipient can better understand the Disease Control and Prevention (CDC) was derived from the eight note types origin of the data. As noted in section recommends the use of these pediatric identified by the Argonaut Project VII.B.4, we are also proposing to include vital signs for settings of care in which 17 participants. The third option we provenance in our proposed ‘‘API pediatric and adolescent patients are identified would look to the eleven HL7 Resource Collection in Health’’ (ARCH) seen (80 FR 16818–16819) as part of best Consolidated Clinical Data Architecture Version 1 implementation specification practices. The availability of a reference (C–CDA) document types identified in in § 170.215(a)(2), which would list a set range/scale or growth curve would help the C–CDA Release 2.1, which also of base Fast Healthcare Interoperability with proper interpretation of the included the note types being identified Resources (FHIR®) resources that Health measurements for the BMI percentile by the Argonaut Project participants. We IT Modules certified to the proposed per age and sex and weight for age per ultimately decided to move forward API criterion (§ 170.315(g)(10)) would length and sex. Further, the inclusion of with the second option because it unites need to support. this health information in the USCDI v1 public and private interests toward the We propose to further delineate the is the appropriate next step after first same goal. The eight selected note types provenance data class into three data specifying them as optional in the CCDS are a minimum bar and, in the future, elements: ‘‘the author,’’ which definition as part of the 2015 Edition the USCDI may be updated to include represents the person(s) who is rulemaking and as a means of other clinical notes. Specifically, we responsible for the information; ‘‘the supporting patient access to their EHI in propose to include the following author’s time stamp,’’ which indicates a longitudinal format through certified clinical note types for both inpatient the time the information was recorded; health IT (see section 3009(e)(2)(A)(i) of and outpatient (primary care, emergency and ‘‘the author’s organization,’’ which the PHSA as amended by the Cures department, etc.) settings in USCDI v1 would be the organization the author is Act). We recognize, however, that as a minimum standard: (1) Discharge associated with at the time they certain health IT developers and their Summary note; (2) History & Physical; interacted with the data. We have customers may not find these (3) Progress Note; (4) Consultation Note; identified these three data elements as capabilities and information useful. fundamental for data recipients to have Therefore, we request comment on the 17 Link to the Clinical Notes Argonaut Project inclusion of pediatric vital signs in the identified (to clarify: Seven bullets are listed, however, we split laboratory and pathology note 18 https://www.healthit.gov/topic/interoperability/ USCDI v1, including the potential types into their own note) http://wiki.hl7.org/ trusted-exchange-framework-and-common- benefits and costs for all stakeholders index.php?title=201805_Clinical_Notes_Track. agreement.

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00020 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7443

available and both are commonly class and creating a new data class Companion Guides (CCGs) 21 and by captured and currently available titled, ‘‘Substance Reactions,’’ which specifying in the CCDS definition where through standards. We request comment would be meant to be inclusive of certain data should be placed in the C– on the inclusion of these three data ‘‘Medication Allergies.’’ The new CDA Release 2.1 templates (e.g., ‘‘goals’’ elements and whether any other ‘‘Substance Reactions’’ data class would in the goals section).22 The C–CDA provenance data elements, such as the include the following data elements: Companion Guide, which was released identity of the individual or entity the ‘‘Substance’’ and ‘‘Reaction,’’ and after the 2015 Edition final rule, data was obtained from or sent by include SNOMED CT as an additional provides similar, but additional C–CDA (sometimes discussed in standards applicable standard for non-medication implementation structure. For example, working groups as the provenance of the substances. race and ethnicity are required data data’s ‘‘last hop’’), would be essential to c. USCDI Standard—Relationship to elements in the USCDI (formerly the include as part of the USCDI v1 Content Exchange Standards and CCDS) and must be included in C–CDA standard. We acknowledge that there is Implementation Specifications exchanges if known, or they may be currently work to help define marked with a nullFlavor of UNK provenance in a standard robust In order to align with our approach to (unknown) if not known. The C–CDA manner, and we anticipate adopting the be responsive to the evolution of Release 2.1 is unclear on the location industry consensus once it becomes standards and to facilitate updates to and value set, but the C–CDA available. newer versions of standards, the USCDI Companion Guide clarifies the location v1 (§ 170.213) is ‘‘content exchange’’ and value set. The adoption of the C– vi. Unique Device Identifier(s) for a standard agnostic. It establishes ‘‘data Patient’s Implantable Device(s) CDA Companion Guide would align policy’’ and does not directly associate with our goal to increase the consistent We are aware of a recently published with the content exchange standards implementation of standards among implementation guide (IG) within HL7 and implementation specifications health IT developers and improve that provides further guidance on the which, given a particular context, may interoperability. We propose to adopt unique device identifier (UDI) be necessary to exchange the entire this C–CDA Companion Guide to requirements. The IG, Health Level 7 USCDI, a USCDI class, or elements ® support best practice implementation of (HL7 ) CDA R2 Implementation Guide: within it. To our knowledge, all data USCDI v1 data classes and 2015 Edition C–CDA Supplemental Templates for classes in the USCDI v1 can be certification criteria that reference C– Unique Device Identification (UDI) for supported by commonly used ‘‘content CDA Release 2.1 (§ 170.205(a)(4)). The Implantable Medical Devices, Release exchange’’ standards, including HL7 C– criteria include: 19 ® 1–US Realm, identifies changes CDA Release 2.1 and FHIR . • ‘‘Transitions of care’’ needed to the C–CDA to better facilitate d. Clinical Notes C–CDA (§ 170.315(b)(1)); the exchange of the individual UDI Implementation Specification • ‘‘clinical information reconciliation components in the health care system and incorporation’’ (§ 170.315(b)(2)); when devices are implanted in a In conjunction with our proposal to • ‘‘care plan’’ (§ 170.315(b)(9)); patient. The UDI components include adopt the USCDI v1, we propose to • ® ‘‘view, download, and transmit to the Device Identifier (DI) and the adopt the HL7 CDA R2 IG: C–CDA 3rd party’’ (§ 170.315(e)(1)); following individual production Templates for Clinical Notes R1 • ‘‘consolidated CDA creation identifiers: The lot or batch number, Companion Guide, Release 1 in performance’’ (§ 170.315(g)(6)); and serial number, manufacturing date, § 170.205(a)(4)(i) (‘‘C–CDA Companion • ‘‘application access—all data expiration date, and distinct Guide’’). The C–CDA Companion Guide request’’ (§ 170.315(g)(9)). identification code. However, as this provides supplemental guidance and We propose, as a Maintenance of new IG has been recently published, we additional technical clarification for Certification requirement for the real request comment on whether we should specifying data in the C–CDA Release world testing Condition of Certification, 20 add this UDI IG as a requirement for 2.1. As noted above, the proposed that health IT developers with health IT health IT to adopt in order to meet the USCDI v1 includes new data classes, certified to the six above-identified requirements for UDI USCDI Data Class. such as ‘‘clinical notes,’’ which are certification criteria prior to the In addition, we do not have a reliable further supported through the C–CDA effective date of a subsequent final rule basis on which to estimate how much it Companion Guide. For example, the C– would have to update such certified would cost to meet the requirements CDA Companion Guide provides health IT to the proposed revisions. We outlined in the UDI IG; and, therefore, specifications for clinical notes by further propose, as a Maintenance of we request comment on the cost and indicating that clinical notes should be Certification requirement for the real burden of complying with this proposed recorded in ‘‘note activity’’ and requires world testing Condition of Certification, requirement. references to other discrete data, such as that health IT developers must provide ‘‘encounters.’’ The C–CDA Companion the updated certified health IT to all vii. Medication Data Request for Guide also enhances implementation of Comment their customers with health IT the 2015 Edition certification criteria previously certified to the identified The USCDI v1 ‘‘Medication’’ data that reference the C–CDA Release 2.1 criteria no later than 24 months after the class includes two constituent data (§ 170.205(a)(4)). As noted by effective date of a final rule for this elements within it: Medications and stakeholders, the C–CDA Release 2.1 proposed rule. For the purposes of Medication Allergies. With respect to includes some optionality and meeting this compliance timeline, we the latter, Medication Allergies, we ambiguity with respect to data element expect health IT developers to update request comment on an alternative components, such as the locations and their certified health IT without new approach. This alternative would result value sets. We attempted to address mandatory testing and notify their in removing the Medication Allergies some of this optionality by clarifying data element from the Medication data requirements using Certification 21 https://www.healthit.gov/topic/certification- ehrs/2015-edition-test-method. 19 http://www.hl7.org/implement/standards/ 20 http://www.hl7.org/implement/standards/ 22 https://www.healthit.gov/sites/default/files/ product_brief.cfm?product_id=486. product_brief.cfm?product_id=447. topiclanding/2018-04/2015Ed_CCG_CCDS.pdf.

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00021 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7444 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

ONC–ACB on the date at which they transactions CMS adopted at 42 CFR • Receive fill status notifications have reached compliance. Developers 423.160(b)(2)(iv) for NCPDP SCRIPT (RxFill, RxFillIndicatorChange) would also need to factor these updates 2017071. Therefore, we propose to An RxFill transaction is sent from a into their next real world testing plan as adopt a new 2015 Edition ‘‘electronic pharmacy to a prescriber or a long term discussed in section VII.B.5 of this prescribing’’ criterion (§ 170.315(b)(11)) or post-acute care (LTPAC) facility proposed rule. that includes the following transactions: indicating the FillStatus (dispensed, 2. Electronic Prescribing Standard and • Create new prescriptions (NewRx, partially dispensed, not dispensed or Certification Criterion NewRxRequest, returned to stock, transferred to another NewRxResponseDenied) pharmacy) of the new, refill, or resupply We propose to update the electronic prescriptions for a patient. prescribing (e-Rx) SCRIPT standard A NewRx transaction is a new RxFillIndicator informs the pharmacy of used for ‘‘electronic prescribing’’ in the prescription from a prescriber to a the prescriber’s intent for fill status 2015 Edition to NCPDP SCRIPT pharmacy so that it can be dispensed to notifications for a specific patient/ 2017071, which would result in a new a patient. A NewRxRequest is a request medication. An RxFillIndicatorChange e-Rx standard becoming the baseline for from a pharmacy to a prescriber for a is sent by a prescriber to a pharmacy to certification. We propose to adopt this new prescription for a patient. A indicate that the prescriber is changing standard in § 170.205(b)(1). ONC and NewRxResponseDenied is a denied the types of RxFill transactions that CMS have historically maintained response to a previously sent were previously requested, where the complementary policies of aligning NewRxRequest (if approved, a NewRx prescriber may modify the fill status of health IT certification criteria and would be sent). A transactions previously selected or associated standard for e-prescribing NewRxResponseDenied response may cancel future RxFill transactions. with the CMS Medicare Part D e-Rx and occur when the NewRxRequest cannot • Request and receive medication MH standards (75 FR 44589; 77 FR be processed or if information is history (RxHistoryRequest, 54198). To this end, CMS has retired the unavailable. current standard (NCPDP SCRIPT RxHistoryResponse) • Change prescriptions version 10.6) for e-RX and MH and An RxHistoryRequest transaction is a (RxChangeRequest, adopted NCPDP SCRIPT 2017071 as the request from a prescriber for a list of RxChangeResponse) standard for Part D e-Rx and MH medications that have been prescribed, effective January 1, 2020, conditional on An RxChangeRequest transaction dispensed, claimed, or indicated by a ONC updating the Program to the originates from a pharmacy to request: patient. This request could be sent to a NCPDP SCRIPT 2017071 standard for its A change in the original prescription state Prescription Drug Monitoring e-Rx certification criterion (see also 42 (new or fillable), validation of prescriber Program (PDMP). An CFR 423.160(b)(1)(v) and (2)(iv)). In credentials, a prescriber to review the RxHistoryResponse is a response to an addition, CMS recently sought comment drug requested, or a prior authorization RxHistoryRequest containing a patient’s regarding whether the NCPDP SCRIPT from the payer for the prescription. An medication history. It includes the 2017071 standard could facilitate future RxChangeResponse transaction medications that were dispensed or reporting of the proposed Query of originates from a prescriber to respond: obtained within a certain timeframe, Prescription Drug Monitoring Program To a prescription change request from a and optionally includes the prescriber (PDMP) measure in both the 2019 pharmacy, to a request for a prior that prescribed it. RxHistoryRequest and Physician Fee Schedule proposed rule authorization from a pharmacy, or to a RxHistoryResponse transactions may be (83 FR 35923) and Hospital Inpatient prescriber credential validation request sent directly or through an Prospective Payment Systems (IPPS) from a pharmacy. intermediary. Fiscal Year 2019 proposed rule (83 FR • • Cancel prescriptions (CancelRx, Ask the Mailbox if there are any 20528). CancelRxResponse) transactions (GetMessage) As summarized in the IPPS Fiscal This transaction is used by the Year 2019 final rule (83 FR 41144), CMS A CancelRx transaction is a request prescriber or pharmacy asking the received comments supportive of using from a prescriber to a pharmacy to not mailbox if there are any transactions. It the NCPDP SCRIPT 2017071 medication fill a previously sent prescription. A is at the heart of the mechanism used by history transactions for PDMP queries CancelRx must contain pertinent a pharmacy or prescriber system to and responses, as well as comments information for the pharmacy to be able receive transactions from each other or asking CMS to seek harmonizing of the to find the prescription in their system from a payer or the REMS Administrator 2015 Edition e-prescribing certification (patient, medication (name, strength, via a Switch, acting as a Mailbox. criterion to the NCPDP SCRIPT 2017071 dosage, form), prescriber, prescription • Relay acceptance of a transaction back standard specified in the part D program number if available). A to the sender (Status) portions of the recent ‘‘Medicare CancelRxResponse is a response from a Program; Contract Year 2019 Policy and pharmacy to a prescriber to This transaction is used to relay Technical Changes to the Medicare acknowledge a CancelRx, and is used to acceptance of a transaction back to the Advantage, Medicare Cost Plan, denote if the cancellation is Approved sender. A Status in response to any Medicare Fee-for-Service, the Medicare or Denied. applicable transaction other than GetMessage indicates acceptance and Prescription Drug Benefit Programs, and • Renew prescriptions the PACE Program’’ final rule (83 FR responsibility for a request. A Status in (RxRenewalRequest, response to GetMessage indicates that 16440). RxRenewalResponse) In addition to proposing to adopt the no mail is waiting for pickup. A Status NCPDP SCRIPT 2017071 standard for An RxRenewalRequest transaction cannot be mailboxed and may not the transactions that are listed in the originates from a pharmacy to request contain an error. current ‘‘electronic prescribing’’ additional refills beyond those • Respond that there was a problem criterion (§ 170.315(b)(3)), we propose to originally prescribed. with the transaction (Error) adopt and require conformance to all of RxRenewalResponse originates from a This transaction indicates an error has the NCPDP SCRIPT 2017071 standard prescriber to respond to the request. occurred, indicating the request was

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00022 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7445

terminated. An Error can be generated The RxTransferRequest transaction is check certain information, such as lab when there is a communication problem used when the pharmacy is asking for results. Second, all REMS, including or when the transaction actually had an a transfer of one or more prescriptions those without ETASU, must fulfill FDA- error. An error can be mailboxed, as it for a specific patient to the requesting approved reporting requirements. Each may be signifying to the originator that pharmacy. The RxTransferResponse REMS program must also include a a transaction was unable to be delivered transaction is the response to the program assessment schedule that or encountered problems in the RxTransferRequest which includes the examines the program’s effectiveness on acceptance. The Error must be a prescription(s) being transferred or a intervals approved by the FDA as part different response than a Status, since rejection of the transfer request. It is of the overall REMS program. The the communication between the system sent from the transferring pharmacy to results of these assessments are and the Mailbox must clearly denote the the requesting pharmacy. The submitted to the FDA as part of the actions taking place. An Error is a RxTransferConfirm transaction is used ongoing evaluation of REMS program response being delivered on behalf of a by the pharmacy receiving (originally effectiveness. Accordingly, we propose previous transaction, and the Status requesting) the transfer to confirm that to include the REMS transactions as part signifies no more mail. the transfer prescription has been of this proposed certification criterion. We would also note for commenters’ • Respond that a transaction requesting received and the transfer is complete. • benefit that the SCRIPT 2017071 testing a return receipt has been received Recertify the continued tool under development is being (Verify) administration of a medication order (Recertification) designed to support testing these REMS This transaction is a response to a This transaction is a notification from transactions. pharmacy or prescriber indicating that a a facility, on behalf of a prescriber, to a We believe that removing the 2015 transaction requesting a return receipt pharmacy recertifying the continued Edition certification criterion (codified has been received. Verifications results administration of a medication order. in § 170.315(b)(3)) that references when a ‘‘return receipt requested’’ flag An example use is when an existing NCPDP SCRIPT version 10.6 and is set in the original request. Upon medication order has been recertified by replacing it with an updated receiving a transaction with the prescriber for continued use. Long e-prescribing criterion (proposed to be codified in § 170.315(b)(11)) would ReturnReceipt set, it is the term or post-acute care use only. responsibility of the receiver to either harmonize with relevant CMS program • Complete Risk Evaluation and generate a Verify in response to the timelines, including Part D e-prescribing Mitigation Strategy (REMS) request (recommended) or generate a requirements and the option for eligible Transactions (REMSInitiationRequest, Status in response to this request, clinicians, hospitals, and CAHs to report REMSInitiationResponse, followed subsequently by a free on the Query of Prescription Drug REMSRequest, and REMSResponse) standing Verify. This transaction Monitoring Program (PDMP) quality notifies the originator that the With CMS’ recent adoption of these measure for Promoting Interoperability transaction was received at the software transactions in their recently issued Programs. However, should our system. It is not a notification of action final rule associated with e-prescribing proposal to adopt the new e-prescribing taking place, since time may elapse for Medicare Part D (42 CFR criterion (§ 170.315(b)(11)) be finalized before the ultimate answer to the 423.160(b)(2)(iv)(W)–(Z)), we believe prior to January 1, 2020, we also transaction may take place. that it would be equally beneficial to propose to permit continued include these four REMS transactions as • certification to the current 2015 Edition Request to send an additional supply part of this proposed certification ‘‘electronic prescribing’’ criterion of medication (Resupply) criterion: REMSInitiationRequest, (§ 170.315(b)(3)) for the period of time This transaction is a request from a REMSInitiationResponse, in which it would continue to be used Long Term or Post-Acute Care (LTPAC) REMSRequest, and REMSResponse. as a program standard in the CMS organization to a pharmacy to send an The Food and Drug Administration Medicare Part D Program or the CMS additional supply of medication for an Amendments Act (FDAAA) of 2007 Promoting Interoperability Programs. existing order. An example use case is (Pub. L. 110–85) enables the Food and Once it is no longer used in those when a medication supply for a resident Drug Administration (FDA) to require a Programs, we would no longer permit is running low (2–3 doses) and a new REMS from a pharmaceutical certification to that criterion and would supply is needed from the pharmacy, manufacturer if the FDA determines that remove it from the Code of Federal the LTPAC organization need a way to a REMS is necessary to ensure the Regulations. We will consider setting an notify the pharmacy that an additional benefits of a drug outweigh the risks effective date for such actions in a supply for the medication is needed. associated with the drug. The currently subsequent final rule based on • Communicate drug administration approved REMS programs vary in levels stakeholder feedback and CMS policies events (DrugAdministration) of complexity. Typically a Med Guide at the time. To this point, we note that and Communication Plan is required, the continued acceptability of a Health This transaction communicates drug but some also require Elements to IT Module certified to the criterion administration events from a prescriber/ Assure Safe Use (ETASU). The large codified in § 170.315(b)(3) for purposes care facility to the pharmacy or other majority of existing REMS programs are of meeting the CEHRT definition and entity. It is a notification from a for drugs dispensed through specialty participating in the CMS Promoting prescriber/care facility to a pharmacy or pharmacies, clinics, and hospitals, but Interoperability Programs would be a other entity that a drug administration as REMS become more common they matter of CMS policy. event has occurred—for example, a may ultimately have a greater impact on medication was suspended or retail-based products. 3. Clinical Quality Measures—Report administration was resumed. The impact of REMS is twofold. First, Criterion • Transfer one or more prescriptions REMS with ETASU may require the In the 2015 Edition final rule, ONC (RxTransferRequest, pharmacist to verify prescriber, patient, adopted four clinical quality measure RxTransferResponse, and/or pharmacy enrollment in a (CQM) certification criteria, RxTransferConfirm) registry and, in some cases, verify or § 170.315(c)(1) CQMs—record and

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00023 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7446 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

export, § 170.315(c)(2) CQMs—import optional provision for CMS program- designed and implemented. We also and calculate, § 170.315(c)(3) CQMs— specific certification, developers can solicit comment on the future report, and § 170.315(c)(4) CQMs—filter also support their end-users who intend possibility of FHIR-enabled APIs (80 FR 62649–62655). These four to use their certified health IT to report replacing or complementing QRDA criteria were adopted with the intent to eCQMs to CMS in the ‘‘form and reports for quality reporting and support providers’ quality improvement manner’’ CMS requires (i.e., using the improvement. activities and in electronically format specified in the CMS QRDA IGs) If we finalize this proposal in a generating CQM reports for reporting (80 FR 62652). subsequent final rule, we propose to with certified health IT to programs Since the 2015 Edition final rule was adopt the latest CMS QRDA IGs at the such as the EHR Incentive Programs, published (October 16, 2015), we have time of final rule publication, as CMS Quality Payment Program, and gained additional certification updates their QRDA IGs annually to Comprehensive Primary Care plus experience and received feedback from support the latest eCQM specifications initiative. All four CQM criteria require the industry that health IT certified to and only accepts eCQM reporting to the certified health IT to be capable of the ‘‘CQMs-report’’ criterion latest version. generating CQM reports using the HL7 (§ 170.315(c)(3)) are only/primarily We note that this approach would Quality Reporting Document being used to submit eCQMs to CMS for also facilitate a means for ONC to permit Architecture (QRDA) Category I participation in CMS programs. developers to update its certified health standard, which provides CQM reports Therefore, as a means of reducing IT to newer versions of the CMS QRDA for individual patients. Specifically, we burden, we propose to remove the HL7 IGs through the real world testing ® adopted HL7 CDA Release 2 QRDA standard requirements from the Maintenance of Certification provision Implementation Guide for: Quality 2015 Edition CQMs—report criterion in for standards and implementation Reporting Document Architecture— § 170.315(c)(3), but require that health specification updates in support of Category I (QRDA I); Release 1, Draft IT certified to the criterion support the ongoing interoperability (see section Standard for Trial Use (DSTU) Release CMS QRDA IGs. This would directly VII.B.5 of this proposed rule). 3 (US Realm)), Volume 1 reduce burden on health IT developers 4. Electronic Health Information Export (§ 170.205(h)(2)). Two of the CQM and indirectly providers as they would criteria, CQMs—report (§ 170.315(c)(3)) We propose to adopt a new 2015 no longer have to, in practice, develop Edition certification criterion for EHI and CQMs—filter (§ 170.315(c)(4)), also (health IT developers) and support (both require certified health IT to be capable export in § 170.315(b)(10). This criterion developers and providers) two forms of is intended to provide patients and of generating CQM reports using the the QRDA standard (i.e., the HL7 and QRDA Category III standard, which health IT users with a means to CMS forms). We note that the Fast efficiently export the entire electronic provides aggregate CQM reports for a set Health Interoperability Resources of patients. More specifically, we health record for a single patient or all (FHIR) standard offers the potential for patients in a computable, electronic adopted QRDA Category III, supporting quality improvement and Implementation Guide for CDA Release format, and facilitate the receiving reporting needs and promises to be a health IT system’s interpretation and 2 (§ 170.205(k)(1)) and the Errata to the more efficient, modular, and HL7 Implementation Guide for CDA® use of the EHI, to the extent reasonably interoperable standard to develop, practicable using the developer’s Release 2: QRDA Category III, DSTU implement, and utilize through APIs. Release 1 (US Realm), September 2014 existing technology. However, until the potential benefits of This outcome would promote access, (§ 170.205(k)(2)). FHIR APIs can be realized for quality The ‘‘CQMs—report’’ certification exchange, and use of EHI and facilitate improvement and reporting, we believe criterion (§ 170.315(c)(3)) includes an health care providers’ ability to switch that solely requiring the CMS QRDA IGs optional certification provision for health IT systems or to migrate EHI for for the ‘‘CQMs—report’’ criterion demonstrating that the health IT can use in other technologies. Additionally, balances the burden to developers and create QRDA reports in the form and as discussed in section VII.B.2 of this providers, while still meeting the goal of manner required for submission to CMS preamble, certification to this criterion facilitating quality improvement and programs, which is in accordance with would provide some degree of assurance reporting to CMS. CMS’ QRDA Implementation Guide that a health IT developer supports, and To support the proposal, we propose (IGs).23 The CMS QRDA IGs include does not inhibit, the access, exchange, to incorporate by reference the latest specific requirements to support and use of EHI for the specific use cases annual CMS QRDA IGs, specifically the providers participating in CMS that the criterion addresses. 2019 CMS QRDA I Implementation programs in addition to the HL7 IGs. At This proposed criterion supports two Guide for Hospital Quality Reporting 24 the time of the finalization of the 2015 specific use cases for which we believe Edition final rule and in response to and the 2019 CMS QRDA III that all EHI produced and electronically public comment, we noted that there Implementation Guide for Eligible managed in a developer’s technology Professionals (EPs) and Eligible should be made readily available for was mixed feedback on whether this 25 criterion should require adherence to Clinicians. A Health IT Module would export as a standard capability of the HL7 QRDA Category I and Category need to be certified to both standards to certified health IT. III standards or solely to the CMS QRDA provide flexibility to providers. First, we propose that health IT IGs. As such, we adopted an approach However, we solicit comment on certified to this criterion would have to that allowed for flexibility and only whether we should consider an enable the export of EHI for a single required that certified health IT support approach that permits certification to patient upon a valid request from that the HL7 QRDA standards, which are only one of the standards depending on patient or a user on the patient’s behalf. program-agnostic and can support a the care setting for which the product is This patient-focused export capability, number of use cases for exchanging which is discussed in more detail 24 https://ecqi.healthit.gov/system/files/QRDA_ below, complements other provisions of CQM data. Because the criterion has the HQR_2019_CMS_IG_final_508.pdf. 25 https://ecqi.healthit.gov/system/files/2019_ this proposed rule that support patients’ 23 https://ecqi.healthit.gov/qrda-quality-reporting- CMS_QRDA_III_Eligible_Clinicians_and_EP_IG- access to their EHI including document-architecture. 508.pdf. information that may eventually be

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00024 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7447

accessible via the APIs described in collaborative process to expand the his or her office staff who will be section VII.B.4 of this preamble. USCDI (see the discussion of the API performing the request on behalf of the Ultimately, we expect all data to be Condition of Certification and the patient given that a request of this transferred through APIs or other proposed API criterion in nature would likely occur in the context advanced technologies. EHI export also § 170.315(g)(10) in VII.B.4 for additional of an individual exercising their right of supports longitudinal data record information). access under the HIPAA Privacy Rule development, and aligns with section (45 CFR 164.524). In this regard, the a. Patient Access 4006(a) of the Cures Act, which requires proposed 2015 Edition ‘‘EHI export’’ [t]he Secretary, in consultation with the As noted above, the export criterion could facilitate and support the National Coordinator, [to] promote functionality required by this provision of a patient’s record in an policies that ensure that a patient’s EHI certification criterion would support electronic format. In service to is accessible to that patient and the both a patient’s access to their EHI and innovative and patient-centric patient’s designees, in a manner that a provider’s ability to switch to another approaches, a health IT developer could facilitates communication with the health IT system. In the patient access develop a method that allows the patient’s health care providers and other context, we propose that a user must be patient using a technology application individuals, including researchers, able to timely execute the single patient (e.g., portal or ‘‘app’’) to execute the consistent with such patient’s consent. EHI export at any time the user chooses request without needing a provider to Second, this criterion would support and without subsequent developer do so on their behalf. We seek comment the export of EHI when a health care assistance to operate. The health IT on whether this portion of the criterion provider chooses to transition or migrate developer should enable the user to should be made more prescriptive to information to another health IT system. make data requests and receive the only allow the patient and his or her As discussed in section VIII.C.5.c.iii of export efficiently, without unreasonable authorized representative to be the this preamble, health IT developers are burden. For example, the health IT requestor of their EHI, similar to how in a unique position to block the export developer should not: Require the user we have previously scoped such criteria and portability of data for use in to make a request multiple times for as ‘‘view, download, and transmit to 3rd competing systems or applications, or to different types of EHI; provide party’’ (§ 170.315(e)(1)). charge rents for access to the basic unreasonable delays for the export; or Similar to the 2015 Edition ‘‘data technical information needed to prohibit reasonable user access to the export’’ certification criterion facilitate the conversion or migration of system during the export process. (§ 170.315(b)(6)), which we propose for data for these purposes. By providing at ‘‘Timely’’ does not mean real-time; removal below, we acknowledge least a baseline capability for exporting however, we stress that any delays in potential privacy and security concerns EHI in a commercially reasonable providing the export must be no longer may arise when EHI is exported and, format, we believe that this criterion than reasonably necessary to avoid therefore, propose that for provider- would help to address some of these interference with other clinical mediated requests, a developer may business practices and enable smoother functions of the health IT system. This design the health IT to limit the type of transitions between health IT systems. is similar to the approach we have taken users that would be able to access and This criterion is intended to further for export of clinical quality measure initiate EHI export functions. However, the two use cases outlined above while data. The export capability does not as we previously specified in the 2015 providing an incremental approach require that data be received Edition final rule, the ability to ‘‘limit’’ given the known and anticipated health instantaneously. Rather, as we have the single patient EHI export IT landscape when ONC expects stated before (80 FR 62650) a non- functionality is intended to be used by certified health IT with this conformity would exist if surveillance and at the discretion of the provider functionality will be widely available in revealed that processing or other delays organization implementing the the ecosystem. At the time of this were likely to substantially interfere technology, not a way for health IT rulemaking, we believe a focused with the ability of a provider or health developers to implicitly prevent the certification criterion that is standards- system to view and verify their CQM overarching user-driven aspect of this agnostic will provide a useful first step results for quality improvement on a capability (80 FR 62646). to enabling patients to request and near real-time basis. Similarly, a non- receive their EHI and for providers to b. Transitions Between Health IT conformity would exist if delays were Systems more readily switch or migrate causing or contributing to users being information between health IT systems. presented with data files that no longer In addition to and separate from the Understanding that open, standards- contained current, accurate, or valid patient access use case described above, based APIs are an emerging technology data. To avoid these implementation health IT certified to this criterion and that some health IT developers issues and ensure that capabilities would facilitate the migration of EHI to today have implemented proprietary support all required outcomes, health IT another health IT system. We propose APIs, this proposed criterion for EHI developers should seek to minimize that a health IT developer of health IT export provides an initial method for processing times and other delays to the certified to this criterion must, at a exporting patient health information in greatest extent possible.26 customer’s request, provide a complete these circumstances. Over time, ONC As previously defined under the export of all EHI that is produced or may consider expanding the proposed Program, ‘‘user’’ is a health care managed by means of the developer’s criterion or replacing it to achieve the professional or his or her office staff; or certified health IT. Health IT developers goals in § 170.402. It is also possible that a software program or service that would have flexibility as to how this in the future, this criterion will no would interact directly with the outcome is achieved, so long as a longer be needed once standards-based certified health IT (80 FR 62611, 77 FR customer is able to receive the export in APIs are widely available in the health 54168). We typically would expect the a timely and efficient manner, and in a IT ecosystem with the ability to ‘‘user’’ in this case to be a provider or format that is commercially reasonable. facilitate exchange of a wider set of For example, in contrast with the standardized data elements per the 26 https://www.healthit.gov/test-method/clinical- patient export capability, which must be predictable, transparent, and quality-measures-cqms-record-and-export#ccg. available to a user without subsequent

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00025 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7448 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

developer assistance to operate, the The use of the term ‘‘electronic health EHI that may present challenges for ‘‘database export’’ capability of this information’’ (EHI) is deliberate and in meeting the intent of this proposed criterion could require action or support alignment with the Cures Act and the criterion. on the part of the health IT developer. proposed definition of this term in d. Export Format We note that while this criterion § 170.102. Its use supports consistency focuses on the technical outcomes and the breadth of types of data The proposed certification criterion supported by this capability, developers envisioned by this criterion. Clinical does not prescribe a content standard of health IT certified to this criterion data would encompass imaging for the EHI export. However, it requires would be required to provide the information—both images and narrative health IT developers to provide the assurances proposed in § 170.402, text about the image—as this is part of format, such as a data dictionary or which include providing reasonable the patient’s total record; however, we export support file, for the exported cooperation and assistance to other understand that EHRs may not be the information to assist the receiving persons (including customers, users, standard storage location for images and system in processing the EHI without and third-party developers) to enable solicit comment on the feasibility, loss of information or its meaning to the the use of interoperable products and practicality, and necessity of exporting extent reasonably practicable using the services. Thus, while developers would images and/or imaging information. We developer’s existing technology. have flexibility as to how they request comment on what image Providing EHI export information is implement the export functionality for elements, at a minimum, should be consistent with emerging industry transitions between systems, they would shared such as image quality, type, and practices and capabilities to offer ultimately be responsible for ensuring narrative text. It is understandable that requestors the ability to access, that the capability is deployed in a way developers will not be able to export download, and move their information that enables a customer and their third- every existing data element, nor that all without unreasonable burden. party contractors to successfully migrate possible data elements are necessary for Companies such as Facebook,27 data. Such cooperation and assistance transfer. For finalization in a subsequent Google,28 and Twitter 29 offer publicly- could include, for example, assisting a final rule, we solicit comment on available links which provide requestors customer’s third-party developer to whether we should require, to support necessary information on how to automate the export of EHI to other transparency, health IT developers to download their personal information systems. We refer readers to section attest or publish as part of the export including, in some cases, several VII.B.2 of the proposed rule for further format documentation the types of EHI download options for requestors discussion of a health IT developer’s they cannot support for export. alongside their export instructions. assurances as proposed in § 170.402. We also propose the following Public access to comparable EHI export metadata categories that would be information would further support c. Scope of EHI excluded from this criterion, and have third-party companies in this space, as For both use cases supported by this listed examples for clarity below. We they would have additional information criterion, EHI export encompasses all seek comment on these exclusion and general knowledge for use of the EHI that the health IT system categories, and request feedback on available data. Accordingly, we propose produces and electronically manages for what metadata elements should remain that the developer’s export format a patient or group of patients. This included for export, or be added to the should be made publicly available via a applies to the health IT’s entire list of data that would be allowed to be hyperlink as part of certification to the database, including but not limited to excluded in a subsequent final rule: ‘‘EHI export’’ criterion, including clinical, administrative, and claims/ • Metadata present in internal keeping the hyperlink up-to-date with billing data. It would also include any databases used for physically storing the the current export format. data that may be stored in separate data data. Examples include: Internal We believe that by making the export warehouses that the system has access database table names, field names, format publicly available at the time of to, can produce, and electronically schema, constraints, Triggers, Field size certification (and keeping the manages. For example, health IT (number of bytes), Field type (String, information current) will stimulate a developers may store EHI in these integer, double, long), and Primary keys vibrant, competitive market in which warehouses to prevent performance or object identifiers used internally for third- party software developers can impacts from data queries that may slow querying. specialize in processing the data down the ‘‘main’’ health IT system’s • Metadata that may not be necessary exported from certified health IT (e.g., EHR) clinical performance. We to interpret EHI export, including products in support of patients and clarify that ‘‘EHI’’ also includes the information that is typically required for providers. Moreover, we believe this oldest EHI available on that patient to processing of transactions such as proposal will transform today’s current the most recent, no matter the specific encryption keys, internal user roles, guess-work, one-off processes into electronic format (e.g., PDFs are ancillary information such as something more predictable and included). As mentioned above, our information stored in different formats, transparent such that greater industry intention is that ‘‘produces and local codes for internal use; audit logs, efficiencies can be realized. We note electronically manages’’ refers to a record reviews, or history of change. and clarify that the export format need health IT product’s entire database. • Metadata that refers to data that is not be the same format used internally However, we seek comment on the not present in the EHI export, such as by the health IT system, and the health terminology used (‘‘produces and links to files and other external IT developer would not need to make electronically manages’’) and whether attachments that are not part of the public their proprietary data model. The that captures our intent or whether there export, and information used in proposed certification criterion also are any alternatives to the language we conjunction with data from other should consider to further clarify our applications that is not part of the 27 https://www.facebook.com/help/ _ _ intent. Alternative language we health IT. 1701730696756992?helpref=hc global nav. 28 https://support.google.com/accounts/answer/ considered included ‘‘produce and We also seek comment, for 3024190?hl=en. electronically retain’’ data, which could consideration in finalizing this criterion 29 https://help.twitter.com/en/managing-your- encompass more data. in a subsequent final rule, on types of account/how-to-download-your-twitter-archive.

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00026 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7449

does not prescribe how the exported manages, should this criterion include providers to adopt and implement the EHI is made available to the user, as this capabilities to permit health care functionality included in the ‘‘EHI may depend on the size and type of providers to set timeframes for EHI export’’ criterion. To note, we refer information. We would expect that the export, such as only the ‘‘past two readers to the ‘‘Assurances’’ Condition information be made available to the years’’ or ‘‘past month’’ of EHI? and Maintenance of Certification user or requestor in an acceptable For discussion of the required requirements in section VII.B.2, which manner without placing unreasonable timeframe for developers of certified propose complementary requirements burden on the user or requestor. Please health IT to certify to this proposed on health IT developers to rollout health also generally see our discussion of criterion and make it available to their IT certified ‘‘EHI export’’ within 24 information blocking in section VIII and customers, please see Section VII.B.2, months of the effective date of a final particularly section VIII.D.5. which addresses a health IT developer’s rule for this proposed rule. We welcome required assurances regarding the comments on our proposed compliance e. Initial Step To Persistent Access to availability and provision of this EHI timeline. All of a Patient’s EHI export capability to its customers. We note that we do not propose a We believe that open, standards-based transition period for the ‘‘data export’’ g. Replaces the 2015 Edition ‘‘Data APIs should provide persistent access to criterion. We propose to remove the Export’’ Criterion in the 2015 Edition patients’ EHI over time to achieve the criterion from the 2015 Edition upon the Base EHR Definition envisioned goals in § 170.404. In the effective date of a final rule for this meantime, this proposed criterion in We propose to remove the ‘‘data proposed rule. Unlike the ‘‘application § 170.315(b)(10) will provide an initial export’’ criterion (§ 170.315(b)(6)) from access—data category request’’ criterion step toward achieving those goals. We the 2015 Edition, including the 2015 (which we propose to replace with the clarify that ‘‘persistent’’ or ‘‘continuous’’ Edition Base EHR definition expressed new API criterion in this proposed rule), access to EHI is not required to satisfy in § 170.102. Correspondingly, we the ‘‘data export’’ criterion does not this criterion’s requirements and that propose to include the proposed ‘‘EHI support an objective or measure under the minimum requirement is for a export’’ criterion (§ 170.315(b)(10)) in the CMS Promoting Interoperability discrete data export capability. the 2015 Edition Base EHR definition, Programs. Therefore, we do not believe Similarly, while the criterion requires which would affect health care that health IT developers and health the timely export of all EHI, such export providers’ compliance responsibilities care providers need to support the need not occur instantaneously (or in when it comes to possessing CEHRT for functionality in the ‘‘data export’’ ‘‘real-time’’). However, health IT associated CMS programs. A specific C– criterion while they transition to the developers are encouraged to consider CDA data export criterion no longer development, adoption, and persistent access and real-time supports advancements in implementation of the EHI export approaches as part of the step-wise interoperability in the evolving health criterion. This approach should reduce progression we see towards open, IT industry. The proposed ‘‘EHI export’’ burden and costs for both health IT standards-based APIs for a growing certification criterion is standards- developers and health care providers. number of data elements per the USCDI agnostic and supports a more open We welcome comments on this in the proposed ‘‘standardized API for approach to interoperability. More approach, including whether this will patient and population services’’ specifically, the proposed ‘‘EHI export’’ leave health care providers without an criterion (§ 170.315(g)(10).’’ Further, we criterion differs significantly from the export capability for an inordinate caution that where it is reasonable for a ‘‘data export’’ certification criterion as period of time such that we should developer to provide persistent or real- the latter is limited to clinical data as require health IT developers to support time access to electronic health specified in the C–CDA. Also, the the ‘‘data export’’ functionality for information, the refusal to do so may be proposed ‘‘EHI export’’ criterion is not health care providers until the health IT inconsistent with the Conditions of limited to just the scope of the certified developer attests to providing the new Certification in § 170.401 (information capabilities in the certified Health IT EHI export functionality to all of its blocking) and § 170.402 (assurances Module as it applies to all produced and customers. related to this capability), as well as the electronically managed EHI. Further, by Readers are also referred to the information blocking provision, as to including this functionality in the 2015 Regulatory Impact Analysis in section which readers should refer to sections Base EHR definition, we can be assured XIV of this proposed rule for a VII and VIII of this proposed rule. that health care providers participating discussion of the estimated costs and Similarly, while this certification in the CMS programs (e.g., Promoting benefits of this proposed criterion, as criterion would provide a baseline Interoperability Programs) have well as the impact of the proposed capability for exporting data for the functionality to both support patient removal of the 2015 Edition ‘‘data specific use cases described above, requests for their EHI and switching export’’ criterion. health IT developers may need to health IT systems. 5. Standardized API for Patient and provide other data export and We propose to modify the Base EHR Population Services Criterion conversion services or support definition to include the proposed ‘‘EHI additional export use cases beyond export’’ criterion 24 months from the To implement the Cures Act, we those encompassed by this criterion to effective date of the final rule for this propose to adopt a new API criterion in facilitate the appropriate access, proposed rule (which practically § 170.315(g)(10), which would replace exchange, and use of electronic health speaking would be 25 months because the ‘‘application access—data category information and to avoid engaging in of the 30-day delayed effective date). We request’’ certification criterion information blocking. believe this is sufficient time for health (§ 170.315(g)(8)) and become part of the IT developers to develop, test, certify, 2015 Edition Base EHR definition. This f. Timeframes and rollout this functionality to health new certification criterion would ONC seeks input on EHI export and care providers based on the flexible require the use of FHIR standards, timeframes. In particular, beyond approach offered for meeting this several implementation specifications, exporting all the EHI the health IT criterion. We also believe this timeframe and focus on supporting two types of system produces and electronically provides sufficient time for health care API-enabled services: (1) Services for

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00027 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7450 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

which a single patient’s data is at focus; Module presented for certification due that if a developer attested to encrypting and (2) services for which multiple to the fact that all health IT must meet authentication credentials, a certified patients’ data are at focus. Please refer the ‘‘authentication, access control, and Health IT Module would be subject to to the ‘‘Application Programming authorization’’ certification criterion ONC–ACB surveillance for any potential Interfaces’’ section (VII.B.4) in this adopted in § 170.315(d)(1) as part of non-conformity with the requirements preamble for a more detailed discussion current Program requirements. While of this criterion. Specifically, if the of the ‘‘API’’ certification criterion and the 2015 Edition ‘‘authentication, access ONC–ACB becomes aware of situations related Conditions and Maintenance of control, and authorization’’ certification where the developer’s health IT is not Certification requirements. criterion criteria requires that patient meeting the developer’s affirmative information saved on end user devices attestation per the criterion’s 6. Privacy and Security Transparency is encrypted, those same protections are requirements, the ONC–ACB may use its Attestations not explicitly required through corrective action process to bring the a. Background certification for the authentication product back into conformance. We propose that, for health IT In 2015, the HIT Standards Committee credentials used to access that same certified prior to a subsequent final (HITSC) recommended the adoption of information. As such, we believe that this proposal would address that gap rule’s effective date, the health IT would two new certification criteria for the and encourage health IT developers to need to be certified to the ‘‘encrypt Program. The National Coordinator take steps to ensure that authentication authentication credentials’’ certification endorsed the HITSC recommendations credentials are protected consistent with criterion within six months after the for consideration by the Secretary, and industry best practices. final rule’s effective date. For health IT the Secretary determined that it was To provide clarity as to what a ‘‘yes’’ certified for the first time after the final appropriate to propose adoption of the attestation for ‘‘encrypt authentication rule’s effective date, we propose that the two new certification criteria through credentials’’ would mean, we provide health IT must meet this criterion at the rulemaking (81 FR 10635). To the following explanation. Encrypting time of certification. This should allow implement the Secretary’s authentication credentials could include sufficient time for health IT developers determination, we propose to add two password encryption or cryptographic to assess their Health IT Modules’ new 2015 Edition privacy and security hashing, which is storing only capabilities and attest ‘‘yes’’ or ‘‘no’’ to ‘‘transparency attestation’’ certification encrypted or cryptographically hashed the certification criterion. criteria for: (1) Encrypt authentication passwords. If a developer attests that its For an assessment of this proposal’s credentials; and (2) multi-factor Health IT Module encrypts costs and benefits, please refer to the authentication. authentication credentials, we propose Regulatory Impact Analysis in section In the 2015 Edition final rule, we that the attestation would mean that the XIV of this preamble. We welcome adopted a new, simpler, and Health IT Module is capable of comments on this assessment and this straightforward approach to privacy and cryptographically protecting stored proposal in general. We also note that security (P&S) certification requirements authentication credentials in accordance some health IT presented for for Health IT Modules certified to the with standards adopted in certification is not designed to store 2015 Edition, which we refer to as the § 170.210(a)(2), Annex A: Federal authentication credentials. Therefore, 2015 Edition privacy and security Information Processing Standards (FIPS) we specifically request comment on certification framework (80 FR 62705). Publication 140–2, Approved Security whether we should include an explicit In this proposed rule, we propose Functions for FIPS PUB 140–2, Security provision in this criterion to modifications to the 2015 Edition Requirements for Cryptographic accommodate such health IT. This privacy and security certification Modules. We posit that FIPS Publication could be similar to the approach we framework in § 170.550(h) and propose 140–2 is the seminal, comprehensive, have taken with the 2015 Edition ‘‘end- to add new criteria to which a health IT and most appropriate standard. user device encryption’’ criterion developer would need to certify Moreover, in the specified FIPS 140–2 (§ 170.315(d)(7)(ii)), where we permit pertaining to whether or not its product standard, there is an allowance for the criterion to be met if the health IT encrypts authentication credentials various approved encryption methods, developer indicates their technology is (specifically § 170.315(d)(12)) and and health IT developers would have designed to prevent electronic health supports multi-factor authentication the flexibility to implement any of the information from being locally stored on (specifically § 170.315(d)(13)). To be approved encryption methods in order end-user devices. clear, we are not proposing to require to attest yes to this criterion. Health IT c. Multi-Factor Authentication that health IT have the functionality developers should keep apprised of present to encrypt authentication these standards as they evolve and are We propose to adopt a ‘‘multi-factor credentials or support multi-factor updated to address vulnerabilities authentication’’ (MFA) criterion in authentication. Rather, we propose that identified in the current standard. § 170.315(d)(13) and include it in the a health IT developer indicate whether We do not believe it is necessary for P&S certification framework or not their certified health IT has those a Health IT Module to be required to be (§ 170.550(h)). We propose to make the capabilities by attesting yes or no. tested to this criterion, so long as by ‘‘multi-factor authentication’’ attesting yes to this criterion, the health certification criterion applicable to any b. Encrypt Authentication Credentials IT developer is attesting that if Health IT Module currently certified to We propose to adopt an ‘‘encrypt authentication credentials are stored, the 2015 Edition and any Health IT authentication credentials’’ certification then the authentication credentials are Module presented for certification. criterion in § 170.315(d)(12) and include protected consistent with the Health IT developers have already been it in the P&S certification framework requirements above. To be clear, a ‘‘no’’ implementing MFA to meet the (§ 170.550(h)). We propose to make the attestation is a sufficient response to Electronic Prescribing of Controlled encrypt authentication credentials address this certification criterion; Substances (EPCS) requirements set by certification criterion applicable to any however, health IT developers should Drug Enforcement Administration Health IT Module currently certified to be aware that this ‘‘no’’ will be made (DEA), and if adopted, this certification the 2015 Edition and any Health IT publicly available on the CHPL. Note criterion would be general in that its

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00028 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7451

intended outcome would provide more it is still vulnerable to theft. These whether the MFA solution complies public transparency around the MFA alternative forms of authentication have with industry standard? This capabilities included in certified health their own set of vulnerability issues. information could enable the health IT IT. The cost of implementing MFA and developer to highlight their health IT’s This proposal supports the ensuring it will be implemented in a capabilities to support MFA. Department of Homeland Security way that does not inhibit clinical 7. Data Segmentation for Privacy and (DHS) led initiative ‘‘STOP, THINK, workflow is also an issue to be Consent Management Criteria CONNECT’’ which strongly considered. recommends and runs campaigns to To provide clarity as to what a ‘‘yes’’ We adopted two 2015 Edition ‘‘data promote stronger authentication, attestation for ‘‘multi-factor segmentation for privacy’’ (DS4P) typically related to MFA, going beyond authentication’’ attestation would mean, certification criteria in the 2015 Edition a username and password to log in. we provide the following explanation. final rule. One criterion (‘‘DS4P-send’’ MFA is also recommended by numerous MFA requires users to authenticate (§ 170.315(b)(7)) includes capabilities organizations and groups. In the ‘‘Report using multiple means to confirm they for creating a summary care record on Improving Cybersecurity in the are who they claim to be in order to formatted to the C–CDA 2.1 standard Health Care Industry,’’ 30 the Health prove one’s identity, under the and document-level tagging as restricted Care Industry Cybersecurity Task Force assumption that it is unlikely that an (and subject to restrictions on re- recommended requiring strong unauthorized individual or entity will disclosure) according to the DS4P authentication to improve identity and be able to succeed when more than one standard. The other criterion (‘‘DS4P- access management for health care token is required. MFA includes using receive’’ (§ 170.315(b)(8)) includes workers, patients, and medical devices/ two or more of these: (i) Something capabilities for receiving a summary EHRs. Using a single factor approach to people know, such as a password or a care record formatted to the C–CDA 2.1 accessing information is particularly personal identification number (PIN); standard and document-level tagged as prone to cyber-attack because one factor (ii) something people have, such as a restricted (and subject to restrictions on passwords can be weak, stolen, and are phone, badge, card, RSA token or access re-disclosure) according to the DS4P vulnerable to external phishing attacks, key; and (iii) something people are, such standard. As noted in the 2015 Edition malware, and social engineering threats. as fingerprints, retina scan, heartbeat, final rule (80 FR 62646)), certification to In situations where the provider is and other biometric information. Thus, these criteria is not required to meet the accessing a health IT product or health in order to be issued a certification, we CEHRT definition for CMS EHR information exchange external to the propose to require that a Health IT Incentive Programs, now referred to as hospital or clinical environment, the Module developer attest to whether or the Promoting Interoperability Health Care Industry Cybersecurity Task not its certified health IT supports MFA Programs. The current 2015 Edition Force recommended that the health care consistent with industry recognized DS4P certification criteria specify the industry adopt the NIST SP 800–46 standards (e.g., NIST Special technical capabilities that the health IT guidelines for remote access, including Publication 800–63B Digital must have to apply and recognize the use of two-factor authentication to Authentication Guidelines, ISO 27001). security labels in a summary document ensure a compromised password cannot We propose that, for health IT (C–CDA) such that the recipient of a alone be used to gain access. Promoting certified prior to a subsequent final summary document would be able to the use of MFA and leveraging rule’s effective date, the health IT would recognize the existence of sensitive biometrics, mobile phones, and/or need to be certified to the ‘‘multi-factor elements within the summary document wearables can help to establish a trust authentication’’ certification criterion (80 FR 62646). Security labeling relationship with the patient. within six months after the final rule’s provides a way for computer systems to Additionally, NIST recommends any effective date. For health IT certified for properly handle data passed among personal data, whether self-asserted or the first time after the final rule’s systems, to preserve the condition of validated, require MFA. effective date, we propose that the security, and to enable access control However, despite the benefits of health IT must meet this criterion at the decisions on the information, so that the adopting MFA, we are also aware of time of certification. This should allow information is only accessed by the some of the challenges. Specifically, in sufficient time for health IT developers appropriate entities. The HL7 health care, many providers are resistant to assess their Health IT Modules’ Healthcare Classification System (HCS) to adopt MFA because of the capabilities and attest ‘‘yes’’ or ‘‘no’’ to standard provides a common syntax and inconvenience and loss of time of going the certification criterion. semantics for interoperable security through another step to access the We generally seek comment on labels in health care. The DS4P standard patient’s EHI. Also, MFA has not been whether there is value in adopting the makes use of the HCS specification and deployed very long in the health care proposed ‘‘multi- factor authentication’’ describes a method for applying security setting, so it is not clear how much it criterion. We also solicit comment on labels to HL7 CDA documents to ensure actually addresses the risk. In most the method of attestation and, if the that privacy policies established at a MFA implementations, passwords are health IT developer does attest to record’s source can be understood and still present. In addition to having to supporting MFA, whether we should enforced by the recipient of the record. manage passwords, users also have to require the health IT developer to In the 2015 Edition final rule, we manage an additional layer of security. explain how they support MFA. For noted that the DS4P standard is not Another usability challenge is that example, should the health IT developer restricted to data subject to the federal systems often require different types of be required to identify the MFA regulations governing the MFA, which adds to the complexity and technique(s) used/supported by Confidentiality of Substance Use also may require providers to keep track submitting specific information on how Disorder Patient Records (42 CFR part 2) of tokens. MFA is often recommended it is implemented, including identifying (80 FR 62647). It may be implemented as a solution to password problems, but the purpose(s)/use(s) to which MFA is to support other data exchange use cases applied within their Health IT Module in which compliance with state or 30 https://www.phe.gov/Preparedness/planning/ (such as where in the clinical workflow federal legal frameworks require CyberTF/Documents/report2017.pdf. it is required), and, as applicable, sensitive health information to be tagged

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00029 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7452 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

and segmented (80 FR 62647). We certified to the current 2015 Edition regarding their implementation of the further stated that we offered DS4P certification criteria. In addition, proposed DS4P criteria. We also note certification to these criteria as an initial stakeholders shared with ONC—through the availability of the Electronic step towards the ability of an public forums, listening sessions, and Consent Management Landscape interoperable health care system to use correspondence—that focusing Assessment, Challenges, and technical standards to compute and certification on segmentation to only the Technology report.36 The report persist security labels to permit access, document level does not permit includes suggestions for overcoming use, or disclosure of protected health providers the flexibility to address more barriers associated with implementing information in accordance with granular segmentation needs. electronic consent management, which applicable policies and patient Stakeholders noted that certain provider may be considered for further research preferences. We understood and types, such as providers of pediatric and discussion. care and behavioral health care, are acknowledged additional challenges a. Implementation With the currently using a range of burdensome surrounding the prevalence of Consolidated CDA Release 2.1 unstructured data, sensitive images, and manual workflows in order to meet potential issues around use of sensitive complex use cases for DS4P which are In place of the removed 2015 Edition health information by clinical decision also impacted by state and local laws. DS4P criteria, we propose to adopt new support systems. The adoption of Additionally, stakeholders have DS4P-send (§ 170.315(b)(12)) and DS4P- document level data segmentation for expressed interest in ONC exploring receive (§ 170.315(b)(13)) criteria that structured documents would not solve health IT standards that work with would remain based on the C–CDA and these issues, but we acknowledged it DS4P to support the management of the HL7 DS4P standard. These criteria would help move technology in the consent for sharing documents that would include capabilities for applying direction where these issues could be include security labels such as through the DS4P standard at the document, addressed (80 FR 16841). the use of an API. section, and entry level. We believe this Adoption of the current 2015 Edition Therefore, in consideration of offers more valuable functionality to DS4P criteria was also consistent with stakeholder feedback and our stated providers and patients, especially given earlier HIT Policy Committee (HITPC) policy approach to adopt DS4P the complexities of the landscape of recommendations on the use of DS4P certification criteria on a glide path, we privacy laws for multiple care and technology to enable the electronic propose to remove the current 2015 specialty settings. We believe health IT implementation and management of Edition DS4P-send (§ 170.315(b)(7)) and certified to these criteria could support disclosure policies that originate from DS4P-receive (§ 170.315(b)(8)) multiple practice settings and use cases. the patient, the law, or an organization, certification criteria. The proposed For example, in section VI.A.2 of this in an interoperable manner, so that effective date of removal of these criteria preamble, we explain how the proposed electronic sensitive health information would be the effective date of a capabilities included in these criteria may be appropriately shared.31 These subsequent final rule for this proposed could support the pediatric health care HITPC recommendations consisted of a rule. We propose to replace these two setting. We believe this proposal could glide path for the exchange of 42 CFR criteria with three new 2015 Edition also reduce burden for providers by part 2-protected data starting with the DS4P certification criteria (two for C– leveraging health IT’s ability to inclusion of Level 1 (document level CDA and one for a FHIR-based API) that recognize and manage sensitive data would support a more granular tagging) send and receive functionality. and patient consent directives, rather approach to privacy tagging data and The HITPC also recommended than relying on case-by-case manual consent management for health advancing the exchange of 42 CFR part redaction and subsequent workarounds information exchange supported by 2-protected data, by outlining additional to transmit redacted documents. We either the C–CDA– or FHIR-based capabilities in sharing, viewing and emphasize that health care providers exchange standards. Our primary incorporating privacy restricted data at already have processes and workflows purpose for proposing to remove and a more granular level, as well as to address their existing compliance replace them, in lieu of proposing to managing computable patient consent obligations which could be made more revise them, is to provide clarity to for the use of restricted data.32 efficient and cost effective through the stakeholders as to the additional use of health IT. We recognize that more Since the 2015 Edition final rule, the functionality enabled by health IT health care industry has engaged in granular privacy markings at the point certified to the new criteria. We note of data capture would further support additional field testing and resources released by ONC and OCR, implementation of the DS4P standard. existing and future priorities of states such as the HHS Security Risk for multiple care and specialty settings, As of the beginning of the third quarter Assessment Tool 33 and the Guide to of the 2018 CY, only about 20 products including behavioral health and Privacy and Security of Electronic pediatric health care settings. (products with multiple certified Health Information,34 as well as the versions were counted once) were We welcome public comment on our Office for Civil Rights’ security risk proposals to replace the current 2015 analysis guidance 35 that entities may 31 See HIT Policy Committee (HITPC) Edition DS4P criteria and adopt new Recommendation Letter to ONC, July 2014, http:// employ to make risk-based decisions 2015 Edition DS4P-send www.healthit.gov/facas/sites/faca/files/PSTT_ (§ 170.315(b)(12)) and DS4P-receive _ _ 33 DS4P Transmittal%20Letter 2014-07-03.pdf; see HHS Security Risk Assessment Tool: http:// (§ 170.315(b)(13)) criteria to support also HITPC’s Privacy and Security Tiger Team www.healthit.gov/providers-professionals/security- Public Meeting, Transcript, May 12, 2014, http:// risk-assessment. improved options for data segmentation www.healthit.gov/facas/sites/faca/files/PSTT_ 34 ONC Guide to Privacy and Security of for health care providers engaged in Transcript_Final_2014-05-12.pdf; Public Meeting, Electronic Health Information: http:// complex use cases such as those Transcript, May 27, 2014, http://www.healthit.gov/ www.healthit.gov/sites/default/files/ pdf/privacy/ identified in pediatric care (see also facas/sites/faca/files/PSTT_Transcript_Final_2014- privacy-and-security-guide.pdf. 05-27.pdf. 35 HHS Office for Civil Rights:https:// section VI.A) and behavioral health 32 For more details on the two glide paths for part www.hhs.gov/hipaa/for-professionals/security/ 2-protected data, see http://www.healthit.gov/facas/ guidance/index.html; and https://www.hhs.gov/ 36 https://www.healthit.gov/sites/default/files/ sites/faca/files/PSTT_DS4P_Transmittal%20Letter_ hipaa/for-professionals/security/guidance/ privacy-security/ecm_finalreport_ 2014-07-03.pdf. guidance-risk-analysis/index.html?language=es. forrelease62415.pdf.

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00030 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7453

care, including for opioid use disorder We acknowledge that our proposed SAMHSA created the ‘‘Consent (OUD) (see also section VI.B). implementation specification, the Implementation Guide’’ to support Consent Implementation Guide, is based developers in implementing the FHIR b. Implementation With FHIR Standard on a different version of the FHIR Consent resource to represent patient In collaboration with ONC, the standard (FHIR Standard for Trial Use 3, consent for treatment, research, and Substance Abuse and Mental Health also known as FHIR Release 3) than the disclosure. The Consent Implementation Services Administration (SAMHSA) proposed ‘‘standardized API for patient Guide provides instructions for using developed the Consent2Share and population services’’ criteria the FHIR ‘‘Consent’’ resource to capture application to address the specific (§ 170.315(g)(10)) which is proposed to a record of a health care consumer’s privacy protections of patients with reference just FHIR Release 2. privacy preferences. Implementing an substance use disorders who are Furthermore, we acknowledge that this instance of the FHIR Consent resource covered by the federal confidentiality discrepancy may result in additional based on this guide allows for a patient regulation, 42 CFR part 2. implementation efforts for developers. consent to permit or deny identified Consent2Share is an open source In ideal circumstances, we would have recipient(s) or recipient role(s) to application for data segmentation and proposed a data segmentation and perform one or more actions, regarding consent management. It is designed to consent management standard for APIs the patient’s health information for integrate with existing FHIR systems. that was based on FHIR Release 2 and specific purposes and periods of time. SAMHSA created a FHIR aligned with the ‘‘standardized API for For example the Consent implementation guide (the patient and population services’’ criteria Implementation Guide supports consent Consent2Share Consent Profile Design, management for specific use cases to hereafter referred to as ‘‘Consent proposed in this proposed rule. However, although SAMHSA also permit or deny disclosure based on a Implementation Guide’’) that describes specific law, regulation, or policy under how the Consent2Share (C2S) created a consent implementation guide 38 which the patient consented. The application and associated access based on FHIR Release 2, the guide used the FHIR ‘‘Contract’’ resource to implementation guide uses security control solution uses the FHIR Consent labels as a mechanism for specifying a resource to represent and persist patient represent patient consent directives. It is our understanding that an approach patient’s preferences (e.g., permit consent for treatment, research, or disclosure of EHI labeled ‘‘restricted’’). disclosure.37 The implementation guide based on the ‘‘Contract’’ resource has since been abandoned by the industry in The Consent Implementation Guide provides instructions for using the FHIR provides a much simpler mechanism for Consent resource to capture a record of favor of using the ‘‘Consent’’ resource representing a patient’s consent a health care consumer’s privacy which was introduced in FHIR Release preferences than the old approach based preferences. 3. Moreover, the FHIR Release 2 version As discussed in section VII.B.4 of this of the Consent Implementation Guide on FHIR Release 2 and has undergone proposed rule, we are proposing went through relatively little testing and implementation and pilot testing by policies related to the implementation was never formally implemented SAMHSA’s Consent2Share (C2S) of a standardized API to support the because SAMHSA began developing an application. exchange of health information between update to the guide based on the Our proposal to adopt the version providers and patients and among ‘‘Consent’’ resource in FHIR Release 3. aligned with FHIR Release 3 and the members of a care team. We anticipate Consequently, proposing an FHIR Release 3 standard for this that the proposed 2015 Edition implementation specification based on criterion reflects stakeholder interests ‘‘standardized API for patient and FHIR Release 2 would not have aligned and efforts to support particular use population services’’ certification with the more common implementation cases. C2S enables data segmentation criterion (§ 170.315(g)(10)) will result in of FHIR-based consent directives by the and consent management for disclosure a proliferation of APIs that will enable health care industry. We do not of several discrete categories of sensitive a more flexible and less burdensome anticipate that the initial misalignment health data related to conditions and approach to exchanging EHI. We believe between the proposed API criterion treatments including: Alcohol, tobacco the health care industry can leverage (§ 170.315(g)(10)) and the proposed and substance use disorders (including this API infrastructure to share third DS4P criterion (§ 170.315(g)(11)) opioid use disorder), behavioral health, segmented data in a secure and scalable will pose a significant burden on health HIV/AIDS, and sexuality and manner. Therefore, we propose to adopt IT developers. Further, our proposal to reproductive health. These capabilities a 2015 Edition certification criterion permit health IT developers to support multiple use cases in both ‘‘consent management for APIs’’ in voluntarily implement and use a new primary and specialty care, and § 170.315(g)(11) to support data version of an adopted standard or specifically address priority needs segmentation and consent management implementation specification so long as identified by stakeholders to support through an API in accordance with the such version was approved by the pediatric care. We emphasize that Consent Implementation Guide. National Coordinator for use in health care providers already have Certification to this criterion would be certification through the Standards processes and workflows to address at a health IT developer’s discretion and Version Advancement Process, their existing compliance obligations would indicate that a system is capable discussed in section VII.B.5, would which could be made more efficient and of responding to requests through an enable standards version alignment cost effective through the use of health API for patient consent directives that between these two criteria in the future IT. Finally, given that the FHIR standard include standards-based security as the FHIR standard matures. is modular in nature, and especially labeling. since the ‘‘Consent’’ resource did not 38 The draft Behavioral Health Information exist in FHIR Release 2, we anticipate 37 The draft FHIR IG titled ‘‘Consent2Share FHIR Technologies and Standards (BHITS) FHIR DSTU2 that health IT developers that elect to Profile Design.docx’’ can be accessed through the Consent Implementation Guide can be accessed certify to this criterion would be able to Community- Based Care and Privacy (CBCP) HL7 through the Community-Based Care and Privacy support the Consent Implementation workgroup, within the Package Name titled (CBCP) HL7 workgroup at https://gforge.hl7.org/gf/ ‘‘BHITS_FHIR_Consent_IG,’’ at https:// project/cbcc/frs/?action=FrsReleaseView&release_ Guide along with the API requirements gforge.hl7.org/gf/project/cbcc/frs/. id=1279. specified in ‘‘standardized API for

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00031 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7454 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

patient and population services’’ V. Modifications to the ONC Health IT framework. This has already been (§ 170.315(g)(10)) with modest extra Certification Program incorporated into sub- regulatory effort. guidance, and we propose to codify this A. Corrections 40 We welcome comments on this clarification in regulation. The 1. Auditable Events and Tamper proposal. We specifically seek comment revision was made upon further analysis Resistance of the P&S certification framework and on how the availability of this proposed the applicability of the ‘‘amendments’’ certification criterion might increase the Currently, § 170.315(d)(2), ‘‘auditable events and tamper resistance,’’ includes certification criterion § 170.315(d)(4) to ability to support multiple care health IT capabilities that would not coordination and privacy priorities, a cross- reference to § 170.315(d)(7). However, the cross reference to necessarily have any patient data for including those associated with which a request for an amendment pediatric care; and whether we should § 170.315(d)(7), ‘‘end-user device encryption,’’ does not always apply. We would be relevant. consider other similar API based propose to revise § 170.550(h)(3) to options and resources as standards for 3. View, Download, and Transmit to 3rd apply the § 170.315(d)(7) cross reference Party certification criteria. We also seek as appropriate and exempt comment on whether the misalignment § 170.315(d)(7) when the certificate We propose to remove between the versions of the FHIR scope does not require § 170.315(d)(7) § 170.315(e)(1)(ii)(B) which includes a standard used by our proposed ‘‘consent certification (see § 170.315(d)(2)(i)(C)). cross-reference to § 170.315(d)(2). This management for APIs’’ and Paragraph 170.315(d)(2)(i)(C) is not cross-reference indicates that health IT ‘‘standardized API for patient and applicable for the privacy and security may demonstrate compliance with population services’’ criteria would testing and certification of a Health IT activity history log requirements if it is create excessive burden for developers Module required by § 170.550(h)(3)(iii), also certified to the 2015 Edition and implementers. Specifically, we seek (v), (vii), and (viii). This specific ‘‘auditable events and tamper- comment on if certification to the requirement was intended to be resistance’’ certification criterion ‘‘consent management for APIs’’ should exempted. It would only apply if (§ 170.315(d)(2)). However, we no longer only be available in conjunction with § 170.315(d)(7) was also required for require testing of activity history log when certifying for § 170.315(d)(2). the ‘‘standardized API for patient and privacy and security testing and Therefore, this cross-reference is no population services’’ criteria at such a certification, which it is not under the longer applicable to meet certification time as the criteria are aligned to one aforementioned paragraphs. For example, a developer that is seeking to requirements for the 2015 Edition version of the FHIR standard or if the ‘‘view, download, and transmit to 3rd option to certify to the ‘‘consent certify a Health IT Module to § 170.315(h) will not necessarily have party’’ certification criterion management for APIs’’ should be end-user device encryption features (see (§ 170.315(e)(1)) activity history log allowed for those developers interested § 170.315(d)(7)). As such, certification requirements. in doing so even without current can proceed for the audit log process standards alignment. We note that 4. Integrating Revised and New without the Health IT Module Certification Criteria Into the 2015 SAMHSA is currently pursuing demonstrating that it can record an additional work to expand use cases Edition Privacy and Security encryption status as required by Certification Framework related to data segmentation for privacy § 170.315(d)(2)(i)(C). We have and FHIR compatibility. previously identified this error in Consistent with the 2015 Edition privacy and security certification C. Unchanged 2015 Edition Criteria— guidance and now propose to codify the correction in regulation.39 framework, each certification criterion Program Reference Alignment has a set of appropriate P&S 2. Amendments ‘‘safeguards’’ that must be in place. In In the FY 2019 IPPS/LTCH PPS the 2015 Edition, we required that an proposed rule (83 FR 20516), CMS We propose to revise § 170.550(h) to remove the ‘‘amendments’’ criterion’s ONC–ACB must ensure that a Health IT proposed scoring and measurement application to certain non-applicable Module presented for certification to policies to move beyond the three stages clinical criteria including: ‘‘Drug-drug, any of the certification criteria that fall of meaningful use to a new phase of drug-allergy interaction checks for into each regulatory text ‘‘first level EHR measurement with an increased computerized provider order entry paragraph’’ category of § 170.315 (e.g., focus on interoperability and improving (CPOE)’’ § 170.315(a)(4); ‘‘clinical § 170.315(a)) identified below would be patient access to health information. To decision support’’ § 170.315(a)(9); certified to either Approach 1 reflect this focus, CMS changed the ‘‘drug-formulary and preferred drug list (technically demonstrate) or Approach 2 name of the Medicare and Medicaid checks’’ § 170.315(a)(10); and ‘‘patient- (system documentation). In this EHR Incentive Programs, to the specific education’’ § 170.315(a)(13). proposed rule, we propose to require the Medicare and Medicaid Promoting Health IT Modules presented for new criteria (§ 170.315(d)(12) and Interoperability (PI) Programs. To align certification to these criteria would not (d)(13)) to apply to all § 170.315 with the renaming of the EHR Incentive have to demonstrate the capabilities certification criteria. Therefore, given Programs, we propose to remove required by the 2015 Edition these and the other modifications references to the EHR Incentive ‘‘amendments’’ certification criterion discussed above, we propose to revise Programs and replace them with (§ 170.315(d)(4)), unless the health IT is the P&S certification framework as ‘‘Promoting Interoperability Programs’’ presented for certification to another in the 2015 Edition ‘‘automated criterion that requires certification to 40 https://www.healthit.gov/sites/default/files/ the 2015 Edition ‘‘amendments’’ 2015Ed_CCG_a4-DD-DAI-checks-for-CPOE.pdf, numerator recording’’ criterion in https://www.healthit.gov/sites/default/files/2015ed_ § 170.315(g)(1) and the ‘‘automated criterion under the P&S certification ccg_a9-clinical-decision-support.pdf, https:// measure calculation’’ criterion in www.healthit.gov/sites/default/files/2015Ed_CCG_ 39 https://www.healthit.gov/sites/default/files/ a10-Drug-formulary-PDL-checks.pdf, and https:// § 170.315(g)(2). 2015Ed_CCG_d2-Auditable-events-tamper- www.healthit.gov/sites/default/files/2015Ed_CCG_ resistance.pdf. a13-Patient-specific-ed-resources.pdf.

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00032 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7455

noted in the table below. However, the on finalization of the proposals propose removal of certain 2015 Edition P&S Certification Framework would discussed in section III.B.4, which certification criteria. need to be further updated depending

TABLE 1—PROPOSED 2015 EDITION PRIVACY AND SECURITY CERTIFICATION FRAMEWORK

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

§ 170.315(a)(1), through (2), § 170.315(d)(1) (authentica- For each applicable P&S certification criterion not certified using Approach 1, the (5), through (8), (11), and tion, access control, and health IT developer submits system documentation that is sufficiently detailed to (12). authorization), (d)(2) enable integration such that the Health IT Module has implemented service inter- (auditable events and faces for each applicable P&S certification criterion that enable the Health IT tamper resistance), (d)(3) Module to access external services necessary to meet the requirements of the (audit reports), (d)(4) P&S certification criterion. (amendments), (d)(5) (automatic log-off), (d)(6) (emergency access), and (d)(7) (end-user device encryption). § 170.315(a)(4), (9), (10), § 170.315(d)(1) through and (13). (d)(3) and (d)(5) through (d)(7). § 170.315(b) ...... § 170.315(d)(1) through (d)(3) and (d)(5) through (d)(8) (integrity). § 170.315(c) ...... § 170.315(d)(1) through (d)(3) and (d)(5) *. § 170.315(e)(1) ...... § 170.315(d)(1) through (d)(3), (d)(5), (d)(7), and (d)(9)(trusted connection). § 170.315(e)(2) and (3) ...... § 170.315(d)(1) through (d)(3), (d)(5), and (d)(9) *. § 170.315(f) ...... § 170.315(d)(1) through (d)(3) and (d)(7). § 170.315(g)(7) through § 170.315(d)(1) and (d)(9); (g)(11). and (d)(2) or (d)(10) (au- diting actions on health information). § 170.315(h) ...... § 170.315(d)(1) through (d)(3) *. § 170.315(b) ...... § 170.315(d)(1) through (d)(3) and (d)(5) through (d)(8) (integrity). § 170.315(c) ...... § 170.315(d)(1) through (d)(3) and (d)(5). § 170.315(e)(1) ...... § 170.315(d)(1) through (d)(3), (d)(5), (d)(7), and (d)(9)(trusted connection). § 170.315(e)(2) and (3) ...... § 170.315(d)(1) through (d)(3), (d)(5), and (d)(9).

§ 170.315(a)–(h) Certification Criterion

§ 170.315(a) through (h) Certification Criterion ...... § 170.315(d)(12) § 170.315(a) through (h) Certification Criterion ...... § 170.315(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 the table above is certified to either Approach 1 (technically dem- onstrate) or Approach 2 (systemdocumentation). In addition, we propose that health IT developers seeking certification to any § 170.315 cer- tification criterion for their Health IT Modules attest to whether they encrypt authentication credentials (§ 170.315(d)(12)) and support multi- factor authentication (§ 170.315(d)(13)) We clarify that of the adopted 2015 Edition certification criteria, only the privacy and security criteria specified in § 170.315(g)(1) through (6) are exempt from the 2015 Edition privacy and security certification framework due to the capabilities included in these criteria, which do not impli- cate privacy and security concerns. 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’’ and (e)(2) ‘‘secure messaging.’’ For each of these criteria, a Health IT Module must be separately tested to § 170.315(d)(9) because of the specific capabilities for secure electronic transmission and secure electronic messaging included in each criterion, respectively. We also propose the health IT developers seeking certification to any § 170.315 certification criterion for their Health IT Modules attest to whether they encrypt authentication credentials (§ 170.315(d)(12)) and support multi-factor authentication (§ 170.315(d)(13)) * § 170.315(d)(2)(i)(C) is not required if the scope of the Health IT Module does not have end-user device encryption features.

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00033 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7456 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

B. Principles of Proper Conduct for the National Coordinator may, under consider the facts and make the final ONC–ACBs this provision, approve a conformance determination. method for certification criteria where ONC–ATLs must be accredited by the 1. Records Retention evidence of a valid declaration of NVLAP and seek authorization from We propose to revise the records conformity (e.g., certification) granted ONC to participate in the ONC Health retention requirement in § 170.523(g) to under an external program can be IT Certification Program. ONC–ATLs include the ‘‘life of the edition’’ as well submitted directly to an ONC–ACB to test products against the ONC-approved as 3 years after the retirement of an meet the requirement of that test method for the standards and edition related to the certification of certification criteria. certification criteria identified by the Complete EHRs and Health IT Second, we propose to revise the Secretary using ONC-approved test Module(s). In the 2015 Edition final rule PoPC to clarify that certifications can methods. ONC–ACBs make certification (80 FR 62602), we adopted a records only be issued to Health IT Modules and determinations and conduct retention provision that required ONC– not Complete EHRs. We are proposing surveillance for health IT originally ACBs to retain all records related to the to remove the 2014 Edition from the tested by an ONC–ATL. Based on the certification of Complete EHRs and CFR (see section II.B.2 of this preamble) process that all ONC-ATLs must Health IT Module(s) for the ‘‘life of the and Complete EHR certifications are no undergo, we believe that they are edition’’ plus an additional 3 years, and longer available for certification to the capable of providing accurate test the records would be available to HHS 2015 Edition (80 FR 62608; 79 FR results that should be accepted by any upon request during this period of time. 54443). We propose to remove the ONC–ACB. In the 2015 Edition final rule, the ‘‘life provision that permits the use of test The intent of this proposal is to of the edition’’ was defined as beginning results from National Voluntary ensure that ONC–ATLs are not with the codification of an edition of discriminated against and do not suffer Laboratory Accreditation Program certification criteria in regulation and injury from ONC–ACBs not accepting (NVLAP)-accredited testing laboratories ending when the edition is removed their test results if, in fact, they are in under the Program because the from regulation. We now propose to good standing. This proposal may also regulatory transition period from clarify that HHS has the ability to access prevent harm to health IT developers, NVLAP-accredited testing laboratories certification records for the ‘‘life of the who present their health IT to be tested to ONC–ATLs has expired (81 FR edition,’’ which begins with the by ONC–ATLs and ultimately seek 72447). codification of an edition of certification certification by ONC–ACBs under the criteria in the Code of Federal Third, we propose to remove the Program. These situations may arise if a Regulations through a minimum of 3 provision that permits the certification health IT developer’s ONC–ACB leaves years from the effective date that of health IT previously certified to an the Program or goes out of business. removes the applicable edition from the edition if the certification criterion or This proposal may also prevent Code of Federal Regulations, not solely criteria to which the Health IT situations of preferential business during the 3-year period after removal Module(s) was previously certified have arrangements such as when one from the CFR. not been revised and no new organization is both an ONC–ATL and certification criteria are applicable ONC–ACB and will not enter into a 2. Conformance Methods for because the circumstances that this contract with another organization who Certification Criteria provision seeks to address are no longer is also an ONC–ATL. The Principle of Proper Conduct feasible with certification to the 2015 (PoPC) in § 170.523(h) specifies that Edition. Any Health IT Module 4. Mandatory Disclosures and ONC–ACBs may only certify health IT previously certified to the 2014 Edition Certifications that has been tested by ONC–ATLs and presented for certification to the We propose to revise the PoPC in using tools and test procedures 2015 Edition would have at least one § 170.523(k). We propose to remove approved by the National Coordinator. new or revised 2015 Edition § 170.523(k) (1)(ii)(B) because We propose to revise this PoPC in three certification criteria that would be certifications can only be issued to ways. First, we propose to revise this applicable. For example, the 2015 Health IT Modules and not Complete PoPC to additionally permit ONC–ACBs Edition ‘‘accessibility-centered design’’ EHRs. We are proposing to remove the to certify Health IT Modules that they criterion (§ 170.315(g)(5)) is applicable 2014 Edition from the CFR (see section have evaluated for conformance with to any Health IT Module presented for III.B.2 of this preamble) and Complete certification criteria without first certification to the 2015 Edition. EHR certifications are no longer passing through an ONC–ATL. available for certification to the 2015 3. ONC–ACBs To Accept Test Results However, we propose that such methods Edition (80 FR 62608; 79 FR 54443). We From Any ONC–ATL in Good Standing to determine conformity must first be also propose to revise § 170.523(k)(1)(iii) approved by the National Coordinator. We propose to revise the PoPC for to broaden the section beyond just the This proposal provides valuable ONC–ACBs in order to address business Medicare and Medicaid EHR Incentive Program flexibility and market relationships between ONC–ACBs and Programs (now referred to as Promoting efficiencies for streamlining Health IT ONC–ATLs. To encourage market Interoperability Programs). We propose Module certification, acknowledging the competition, we propose to require to revise the section to include a broad spectrum of evidence of ONC–ACBs to accept test results from detailed description of all known conformance, from laboratory testing any ONC–ATL that is in good standing material information concerning with an ONC–ATL to developer self- under the Program and is compliant additional types of costs or fees that a declaration. This Program flexibility with its ISO 17025 accreditation user may be required to pay to will also allow us to leverage the requirements. However, if an ONC–ACB implement or use the Health IT success we have seen in implementation has concerns about accepting test results Module’s capabilities, whether to meet of our alternative test method process from a certain ONC–ATL, the ONC–ACB provisions of HHS programs requiring where any entity can submit a test would have an opportunity to explain the use of certified health IT or to procedure and/or test tool for approval the potential issues to ONC and NVLAP, achieve any other use within the scope for use under the Program. For example, and on a case-by-case basis, ONC could of the health IT’s certification.

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00034 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7457

We also propose to remove the the Promoting Interoperability manner that would align with other provision in § 170.523(k)(3) that Programs). However, we decided that relevant programs and specific requires a certification issued to a pre- the initial focus of the Program should stakeholder needs. While we never have coordinated, integrated bundle of Health be on supporting the EHR Incentive had intentions to adopt care- or IT Modules to be treated the same as a Programs, which focuses on EHR practice-specific certification tracks, or certification issued to a Complete EHR technology for the ambulatory and additional voluntary program(s), in for the purposes of § 170.523(k)(1), inpatient settings (76 FR 1294). As the parallel to the existing voluntary ONC except that the certification must also Program evolved and the adoption and Health IT Certification Program, we indicate each Health IT Module that is use of certified health IT increased stated that we would welcome the included in the bundle. We propose to significantly, we modified the Program opportunity to work with HHS agencies, remove this provision because pre- in the 2015 Edition final rule to make other agencies, and provider coordinated, integrated bundles are no it more open and accessible to more associations in identifying the longer applicable for certification under types of health IT, including health IT appropriate functionality and Program. that supports various care and practice certification criteria in the Program to We propose to revise § 170.523(k)(4) settings beyond those included in the support their stakeholders (80 FR to clarify that a certification issued to a EHR Incentive Programs (80 FR 62604). 62704). This approach is consistent with Health IT Module based solely on the Our goal was then and is now to support the recommendations by the HITPC. applicable certification criteria adopted the advancement of interoperable health Since the publication of the 2015 by the ONC Health IT Certification IT and to promote health IT Edition final rule, ONC has explored Program must be separate and distinct functionality in care and practice how we might work with the industry from any other certification(s) based on settings across the care continuum (see and with specialty organizations to other criteria or requirements. The also 80 FR 62604). collaboratively advance health IT that intent of this provision, as indicated in ONC’s efforts in the 2015 Edition to supports medical specialties and sites of the Establishment of the Permanent make the Program more open and service. As a result, we have gained Certification Program for Health accessible to other care settings also insight from stakeholders regarding the Information Technology final rule (76 aligned with fall 2013 recommendations burdens associated with establishing a FR 1272), is to ensure that any other from the HIT Policy Committee (HITPC). specific set of required certification certifications an ONC–ACB may issue, The HITPC examined the extension of criteria for all users—which may is separately indicated from the the Program to include functionalities include capabilities not applicable to applicable certification criteria adopted that would benefit settings not covered certain settings of care or specialties. by the ONC Health IT Certification by the EHR Incentive Programs. The Stakeholders have also noted that the Program. HITPC recommended that adoption of a set of required criteria We also propose changes related to considerations regarding functionality without also enabling and incentivizing transparency attestations and should focus on whether the innovation beyond those criteria may limitations in section III.B.5. of this functionality would: have the unintended consequence of preamble. Additionally, we propose stifling progress for that setting. • Advance a national priority or other new PoPCs for ONC–ACBs in Stakeholders noted that the timeline for legislative mandate sections VII.B.5 and VII.D of this testing and certifying to required criteria • Align with existing federal/state preamble. and the subsequent deployment of programs • certification criteria in practice settings C. Principles of Proper Conduct for Utilize the existing technology is not always aligned with standards ONC–ATLs—Records Retention pipeline • updates, the emergence of new We propose to revise the records Build on existing stakeholder support standards, or technological innovation. • Appropriately balance the costs and retention requirement in § 170.524(f) to Finally, stakeholders have urged ONC to include the ‘‘life of the edition’’ as well benefits of a certification program. leverage multiple means to advance as 3 years after the retirement of an Taking into consideration the HITPC interoperability standards that are edition related to the certification of recommendations, ONC’s 2015 Edition widely applicable, to enable and Health IT Module(s). The circumstances focused on the adoption of certification promote innovation that is supported by are the same as in section V.B.1 of this criteria that are standards-based, these standards, and—in collaboration preamble mentioned above, therefore, applicable to a wide variety of care and with stakeholders to monitor and we propose the same revisions for ONC– practice settings, and that advance the support developments in emerging ATLs as we did for ONC-ACBs. structured recording, access, exchange, standards and technologies for specialty and use of health information. ONC has use cases. VI. Health IT for the Care Continuum also encouraged users—including Section 4001(b)(i) of the Cures Act ONC believes health IT should help specialty groups—to continue to work instructs the National Coordinator to promote and support patient care when with developers to innovate, develop, encourage, keep, or recognize, through and where it is needed. This means and deploy health IT in specific clinical existing authorities, the voluntary health IT should help support patient settings in ways that promote safety, certification of health IT under the populations, specialized care, effectiveness, and efficient health care Program for use in medical specialties transitions of care, and practice settings delivery while also reducing burden. and sites of service for which no such across the care continuum. In the In the 2015 Edition final rule we technology is available or where more Permanent Certification Program final stated that we did not intend to develop technological advancement or rule, we clarified that section 3001(c)(5) and issue separate regulatory integration is needed. This provision of of the PHSA provides the National certification ‘‘paths’’ or ‘‘tracks’’ for the Cures Act closely aligns with ONC’s Coordinator with the authority to particular care or practice settings (e.g., ongoing collaborative efforts with both establish a voluntary certification a ‘‘long-term and post-acute care federal partners and stakeholders within program or programs for other types of (LTPAC) certification’’) because it the health care and health IT health IT beyond those which supported would be difficult to independently community to encourage and support the EHR Incentive Programs (now called construct such ‘‘paths’’ or ‘‘tracks’’ in a the advancement of health IT for a wide

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00035 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7458 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

range of clinical settings. These This section outlines our approach to successfully implement these health IT initiatives have included projects implement Section 4001(b) of the Cures solutions in a clinical setting. related to clinical priorities beyond Act, which requires that the Secretary those specifically included in the EHR make recommendations for the A. Health IT for Pediatric Setting Incentive Programs (now called the voluntary certification of health IT for Section 4001(b)(iii) of the Cures Act— Promoting Interoperability Programs) use by pediatric health providers and to ‘‘Health information technology for including efforts in public health, adopt certification criteria to support pediatrics’’ requires that: behavioral health, and long-term and the voluntary certification of health IT • First, that the Secretary, in post-acute care. We further note that for use by pediatric health providers to consultation with relevant stakeholders, these initiatives often include the support the health care of children. To shall make recommendations for the development of non-regulatory be clear, and consistent with past voluntary certification of health IT for informational resources to support the practice, we do not recommend or use by pediatric health providers to specific implementation goal and align propose a ‘‘pediatric-specific track or support the health care of children, and • with the technical specifications already program’’ under the ONC Health IT Second, that the Secretary shall available in the Program for Certification Program. This proposed adopt certification criteria to support certification. To advance these efforts, rule outlines the certification criteria the voluntary certification of health IT we generally consider a range of factors adopted in the 2015 Edition which we for use by pediatric health providers to including: stakeholder input and believe support the certification of support the health care of children. identification of clinical needs and health IT for pediatric care. Finally, it In this proposed rule, we describe our clinical priorities, the evolution and identifies the new and revised criteria approach to stakeholder engagement, adoption of health IT across the care proposed in this rule which we believe the analysis used to develop the continuum, the costs and benefits further support the voluntary recommendations, and the specific associated with any policy or certification of health IT for pediatric certification criteria we believe can implementation strategy related to care care. We have included in the appendix support each recommendation. settings and sites of service, and of this proposed rule a set of technical 1. Background and Stakeholder potential regulatory burden and worksheets that can help inform your Convening compliance timelines. Generally, ONC’s comments on the recommendations, the Over the past ten years, a number of approach can be summarized in three new and revised criteria in the Program parts: initiatives have focused on the • that would also support pediatric care availability and use of effective health First, ONC analyzes existing settings, and the overall approach we certification criteria to identify how IT tools and resources for pediatric care. have herein described. These These have included a number of such criteria may be applicable for worksheets outline the following medical specialties and sites of service. public-private partnerships including • information: efforts between HHS, state agencies, and Second, ONC focuses on the real- • The alignment of each time evaluation of existing and health systems for innovative projects recommendation to the Children’s that range from care coordination emerging standards to determine Model EHR Format 42 as identified by applicability to medical specialties and enterprise solutions to immunization stakeholders (see also Section VI.A.1 sites of service as well as to the broader information systems and to point of care and 2 for further detail on the Children’s care continuum, including the solutions for specialty needs. In order to Model EHR Format and the evaluation of such standards for learn from and build upon these efforts, recommendations). ONC has engaged with stakeholders in inclusion in the ONC Interoperability • The alignment of each Standards Advisory (ISA).41 both the public and private sector recommendation to the 2015 Edition • Third, ONC may work in including other federal, state and local certification criteria and new or revised collaboration with stakeholders to government partners, health care criteria described in this proposed rule support the development of providers engaged in the care of informational resources for medical (see also section VI.A.2.a and b). children, standards development • Potential supplemental items from specialties and sites of service for which organizations, charitable foundations the Children’s Model EHR Format ONC identifies a need to advance the engaged in children’s health care identified by ONC which relate to the effective implementation of certified research, and health IT developers primary recommendation and the health IT. supporting pediatric care settings. We believe this approach provides an related certification criteria. For example, significant work has economical, flexible, and responsive We invite readers to use these worksheets been done by the Agency for Healthcare option for both health care providers to inform public comment on the Research and Quality (AHRQ), CMS, the and the health IT industry, which is also recommendations and criteria described in Health Resources and Services in alignment with the provisions of the Section VI.A.2 specifically as they relate to Administration (HRSA), and pediatric health care use cases. The organizations around the Children’s Cures Act related to burden reduction comments received on these technical and promoting interoperability. We are worksheets through this proposed rule will Model EHR Format (Children’s Format), committed to continuing to work with be used to inform the final recommendations which is critical to any discussion of the stakeholders in this manner to for voluntary certification of health IT criteria pediatric health IT landscape.43 The encourage and advance the adoption of for use in pediatric care. Furthermore, these Children’s Format was authorized by health IT to support medical specialties comments, and the detailed insights received the 2009 Children’s Health Insurance and sites of service, and to help ensure through stakeholder outreach, may inform Program Reauthorization Act that providers have the tools they need the future development of a non-binding (CHIPRA) 44 and developed by AHRQ in to support patients at the point of care informational guide or resource to provide useful information for health IT developers 43 Agency for Health Care Information and and that essential patient health and pediatric care providers seeking to information is available across a care Technology. Health Information Technology. http:// healthit.ahrq.gov/health-it-tools-and-resources/ settings. 42 https://healthit.ahrq.gov/health-it-tools-and- childrens-electronic-health-record-ehr-format resources/pediatric-resources/childrens-electronic- Accessed September, 2017. 41 https://www.healthit.gov/isa/. health-record-ehr-format. 44 Public Law 111–3, section 401.

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00036 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7459

close collaboration with CMS. It was certification for health IT for pediatric recommendation and the related developed to bridge the gap between the care. These include eight certification criteria. functionality present in most EHRs recommendations related to the Priority We invite readers to use these currently available and the functionality List: worksheets to inform public comment that could optimally support the care of • Recommendation 1: Use biometric- on the recommendations, the inclusion children. Specifically, the Children’s specific norms for growth curves and of specific items from the Children’s Format provides information to EHR support growth charts for children. Format, and the identified certification system developers and others about • Recommendation 2: Compute criteria as they relate specifically to use critical functionality and other weight-based drug dosage. cases for pediatric care and sites of requirements that are helpful to include • Recommendation 3: Ability to service. We also seek comment on the in an EHR system to address health care document all guardians and caregivers. following: needs specific to the care of children. • Recommendation 4: Segmented 1. Relevant gaps, barriers, safety The final version of the Children’s access to information. concerns, and resources (including Format,45 released in 2015, consists of • Recommendation 5: Synchronize available best practices, activities, and 47 high priority functional requirements immunization histories with registries. tools) that may impact or support in 19 topic areas that focus on • Recommendation 6: Age- and feasibility of the recommendation in improvements that would better support weight-specific single-dose range practice. the safety and quality of care delivered checking. 2. Effective use of health IT itself in to children. The Children’s Format was • Recommendation 7: Transferrable support of each recommendation as intended as a starting point for access authority. involves provider training, establishing developers, users, and purchasers for • Recommendation 8: Associate workflow, and other related safety and informing an approach for pediatric maternal health information and usability considerations. voluntary certification. We refer to the demographics with newborn. 3. If any of the 10 recommendations Voluntary Edition proposed rule for a We also developed two additional should not be included in ONC’s final description of ONC’s prior discussion recommendations beyond the Priority recommendations for voluntary around the Children’s Format (79 FR List which relate to other items within certification of health IT for pediatric 10930). the Children’s Format that are care. In the summer of 2017, the American considered important to pediatric 4. Any certification criteria from the Academy of Pediatrics (AAP) reviewed stakeholders. These additional Program that is identified for the 10 the 2015 Format using a robust recommendations, which we believe recommendations that should not be analytical process and engagement with may be supported by certified health IT, included to support the specific their members. The result was a are as follows: recommendation. prioritized list of eight clinical priorities • Recommendation 9: Track As stated in the worksheets located in to support pediatric health care incomplete preventative care the appendix, commenters are (‘‘Priority List’’). In October 2017, ONC opportunities. encouraged to reference the specific held a technical discussion with • Recommendation 10: Flag special ‘‘recommendation number’’ (1–10) with stakeholders titled ‘‘Health IT for health care needs. the corresponding technical worksheet Pediatrics’’ with the specific purpose of In order to implement the second part question number in their response. For obtaining input from an array of of Section 4001(b) of the Cures Act for example, ‘‘Recommendation 1— stakeholders in an effort to draw the adoption of certification criteria to Question 3’’. correlations between the pediatric support the voluntary certification of a. 2015 Edition Certification Criteria providers’ clinical priorities identified health IT for use by pediatric health care In order to implement the second part in the Priority List with the detailed providers, we have identified both the of Section 4001(b) of the Cures Act to technical requirements outlined in the 2015 Edition certification criteria and adopt certification criteria to support Children’s Format and the capabilities the new or revised criteria in this the voluntary certification of health IT and standards that could be included in proposed rule that we believe support for use by pediatric health providers to certified health IT. Through this these 10 recommendations for health IT support the health care of children, we collaborative approach, the meeting for pediatric care and sites of service. identified the following 2015 Edition participants identified a set of priority We direct readers to the appendix of certification criteria that support the needs for health IT to support pediatric this proposed rule for a set of technical recommendations. Within the technical care based upon those identified by the worksheets which include a cross-walk worksheets in the appendix of this Priority List and the primary correlation of the various criteria specifically proposed rule, these criteria are noted to the Children’s Format. associated with each recommendation. These worksheets outline the following under each recommendation to which 2. Recommendations for the Voluntary information: they are correlated. The 2015 Edition Certification of Health IT for Use in • criteria are as follows: The alignment of each • Pediatric Care recommendation to the primary ‘‘API functionality’’ criteria To support the first part of Section Children’s Format 46 item identified by (§ 170.315(g)(7)–(g)(9)) which addresses 4001(b) of the Cures Act, ONC stakeholders. many of the challenges currently faced considered the historical efforts on the • The alignment of each by patients and by caregivers such as Children’s Model EHR Format, the input recommendation to the 2015 Edition parents or guardians accessing child’s from stakeholders, and our own certification criteria and new or revised health information, including the technical analysis and review of health criteria described in this proposed rule. ‘‘multiple portal’’ problem, by IT capabilities and standards to develop • Supplemental items from the potentially allowing individuals to a set of recommendations for voluntary Children’s Format for each aggregate health information from multiple sources in a web or mobile application of their choice. 45 https://healthit.ahrq.gov/sites/default/files/ 46 https://healthit.ahrq.gov/health-it-tools-and- • docs/citation/children-ehr-format-enhancement- resources/pediatric-resources/childrens-electronic- ‘‘Care plan’’ criterion final-recommendation-report-abridged.pdf. health-record-ehr-format. (§ 170.315(b)(9)) which supports

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00037 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7460 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

pediatric care by facilitating the making authority of a patient this proposed rule to inform their public documentation of electronic health representative. comment on the recommendations, the information in a structured format to • ‘‘Social, psychological, and inclusion of specific items from the improve care coordination (80 FR behavioral data’’ criterion Children’s Format, and the identified 62648–62649). § 170.315(a)(15) which supports 2015 Edition certification criteria as • ‘‘Clinical decision support’’ (CDS) integration of behavioral health data they relate specifically to use cases for criterion (§ 170.315(a)(9)) which into a child’s record across the care pediatric care and sites of service. supports pediatric care by enabling continuum by enabling a user to record, interventions based on the capture of change, and access a patient’s social, b. New or Revised Certification Criteria biometric data. psychological, and behavioral data in This Proposed Rule • ‘‘Common Clinical Data Set’’ based using SNOMED CT® and LOINC® In order to implement the second part (adopted in (§ 170.315(b)(4) and codes. of Section 4001(b)(iii) of the Cures Act § 170.315(b)(5)) which includes optional • ‘‘Transitions of care’’ criterion to adopt certification criteria to support pediatric vital sign data elements (§ 170.315(b)(1)) which supports the voluntary certification of health including as optional the reference structured transition of care summaries information technology for use by range/growth curve for three pediatric and referral summaries that help ensure pediatric health providers to support the vital signs—BMI percent per LOINC the coordination and continuity of health care of children, we identified identifiers for age per sex, weight per health care as children transfer between new or revised certification criteria in length/sex, and head occipital-frontal different clinicians at different health this proposed rule that support the circumference for children less than care organizations or different levels of recommendations. These new or revised three years of age. care within the same health care criteria and standards in this proposed • ‘‘Data segmentation for privacy’’ organization; rule that would support pediatric send criterion and receive criterion • ‘‘Transmission to immunization settings include: (adopted in § 170.315(b)(7) and registries’’ criterion (§ 170.315(f)(1)) • New API criterion (§ 170.315(g)(10)) § 170.315(b)(8)) which provides the which supports the safe and effective which would serve to implement the ability to: Create a summary record that provision of child health care through Cures Act requirement to permit health is tagged at the document level as immunizations and registry linkages. information to be accessed, exchanged, restricted and subject to re-disclosure; This criterion also provides the ability and used from APIs without special receive a summary record that is to request, access, and display the effort (see section IV.B.5 of this document-level tagged as restricted; evaluated immunization history and proposed rule). separate the document-level tagged forecast from an immunization registry • New ‘‘DS4P’’ criteria (two for C– document from other documents for a patient. Immunization forecasting CDA ((§ 170.315(b)(12)) and received; and, view the restricted recommendations allow for providers to (§ 170.315(b)(13)) and one for FHIR document without having to incorporate access the most complete and up-to-date (§ 170.315(g)(11))) that would support a any of the data from the document. information on a patient’s immunization more granular approach to privacy • ‘‘Demographics’’ criterion history to inform discussions about tagging data for health information (§ 170.315(a)(5)) which supports what vaccines a patient may need based exchange supported by either the C– pediatric care through the capture of on nationally recommended CDA- or FHIR-based exchange standards values and value sets relevant for the immunization recommendations (80 FR (see section VI.A for a discussion of this pediatric health care setting as well as 62662–62664). criteria in relation to pediatric settings allowing for improved patient matching • ‘‘View, download, and transmit to and section VI.B for discussion of these which is a key challenge for pediatric 3rd party’’ (VDT) criterion criteria in relation to Opioid Use care. (§ 170.315(e)(1)) which supports Disorder). • ‘‘Electronic Prescribing’’ criterion transferrable access authority for the • New electronic prescribing (adopted in § 170.315(b)(3)) which pediatric health care setting and certification criterion (§ 170.315(b)(11)), includes an optional Structured and provides the ability for patients (and which would supports improved patient Codified Sig Format, which has the their authorized representatives) 47 to safety and prescription accuracy, capability to exchange weight-based view, download, and transmit their workflow efficiencies, and increased dosing calculations within the NCPDP health information to a 3rd party. configurability of systems including SCRIPT 10.6 standard and limits the We note that some of these criteria functionality that could support ability to prescribe all oral, liquid may be updated based on proposals pediatric medication management. medications in only metric standard contained in this proposed rule; • USCDI (§ 170.213) which enables units of mL (i.e., not cc) important for however, we believe that prior to any the inclusion of pediatric vital sign data enabling safe prescribing practices for such updates, technology that is elements, including the reference range/ children. currently available and certified to these scale or growth curve for BMI percentile • ‘‘Family health history’’ criterion 2015 Edition criteria can make a per age and sex, weight for age per (§ 170.315(a)(12)) which supports significant impact in supporting length and sex, and head occipital- pediatric care because it leverages providers engaged in the health care of frontal circumference (and the criteria concepts or expressions for familial children. We invite readers to use the that include the USCDI). conditions, which are especially technical worksheets in the appendix to Each of these proposed criteria are clinically relevant when caring for further described in other sections of children. 47 The VDT criterion includes a ‘‘patient- this proposed rule; however, in this • authorized representative’’ concept that aligns with ‘‘Patient health information the use of the term under the EHR Incentive section of this proposed rule we capture’’ criterion (§ 170.315(e)(3)) Program. A ‘‘patient-authorized representative’’ is specifically seek comment on the which supports providers’ ability to defined as any individual to whom the patient has application of these criteria to pediatric accept health information from a patient granted access to their health information (see also use cases in support of our 77 FR 13720). However, consent is not needed for or authorized representative. This minors, for whom existing local, state, or federal recommendations for the voluntary criterion could support pediatric care law grants their parents or guardians access (see certification of health IT for pediatric through documentation of decision- also 77 FR 13720). care.

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00038 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7461

For example, our proposal for three additional support for health IT initiatives for substance use disorder new 2015 Edition DS4P certification implementation (see, for example, the and also includes interoperability and criteria (two for C–CDA ONC Patient Engagement Playbook). health IT tools as a key part of the ((§ 170.315(b)(12)) and (§ 170.315(b)(13)) Such a resource could include the response to this crisis. and one for FHIR (§ 170.315(g)(11))) recommendations and certification We believe health IT offers promising could provide functionality to address criteria here identified and synthesize strategies to help medical specialties the concerns of multiple stakeholders in these technical recommendations with and sites of service as they combat a range of specialty use cases— information outside of the Program opioid use disorder (OUD). For including pediatric care settings. In this related to patient safety, usability, example, health IT has the potential to section of this proposed rule, we seek privacy and security, and other key improve adherence to opioid comment specifically related to the considerations for successful prescribing guidelines and physician inclusion of these criteria in our implementation of a health IT system adherence to treatment protocols, to recommendations. Specifically, within a clinical setting. We believe that increase the safety of prescribing for stakeholders have expressed the need the creation of such a resource, in controlled substances, to enhance to—based on the intended recipient of collaboration with clinical and technical clinician access to PDMPs, and to the data—to restrict granular pediatric stakeholders, would help support the expand access to addiction treatment health data at production. We believe advancement of health IT solutions for and recovery support services. these criteria could, for example, help use in pediatric care and pediatric Additionally, through the Program, our enable providers to: settings. We further include additional goal continues to be to improve access • Limit the sharing of reproductive information on prior ONC initiatives to data from disparate sources and help and sexual health data from an EHR in related to health IT for pediatric settings ensure that key data is consistently order to protect the minor’s privacy; as available on our website at available to the right person, at the right • Prevent disclosure of an www.healthit.gov/pediatrics. place, and at the right time across the emancipated minor’s sensitive health care continuum. One component of information, while also permitting a B. Health IT and Opioid Use Disorder advancing that goal is through technical parent or legal guardian to provide Prevention and Treatment—Request for standards for exchanging health consent for treatment; and Information information that form an essential • Segment child abuse information We have identified a need to explore foundation for interoperability. based on jurisdictional laws, which may ways to advance health IT across the ONC has heard from stakeholders have varying information sharing care continuum to support efforts to including policymakers, implementers, requirements for parents, guardians, fight the opioid epidemic. To that health care providers and patient and/or other possible legal purpose, we seek comment in this advocacy groups that additional representatives. proposed rule on a series of questions information is needed to assist in While health care providers should related to health IT functionalities and planning for the effective use of health already have processes and workflows standards to support the effective IT in OUD prevention and treatment. in place to address their existing prevention and treatment of opioid use We additionally recognize stakeholders’ compliance obligations, we recognize disorder (OUD) across patient interest in the new opioid measures that more granular privacy markings at populations and care settings. (Query of PDMP measure and Verify the point of data capture would further We recognize the significance of the Opioid Treatment Agreement measure) support existing and future priorities of opioid epidemic confronting our nation included in CMS’s Promoting pediatric health providers, as well as for and the importance of helping to Interoperability Programs (formerly multiple medical specialties and sites of support health care providers known as the Medicare and Medicaid service. We also recognize that such committed to preventing inappropriate EHR Incentive Programs). These two point of data capture markings can access to prescription opioids and measures support HHS initiatives reduce administrative burden through providing safe, appropriate treatment. related to the treatment of opioid and efficiencies gained in streamlined HHS has a comprehensive strategy to substance use disorders by helping compliance workflows. combat the opioid crisis. It consists of health care providers avoid We invite readers to use the technical five points that are focused on better: inappropriate prescriptions, improve worksheets in the appendix of this Addiction prevention, treatment, and coordination of prescribing amongst proposed rule to support public recovery services; data; pain health care providers, and focus on the comment on the recommendations, the management; targeting of overdose advanced use of certified health IT in inclusion of specific items from the reversing drugs; and research.48 In care coordination for OUD prevention Children’s Format, and the identified support of this strategy, HHS will and treatment (83 FR 41644). proposed new or revised certification improve access to prevention, treatment, In order to support these efforts, in criteria as they relate specifically to use and recovery support services; target the this proposed rule we outline a brief cases for pediatric care and sites of availability and distribution of overview of some key areas of health IT service. overdose-reversing drugs; strengthen implementation that could support OUD However, as discussed, through our public health data reporting and prevention and treatment. These experience and engagement with health collection; support cutting-edge include consideration of current health care providers and health IT developers, research; and advance the practice of IT certification criteria included in the we believe that in some cases pain management. To combat the opioid 2015 Edition, revised or new information resources can aid in crisis, in October 2018, Congress passed certification criteria as outlined in this implementation in clinical settings. In the Substance Use-Disorder Prevention proposed rule, and current health IT the past, ONC has worked that Promotes Opioid Recovery and initiatives underway in the health care collaboratively with federal partners, Treatment (SUPPORT) for Patients and industry or health IT industry which health IT developers, and the health Communities Act. It aims to expand intersect with ONC policy goals. In this care community to support the treatment, recovery, and prevention section of the proposed rule, we request development of non-regulatory public comment specifically from the informational resources that can provide 48 https://www.hhs.gov/opioids/. perspective of how our existing Program

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00039 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7462 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

requirements and proposals in this organization. This criteria supports the coordination and lead to the rulemaking may support use cases ability to transmit a summary care identification of appropriate social related to OUD prevention and record to support an individual with supports and community resources. treatment and if there are additional OUD upon discharge from an inpatient We seek comment on how these areas that ONC should consider for setting or from a primary care provider criteria and what additional 2015 effective implementation of health IT- to another setting for their care. Edition certification criteria may be enabled OUD prevention and treatment. • The ‘‘clinical information considered a clinical and We seek comment from this perspective reconciliation and incorporation’’ interoperability priority for supporting on the identification of 2015 Edition criterion (§ 170.315(b)(2)) allows OUD treatment and prevention. We also certification criteria, the proposals for clinicians to reconcile and incorporate seek comment on the value of revised or new certification criteria, and patient health information sent from developing a potential future non- the potential future consideration of external sources to maintain a more binding informational guide or resource emerging technologies described in accurate and up-to-date patient record. to provide useful information for OUD various initiatives. This process could help—for example— providers and sites of service related to reduce opioid related errors regarding specific clinical priorities and use cases 1. 2015 Edition Certification Criteria patients who use multiple pharmacies, of focus. We seek public comment on how the have co-morbidity factors, and visit 2. Revised or New 2015 Edition existing 2015 Edition certification multiple clinicians. criteria as well as proposals within this • The ‘‘electronic prescribing’’ Certification Criteria in This Proposed proposed rule for revised or new criteria criterion (§ 170.315(b)(3)) provides a Rule support OUD prevention and treatment. way to write and transmit prescription This proposed rule contains Specifically, we seek comment on information electronically. This additional proposals to revise or add certification criteria previously adopted criterion facilitates appropriate opioid new criteria to the Program to better in the 2015 Edition that can support prescribing by simplifying the review of support care across the continuum. We clinical priorities, advance prescription information during follow- believe these criteria and standards, interoperability for OUD (including care up visits or transitions to other highlighted below, can also support coordination and the effective use of clinicians, by allowing prescribers to treatment and prevention of OUD. We health IT for the treatment and communicate prescription-related seek comment specifically on the prevention of OUD). In this proposed messages to pharmacies electronically applicability of these criteria to the OUD rule, we summarize some of these 2015 and by capturing and transmitting use case. They are: Edition certification criteria identified medication histories that are shared • USCDI: As detailed in section and indicate how they support care with PDMPs. In this proposed rule, we IV.B.1, we are proposing to adopt the coordination, the prevention of OUD propose to update the existing USCDI as a standard (§ 170.213) which and overdose, and the detection of electronic prescribing certification would establish a minimum set of data opioid misuse, abuse, and diversion. criterion as described in section IV.B.2 classes (including structured data fields) We have also below identified the of this proposed rule. that are required to be interoperable proposals for revised or new 2015 • The ‘‘patient health information nationwide, and is designed to be Edition criteria within this proposed capture’’ (§ 170.315(e)(3)) allows expanded in an iterative and predictable rule that we believe can support clinical clinicians to incorporate unstructured way over time. The USCDI Version 1 priorities, advance interoperability for patient generated health data or data (USCDI v1) builds upon the 2015 OUD (including care coordination and from a non-clinical setting into a patient Edition CCDS and includes a common also the effective use of health IT for the record. The CMS Promoting set of data classes that can be supported treatment and prevention of OUD). We Interoperability Programs for eligible by commonly used standards. It welcome input from stakeholders hospitals includes a new optional includes the 2015 Edition CCDS data specifically on these criteria within the measure which is focused on verifying elements, such as medications. It also context of OUD prevention and the existence of a signed Opioid includes two new data classes, titled treatment, as well as input on the Treatment Agreement for certain ‘‘clinical notes’’ and ‘‘provenance,’’ identification of other criteria included patients when a controlled substance is which would help facilitate either in the 2015 Edition and/or that prescribed and incorporating it into the interoperable exchange and the are proposed in other parts of this rule record. In the Hospital Inpatient trustworthiness of the data being that may be considered a clinical and Prospective Payment Systems final rule, exchanged. These enhancements to the interoperability priority for supporting CMS recognized this certification comprehensiveness and reliability of the OUD treatment and prevention. criterion’s potential to support this goal data being exchanged could help We have identified several 2015 within a certified health IT system (83 empower physicians in the prevention Edition certification criteria available FR 41654). and detection of opioid misuse, abuse, now for certification in the Program • The ‘‘social, psychological, and and diversion. which could support care coordination behavioral data’’ criterion In addition, because we propose to and the prevention and detection of (§ 170.315(a)(15)) can help to provide a adopt the USCDI as a standard, health opioid misuse, abuse, and diversion. more complete view of a patient’s IT developers would be allowed to take They are: overall health status. This is important advantage of the Maintenance of • The ‘‘transitions of care’’ criterion to help provide a ‘‘whole-patient’’ Certification requirements described in (§ 170.315(b)(1)) supports structured approach to the treatment of substance section VII.B.5 of this proposed rule. transition of care summaries and referral use disorders included as part of Therefore, the USCDI would have the summaries that help ensure the Medicated-Assisted Treatment (MAT) potential to further benefit clinical coordination and continuity of health that involves the use of FDA-approved priorities and interoperability for OUD, care as patients transfer between medications, in combination with including safe and appropriate opioid different clinicians at different health counseling and behavioral therapies, to prescribing, through the ability to care organizations or different levels of treat individuals recovering from OUD. voluntarily implement and use a new care within the same health care This data can help to improve care version of an adopted standard or

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00040 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7463

implementation specification so long as efficiencies, reduce testing acknowledged that ‘‘not all states have certain conditions are met, including requirements, and increase adopted the guideline, not all the new version being approved by the configurability of systems. This new physicians are aware of them, and National Coordinator for use in proposed criterion includes the addition sound opioid prescribing guidelines are certification through the Standards of Risk Evaluation and Mitigation far from universally followed.’’ Clinical Version Advancement Process. We seek Strategy (REMS) messages. We believe decision support (CDS) Hooks is a comment on how this proposal would this proposal would help address health IT specification that has the further support the access, exchange, challenges discussed in the CMS potential to positively affect prescriber and use of additional and future data Hospital Inpatient Prospective Payment adoption of evidence-based prescribing classes (including structured data fields) Systems final rule (83 FR 41651) and guidelines by invoking patient-specific in more care and practice settings Medicare Physician Fee Schedule clinical support from within the specifically as related to the prevention proposed rule (83 FR 35704) by clinician’s EHR workflow. ONC is and treatment of OUD. strengthening clinical and currently collaborating with CDC on a • Standardized API: We are administrative efficiency, helping move project to translate the CDC guideline proposing new API functionality the industry forward by adopting more into standardized, shareable, through the adoption of a new API current standards for electronic computable decision support artifacts certification criterion (§ 170.315(g)(10)), prescribing, and harmonizing efforts using CDS Hooks. We recognize that which serves to implement the Cures across federal agencies in the prevention CDS Hooks is still an emerging Act requirement to permit health and treatment of OUD. In addition, the technology and seek input on the information to be accessed, exchanged, FDA has enacted an opioids adoption of the CDS Hooks specification and used from APIs without special medications REMS program for opioid for opioid prescribing and OUD effort. This criterion would enable analgesics 49 mandating prescriber and prevention and treatment. We also efficient exchange of health information patient education to encourage proper request public comment on other health using modern internet technologies and patient screening and appropriate IT solutions and effective approaches to thus enable collaborative, patient- monitoring. Adoption of the new improve opioid prescription practices driven, integrated care for individuals proposed criterion also supports the and clinical decision support for OUD. recovering from OUD. efficient and accurate exchange of • Care Plan FHIR Resource: A shared • Data Segmentation for Privacy and medication history transactions between care plan is a critical concept for Consent Management: As discussed in providers and pharmacies, and between managing an individual’s health across section IV.B.7, we are also proposing to pharmacies and state PDMPs. a continuum that includes both clinical remove the current 2015 Edition DS4P— and non-clinical settings 52 and can help send (§ 170.315(b)(7)) and DS4P— 3. Emerging Standards and Innovations enable more informed and useful receive (§ 170.315(b)(8)) certification In addition to the certification criteria connections among all the stakeholders criteria. We propose to replace these established in the 2015 Edition final engaged in preventing or treating OUD. two criteria with three new 2015 Edition rule and proposed in this rule, ONC is For those in recovery from OUD, the DS4P certification criteria (two for C– engaged in a number of health IT and care plan can enable patients to access CDA ((§ 170.315(b)(12)) and standards initiatives exploring their care plan information and (§ 170.315(b)(13)) and one for FHIR innovation and emerging standards to coordinate their care with approved (§ 170.315(g)(11))) that would support a inform future health IT policy. In some community care providers which is more granular approach to privacy cases, these efforts may not be mature critical and part of evidence-based tagging data for health information enough or best suited for adoption in recovery treatment services. In 2015, the exchange supported by either the C– the Program; however, we seek ONC HITPC recommended that the CDA- or FHIR-based exchange comment on the potential consideration National Coordinator accelerate the standards. We believe this proposal of these initiatives for future direction of implementation of dynamic, shared, would offer functionality that is more ONC policy. longitudinal care plans that incorporate valuable to providers and patients, • CDS Hooks: Improving how opioids information from both clinical and non- especially given the complexities of the are prescribed through evidence-based clinical services and empower privacy law landscape for multiple care guidelines can ensure patients have individuals to manage their own health and specialty settings. We also believe access to safer, more effective chronic and care.53 A consideration for HHS as this proposal could lead to more pain treatment while reducing the risk part of this earlier recommendation complete records, contribute to patient of opioid misuse, abuse, or overdose included looking at the future standards safety, and enhance care coordination. from these drugs. In response to the development needed to transition from Additionally, we believe this proposal critical need for consistent and current the static care plan documentation may support a more usable display of opioid prescribing guidelines, the (document template in C–CDA R2.1) to OUD information at the request of Centers for Disease Control and a dynamic shared care plan that patients within an EHR and we invite Prevention (CDC) released the Guideline supports more robust care input on best practices, including the for Prescribing Opioids for Chronic coordination.54 We believe HL7 processes and methods by which OUD Pain.50 While progress has been made in standards and standardized APIs can information should be displayed. training prescribers and fostering the elevate care coordination and care • Electronic Prescribing and PDMPs: adoption of the CDC guideline, the management across the continuum, As discussed in section IV.B.2, we are President’s Opioid Commission 51 proposing to remove the current 2015 52 https://www.healthit.gov/hitac/events/policy- Edition electronic prescribing 49 https://www.fda.gov/Drugs/DrugSafety/ advanced-health-models-and-meaningful-use- certification criterion (§ 170.315(b)(3)) InformationbyDrugClass/ucm163647.htm. workgroup-8. and replace this criterion with a new 50 Guideline for Prescribing Opioids for Chronic 53 https://www.healthit.gov/sites/default/files/ electronic prescribing certification Pain: https://www.cdc.gov/mmwr/volumes/65/rr/ facas/HITPC_AHM_Hearing_Transmittal_08-11- rr6501e1.htm. 2015_0.pdf. criterion (§ 170.315(b)(11)) that would 51 President’s Opioid Commission: https:// 54 https://www.healthit.gov/hitac/events/policy- support improved patient safety and www.whitehouse.gov/sites/whitehouse.gov/files/ advanced-health-models-and-meaningful-use- prescription accuracy, create workflow images/Final_Report_Draft_11-1-2017.pdf. workgroup-8.

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00041 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7464 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

including for those providers without allows a prescriber to request a patient’s they should adopt the NCPDP SCRIPT EHRs, whether for opioid use disorder medication history from a state PDMP 2017071 standard to facilitate future related treatment, primary health, or via the RxHistoryRequest and reporting of the proposed Query of other problems. Indeed, numerous RxHistoryResponse. ONC is also PDMP quality measure. As noted in the efforts are underway within HL7 and working to enhance the ISA to make it Hospital Inpatient Prospective Payment other collaborations to standardize ‘‘care easier for stakeholders to find standards Systems final rule, a few commenters plans’’ and their content using FHIR and and implementation specifications supported the use of NCPDP Script the C–CDA. From a technical related to high-priority use cases, such Standard Implementation Guide Version perspective and in the context of the as OUD/SUD. The ISA has a comment 2017071 medication history transactions proposals focused on the USCDI process that occurs each year 56 and we for PDMP queries and response. standard, the ARCH standard, the new encourage stakeholders to participate in Additionally, CMS encourages advances proposed API certification criterion at that process to comment on other in standards and their use to deliver 170.315(g)(10), and the voluntary standards and implementation innovative, interoperable solutions that Standards Version Advancement specifications that currently exist in the will seamlessly integrate PDMP query Process Maintenance of Certification ISA or that the industry and its functionality into clinician-friendly, requirement described in section VII.B.5 stakeholders feel should be added to the patient- centered CEHRT-enabled of this proposed rule, we can see a ISA that support OUD/SUD prevention, workflows that facilitate safer, more future where a (g)(10)–certified API treatment, monitoring, and care informed prescribing practices and would be capable of supporting care coordination. improved patient outcomes (83 FR plan data. We request public comment 4. Additional Comment Areas 41651). on the current maturity of existing and We seek comment on how successful forthcoming technical specifications to We further seek comment on effective implementation of health IT that support care plan/care plan data as well approaches for the successful supports OUD can aid in the as specific information that could be dissemination and adoption of achievement of national and prioritized within a future USCDI data standards including the NCPDP SCRIPT programmatic goals, especially where class focused on care plans. 2017071 standard (see section IV.B.2) they may align with initiatives across In addition to commenting on the that can support the exchange of PDMP HHS and with stakeholder and industry criteria noted in this section, we also data for integration into EHRs and also led efforts. enable further adoption and use of encourage stakeholders to participate in Finally, we seek comment on a topic 55 Electronic Prescribing of Controlled the ISA process. The ISA represents that involves health IT for both pediatric Substances (EPCS). Regarding the model by which ONC coordinates care and OUD prevention and integration of health IT with PDMPs and the identification, assessment, and treatment—Neonatal Abstinence EPCS, we believe there are real and public awareness of interoperability Syndrome (or NAS). In its September perceived challenges and opportunities standards and implementation 2018 report, Facing Addiction in that involve policy and technical specifications. ONC encourages all America: The Surgeon General’s components. As we explore these issues stakeholders to implement and use the Spotlight on Opioids, the HHS Office of in collaboration with industry and standards and implementation the Surgeon General describes how the stakeholders, we seek comment on the specifications identified in the ISA as incidence of Neonatal Abstinence priority challenges and opportunities for applicable to the specific Syndrome (or NAS), has increased these topics and on any technical and interoperability needs they seek to dramatically in the last decade along policy distinctions, as appropriate. address and encourages pilot testing and with increased opioid misuse. other industry experience adopting We also note that there are many federal initiatives separate from ONC Newborns may experience NAS, a standards and implementation withdrawal syndrome, following specifications identified as ‘‘emerging’’ proposed rulemaking and the Program that exist within HHS programs exposure to drugs while in the mother’s in the ISA. The web-based version of the womb. NAS is an expected and treatable ISA documents known limitations, including, but not limited to, CMS Medicaid and Medicare programs. For condition following repeated maternal preconditions, and dependencies, and substance use and abuse during provide suggestions for security best example, Medicare now provides separate payment for psychiatric pregnancy, which may have long-term practices in the form of security patterns health consequences for the infant. for referenced standards and collaborative care model/behavioral health integration and chronic care Immediate newborn NAS signs implementation specifications when include neurological excitability, they are used to address a specific management services (see 81 FR 80233, and 80247), and Medicaid issued gastrointestinal dysfunction, and clinical health IT interoperability need. autonomic dysfunction. Newborns with Additionally, through the ISA guidance on leveraging technology to NAS are more likely than other babies process, stakeholders are encouraged to address the opioid crisis at enhanced to have low birthweight and respiratory comment on the outlined standards and funding matches 56 and also includes complications. ONC believes the implementation specifications, as ONC SUD health IT in standard terms and pediatric clinical health IT updates the ISA regularly. ONC has conditions as part of 1115 waiver recommendations proposed in this rule developed and has plans to develop requirements. (including Priority 8, which includes further ISA content to highlight In addition, CMS sought comment for the linkage of health data in records of standards and implementation consideration through separate the mother and newborn) are important specifications that support the rulemaking in both the 2019 Physician for supporting newborns at birth and as prevention and treatment of OUD/ Fee Schedule proposed rule (83 FR they grow and receive care in various substance use disorder (SUD). For 35923) and Hospital Inpatient settings. As such, we invite comment example, the NCPDP SCRIPT standard Prospective Payment Systems proposed rule (83 FR 20528) regarding whether on: • 55 To learn more about, and/or participate in, the The effective use of health IT itself ISA process, please visit https://www.healthit.gov/ 56 https://www.medicaid.gov/federal-policy- in support of the NAS use case as isa/. guidance/downloads/smd18006.pdf. involves provider training, establishing

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00042 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7465

workflow, and other related safety and establish clear baseline technical and Maintenance of Certification under the usability considerations. behavior Conditions of Certification Program, provide assurances to the • Existing and potential tools, such as requirements with evidence that the Secretary, unless for legitimate purposes decision support or clinical quality Conditions of Certification are specified by the Secretary, that it will measurement, for supporting children continually being met through the not take any action that constitutes with NAS and on the specific data Maintenance of Certification information blocking as defined in elements related to the care of these requirements. section 3022(a) of the PHSA, or any children and use of these tools in other action that may inhibit the practice. B. Provisions appropriate exchange, access, and use of • Identification of any related criteria 1. Information Blocking electronic health information (EHI). We and the respective corresponding propose to implement this Condition of The Cures Act requires that a health proposed pediatric recommendation for Certification and accompanying IT developer, as a Condition and the voluntary certification of health IT Maintenance of Certification Maintenance of Certification under the for use in pediatric care that supports requirements in § 170.402. As a Program, not take any action that the NAS use case including but not Condition of Certification requirement, constitutes ‘‘information blocking’’ as limited to recommendation number 8 a health IT developer must comply with defined in section 3022(a) of the PHSA noted above. the Condition as recited here and in the We welcome public comment on (see 3001(c)(5)(D)(i) of the PHSA). We Cures Act. We refer readers to section these health IT policies, functionalities propose to establish this information VIII of this proposed rule for the and standards to support providers blocking Condition of Certification in proposed reasonable and necessary engaged in the treatment and prevention § 170.401. The Condition of activities specified by the Secretary, of OUD. Certification prohibits any health IT which constitute the exceptions to the developer under the Program from information blocking definition. VII. Conditions and Maintenance of taking any action that constitutes Certification We also propose to establish more information blocking as defined by specific Conditions and Maintenance of Section 4002 of the Cures Act requires section 3022(a) of the PHSA and Certification requirements for a health the Secretary of HHS, through notice proposed in § 171.103. IT developer to provide assurances that and comment rulemaking, to establish We clarify that this proposed it does not take any action that may Conditions and Maintenance of ‘‘information blocking’’ Condition of inhibit the appropriate exchange, Certification requirements for the Certification and its requirements would access, and use of EHI. These proposed Program. Specifically, health IT be substantive requirements of the requirements serve to provide further developers or entities must adhere to Program and would use the definition of clarity under the Program as to how certain Conditions and Maintenance of ‘‘information blocking’’ established by health IT developers can provide such Certification requirements concerning section 3022(a) of the PHSA and as also broad assurances with more specific information blocking; appropriate proposed in § 171.103, as it relates to actions. exchange, access, and use of electronic health IT developers of certified health health information; communications IT. In addition to ONC’s statutory a. Full Compliance and Unrestricted regarding health IT; application authority for this Condition of Implementation of Certification Criteria programming interfaces (APIs); real Certification, the HHS Office of the Capabilities world testing for interoperability; Inspector General (OIG) has both We propose, as a Condition of attestations regarding certain Conditions investigatory and enforcement authority Certification, that a health IT developer and Maintenance of Certification over information blocking and may must ensure that its health IT certified requirements; and submission of issue civil money penalties for under the ONC Health IT Certification reporting criteria under the EHR information blocking conducted by Program (Program) conforms to the full reporting program. health IT developers of certified health scope of the certification criteria to IT, health information networks and which its health IT is certified. This has A. Implementation health information exchanges. OIG may always been an expectation of ONC and To implement Section 4002 of the also investigate health care providers for users of certified health IT and, Cures Act, we propose an approach information blocking for which health importantly, a requirement of the whereby the Conditions and care providers could be subject to Program. We believe, however, that by Maintenance of Certification express disincentives. incorporating this expectation and both initial requirements for health IT We refer readers to section VII.D of requirement as a Condition of developers and their certified Health IT this proposed rule for additional Certification under the Program, there Module(s) as well as ongoing discussion of ONC’s enforcement of this would be assurances, and requirements that must be met by both and other proposed Conditions and documentation via the ‘‘Attestations’’ health IT developers and their certified Maintenance of Certification Condition and Maintenance of Health IT Module(s) under the Program. requirements. We also refer readers to Certification requirements proposed in If these requirements are not met, then section VIII of this proposed rule for our § 170.406, that all health IT developers the health IT developer may no longer proposals to implement the information fully understand their responsibilities be able to participate in the Program blocking provisions of the Cures Act, under the Program, including not to take and/or its certified health IT may have including proposed § 171.103. any action with their certified health IT its certification terminated. We propose We do not, at this time, propose any that may inhibit the appropriate to implement each Cures Act Condition associated Maintenance of Certification exchange, access, and use of EHI. To of Certification with further specificity requirements for this Condition of this point, certification criteria are as it applies to the Program. We also Certification. designed and issued so that certified propose to establish the Maintenance of health IT can support interoperability Certification requirements for each 2. Assurances and the appropriate exchange, access, Condition of Certification as standalone The Cures Act requires that a health and use of electronic health requirements. This approach would IT developer, as a Condition and information.

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00043 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7466 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

We propose that, as a complementary electronically manages EHI must certify requirements, including certification Condition of Certification, health IT health IT to the 2015 Edition ‘‘electronic criteria and Conditions of Certification. developers of certified health IT must health information export’’ certification We believe that 10 years is an provide an assurance that they have criterion in § 170.315(b)(10). We discuss appropriate period of time given that made certified capabilities available in the proposed ‘‘electronic health many users of certified health IT ways that enable them to be information (EHI) export’’ criterion in participate in various CMS programs, as implemented and used in production section IV.B.4 of this proposed rule. well as other programs, that require environments for their intended Further, as a Maintenance of similar periods of records retention. We purposes. More specifically, developers Certification requirement, we propose also refer readers to section VII.D.3.c of would be prohibited from taking any that a health IT developer that produces this preamble for additional discussion action that could interfere with a user’s and electronically manages EHI must of records access to information ability to access or use certified provide all of its customers of certified necessary to enforce the Conditions and capabilities for any purpose within the health IT with health IT certified to the Maintenance of Certification. scope of the technology’s certification. functionality included in In an effort to reduce administrative Such actions may inhibit the § 170.315(b)(10) within 24 months of a burden, we also propose, that in appropriate access, exchange, or use of subsequent final rule’s effective date or situations where applicable certification EHI and are therefore contrary to this within 12 months of certification for a criteria are removed from the Code of proposed Condition of Certification and health IT developer that never Federal Regulations before the 10 years the statutory provision that it previously certified health IT to the have expired, records must only be kept implements. While such actions are 2015 Edition, whichever is longer. for 3 years from the date of removal for already prohibited under the Program Consistent with these proposals, we also those certification criteria and related (80 FR 62711), making these existing propose to amend § 170.550 to require Program provisions unless that requirements explicit would ensure that that ONC–ACBs certify health IT to the timeframe would exceed the overall 10- health IT developers are required to proposed 2015 Edition ‘‘EHI export’’ year retention period. This ‘‘3-year from attest to them on a regular basis when the health IT developer of the the date of removal’’ records retention pursuant to the Condition of health IT presented for certification period also aligns with the records Certification proposed in § 170.406, produces and electronically manages retention requirements for ONC–ACBs which will in turn provide additional EHI. and ONC–ATLs under the Program. assurances to the Secretary that As discussed in section IV.C.1 of this We encourage comment on these developers of certified health IT support proposed rule, the availability of the proposals and whether the proposed and do not inhibit appropriate access, capabilities in the proposed 2015 requirements can provide adequate exchange, or use of EHI. Edition ‘‘EHI export’’ certification assurances that certified health IT By way of example, actions that criterion to providers and patients developers are demonstrating initial and would violate this aspect of the would promote access, exchange, and ongoing compliance with the proposed Condition include failing to use of EHI to facilitate health care requirements of the Program; and fully deploy or enable certified providers in switching practices and thereby ensuring that certified health IT capabilities; imposing limitations health IT systems and patients’ can support interoperability, and (including restrictions) on the use of electronic access to all their health appropriate exchange, access, and use of certified capabilities once deployed; or information stored by a provider. As EHI. requiring subsequent developer such, health IT developers with health d. Trusted Exchange Framework and the assistance to enable the use of certified IT certified to the proposed 2015 Common Agreement—Request for capabilities, contrary to the intended Edition ‘‘EHI export’’ certification Information uses and outcomes of those capabilities criterion that is made available to its (see 80 FR 62711). The Condition would customers provides assurances that the The Cures Act added section also be violated were a developer to developer is not taking actions that 3001(c)(9) to the PHSA, which requires refuse to provide documentation, constitute information blocking or any the National Coordinator to work with support, or other assistance reasonably other action that may inhibit the stakeholders with the goal of developing necessary to enable the use of certified appropriate exchange, access, and use of or supporting a Trusted Exchange capabilities for their intended purposes EHI. Framework and a Common Agreement (see 80 FR 62711). More generally, any (collectively, ‘‘TEFCA’’) for the purpose c. Records and Information Retention action that would be likely to of ensuring full network-to-network substantially impair the ability of one or We propose that, as a Maintenance of exchange of health information. Section more users (or prospective users) to Certification requirement, a health IT 3001(c)(9)(B) outlines a process for implement or use certified capabilities developer must, for a period of 10 years establishing a TEFCA between health for any purpose within the scope of beginning from the date of certification, information networks (HINs)—including applicable certification criteria would retain all records and information provisions for the National Coordinator, be prohibited by this Condition (see 80 necessary that demonstrate initial and in collaboration with the NIST, to FR 62711). Such actions may include ongoing compliance with the provide technical assistance on imposing limitations or additional types requirements of the ONC Health IT implementation and pilot testing of the of costs, especially if these were not Certification Program. In other words, TEFCA. In accordance with section disclosed when a customer purchased records and information should be 3001(c)(9)(C), the National Coordinator or licensed the certified health IT (see retained starting from the date a shall publish the TEFCA on its website 80 FR 62711). developer first certifies health IT under and in the Federal Register, as well as the Program and applies separately to annually publish on its website a b. Certification to the ‘‘Electronic Health each unique Health IT Module (or directory of the HINs that have adopted Information Export’’ Criterion Complete EHR, as applicable) certified the Common Agreement and are capable We propose, as a Condition of under the Program. This retention of of trusted exchange pursuant to the Certification requirement, that a health records is necessary to verify health IT Common Agreement. The process, IT developer that produces and developer compliance with Program application, and construction of the

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00044 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7467

TEFCA are further outlined in section inhibit the appropriate exchange, to limit the sharing of information about 3001(c)(9)(D), including requiring that access, and use of EHI. For more their products. As such, we propose to the Secretary shall through notice and information on the Trusted Exchange allow developers to impose prohibitions comment rulemaking, establish a Framework and Common Agreement, or restrictions on protected process for HINs that voluntarily adopt please visit: https://www.healthit.gov/ communications in certain narrowly the TEFCA to attest to such adoption. topic/interoperability/trusted-exchange- defined circumstances. In order for a We request comment as to whether framework-and-common-agreement. prohibition or restriction on a protected certain health IT developers should be In consideration of this request for communication to be permitted, we required to participate in the TEFCA as comment, we welcome comment on the propose that it must pass a two-part test. a means of providing assurances to their certification criteria we have identified First, the communication that is being customers and ONC that they are not as the basis for health IT developer prohibited or restricted must not fall taking actions that constitute participation in the Trusted Exchange within a class of communication about information blocking or any other action Framework and adherence to the which no restriction or prohibition that may inhibit the appropriate Common Agreement, other certification would ever be legitimate or exchange, access, and use of EHI. We criteria that would serve as a basis for reasonable—such as communications would expect that such a requirement, health IT developer participation in the required by law, made to a government if proposed in a subsequent rulemaking, Trusted Exchange Framework and agency, or made to a defined category of would apply to health IT developers adherence to the Common Agreement, safety organizations—and which we that have a Health IT Module(s) certified and whether the current structure of the refer to hereafter as ‘‘communications to any of the certification criteria in Trusted Exchange Framework and with unqualified protection.’’ Second, to §§ 170.315(b)(1), (c)(1) and (c)(2), (e)(1), Common Agreement are conducive to be permitted, a developer’s prohibition (f), and (g)(9) through (11); and provide health IT developer participation and in or restriction must also fall within a services for connection to health what manner. prescribed category of circumstances for which we propose it is both legitimate information networks (HINs). These 3. Communications services could be routing EHI through a and reasonable for a developer to limit HIN or responding to requests for EHI The Cures Act requires that a health the sharing of information about its from a HIN. IT developer, as a Condition and products. This would be because of the Maintenance of Certification under the nature of the relationship between the We have identified health IT Program, does not prohibit or restrict developer and the communicator or developers that certify health IT to the communication regarding the following because of the nature of the information criteria above because the capabilities subjects: that is, or could be, the subject of the included in the criteria support access • The usability of the health communication (referred to hereafter as and exchange of EHI. Therefore, we information technology; ‘‘permitted prohibitions and believe such health IT developers, as • The interoperability of the health restrictions’’). A restriction or opposed to a health IT developer that information technology; prohibition that does not satisfy this only supports clinical decision support • The security of the health two-part test will contravene this (§ 170.315(a)(9)) with its certified health information technology; Condition of Certification. As discussed IT, would be best suited to participate • Relevant information regarding in more detail below, we propose that in the Trusted Exchange Framework and users’ experiences when using the this two-part test strikes a reasonable adhere to the Common Agreement. health information technology; balance between the need to promote • Similarly, we believe that many such The business practices of open communication about health IT health IT developers with the identified developers of health information and related business practices, and the certified health IT would be in position, technology related to exchanging need to protect the legitimate interests and requested by customers, to provide electronic health information; and of health IT developers and other • connection services to HINs. When such The manner in which a user of the entities. criteria are met (certified to the health information technology has used identified criteria above and actually such technology. a. Background and Purpose providing connection services), We propose to implement this This Condition of Certification participation in the Trusted Exchange Condition of Certification and its addresses industry practices that Framework and adherence to the requirements in § 170.403. The Cures severely limit the ability and Common Agreement are consistent with Act placed no limitations on the willingness of health IT customers, this Condition and Maintenance of protection of the communications users, researchers, and other Certification as specified by the Cures delineated above (referred to hereafter stakeholders who use and work with Act, the intent of Congress to establish as ‘‘protected communications’’). As health IT to openly discuss and share widespread interoperability and such, we propose to broadly interpret their experiences and other relevant exchange of health information without the subject matter of communications information about the performance of information blocking, and supports that are protected from developer health IT, including the ability of health ONC’s responsibility, as established by prohibition or restriction as well as the IT to exchange health information the HITECH Act, to develop and support conduct of developers that implicate the electronically. These practices result in a nationwide health IT infrastructure protection afforded to communications a lack of transparency around health IT that allows for the electronic use and by this Condition of Certification and that can contribute to and exacerbate exchange of information. More discuss this proposed approach in detail patient safety risks, system security specifically, by participating in the below. While we propose to implement vulnerabilities, and product Trusted Exchange Framework and a broad general prohibition against performance issues. As discussed adhering to the Common Agreement, developers imposing prohibitions and below, these issues have been these health IT developers provide restrictions on protected documented and reported on over a assurances that they are not taking communications, we also recognize that number of years. actions that constitute information there are circumstances where it is both The challenges presented by health IT blocking or any other action that may legitimate and reasonable for developers developer actions that prohibit or

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00045 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7468 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

restrict communications have been The issue of health IT developers investigative reporting.70 A September examined for some time. The problem prohibiting or restricting 2015 report examined eleven contracts was identified in a 2012 report by the communications about health IT has between health systems and major Institute of Medicine of the National been the subject of a series of hearings health IT developers and found that, Academies (IOM) entitled ‘‘Health IT by the Senate Committee on Health, with one exception, all of the contracts and Patient Safety: Building Safer Education, Labor and Pensions (HELP protected large amounts of information Systems for Better Care’’ 57 (IOM Committee), starting in the spring of from being disclosed, including Report). The IOM Report stated that 2015. During several hearings, information related to safety and health care providers, researchers, stakeholders emphasized the lack of performance issues.71 The report stated consumer groups other health IT users transparency around the performance of that broad confidentiality and lack information regarding the health IT in a live environment, noting intellectual property protection clauses functionality of health IT.58 The IOM that this can undermine a competitive were the greatest barriers to allowing the Report observed, relatedly, that many marketplace, hinder innovation, and communication of information developers restrict the information that prevent improvements in the safety and regarding potential safety issues and users can communicate about usability of the technology.65 66 adverse events.72 developers’ products through Additionally, the HELP Committee Finally, ONC has itself been made nondisclosure clauses, confidentiality indicated serious concerns regarding the aware of health IT developer contract clauses, intellectual property reported efforts of health IT developers language that purports to prohibit the protections, hold-harmless clauses, and to restrict, by contract and other means, disclosure of information about health other boilerplate contract language.59 communications regarding user IT, including even a customer’s or user’s Importantly, the IOM Report found that experience, including information opinions and conclusions about the such clauses discourage users from relevant to safety and interoperability.67 performance and other aspects of the sharing information about patient safety When one Senator asked a panel of technology. Our extensive interactions risks related to health IT, which experts—which included a health IT with health care providers, researchers, significantly limits the ability of health developer—if there were any reasons for and other stakeholders consistently IT users to understand how health IT health IT contracts to have indicate that such terms are not impacts patient safety.60 The report confidentiality clauses restricting users uncommon and that some developers stressed the need for health IT of health information technology from may actively enforce them and engage developers to enable the free exchange discussing their experience of using the in other practices to discourage of information regarding the experience health IT, all panel members agreed that communications regarding developers’ of using their health IT products, such clauses should be prohibited.68 health IT products and related business 61 practices. including the sharing of screenshots. Prior to the HELP Committee hearings This proposed Condition of Other close observers of health IT described above, the issue of developers Certification is needed to significantly have similarly noted that broad prohibiting and restricting improve transparency around the restrictions on communications can communications about the performance functioning of health IT in the field. inhibit the communication of of their health IT was also addressed in This will help ensure that the health IT information about errors and adverse House Energy and Commerce ultimately selected and used by health events.62 Concerns have also been Committee hearings when committee care providers and others functions as raised by researchers of health IT members heard testimony and held expected, is less likely to have safety products,63 who emphasize that discussions related to the Cures Act.69 issues or implementation difficulties, confidentiality and intellectual property Commentary by witnesses at the enables greater interoperability of health provisions in contracts often place hearings emphasized the need to ensure information, and more fully allows broad and unclear limits on authorized that health IT products are safe and users to reap the benefits of health IT uses of information related to health IT, encouraged the availability of utilization, including improvements in which in turn seriously impacts the information around health IT products care and quality, and reductions in ability of researchers to conduct and to improve quality and ensure patient costs. publish their research.64 safety. Developer actions that prohibit or b. Condition of Certification 57 IOM (Institute of Medicine), Health IT and restrict communications about health IT Requirements Patient Safety: Building Safer Systems for Better Care (2012). Available at http:// have also been the subject of i. Protected Communications and www.nationalacademies.org/hmd/Reports/2011/ Communicators Health-IT-and-Patient-Safety-Building-Safer- healthaffairs.org/blog/2015/10/14/overcoming- We propose that the protection Systems-for-Better-Care.aspx. contractual-barriers-to-ehr-research/. 58 Id, 195. 65 HELP 6/10/15 pg 12; Available at https:// afforded to communicators under this 59 Ibid. www.gpo.gov/fdsys/pkg/CHRG-114shrg25971/pdf/ Condition of Certification would apply 60 Ibid. CHRG-114shrg25971.pdf. irrespective of the form or medium in 61 Ibid. 66 HELP 3/17/15 pg 47; Available at https:// which the communication is made. 62 See Kathy Kenyon, Overcoming Contractual www.gpo.gov/fdsys/pkg/CHRG-114shrg93864/pdf/ Developers must not prohibit or restrict Barriers to EHR Research, Health Affairs Blog CHRG-114shrg93864.pdf. (October 14, 2015). Available at http:// 67 HELP 7/23/15 pg 13, pg 27; Available at https:// communications whether written, oral, healthaffairs.org/blog/2015/10/14/overcoming- www.help.senate.gov/hearings/achieving-the- electronic or by any other method if contractual-barriers-to-ehr-research/. promise-of-health-information-technology- they concern protected 63 See Hardeep Singh, David C. Classen, and Dean information-blocking-and-potential-solutions. communications, unless permitted F. Sittig, Creating an Oversight Infrastructure for 68 HELP 7/23/15 pg 38; Available at https:// otherwise by this Condition of Electronic Health Record-Related Patient Safety www.help.senate.gov/hearings/achieving-the- Hazards, 7(4) Journal of Patient Safety 169 (2011). promise-of-health-information-technology- Available at https://www.ncbi.nlm.nih.gov/pmc/ information-blocking-and-potential-solutions. 70 D Tahir, POLITICO Investigation: EHR gag articles/PMC3677059/. 69 Energy and Commerce 7/17/14 pg 35; Available clauses exist—and, critics say, threaten safety, 64 Kathy Kenyon, Overcoming Contractual at http://docs.house.gov/meetings/IF/IF16/ Politico, August 27, 2015. Barriers to EHR Research, Health Affairs Blog 20140717/102509/HHRG-113-IF16-20140717- 71 Ibid. (October 14, 2015). Available at http:// SD008.pdf. 72 Ibid.

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00046 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7469

Certification. Similarly, this Condition scope of communications that Congress customizability; use of templates; of Certification does not impose any specified in the Act. We encourage mandatory data elements; the use of text limit on the identity of the comment on whether the types of fields; and customer support. communicators that are able to benefit subject matter we identify below are (B) Interoperability of Health from the protection afforded, except that adequate to protect the full range of Information Technology employees and contractors of a health IT communications contemplated by the developer may be treated differently Cures Act. Section 3000(9) of the PHSA, as amended by the Cures Act, provides a when making communications that are (A) Usability of Health Information definition of ‘‘interoperability’’ that not afforded unqualified protection Technology under § 170.403(a)(2)(i). This Condition describes a type of health IT that of Certification is not limited to The term ‘‘usability’’ is not defined in demonstrates the necessary capabilities communications by health IT customers the Cures Act nor in any other relevant to be interoperable. For the purposes of (e.g., providers) who have contracts statutory provisions. In the National this Condition of Certification, we with health IT developers. Entities or Institute of Standards and Technology propose that protected communications individuals who enter into agreements (NIST) Usability Initiative, NIST regarding the ‘‘interoperability of health with a developer in connection with the describes ‘‘usability’’ of health IT by IT’’ would include communications 73 developer’s health IT—for example, a referencing the ISO standard, about whether a health IT product and data analytics vendor who is required to ISO9241: Usability is ‘‘the extent to associated developer business practices sign a non-disclosure agreement before which a product can be used by meet the interoperability definition being granted access to the developer’s specified users to achieve specified described in section 3000(9) of the health IT—would also be covered by the goals with effectiveness, efficiency and PHSA, including communications about protection afforded to communicators satisfaction in a specified context of aspects of the technology or developer 74 75 under this Condition of Certification. use.’’ Separately, HIMSS has that fall short of the expectations found Patients, health IT researchers, industry recognized the following principles of in that definition. This will include groups, and health information software usability: Simplicity; communications about the exchanges would be able to make Naturalness; Consistency; Forgiveness interoperability capabilities of health IT protected communications about the and Feedback; Effective Use of and the practices of a health IT health IT free of impermissible Language; Efficient Interactions; developer that may inhibit the access, prohibitions or restrictions. Similarly, Effective Information Presentation; exchange, or use of EHI, including the Condition of Certification would Preservation of Context; and Minimize information blocking. Cognitive Load.76 As these also extend to potential customers of (C) Security of Health IT health IT who are provided with organizations have expressed, there are product or software demonstrations, a multitude of factors that contribute to The security of health information irrespective of whether they proceed any judgment about ‘‘usability,’’ and technology is primarily addressed under with the acquisition of the technology. any assessment about the usability of the HIPAA Security Rule,77 which Examples of other protected health IT should appropriately rest on establishes national standards to protect communications include, but are not the factors contributing to the individuals’ electronic protected health limited to: effectiveness, efficiency, and information (ePHI) that is created, • A post made to an online forum; performance offered. As such, we received, maintained, or transmitted by • the sharing of screenshots, subject propose that the ‘‘usability’’ of health IT a covered entity or business associate. to certain proposed restrictions on their be construed broadly to include both an Covered entities and business associates general publication; overall judgment on the ‘‘usability’’ of a must ensure the confidentiality, • an unattributed written review by a particular health IT product, as well as integrity, and availability of all such health IT user; any factor that contributes to usability. ePHI; protect against any reasonably • a quote given by a health care Factors of usability that could be the anticipated threats or hazards to the executive to a journalist; subject of protected communications security or integrity of such information; • a presentation given at a trade include, but are not limited to: The user and protect against any reasonably show; interface (i.e., what a user sees on the anticipated uses or disclosures of such • a social media post; screen, such as layout, controls, information that are not permitted or • a product review posted on a video- graphics and navigational elements); required under the HIPAA Privacy sharing service such as YouTube; ease of use (e.g., how many clicks); how 78 • Rule. HIPAA requires that health IT the statements and conclusions the technology supports users’ developers, to the extent that they are made in a peer-reviewed journal; and workflows; the organization of • business associates of HIPAA-covered private communications made information; cognitive burden; cognitive entities, implement appropriate between health IT customers about the support; error tolerance; clinical administrative, physical, and technical health IT. decision support; alerts; error handling; safeguards to ensure the confidentiality, ii. Protected Subject Areas integrity, and security of ePHI. 73 The International Organization for We propose that the matters that fall The Cures Act (and § 170.403(a)(1)) Standardization (ISO) is an international standard- identifies a list of subject areas about setting organization that develops, publishes, and within the topic of health IT security which developers cannot prohibit or promotes proprietary, industrial, and commercial should be broadly construed to include standards. For more information see https:// restrict communications. These subject any safeguards, whether or not required www.iso.org/home.html. by the Security Rule, that may be areas address health IT performance and 74 See https://www.nist.gov/programs-projects/ implemented (or not implemented) by a usability, health IT security, and the health-it-usability. business practices related to exchanging 75 The Healthcare Information and Management developer to ensure the confidentiality, EHI. For the reasons discussed below, Systems Society (HIMSS) is a not-for-profit organization that promotes the use of information 77 45 CFR part 160 and subparts A and C of part we propose that the terms used to technology in health care. For more information, 164. describe the subject areas should be see http://www.himss.org/. 78 45 CFR part 160 and subparts A and E of part construed broadly, consistent with the 76 See http://www.himss.org/what-ehr-usability. 164.

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00047 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7470 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

integrity, and security of the wider set (E) Manner in Which a User Has Used • the developer’s licensing practices of EHI (including ePHI), together with Health IT and terms as it relates to making the health IT product’s performance We propose that protected available APIs and other aspects of its regarding security. For example, a communications regarding the ‘‘manner technology that enable the development developer may not prohibit or restrict a in which a user has used health IT’’ and deployment of interoperable potential communicator from would encompass any information products and services; and • the developer’s approach to creating communicating about, without related to how the health IT has been interfaces with third-party products or limitation: used in practice. This subject area • The approach to security adopted services, including whether connections largely overlaps with the matters are treated as ‘‘one off’’ customizations, for the health IT at issue (e.g., covered under the ‘‘user experience’’ architectural approach or authentication or whether similar types of connections subject area but may include additional can be implemented at a reduced cost. methodology); perspectives or details beyond those • Importantly, we further propose that the resilience of the health IT; experienced by a user of health IT. • information regarding business practices identified security flaws in the Types of information that would fall developer’s health IT; or related to exchanging electronic health within this subject area include but are information would include information • the response to cyber threats or not limited to: about the switching costs imposed by a security breaches by the developer. • Information about a work-around developer, as we are aware that the cost (D) User Experiences implemented to overcome an issue in of switching health IT is a significant the health IT; factor impacting health care providers The phrase ‘‘user experience’’ is not • customizations built on top of core adopting the most exchange-friendly defined in the Cures Act nor in any health IT functionality; health IT products that are available. other relevant statutory provisions. We • the specific conditions under which propose to afford these terms their a user used the health IT, such as iii. Meaning of ‘‘Prohibit or Restrict’’ ordinary meaning. To qualify as a ‘‘user information about constraints imposed The terms ‘‘prohibit’’ and ‘‘restrict’’ experience,’’ the experience must be one on health IT functionality due to are not defined in the Cures Act or in that is had by a user of health IT. implementation decisions; and any other relevant statutory provisions. However, beyond this, we do not • information about the ways in As discussed in detail below, propose to qualify the types of which health IT could not be used or communications can be prohibited or experiences that would receive did not function as was represented by restricted through contractual terms or protection under the Condition on the the developer. agreements (e.g., non-disclosure basis of the ‘‘user experience’’ subject agreements, non-disparagement clauses) (F) Business Practices Related to area. This reflects the great variety of as well as through conduct, including Exchange experiences that users may have with punitive or retaliatory business health IT and the often subjective nature We propose that the subject matter of practices that are designed to create of such experiences. Thus, we believe ‘‘developer business practices related to powerful disincentives to engaging in that if the user had the experience, the exchanging electronic health communications about developers or experience is relevant. information’’ should be broadly their products. Therefore, we propose To illustrate the breadth of potential construed to include developer policies that this Condition of Certification user experiences that would be and practices that facilitate the would not be limited to only formal protected by this Condition of exchange of electronic health prohibitions or restrictions (such as by Certification, we propose that information, and developer policies and means of contracts or agreements) and communications about ‘‘relevant practices that impact the ability of would encompass any conduct by a information regarding users’ health IT to exchange health developer that would be likely to experiences when using the health IT’’ information. We further propose That restrict a communication or class of would encompass, for example, the exchange of electronic health communications protected by this communications and information about information encompasses the Condition, as discussed in detail below. a person or organization’s experience appropriate and timely sharing of The conduct in question must have acquiring, implementing, using, or electronic health information. some nexus to the making of a protected otherwise interacting with health IT. We propose that protected communication or an attempted or This includes experiences associated communications include, but are not contemplated protected communication. with the use of the health IT in the limited to: That is, conduct by a developer that delivery of health care, together with • The costs charged by a developer may be perceived as intimidating or administrative functions performed for products or services that support the punitive would not implicate this using the health IT. User experiences exchange of electronic health Condition of Certification unless that would also include the experiences information (e.g., interface costs, API conduct was designed to directly or associated with configuring and using licensing fees and royalties, indirectly influence the making of a the technology throughout maintenance and subscription fees, protected communication. Similarly, implementation, training, and in transaction or usage-based costs for health IT contracts may include terms practice. Further, user experiences exchanging information); that govern the manner in which the would include patients’ and consumers’ • the timeframes and terms on which parties conduct themselves, and those user experiences with consumer apps, developers will or will not enable terms would not implicate this patient portals, and other consumer- connections and facilitate exchange Condition of Certification unless the facing technologies. To be clear, a with other technologies, individuals, or operative effect of a term was to restrict ‘‘relevant user experience’’ includes any entities, including other health IT or prohibit a protected communication. aspect of the health IT user experience developers, exchanges, and networks; For abundant clarity, we note that the that could positively or negatively • the developer’s approach to fact that a customer’s health IT product impact the effectiveness or performance participation in health information is not performing in the manner the of the health IT. exchanges and/or networks; customer expected, or in the manner

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00048 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7471

that the developer promised, would not, be made may be treated as a prohibition protected communication would be in itself be evidence that the developer or restriction if it has the effect of subject to this Condition of is engaging in conduct that restricts or restricting legitimate communications Certification. We emphasize that, as prohibits a protected communication. about health IT. discussed above, the conduct in Rather, a nexus must exist between the Restrictions and prohibitions found in question must have some nexus to the alleged poor performance and the contracts used by developers to sell or making of a protected communication or making of (or attempting or license their health IT products can an attempted or contemplated protected contemplating to make) a protected apply to customers directly and can communication. As such, developer communication. require that the customer ‘‘flow-down’’ conduct that was alleged to be We note that contractual prohibitions obligations onto the customer’s intimidating, or health IT performance or restrictions on communications can, employees, contractors, and other that was perceived to be substandard, in limited circumstances, be legitimate individuals or entities that use or work would not, in and of itself, implicate and serve an important role in with the developer’s health IT. Such this Condition of Certification unless protecting proprietary information and contract provisions would not comply there was some nexus between the intellectual property that are essential with this Condition of Certification if conduct or performance issue and the for health IT developers to innovate and they prohibit or restrict protected making of (or attempting or threatening compete. On this basis, we propose to communications. Prohibitions or to make) a protected communication. permit certain types of prohibitions and restrictions on communications can also Examples of conduct that could restrictions, subject to strict conditions be found in separate nondisclosure implicate this Condition of Certification to ensure that they are narrowly tailored agreements (NDAs) that developers include, but are not limited to: and do not restrict protected require their customers—and in some • Taking steps to enforce, including communications. These permitted instances the users of the health IT—to by threatening to enforce, a right arising prohibitions and restrictions are enter into in order to receive or access under contract that contravenes this discussed in section VII.B.3.b.v below. the health IT. We propose that such Condition of Certification. agreements are covered by this • Taking steps to enforce, including (A) Prohibitions or Restrictions Arising Condition of Certification. Finally, by threatening to enforce, a legal right by Way of Contract health IT developers typically may that purports to prohibit or restrict a The principal way that health IT require third-party contractors used by protected communication. This would developers can control the disclosure of their customers (such as a data analytics include, for example, the making of information about their health IT is vendor engaged by a health care threats, such as via a cease and desist through contractual prohibitions or provider to analyze the provider’s data) letter, to a researcher who has made a restrictions. Such prohibitions or to enter into a NDA with the developer protected communication. restrictions can arise in contractual before commencing their contract • Employing a technological measure provisions that address, for example, activities. In some extreme cases, the (within the meaning of 17 U.S.C. 1201) confidentiality obligations, intellectual employees of these third-party that a user would have to circumvent in property protections, hold-harmless contractors are required to sign NDAs in order to make a protected requirements, nondisclosure their personal capacities. These NDAs communication, for example, a obligations, non-compete obligations, typically include obligations that technological measure that a health IT and publicity rights. prohibit or restrict communications user would need to circumvent in order There are different ways that about the developer’s health IT to take a screenshot of the developer’s contractual prohibitions or restrictions products, and we propose that any such health IT. arise. In some instances a contractual prohibitions or restrictions within the • Discouraging the making of prohibition or restriction will be context of protected communications as protected communications by: expressed, and the precise nature and defined here would be subject to this Æ Making threats against a health care scope of the prohibition or restriction Condition of Certification. customer (e.g., by threatening to will be explicit from the face of the withhold the latest version of the (B) Prohibitions or Restrictions That contract or agreement. For example, a developer’s software) in response to the Arise by Way of Conduct contract will say that the health IT customer making or attempting to make customer must not disclose screenshots We are aware that some health IT a protected communication. of the health IT. However, more often, developers engage in conduct that has Æ Taking retaliatory action against a a contract will impose prohibitions or the effect of prohibiting or restricting person or entity that has made a restrictions in less precise terms. For protected communications. This protected communication (e.g., example, a health IT contract might use conduct may arise despite the withholding support, delaying the broad language when describing the developer’s contract and/or business provider’s adoption of a new software information or materials that customers associate agreement being silent on, or release, or removing a provider from the and users are forbidden from disclosing even expressly permitting, the protected developer’s ‘‘preferred customer’’ list). pursuant to a confidentiality clause, communication. The effect of such • Having policies that disadvantage casting a vague net over the developer’s conduct can be significant, as health persons or entities that make protected ‘‘proprietary’’ information and care providers are dependent on their communications (e.g., a policy that bars purporting to cover information that health IT developer in order to receive a provider from qualifying for the may be neither confidential, secret, nor critical software updates or other developer’s ‘‘preferred customer’’ list if protected by law. A contract does not maintenance services, and sometimes it shares screenshots in a manner need to expressly prohibit or restrict a have little bargaining power. Similarly, protected by this Condition of protected communication in order to a third-party developer is dependent on Certification). have the effect of prohibiting or a health IT developer’s authorization in • Refusing to publish—or refusing to restricting that protected order to perform work in connection remove or delete—protected communication. The use of broad or with the developer’s health IT. communications made in an online vague language that obfuscates the types We propose that conduct that has the forum that the developer moderates or of communications that can and cannot effect of prohibiting or restricting a controls.

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00049 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7472 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

• Causing the removal or deletion of (B) Communicating Information About PSQIA, its implementing regulation, a protected communication from any Adverse Events, Hazards, and Other and section 4005(c) of the Cures Act, no publication (e.g., a YouTube Copyright Unsafe Conditions to Government such activities shall be construed as Take-down Notice that does not raise a Agencies, Health Care Accreditation constituting restrictions or prohibitions legitimate copyright claim). Organizations, and Patient Safety that contravene this Condition of Organizations Certification. iv. Communications With Unqualified We understand that the nature of the Protection It is well established that there is a information about health IT that would strong public interest in allowing open ordinarily be disclosed by a health care We propose, and discuss below, a communication of information provider when reporting an adverse narrow class of communications— regarding health care hazards, adverse event, hazard, or unsafe conditions to consisting of five specific types of events, and unsafe conditions. Given the government agencies, health care communications—that would receive central role played by health IT in the accreditation organizations, and patient unqualified protection from developer delivery of care, information about safety organizations, would not prohibitions or restrictions. With health IT is a critical component of any ordinarily contain intellectual property respect to communications with investigation into the cause of hazards, or trade secrets. Notwithstanding this, unqualified protection, a developer adverse events, or unsafe conditions. On in light of the public policy interest and would be prohibited from imposing any the basis of this public policy interest established reporting mechanisms prohibition or restriction. As discussed alone, we propose there is an described above, we do not consider the overwhelming interest in ensuring that below, we propose that this narrow potential inclusion of intellectual all communications about health IT that class of communications warrants property or trade secrets in the are necessary to identify patient safety communication should prohibit or unqualified protection because of the risks, and to make health IT safer, not strength of the public policy interest restrict a health care provider from be encumbered by prohibitions or making a complete and timely report. being advanced by the communication restrictions imposed by health IT and/or the sensitivity with which the For example, proposed developers that may affect the extent or § 170.403(a)(2)(ii)(D) permits developers identified recipient treats, and timeliness of communications. In to impose certain restrictions on the implements safeguards to protect the addition to the public policy interest in general publication of screenshots, but confidentiality and security of, the promoting uninhibited communications we do not consider that such information received. A developer that about health IT safety, the recognized restrictions should be permitted when imposes a prohibition or restriction on communication channels for adverse the communication is made for one of a communication with unqualified events, hazards, and unsafe conditions the purposes, and to one of the protection would fail the first part of the provide protections that help ensure recipients, identified in two-part test for allowable prohibitions that any disclosures made are § 170.403(a)(2)(i)(B). or restrictions, and as such would appropriately handled and kept We seek comment on whether the contravene the Condition of confidential and secure. Indeed, the unqualified protection afforded to Certification. class of recipients to which the communications made to a patient information can be communicated safety organizations about adverse (A) Disclosures Required by Law under this category of communications events, hazards, and other unsafe We propose that where a with unqualified protection should conditions should be limited. provide health IT developers with communication relates to subject areas Specifically, we seek comment on comfort that there is very little risk of whether the unqualified protection enumerated in § 170.403(a)(1) and there such communications prejudicing the should be limited by the nature of the are federal, state, or local laws that developer’s intellectual property rights. patient safety organization to which a would require the disclosure of For example, government agencies communication can be made, or the information related to health IT, impose appropriate controls on nature of the communication that can developers must not prohibit or restrict information they receive, mitigating any made—such as limiting to only material in any way protected communications risk that developers may feel arises from that was created as PSWP. made in compliance with those laws. the disclosure of information about their (C) Communicating Information About We note that we expect that most health health IT. Similarly, accrediting bodies Cybersecurity Threats and Incidents to IT contracts would allow for, or at the for health care delivery observe strict Government Agencies very least not prohibit or restrict, any confidentiality policies for information communication or disclosure that is received or developed during the We propose that if health IT required by law, such as responding to accreditation process and in connection developers were to impose prohibitions a court or Congressional subpoena, or a with complaints received. or restrictions on the ability of any valid warrant presented by law Finally, the Patient Safety and Quality person or entity to communicate enforcement. We further propose that if Improvement Act of 2005 (PSQIA) 79 information about cybersecurity threats required by law, a potential provides for privilege and and incidents to government agencies, communicator should not have to delay confidentiality protections for such conduct would not comply with any protected communication under information that meets the definition of this Condition of Certification. Government agencies such as the United this Condition of Certification. patient safety work product (PSWP). States Computer Emergency Readiness Furthermore, we propose that the This means that PSWP may only be Team (US–CERT) respond to and reasonable limitations and prohibitions disclosed as permitted by the PSQIA and its implementing regulations. We protect both the government and private that are discussed below and permitted industry from cyber threats. Their work by § 170.403(a)(2) do not apply to these clarify that to the extent activities are conducted in accordance with the helps protect the entire health care types of protected communications. system from cybersecurity threats and 79 Patient Safety and Quality Improvement Act of relies on the timely reporting of security 2005, 42 U.S.C. 299b–21–b–26 (Pub. L. 109–41). issues and vulnerabilities by health care

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00050 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7473

providers and health IT users. These to a health IT developer’s intellectual • Certain communications that would agencies impose appropriate controls on property or trade secrets. Generally infringe the developer’s or another information they receive, which speaking, agencies collecting reports person’s intellectual property rights; mitigates any risk that developers may would protect all information received • Publication of screenshots in very feel arises from the disclosure of and keep it confidential to the extent narrow circumstances; and information about their health IT. The permitted by law. • Communications of information US–CERT, for example, provides secure that a person or entity knows only forms for such reporting, and we are (E) Communicating Information About a because of their participation in confident that reporting security Health IT Developer’s Failure To developer-led product development and incident information to US–CERT and Comply With a Condition of testing. other government agencies would be Certification or Other Program As discussed in detail in the sections unlikely to pose any threat to health IT Requirement that follow, the proposed Condition of developer intellectual property or trade We propose that the benefits to the Certification carefully delineates the secrets. Additionally, the information public and to users of health IT of circumstances under which these types likely reported regarding such an communicating information about a of prohibitions and restrictions would incident would generally not reveal health IT developer’s failure to comply be permitted, including certain trade secrets. Where circumstances may with a Condition of Certification or associated conditions that developers require collection of more sensitive and other Program requirement (45 CFR part would be required to meet. To be clear, confidential information related to a 170) justify prohibiting developers of any prohibition or restriction not developer’s intellectual property, we health IT from placing any restrictions expressly permitted would violate the believe that appropriate protections on such protected communications. Condition. Additionally, it would be the would likely apply and that the public Information regarding the failure of a developer’s burden to demonstrate to benefit of thoroughly investigating and health IT product to meet any Condition the satisfaction of ONC that the addressing cybersecurity issues of Certification or other Program developer has met all associated requirements. Further, as an additional outweighs any potential harm. requirement is vital to the effective safeguard, we propose that where a Communications about security issues performance and integrity of the developer seeks to avail itself of one of related to health IT may alert nefarious Program, which certifies that health IT the permitted types of prohibitions or individuals or entities to the existence functions consistent with its restrictions, the developer must ensure of a security vulnerability which could certification. While the current that potential communicators are clearly be exploited before a developer has time procedures for reporting issues with and explicitly notified about the to fix the vulnerability. However, we certified health IT encourage providers information and material that can be propose that this concern must be to contact developers in the first communicated, and that which cannot. balanced against the imperative of instance to address certification issues, ensuring that health IT customers are We propose this would mean that the users of health IT should not hesitate to language of health IT contracts must be aware of security vulnerabilities so that contact ONC-Authorized Certification they can respond by deploying reactive precise and specific. Contractual Bodies (ONC–ACBs), or ONC itself, if provisions or public statements that measures independent of the developer, the developer does not provide an such as ceasing health information support a permitted prohibition or appropriate response, or the matter is of restriction on communication should be exchange with a compromised system. a nature that should be immediately We seek comment on whether it would very specific about the rights and reported to an ONC–ACB or to ONC. be reasonable to permit health IT obligations of the potential developers to impose limited v. Permitted Prohibitions and communicator. Contract terms that are restrictions on communications about Restrictions vague and cannot be readily understood security issues so as to safeguard the by a reasonable health IT customer will We propose that, except for confidentiality, integrity, and security of not benefit from the qualifications to communications with unqualified eHI. For example, should health IT this Condition of Certification outlined protection discussed above and developers be permitted to require that below. enumerated in § 170.403(a)(2)(i), health health IT users notify the developer IT developers would be permitted to (A) Developer Employees and about the existence of a security Contractors vulnerability prior to, or simultaneously impose certain narrow kinds of with, any communication about the prohibitions and restrictions discussed We recognize that health IT developer issue to a government agency? below and specified in employees, together with the entities § 170.403(a)(2)(ii). We believe this and individuals who are contracted by (D) Communicating Information About policy strikes a reasonable balance health IT developers to deliver products Information Blocking and Other between the need to promote open and/or services (such as consultants), Unlawful Practices to a Government communication about health IT and may be exposed to highly sensitive, Agency related business practices and the need proprietary, and valuable information in As in the circumstances described to protect the legitimate interests of the course of performing their duties. above, we believe that the public benefit health IT developers and other entities. We also recognize that the proper associated with the communication of Specifically, with the exception of functioning of a workforce depends, at information to government agencies on communications with unqualified least in part, on the ability of an information blocking, or any other protection, developers would be employer to regulate how and when the unlawful practice, outweighs any permitted to prohibit or restrict the organization communicates information concerns developers might have about following communications, subject to to the public, and that employees owe the disclosure of information about their certain conditions: confidentiality obligations to their health IT. We believe that reporting • Communications of their own employers. We propose that on this information blocking, as well as other employees; basis, developers are permitted to unlawful practices, to a government • Disclosure of non-user-facing impose prohibitions or restrictions on agency would not cause an undue threat aspects of the software; the communications of employees and

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00051 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7474 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

contractors to the extent that those other potential communicators will also (C) Intellectual Property communications fall outside of the class be exposed to ‘‘user-facing aspects of Many aspects of health IT—including of communications with unqualified health IT,’’ such as third-party software and documentation—will protection as discussed above. contractors, health information contain intellectual property that exchange organizations, recipients of a (B) Non-User-Facing Aspects of Health belongs to the health IT developer (or a IT software demonstration, and trade third party) and is protected by law. groups or researchers that observe the The purpose of this Condition of Health IT products may have portions in operation of health IT in the field. which copyrighted works exist, or that Certification is to ensure that health IT We propose that this approach users and other potential are subject to patent protection. As in reasonably implements the Cures Act, other technology sectors, health IT communicators are not restrained in which, in direct response to strict their ability to communicate—publicly developers place a high value on their confidentiality obligations, broad intellectual property and go to or privately—about certain protected intellectual property clauses, and non- subject areas. We propose that this significant lengths to protect it, disclosure provisions in EHR contracts, including intellectual property purpose can generally be achieved identified a list of protected subject without communicators disclosing provisions in their health IT contracts. areas for disclosure (enumerated at This Condition of Certification is not information about those parts of health section 3001(c)(5)(D)(iii) of the PHSA) IT that are legally protected trade intended to operate as a de facto license that largely targeted the aspects of for health IT users and others to act in secrets. As such, we propose this health IT that are apparent to, and Condition of Certification will permit any way that might infringe the known by, individuals and entities that health IT developers to impose legitimate intellectual property rights of use or interact with health IT. We prohibitions and restrictions on developers. Indeed, we propose that propose that if a health IT user were communications that are not health IT developers are permitted to prohibited from describing the user- communications with unqualified prohibit or restrict communications that facing aspects of their health IT product, protection to the extent necessary to would infringe their intellectual they could not sensibly communicate ensure that communications do not property rights so long as the useful information about the usability or disclose ‘‘non-user-facing aspects of communication in question is not a interoperability of the product, or their health IT.’’ communication with unqualified A ‘‘non-user-facing aspect of health experiences as a health IT user. These protection. However, any prohibition IT’’ is, for the purpose of this Condition subject areas are fundamentally tied to and restriction imposed by a developer of Certification, an aspect of health IT the way that the health IT product must be no broader than legally that is not a ‘‘user-facing aspect of works, its design, and its functionality. permissible and reasonably necessary to health IT.’’ A ‘‘user-facing aspect of Protecting the communication of protect the developer’s legitimate health IT’’ means those aspects of health ‘‘user-facing aspects of health IT’’ is also intellectual property interests. We are IT that that are disclosed and evident to consistent with the treatment of aware that some health IT contracts anyone running, using, or observing the software products under trade secret contain broad intellectual property operation of health IT. That is, a user- law, where the public-facing aspects of provisions (and related terms, such as facing aspect of health IT comprises software products are not generally nondisclosure provisions) that purport those aspects of the health IT that are considered secret because they are to prevent health IT customers and manifest in how the health IT software evident to anyone running the software users from using copyright material in works. User-facing aspects of health IT program. Moreover, this approach is ways that are lawful. On this basis, include the design concepts and appropriate given the manner in which while we are providing an exception for functionality that is readily health IT is deployed and used by the protection of intellectual property ascertainable from the health IT’s user health IT customers. Unlike software interests, we want to clarify that under interface and screen display. They do products that are deployed and used in this Condition of Certification health IT not include those parts of the health IT a cloistered setting where access to the developers are not permitted to prohibit that are not exposed to persons running, software is highly restricted, health IT is or restrict, or purport to prohibit or using, or observing the operation of the typically deployed in a setting in which restrict, communications that would be health IT. We propose that non-user- the operation of the health IT can be a ‘‘fair use’’ of any copyright work facing aspects of health IT would readily observed by a wide range of comprised in the developer’s health IT. include source and object code, software persons. Health IT used in a physician’s That is, a developer is not permitted to documentation, design specifications, consulting room can be observed by the prohibit or restrict communications flowcharts, and file and data formats. patient. Health IT deployed in a hospital under the guise of copyright protection We welcome comments on whether can be observed by numerous (or under the guise of a confidentiality these and other aspects of health IT individuals in addition to those who are or non-disclosure obligation) when the should be treated as not being user- ‘‘authorized users’’ of the health IT communication in question makes a use facing. system, including, for example, the of the copyright material in a way that For clarity, we note that the patient, the patient’s family, volunteer would qualify that use as a ‘‘fair use.’’ 80 terminology of ‘‘user-facing aspects of staff, law enforcement, and clergy. As We welcome comments on whether health IT’’ is not intended to afford only such, because health IT is of a nature an appropriate balance has been struck health IT users with specific protections that license terms or nondisclosure between protecting legitimate against developer prohibitions or obligations do not act as a genuine intellectual property rights of restrictions on communications. Rather, control over the disclosure of those developers and ensuring that health IT the terminology is agnostic as to the aspects of the software that are ‘‘user- customers, users, researchers, and other identity of the communicator and is facing,’’ communications about such stakeholders who use and work with instead focused on describing those aspects should be afforded protection health IT can openly discuss and share aspects of health IT that are readily from developer prohibitions and their experiences and other relevant ascertainable from the health IT’s user restrictions under this proposed interface and screen display. Numerous Condition of Certification. 80 See 17 U.S.C. 107.

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00052 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7475

information about the performance of However, to take advantage of this in § 170.403(a)(2)(i) if the software is health IT. exception, the developer would need to certified or released to market. We first put all potential communicators on (D) Faithful Reproductions of Health IT propose that this permitted restriction sufficient written notice of those parts of Screenshots would also not apply to the screen display that contain trade communications about the released We propose that health IT developers secrets or intellectual property rights version of the health IT once the health generally would not be permitted to and cannot be communicated, and IT has been released to market or has prohibit or restrict communications that would still need to allow been certified, provided that the disclose screenshots of the developer’s communicators to communicate communications otherwise meet all health IT. We consider screen displays redacted versions of screenshots that do other requirements to be afforded an essential component of health IT not reproduce those parts. protection under this Condition of performance and usability, and their Finally, we also recognize that health Certification and the information reproduction may be necessary in order IT developers may have obligations for a health IT user or other health IT under HIPAA as a business associate communicated could be discovered by stakeholder to properly make and that it would be reasonable for any ordinary user of the health IT. communications about the subject developers to impose restrictions on the For example, a health IT developer matters enumerated in § 170.403(a)(1). communication of screenshots that and a large health system enter into an We acknowledge that some health IT contain protected health information, agreement for members of the health IT developers have historically and provided that developers permit the developer’s engineering team to work aggressively sought to prohibit the communication of screenshots that have with members of the health system’s disclosure of such communications. We been redacted to conceal protected clinical team to develop a customization consider that developers may benefit health information, or the relevant for the system’s use of the developer’s from screen displays being faithfully individual’s consent or authorization EHR. In order to properly protect any reproduced so that health IT users and had been obtained. intellectual property rights, or other stakeholders can form an objective (E) Testing and Development proprietary information, arising from opinion on any question raised about this work, the developer and health usability in communications protected We are aware that some health IT system enter into a contract which by this proposed Condition of developers expose aspects of their imposes on the system and affected Certification. Moreover, we consider health IT to health care providers and members of its clinical team strict that the reproduction of screenshots in others for the purpose of testing and connection with the making of a development prior to a product’s nondisclosure related to testing and communication protected by this ‘‘general availability’’ release. Such development of the health IT. This Condition of Certification would disclosures may relate to beta releases would be reasonable and would not ordinarily represent a ‘‘fair use’’ of any that are shared with certain customers contravene this Condition of copyright subsisting in the screen for testing prior to the software being Certification, provided that: (1) The display, and developers should not made generally available to the market, nondisclosure obligations were impose prohibitions or restrictions that or may be made as part of a joint- narrowly targeted toward the work would limit that fair use. venture or cooperative development product associated with the testing and Notwithstanding the above, we process. In these circumstances, we development; and (2) the obligations propose to permit certain prohibitions propose that a health IT developer ceased immediately upon any resultant and restrictions on the communication would be justified in keeping software being deployed in the health of screenshots. Except in connection information about its health IT system, to the extent that the with communications with unqualified confidential, and we do not intend that information fell within one of the protection, developers would be the protection afforded to subject areas enumerated in permitted to impose certain restrictions communicators under this Condition of § 170.403(a)(1) and would be apparent on the disclosure of screenshots, as Certification would allow disclosures of to an ordinary user of the health IT. this information. This permitted described below. To ensure that this permitted In order to ensure that disclosures of prohibition or restriction would allow prohibition/restriction is not abused, screenshots are reasonable and developers to seek appropriate such as by maintaining a product in beta represent a faithful reproduction of the intellectual property protection and release for an indefinite or lengthy developer’s screen design and health IT, freely discuss novel, ‘‘unreleased’’ we propose that developers would be product features with their customer period of time, we request comment on permitted to prevent communicators base, which has significant public whether we should limit the time this from altering screenshots, other than to policy benefits for research and protection would apply for testing annotate the screenshot or to resize it for innovation in the health IT industry. purposes. This could be no longer than the purpose of publication. We consider As with the other allowable a year after release of a product or this a reasonable limitation on the restrictions listed above, we propose update. We also request comment on disclosure of screenshots and one that that this permitted restriction would be whether we should set specific would help developers’ health IT avoid limited and does not apply to parameters for covered testing. For being misrepresented by communicators communications which are example, we note above our seeking to make a communication communications with unqualified expectations that a product would be protected by this proposed Condition of protection as described above and shared with certain customers for Certification. specified in § 170.403(a)(2)(i). For testing prior to the software being made We also propose that health IT example, information that is learned as generally available to the market. As developers could impose restrictions on part of development and testing, such as such, for this permitted prohibition/ the disclosure of a screenshot on the the hard-coding of test procedure restriction to apply, should we more basis that it would infringe third-party processes that raise serious patient specifically limit the extent a product intellectual property rights (on their safety concerns, could be communicated can be distributed to customers for behalf or as required by license). for one of the limited purposes specified testing purposes?

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00053 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7476 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

c. Maintenance of Certification of time, but not later than two years 4. Application Programming Interfaces Requirements from the effective date of a subsequent As a Condition of Certification (and We propose that to maintain final rule for this proposed rule. Maintenance thereof) under the We believe this is an appropriate compliance with this Condition of Program, the Cures Act requires health approach as we understand that health Certification a health IT developer must IT developers to publish APIs that allow IT developers are in regular contact with not establish or enforce any contract or ‘‘health information from such their customers, and so the provision of agreement provision that contravenes technology to be accessed, exchanged, a notice that satisfies this requirement this Condition of Certification. We are and used without special effort through should not present an undue burden for aware that some developers currently the use of APIs or successor technology a developer. We would also expect that have in place health IT contracts that or standards, as provided for under developers have kept good records of contain provisions that contravene this nondisclosure agreements that they applicable law.’’ The Cures Act’s API proposed Condition of Certification have entered into with other Condition of Certification also states because they impose impermissible organizations or individuals, such as that a developer must, through an API, prohibitions or restrictions on third-party developers, and can ‘‘provide access to all data elements of communications. In some instances, the communicate with those organizations a patient’s electronic health record to provisions in question will be expressly or individuals as necessary to satisfy the extent permissible under applicable at odds with this Condition, imposing this requirement. In the event that a privacy laws.’’ obligations on health IT customers, or health IT developer cannot, despite all The Cures Act’s API Condition of creating rights in favor of the developer, reasonable efforts, locate an entity or Certification includes several key that prohibit or restrict communications individual that previously entered into phrases and requirements for health IT that are protected. In other instances, a an agreement with the developer that developers that go beyond just the contract will include a provision that prohibits or restricts communications technical functionality of the products contravenes this Condition because it protected by this Condition, the they present for certification. In this has been drawn in such broad terms— developer would not be in section of the preamble we outline our such as an overly-expansive definition contravention of this Condition so long proposals to implement the Cures Act’s of confidential information—that a as it takes no step to enforce the API Condition of Certification in order reasonable reader of the provision prohibition or restriction. For clarity, we to provide compliance clarity for health would consider the making of a do not propose that health IT developers IT developers. communication protected by this be required to furnish to ONC or their These proposals include new Condition a breach of the contract. ONC–ACB copies of notices made to standards, new implementation Health IT contracts are typically for a customers, or copies of contracts or specifications, and a new certification significant duration—e.g., 5 years or agreements revised, in satisfaction of criterion as well as detailed Conditions more—or include an automatic renewal this Maintenance of Certification and Maintenance of Certification whereby the then current terms roll over requirement, although those requirements. We also propose to for any renewal period. The communications may be requested by modify the Base EHR definition. We implementation of this proposed ONC or an ONC–ACB in the usual note that health IT developers should Condition of Certification cannot course of business. To this point, under also consider these proposals in the therefore wait until health IT contracts the ‘‘Enforcement’’ section of this context of what could warrant review that contravene this Condition expire in proposed rule (VII.D), we describe our from an information blocking the ordinary course. As such, we are general enforcement approach outlining perspective in so far as action (or requiring that health IT developers take a corrective action process for ONC to inaction) that would be inconsistent immediate steps to become in review instances where Conditions and with this proposed rule’s API compliance with this Condition of Maintenance of Certification Conditions and Maintenance of Certification. requirements are not being met by a Certification requirements. We propose that a health IT developer health IT developer under the Program. must notify all customers and those a. Statutory Interpretation and API We note that another approach we Policy Principles with which it has contracts/agreements, considered proposing would have been within six months of the effective date to require that developers amend their One of the most significant phrases in of a subsequent final rule for this current health IT contracts immediately. the Cures Act’s API Condition of proposed rule, that any communication We have, however, relied on the Certification concerns the deployment or contract/agreement provision that proposed requirement that developers and use of APIs ‘‘without special effort.’’ contravenes this Condition of not enforce contractual terms that Specifically, the Cures Act requires Certification will not be enforced by the contravene this proposed Condition of health IT developers to publish APIs health IT developer. Further, we Certification until they can amend their and allow health information from such propose that this notice would need to contracts in a reasonable period of time, technology ‘‘to be accessed, exchanged, be provided annually up to and until but not later than two years from the and used without special effort.’’ In this the health IT developer amends the effective date of a subsequent final rule context, we interpret the ‘‘effort’’ contract or agreement to remove or for this proposed rule. We seek exerted (i.e., by whom) to be focused on make void any contractual provision comment on whether this is an adequate the API users, which could include that contravenes this Condition of approach to removing prohibitions and third-party software developers, the Certification. We further propose as a restrictions on protected health care providers that acquired this Maintenance of Certification communications and ensuring that API technology, and patients, health requirement in § 170.405(b)(2) that health IT customers, users, researchers, care providers, and payers that use health IT developers must amend their and other stakeholders are aware of apps/services that connect to API contracts or agreements to remove or their right to engage in such technology. make void any provisions that communications notwithstanding As we considered the meaning and contravene the Condition of existing contracts or agreements to the context associated with the phrase Certification within a reasonable period contrary. ‘‘without special effort’’ and what

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00054 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7477

would make APIs included in certified line. It also means that developers • The term ‘‘(g)(10)-certified API’’ for health IT truly ‘‘open,’’ we focused on (together with health care providers that ease of reference throughout the key attributes that could be used to deploy APIs) are accountable to patients preamble to refer to health IT certified refine our interpretation and guide our who, as consumers of health care to the certification criterion proposed proposals. We interpret ‘‘without services, have paid for their care and the for adoption in 45 CFR 170.315(g)(10). special effort’’ to require that APIs, and information generated from such care. • The term ‘‘app’’ for ease of the health care ecosystem in which they Thus, patients should be able to access reference to describe any type of are deployed, have three attributes: their EHI via any API-enabled app they software application that would be Standardized, transparent, and pro- choose without special effort, including designed to interact with the (g)(10)- competitive. Each of these attributes is without incurring additional costs and certified APIs. This generic term is briefly described in more detail below without encountering access meant to include, but not be limited to, and all of our subsequent proposals requirements that impede their ability to a range of applications from mobile and address one or a combination of these access their information in a persistent browser-based to comprehensive attributes. manner. business-to-business enterprise • Standardized—meaning that all b. Key Terms applications administered by third health IT developers seeking parties. certification would have to implement To clearly convey the stakeholders on the same technical API capabilities in which our proposals focus and are c. Proposed API Standards, their products (using modern, meant to support, we propose to use the Implementation Specifications, and computing standards such as RESTful following terms to reflect these Certification Criterion interfaces and XML/JSON). Technical meanings and/or roles: APIs can be thought of as a set of consistency and implementation • The term ‘‘API technology’’ (with a commands, functions, protocols, and/or predictability are fundamental to scale lowercase ‘‘t’’) generally refers to the tools published by one software API-enabled interoperability and reduce capabilities of certified health IT that developer (‘‘software developer A’’) that the level of custom development and fulfill the API-focused certification enable other software developers (X, Y, costs necessary to access, exchange, and criteria adopted or proposed for and Z) to create programs and use health information. Further, from a adoption at 45 CFR 170.315(g)(7) applications that interact with A’s regulatory standpoint, health IT through (g)(11). software without needing to know the developers would gain certainty in • ‘‘API Technology Supplier’’ refers to ‘‘internal’’ workings of A’s software. regards to pre-certification testing a health IT developer that creates the APIs can facilitate more seamless access requirements and post-certification API technology that is presented for to health information and it is important ‘‘real world testing’’ expectations. testing and certification to any of the Equally, from an industry standpoint, a to note for context that ONC adopted certification criteria adopted or three 2015 Edition certification criteria consistent and predictable set of API proposed for adoption at 45 CFR functions would provide the health IT that specified API capabilities for Health 170.315(g)(7) through (g)(11). We ecosystem with known technical IT Modules (criteria adopted in 45 CFR propose to adopt this term in § 170.102. requirements against which ‘‘app’’ 170.315(g)(7), (g)(8), and (g)(9)). The • ‘‘API Data Provider’’ refers to the developers and other innovative following sections detail our proposals organization that deploys the API services can be built. to adopt standards, implementation • Transparent—meaning that all technology created by the ‘‘API specifications, and a new API health IT developers seeking Technology Supplier’’ and provides certification criterion. Together, these certification would need to make the access via the API technology to data it proposals account for the technical specific business and technical produces and electronically manages. In requirements we propose to associate documentation necessary to interact some cases, the API Data Provider may with the Cures Act’s API Condition of with the APIs in production freely and contract with the API Technology Certification and are reinforced through publicly accessible. Such transparency Supplier to perform the API deployment the condition’s policy proposals. and openness is commonplace in many service on its behalf. However, in such circumstances, the API Data Provider i. Proposed Adoption of FHIR DSTU2 other industries and has fueled Standard innovation, growth, and competition. retains control of what and how • Pro-competitive—meaning that all information is disclosed and so for the Overall, and on balance, we have health IT developers seeking purposes of this definition is considered structured our standards and certification would need to abide by to be the entity that deploys the API implementation specifications proposals business practices that promote the technology. We propose to adopt this to best meet the health IT industry efficient access, exchange, and use of term in § 170.102. where it is most prepared to comply EHI to support a competitive • ‘‘API User’’—refers to persons and today. As a result, we propose to adopt marketplace that enhances consumer entities that use or create software the HL7® Fast Healthcare value and choice. Moreover, health care applications that interact with the APIs Interoperability Resources (FHIR®) providers should have the sole authority developed by the ‘‘API Technology standard as a foundational standard and autonomy to unilaterally permit Supplier’’ and deployed by the ‘‘API within our suite of proposals. third-party software developers to Data Provider.’’ An API User includes, Specifically, we propose to adopt FHIR connect to the API technology they have but is not limited to, third-party Draft Standard for Trial Use (DSTU) 2 acquired. In other words, health IT software developers, developers of (hereafter referred to as ‘‘FHIR Release developers must not interfere with a software applications used by API Data 2’’) as a baseline standard conformance health care provider’s use of their Providers, patients, health care requirement. In so doing, we can work acquired API technology in any way, providers, and payers that use apps/ with industry to support a conformance especially ways that would impact its services that connect to API technology. testing infrastructure for a full suite of equitable access and use based on (for We propose to adopt this term in proposals focused on one FHIR release example) another software developer’s § 170.102. (its associated implementation size, current client base, or business We also use: specifications) and complementary

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00055 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7478 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

security and app registration protocols, included varied support for it in their Option 1 (proposed in regulation compared to numerous versions.81 product(s) at this time, there is limited text): Adopt just FHIR Release 2 for The 2015 Edition final rule did not evidence that its production reference in proposed § 170.315(g)(10). include specific standards or deployment is as widespread as FHIR This option would require health IT implementation specifications to Release 2. Thus, we believe that FHIR developers seeking certification to describe the way in which APIs needed Release 2 is the most appropriate build, test, and certify systems solely to to be designed to meet § 170.315(g)(8). version to propose to adopt as part of FHIR Release 2 and its associated Instead, we specified a functional proposed § 170.315(g)(10)’s implementation specifications. Under certification criterion and encouraged conformance requirements. This this option, if the National Coordinator the industry to coalesce around a approach would provide a stable and approved the use of FHIR Release 3 or standardized specification for its API consistent direction in which the 4 (pursuant to the Standards Version functionality, such as the FHIR industry can go when it comes to Advancement Process) it would occur, standard. We did, however, require deploying (g)(10)–certified APIs that at the earliest, one year after a final rule health IT developers to make their support data access to the USCDI. FHIR was issued. Given that timing, and the technical API documentation publicly Release 2 best reflects the industry’s compliance deadlines proposed later in available and we subsequently made current maturity and implementation this section, it would mean that health such information accessible via the readiness, it has been more rigorously IT developers would have no option but CHPL. tested, and it is largely implemented in to develop to FHIR Release 2 in order Upon reviewing health IT developers most 2015 Edition health IT systems to meet the proposed compliance certified to § 170.315(g)(8), that have and are being deployed in deadlines. approximately 32% have published via production. Thus, the incremental Option 2: Adopt FHIR Release 2 and the CHPL that they are using FHIR, burden for many health IT developers to FHIR Release 3 in order to introduce specifically FHIR Release 2, as of mid- get certified to the proposed criterion in optionality into how health IT September 2018. Additionally, nearly § 170.315(g)(10) would be largely developers are able to demonstrate 51% of health IT developers appear to limited to the added security and compliance with proposed be using a version of FHIR and OAuth registration conformance requirements § 170.315(g)(10). In other words, by 2.0 together. We also note that when we have proposed to include. We adopting and referencing both FHIR viewed from the perspective of how recognize, however, that some health IT Release 2 and 3 in proposed many providers are served by these developers certified to § 170.315(g)(8) § 170.315(g)(10) it would permit a FHIR implementers, we estimate that chose not to use FHIR and will have health IT developer to use either one to approximate 87% of hospitals and 57% more substantial changes to make in meet the criterion (i.e., both versions of clinicians are served by developers order to meet this proposal. would not be required to be supported with a FHIR Release 2 API and 87% of Additionally, FHIR Release 4 has now and demonstrating only one would be needed to meet certification). Similarly, hospitals and 69% of clinicians are been published 84 and updated under this option, if the National served by developers with a FHIR API associated implementation Coordinator approved the use of FHIR of any version. In the years since the specifications are expected to follow. Release 4 (pursuant to the Standards 2015 Edition final rule, industry FHIR Release 4 has several key Version Advancement Process) it would stakeholders have made rapid progress improvements, including certain occur, at the earliest, one year after a to advance the FHIR standard. This foundational aspects in the standard final rule was issued. Given that timing, includes substantial investments in and ‘‘FHIR resources’’ designated as and the compliance deadlines proposed industry pilots, specification ‘‘normative’’ for the first time. This will later in this section, it would mean that development led through the Argonaut lead to acycle of more mature US FHIR 82 health IT developers would have no Project production deployment of Core profiles aligned with Release 4 and APIs conformant to FHIR Release 2 option but to develop to FHIR Release additional implementation guidance 2 or Release 3 in order to meet the following the Argonaut specifications, that explicitly specifies how to handle and the support for FHIR Release 2 in proposed compliance deadlines. populations of patient data (batch Option 3: Adopt FHIR Release 2 and Apple’s iOS 11.3, which includes a new exports) via FHIR to more efficiently ‘‘health records’’ app for the iPhone FHIR Release 4 in order to introduce 83 enable population and learning health flexibility into how health IT developers based on these specifications. system-oriented services. Likewise, from Therefore, the industry is well prepared are able to demonstrate compliance with an industry update trajectory, we proposed § 170.315(g)(10). The full and ready to adopt the FHIR standard. believe that FHIR Release 4’s normative Thus, we propose to adopt FHIR implementation of this option would resources will be compelling from a Release 2 as the baseline standard in a depend on all applicable corresponding maturity and stability perspective such new API standards section of our rules FHIR Release 2 implementation that many health IT developers will at 45 CFR 170.215(a)(1). Additionally, as specifications also being published in either rapidly progress to FHIR Release discussed in further detail below, we their FHIR Release 4 formats and 4 from Release 3 or skip wide-scale reference FHIR Release 2 for use in the available prior to the issuance of a final production deployment of FHIR Release new API certification criterion proposed rule. Provided these FHIR Release 4 3 altogether, making FHIR Release 4 the for adoption in § 170.315(g)(10). implementation specifications are Although FHIR Release 3 is published next de facto version the industry would published in time for a final rule, this and some health IT developers have move toward and coalesce behind. option would appear to be the best near- Given FHIR Release 4’s public release and long-term option for the industry. 81 In October 2018, ONC released a first version and that the industry will begin to We anticipate this being the case of a FHIR testing tool visit here for more details: implement Release 4 in parallel with because it would let lagging health IT https://inferno.healthit.gov/. this rulemaking, we request comment developers catch up to the FHIR Release 82 http://argonautwiki.hl7.org/ on the following options we could _ 2 baseline while at the same time enable index.php?title=Main Page. pursue for a final rule. 83 https://www.apple.com/newsroom/2018/01/ leading health IT developers to move apple-announces-effortless-solution-bringing- directly and immediately to FHIR health-records-to-iPhone/. 84 http://blog.hl7.org/hl7-publishes-fhir-release-4. Release 4 as a means to meet proposed

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00056 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7479

§ 170.315(g)(10)’s compliance timelines. permit FHIR Release 2 APIs to be § 170.315(g)(10) would need to support. In other words, unlike Options 1 and 2, deployed in 2022 and used for an We refer to this proposed initial set of the Standards Version Advancement indeterminate period of time. FHIR resources as the ‘‘API Resource Process would not be necessary and the In preparing your comments, please Collection in Health’’ or ‘‘the ARCH.’’ trajectory of leading health IT fully review our proposed certification The ARCH would align with and be developers would be well supported by criterion in § 170.315(g)(10) and the directed by the data policy specified in the certification criterion. We also accompanying Conditions of the proposed US Core Data for request comment on a variant of Option Certification attributed to the API- Interoperability (USCDI) standard 3 that would include a pre-defined cut- oriented certification criteria. Notably, if (discussed in section IV.B.1 of this over for the permitted use of and we were to adopt another FHIR Release proposed rule). certification to FHIR Release 2. We note in a final rule as an alternative to FHIR As a result, we propose to include 15 that if this variant were implemented as Release 2 for the proposed API criterion FHIR resources in the ARCH’s first part of Option 3, we would likely also in § 170.315(g)(10), then we would also version. Based on prior industry efforts, need to add a maintenance of adopt the applicable implementation including the Argonaut Project to map certification requirement in the final specifications and FHIR profiles (the US FHIR resources to the previously rule to establish an upgrade timeline to FHIR Core profiles) associated with the defined Common Clinical Data Set FHIR Release 4 for those health IT FHIR Release in order to support USCDI (CCDS), we know that the following 13 developers who originally sought data access. We highly encourage FHIR resources map to and support the certification for FHIR Release 2. Such a stakeholders to express their perspective equivalent data classes specified in the maintenance requirement would seem and explicitly note their preferred USCDI: AllergyIntolerance; CarePlan; necessary in order to bring the industry option in comments. Condition; Device; DiagnosticReport; Goal; Immunization; Medication; into closer alignment with respect to a ii. Proposed Adoption of Associated MedicationOrder; MedicationStatement; more up-to-date national baseline for FHIR Release 2 Implementation Observation; Patient; and Procedure. We FHIR. Specifications also propose to include, specifically for Option 4: Adopt solely FHIR Release Our proposal to adopt the FHIR the Patient resource that the 4 in the final rule for reference in standard alone, however, is insufficient ‘‘Patient.address’’ and ‘‘Patient.telecom’’ proposed § 170.315(g)(10). This option to provide the level of consistent elements must be supported as part of would require health IT developers implementation that will be necessary the Patient resource. These elements are seeking certification to build, test, and to realize the ‘‘without special effort’’ neither required in the base FHIR certify systems solely to FHIR Release 4 provision in this Condition of resource or additional implementation and its associated implementation Certification. FHIR, much like other specifications; however, they are specifications. Again, provided all standards that are initially developed to necessary to align with the USCDI’s data applicable FHIR Release 4 be internationally applicable, requires requirements. With respect to the implementation specifications are additional implementation Device resource, we propose to require published in time for a final rule, this specifications in order to further that the ‘‘Device.udi’’ element follow option would appear to be a close constrain implementation choices and the human readable representation of preference to Option 3 for industry. We reflect US-based standards policies the unique device identifier (UDI) found believe this would be the case because (such as the use of RxNorm for in the recommendation, guidance, and by the time a final rule associated with representing medications). In FHIR, the conformance requirements section of these proposals is issued, it is likely that additional constraints placed on ‘‘base the ‘‘HL7 Version 3 Cross Paradigm health IT developers would have close FHIR resources’’ are expressed through Implementation Guide: Medical Devices to or over a year’s worth of development what are called ‘‘FHIR profiles.’’ FHIR and Unique Device Identification (UDI) experience with FHIR Release 4. As a Profiles typically provide additional Pattern, Release 1,’’ a document hosted result, many may be poised to introduce rules about which resource elements by HL7.85 Developers would be held their first round of generally available must be used and what additional responsible only for the FHIR Release 4 products into elements have been added that are not recommendation, guidance, and production. If ONC were to offer part of the base FHIR resource. This can conformance requirements for HL7 certification to FHIR Release 2 (as in include, but not be limited to, rules FHIR in the implementation guide and Option 3) this flexibility could about which API features are used and would not be held responsible for other unintentionally delay the industry’s how as well as rules about which requirements in the implementation transition to FHIR Release 4 and slow terminologies are used in particular guide specific to other standards, progress associated with FHIR-based elements. The term ‘‘profile’’ is a including requirements for HL7 Version interoperability. The following general term that is used in the FHIR 2 and HL7 Version 3. For clarity, these compliance timeline example attempts standard to describe either an proposed requirements are part of the to make this point clearer. If, for individual FHIR resource, or an entire ARCH Version 1 standard. example, the final rule was effective implementation specification consisting In addition to these 13 FHIR January 2020, based on other proposals of multiple FHIR resources. resources, we have included two associated with the API Conditions of Accordingly, we propose to adopt three additional FHIR resources: Certification, health IT developers implementation specifications that will (1) The Provenance resource; and (2) would have up to 2 years to rollout their establish a standardized baseline and the DocumentReference resource to (g)(10)–certified API technology, which further constrain API conformance to accommodate clinical notes. These would mean January 2022. At that help assure that APIs can be used additions would make for a total of 15 point, FHIR Release 4 would have been ‘‘without special effort.’’ FHIR resources to reflect the direction of published for nearly 3 years and FHIR We propose to adopt in the USCDI v1. With respect to clinical Release 2 would have been published § 170.215(a)(2) an implementation notes, we understand from our own for nearly 6 years. Without a pre-defined specification that would list a set of base cut-over for FHIR Release 2 in Option 3, FHIR resources that Health IT Modules 85 http://www.hl7.org/implement/standards/ that certification approach would certified to the proposed criterion in product_brief.cfm?product_id=487.

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00057 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7480 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

analysis and technical discussions Over time, and as the USCDI is defines ‘‘how a provider or patient can within HL7 that the FHIR expanded, we also expect to update this retrieve a patient’s existing clinical DocumentReference resource is best implementation specification to expand document.’’ This particular capable of handling the exchange of the ARCH beyond these 15 FHIR specification was produced in support clinical notes. Since the CCDS was resources. Equally, consistent with the of the 2015 Edition certification defined over two years ago, we have Maintenance of Certification criterion adopted in § 170.315(g)(9). As most frequently heard from provider requirements described in section a result, we clarify that this specific stakeholders that access to ‘‘clinical VII.B.5 of this proposed rule (the portion of the Server IG and notes’’ is key, impactful, and highly Standards Version Advancement conformance requirement would be out desirable data that should be accessible Process proposals), which would permit of scope for the purposes of proposed via the C–CDAs they exchange as well health IT developers to voluntarily § 170.315(g)(10). as via APIs. While we realize the implement and use a new version of an We have separately proposed the industry may need to develop adopted standard or implementation FHIR standard and each of these implementation specifications so that additional implementation guidance to specification so long as certain the National Coordinator may evaluate support clinical notes via FHIR, we conditions are met including that the new version is approved by the National industry progress and make a unique or believe that including FHIR resources in Coordinator for use in certification combined determination as to the ARCH Version 1 directly addresses the through the Standards Version appropriate time to approve for steady requests we have received from Advancement Process, health IT voluntary upgrade pursuant to the providers to include a focus on the developers would be able to update standards version advancement process access, exchange, and use of ‘‘clinical their certified health IT to include discussed in more detail in section notes’’ as part of certification. Thus, we (g)(10)-certified API access to a broader VII.B.5 as well as subsequently go propose to include the FHIR set of data once a new version of the through rulemaking to adopt a new DocumentReference resource in the ARCH is approved. version of: The FHIR standard, the ARCH to support clinical notes. We also The next implementation ARCH, implementation specifications clarify that the clinical note text specification for the FHIR standard we that ‘‘profile’’ the resources in the included in this FHIR resource would propose to adopt in § 170.215(a)(3) is ARCH, and implementation need to be represented in its ‘‘raw’’ text the Argonaut Data Query specifications for FHIR server form. In other words, it would be Implementation Guide version 1 conformance capabilities. While the unacceptable for the note text to be (Argonaut IG), hosted by HL7.86 This proposed implementation specifications converted to another file or format (e.g., implementation guide has been pilot relate to one another, they can also be .docx, PDF) when it is provided as part tested and is now being implemented updated independently of each other as of an API response. With respect to the for production use by health IT time goes on. For instance, the National Provenance resource, we believe its developers. Notably, it specifies FHIR Coordinator could approve a new inclusion in the ARCH is paramount to profile constraints for 13 of the version of the FHIR standard ‘‘Release the long-term success and use of FHIR- associated FHIR resources we propose 5’’ in the future in accordance with the based APIs. While C–CDA’s are often to include in the ARCH Version 1 and standards version advancement process. critiqued due to their relative ‘‘length,’’ these FHIR profiles support the data In so doing, the National Coordinator the C–CDA often represents the output included in the USCDI (v1). could leave the scope of the ARCH the of a clinical event and includes relevant The next implementation same and update (necessarily) the context. The same will not always be specification for the FHIR standard we implementation specifications for the true in an API-context. This is due to propose the Secretary adopt in FHIR profiles and FHIR server the fact that FHIR-based APIs make it § 170.215(a)(4) is the specific portion of conformance requirements accordingly significantly easier for apps to request the Argonaut IG that refers to the to align with the new FHIR version. As specific data (e.g., just a patient’s active ‘‘Argonaut Data Query Implementation an alternative example, the National Guide Server’’ conformance medications). Thus, it is equally Coordinator could leave the FHIR requirements. While it could be implied important over the long-term that the standard version the same and approve through our proposed adoption of the industry not lose sight of the metadata a new version of the ARCH to include Argonaut IG that these conformance (i.e., the who, what, when, where, why, more FHIR resources. requirements would be included, we We note that other federal agencies and how) behind the data that was seek to make this an explicit may be adopting the FHIR standard and created. As a result, we believe that this requirement for the API certification additional FHIR implementation guides early stage of FHIR deployment is the criterion proposed in § 170.315(g)(10). for their program requirements. We plan best time for the industry to build in Conformance to this implementation to coordinate with such other agencies support for the Provenance resource. specification is essential in order to to focus on strategic alignment among Otherwise, if we were to expand the ensure that all FHIR servers are the FHIR standard versions, applicable ARCH in future years to include this consistently configured to support the implementation guides, and use cases. FHIR resource, we estimate that the defined data queries and ‘‘supported developer burden and overall industry searches’’ associated with each iii. Proposed Adoption of Standards and impact would be greater than building Argonaut profiled FHIR resource. For Implementation Specifications To this support in ‘‘from the start.’’ clarity, conformance testing would Support Persistent User Authentication Specifically, and to remain consistent focus on and be limited to the ‘‘SHALL’’ and App Authorization with the USCDI, we propose to require requirements. We also note that the To enable and support persistent user that the ‘‘Provenance.recorded’’ (for the Argonaut Data Query Implementation authentication and app authorization author’s time stamp) and Guide Server includes conformance processes, we propose to adopt a ‘‘Provenance.agent.actor’’ (for the author requirements for the standards and additional and author’s organization) elements be ‘‘DocumentReference Profile,’’ which implementation specification for the supported as part of the Provenance FHIR standard. First, we propose to resource. 86 http://www.fhir.org/guides/argonaut/r2/. adopt the ‘‘OpenID Connect Core 1.0

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00058 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7481

incorporating errata set 1’’ standard in We also propose to require that the stakeholders and the Cures Act, which § 170.215(b) as it complements the ‘‘Standalone Launch’’ and ‘‘EHR is why we believe it is necessary and SMART Application Launch Framework Launch’’ requirements specified in the appropriate to replace § 170.315(g)(8). In Implementation Guide Release 1.0.0 87 SMART Guide be supported. We believe contrast, we do not propose that it is (SMART Guide). The OpenID standard that requiring API Technology Suppliers necessary to replace the certification is typically paired with OAuth 2.0 to demonstrate both of these capacities criteria adopted in § 170.315(g)(7) and implementations and focuses on user will help ensure greater standardization (g)(9) because the former does not authentication. Second, we propose to and ease of use among (g)(10)-certified prescribe specific technical approaches adopt the SMART Guide in APIs. When a third-party ‘‘app’’ first (and can continue to be met as § 170.215(a)(5) as an additional connects to a FHIR server, it often technology evolves) and the latter implementation specification associated requires some contextual data to make supports a discrete use case relative to with the FHIR standard. This guide is the app more ‘‘user friendly.’’ This an API function that responds with a C– referenced by the Argonaut IG and is information could include things such CDA. generally being implemented by the as the most recent patient encounter or We propose our approach to adopt a health IT community as a security layer hospital visit. The contextual replacement for § 170.315(g)(8) that will with which FHIR deployment is being information depends on how the ‘‘app’’ provide clear regulatory compliance combined (from both a FHIR server and is launched. requirements for stakeholders because: FHIR application perspective). Further, When an app is launched from (1) 2015 Edition testing and certification while the SMART Guide includes ‘‘outside of an EHR,’’ such as from a to § 170.315(g)(8) will continue certain mandatory requirements, we patient’s smartphone or web browser, throughout this rulemaking; (2) believe three specific aspects are then the app is considered to be presuming we adopt this (or a modified necessary to specifically require in order launched in a ‘‘Standalone’’ mode. In version of this) proposal in a final rule, for certification to enable consistent this mode, the app has to request that it will be easier for the industry to industry-wide implementation. the FHIR server provide appropriate distinguish compliance requirements The SMART Guide specifies the use contextual information, which can then between two separate certification of ‘‘refresh tokens’’ as optional. We be used to customize the app’s display criteria compared to a time/context- believe that this requirement is for the patient. The SMART Guide has sensitive ‘‘version’’ of § 170.315(g)(8); necessary in order to enable persistent standardized the information that such and (3) § 170.315(g)(8) is currently access by apps, especially in a patient apps can request from FHIR servers and specified in the Base EHR definition so access context. Thus, we propose to defined it as ‘‘Standalone Launch.’’ its replacement has compliance effects make their use mandatory with a In other contexts, apps can be on health care providers participating in minimum refresh token life of 3 months. launched from ‘‘within the EHR.’’ This every program that requires the use of While this technique would need to be is typically the case when a third-party Certified EHR Technology, which supported for both types of API-enabled app is integrated as part of an EHR references the Base EHR definition. services we propose be supported technology. In this case, the app is At a high-level, we propose that this through § 170.315(g)(10), we wish to considered to have been launched in the new API certification criterion would emphasize that implementing refresh ‘‘EHR’’ mode. Typically, when such an require FHIR servers to support two token support is directly intended to app is launched from within an EHR, types of API-enabled services: • Services for which a single enable a patient’s ‘‘persistent access’’ to the user (e.g., provider, nurse) has a patient’s 88 data is at focus; and their electronic health information patient’s record ‘‘open’’ or ‘‘active’’ in without special effort (i.e., without • services for which multiple the EHR and expects the app to directly patients’ data are at focus, which, having to frequently re-authenticate and open the same patient when it is re-authorize while using their preferred hereafter, we refer to as ‘‘population- launched. In order for this to happen, level’’ to convey the grouped and cohort app). This proposal aligns with the the app has to request that the FHIR industry developed security best scope on which the data associated with server provides information about the these services would be focused (e.g., a practice guidelines for OAuth 2.0 patient record that is currently ‘‘open’’ implementations, which require support specific provider’s patient panel, all of in the EHR. The SMART Guide has for a short-lived ‘‘access token’’ and a the patients covered by a particular standardized this interaction and long-lived ‘‘refresh token’’ that could be health plan, a group of patients cared for defined it as ‘‘EHR Launch.’’ subsequently used by the app to obtain through an alternative payment model). a new ‘‘access token’’ after the original iv. Proposed Adoption of a New API This proposed certification criterion ‘‘access token’’ expires. We believe this Certification Criterion in would only require mandatory support approach enhances the seamlessness of § 170.315(g)(10) for ‘‘read’’ access for both identified services, though we envision a future a patient’s data access and reduces the Proposal Overview ‘‘friction’’ they would otherwise version of this certification criterion that experience having to re-authenticate To implement the Cures Act, we could include specific ‘‘write’’ and re-authorize. At the same time, propose to adopt a new criterion in conformance requirements (for example, because the access token is short lived, § 170.315(g)(10) to replace the to aid decision support) once FHIR- this minimizes the risk of a patient’s certification criterion adopted in based APIs are widely adopted. In all information being accessed by § 170.315(g)(8). Currently, the criterion cases, this proposed criterion will unauthorized users if for some reason adopted in § 170.315(g)(8) focuses on a require that the two types of API the access token is compromised. The Health IT Module’s ability to provide services have appropriate security technical capabilities that we intend to API functionality that can respond with controls implemented. These controls explicitly test are referenced as part of data for each of the data categories the proposed API certification criterion specified in the Common Clinical Data 88 We recognize that individuals may not always Set. Moreover, its focus on read-access/ be in an active role as a ‘‘patient’’ when they use in § 170.315(g)(10). an application to access their data. However, we response to requests for specific types of believe it is clearer for the purposes of readability 87 https://build.fhir.org/ig/HL7/smart-app- data most directly aligns with the API and policy intent to use the term ‘‘patient’’ as launch/. uses envisioned by industry opposed to ‘‘individual.’’

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00059 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7482 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

would ensure a user fully authenticates certification criterion because the testing and certification to the proposed to the API-enabled data source to which current certification criterion in certification criterion in § 170.315(g)(10) the request is being made and that the § 170.315(g)(8) has largely been tested, would need to meet the requirements user’s software application is certified, and deployed to support the outlined below. We seek comment on appropriately authorized to request ‘‘patient data request’’ use case. In all of the following proposals. specified data. comparison, population-level focused API services that focus on a single API services are envisioned to support Data Response patient would include, but not be FHIR-based apps that not only improve We propose in § 170.315(g)(10)(i) that limited to, those that interact with clinical workflow and decision support the health IT presented for testing and software applications controlled and but also help advance a learning health used by a patient to access their data as system. In so doing, providers, payers, certification must be capable of well as software applications and other stakeholders will be able to responding to requests for data on a implemented by a provider to enhance make incrementally better use of FHIR’s single patient and multiple patients their own ‘‘internal’’ clinical care tools RESTful API and JSON payload to apply associated with each of the FHIR and workflow (e.g., a specialized modern computing techniques, resources specified in ARCH Version 1 calculation app). Most, if not all, of including big data analyses and and consistent with FHIR Release 2 and these types of interactions are typically machine learning, to account for, assess, the Argonaut IG implementation orchestrated in a synchronous, real to and inform the quality and effectiveness specification. More specifically, we near-real-time mode via APIs. of care delivered. As noted in the clarify that all data elements indicated Conversely, API services that focus on proposed API standards section, FHIR as ‘‘mandatory’’ and ‘‘must support’’ by multiple patients would include, but Release 4 includes technical the proposed standards and not be limited to, software applications specifications to enable standardized implementation specifications must be used by a health care provider to population-level services via FHIR- supported and would be in scope for manage various internal patient based APIs in a more efficient manner testing. Through this approach, populations as well as external services than currently possible. If ‘‘Option 3’’ or certification will provide for a a health care provider may contract for ‘‘Option 4’’ is preferred by industry in consistent and predictable starting to support quality improvement, terms of the FHIR standards options for scope of data from which apps and population health management, and this certification criterion, these other services can be developed. cost accountability vis-a`-vis the approaches would be demonstrable. provider’s partners (e.g., health plans). Alternatively, if the National Search Support Historically, access to this kind of Coordinator were to approve FHIR computing has often been cumbersome, Release 4 for use under this proposed We propose to require in opaque, and required one-off scripting certification criterion (following the § 170.315(g)(10)(ii) that the health IT and significant engineering labor with Standards Version Advancement presented for testing and certification no overarching standardized methods. Process described in Section VII.B.5 of must be capable of responding to all of By shifting this paradigm to a FHIR- this preamble) then it would be able to the ‘‘supported searches’’ specified in based API, we anticipate that the market be used to meet these technical the Argonaut Data Query will be able to respond with a new slate expectations. Implementation Guide Server, which as of innovative solutions. Lastly, as we considered the necessary a reminder we have proposed for Across this spectrum of population- oversight responsibilities the Cures Act adoption as an implementation level uses, the scope or quantity of the adds to the Program, we have specification in § 170.215(a)(4).89 Given data may range from a small group to determined that it would be essential to that there is not yet a consistent, many hundreds or thousands of include a specific population-level API standardized specification for FHIR patients. Moreover, when ‘‘external’’ conformance requirement as part of this servers to handle searches for multiple applications and services are provided criterion so that such capabilities could patients, we clarify that a health IT access to patient data by the provider, be evaluated post-certification for developer would be permitted to we expect that such access and compliance with (among other approach searches for multiple patients associated privacy and security requirements) this API Condition of in the manner it deems most efficient to protocols would be established Certification and the information meet this proposed certification consistent with existing legal blocking and real world testing criterion. We note, consistent with the requirements under the HIPAA Privacy Conditions of Certification. implementation specifications current and Security Rules (including business scope, that conformance would focus on associate agreements), other data use Specific Proposals search associated with a single patient’s agreements (as applicable), and any In general, we have approached data. However, we reiterate the health other state or federal applicable law. framing § 170.315(g)(10) in the same IT presented for testing and certification Principally, for the purposes of the way we framed § 170.315(g)(8). This and as implemented must support proposed certification criterion, we seek new proposed criterion, however, to include and ensure through testing includes some important differences searches for multiple patients and certification that a set of baseline and specificity compared to independent of a required standard for API functionality exists and is deployed § 170.315(g)(8). Taken together, the such searches. for providers to use at their discretion following proposals are designed to For the DocumentReference and to support their own clinical priorities establish a consistent set of API Provenance resources, which are as well as to use to engage with their implementation requirements aimed at currently present in the base FHIR partners, such as software developers the API Condition of Certification’s standard, we request comments on the and developers of third-party ‘‘without special effort’’ requirement. minimum ‘‘search’’ parameters that applications. We propose that API technology would need to be supported. We have explicitly proposed to presented by a health IT developer include support for API services that are (otherwise considered an API 89 http://www.fhir.org/guides/argonaut/r2/ population-level focused in this Technology Supplier in this context) for Conformance-server.html.

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00060 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7483

App Registration registration within a clinical in the ‘‘Standalone Launch’’ and ‘‘EHR We propose in § 170.315(g)(10)(iii) environment. However, we request Launch’’ modes. Additionally, we that health IT presented for testing and comment on this perspective. clarify that for the purposes of testing and certification, we propose to require certification must be capable of enabling Secure Connection, Authentication and that health IT support only a limited set apps to register with an ‘‘authorization Authorization of capabilities related to the OpenID server.’’ This proposed conformance We propose in § 170.315(g)(10)(iv) requirement would require an API Connect Standard—specifically, only that the health IT presented for testing those that are specified in the SMART Technology Supplier to demonstrate its and certification must be capable of registration process, but would not Guide. establishing a secure and trusted Further, in order to enable patients require that it be done according to a connection with an application that and providers to get persistent access to specific standard. We considered requests patient data in accordance with health information without having to re- proposing the OAuth 2.0 Dynamic the SMART Guide. In the context of this authenticate and re-authorize, we Client Registration Protocol (RFC 7591) proposed criterion, this would require propose to require that a ‘‘refresh token’’ standard (‘‘Dynamic Registration’’) as that an ‘‘authorization server’’ be must be provided with an expiration the only way to support registration for deployed and support, at a minimum, period of at least 3 months from the date this certification criterion and request ‘‘authorize’’ and ‘‘token’’ endpoints and issued. The ‘‘refresh token’’ could be public comment on whether we should the publication of the endpoint URLs subsequently used by the app to obtain require its support as part of a final via FHIR server’s metadata as specified a new ‘‘access token’’ after the rule’s certification criterion. For clarity, in the SMART Guide to enable expiration of the original ‘‘access we note that while we have not automated discovery by apps. Again, we token.’’ Note the proposed refresh token explicitly required Dynamic note, consistent with this requirement is different than providing Registration as the only way to implementation specification’s current an ‘‘access token’’ with an extended life, demonstrate conformance with this scope, that initial conformance would which is typically discouraged from a specific portion of the certification focus on the secure connection security best practice perspective so as criterion, API Technology Suppliers parameters with a single patient’s data to prevent unauthorized access if for would still be allowed to use Dynamic in mind. Given that there is not yet a some reason the access token were to be Registration if they so choose. consistent, standardized specification acquired for use by an unauthorized While requiring Dynamic Registration for FHIR servers to handle secure application. could create a more consistent connection parameters for multiple We propose in § 170.315(g)(10)(vi) registration experience for health IT patients, we clarify that a health IT that health IT presented for testing and developers, we did not expressly developer would be permitted to certification must demonstrate that it include this standard because of its approach secure connections for can support subsequent connections by relatively low adoption and multiple patients in the manner it an app and requests data without implementation in the health IT deems most efficient to meet this requiring the user to re-authorize and re- ecosystem. Notably, while the SMART proposed certification criterion. authenticate when a valid refresh token Guide covers a majority of technical When an application connects to is supplied. Further, we propose that steps necessary for an app to connect a request data for the first time, we once a valid refresh token has been used FHIR server, it is neutral on the propose in § 170.315(g)(10)(v)(A) that to get a new access token that the FHIR registration process API Technology health IT presented for testing and server must demonstrate that it can Suppliers could take. Much like we did certification must be capable of issue a new refresh token to the app, with § 170.315(g)(8) in the initial 2015 demonstrating support for user which must be for a new period no Edition final rule by not requiring FHIR, authentication according to the OpenID shorter than three months. For example, we believe that a prudent approach for Connect Core 1.0 incorporating errata if an application were issued a refresh registration is to require that it be set 1 90 standard. It should be noted that token that was good for three months addressed from a functional perspective the OpenID Connect Standard is upon its first-ever connection and then while the industry reaches consensus on agnostic to the actual authentication subsequently connected to the FHIR the best techniques to enable mechanism used by the health IT while server one month later, the FHIR server registration. providing a standard way for health IT would need to enable that connection to Note, that while this portion of to exchange the authentication occur without re-authentication and re- proposed § 170.315(g)(10) focuses on the information to the app. The primary authorization, and it would need to technical standards conformance, we benefit being that it lets apps verify the issue a new refresh token for a new have also included a specific identity of the end-user based on the three-month period from that access ‘‘maintenance requirement’’ associated authentication performed by the date. Again, we intend to test health IT with the API Condition of Certification Authorization Server without having the in the ‘‘Standalone Launch’’ and ‘‘EHR around the timeliness of this registration apps to take additional responsibility for Launch’’ contexts pursuant to the process in production settings as authenticating the user. We also propose SMART Guide. applicable to API Technology Suppliers. in § 170.315(g)(10)(v)(B) that health IT We have proposed this renewal This proposed requirement will ensure presented for testing and certification requirement because industry that patients are able to use their apps must demonstrate that users can stakeholders at various meetings and in a timely manner. authorize applications (in the conferences at which we have attended We do not intend to test registration appropriate context) to access data in have indicated that a constant need for capabilities for apps that would be accordance with the SMART Guide. patients to re-authenticate and re- executed within an API Data Provider’s Pursuant to this proposed authorize their apps creates usability clinical environment. We believe this implementation specification described challenges and may otherwise discretion is warranted as API above, we also intend to test health IT contradict the Cures Act’s intent Technology Suppliers and API Data associated with the phrase ‘‘without Providers are best poised to innovate 90 http://openid.net/specs/openid-connect-core-1_ special effort.’’ Further, we are not and execute various methods for app 0.html. aware of a standard, consistent

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00061 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7484 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

methodology for specifying the lifetime requirements against which their supplied for the purposes of of refresh tokens in published technical software will need to be designed. registration. specifications. As a result, we believe In reconciling the 2015 Edition final Thus, we propose in our approach would improve the rule’s API documentation requirements § 170.315(g)(10)(vii) that an API current user experience for patients and with the new expectations set forth by Technology Supplier would need to providers alike. Additionally, the Cures Act regarding a health IT provide detailed information for all authorization servers maintain binding developer’s practices, we have aspects of its (g)(10)-certified API, between the refresh token and the determined that revisions are necessary. especially for any unique technical application to whom it was issued, and Accordingly, we propose to revise the requirements and configurations, such hence can protect against misuse by documentation provision in the API as how the FHIR server handles requests unauthorized applications. certification criteria adopted in for multiple patients (until such time as We believe that the three-month § 170.315(g)(7) through (g)(9) as well as there is an approved standardized period is a reasonable length given the reflect the same revision in proposed approach that can be cited) as well as proposal for the re-issuance of a new § 170.315(g)(10) and (11). Specifically, app registration requirements. For refresh token. However, we we propose to focus the documentation aspects that are not unique and are fully acknowledge that this same policy requirement set forth by the certification specified by the FHIR standard and outcome we discuss above could be criteria on solely the technical associated implementation achieved by, for example, having a two- documentation associated with the API specifications, the developer could month period. Accordingly, we seek technology. As a result, we propose to include hyperlinks to this information comment on whether there are available remove the provision in § 170.315(g)(7) as part of its overall documentation. specifications we should review as well through (g)(9) associated with ‘‘terms of Further, we propose to include the word as whether there should be a reasonable use’’ as this type of documentation ‘‘complete’’ in the documentation upper bound from a timing perspective could be considered more reflective of provision in order to make this point (e.g., one year) after which the user business practice and better placed with explicit and link this obligation to the should be required to re-authenticate other similar requirements. Consistent associated transparency conditions and re-authorize. with the Cures Act’s API Condition of proposed as part of the overall For both the first time connection and Certification, we have proposed more Condition of Certification. We note for subsequent connection proposals, we detailed Condition of Certification health IT developers that the recognize that there is not yet a documentation published must be of the requirements associated with a health IT consistent, standardized specification sort and to the level of specificity, developer’s API terms of use in order to for FHIR servers to handle data requests precision, and detail that the health IT address business practices that could for multiple patients. As noted above, developer customarily provides to its interfere with and create special effort we expect that FHIR Release 4 will have own employees, contractors, and/or on the part of an API User. such specificity. However, for the partners who develop software purposes of meeting this proposed With respect to the technical applications for production certification criterion, we clarify that a documentation that would need to be environments. health IT developer would be permitted made publicly available, we recognize Lastly, we note that all of the to approach requests for multiple that our proposed formal adoption of documentation referenced by this patients in the manner it deems most the FHIR standard and the associated criterion must be accessible to the efficient. implementation specifications (for public via a hyperlink without § 170.315(g)(10)) would be consistent additional access requirements, Transparency Through the Publication across all health IT presented for including, without limitation, any form of API Documentation certification. As a result there may be of registration, account creation, ‘‘click- In the 2015 Edition final rule we minimal additional documentation through’’ agreements, or requirement to included transparent documentation needed for these capabilities beyond provide contact details or other requirements for all three of the API- what is already documented in these information prior to accessing the focused certification criteria adopted in standards and specifications. However, documentation. It would also require § 170.315(g)(7) through (g)(9). These pursuant to the limited mandatory that such documentation needs to be requirements specified that scope proposed for ‘‘data response’’ (for submitted as part of testing for this documentation associated with API § 170.315(g)(10)), we believe that API certification criterion and subsequently syntax (and other technical descriptors), Technology Suppliers should disclose to ONC–ACBs for review prior to the software components and any additional data their (g)(10)- issuing a certification. configurations that would be necessary certified API supports in the context of in order for a deployed API to FHIR resources referenced in ARCH d. Condition of Certification successfully work, and the terms of use Version1 and associated Requirements for the API be made publicly available. implementation specifications. For To implement the Cures Act, we have We continue to believe that such a example, the Argonaut IG ‘‘Patient designed this API Condition of requirement is important for proposed Profile’’ includes optional elements for Certification in a manner that will § 170.315(g)(10), especially in light of marital status, photo, and contact (as in complement the technical capabilities the Cures Act’s ‘‘without special effort’’ contact person like a guardian or described in our other proposals, while provision. Such transparency and friend). To the degree that a (g)(10)- addressing the broader technology and openness is commonplace in many certified API supports such optional business landscape in which these API other industries and has fueled data an API Technology Supplier would capabilities will be deployed and used. innovation, growth, and competition. be required to convey this support in its Consistent with the attributes we have Further, we believe that full published technical documentation. identified for the statutory phrase transparency is necessary to ensure that Additionally, we note that other ‘‘without special effort,’’ our software developers building to a health specifications, like the RFC 7591, overarching vision for this Condition of IT developer’s (g)(10)-certified API have provide developers some latitude in Certification is to ensure that (g)(10)- a thorough understanding of any terms of the information that could be certified APIs, among all API

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00062 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7485

technology, are deployed in a manner associated with such criteria, we also business and technical documentation that supports an experience that is as propose certain compliance timelines freely and publicly accessible. Thus, we seamless and frictionless as possible. To associated with this Condition of propose to adopt several transparency that end, we seek to promote a Certification that would need to be met. conditions as part of § 170.404(a)(2). standards-based ecosystem that is Similar to our policy associated with ii. Cures Act Condition and transparent, scalable, and open to robust the API-focused certification criteria, we Interpretation of Access to ‘‘All Data competition and innovation. propose in § 170.404(a)(2)(i) that all The specific requirements of this Elements’’ published documentation be complete Condition of Certification are discussed First, we propose to adopt the Cures and available via a publicly accessible in several sections below. These Act’s API Condition of Certification in hyperlink that allows any person to requirements would address certain § 170.404(a)(1) to fully incorporate the directly access the information without implementation, maintenance, and statute’s compliance requirements. any preconditions or additional steps. business practices for which clear and Second, strictly for the scope of the API For example, the API Technology consistent parameters are needed to Condition of Certification, we propose Supplier cannot impose any access ensure that API technology is deployed to interpret the meaning of the phrase requirements, including, without in a manner that achieves the policy ‘‘all data elements of a patient’s limitation, any form of registration, goals we have described. The proposed electronic health record’’ as follows. account creation, ‘‘click-through’’ requirements would also align this For the reasons discussed above, the agreements, or requirement to provide Condition of Certification with other proposed § 170.315(g)(10) certification contact details or other information requirements and policies of the Cures criterion and associated standards and prior to accessing the documentation. Act that promote interoperability and implementation specifications would Terms and Conditions Transparency deter information blocking, as discussed facilitate API access to a limited set of in more detail in the sections that data elements (i.e., from the FHIR In addition to technical follow. resources that ARCH Version 1). documentation, we propose in Accordingly, for the purposes of § 170.404(a)(2)(ii)(A) to require API i. Scope and Compliance meeting this portion of the Cures Act’s Technology Suppliers to publish all To start this Condition of API Condition of Certification, we terms and conditions for use of its API Certification, we propose in § 170.404 to interpret the scope of: The ARCH; its technology. We believe that it is apply this Condition of Certification to associated implementation important to make this information health IT developers with health IT specifications; and the policy expressed readily accessible to API Data Providers, certified to any of the API-focused around the data elements that must be API Users, app developers, and other certification criteria. These criteria supported by (g)(10)-certified APIs (i.e., persons. This transparency would include the proposed ‘‘standardized API FHIR servers) to constitute ‘‘all data ensure that these stakeholders do not for patient and population services’’ elements.’’ Given other proposals experience ‘‘special effort’’ in the form (§ 170.315(g)(10)) and ‘‘consent related to permitting the use of updated of unnecessary costs or delays to obtain management for APIs’’ (§ 170.315(g)(11)) versions of adopted standards and the terms and conditions for API as well as the current ‘‘application implementation specifications, we technology. Further, we believe that full access—patient selection’’ expect that (g)(10)-certified APIs will be transparency is necessary to ensure that (§ 170.315(g)(7)), ‘‘application access— able to support access to more data over app developers have a thorough data category request’’ (§ 170.315(g)(8)), time in response to updates to the understanding in advance of any terms ‘‘application access—all data request’’ USCDI and the ARCH. As these updates or conditions that might apply to them (§ 170.315(g)(9)). In other words, this occur, the industry would be able to and do not encounter unanticipated entire Condition of Certification would incrementally approach the totality of hurdles once they have committed to not apply to health IT developers that data that can be electronically accessed, developing software or attempt to do not have technology certified to any exchanged, and used pursuant to the implement or deploy such software in of these API-focused certification Cures Act’s reference to ‘‘all data production. criteria. Similarly, this condition is elements.’’ We note that this requirement would solely applicable to these API-focused Again, we reiterate that this specific apply to all terms and conditions that certification criteria. As a result, the interpretation does not extend beyond apply to the API technology and its use. proposed policies for this Condition of the API Condition of Certification and As noted above, and for the purposes of Certification would not apply to a cannot be inferred to reduce the scope this proposal’s scope, ‘‘API technology’’ health IT developer’s practices or applicability of other Cures Act refers to the specified API capabilities associated with, for example, the Conditions of Certification or the for Health IT Modules certified to immunization reporting certification information blocking proposals, which § 170.315(g)(7) through (11) under the criterion adopted in § 170.315(f)(1) necessarily will include a larger scope Program. We consider ‘‘terms and because that criterion is not one of the of data. For example, other Conditions conditions’’ to include any fees, API-focused criteria. However, health IT of Certification will apply to health IT restrictions, limitations, obligations, developers should remain mindful that developer behaviors associated with registration process requirements, and other proposals in this proposed rule, data that are not part of the USCDI or other terms or conditions that would be especially those related to information ARCH, such as the proposals at 45 CFR material and needed to: blocking, could still apply to its 170.402 and the proposals in Part 171, • Develop software applications to practices associated with non-API- which apply across several stakeholders interact with the API technology; focused certification criteria. including health information networks • distribute, deploy, and enable the Given the proposed applicability of and health care providers. use of software applications in this condition to current API-focused production environments that use the criteria and that health IT developers iii. Transparency Conditions API technology; with products certified to We propose as part of this Condition • use software applications, including §§ 170.315(g)(7)–(9) would need to meet of Certification that API Technology to access, exchange, and use EHI by new compliance requirements Suppliers be required to make specific means of the API technology;

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00063 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7486 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

• use any EHI obtained by means of and/or construct terms and conditions Technology Suppliers to institute a the API technology; and for its API technology that account for process to verify the authenticity of • register software applications (as and reflect the proposals associated application developers so long as such discussed in more below). with this API Condition of Certification process is completed within five In addition, we propose in and information blocking policies. In so business days 91 of receipt of an § 170.404(a)(2)(ii)(B) that any and all far as an API Technology Supplier application developer’s request to permitted fees charged by an API would find it necessary to enforce its register their software application with Technology Supplier for the use of its published terms and conditions, we the API technology’s authorization API technology must be published and caution API Technology Suppliers to be server. To clarify, this verification described in detailed, plain language as mindful of whether such terms and process would need to focus specifically part of its publicly available terms and conditions would be acceptable and on the application developer—not its conditions. The description of the fees consistent with the aforementioned software application(s). We also clarify must include all material information, policies in the first place—as an that API Technology Suppliers would including, but not limited to, the impermissible term or condition would have the discretion to establish their persons or classes of persons to whom be problematic regardless of whether it verification process so long as the the fee applies; the circumstances in was actively enforced. process is objective and the same for all which the fee applies; and the amount We propose in § 170.404(a)(2)(ii)(C) a application developers and it can of the fee, which for variable fees must final transparency condition associated reasonably be completed within the five include the specific variable(s) and with API Technology Suppliers’ business days—otherwise such a methodology(ies) that will be used to application developer verification process could risk implicating/violating calculate the fee. processes that takes into account the other elements of this proposed API For the purposes of the specific fact that we did not propose to adopt the Condition of Certification as well as transparency conditions proposed in Dynamic Registration standard as part of information blocking behaviors. The § 170.404(a)(2) and their relationship proposed § 170.315(g)(10). Had we following includes a few non-exhaustive and applicability to API Technology proposed requiring Dynamic examples of verification techniques that Suppliers with products already Registration, we would have also could be used by an API Technology certified to § 170.315(g)(7), (8), or (9), we proposed a specific Condition of Supplier to have additional certainty propose to establish a compliance date Certification that would have outright about the application developer with of six months from the final rule’s prohibited API Technology Suppliers whom they are interacting: Instituting a effective date (which would give from identity proofing or verifying ‘‘penny verification’’ process, requiring developers approximately eight months authenticity of an app developer when some form of corporate documentation, from the final rule’s publication date) to it came to apps that were designed to or requesting other forms of revise their existing API documentation enable patient access. authenticating documentation or to come into compliance with the final On balance, however, we believe that transactions. rule. We also recognize that API permitting API Technology Suppliers to We believe that five business days is Technology Suppliers will need to institute a process to verify the sufficient time for API Technology update the proposed publicly available authenticity of application developers Suppliers to weed out malicious information from time to time. Thus, for will foster additional trust in the developers seeking to deceive the API the purposes of and with respect to growing API ecosystem. We seek Technology Supplier, API Data subsequent updates to this information, comments and recommendations on Providers or API Users, but request we expect API technology suppliers to factors that would enable registration public comment on other timing make clear to the public the timing with minimal barriers. For example, considerations. Moreover, we clarify information applicable to their permitting API Technology Suppliers to that this proposed Condition of disclosures (e.g., effective/as of date or do one- time verification of the app Certification is meant to set the upper last updated date) in order to prevent developers (or even rely on centralized bound for a verification process an API out of sync discrepancies in what an vetting by a trusted third party), which Technology Supplier would be API Technology Supplier’s public would allow the developer’s future apps permitted to take and should not be documentation states and what it may to automatically register without case- interpreted as compelling API be communicating directly to its by- case checks (or checks for each API Technology Suppliers to institute such customers (e.g., a change in fees is Technology Supplier with which the a process (i.e., API Technology directly communicated to customers but app developer interacts). One risk to Suppliers would not be required to not reflected at the publicly available consider with Dynamic Registration institute a verification process). Rather, hyperlink pursuant to its plus a prohibition on vetting, for for those API Technology Suppliers that responsibilities under this proposal). If instance, is that it would be much easier see it in their (as well as their customers an API Technology Supplier’s actions for a malicious app developer to spoof and patients) best interests to institute are out of sync with its publicly another legitimate app developer’s app. such a process, we have laid out the provided documentation, the API Such an action could ultimately lead to Technology Supplier would be at risk of confusion and distrust in the market. rules that we believe meet the Cures violating this Condition of Certification. However, the Dynamic Registration Act’s without special effort We request public comment on whether option would minimize barriers to expectations. If an API Technology this expectation should be formally registration especially for third-party Supplier chooses not to institute an app specified in regulation text or if these apps designed to enable patient access. developer verification process prior to ‘‘effective date’’ approaches for changes We seek comments on options and enabling the production use of an app, to transparency documentation are trade-offs we should consider. it would solely need to meet the common place such that it would be a Accordingly, and weighing those Maintenance of Certification standard practice as part of making this concerns with the Cures Act’s ‘‘without 91 We consider a ‘‘business day’’ to include the documentation available. special effort’’ provision and our normal work days and hours of operation during a We also note that API Technology proposed information blocking policies, week (Monday through Friday), excluding federal Suppliers would be expected to revise we specifically propose to permit API holidays and weekends.

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00064 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7487

requirement associated with enabling IT developer’s business practices may pay the API Technology Supplier’s apps for production use discussed in associated with its ‘‘API technology’’ permitted fee. In other words, these more detail below. (i.e., the capabilities certified to conditions limit the party from which We remind stakeholders that even in § 170.315(g)(7) through (11)). We seek an API Technology Supplier may the case where an API Technology comment on all of the following require payment, but they do not speak Supplier chooses not to vet app proposals. to who may pay the fee. For example, developers, the apps would not have In § 170.404(a)(3)(i)(A), we propose to if through some type of relationship/ carte blanche access to a health care establish a general prohibition on API agreement an API User or other party provider’s data. To the contrary, such Technology Suppliers imposing fees offered to pay the fee an API Data apps will still be registered and thus be associated with API technology. This Provider owed to an API Technology identifiable and able to have their access general prohibition is meant to ensure Supplier, that practice would be deactivated by an API Technology that API Technology Suppliers do not allowed and unaffected under these Supplier or health care provider (API engage in pricing practices that create conditions. This is an acceptable Data Provider) if they behave in barriers to entry and competition for practice because the fee is first arrived anomalous or malicious ways (e.g., apps and API-based services that health at between the API Technology Supplier denial of service attack). And a patient care providers seek to use. These and API Data Provider, and then API seeking access to their data using the outcomes would be inconsistent with Technology Supplier receives payment app will need to authenticate the goal of enabling API-based access, from another party via the API Data themselves (using previously issued exchange, and use of EHI by patients Provider or directly on behalf of the API credentials by a health care provider or and other stakeholders without special Data Provider. As a general matter, we trusted source) and authorize: (1) The effort. note that stakeholders should be app to connect to the FHIR server; and In establishing this general mindful of other federal and state laws (2) specify the scope of the data the app prohibition, we have been mindful of and regulations that could prohibit or may access. the need for API Technology Suppliers limit certain types of relationships As a separate matter, we also to recover their costs and to earn a involving remuneration. recognize that in order to assure health reasonable return on their investments We note that the proposed ‘‘permitted care providers that the apps they use in providing API technology that has fees conditions’’ align with the within their health IT will operate been certified under the Program. requirements of the information appropriately, will fully integrate into Accordingly, we have identified blocking exceptions proposed in 45 CFR workflow, and will not degrade overall categories of ‘‘permitted fees’’ that API 171.204 and 171.206. Any fee that system performance, that API Technology Suppliers would be would not be covered by those Technology Suppliers may establish permitted to charge and still be exceptions, and that would, therefore, additional mechanisms to vet app compliant with the Condition of be suspect under the information developers. Such mechanisms could fit Certification and Program requirements, blocking provision, would equally not into the ‘‘value-added services’’ and discuss these proposals below. We be permitted by this API Condition of permitted fee and result in the app emphasize, however, and propose in Certification. We strongly encourage being acknowledged or listed by the detail below, that API Technology readers to review our proposals health IT developer in some special Suppliers would not be permitted in associated with those exceptions, which any way whatsoever to impose fees on manner (e.g., in an ‘‘app store,’’ are contained in sections VIII.D.4 and any person in connection with an API ‘‘verified app’’ list). While our proposals VIII.D.6 of this preamble, respectively. Technology Supplier’s work to support do not specify any explicit limits to the the use of API technology to facilitate a Permitted Fees—General Conditions nature and governance of these patient’s ability to access, exchange, or We propose in § 170.404(a)(3)(i)(B) approaches, we wish to caution health use their EHI. general conditions that an API IT developers that even though such We note that other than for fees Technology Supplier’s fee must satisfy processes have a reasoned basis in charged for ‘‘value-added services’’ in order for such fee to be expressly providing an added layer of trust above (proposed in § 170.404(a)(3)(iv)), the permitted and thus not contravene the and beyond the basic production- fees permitted under this Condition of proposed Condition of Certification. readiness of an app, they can equally be Certification must arise between an API First, we propose in used as a means to prevent, limit, and Technology Supplier and an API Data § 170.404(a)(3)(i)(B)(1) that in order to otherwise frustrate innovation, Provider. Any fee that arises in be a permitted fee, a fee imposed by an competition, and access to the market. connection with an API User’s use of API Technology Supplier must be based Such an outcome would be inconsistent API technology would need to exist on objective and verifiable criteria that with the Cures Act, could directly solely between the API Data Provider are uniformly applied for all violate the specific Condition of and the API User. This policy reinforces substantially similar or similarly Certification associated with fees the autonomy that we believe API Data situated classes of persons and requests. permitted for value-added services, and Providers should have to establish This would require an API Technology could constitute information blocking. relationships with API Users. However, Supplier to apply fee criteria that, iv. Permitted Fees Conditions as discussed in detail below, API among other things, would lead an API Technology Suppliers would be Technology Supplier to come to the General Proposals Involving Fees permitted to charge API Data Providers same conclusion with respect to the As part of this API Condition of based on the usage activities of API permitted fee’s amount each time it Certification, we propose to adopt Users. interacted with a class of persons or specific conditions that would set We also seek to clarify that while the responded to a request. Accordingly, the boundaries for the fees API Technology proposed permitted fees set the fee could not be based on the API Suppliers would be permitted to charge boundaries for the fees API Technology Technology Supplier’s subjective and to whom those permitted fees could Suppliers would be permitted to charge judgment or discretion. be charged. As a reminder, these and to whom those permitted fees could Moreover, in order to be permitted, proposals would only apply to a health be charged, they do not prohibit who the fee must not be based in any part on

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00065 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7488 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

whether the API User is a competitor or with minimal tailoring, the core costs of Technology Supplier would be potential competitor, or on whether the developing its API technology should be permitted to charge fees associated with API Data Provider or API User will be allocated among those customers when API technology certified under the using the data accessed via the API recovered as a fee. The API Technology Program. A fee that satisfies one of the technology in a way that facilitates Supplier would not be permitted to permitted fees in §§ 170.404(a)(3)(ii)– competition with the API Technology recover the total of its core costs from (iv) must also satisfy each of the general Supplier. This condition is intended to each customer. Similarly, when an API conditions in § 170.404(a)(3)(i) in order ensure that any fee charged by an API Technology Supplier uses shared to be permitted and for its recovery Technology Supplier does not have the facilities and resources to support the compliant with this Condition of purpose or effect of excluding or usage of API technology, it would need Certification. creating impediments for competitors, to ensure that those shared costs were Permitted Fee for Developing, business rivals, or other persons reasonably allocated between all of the Deploying, and Upgrading API engaged in developing or enabling the customers that benefited from them. Technology use of API technology. We believe these However, whenever an API Technology fee limitations are necessary in light of Supplier is required to provide services In § 170.404(a)(3)(ii), we propose to the potential for API Technology and incur costs that are unique to a permit an API Technology Supplier to Suppliers to use their control over API particular customer, it would not need charge API Data Providers reasonable technology to engage in discriminatory to distribute those costs among other fees for developing, deploying, and practices that create barriers to API customers that had deployed its API upgrading API technology. Fees for technology. These principles are technology. ‘‘developing’’ API technology comprise consistent with the approach described Last, we propose in the API Technology Supplier’s costs of in section VIII of this preamble § 170.404(a)(3)(i)(B)(4) to require that in designing, developing, and testing API (‘‘information blocking’’). order to be a permitted fee, the API technology to specifications that fulfill Second, we propose in Technology Supplier must ensure that the requirements of the API-focused § 170.404(a)(3)(i)(B)(2) that in order to fees are not be based in any part on certification criteria adopted or be a permitted fee, a fee imposed by an whether the requestor or other person is proposed for adoption at 45 CFR API Technology Supplier must be a competitor, potential competitor, or 170.315(g)(7) through (g)(11). Fees for reasonably related to the API will be using the API technology in a developing API technology must not Technology Supplier’s costs of way that facilitates competition with the include the API Technology Supplier’s supplying and, if applicable, supporting API Technology Supplier. The use of costs of updating the non-API related the API technology to, or at the request such criteria would be suspect because capabilities of the API Technology of, the API Data Provider to whom the it suggests the fee the API Technology Supplier’s existing health IT, including fee is charged. For example, the API Supplier is charging is not based on its its databases, as part of its development Technology Supplier would not be reasonable costs to provide the API of the API technology. These costs permitted to charge a fee when the technology or services and may have the would be connected to past business underlying costs relevant to the supply purpose or effect of excluding or decisions made by the API Technology or service have already been accounted creating impediments for competitors, Supplier and typically arise due to for or recovered through other fees business rivals, or other persons health IT being designed or (regardless of whether such fees were engaged in developing or enabling the implemented in nonstandard ways that charged to the API Data Provider or to use of API technologies and services. unnecessarily increase the complexity, other persons). Moreover, an API We request comments on these difficulty or burden of accessing, Technology Supplier that conditioned general conditions for permitted fees exchanging, or using EHI. The recovery access to its API technology on revenue- and whether commenters believe we of the costs associated with updating an sharing or the entry into a royalty have created effective guardrails to API Technology Supplier’s health IT agreement would be at significant risk of ensure that fees do not prevent EHI from generally would be inconsistent with imposing a fee that bore no plausible being accessed, exchanged, and used the Cures Act requirement that API relation to the costs incurred by the API through the use of APIs without special technology be deployed ‘‘without Technology Supplier to develop the API effort. special effort.’’ technology or support its use by API The API Technology Supplier’s fees Specific Proposed Permitted Fees Users. for ‘‘deploying’’ API technology Third, we propose in As noted above, we propose that API comprise the API Technology Supplier’s § 170.404(a)(3)(i)(B)(3) to require that in Technology Suppliers would be costs of operationalizing API technology order to be a permitted fee, the costs of prohibited from charging fees associated in a production environment. Such fees supplying, and if applicable, supporting with API technology unless such fees include, but are not limited to, standing the API technology upon which the fee are expressly permitted. Additionally, up hosting infrastructure, software is based must be reasonably allocated as a reminder, the scope of ‘‘API installation and configuration, and the among all customers to whom the API technology’’ subject to these proposals creation and maintenance of API Data technology is supplied or for whom it is would only include certified health IT Provider administrative functions. An supported. A reasonable allocation of that fulfill the API-focused certification API Technology Supplier’s fees for costs would require that the API criteria adopted or proposed for ‘‘deploying’’ API technology does not Technology Supplier allocate its costs in adoption at 45 CFR 170.315(g)(7) include the costs associated with accordance with criteria that are through (g)(11). Thus, all other API managing the traffic of API calls that reasonable and between only those API functionality provided by a health IT access the API technology, which an Data Providers that either cause the developer with its product(s) that have API Technology Supplier can only costs to be incurred or benefit from the no link to these certified capabilities recover under the permitted fee for associated supply or support of the API would not be subject to this Condition usage support costs under technology. If an API Technology of Certification. § 170.404(a)(3)(iii). For clarity, we Supplier developed API technology that The following proposals outline the reiterate that for the purpose of this could be supplied to multiple customers specific circumstances in which an API Condition of Certification, we consider

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00066 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7489

that API technology is ‘‘deployed’’ by and earn a reasonable return on their Technology Supplier acts on behalf of the customer—the API Data Provider— investments so that they have adequate the API Data Provider to deploy its API that purchased or licensed it. incentives to make continued technology. Conversely, in scenarios The API Technology Supplier’s fees investments in these technologies. In where the API Data Provider, such as a for ‘‘upgrading’’ API technology particular, we anticipate that API large hospital system, assumes full comprise the API Technology Supplier’s Technology Suppliers will need to responsibility for the technical costs of supplying an API Data Provider continually expand the data elements infrastructure necessary to deploy and with an updated version of API and upgrade the capabilities associated host the API technology it has acquired, technology. Such costs would include with Certified APIs as the FHIR the volume and scale of its usage would the costs required to bring API standard and its implementation be the API Data Provider’s sole technology into conformity with new specifications mature, and the National responsibility. As a result, in this requirements of the Program, upgrades Coordinator expands the USCDI and scenario and under our proposal’s to implement general software updates ARCH. structure, an API Technology Supplier (not otherwise covered by development would not be permitted to charge usage- Permitted Fee To Recover Costs of fees or under warranty), or developing based fees. Instead, the API Technology Supporting API Usage for Purposes and releasing newer versions of the API Supplier would be limited to the fees it Other Than Patient Access, Exchange, technology at the request of an API Data would be permitted to recover through and Use Provider. the ‘‘development, deployment, The nature of the costs that can be In § 170.404(a)(3)(iii) we propose to upgrade’’ permitted fee discussed above. charged under this category of permitted permit an API Technology Supplier to We reiterate, that ‘‘usage-based’’ fees fees will depend on the scope of the charge usage-based fees to API Data would need to be settled between an work to be undertaken by an API Providers to the extent that the API API Technology Supplier and API Data Technology Supplier (i.e., how much or technology is used for purposes other Provider. The API Technology Supplier how little labor an API Data Provider than facilitating access, exchange, or use would have no standing to go around or requires of the API Technology Supplier of EHI by patients or their applications, through the API Data Provider to issue to deploy and upgrade the API technologies, or services. fees to, for example, a population health technology being supplied). For We consider ‘‘usage-based’’ fees to be analytics company engaged by an API example, where an API Data Provider the fees imposed by an API Technology Data Provider who accesses the API decides to fully outsource the Supplier to recover the costs that would Data Provider’s data via the API deployment of its API technology to its typically be incurred supporting API technology. API Technology Supplier, the API interactions at increasing volumes and We propose that any usage-based fees Technology Supplier’s costs will scale within established service levels. associated with API technology be include the work associated with the That is, ‘‘usage-based’’ fees recover costs limited to the recovery of the API development of the API technology, the incurred by an API Technology Supplier Technology Supplier’s ‘‘incremental work deploying the API technology, and due to the actual use of the API costs.’’ An API Technology Supplier’s any work upgrading the API technology. technology once it has been deployed ‘‘incremental costs’’ comprise the API We propose that any fees that an API (e.g., costs to support a higher volume Technology Supplier’s costs that are Technology Supplier charges for of traffic, data, or number of apps via directly attributable to supporting API developing, deploying, or upgrading the API technology). We acknowledge interactions at increasing volumes and API technology must be charged solely that API Technology Suppliers could scale within established service levels. to the API Data Provider(s) for whom adopt a range of pricing methodologies We propose than an API Technology the capabilities are deployed. We when charging for the support of API Supplier should ‘‘price’’ its costs of propose this limitation because we usage. We expect that API usage support supporting access to the API technology believe that these costs should be fees would only come into play when by reference to the additional costs that negotiated between the API Technology the API Technology Supplier acts on the API Technology Supplier would Supplier that supplies the capabilities behalf of the API Data Provider to incur in supporting certain volumes of and the API Data Provider (i.e., health deploy its API technology. Thus, the API use. In practice, we expect that this care provider) that implements them in costs recovered under ‘‘usage-based’’ means that API Technology Suppliers its production environment. In our fees would only be able to reflect ‘‘post- will offer a certain number of ‘‘free’’ API view, it is inappropriate to pass these deployment’’ costs. As such, ‘‘usage- calls based on the fact that, up to a costs on to API Users as doing so would based’’ fees would not be allowed to certain threshold, the API Technology impose considerable costs on the API include any costs necessary to prepare Supplier will not incur any material Data Provider’s current or potential and ‘‘get the API technology up, costs in supporting API technology in partners, such as those offering third- running, and ready for use,’’ which are addition to the costs recovered for party applications and services, as well costs that we propose should be deployment services. However, after as the end-users of API technology and recovered as part of the deployment this threshold is exceeded, we expect would amount to the kind of ‘‘special services delivered by the API that the API Technology Supplier will effort’’ that the Cures Act’s API Technology Supplier if permitted under impose usage-based costs commensurate Condition of Certification seeks to § 170.404(a)(3)(ii). We believe this to the additional costs that the API prevent. Condition of Certification offers the Technology Supplier must incur to Subject to the general conditions flexibility necessary to accommodate support API technology use at proposed in § 170.404(a)(3)(i) and reasonable pricing methodologies and increasing volumes and scale. discussed above, API Technology will allow API Technology Suppliers to We expect that API Technology Suppliers can recover the full range of explore innovative approaches to Suppliers would charge fees that are reasonable costs associated with recovering the costs associated with correlated to the incremental ratchetting developing, deploying, and upgrading supporting API use as a permitted fee. up of the cost required to meet API technology over time. We believe it As discussed above, we expect that increased demand. For example, if, at a is important that API Technology API usage support fees would only certain volume of API calls, the API Suppliers be able to recover these costs come into play when the API Technology Supplier needed to deploy

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00067 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7490 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

additional server capacity, the So long as the API Technology Supplier based costs associated with the API associated incremental cost of bringing made a realistic estimate of the technology. an additional server online could be anticipated volume and support level, Any unreasonable fees associated passed on to the API Data Provider the legitimacy of the API Technology with a patient’s access to their EHI may because the API technology deployed on Supplier’s fees, and its ability to recover be suspect under the information behalf of the API Data Provider was the them as permitted fees, would be blocking provision. Such fees may also subject of the higher usage. Up until the unaffected by API Users making lower be inconsistent with an individual’s point that the threshold is reached, the than expected use of API technology. right of access to their PHI under the additional server capacity was not In the context of this proposed HIPAA Privacy Rule (45 CFR 164.524).) required and so the API Technology permitted fee’s scope and the proposed In addition to our proposal in Supplier would not be permitted to general prohibition on fees, we seek to § 170.404(a)(3)(iii)(A) and detailed recover the cost associated with it. make clear that API Technology above that this permitted fee would not Moreover, the additional server capacity Suppliers would be prohibited from include any costs incurred by the API would support ongoing demand up to a charging (or including in their contracts Technology Supplier to support uses of certain additional volume, and so the and agreements with API Data the API technology that facilitate a API Technology Supplier would not be Providers) any usage-based fees for API patient’s ability to access, exchange, or permitted to recover the costs of further uses that are associated with the access, use their electronic health information, additional server capacity until the then exchange, and use of EHI by patients or we also propose to explicitly exclude current capacity was exhausted. their applications, technologies, or two additional costs from this permitted Notwithstanding the above, we note services. This would include, among fee. In § 170.404(a)(3)(iii)(B), we propose that API Technology Suppliers may other things, API calls or other that this permitted fee would not choose to charge for their API usage transactions initiated by or on behalf of include costs associated with intangible support services on a ‘‘pay as you go’’ a patient, including third parties (e.g., assets (including depreciation or loss of basis, such as a fee-per-call pricing an application or any other technology value), except the actual development or structure. This approach could be or service) authorized by the patient or acquisition costs of such assets. For consistent with the requirement that the their representative to request data on instance, an API Technology Supplier API Technology Supplier only impose their behalf. could not charge an API Data Provider its incremental costs, and the Usage fees associated with the access, a fee based on the purported ‘‘cost’’ of requirements of this Condition of exchange, and use of EHI by patients is allowing the API Data Provider to use Certification more generally. However, a specific example of a prohibited fee the API Technology Supplier’s patented depending on the amount being that would fit under the general API technology. As discussed in more charged, this pricing model is open to prohibition of a ‘‘fee not otherwise detail in section VIII.D.4 (Information abuse, with API Data Providers at risk permitted’’ and is based on several Blocking), we believe it would be of paying unreasonably high fees if the considerations. First, such fees between inappropriate to permit an actor to volume of API use is high and when the an API Technology Supplier and API charge a fee based on these API Data Provider does not share in the Data Provider would likely be passed on considerations, which are inherently benefits enjoyed by the API Technology directly to patients, creating a subjective and could invite the kinds of Supplier when delivering a service at significant impediment to their ability rent-seeking and opportunistic pricing scale. As such, the API Technology to access, exchange, and use their EHI, practices that create barriers to access, Supplier would need to be careful to without special effort, through use, and exchange of EHI and impede ensure that the total fees paid by an API applications and technologies of their interoperability. Data Provider were reasonably related to choice. More fundamentally, most of the In § 170.404(a)(3)(iii)(C), we propose the API Technology Supplier’s costs of information contained in a patient’s that this permitted fee would not supporting the API technology. Where electronic record has been documented include opportunity costs, except for the the fees paid over a reasonable during the practice of medicine or has reasonable forward-looking cost of measuring period were not reasonably otherwise been captured in the course of capital. These speculative costs could related to the API Technology providing health care services to include revenues that an API patients. In our view, patients have Supplier’s costs, they would not be Technology Supplier could have earned effectively paid for this information, permitted. had it not provided the API technology. We are also aware that API either directly or through their We clarify that the exclusion of Technology Suppliers may offer a employers, health plans, and other opportunity costs would not preclude pricing structure for API usage support entities that negotiate and purchase an API Technology Supplier from based on unlimited API calls. That is, health care items and services on their recovering its reasonable forward- the API Technology Supplier may behalf. Thus, our proposal reflects our looking cost of capital. We believe these charge a flat-fee irrespective of the belief that it is inappropriate to charge costs are relatively concrete and that volume of traffic accessing the API patients additional costs to access this permitting their recovery will protect technology. Such a pricing model would information, whether those costs are be allowed under the proposed charged directly to patients or passed on incentives for API Technology Suppliers condition provided that the API as a result of fees charged to persons to invest in developing and providing Technology Supplier’s fee for API usage that provide apps, technologies, and interoperability elements (as described support was reasonably related to the services on a patient’s behalf. in section VIII.D.4). cost of the services that it had agreed to To be clear, if an API Data Provider Permitted Fee for Value-Added Services provide. This would mean that the API sought to employ API technology for the In § 170.404(a)(3)(iv) we propose to Technology Supplier would need to limited purpose of making EHI available permit an API Technology Supplier to make a realistic estimate of the volume to patients and their apps, the API Data charge fees to API Users 92 for value- of API calls that it would need to Provider’s API Technology Supplier support to fulfill any service level would have no legitimate basis to charge 92 In this context a health care provider, which promised, and calculate its fee based on the API Data Provider, or any other could otherwise be an ‘‘API Data Provider’’ in one the costs of supporting that call volume. person, for the ‘‘patient access’’ usage- context, may equally be an API User in a different

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00068 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7491

added services supplied in connection special effort. We are aware that API • Any fee for access to the with software that can interact with the Technology Suppliers offer services documentation that an API Technology API technology. These ‘‘value-added associated with the listing and Supplier is required to publish or make services’’ would need to be provided in promotion of apps beyond basic app available under this Condition of connection with and supplemental to placement. Such fees would be Certification. the development, testing, and permitted, so long as the API • Any fee for access to other types of deployment of software applications Technology Supplier ensured that basic documentation or information that a that interact with API technology. access and listing in the app store was software developer may reasonably Critically, fees would not be permitted provided free of charge if an app require to make effective use of API if they interfere with an API User’s developer depended on such listing to technology for any legally permissible ability to efficiently and effectively efficiently and effectively develop and purpose. • develop and deploy production-ready deploy production-ready apps without Any fee in connection with any software. This means that in order to be special effort. Fees charged for services that would be essential to a permitted, an API User could not be additional/specialized technical support developer or other person’s ability to required to incur the fee in order to or promotion of the API User’s app develop and commercially distribute develop and deploy a production-ready beyond these basic access and listing production-ready applications that use software application that interacts with services would also be permitted. In API technology. These services could the API technology acquired by the API contrast, if an API Technology Supplier include, for example, access to ‘‘test Data Provider. Rather, a fee will only be required, for example, a software environments’’ and other resources that permitted if it relates to a service that a developer’s app to go through a paid an app developer would need to software developer can elect to listing process as a dependency/ efficiently design and develop apps. The purchase, but is not required to precondition to be able to be deployed services could also include access to purchase in order to develop and deploy (and generally accessible) to the API distribution channels if they are production-ready apps. Technology Supplier’s health care necessary to deploy production-ready We believe it appropriate to permit provider customers to use, this would software and to production resources, this type of fee because API Technology not be a permitted fee under this such as the information needed to Suppliers may offer a wide-range of Condition of Certification, would connect to FHIR servers (endpoints) or market differentiating services to make constitute special effort, and could raise the ability to dynamically register with it attractive for API Users to develop information blocking concerns. an authorization server. software applications that can interact Permitted Fees Request for Comment with the API technology supplied by an Prohibited Fees We request comment on any API Technology Supplier. Such services As discussed above, we proposed that additional specific ‘‘permitted fees’’ not could include advanced training, any API-related fee imposed by an API addressed above that API Technology premium development tools and Technology Supplier that is not Suppliers should be able to recover in distribution channels, and enhanced expressly permitted is prohibited. This order to assure a reasonable return on compatibility/integration testing approach is necessary because, as investment. Furthermore, we request assessments. For example, an API discussed in section VIII.C.5.c of this comment on whether it would be Technology Supplier would be proposed rule, we continue to receive prudent to adopt specific, or more permitted to charge fees for value-added evidence that some health IT developers granular, cost methodologies for the services that would be associated with are engaging in practices that create calculation of the permitted fees. but go beyond the scope set by the special effort when it comes to API Commenters are encouraged to consider, (g)(10)–certified API, such as write technology. These practices include fees in particular, whether the approach we access, co-branded integration into the that create barriers to entry or have described will be administrable API Technology Supplier’s product(s) competition as well as rent-seeking and and appropriately balance the need to workflow, co-marketing arrangements, other opportunistic behaviors. For ensure that patients, providers, app and promoted placement in an API example, some health IT developers are developers, and other stakeholders do Technology Supplier’s app store. That conditioning access to technical not encounter unnecessary costs and said, we caution API Technology interoperability documentation on other special effort with the need to Suppliers that value-added services revenue-sharing or royalty agreements provide adequate assurance to API would have to be made available in a that bear no plausible relation to the Technology Suppliers, investors, and manner that complies with other costs incurred by the health IT innovators that they will be able to earn requirements of this Condition of developer to provide or enable its use. a reasonable return on their investments Certification and with the information We are also aware of discriminatory in API technology. We welcome blocking provision. pricing policies that have the purpose or comments on whether the approach To illustrate the scope of the fees effect of excluding competitors from the adequately balances these concerns or permitted under this proposal, we use of APIs and other interoperability would achieve our stated policy goals, clarify that the permitted value-added elements. These practices close off the and we welcome comments on potential services fee would enable an API market to innovative applications and revisions or alternative approaches. We Technology Supplier to recover certain services that could empower patients encourage detailed comments that costs associated with operating an ‘‘app and enable providers to deliver greater include, where possible, economic store.’’ However, those fees cannot value and choice to health care justifications for suggested revisions or interfere with an API User’s ability to consumers and additional service alternative approaches. efficiently and effectively develop and providers. deploy production-ready apps without To address these concerns we provide Record-Keeping Requirements the following non-exhaustive examples To provide appropriate context. Given this potential dual role for health of fees for services that API Technology accountability, we propose in care providers, we have focused on API Users as the party to whom a fee may be charged for the Suppliers would be prohibited from § 170.404(a)(3)(v) that API Technology purposes of this permitted fee. charging: Suppliers must keep for inspection

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00069 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7492 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

detailed records of all fees charged with iv. Openness and Pro-Competitive technology. As a starting point, we respect to API technology and all costs Conditions propose to require in that it claims to have incurred to We propose that API Technology § 170.404(a)(4)(i)(A) that API provide API technology to API Data Suppliers would have to comply with Technology Suppliers comply with all Providers. To provide assurance that the certain requirements to promote an of the requirements discussed in section API Technology Supplier’s fees are open and competitive marketplace. As a VIII.C.4.b of this proposed rule reasonably related to the API general condition, we propose in regarding the non-discriminatory Technology Supplier’s costs, the API § 170.404(a)(4) that API Technology provision of interoperability elements. Technology Supplier would need to Suppliers must grant API Data Providers Accordingly, and consistent with developers’ obligations under the document, with the same level of detail, (i.e., health care providers who Program and our expectation that API any fees charged and associated costs purchase or license API technology) the technology be truly ‘‘open,’’ we propose incurred to provide other services to sole authority and autonomy to permit to require that API Technology which any portion of the costs could API Users to interact with the API Suppliers must provide API technology reasonably be attributed. For example, if technology deployed by the API Data to API Data Providers on terms that are the API Technology Supplier charges a Provider. We reinforce this general no less favorable than they would fee that reflects its costs for internet condition through more specific provide to themselves and their servers used to provide the API proposed conditions proposals customers, suppliers, partners, and technology, the API Technology discussed below that would require API Supplier would need to document the other persons with whom they have a Technology Suppliers to provide business relationship. This requirement costs of any other internet-based equitable access to API technology, services it provides, as well as any other would apply to both price and non-price which would include granting the rights terms and thus would apply to any fees purposes for which the internet servers and providing the cooperation necessary are used. that the API Technology Supplier is to enable apps to be deployed that use permitted to charge under the Separately, an API Technology the API technology to access, exchange, Supplier would need to document the ‘‘permitted charges conditions’’ of this and use EHI in production Condition of Certification. We believe criteria it used to allocate any costs environments. across relevant customers, requestors, or this requirement would ensure that API As important context for these Data Providers (i.e., health care other persons. The criteria must be proposals, we note that the API documented in a level of detail that providers) who purchase or license API technology required by this Condition of technology have sole authority and would enable determination as to Certification falls squarely within the whether the API Technology Supplier’s autonomy to permit third-party software concept of ‘‘essential interoperability developers to connect to and use the cost allocations are objectively elements’’ described in section reasonable and comply with the cost API technology they have acquired. VIII.C.4.b of this preamble and, as such, Next, we propose in accountability requirements, including are subject to strict protections under § 170.404(a)(4)(i)(B) that any terms and whether fees reflect the API Technology the information blocking provision. As conditions associated with API Supplier’s actual costs reasonably a corollary, to the extent that API technology would have to be based on incurred, were allocated reasonably and Technology Suppliers claim an objective and verifiable criteria that are between only those API Data Providers intellectual property right or other uniformly applied for all substantially that either cause the costs to be incurred proprietary interest in the API similar or similarly situated classes of or benefit from the associated supply or technology, they must take care not to persons and requests. For example, if support of the API technology, and were impose any fees, require any license the API Technology Supplier applied an distributed across customers and other terms, or engage in any other practices ‘‘app store’’ entry/listing process relevant persons in a permissible that could add unnecessary cost, unequally and added arbitrary criteria manner, as described above. difficulty, or other burden that could based on the use case(s) an app was We note that an API Technology impede the effective use of the API focused on, such business practices Supplier must retain its accounting technology for the purpose of enabling would not comply with this specific records consistent with the retention or facilitating access, exchange, or use of condition and could also be in violation requirement proposed for adoption as EHI. Moreover, even apart from these of the information blocking provision. part of the Assurances Condition of information blocking considerations, we Moreover, we propose in Certification (proposed for adoption in believe that, as developers of technology § 170.404(a)(4)(i)(C) that an API § 170.402). In the event that a potential certified under the Program, API Technology Supplier would be violation of this Condition and Technology Suppliers owe a special prohibited from offering or varying such Maintenance of Certification creates a responsibility to patients, providers, and terms or conditions on the basis of conformance fact-finding scenario by other stakeholders to make API impermissible criteria, such as whether ONC or information blocking is technology available in a manner that is the API User with whom the API Data investigated, we believe that this period truly ‘‘open’’ and minimizes any costs Provider has a relationship is a of time would provide ONC with or other burdens that could result in competitor, potential competitor, or will appropriate visibility into the API special effort. The proposed conditions be using EHI obtained via the API Technology Supplier’s business set forth below are intended to provide technology in a way that facilitates practices. clear rules and expectations for API competition with the API Technology We request comment on whether Technology Suppliers so that they can Supplier. The API Technology Supplier these requirements provide adequate meet these obligations. would also be prohibited from taking traceability and accountability for costs into consideration the revenue or other permitted under this API Condition of Non-Discrimination value the API User with whom the API Certification. We also seek comment on We propose in § 170.404(a)(4)(i) that Data Provider has a relationship may whether to require more detailed an API Technology Supplier must derive from access, exchange, or use of accounting records or to prescribe adhere to a strictly non-discriminatory EHI obtained by means of the API specific accounting standards. policy regarding the provision of API technology. We believe these proposals

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00070 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7493

will help promote greater equity and • Enabling the use of the VIII.D.3.c of this preamble, health IT competition in market as well as interoperable products or services in developers should generally be prevent discriminatory business production environments, including permitted to charge reasonable royalties practices by API Technology Suppliers. accessing and enabling the exchange for the use of their intellectual property, and use of electronic health Rights To Access and Use API we consider API technology to be a information. Technology special case. Certified health IT Relatedly, in § 170.404(a)(4)(ii)(B) we developers (i.e., API Technology We propose in § 170.404(a)(4)(ii)(A) propose to prohibit an API Technology Suppliers) are required to provide these that an API Technology Supplier would Supplier from imposing any collateral capabilities as part of their statutory have to make API technology available terms or agreements that could interfere duty to facilitate the access, exchange, in a manner that enables API Data with or lead to special effort in the use Providers and API Users to develop and of API technology for any of the above and use of patient health information deploy apps to access, exchange, and purposes. We note that these collateral from EHRs ‘‘without special effort.’’ We use EHI in production environments. To terms or agreements may also implicate believe the language requiring that these this end, we propose that an API the information blocking provision for capabilities be ‘‘open’’ precludes an API Technology Supplier must have and, the reasons described in section Technology Supplier from conditioning upon request, must grant to API Data VIII.D.3.c of this preamble. These access to API technology on the Providers and their API Users all rights specific proposed conditions would payment of a royalty or other fee, that may be reasonably necessary to expressly prohibit an API Technology however ‘‘reasonable’’ the fee might access and use API technology in a Supplier from conditioning any of the otherwise be. production environment. In other rights described above on the We clarify that the prohibitions words, this proposal is focused on the requirement that the recipient of the explained above against additional provision of rights reasonably necessary rights do, or agree to do, any of the developer or Health IT Module to access and use API technology and following: does not extend to other intellectual • certification requirements and, Pay a fee to license the rights separately, against requirements for property maintained by the API described above, including but not reciprocal access to application data, are Technology Supplier, especially limited to a license fee, royalty, or within the scope of the collateral terms intellectual property that has no nexus revenue-sharing arrangement. with the access and use of API • Not compete with the API prohibited by proposed § 171.206 even technology. In situations where such a Technology Supplier in any product, though these additional API Technology nexus exists, even partially, the API service, or market. Supplier requirements are not explicitly Technology Supplier would have the • Deal exclusively with the API referenced by that exception because duty to determine a method to grant the Technology Supplier in any product, they are not generally applicable to all applicable rights reasonably necessary service, or market. types of interoperability elements. to access and use the API technology. • Obtain additional licenses, Nevertheless, permitting an API And if practicable, under these partial products, or services that are not related Technology Supplier to impose these cases, we note that it would be possible to or can be unbundled from the API kinds of additional requirements would for the API Technology Supplier to technology. be inconsistent with the Cures Act’s • exclude the intellectual property that License, grant, assign, or transfer expectation that API technology be would have no impact on the access and any intellectual property to the API made available openly and in a manner use of the API technology. Technology Supplier. that promotes competition. For the same Accordingly, following our proposal, • Meet additional developer or reason such practices may raise API Technology Suppliers would need product certification requirements. information blocking concerns. to grant API Data Providers and their • Provide the API Technology API Users with rights that could include Supplier or its technology with API Technology Suppliers—Additional but not be limited to the following in reciprocal access to application data. Obligations order to sufficiently support the use of These prohibitions largely mirror the API technology: those proposed under the exception to To support the use of API technology • For the purposes of developing the information blocking definition in in production environments, we products or services that are designed to § 171.206 and reflect the same concerns propose in § 170.404(a)(4)(iii) that an be interoperable with the API expressed in that context in section API Technology Supplier must provide Technology Supplier’s health IT or with VIII.D.3.c of this preamble. However, we all support and other services that are health IT under the API Technology note the following important reasonably necessary to enable the Supplier’s control. distinction: Whereas proposed § 171.206 effective development, deployment, and • Any marketing, offering, and would permit a developer to charge a use of API technology by API Data distribution of interoperable products reasonable royalty to license Providers and its API Users in and services to potential customers and interoperability elements, this API production environments. In general, users that would be needed for the API Condition of Certification would not the precise nature of these obligations technology to be used in a production permit any such royalty, license fee, or will depend on the specifics of the API environment. Note, API Technology other type of fee of any kind whatsoever Technology Supplier’s technology and Suppliers, pursuant to the ‘‘value-added pursuant to the general fee prohibition services’’ permitted fee, would be able proposed in the ‘‘permitted charges the manner in which it is implemented to offer and charge for services such as condition.’’ This additional limitation and made available for specific preferential marketing agreements, co- reflects the more exacting standards that customers. Therefore, with the marketing agreements, and other apply to API Technology Suppliers with following exceptions, we do not business arrangements so long as such respect to the provision of API delineate the API Technology Supplier’s services are beyond what is necessary technology under this Condition of specific support obligations and instead for the API technology to be put into use Certification. While we believe that, for propose a general requirement to this in a production environment. the reasons described in section effect in § 170.404(a)(4)(iii).

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00071 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7494 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

Changes and Updates to API this Condition of Certification provided solely meet this one business day Technology and Terms and Conditions they are tailored and do not requirement from the point of having We propose to require in unnecessarily interfere with the use of received a request for registration. API technology. From an information § 170.404(a)(4)(iii)(A) that API ii. Publication of FHIR Endpoints blocking standpoint, if such practices Technology Suppliers must make In order to interact with a FHIR reasonable efforts to maintain the interfered with access, exchange, or use of EHI, the API Technology Supplier RESTful API, an app needs to know the compatibility of the API technology they ‘‘FHIR Service Base URL,’’ which is develop and assist API Data Providers to could seek coverage under the exceptions to the information blocking often referred to colloquially as a ‘‘FHIR deploy in order to avoid disrupting the server’s endpoint.’’ 93 The public use of API technology. Similarly, we provision described in section VIII.D of this preamble. For instance, if the availability and easy accessibility of this propose in § 170.404(a)(4)(iii)(B) that information is a central necessity to prior to making changes or updates to suspended access was in response to a privacy exigency, the API Technology assuring the use of FHIR-based APIs its API technology or to the terms or Supplier may be able to seek coverage without special effort, especially for conditions thereof, an API Technology under the exception for promoting the patient access apps. Accordingly, we Supplier would need to provide notice privacy of EHI at proposed § 171.202. propose to adopt in § 170.404(b)(2) a and a reasonable opportunity for its API specific requirement that an API Data Provider customers and registered e. Maintenance of Certification Technology Supplier must support the application developers to update their Requirements publication of Service Base URLs for all applications to preserve compatibility We propose to adopt Maintenance of its customers, regardless of those that with its API technology or to comply requirements for this Condition of are centrally managed by the API with any revised terms or conditions. Certification. These maintenance Technology Supplier or locally Without this opportunity, clinical and requirements would be duties that we deployed, and make such information patient applications could be rendered believe the Cures Act expected API publicly available (in a computable inoperable or operate in unexpected Technology Suppliers (i.e., health IT format) at no charge. In instances where ways unbeknownst to the users or developers) would need to comply with an API Technology Supplier is software developers. in the course of maintaining their contracted by an API Data Provider to Further, we note that this proposal Health IT Module(s)’ certification. manage its FHIR server, we expect that aligns with the exception to the this administrative duty will be i. App Registration Timeliness information blocking definition relatively easy to manage. In instances proposed in § 171.206. As explained in In the specific context of application where an API Data Provider assumes section VIII.D.3.c of this preamble, the registration, we wish to underscore that full responsibility to ‘‘locally manage’’ information blocking definition would to provide a frictionless experience for its FHIR server, the API Technology be implicated were an API Technology developers of these applications and Supplier would be required, pursuant to Supplier to make changes to its API individuals that use them, an API this proposed maintenance requirement, technology that ‘‘break’’ compatibility or Technology Supplier would be required to obtain this information from its otherwise degrade the performance or to provide all services and other support customers. We strongly encourage API interoperability of the licensee’s necessary to ensure that such apps can Technology Suppliers, health care products or services that incorporate the be deployed and used in production providers, HINs and patient advocacy licensed API technology. We propose without any additional assistance or organizations to coalesce around the these additional safeguards are intervention by the API Technology development of a public resource or important in light of the ease with Supplier. For this reason, we propose in service from which all stakeholders which an API Technology Supplier § 170.404(b)(1) a specific requirement could benefit. We believe this would could make subtle ‘‘tweaks’’ to its for API Technology Suppliers that they help scale and enhance the ease with technology or related services, which would need to ‘‘register’’ (in connection which Service Base URLs could be could disrupt the use of the licensee’s with the API technology functionality obtained and used. compatible technologies or services and proposed in § 170.315(g)(10)(iii)) and result in substantial competitive and enable all applications for production iii. Providing (g)(10)–Certified APIs to consumer injury. use within one business day of API Data Providers We clarify that this requirement completing its verification of an We propose in § 170.404(b)(3) that an would in no way prevent an API application developer’s authenticity as API Technology Supplier with API Technology Supplier from making described in proposed technology previously certified to the improvements to its technology or § 170.404(a)(2)(ii)(C). We propose this certification criterion in § 170.315(g)(8) responding to the needs of its own explicit requirement is necessary in must provide all API Data Providers customers or users. However, the API order to ensure that a patient’s ability to with such API technology deployed Technology Supplier would need to use an app of their choice is not with API technology certified to the demonstrate that whatever actions it artificially or intentionally slowed by an certification criterion in § 170.315(g)(10) took were necessary to accomplish these API Technology Supplier, causing within 24 months of this final rule’s purposes and that it afforded the special effort on the part of the patient effective date. We believe this licensee a reasonable opportunity under to gain access to their EHI. We also Maintenance of Certification the circumstances to update its emphasize that this is specific duty for requirement will permit ONC to monitor technology to maintain interoperability. API Technology Suppliers in the course and facilitate the rollout to health care Relatedly, we recognize that an API of maintaining the Health IT Module(s)’ providers of this important Technology Supplier may have to certificate to which their API technology functionality. This is of particular suspend access or make other changes is associated. In instances where an API relevance as we propose below to immediately and without prior notice in Technology Supplier chooses not to include this functionality in the 2015 response to legitimate privacy, security, perform app developer verification Base EHR definition in place of the or patient safety-related exigencies. processes described in proposed Such practices would be permitted by § 170.404(a)(2)(ii)(C), it would need to 93 http://hl7.org/fhir/http.html#general.

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00072 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7495

current ‘‘application access—data health IT developers have successfully health IT deployed in operational category request’’ certification criterion tested the real world use of the production settings is demonstrating (§ 170.315(g)(8)), which means health technology for interoperability in the continued compliance to certification care providers will need this type of setting in which such technology criteria and functioning with the functionality to meet the Certified EHR would be marketed. The Cures Act intended use cases as part of the overall Technology (CEHRT) for associated defines interoperability as ‘‘health maintenance of a health IT’s Centers for Medicare & Medicaid information technology that enables the certification. Real world testing should Services (CMS) programs. secure exchange of electronic health ensure certified health IT has the ability information with, and use of electronic f. 2015 Edition Base EHR Definition to share electronic health information health information from, other health with other systems. Real world testing As described in detail above, we have information technology without special should assess that the certified health IT propose to adopt a new certification effort on the part of the user; allows for is meeting the intended use case(s) of criterion in § 170.315(g)(10) that would complete access, exchange, and use of the certification criteria to which it is replace the current criterion adopted in all electronically accessible health certified within the workflow, health IT § 170.315(g)(8) and as referenced in the information for authorized use under architecture, and care/practice setting in 2015 Edition Base EHR definition applicable state or federal law; and does which the health IT is implemented. expressed in § 170.102. This change is not constitute information blocking as Accordingly, we propose that successful necessary to fully implement the Cures also defined by the Cures Act.’’ 94 We real world testing means for the purpose Act and ensure that API Technology propose to codify this interoperability of this Condition of Certification that: Suppliers have the requisite incentive to definition in § 170.102. We further note • The certified health IT continues to deploy standardized APIs that can be that we propose in section VIII of this be compliant to the certification criteria used ‘‘without special effort’’ and API proposed rule to codify the definition of to which it is certified, including the Data Providers have added incentive to information blocking included in the required technical standards and adopt such functionality. As result, we Cures Act in § 171.103. vocabulary codes sets; propose to create a phase-in for the The Program issues, and will continue • The certified health IT is proposed API certification criterion in to issue under our real world testing exchanging electronic health § 170.315(g)(10) from the issuance of a approach, certifications to health IT information in the care and practice subsequent final rule. This phase-in through a process whereby health IT is settings for which it is intended for use; period includes separate and sequential assessed against the testing and time for API Technology Suppliers and requirements established by ONC. • Electronic health information is API Data Providers. Often, this means health IT is tested by received by and used in the certified Consistent with our proposed an ONC–ATL in a laboratory health IT. compliance timing for the certification environment through methods that We propose to limit the applicability criterion proposed for adoption in include a testing proctor’s visual of this Condition of Certification to § 170.315(b)(10), we propose to add inspection of functions, review of health IT developers with Health IT compliance timeline language to the developer-provided documentation of Modules certified to one or more 2015 2015 Edition Base EHR definition for functions, and testing tools with Edition certification criteria focused on the transition from § 170.315(g)(8) to simulation test data. An ONC–ACB interoperability and data exchange, § 170.315(g)(10) that would reflect a evaluates the results of testing and which are: total of 24 months from the final rule’s makes a determination, based on these • The care coordination criteria in effective date (which practically test results and an assessment of § 170.315(b); speaking would be 25 months because compliance with other Program • The clinical quality measures of the 30-day delayed effective date). We requirements, to issue the health IT a (CQMs) criteria in § 170.315(c)(1) believe this approach is best because it certificate. Over the course of the through (c)(3); identifies a single, specific date for both Program’s existence, ONC has • The ‘‘view, download, and transmit API Technology Suppliers and API Data emphasized the continued conformance to 3rd party’’ criterion in § 170.315(e)(1); Providers by which upgraded API of certified health IT products post- • The public health criteria in technology needs to be deployed in certification in real world and clinical § 170.315(f); production. We also believe that 24 settings. For example, ONC expanded • The application programming months is sufficient for this upgrade the responsibilities of ONC–ACBs in the interface criteria in § 170.315(g)(7) because the scope and nature of our 2015 Edition final rule to require that through (g)(11); and proposals intersect and reflect a large they perform in-the-field surveillance. • The transport methods and other portion of capabilities API Technology We did this to affirm the Program’s protocols criteria in § 170.315(h). Suppliers have already developed and long-standing expectations that certified The 2015 Edition certification criteria deployed to meet § 170.315(g)(8). health IT continue to operate in that are not included in the proposed Moreover, this single date enables API accordance with certification list include many functionality-based Technology Suppliers (based on their requirements when implemented in the criteria, administrative criteria, and, client base and IT architecture) to field (80 FR 62707–62719). These efforts overall, criteria that do not focus on determine the most appropriate timeline are also in line with the Cures Act’s real interoperability and exchange of data. In for development, testing, certification, world testing Condition of Certification particular, we do not propose to include and product release cycles in through their focus on system the 2015 Edition paragraph (a) comparison to having to meet an interoperability and exchange of ‘‘clinical’’ certification criteria in this arbitrary ‘‘must be certified by this date’’ information as deployed and used in list because they do not focus on requirement. care environments—that is to say, in the interoperability and exchange of data. ‘‘real world.’’ However, the data in the paragraph (a) 5. Real World Testing The objective of real world testing is criteria largely will be covered through The Cures Act requires, as a to verify the extent to which certified the USCDI as a minimum data set Condition and Maintenance of expected for exchange; the USCDI is Certification under the Program, that 94 Defined in Section 3022 of the Cures Act. included in such criteria as ‘‘transitions

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00073 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7496 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

of care’’ (§ 170.315(b)(1)), ‘‘view, authorized representative capable of type of organization and setting, the download, and transmit to 3rd party’’ binding the health IT developer for number of patient records and users, (§ 170.315(e)(1)), and the API criteria execution of the plan and include the system components and integrations, (i.e., § 170.315(g)(9) and (10)). representative’s contact information. and the volume and types of data We solicit comment on whether to The plan would need to include all exchange in planning for real world include the ‘‘patient health information health IT certified to the 2015 Edition testing. We would also expect capture’’ certification criteria in through August 31 of the preceding developers to explain how they will § 170.315(e)(3), including the value of year. The plan would also need to incorporate voluntary standards updates real world testing these functionalities address the health IT developer’s real in their real world testing as discussed compared to the benefit for world testing for the upcoming calendar further below. While we are not interoperability and exchange. We also year and include, for each of the proposing a minimum proportion of the solicit comment on whether any other certification criteria in scope: customer base that must be covered in 2015 Edition certification criteria • The testing method(s)/ real world testing, we highly encourage should be included or removed from the methodology(ies) that will be used to developers to find ways to ensure, to the applicability list for this Condition of demonstrate real world interoperability, extent practical, proportionate coverage Certification. including a mandatory focus on of their customer base that balances the To fully implement the real world scenario- and use case-focused testing; goals of real world testing with burden • testing Condition of Certification as The care and practice setting(s) that to providers. Health IT developers described above, we propose will be tested for real world would not be required to test the Maintenance of Certification interoperability, including conformance certified health IT in each and every requirements that would require health to certification criteria requirements, setting in which it is intended for use IT developers to submit publicly and an explanation for the health IT as this would likely not be feasible due available prospective annual real world developer’s choice of care setting(s) to to the associated burden; however, testing plans and retrospective annual test; 95 • developers must address their choice of real world testing results for its certified The timeline and plans for care and/or practice settings to test and health IT that include certification voluntary updates to standards and ONC encourages developers test in as criteria focused on interoperability. As implementation specifications that ONC many settings as feasible. Additionally, we considered the various approaches has approved (further discussed below); • health IT developers would be required to implement this Cures Act A schedule of key real world testing to provide a justification for their requirement on health IT developers, we milestones; chosen approach. Because our approach • A description of the expected determined that health IT developers provides great flexibility for health IT outcomes of real world testing; would be best positioned to construct developers with respect to how their certified health IT could be • At least one measurement/metric demonstrating compliance, we believe it tested in the real world. Moreover, by associated with the real world testing; is imperative that they provide a requiring health IT developers to be and justification to explain their responsible for facilitating their certified • A justification for the health IT methodology. Through the transparent health IT testing in production settings developer’s real world testing approach. reporting of their real world testing and being held accountable to publicly The intended testing methods/ plans, the public will have an publish their results, we would balance methodologies would need to address opportunity to consider a health IT the respective burden of this statutory testing scenarios, use cases, and developer’s chosen approach(es) and requirement with its intended workflows associated with whether it is sufficiently comprehensive assurances for health care providers. interoperability. Testing may occur in Additionally, ONC is not adequately the operational setting using real patient to provide assurance that the certified resourced to centrally administer a real data, in an environment that mirrors the health IT has satisfactorily world testing regime among each health clinical setting using synthetic or real demonstrated its satisfaction of Program IT developer and its customers, nor do patient data, or in the clinical setting requirements including interoperability we have the specific relationships with with synthetic data intermixed. Note in real world settings relevant to their health care providers that health IT that when Health IT developers who are needs. developers do. Lastly, even if ONC were HIPAA business associates are Health IT developers should consider positioned to support and scale a real conducting testing using ePHI, such existing testing tools and approaches world testing regime, we would run the testing must be conducted consistent that may be used to assess real world risk of having one-size-fits-all tools that with their business associate agreements interoperability. For example, we would not necessarily get to the level of and other compliance responsibilities. encourage health IT developers to detail and granularity necessary and The health IT developer may also consider metrics of use and exchange reflective of different health care partner with other health IT developers from existing networks, communities, settings and different scopes of practice to perform real world testing. We would and tools including, but not limited to, that use certified health IT. expect developers to consider such Surescripts, Carequality, CommonWell Given these considerations, we factors as the size of the organization Health Alliance, the C–CDA One-Click propose that a health IT developer must that production systems support, the Scorecard, and DirectTrust. We do not submit an annual real world testing plan believe that testing through the ONC- to its ONC–ACB via a publicly 95 We do not propose to specifically define or approved test procedures is sufficient to accessible hyperlink no later than limit the care settings and leave it to the health IT demonstrate real world use as the test developer to determine. As an example, health IT procedures developed for initial December 15, of each calendar year for developers can consider categories, including but each of its certified 2015 Edition Health not limited to, those used in the EHR Incentive laboratory testing and certification are IT Modules that include certification Programs (https://www.cms.gov/Regulations-and- generally setting agnostic, focused on criteria specified for this Condition of Guidance/Legislation/EHRIncentivePrograms/ standards conformance, and do not _ Downloads/October2017 always test the full scope of the Certification. Prior to submission to the MedicareEHRIncentivePayments.pdf); long-term ONC–ACB, the plan would need to be and post-acute care; pediatrics; behavioral health; certification criteria’s intended approved by a health IT developer and small, rural, and underserved settings. functionality. We also clarify that the

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00074 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7497

ONC-approved test procedures are not real world testing with any challenges Certification Requirements, we believe intended for use in in-the-field encountered, and provide at least one that a health IT developer’s ability to surveillance or for real world testing. measurement or metric associated with conduct ongoing maintenance on its Further, we do not believe connect-a- the real world testing. As noted above, certified Health IT Module(s) to thons are a valid approach to testing real developers are encouraged to use incorporate these new versions is world use of health IT because they do metrics demonstrating real world use essential to support interoperability in not necessarily assess interoperability from existing networks and the real world. Updated versions of and functionality in live settings, but communities. We seek comment on standards reflect insights gained from rather test developer/vendor whether ONC should require developers real-world implementation and use. connectivity in a closed test submit real world testing results for a They also reflect industry stakeholders’ environment. Health IT developers may minimum ‘‘core’’ set of general metrics/ interests to improve the capacity, consider working with an ONC–ACB to measurements and examples of capability, and clarity of such standards have the ONC–ACB oversee the suggested metrics/measurements. We to meet new, innovative business needs, execution of the health IT developer’s also invite comment on the proposed which earlier standards versions cannot real world testing plans, which could annual frequency and timing of required support. Therefore, as part of the real include in-the-field surveillance per real world testing results reporting. world testing Condition of Certification, § 170.556, as an acceptable approach to We acknowledge that a subsequent we propose a Maintenance of meet the requirements of the real world final rule for this proposed rule may not Certification flexibility that we refer to testing Condition of Certification. provide sufficient time for health IT as the Standards Version Advancement We propose that health IT developers developers to develop and submit plans Process. The Standards Version with multiple certified health IT for a full year of real world testing in Advancement Process would permit products that may include the same 2020. If such a situation comes to health IT developers to voluntarily use interoperability-focused certification fruition, we expect to provide an in their certified Health IT Modules criteria intended to be implemented in appropriate period of time for newer versions of adopted standards so the same settings have the discretion to developers to submit their plans and long as certain conditions are met, not design their real world testing plans in potentially treat 2020 as a ‘‘pilot’’ year limited to but notably including a way that efficiently tests a for real world testing. We would expect successful real world testing of the combination of products. Likewise, that such pilot testing conform to our Health IT Module using the new health IT developers may find portions proposed real world testing to the extent version(s). of their real world testing plans are practical and feasible (e.g., same criteria transferrable to their other certified but for a shorter duration and without We propose to establish the Standards products; thus a health IT developer the same consequences for non- Version Advancement Processnot only could choose to submit a real world compliance). We welcome comments on to meet the Cures Act’s goals for testing plan that covers multiple this potential approach. interoperability, but also in response to certified products as appropriate and as We clarify, and propose, that even if the continuous stakeholder feedback long as there is traceability to the a health IT developer does not have that ONC has received through prior specific certified Health IT Modules. To customers or has not deployed their rulemakings and engagements, which be clear, developers of health IT certified Health IT Module at the time requested that ONC establish a products deployed through the cloud the real world testing plan is due, the predictable and timely approach within who offer their products for multiple health IT developer would still need to the Program to keep pace with the types of settings would be required to submit a plan that addresses its industry’s standards development test the same capability for those prospective testing for the coming year efforts. Rulemaking has not kept up different settings. However, we solicit for any health IT certified prior to with the pace of standards development comment on whether we should offer an August 31 of the preceding calendar and deployment in the health care exemption for services that truly year. If a health IT developer does not market. There is no better evidence of support all of a developer’s customers have customers or has not deployed this reality than by example from our through a single interface/engine and their certified Health IT Module when 2015 Edition rulemaking finalized whether this would be sufficient to meet the annual real world testing results are approximately three years ago and the intent of the real world testing due, we propose that the developer before the Cures Act added Conditions Condition of Certification. Additionally, would need to report as such to meet and Maintenance of Certification while the developers’ plans must the proposed Maintenance of provisions to the PHSA. Two version address each of the interoperability- Certification requirement. For further updates of the National Health Care focused certification criteria in their clarity, a developer would not need to Survey standard (versions 1.1 and 1.2) certified health IT, developers can and report on any health IT certified after have been issued since we adopted should design scenario-based test cases August 31, in the preceding year. version 1.0 in the 2015 Edition final rule that incorporate multiple functionalities (October 16, 2015). Health IT developer Standards Version Advancement and health care provider compliance as appropriate for the real world Process workflow and setting. and use of these versions has and will We propose that a health IT developer As new and more advanced be necessary for submission to Centers would submit annual real world testing versions 96 become available for adopted for Disease Control and Prevention results to their ONC–ACBs via a standards and implementation (CDC) even though the certification publicly accessible hyperlink no later specifications applicable to criteria criterion adopted in § 170.315(f)(7) than January 31, of each calendar year subject to the real world testing continues to require conformance to for the preceding calendar year’s real Condition and Maintenance of version 1.0. Similarly, many other world testing. Real world testing results adopted standards have seen multiple for each interoperability-focused 96 We note that standards development newer versions introduced to the market organizations and consensus standards bodies use certification criterion must address the various nomenclature, such as ‘‘versions,’’ to since we issued the 2015 Edition final elements required in the previous year’s identify updates to standards and implementation rule, such as for eCQM reporting or e- testing plan, describe the outcomes of specifications. prescribing. The proposed Standards

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00075 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7498 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

Version Advancement Process element), we would need to initiate Version Advancement Process to flexibility gives health IT developers the notice and comment rulemaking to National-Coordinator-approved newer option to avoid such unnecessary costs incorporate that USCDI version change versions of all standards to which Real and can help reduce market confusion into the Program. Likewise, similar World Testing requirements apply.97 by enabling certified Health IT Modules updates to standards included in our In order to ensure equitable treatment keep pace with standards advancement 2015 Edition final rule are made under the Program and in order for ONC and market needs including but not annually (or more frequently) by SDOs. to maintain the Program’s overall limited to those related to emerging In order to attempt to keep pace with integrity, each developer that chooses to public health concerns. such updates, which are published at leverage the proposed Standards We have also been informed by different times of the year, ONC would Version Advancement Process stakeholders that, in other cases, ONC’s need to continuously engage in Maintenance of Certification Program inability to more nimbly identify and rulemaking cycles, perhaps even more flexibilities would need to satisfy the incorporate newer versions to standards than once per year. We believe that the following. and implementation specifications that proposed Standards Version Health IT Developers Updating Already were already adopted by the Secretary Advancement Process would allow for Certified Health IT into the Program has perversely more advanced versions of standards impacted standards developing and implementation specifications to be In instances where a health IT organization (SDO) processes. Although approved for use under the Program in developer has certified a Health IT SDOs can rapidly iterate version a more timely and flexible manner that Module, including but not limited to updates to standards and helps to ease the concerns stakeholders instances where its customers are implementation specifications to have reported. Stakeholder input already using the certified Health IT address ambiguities and throughout the Program’s existence has Module, if the developer intends to update pursuant to the Standards implementation challenges reported informed ONC that updating large Version Advancement Process election, from the field and to particularly groupings of standards’ versions while the developer would be required to address matters that adversely impact also adopting new standards through provide advance notice to all affected interoperability, the lack of a clear path rulemakings that only occur about once customers and its ONC–ACB: (a) for that work effort to be timely realized every three years can create an artificial Expressing its intent to update the as part of the Program’s certification market impact in a number of ways. software to the more advanced version requirements has had a chilling effect Such ‘‘all-in-one’’ updates affect all of the standard approved by the on the pace of change. It can also affect health IT developers and the vast National Coordinator through the the willingness of volunteers at these majority of health care providers at the Standards Version Advancement SDOs to devote their time to make same time across all sectors rather than Process; (b) the developer’s expectations updates that would be outdated by the enabling a more incremental and for how the update will affect time ONC goes through a rulemaking, market-based upgrade cycle in response interoperability of the affected Health IT which can be years. Stakeholders have to interoperability, business, and Module as it is used in the real world; indicated that certified health IT clinical needs. developers, customers and users of and (c) whether the developer intends to certified health IT, and the SDO The Standards Version Advancement continue to support the certificate for industry have been technologically Process and corresponding proposed the existing Health IT Module version restricted and innovation-stunted as a revisions to §§ 170.550 and 170.555 for some period of time and how long, result of our prior regulatory approach, would introduce two types of or if the existing version of the Health which focused on certification assuring administrative flexibility for health IT IT Module certified to prior version(s) of compliance only to the version of a developers participating in the Program. applicable standards will be deprecated standard adopted in regulation and did First, for those health IT developers (e.g., that the developer will stop not provide an avenue for the Program with an existing certified Health IT supporting the earlier version of the to accommodate iterative updates to Module, the Health IT Modules would module and request to have the standards during the time between be permitted to be upgraded (in the certificate withdrawn). The notice rulemakings. With the passage of the course of ongoing maintenance) to a would be required to be provided ‘‘maintenance of certification’’ provision new version of an adopted standard sufficiently in advance of the developer in § 4002 of the Cures Act, we believe within the scope of the certification establishing its planned timeframe for the approach proposed here is in line (without having to retest or recertify) so implementation of the upgrade to the with our new statutory authority long as such version was approved by more advanced standard(s) version(s) in regarding Conditions of Certification the National Coordinator for use in order to offer customers reasonable and Maintenance of Certification and certification through the Standards opportunity to ask questions and plan would better and more timely support Version Advancement Process. Second, for the update. We request public market demands for widespread for those health IT developers seeking to comment on the minimum time prior to interoperability. have a Health IT Module’s initial an anticipated implementation of an In supporting more rapid certificate issued, the Health IT Module updated standard or implementation advancement of interoperability, we would be permitted to be presented for believe the proposed Standards Version certification to a new version of an 97 For purposes of clarity, we note that the Advancement Process approach will adopted standard so long as such Standards Version Advancement Process would not benefit patient care, improve version was approved by the National affect the established minimum standards code sets flexibility. Consistent with § 170.555, under the competition, and spur additional Coordinator through the Standards Program, health IT could continue to be certified or engagement in standards development. Version Advancement Process. This upgraded to a newer version of identified minimum To this point, currently, if the USCDI v1 policy flexibility is similar to the standards code sets (see 80 FR 62612) than even the were adopted as currently proposed in flexibility we introduced several years most recent one the National Coordinator had approved for use in the Program via the Standards § 170.213 and then needed to be ago for ‘‘minimum standards’’ code sets, Version Advancement Process unless the Secretary updated to add just one data class or but we would require ONC–ACBs to prohibits the use of the newer version for data element (e.g., a new demographic offer certification under the Standards certification.

VerDate Sep<11>2014 20:39 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00076 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7499

specification version update that should for certification for which no prior approved new versions of adopted be considered reasonable for purposes certificate can serve as the basis for standards. We also believe that this of allowing customers, especially health using the Standards Version approach will continue to hold care providers using the Health IT Advancement Process, we propose that developers accountable for, and shift the Module in their health care delivery the health IT developer would be focus of Health IT Module performance operations, to adequately plan for permitted to use and implement any demonstration to, real world testing for potential implications of the update for and all of the newer versions of adopted interoperability for deployed Health IT their operations and their exchange standards the National Coordinator Modules. As described above, we relationships. We would also be approves through the Standards Version understand the limitations of test interested to know if commenters Advancement Process. We have methods used prior to certification and believe that there are specific implemented this proposed policy further emphasize the importance of certification criteria, standards, through necessary adjustments to the continued conformance of Health IT characteristics of the certified Health IT way in which ONC–ACBs process Modules in the field. However, we Module or its implementation (such as certifications in § 170.550. We recognize request comment on specific Program locally hosted by the customer using it that this proposed flexibility reflects impacts we should consider. versus software-as-a-service type of certain programmatic and policy trade- General Requirements Associated With implementation), or specific types or offs. On one hand, a health IT developer Health IT Modules Certified Using the characteristics of customers that could would be permitted to use the most Standards Version Advancement affect the minimum advance notice that recent version of standards approved by Process should be considered reasonable across the National Coordinator instead of variations in these factors. having to build in potentially In all cases, regardless of whether a We anticipate providing ONC–ACBs ‘‘outdated’’ standards just to get health IT developer is updating an (and/or health IT developers) with a certified. On the other hand, the existing certified Health IT Module or means to attribute this updated Program’s testing infrastructure (which presenting a new Health IT Module for information to the listings on the CHPL is now inclusive of government- certification to new versions of adopted for the Health IT Modules the ONC– developed and non-government- standards approved by the National ACB has certified, and propose to developed tools) may experience certain Coordinator through the Standards require in the Principles of Proper lag times in terms of when updated test Version Advancement Process, it would need to adhere to the following once it Conduct for ONC–ACBs that they are tools to support the approved version elects to takes advantage of this ultimately responsible for this advancements would be available to test proposed flexibility: information being made publicly Health IT Modules for certification available on the CHPL. We request • The developer would need to purposes. As a result, we propose to ensure its mandatory disclosures in public comment on any additional provide the ability for ONC–ACBs to information about updated standards § 170.523(k)(1) appropriately reflect its accept a developer self-declaration of use of any National Coordinator- versions that may be beneficial to have conformity as to the use, listed with certified Health IT Modules approved newer versions of standards. implementation, and conformance to a • The developer would need to on the CHPL. newer version of a standard (including We clarify that a health IT developer address and adhere to all Conditions of but not limited to implementation would be able to choose which of the Certification and Maintenance of specifications) as sufficient updated standards versions approved by Certification requirements proposed that demonstration of conformance in the National Coordinator for use in are otherwise be applicable to its circumstances where the National certification through the Standards certified Health IT Modules regardless Version Advancement Process the Coordinator has approved a version of whether those Health IT Modules developer seeks to include in its update of a standard for use in were certified to the exact same versions updated certified Health IT Module and certification through the Standards of adopted standards that are listed in would be able to do so on an itemized Version Advancement Process but an the text of 45 CFR part 170 or National basis. In other words, if the National associated testing tool is not yet updated Coordinator-approved newer version(s) Coordinator were to approve for use to test to the newer version. Again, we of the standard(s). For instance, the through the Standards Version clarify that a health IT developer would developer would need to ensure that its Advancement Process several different be able to choose which National real world testing plan and performance new versions of adopted standards that Coordinator-approved standard included the National Coordinator- affected different certification criteria version(s) it seeks to include in a new approved standards versions to which it within the scope of a certified Health IT or updated certified Health IT Module is claiming conformance. Module, the developer would be able to and would be able to do so on an In terms of compliance with the real just update one certification criterion to itemized basis. world testing Condition and one or more of the applicable new On balance, we believe that this Maintenance of Certification standards and would not have to update programmatic flexibility and the requirements, the attestations Condition its Health IT Module to all of the potential interoperability improvements and Maintenance of Certification National Coordinator-approved new from the use of newer versions of requirements proposed in § 170.406, versions all at once in order to be able standards outweighs the subsequent and for the purposes of ONC–ACB to take advantage of this proposed oversight challenges. Moreover, these surveillance, we note that health IT flexibility. oversight challenges can be mitigated by developers would be accountable for the Standards Version Advancement maintaining all applicable certified Health IT Developers Presenting a New Process itself (i.e., the National Health IT Modules in accordance with Health IT Module for Certification and Coordinator not approving a new approved versions of standards and Leveraging the Standards Version version if the Program or industry is not implementation specifications that they Advancement Process ready) and the corresponding voluntarily elect to use in their certified In instances where a health IT Conditions of Certification that continue health IT. If, at any point after initial developer presents a Health IT Module with the use of National Coordinator- certification or updated certification for

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00077 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7500 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

a Health IT Module using the National Advisory (ISA) web platform to consistent with that standard’s name Coordinator approved advanced facilitate the public transparency and and version track. This method would versions of standards or implementation engagement process. At a particular provide long-term consistency for health specifications, real world testing results time of the year (e.g., early fall), ONC IT developers in terms of the overall do not demonstrate the Health IT would post a list of new versions of technical conformance requirements on Module’s conformance to each adopted standards and implementation which they will be focused. applicable certification criterion had specifications that appear timely and With respect to adopted been achieved and maintained using the appropriate for use within the Program implementation specifications, we National Coordinator approved (for the subsequent calendar year) along believe that more flexibility about the advanced version update of any with accompanying descriptive context precise name and version track applicable standard(s) and (e.g., the types/nature of updates in the identifiers would be warranted given implementation specification(s), then new version of a standard). ONC would that implementation specifications are the developer would not be allowed to then widely communicate to all developed by market-driven industry claim or characterize the Health IT members of the public that the list was consortia (e.g., Argonaut project and Module as conformant to the criterion available and make a general solicitation Direct project stakeholders) as well as using such standard version, and the of comments to any and all interested traditional SDOs. Similarly, authors of standard or implementation parties for a period of 30 to 60 days. We implementation specifications specification version could not be would generally expect to receive sometimes develop supplemental indicated in the health IT Module’s comments on a range of issues related documents to the ‘‘parent’’ CHPL record as supported by any to the version of the standard under implementation specification or split version release of the Health IT Module, consideration, including its availability, the implementation specification to until such time as they could testing tools, maturity, implementation form newly titled materials. In any of demonstrate through ONC–ATL or burden, and overall impact on these cases, the resulting results of real world testing that they interoperability. Health IT developers, implementation specification may—on had successfully upgraded the Health IT health information networks (HINs), and its face—initially appear to bear no Module to fully conform to applicable the health care organizations that relation to a previously adopted certification criteria while incorporating purchase and use health IT are already implementation specification because of the more advanced version of the familiar with the process of commenting changes to its title, version naming, or standard. Non-conformities associated through our existing ISA resource and numbering presentation. In reality, in with the use of new versions of National we believe this process is well suited to many of these cases, the implementation Coordinator-approved standards would support widespread engagement by all specification retains substantially the be found and enforced through the same stakeholders. Similar to the ISA, we same purpose(s) and thus represents a Program rules just like they would be would expect to be open to receiving versioning update rather than for non-conformities with the versions comments on newer versions of adopted amounting to a novel specification. of adopted standards that are codified in standards throughout the year leading Accordingly, regardless of its title and regulation text. Further, we remind up to the formal comment period. author, the National Coordinator would health IT developers that they would be Once the formal comment period take into account whether any ‘‘new’’ required to make an attestation to their closes, ONC would review the implementation specification under real world testing results, including comments and consider the potential consideration is more accurately (though not limited to) those that would impacts of a new version an adopted characterized as novel to the Program or be used to support use of new versions standard or implementation instead is a derivative work that is of National Coordinator-approved specification. We anticipate approving substantially a more advanced version standards. newer versions of adopted standards of a previously adopted implementation and implementation specifications specification(s). Stakeholders would Advanced Version Approval Approach based on several interdependent also be able to comment on the same Once a standard has been adopted for Program and market factors, such as its during the advanced version approval use in the Program through notice and ability to enhance interoperability and process described here. comment rulemaking, ONC would overall compatibility with other adopted The public listing of these National undertake an annual, open and versions, how burdensome it would be Coordinator determinations to approve transparent process, including to update to the newer version and the version updates to already adopted opportunity for public comment, to scope and scale of the changes, whether standards and implementation timely ascertain whether a more recent the new version would be required for specifications would serve as the single, version of that standard or reporting by a corresponding program comprehensive, and authoritative index implementation specification should be (e.g., CMS or CDC), the availability of of the versions of adopted standards and approved for developers’ voluntary use. test tools for the new version, and the implementation specifications available ONC would identify updated versions of new version’s relationship to other for use under the Program. We note, previously adopted standards and adopted standards and any however, that certain Program implementation specifications based on dependencies. Upon concluding our administration steps would need to our own monitoring of market trends review and analysis, ONC would occur (such as ONC–ACBs expanding and interoperability needs, as well as publish in this new ISA section a final the scope of their accreditations) after input received from external list of National Coordinator-approved the National Coordinator has approved stakeholders. Such external input may advanced versions that health IT newer versions of adopted standards. As include, but would not be limited to, developers could electively use a result, there would likely be a recommendations made by the Health consistent with the Standards Version temporary delay between the National Information Technology Advisory Advancement Process. Coordinator’s approval decision and Committee as well as input received Within this proposed approach, we when certification to new standards from SDOs. expect that when it comes to a standard, versions under the Program would start. ONC expects to use an expanded the National Coordinator would identify We welcome comments on any and section of the Interoperability Standards version updates to an adopted standard all aspects of our proposed standards

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00078 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7501

version approval process as an option Because we are proposing to allow CHPL attributed to the certified Health available to developers through health IT developers to implement IT Modules to which it applies. maintenance requirements as part of the National Coordinator-approved We seek comment on the proposed real world testing Condition and advanced versions of standards and additions to the Principles of Proper Maintenance of Certification. This implementation specifications in Conduct for ONC–ACBs. More includes all aspects of our described certified Health IT Modules through a specifically, we seek comment on approach to standards and developer self-declaration of conformity whether ONC–ACBs should be required implementation specification advanced presented for certification if an to perform an evaluation beyond a version approval processes. We also associated testing tool is not yet updated completeness check for the real world invite comments on our proposal to to test to the newer version for the testing plans and results and the value allow in conjunction with this standards and implementation versus the burden of such an endeavor. maintenance flexibility the opportunity specification version updates they have 6. Attestations for developers to elect to present health chosen to use in the Program, we IT for initial testing and certification The Cures Act requires that a health propose two requirements to ensure the IT developer, as a Condition and either to more advanced versions or the public and ONC–ACBs have knowledge prior versions included in regulatory Maintenance of Certification under the of the version of a standard that certified Program, provide to the Secretary an text as of the date the technology is health IT meets. First, we propose to presented. attestation to all the Conditions of revise the Principle of Proper Conduct Certification specified in the Cures Act, Principle of Proper Conduct for ONC– in § 170.523(m) to require ONC–ACBs to except for the ‘‘EHR reporting criteria ACB for All Real World Testing collect, no less than quarterly, all submission’’ Condition of Certification. Proposals version updates made to standards We propose to implement the Cures Act successfully included in certified health ‘‘attestations’’ requirements Condition We propose to include a new IT per the requirements within the real of Certification in § 170.406. We also Principle of Proper Conduct for ONC– world testing Condition of Certification propose that, as part of the ACBs in § 170.523(p) that would require Standards Version Advancement implementation of this statutory ONC–ACBs to review and confirm that Process. This would ensure that ONC– provision, health IT developers would applicable health IT developers submit ACBs are aware of the version of a attest, as applicable, to compliance with real world testing plans and results in standard that certified health IT meets the Conditions and Maintenance of accordance with our proposals. We for the purposes of surveillance and Certification requirements described in expect that ONC–ACBs would review Program administration. Second, we this section of the preamble and the plans for completeness. Once propose (as discussed above), that a proposed in §§ 170.401 through completeness is confirmed, ONC–ACBs developer that chooses to avail itself of 170.405. would provide the plans to ONC by the Standards Version Advancement We propose that, as a Maintenance of December 15 and results to ONC by Process flexibility must address in its Certification requirement for the April 1. The December 15 date is the real world testing plans and results ‘‘attestations’’ Condition of Certification, same date as the health IT developer submissions the timeline and rollout of health IT developers must submit their requirement for submission of the real applicable version updates for standards attestations every 6 months (i.e., world testing plan. For purposes of the and implementation specifications. This semiannually). We believe this would Program, this treats both regulated addition to § 170.523(m) along with provide an appropriate ‘‘attestation entities equally and permits them to period’’ to base any enforcement work out a process that ensures all real existing requirements for weekly ONC– ACB CHPL reporting to versions of actions, such as by ONC under the world testing plans are submitted to the Program or by the Office of the Inspector CHPL by December 15. For example, a standards per § 170.523(f)(1)(xvii) would allow for timely updates to General under its Cures Act authority. health IT developer that is confident in We also believe this 6-month attestation its plan and does not anticipate any Health IT Module certificate information in the CHPL. Together with period properly balances the need to further certification, may submit its plan support appropriate enforcement in July of the preceding year. the requirements (discussed above) for developers’ communication with their actions with the attestation burden The submission of results, however, current and potential customers, we placed on developers. We will does not present the same dynamic of intend to ensure that the public and determine when the first attestation will the potential need to work together to end-users have transparency into be due depending on when the final ensure the plan is complete. As such, rule is published. We require planned and actual standards and we have proposed different dates. We attestations to be due twice a year, likely implementation specifications updates would expect the developers to submit in the middle and end of the calendar for their certified health IT. their results by January 31. We believe year. this would provide sufficient time for In complement to the above The process we plan to implement for ONC–ACBs to review all plans and post requirements to ensure transparency for providing attestations should minimize them to the CHPL by April 1, including the public and end users, we propose in burden on health IT developers. First, notifying ONC when the results were § 170.523(t) a new Principle of Proper we propose to provide a 14-day not in compliance with requirements. Conduct for ONC–ACBs requiring them attestation period twice a year. For ONC would make both the plans and to ensure that developers seeking to take health IT developers presenting health results publicly available via the CHPL. advantage of the Standards Version IT for certification for the first time We note that ONC–ACBs will continue Advancement Process flexibility in under the Program, we propose that to be required to perform in-the-field § 170.405(b)(5) comply with the they would be required to submit an surveillance of certified Health IT applicable requirements, and that the attestation at the time of certification Modules and results of real world ONC–ACB both retain records of the and then also comply with the testing could be considered information timing and content of developers’ semiannual attestation periods. Second, to inform ONC–ACB surveillance § 170.405(b)(5) notices and timely post we would publicize and prompt activities. each notice’s content publicly on the developers to complete their attestation

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00079 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7502 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

during the required attestation periods. also welcome comments on the IT’s capabilities for the access, use, and Third, we propose to provide a method proposed responsibilities for ONC– exchange of electronic health for health IT developers to indicate their ACBs related to the attestations of information. The Cures Act provides compliance, non-compliance with, or Condition and Maintenance of this affirmation through expanded the inapplicability of each Condition Certification requirements. certification authority for ONC to and Maintenance of Certification 7. EHR Reporting Criteria Submission establish Conditions and Maintenance requirement as it applies to all of their of Certification requirements for health health IT certified under the Program for The Cures Act specifies that health IT IT developers that go beyond the each attestation period. Last, we developers be required, as a Condition certified health IT itself. The new propose to provide health IT developers and Maintenance of Certification under Conditions and Maintenance of the flexibility to specify non-compliance the Program, to submit reporting criteria Certification provisions in section 4002 per certified Health IT Module, if on certified health IT in accordance of the Cures Act focus on the actions with the EHR reporting program necessary. We note, however, that any and business practices of health IT established under section 3009A of the non-compliance with the proposed developers (e.g., information blocking PHSA, as added by the Cures Act. We Conditions and Maintenance of and appropriate access, use, and have not yet established an EHR Certification requirements, including exchange of electronic health the ‘‘attestations’’ Conditions and reporting program. Once ONC establishes such program, we will information) as well as technical Maintenance of Certification interoperability of health IT (e.g., APIs requirements, would be subject to ONC undertake future rulemaking to propose and implement the associated Condition and real world testing). Furthermore direct review, corrective action, and and equally important, section 4002 of enforcement procedures under the and Maintenance of Certification requirement(s) for health IT developers. the Cures Act provides that the Program. We refer readers to section Secretary of HHS may encourage VII.D of this preamble for discussion of C. Compliance compliance with the Conditions and proposed ONC direct review, corrective The proposed Maintenance of Maintenance of Certification action, and enforcement procedures for Certification requirements discussed requirements and take action to the Conditions and Maintenance of above do not necessarily define all the discourage noncompliance. As Certification requirements under the outcomes necessary to meet the discussed in the 2015 Edition final rule, Program. Conditions of Certification. Rather, they ONC is not limited to enforcing Program We propose that attestations would be provide preliminary or baseline compliance solely through those submitted to ONC–ACBs on behalf of evidence toward measuring whether a requirements expressed in certification ONC and the Secretary. We propose that Condition is being met. Thus, ONC criteria adopted under the Program (80 ONC–ACBs would have two could determine that a Condition of FR 62710; see also 81 FR 72412). responsibilities related to attestations. Certification is not being met through Certification under the Program also One responsibility we propose in reasons other than the Maintenance of relies on a health IT developer’s § 170.523(q) is that an ONC–ACB must Certification requirements. For example, compliance with Program requirements review and submit the health IT meeting the proposed Maintenance of that ensure the basic integrity and developers’ attestations to ONC. ONC Certification requirement that requires a effectiveness of the Program, which is would then make the attestations health IT developer to not establish or further stressed through the addition of publicly available through the CHPL. enforce any contract or agreement that the Conditions and Maintenance of The other responsibility we propose in contravenes the Communications Certification requirements in the Cures § 170.550(l) is that before issuing a Condition of Certification does not Act (referred to jointly as the certification, an ONC–ACB would need excuse a health IT developer from ‘‘Conditions and Maintenance of to ensure that the health IT developer of meeting all the requirements specified Certification’’ in this section of the the Health IT Module has met its in the proposed Communications preamble). responsibilities related to the Condition of Certification. This is Conditions and Maintenance of analogous to clarifications ONC has Given these considerations, we Certification requirements as solely previously provided about certification propose a general enforcement approach evidenced by its attestation. For criteria requirements whereby testing outlining a corrective action process for example, if a health IT developer with prior to certification sometimes only ONC to review potential or known an active certification under the tests a subset of the full criterion’s instances where a Condition or Program indicated non-compliant intended functions and scope. However, Maintenance of Certification designations in their attestation but is for compliance and surveillance requirement has not been or is not being already participating in a corrective purposes, we have stated that ONC and met by a health IT developer under the action plan under ONC direct review to its ONC–ACBs will examine whether Program, including the requirement for resolve the non-compliance, the certified health IT meets the full a health IT developer to attest to certification would be able to proceed scope of the certification criterion rather meeting the Conditions and while the issue is being resolved. than the subset of functions it was Maintenance of Certification. Table 2 We welcome comments on the tested against (80 FR 62709–10). below provides an overview of the proposed attestations Condition and proposed approach to ONC enforcement Maintenance of Certification D. Enforcement of the Conditions and Maintenance of requirements, including the appropriate The Cures Act affirms ONC’s role in Certification. We provide more specific frequency and timing of attestations. We using certification to improve health proposals following Table 2.

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00080 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7503

TABLE 2—PROPOSED APPROACH FOR ENFORCEMENT OF THE CONDITIONS AND MAINTENANCE OF CERTIFICATION

Opportunity for developer to Proposed Opportunity for Consequences of not taking appropriate corrective appeal ONC regulatory Condition of certification developer to take action determination to text corrective action terminate or ban

§ 170.401 ...... Information Blocking ...... Yes ...... Certification ban of all of a developer’s certified Yes. § 170.402 ...... Assurances. Health IT Modules. § 170.403 ...... Communications...... ONC may also consider termination of Health IT § 170.404 ...... APIs. Module certificates if there is a nexus between the § 170.405 ...... Real World Testing. developer’s practices and a certified Health IT § 170.406 ...... Attestations. Module.

1. ONC Direct Review of the Conditions with the behavioral requirements based ONC may issue the health IT developer and Maintenance of Certification on its expertise and experience. a notice of potential non-conformity or Requirements Conversely, ONC–ACBs are generally notice of non-conformity and provide We propose to utilize the processes more suited, based on their the health IT developer an opportunity previously established for ONC direct accreditation and current to respond with an explanation and review of certified health IT in the EOA responsibilities, to address non- written documentation, including any final rule (81 FR 72404) and codified in conformities with technical and other information ONC requests. These §§ 170.580 and 170.581 for the Program requirements. ONC also has the processes, including relevant enforcement of the Conditions and necessary resources and the ability to timeframes, are specified in Maintenance of Certification. We coordinate with other agencies to § 170.580(b). enforce the Conditions and Maintenance propose this approach for multiple i. Complaint Resolution reasons. First, these processes were of Certification, such as with the established to address non-conformities ‘‘information blocking’’ Condition of We note and recommend that with Program requirements. Conditions Certification (proposed § 170.401). customers and end-users first work with and Maintenance of Certification are Further, ONC enforcement would their health IT developers to resolve any proposed to be adopted as Program provide more predictability and issues of potential non-compliance with requirements and, as such, any consistency, which would likely benefit the Conditions and Maintenance of noncompliance with the Conditions and stakeholders in matters related to API Certification as prior Program Maintenance of Certification would fees and information blocking. We do, experience has shown that many issues constitute a Program non-conformity. however, discuss below the scope of can be resolved at this step. If the issue Second, health IT developers are ONC–ACB surveillance as it relates to cannot be resolved, we then recommend familiar with the ONC direct review ONC’s proposed enforcement of the the end-user contact the ONC–ACB. provisions as they were established in Conditions and Maintenance of However, as discussed above and in October 2016. Third, §§ 170.580 and Certification. section VII.D.5 below, the ONC–ACB purview for certified health IT generally 170.581 provide thorough and 3. Review Processes transparent processes for working with applies to certified capabilities and health IT developers through notice and We propose to substantially adopt the limited requirements of developer corrective action to remedy Program processes as they are currently codified business practices. If neither of these non-conformities. Last, the direct review in §§ 170.580 and 170.581 for ONC’s pathways resolves the issue, end-users framework provides equitable review and enforcement of the may provide feedback to ONC via the opportunities for health IT developers to Conditions and Maintenance of Health IT Feedback Form.98 Certification, but propose certain respond to ONC actions and appeal ii. Method of Correspondence With certain ONC determinations. revisions and additions to the processes to properly incorporate the proposed Health IT Developers 2. Review and Enforcement Only by Conditions and Maintenance of Section 170.505 states that ONC Certification and effectuate correspondence and communication We propose to retain use of the term Congressional intent. These revisions with ONC or the National Coordinator ‘‘direct review’’ as previously adopted and additions include renaming and shall be conducted by email, unless in the EOA final rule to continue to restructuring headings for clarity, which otherwise necessary or specified. In the distinguish actions ONC takes to we do not discuss below. EOA final rule, we signaled our intent directly review certified health IT or to send notices of potential non- a. Initiating Review and Health IT health IT developers’ actions in conformity, non-conformity, Developer Notice comparison to an ONC–ACB’s review of suspension, proposed termination, and certified health IT under surveillance. We propose to fully incorporate the termination via certified mail (81 FR We propose, however, that ONC would review of the Conditions and 72429). However, in accordance with be the sole party responsible for Maintenance of Certification into the § 170.505, we propose that email should enforcing compliance with the provisions of § 170.580(a) and (b). We be the default mode of correspondence Conditions and Maintenance of propose in § 170.580(a)(iii) that if ONC for direct review of non-compliance Certification. The Conditions and has a reasonable belief that a health IT with the Conditions and Maintenance of Maintenance of Certification focus on developer has not complied with a Certification. health IT developer behavior and Condition of Certification, then it may actions in addition to the certified initiate direct review. Similarly, we 98 https://www.healthit.gov/form/healthit- Health IT Module. ONC is more familiar propose in § 170.580(b)(1) and (2) that feedback-form.

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00081 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7504 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

Under the EOA final rule, ONC can ONC–ACB. As finalized in the EOA secret, competitively sensitive, or other initiate direct review of certified health final rule and per § 170.580(a)(3)(v), we confidential information. As we stated IT in limited circumstances, namely remind readers that ONC may refer the in the EOA final rule (81 FR 72429), when there is a reasonable belief that applicable part of its review of certified ONC would implement appropriate the certified health IT may be causing or health IT to the relevant ONC–ACB(s) if safeguards to ensure, to the extent contributing to serious risks to public ONC determines this would serve the permissible with federal law, that any health or safety or suspected non- effective administration or oversight of proprietary business information or conformities present practical the Program (81 FR 72427–72428). trade secrets ONC may encounter by challenges that may prevent an ONC– accessing the health IT developer’s c. Records Access ACB from effectively investigating or records, other information, or responding to the suspected non- We propose to revise § 170.580(b)(3) technology, would be kept confidential conformity. In contrast, we propose in to ensure that ONC, or third parties by ONC or any third parties working on this proposed rule to enable ONC to acting on its behalf, has access to the behalf of ONC. However, a health IT initiate direct review to address a health information necessary to enforce the developer would not be able to avoid IT developer’s conduct under the Conditions and Maintenance of providing ONC access to relevant Conditions and Maintenance of Certification. As specified in records by asserting that such access Certification requirements in addition to § 170.580(b)(1)(ii)(A)(2), (b)(2)(ii)(A)(2) would require it to disclose trade secrets non-conformities in certified health IT. and (b)(3), in response to a notice of or other proprietary or confidential This proposal would create an potential non-conformity or notice of information. Therefore, health IT expanded set of circumstances for ONC non-conformity, ONC must be granted developers must clearly mark, as to conduct direct review. Accordingly, access to, and have the ability to share described in HHS Freedom of the type and extent of review by ONC within HHS, with other federal Information Act regulations at 45 CFR could vary significantly based on the agencies, and with appropriate entities, 5.65(c), any information they regard as complexity and severity of each fact all of a health IT developers’ records trade secret or confidential commercial pattern. For instance, ONC may be able and technology related to the or financial information which they to address certain non-conformities development, testing, certification, seek to keep confidential prior to under the Conditions and Maintenance implementation, maintenance, and use disclosing the information to ONC or of Certification quickly and with of a health IT developers’ certified any third party working on behalf of minimal effort (e.g., failure to make health IT; and any complaint records ONC. public a documentation hyperlink), related to the certified health IT. d. Corrective Action while others may be more complex and ‘‘Complaint records’’ include, but are require additional time and effort (e.g., not limited to issue logs and help desk We propose that if ONC determines violation of API fee prohibitions). tickets (81 FR 72431). We propose to that a health IT developer is Considering this wide range of potential supplement these requirements with a noncompliant with a Condition of non-conformities under the Conditions requirement that a health IT developer Certification (i.e., a non-conformity), and Maintenance of Certification, we make available to ONC, and third ONC would work with the health IT believe it is appropriate for ONC to parties acting on its behalf, records developer to establish a corrective retain discretion to decide, on a case-by- related to marketing and distribution, action plan (CAP) to remedy the issue case basis, when to go beyond the communications, contracts, and any through the processes specified in provisions of § 170.505 in providing other information relevant to § 170.580(b)(2)(ii)(A)(4) and (c). We note notices and correspondence for non- compliance with any of the Conditions that a health IT developer may be in compliance with the Conditions and and Maintenance of Certification or noncompliance with more than one Maintenance of Certification. other Program requirements. This Condition of Certification. In such cases, We solicit comment on the nature and information would assist in reviewing ONC will follow the proposed types of non-conformities with the allegations that a health IT developer compliance enforcement process for Conditions and Maintenance of violated, for example, the ‘‘prohibit and each Condition of Certification Certification requirements that ONC restrict communications’’ Condition of accordingly, but may also require the should consider in determining the Certification. Further, it is possible that health IT developer to address all method of correspondence. We also multiple Conditions and Maintenance of violations in one CAP for efficiency of solicit comment on whether the type of Certification may be implicated under a process. We also propose, as we notice should affect the method of review, and thus ONC believes it is currently do with CAPs for certified correspondence and whether certain appropriate to require a developer make health IT, to list health IT developers types of notices under direct review available to ONC all records and other under a CAP on ONC’s website. should be considered more critical than relevant information concerning all the e. Certification Ban and Termination others, thus requiring a specific method Conditions and Maintenance of of correspondence. Certification and Program requirements We propose in § 170.581 that if a to which it and its Health IT Modules health IT developer under ONC direct b. Relationship With ONC–ACBs and are subject. review for non-compliance with a ONC–ATLs If ONC determined that a health IT Condition of Certification failed to work Section 170.580(a)(3) outlines ONC developer was not cooperative with the with ONC or was otherwise direct review in relation to the roles of fact-finding process, we propose ONC noncompliant with the requirements of ONC–ACBs and ONC–ATLs, which we would have the ability to issue a the CAP and/or CAP process, ONC propose to revise to incorporate certification ban and/or terminate a could issue a certification ban for the Conditions and Maintenance of certificate (see proposed § 170.581 health IT developer (and its subsidiaries Certification. We note that we provide discussed below and and successors). A certification ban, as situational examples below in section § 170.580(f)(1)(iii)(A)(1)). it currently does for other matters under VII.D.5 ‘‘Effect on Existing Program We understand that health IT § 170.581, would prohibit prospective Requirements and Processes’’ regarding developers may have concerns regarding certification activity by the health IT ONC direct review and the role of an the disclosure of proprietary, trade developer.

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00082 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7505

ONC would also consider of a Condition of Certification may Certification, which would also include termination 99 of the certificate(s) of the relate solely to health IT developer instructions for requesting affected Health IT Module(s) should the business practices or actions that do not reinstatement. In this regard, we health IT developer fail to work with affect the Health IT Module’s propose to apply the current ONC or is otherwise noncompliant with conformance to the requirements of the reinstatement procedures under the requirements of the CAP and/or CAP certification criteria. In this case, § 170.581 to Conditions and process (see proposed termination of the certification could Maintenance of Certification bans, but § 170.580(f)(1)(iii)). ONC may consider unfairly and negatively affect a with an additional requirement that the termination if there is a nexus between provider’s ability to use the Health IT health IT developer has resolved the the developer’s actions or business Module for participation in CMS non-compliance with the Condition of practices and certified Health IT programs that require certification Certification. In sum, a health IT Module(s) (see proposed because the Health IT Module itself is developer could seek ONC’s approval to § 170.580(f)(1)(iii)). For example, ONC functioning in accordance with the re-enter the Program and have the may determine that a health IT technical requirements of its certification ban lifted if it demonstrates developer is violating a Condition of certificate.100 As such, ONC would it has resolved the noncompliance with Certification due to a clause in its carefully consider on a case-by-case the Condition of Certification and ONC contracts that prevents its users from basis the appropriateness of termination is satisfied that all affected customers sharing or discussing technological of a Health IT Module’s certification(s) have been provided appropriate impediments to information exchange. based on the specific circumstances of remediation. In this example, the health IT the noncompliance with the Condition For clarity, a health IT developer developer’s conduct would violate the of Certification. The proposed would have an opportunity to appeal an ‘‘prohibiting or restricting enforcement approach balances the ONC determination to issue a communication’’ Condition of above stated goals and provides an certification ban and/or termination IT Certification proposed in § 170.403. If outlined process that can be resulting from a non-conformity with a the same conduct were also found to consistently followed. Condition of Certification as discussed impair the functionality of the certified In considering whether termination of below and/or seek reinstatement in the Health IT Module (such as by a Health IT Module’s certificate(s) and/ Program and have the certification ban preventing the proper use of certified or a certification ban is appropriate, lifted. To note, we propose to make capabilities for the exchange of EHI), ONC will consider factors including, but terminations effective consistent with ONC may determine that a nexus exists not limited to: Whether the health IT current § 170.580(f)(2)(iii) and similarly between the developer’s business developer has previously been found in for certification bans (see proposed practices and the functionality of the noncompliance with the Conditions and § 170.581(c)). We seek comment on certified Health IT Module, and may Maintenance of Certification or other whether ONC should: • consider termination of the certificates Program requirements; the severity and Impose a minimum certification of that particular Health IT Module pervasiveness of the noncompliance, ban length before a health IT developer under the proposed approach. including the effect of the can request ONC remove the ban for We propose this approach, which noncompliance on widespread health IT developers who are allows ONC to initiate a certification interoperability and health information noncompliant with a Condition of ban and/or certificate termination under exchange; the extent to which the health Certification more than once (e.g., a certain circumstances, to ensure that IT developer cooperates with ONC to minimum six months for two instances, health IT developers are acting in review the noncompliance; the extent of a minimum of one year for three accordance with the Conditions and potential negative impact on providers instances). • Maintenance of Certification. However, who may seek to use the certified health Consider additional factors for a we stress that our first and foremost IT to participate in CMS programs; and certification ban and/or the termination priority is to work with health IT whether termination and/or a of a health IT developer’s certified developers to remedy any certification ban is necessary to ensure health IT resulting from a non- noncompliance with Conditions and the integrity of the certification process. conformity with a Condition of As under § 170.580(f)(2), ONC would Maintenance of Certification through a Certification. provide notice of the termination to the corrective action process before taking health IT developer, including f. Appeal further action. This emphasizes ONC’s providing reasons for, and information We propose to provide a health IT desire to promote and support health IT supporting, the termination and developer an opportunity to appeal an developer compliance with the instructions for appealing the ONC determination to issue a Conditions and Maintenance of termination. We propose to add similar certification ban and/or termination Certification and ensure that certified notice provisions to § 170.581 for resulting from a non-conformity with a health IT is compliant with Program certification bans issued under ONC Condition of Certification and would requirements in order to foster an direct review for non-compliance with follow the processes specified in environment where EHI is exchanged in the Conditions and Maintenance of § 170.580(g). As such, we propose to an interoperable way. revise § 170.580(g) to include ONC ONC does not believe that 100 Note that, in this example, an ONC–ACB may direct review of the Conditions and noncompliance with a Condition of investigate the technical functionalities of the Maintenance of Certification. Certification should always result in the Health IT Module against its certificate and perform termination of the certificate of one or surveillance under § 170.556 separate from ONC’s g. Suspension more of a developer’s Health IT process to enforce compliance with the Conditions of Certification. If under ONC–ACB surveillance, a Section 170.580 includes a process for Modules for a few reasons. A violation health IT developer does not adequately or timely suspending the certification of a Health fulfill a corrective action plan, the ONC–ACB may IT Module at any time if ONC has a 99 As noted in the EOA final rule, ‘‘termination’’ suspend and withdraw the Health IT Module’s means an ONC action to ‘‘terminate’’ or ‘‘revoke’’ certificate. The expectations of ONC–ACB duties as reasonable belief that the certified the certification status of a Complete EHR or Health relates to ONC’s enforcement of the conditions of health IT may present a serious risk to IT Module. (81 FR 72443). certification are described further in the preamble. public health and safety. While this will

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00083 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7506 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

remain the case for certified health IT subject to a certification ban and/or impediments to ONC–ACB oversight, under ONC direct review (i.e., have been terminated, respectively, for ONC may directly review certified suspension of certification is always noncompliance with a Condition of health IT to determine whether it available under ONC direct review Certification or for reasons already conforms to the requirements of the when the certified health IT presents a specified in § 170.581. We currently Program (see § 170.580 and the EOA serious risk to public health and safety), take this same approach for health IT final rule at 81 FR 72404). These we do not believe such circumstances with terminated certifications (see 81 FR avenues for investigating non- would apply to noncompliance with the 72438). Public listing serves to conformities with certified Health IT Conditions of Certification. Further, we discourage noncompliance with Modules will continue to exist under believe the more streamlined processes Conditions and Maintenance of the Program and generally focus on proposed for addressing noncompliance Certification, other Program functionality and performance of with Conditions and Maintenance of requirements, remediation of non- certified health IT or more limited Certification alleviates the need to conformities, and cooperation with ONC requirements of business practices of proceed through a suspension process. and the ONC–ACBs. It also serves to health IT developers found in subparts Therefore, we do not propose to apply provide notice to all ONC–ATLs, ONC– A, B, C and E of Part 170, respectively. the suspension processes under ACBs, public and private programs Thus, there may be instances where one § 170.580 to our review of the requiring the use of certified health IT, or more Conditions and Maintenance of Conditions of Certification. We welcome and consumers of certified health IT of Certification are not being or have not comments on this proposal, including the status of certified health IT and been met that also relate to certified reasons for why we should apply health IT developers operating under Health IT Modules non-conformities suspension processes to the Conditions the Program. under subparts A, B, C and E. Under of Certification as part of a subsequent We seek comment on this proposal, these situations, ONC could in parallel final rule. including input on the appropriate implement both sets of processes— period of time to list health IT h. Proposed Termination existing processes to investigate Health developers and affected certified Health IT Module non-conformities and the Section 170.580 includes an IT Modules on healthit.gov. For proposed process to enforce compliance intermediate step between a developer example, if a developer sought and with the Conditions and Maintenance of failing to take appropriate and timely received reinstatement under the Certification. corrective action and termination of a Program (and lifting of the certification certified Health IT Module’s certificate, ban), should the health IT developer no We again note that under the called ‘‘proposed termination’’ (see longer be listed on the ONC website? proposed enforcement approach, only § 170.580(e) and 81 FR 72437)). We Alternatively, should we list health IT ONC would have the ability to propose to not include this step when developers who have been subject to the determine whether a Condition or a health IT developer fails to take certification ban under § 170.581 for a Maintenance of Certification appropriate and timely corrective action certain period of time beyond the active requirement per subpart D has been or for noncompliance with a Condition of ban, including indefinitely (e.g., with is being met. We propose to delineate Certification. Rather, as discussed the timeframe when the ban was the scope of an ONC–ACB’s above, ONC may proceed directly to active)? requirements to perform surveillance on issuing a certification ban or notice of certified Health IT Modules as related termination if it determines a 5. Effect on Existing Program only to the requirements of subparts A, certification ban and/or termination are Requirements and Processes B, C and E of Part 170. Table 3 below appropriate per the considerations The Cures Act introduces new further illustrates the proposed discussed above. The Conditions and Conditions and Maintenance of difference in scope of review activities Maintenance of Certification include Certification that encompass technical between ONC–ACBs and ONC. Given requirements of developer business and functional requirements of health IT our proposed approach that would practices and actions for which, as and new actions and business practice authorize solely ONC to determine previously discussed, noncompliance requirements for health IT developers, whether a Condition or Maintenance of with the Conditions and Maintenance of which ONC proposes to adopt in Certification requirement per subpart D Certification in these arenas are likely to subpart D of Part 170. The pre-Cures Act has been or is being met, we propose to undermine the integrity of the Program structure and requirements of the add a new Principle of Proper Conduct and impede widespread interoperability Program provide processes to enforce for ONC–ACBs in § 170.523(s) that and information exchange. As such, compliance with technical and would require ONC–ACBs to report to ONC believes it is appropriate and functional requirements of certified ONC, no later than a week after consistent with the Cures Act to proceed health IT, and to a more limited extent, becoming aware, any information that immediately to a certification ban and/ requirements for the business practices could inform whether ONC should or termination of the affected certified of health IT developers (see, e.g., 45 CFR exercise direct review for Health IT Modules’ certificates if a 170.523(k)(1)) under subparts C noncompliance with a Condition of developer does not take appropriate and (Certification Criteria for Health Certification or any matter within the timely corrective action. A certification Information Technology) and E (ONC scope of ONC direct review. We believe ban and/or termination are appropriate Health IT Certification Program) of Part this is appropriate because ONC–ACBs disincentives for noncompliance with 170. ONC–ACBs are required to perform receive complaints and other the Conditions and Maintenance of surveillance on certified Health IT information about certified Health IT Certification. Modules and may investigate reported Modules through their own channels; as alleged non-conformities with Program this information may relate to potential 4. Public Listing of Certification Ban requirements under subparts A, B, C, noncompliance with the Conditions and and Terminations and E with the ultimate goal to work Maintenance of Certification or other We propose to publicly list health IT with the health IT developer to correct matters within the scope of ONC direct developers and certified Health IT the non-conformity. Under certain review, ONC should be made aware of Modules on ONC’s website that are situations, such as unsafe conditions or this information.

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00084 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7507

TABLE 3—SCOPE OF ONC–ACB SURVEILLANCE AND ONC DIRECT REVIEW FOR PROPOSED ENFORCEMENT APPROACH FOR CONDITIONS AND MAINTENANCE OF CERTIFICATION

ONC purview for enforcement Condition of certification ONC–ACB purview for surveillance per 170.556 per 170.580 and 170.581

170.401: Information Blocking ...... Only as it relates to Subparts A, B, C and E of Part 170 ...... All of 170.401. 170.402: Assurances ...... Only as it relates to Subparts A, B, C and E of Part 170, including the certification cri- All of 170.402. terion in § 170.315(b)(10) ‘‘EHI export’’. 170.403: Communications ...... Only as it relates to Subparts A, B, C and E of Part 170 ...... All of 170.403. 170.404: APIs ...... Only as it relates to Subparts A, B, C and E of Part 170, including the certification cri- All of 170.404. terion in § 170.315(g)(10). 170.405: Real World Testing ...... Only as it relates to Subparts A, B, C and E of Part 170 ...... All of 170.405. 170.406: Attestations ...... Only as it relates to Subparts A, B, C and E of Part 170 ...... All of 170.406.

For example and further illustration this health IT under the requirements of authorizes the OIG to investigate claims purposes, ONC may receive a complaint § 170.556 (under subpart E). that a health IT developer of certified of information blocking alleging that a Additionally, ONC could follow the health IT has engaged in information health IT developer has limited the CAP process under § 170.580(c) to blocking, which is defined by section ability to receive secure Direct messages enforce the associated ‘‘API’’ Condition 3022(a)(1) of the PHSA subject to from users of a competing developer’s of Certification proposed in reasonable and necessary activities EHR. The complaint alleges the certified § 170.404(a)(2). During the course of the identified by the Secretary as exceptions health IT drops the incoming message ONC–ACB surveillance, the ONC–ACB to the definition as proposed at part 171 without alerting the user that a message subsequently discovers the developer (see section VIII. of this proposed rule). was ever received. ONC would consider has implemented the FHIR DSTU 2 Additionally, section 3022(b)(1)(A)(i) the information blocking concerns standard and associated resources in authorizes OIG to investigate claims that (proposed § 170.401) as well as the such as a way that the patient’s a health IT developer of certified health potential safety concerns presented by historical medications are being IT has submitted a false attestation dropped messages associated with accessed, but not the patient’s current under the Condition of Certification certified functionality of the 2015 medications. The ONC–ACB would described at section 3001(c)(5)(D)(vii). Edition ‘‘transitions of care’’ notify ONC of its findings as it relates We emphasize that ONC’s and OIG’s certification criterion (§ 170.315(b)(1)) to a Condition of Certification under respective authorities under the Cures and standards for the secure Direct subpart D and pursue its own corrective Act (and in general) are independent messaging in its review. For the action process under the surveillance and that either or both offices may potential safety concerns, ONC would requirements of § 170.556. Once ONC exercise those authorities at any time. be exercising its authority to review receives information regarding the We anticipate, however, that ONC and certified health IT that may be causing complaints from the ONC–ACB, we OIG may coordinate their respective or contributing to conditions that could consider the potential safety risks enforcement activities, as appropriate, present a serious risk to public health or for providers using the developer’s API such as by sharing information about safety under § 170.580(a)(2)(i). In to access new or referred patients’ claims or suggestions of possible contrast, the ONC–ACB would not be medical information for diagnostic and information blocking or false responsible for reviewing the treatment purposes. In this example, attestations (including violations of information blocking or safety concerns ONC could review both the certified Conditions and Maintenance of directly, but it would be responsible for health IT and the developer action Certification that may indicate that a assessing whether surveillance needs to under § 170.580, which is proposed to developer has falsely attested to meeting be performed on the certified health IT be expanded to account for developer a condition). Therefore, we propose that for the functionality in the 2015 Edition actions under the Conditions and we may coordinate our review of a claim of information blocking with the ‘‘transitions of care’’ certification Maintenance of Certification (see OIG or defer to the OIG to lead a review criterion (§ 170.315(b)(1)) and the 2015 proposed § 170.580(a)(2)(iii)) in addition of a claim of information blocking. In Edition ‘‘Direct Project’’ certification to ONC’s direct investigation of certified addition, we propose that we may rely criterion (§ 170.315(h)(1)), as these health IT for potential safety risks (see on OIG findings to form the basis of a requirements are found within subpart § 170.580(a)(2)(i)). direct review action. C of Part 170 and could be implicated 6. Concurrent Enforcement by the Office based on the complaint. of Inspector General 7. Applicability of Conditions and To provide another example, an We clarify that the enforcement Maintenance of Certification ONC–ACB could receive complaints approach described in this proposal Requirements for Self-Developers from users that a developer’s certified would apply to ONC’s administration of The final rule establishing ONC’s health IT does not support the FHIR the Conditions and Maintenance of Permanent Certification Program, DSTU 2 standard and associated API Certification and other requirements ‘‘Establishment of the Permanent resource collection in health (ARCH under the Program but would not apply Certification for Health Information’’ (76 Version 1) as required in the proposed to other agencies or offices that have FR 1261), addresses self-developers. The new 2015 Edition certification criterion independent authority to investigate language in the final rule describes the § 170.315(g)(10) (proposed under and take enforcement action against a concept of ‘‘self-developed’’ as referring subparts B and C).The respective ONC– health IT developer of certified health to a Complete EHR or EHR Module ACB(s) responsible for the certification IT. Notably, section 3022(b)(1)(A)(ii) of designed, created, or modified by an of the certified health IT could surveil the PHSA, as added by the Cures Act, entity that assumed the total costs for

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00085 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7508 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

testing and certification and that will be subsequently in section VIII.D of this adverse incentives remain and continue the primary user of the health IT (76 FR preamble. to undermine progress toward a more 1300). Therefore, self-developers differ connected health system. 1. Purpose of the Information Blocking Based on these economic realities and from other health IT developers in that Provision their products are not made our first-hand experience working with commercially available and they do not The information blocking provision the health IT industry and stakeholders, have customers. While we propose that was enacted in response to concerns in the Information Blocking all general Conditions and Maintenance that some individuals and entities are Congressional Report, we concluded of Certification requirements apply to engaging in practices that unreasonably that information blocking is a serious such developers, we also seek comment limit the availability and use of problem and recommended that on which aspects of the Conditions and electronic health information (EHI) for Congress prohibit information blocking Maintenance of Certification authorized and permitted purposes. and provide penalties and enforcement requirements may not be applicable to These practices undermine public and mechanisms to deter these harmful self-developers. For example, when private sector investments in the practices. considering the Communications nation’s health IT infrastructure and Recent empirical and economic Condition of Certification, a self- frustrate efforts to use modern research further underscores the developer of health IT may not have technologies to improve health care intractability of this problem and its customer contracts, but could have quality and efficiency, accelerate harmful effects. In a national survey of other agreements in place, such as research and innovation, and provide health information organizations, half of NDAs, that would be subject to the greater value and choice to health care respondents reported that EHR Condition of Certification. consumers. developers routinely engage in The nature and extent of information information blocking, and a quarter of VIII. Information Blocking blocking has come into sharp focus in respondents reported that hospitals and recent years. In 2015, at the request of health systems routinely do so. The A. Statutory Basis Congress, we submitted a Report on survey reported that perceived 101 Section 4004 of the Cures Act added Health Information Blocking motivations for such conduct included, section 3022 of the PHSA (42 U.S.C. (‘‘Information Blocking Congressional for EHR vendors, maximizing short-term 300jj–52, ‘‘the information blocking Report’’), in which we commented on revenue and competing for new clients, provision’’). Section 3022(a)(1) of the the then current state of technology and and for hospitals and health systems, PHSA defines practices that constitute of health IT and health care markets. strengthening their competitive position information blocking when engaged in Notably, we observed that prevailing relative to other hospitals and health 102 by a health care provider, or a health market conditions create incentives for systems. Other research suggests that some individuals and entities to information technology developer, these practices weaken competition exercise their control over EHI in ways exchange, or network. Section among health care providers by limiting that limit its availability and use. 3022(a)(3) authorizes the Secretary to patient mobility, encouraging Since that time, we have continued to consolidation, and creating barriers to identify, through notice and comment receive complaints and reports of rulemaking, reasonable and necessary entry for developers of new and information blocking from patients, innovative applications and activities that do not constitute clinicians, health care executives, information blocking for purposes of the technologies that enable more effective payers, app developers and other uses of clinical data to improve definition set forth in section 3022(a)(1). technology companies, registries and We propose to establish seven population health and the patient health information exchanges, 103 exceptions to the information blocking experience. professional and trade associations, and The information blocking provision definition, each of which would define many other stakeholders. ONC has provides a comprehensive response to certain activities that would not listened to and reviewed these these concerns. The information constitute information blocking for complaints and reports, consulted with blocking provision defines and creates purposes of section 3022(a)(1) of the stakeholders, and solicited input from possible penalties and disincentives for PHSA because they are reasonable and our federal partners in order to inform necessary to further the ultimate policy our proposed information blocking 102 See, e.g., Julia Adler-Milstein and Eric Pfeifer, goals of the information blocking policies. Stakeholders described Information Blocking: Is It Occurring And What provision. We also propose to interpret discriminatory pricing policies that Policy Strategies Can Address It?, 95 Milbank or define certain statutory terms and Quarterly 117, 124–25 (Mar. 2017), available at have the obvious purpose and effect of http://onlinelibrary.wiley.com/doi/10.1111/1468- concepts that are ambiguous, excluding competitors from the use of 0009.12247/full. incomplete, or provide the Secretary interoperability elements. Many of the 103 See, e.g., Martin Gaynor, Farzad Mostashari, with discretion, and that we believe are industry stakeholders who shared their and Paul B. Ginsberg, Making Health Care Markets necessary to carry out the Secretary’s Work: Competition Policy for Health Care, 16–17 perspectives with us in listening (Apr. 2017), available at http://heinz.cmu.edu/ rulemaking responsibilities under sessions, including several health IT news/news-detail/index.aspx?nid=3930; Diego A. section 3022(a)(3). developers of certified health IT, Martinez et al., A Strategic Gaming Model For condemned these practices and urged us Health Information Exchange Markets, Health Care B. Legislative Background and Policy Mgmt. Science (Sept. 2016). (‘‘[S]ome healthcare Considerations to swiftly address them. Our provider entities may be interfering with HIE across engagement with stakeholders confirms disparate and unaffiliated providers to gain market In this section, we outline the purpose that, despite significant public and advantage.’’) Niam Yaraghi, A Sustainable Business private sector efforts to improve Model for Health Information Exchange Platforms: of the information blocking provision The Solution to Interoperability in Healthcare IT and related policy and practical interoperability and data accessibility, (2015), available at http://www.brookings.edu/ considerations that we considered in research/papers/2015/01/30-sustainable-business- identifying the reasonable and necessary 101 ONC, Report to Congress on Health model-health-information-exchange-yaraghi; Information Blocking (Apr. 2015), https:// Thomas C. Tsai & Ashish K. Jha, Hospital activities that are proposed as www.healthit.gov/sites/default/files/reports/ Consolidation, Competition, and Quality: Is Bigger exceptions to the definition of info_blocking_040915.pdf [hereinafter ‘‘Information Necessarily Better?, 312 J. AM. MED. ASSOC. 29, information blocking described Blocking Congressional Report’’]. 29 (2014).

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00086 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7509

information blocking in broad terms, would not be penalized (sections Third, and last, each exception is while working to deter the entire 3022(a)(6) and (7) of the PHSA). intended to be tailored, through spectrum of practices that unnecessarily In considering potential exceptions to appropriate conditions, so that it is impede the flow of EHI or its use to the information blocking provision, we limited to the reasonable and necessary improve health and the delivery of care. must balance a number of policy and activities that it is designed to protect The information blocking provision practical considerations. To minimize and does not extend protection to other applies to the conduct of health care compliance and other burdens for activities or practices that could raise providers, and to health IT developers stakeholders, we seek to promote information blocking concerns. of certified health IT, exchanges, and policies that are clear, predictable, and We discuss these policy networks, and seeks to deter it with administrable. In addition, we seek to considerations in more detail in the substantial penalties, including civil implement the information blocking context of each of the exceptions money penalties, and disincentives for provision in a way that is sensitive to proposed in section VIII.D of this violations. Additionally, developers of legitimate practical challenges that may preamble. health IT certified under the Program prevent access, exchange, or use of EHI are prohibited from information in certain situations. We must also C. Relevant Statutory Terms and blocking under 3001(c)(5)(D)(i) of the accommodate practices that, while they Provisions PHSA. To promote effective may inhibit access, exchange, or use of In this section of the preamble, we enforcement, the information blocking EHI, are reasonable and necessary to discuss how we propose to interpret provision empowers the HHS Office of advance other compelling policy certain aspects of the information Inspector General (OIG) to investigate interests, such as preventing harm to blocking provision that we believe are claims of information blocking and patients and others, promoting the ambiguous, incomplete, or that provide provides referral processes to facilitate privacy and security of EHI, and the Secretary with discretion. We promoting competition and consumer coordination with other relevant propose to define or interpret certain welfare. agencies, including ONC, the HHS terms or concepts that are present in the Office for Civil Rights (OCR), and the At the same time, while pursuing these objectives, we must adhere to statute and, in a few instances, to Federal Trade Commission (FTC). The establish new regulatory terms or information blocking provision also Congress’s plainly expressed intent to provide a comprehensive response to definitions that we believe are necessary provides for a complaint process and to implement the Secretary’s authority corresponding confidentiality the information blocking problem. Information blocking can occur through under section 3022(a)(3) to identify protections to encourage and facilitate reasonable and necessary activities that the reporting of information blocking. a variety of business, technical, and organizational practices that can be do not constitute information blocking. Enforcement of the information blocking difficult to detect and that are Our goal in interpreting the statute and provision is buttressed by section constantly changing as technology and defining relevant terms is to provide 3001(c)(5)(D)(i) and (vi) of the PHSA, industry conditions evolve. The statute greater clarity concerning the types of which prohibits information blocking by responds to these challenges by defining practices that could implicate the developers of certified health IT as a information blocking broadly and in a information blocking provision and, Condition and Maintenance of manner that allows for careful relatedly, to more effectively Certification requirement under the consideration of relevant facts and communicate the applicability and Program and requires them to attest that circumstances in individual cases. scope of the proposed exceptions they have not engaged in such practices. Accordingly, we propose to establish outlined in this proposed rule. We 2. Policy Considerations and Approach certain defined exceptions to the believe that these proposals will provide to the Information Blocking Provision information blocking provision. These a more meaningful opportunity for the exceptions would be subject to strict public to comment on the proposed To ensure that individuals and conditions that balance the exceptions and our overall approach to entities that engage in information considerations described above. Based interpreting and administering the blocking are held accountable, the on those considerations, in developing information blocking provision. information blocking provision the proposed exceptions, we applied Additionally, we believe additional encompasses a relatively broad range of three overarching policy criteria. First, interpretive clarity will assist regulated potential practices. For example, it is each exception would be limited to actors to comply with the requirements possible that some activities that are certain activities that are both of the information blocking provision. innocuous, or even beneficial, could reasonable and necessary to advance the 1. ‘‘Required by Law’’ technically implicate the information aims of the information blocking blocking provision. Given the provision. These reasonable and With regard to the statute’s exclusion possibility of these practices, Congress necessary activities include: Promoting of practices that are ‘‘required by law’’ authorized the Secretary to identify public confidence in the health IT from the definition of information reasonable and necessary activities that infrastructure by supporting the privacy blocking, we emphasize that ‘‘required do not constitute information blocking and security of EHI, and protecting by law’’ refers specifically to (see section 3022(a)(3) of the PHSA) (in patient safety; and promoting interferences with access, exchange, or this proposed rule, we refer to such competition and innovation in health IT use of EHI that are explicitly required by reasonable and necessary activities and its use to provide health care state or federal law. By carving out identified by the Secretary as services to consumers. Second, we practices that are ‘‘required by law,’’ the ‘‘exceptions’’ to the information believe that each exception addresses a statute acknowledged that there are state blocking provision). The information significant risk that regulated and federal laws that advance important blocking provision also excludes from individuals and entities will not engage policy interests and objectives by the definition of information blocking in these reasonable and necessary restricting access, exchange, and use of practices that are required by law activities because of uncertainty their EHI, and that practices that follow (section 3022(a)(1) of the PHSA) and regarding the breadth or applicability of such laws should not be considered clarifies certain other practices that the information blocking provision. information blocking.

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00087 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7510 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

We note that for the purpose of b. Health IT Developers of Certified ‘‘certified health information developing an exception for reasonable Health IT technology.’’ That the scope of the and necessary privacy-protective Section 3022(a)(1)(B) of the PHSA information blocking provision should practices, we have distinguished defines information blocking, in part, by not be limited to practices that involve between interferences that are ‘‘required reference to the conduct of ‘‘health only certified health IT is further by law’’ and those engaged in pursuant information technology developers.’’ evidenced by no such limitation to a privacy law, but which are not Because title XXX of the PHSA does not applying to health care providers, health ‘‘required by law.’’ The former does not define ‘‘health information technology information exchanges (HIEs), and fall within the definition of information developer,’’ we interpret section health information networks (HINs) as blocking, but the latter may implicate 3022(a)(1)(B) in light of the specific listed in sections 3022(b)(1) of the authority provided to OIG in section PHSA. the information blocking provision and Additionally, the ‘‘practice described’’ 3022(b)(1)(A) and (b)(2). Section an exception may be necessary. For a in section 3022(a)(2) of the PHSA refers 3022(b)(2) discusses developers, detailed discussion of this topic, please to ‘‘certified health information networks, and exchanges in terms of an see section VIII.D.2 of this preamble. technologies’’ when illustrating ‘‘individual or entity,’’ specifically practices that restrict authorized access, 2. Health Care Providers, Health IT cross-referencing section 3022(b)(1)(A). exchange, or use of EHI under Developers, Exchanges, and Networks Sections 3002(b)(1) and (b)(1)(A) state, applicable state or federal laws (section in relevant part, that the OIG may 3022(a)(2)(A) of the PHSA), but omits Section 3022(a)(1) of the PHSA, in investigate information blocking claims any reference to certification when defining information blocking, refers to regarding a health information four classes of individuals and entities describing ‘‘health information technology developer of certified health technology’’ in the practices described that may engage in information blocking information technology or other entity and which include: Health care in sections 3022(a)(2)(B) and (C) of the offering certified health information PHSA. Importantly, sections providers, health IT developers of technology. Together, these sections certified health IT, networks, and 3022(a)(2)(B) and (C) of the PHSA make clear that the information blocking address practices that are particularly exchanges. We propose to adopt provisions and OIG’s authority extend relevant to health IT developers and definitions of these terms to provide to individuals or entities that develop or offerors, although they could be engaged clarity regarding the types of offer certified health IT. That the in by other types of actors. We interpret individuals and entities to whom the individual or entity must develop or this drafting as a deliberate decision not information blocking provision applies. offer certified health IT is further to link the information blocking We note that, for convenience and to supported by section 3022(a)(7) of the provisions with only the performance or avoid repetition in this preamble, we PHSA—which refers to developers’ use of certified health IT. typically refer to these individuals and responsibilities to meet the Finally, we note that the Cures Act entities covered by the information requirements of certification—and does not impose a temporal nexus that blocking provision as ‘‘actors’’ unless it section 4002 of the Cures Act—which would require that information blocking is relevant or useful to refer to the identifies information blocking as a be carried out at a time when an specific type of individual or entity. Condition of Certification. individual or entity had health IT That is, when the term ‘‘actor’’ appears Notwithstanding this, the Cures Act certified under the Program. Ostensibly, does not prescribe that conduct that in this preamble, it means an individual then, once an individual or entity has may implicate the information blocking or entity that is a health care provider, health IT certified, or otherwise provisions be limited to practices health IT developer, exchange, or maintains the certification of health IT, related to only certified health IT. the individual or entity becomes forever network. For the same reasons, we Rather, the information blocking propose to define ‘‘actor’’ in § 171.102. subject to the information blocking provisions would be implicated by any provision. We do not believe that, a. Health Care Providers practice engaged in by an individual or understood in context, the Cures Act entity that develops or offers certified supports such a broad interpretation. The term ‘‘health care provider’’ is health IT that is likely to interfere with Noting the above discussion concerning defined in section 3000(3) of the PHSA. the access, exchange, or use of EHI, OIG’s scope of authority under section We propose to adopt this definition for including practices associated with any 3022(b)(1)(A) and (b)(2) of the PHSA, we purposes of section 3022 of the PHSA of the developer or offeror’s health IT believe that to make developers and when defining ‘‘health care provider’’ in products that have not been certified offerors of certified health IT subject to § 171.102. We note that this definition is under the Program. This interpretation the information blocking provision in different from the definition of ‘‘health is based primarily on section 3022(b)(1) perpetuity would be inconsistent with care provider’’ under the HIPAA Privacy of the PHSA. If Congress had intended the voluntary nature of the Program. and Security Rules. We are considering that the enforcement of the information However, we also believe that the Cures adjusting the information blocking blocking provisions were limited to Act does not provide any basis for definition of ‘‘health care provider’’ to practices connected to certified health interpreting the information blocking cover all individuals and entities IT, we believe the Cures Act would have provision so narrowly that a developer covered by the HIPAA ‘‘health care included language that tied enforcement or offeror of certified health IT could provider’’ definition. We seek comment to the operation or performance of a escape penalty as a consequence of product certified under the Program. on whether this approach would be having its certification terminated or by Rather, the description of the practices justified, and commenters are withdrawing all of its extant that OIG can investigate in section certifications. encouraged to specify reasons why 3022(b)(1)(A)(ii) of the PHSA are not We consider that in the circumstances doing so might be necessary to ensure tied to the certification status of the where a health IT developer has its that the information blocking provision health IT at issue, omitting any express certification terminated, or withdraws applies to all health care providers that reference to a health IT developer’s its certification, such that it no longer might engage in information blocking. practice needing to be related to has any health IT certified under the

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00088 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7511

Program, it should nonetheless be are aware they typically have great We clarify that we interpret subject to penalties for information difficulty doing.104 ‘‘individual or entity that develops the blocking engaged in during the time that One way that this could be achieved certified health IT’’ as the individual or it did have health IT certified under the would be to define ‘‘health IT developer entity that is legally responsible for the Program. Accordingly, we propose to of certified health IT’’ as including certification status of the health IT, adopt a definition of ‘‘heath information developers and offerors of certified which would be the individual or entity technology (IT) developer of certified health IT that continue to store EHI that that entered into a binding agreement health IT’’ for the purposes of was previously stored in health IT that resulted in the certification status of interpretation and enforcement of the certified in the Program. Alternatively, the health IT under the Program or, if information blocking provisions, we are considering whether developers such rights are transferred, the including those regulatory provisions and offerors of certified health IT should individual or entity that holds the rights proposed under Title 45, part 171, of the remain subject to the information to the certified health IT. We also clarify Code of Federal Regulations, that would blocking provision for an appropriate that an ‘‘individual or entity that offers capture such developers or offerors. We period of time after leaving the Program. certified health IT’’ would include an propose, in § 171.102, that ‘‘health IT Namely, that the information blocking individual or entity that under any developer of certified health IT’’ means provision should apply for a specific arrangement makes certified health IT an individual or entity that develops or time period, say one year, after the available for purchase or license. We offers health information technology (as developer or offeror no longer has any seek comment on both of our that term is defined in 42 U.S.C. health IT certified in the Program. This interpretations. More specifically, we 300jj(5)) and which had, at the time it second approach has the attraction of seek comment on whether there are engaged in a practice that is the subject providing a more certain basis for particular types of arrangements under of an information blocking claim, health understanding which developers are which certified health IT is ‘‘offered’’ in IT (one or more) certified under the subject to the information blocking which the offeror should not be Program. To note, we propose that the provision. However, it also potentially considered a ‘‘health IT developer of term ‘‘information blocking claim’’ captures developers and offerors who certified health IT’’ for the purposes of within this definition should be read have fully removed themselves from the the information blocking provisions. broadly to encompass any statement of Program and, for example, no longer We also clarify that the proposed information blocking or potential exercise control over EHI that was definition of ‘‘health IT developer of information blocking. ‘‘Claims’’ of stored in their certified health IT. certified health IT’’ and our information blocking within this We seek comment on which of these interpretation of the use of ‘‘health definition would not be limited, in any two models best achieves our policy information technology developer’’ way, to a specific form, format, or goal of ensuring that health IT applies to Part 171 only and does not submission approach or process. developers of certified health IT will apply to the implementation of any We are also considering additional face consequences under the other section of the PHSA or the Cures approaches to help ensure that information blocking provision if they Act, including section 4005(c)(1) of the developers and offerors of certified engage in information blocking in Cures Act. health IT remain subject to the connection with EHI that was stored or We clarify that API Technology information blocking provision for an controlled by the developer or offeror Suppliers, as described in section VII.4 appropriate period of time after leaving whilst they were participating in the of this preamble and defined in the Program. The rationale for this program. Commenters are also § 170.102, would be considered health approach would be that a developer or encouraged to identify alternative IT developers of certified health IT offeror of certified health IT should be models and approaches for identifying subject to the conditions described subject to penalties if, following the when a developer or offeror should, and above. termination or withdrawal of should no longer, be subject to the Last, we clarify that a ‘‘self- certification, it refused to provide its information blocking provision. developer’’ of certified health IT, as the customers with access to the EHI stored We note that a developer or offeror of term has been used in the ONC Health in the decertified health IT, provided a single health IT product that has had IT Certification Program (Program) and that such interference was not required its certification suspended would be described in this rulemaking (section by law and did not qualify for one of the considered to have certified health IT VII.D.7) and previous rulemaking,105 information blocking exceptions. for the purpose of the definition. We would be treated as a health care Adopting this broader approach would also note that we interpret the provider for the purposes of information help avoid the risk that a developer requirement that the health IT developer blocking. This is because of our would be able to engage in the practices of certified health IT ‘‘exercise control’’ description of a self-developer for described in section 3022(a)(2) of the over EHI broadly. A developer would Program purposes 106 would essentially PHSA in respect to EHI that was not necessarily need to have access to mean that such developers would not be collected on behalf of a health care the EHI in order to exercise control. For supplying or offering their certified provider when that health care provider example, a developer that implemented health IT to other entities. To be clear, would reasonably expect that the a ‘‘kill-switch’’ for a decertified software self-developers would still be subject to information blocking provision would product that was locally hosted by a the proposed Conditions and protect against unreasonable and health care provider, preventing that unnecessary interferences with that EHI. provider from accessing its records, 105 The final rule establishing ONC’s Permanent If the information blocking provision would be exercising control over the Certification Program, ‘‘Establishment of the Permanent Certification for Health Information’’ (76 did not extend to capture such conduct, EHI for the purpose of this definition. FR 1261), addresses self-developers. the protection afforded by the 106 The language in the final rule describes the information blocking provision could 104 See ONC, EHR Contracts Untangled Selecting concept of ‘‘self-developed’’ as referring to a become illusory, and providers would Wisely, Negotiating Terms, And Understanding The complete EHR or EHR Module designed, created, or Fine Print, https://www.healthit.gov/sites/default/ modified by an entity that assumed the total costs need to consider securing contractual files/EHR_Contracts_Untangled.pdf (September for testing and certification and that will be the rights to prevent interference, which we 2016). primary user of the health IT (76 FR 1300).

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00089 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7512 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

Maintenance of Certification the other, or if both parties are under the following examples. An entity is requirements because they have health common control or ownership of a established within a state for the IT certified under the Program (see also common owner. We note that a purpose of improving the movement of section VII.D.7). We welcome comments significant implication of this definition EHI between the health care providers on our determination regarding ‘‘self- is that a health care provider or other operating in that state. The entity developers’’ for information blocking entity that enables, facilitates, or identifies standards relating to security purposes and whether there are other controls the movement of EHI within its and offers terms and conditions to be factors we should consider in how we own organization, or between or among entered into by health care providers treat ‘‘self-developers’’ of certified its affiliated entities, is not a HIN in wishing to participate in the network. health IT for the purposes of connection with that movement of The entity offering (and then overseeing information blocking. information for the purposes of this and administering) the terms and We also seek comment generally on proposed rule. conditions for participation in the the definition proposed for ‘‘health IT More affirmatively, we propose that network would be considered a HIN for developer of certified health IT.’’ an actor could be considered a HIN if it the purpose of the information blocking performs any or any combination of the c. Networks and Exchanges provision. We note that there is no need following activities. First, the actor for a separate entity to be created in The terms ‘‘network’’ and ‘‘exchange’’ would be a HIN if it were to determine, order that an entity be considered a are not defined in the information oversee, administer, control, or HIN. For instance, a health system that blocking provision or in any other substantially influence policies or administers business and operational relevant statutory provisions. We agreements that define the business, agreements for facilitating the exchange propose to define these terms so that operational, technical, or other of EHI that are adhered to by these individuals and entities that are conditions or requirements that enable unaffiliated family practices and covered by the information blocking or facilitate the access, exchange, or use specialist clinicians in order to provision understand that they must of EHI between or among two or more streamline referrals between those comply with its provisions. In unaffiliated individuals or entities. practices and specialists would likely be accordance with the meaning and intent Second, an actor would be a HIN if it considered a HIN. of the information blocking provision, were to provide, manage, control, or We note that the proposed definition we believe it is necessary to define these substantially influence any technology would also encompass an individual or terms in a way that does not assume the or service that enables or facilitates the application or use of certain access, exchange, or use of EHI between entity that does not directly enable, technologies and is flexible enough to or among two or more unaffiliated facilitate, or control the movement of apply to the full range and diversity of individuals or entities. information, but nonetheless exercises exchanges and networks that exist today Typically, a HIN will influence the control or substantial influence over the and may arise in the future. We note sharing of EHI between many policies, technology, or services of a that in the past few years alone many unaffiliated individuals or entities. network. In particular, there may be an new types of exchanges and networks However, we do not propose to establish individual or entity that relies on that transmit EHI have emerged, and we any minimum number of parties or another entity—such as an entity expect this trend to accelerate with ‘‘nodes’’ beyond the requirement that specifically created for the purpose of continued advancements in technology there be some actual or contemplated managing a network—for policies and and renewed efforts to advance trusted access, exchange, or use of information technology, but nevertheless dictates the exchange among networks and other between or among at least two movement of EHI over that network. For entities under the trusted exchange unaffiliated individuals or entities that example, a large health care provider framework and common agreement is enabled, facilitated, or controlled by may decide to lead an effort to establish provided for by section 4003(b) of the the HIN. We believe such a limitation a network that facilitates the movement Cures Act. would be artificial and would not of EHI between a group of smaller In considering the most appropriate capture the full range of entities that health care providers (as well as the way to define these terms, we examined should be considered networks under large health care provider) and through how they are used throughout the Cures the information blocking provision. To the technology of health IT developers. Act and the HITECH Act. Additionally, be clear, any individual or entity that To achieve this outcome, the large we considered dictionary and industry enables, facilitates, or controls the health care provider, together with some definitions of ‘‘network’’ and access, exchange, or use of EHI between of the participants, creates a new entity ‘‘exchange.’’ While these terms have or among only itself and another that administers the network’s policies varied usage and meaning in different unaffiliated individual or entity would and technology. In this scenario, the industry contexts, certain concepts are not be considered a HIN in connection large health care provider would come common and have been incorporated with the movement of that EHI within the functional definition of a into the proposed definitions below. (although that movement of EHI may HIN and could be held accountable for still be regulated under the information the conduct of the network if the large i. Health Information Network blocking provision on the basis that the health care provider used its control or We propose a functional definition of individual or entity is a health care substantial influence over the new ‘‘health information network’’ (HIN) that provider or health IT developer of entity—either in a legal sense, such as focuses on the role of these actors in the certified health IT). To be a HIN, the via its control over the governance or health information ecosystem. We individual or entity would need to be management of the entity, or in a less believe the defining attribute of a HIN enabling, facilitating, or controlling the formal sense, such as if the large health is that it enables, facilitates, or controls access, exchange, or use of EHI between care provider prescribed a policy to be the movement of information between or among two or more other individuals adopted—to interfere with the access, or among different individuals or or entities that were not affiliated with exchange, or use of EHI. We note that entities that are unaffiliated. For this it. the large health care provider in this purpose, we propose that two parties are To illustrate how the proposed example would be treated as a health affiliated if one has the power to control definition would operate, we note the care provider when utilizing the

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00090 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7513

network to move EHI via the network’s blocking provision, and whether the billing for health care services, and policies, technology, or services, but proposed definition is sufficiently payment information for services to be would be considered a HIN in flexible to accommodate changing provided or already provided, which connection with the practices of the technological and other conditions. may include price information. network over which the large health 3. Electronic Health Information Price Information care provider exercises control or substantial influence. The definition of information The fragmented and complex nature We seek comment on the proposed blocking applies to electronic health of pricing within the health care system definition of a HIN. In particular, we information (EHI) (section 3022(a)(1) of has decreased the efficiency of the request comment on whether the the PHSA). While section 3000(4) of the health care system and has had negative proposed definition is broad enough (or PHSA by reference to section 1171(4) of impacts on patients, health care too broad) to cover the full range of the Social Security Act defines ‘‘health providers, health systems, plans, plan individuals and entities that could be information,’’ EHI is not specifically sponsors and other key health care considered health information networks defined in the Cures Act, HITECH Act, stakeholders. Patients and plan sponsors within the meaning of the information or other relevant statutes. We propose to have trouble anticipating or planning for blocking provision. Additionally, we define EHI to mean: costs, are not sure how they can lower specifically request comment on (i) Electronic protected health their costs, are not able to compare whether the proposed definition would information; and costs, and have no practical way to effectuate our policy goal of defining (ii) any other information that— measure the quality of the care or • this term in a way that does not assume is transmitted by or maintained in coverage they receive relative to the particular technologies or arrangements electronic media, as defined in 45 CFR price they pay. Pricing information and is flexible enough to accommodate 160.103; continues to grow in importance with • changes in these and other conditions. identifies the individual, or with the increase of high deductible health respect to which there is a reasonable plans and surprise billing, which have ii. Health Information Exchange basis to believe the information can be resulted in an increase in out-of-pocket We propose to define a ‘‘health used to identify the individual; and health care spending. Transparency in information exchange’’ (HIE) as an • relates to the past, present, or future the price and cost of health care would individual or entity that enables access, health or condition of an individual; the help address the concerns outlined exchange, or use of EHI primarily provision of health care to an above by empowering patients to make between or among a particular class of individual; or the past, present, or informed health care decisions. Further, individuals or entities or for a limited future payment for the provision of the availability of price information set of purposes. Our research and health care to an individual. could help increase competition that is experience in working with exchanges This definition of EHI includes, but is based on the quality and value of the drove the proposed definition of this not limited to, electronic protected services patients receive. Consistent term. HIEs include but are not limited health information and health with its statutory authority, the to regional health information information that is created or received Department is considering subsequent organizations (RHIOs), state health by a health care provider and those rulemaking to expand access to price information exchanges (state HIEs), and operating on their behalf; health plan; information for the public, prospective other types of organizations, entities, or health care clearinghouse; public health patients, plan sponsors, and health care arrangements that enable EHI to be authority; employer; life insurer; school; providers. accessed, exchanged, or used between or university. In addition, we clarify Increased consumer demand, aligned or among particular types of parties or that under our proposed definition, EHI incentives, more accessible and for particular purposes. For example, an includes, but is not limited to, digestible information, and the HIE might facilitate or enable the access, electronic protected health information evolution of price transparency tools are exchange, or use of EHI exclusively (ePHI) as defined in 45 CFR 160.103. In critical components to moving to a within a regional area (such as a RHIO), particular, unlike ePHI and health health care system that pays for value. or for a limited scope of participants information, EHI is not limited to However, the complex and and purposes (such as a clinical data information that is created or received decentralized nature of how price registry or an exchange established by a by a health care provider, health plan, information is created, structured, hospital-physician organization to health care clearinghouse, public health formatted, and stored presents many facilitate Admission, Discharge, and authority, employer, life insurer, school, challenges to achieving price Transfer (ADT) alerting). We note that or university. EHI may be provided, transparency. To this point, pricing HIEs may be established under federal directly from an individual, or from within health care demands a market- or state laws or regulations but may also technology that the individual has based approach whereby, for example, be established for specific health care or elected to use, to an actor covered by the platforms are created that utilize raw business purposes or use cases. information blocking provisions. We data to provide consumers with Additionally, we note that if an HIE propose that EHI does not include digestible price information through facilitates the access, exchange, or use of health information that is de-identified their preferred medium. EHI for more than a narrowly defined consistent with the requirements of 45 ONC has a unique role in setting the set of purposes, then it may be both an CFR 164.514(b). We generally request stage for such future actions by HIE and a HIN. comment on this proposed definition as establishing the framework to prevent We seek comment on this proposed well as on whether the exclusion of the blocking of price information. Given definition of an HIE. Again, we health information that is de-identified that price information impacts the encourage commenters to consider is consistent with the requirements of ability of patients to shop for and make whether this proposed definition is 45 CFR 164.514(b). decisions about their care, we seek broad enough (or too broad) to cover the To be clear, this definition provides comment on the parameters and full range of individuals and entities for an expansive set of EHI, which could implications of including price that could be considered exchanges include information on an individual’s information within the scope of EHI for within the meaning of the information health insurance eligibility and benefits, purposes of information blocking. In

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00091 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7514 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

addition, the overall Department seeks • Are there electronic mechanisms/ Æ The provision of a binding quote comment on the technical, operational, processes available for providing price reasonably in advance of scheduled care legal, cultural, environmental and other information to patients who are not (that is, non-emergent care) or some challenges to creating price registered (i.e., not in the provider subset of scheduled care, such as for the transparency within health care. system) when they try to get price most ‘‘shoppable’’ services; • Should prices that are included in information? Æ Ensuring that all health care EHI: • Should price information be made providers in an in-network facility Æ Reflect the amount to be charged to available on public websites so that charge the in-network rate; and and paid for by the patient’s health plan patients can shop for care without Æ Notification of billing policies such (if the patient is insured) and the having to contact individual providers, as timely invoice dates for all providers amount to be charged to and collected and if so, who should be responsible for and facilities, notwithstanding network from the patient (as permitted by the posting such information? Additionally, status, due date for invoice payments by provider’s agreement with the patient’s how would the public posting of pricing the prospective patient’s payers and out- health plan), including for drugs or information through API technology of-pocket obligations, date when unpaid medical devices; help advance market competition and balances are referred for collections, and Æ Include various pricing information the ability of patients to shop for care? appeals rights and procedures for such as charge master price, negotiated • If price information that includes a patients wishing to contest an invoice? prices, pricing based on CPT codes or provider’s negotiated rates for all plans DRGs, bundled prices, and price to 4. Interests Promoted by the Information and the rates for the uninsured were to Blocking Provision payer; be required to be posted on a public Æ Be reasonably available in advance website, is there technology currently a. Access, Exchange, and Use of EHI and at the point of sale; available or that could be easily The information blocking provision Æ Reflect all out-of-pocket costs such developed to translate that data into a promotes the ability to access, as deductibles, copayments and useful format for individuals? Are there exchange, and use EHI, consistent with coinsurance (for insured patients); and/ existing standards and code sets that the requirements of applicable law. We or would facilitate such transmission and Æ Include a reference price as a interpret the terms ‘‘access,’’ translation? To the extent that some data ‘‘exchange,’’ and ‘‘use’’ broadly, comparison tool such as the Medicare standards are lacking in this regard, rate and, if so, what is the most consistent with their generally could developers make use of understood meaning in the health IT meaningful reference? unstandardized data? • For the purpose of informing industry and their function and context • What technical standards currently referrals for additional care and in the information blocking provision. exist or may be needed to represent prescriptions, should future rulemaking The concepts of access, exchange, and price information electronically for by the Department require health IT use are closely related: EHI cannot be purposes of access, exchange, and use? developers to include in their platforms used unless it can be accessed, and this • Are there technical impediments a mechanism for patients to see price often requires that the EHI be exchanged experienced by stakeholders regarding information, and for health care among different individuals or entities price information flowing providers to have access to price and through various technological electronically? information, tailored to an individual means. Moreover, the technological and • Would updates to the CMS- patient, integrated into the practice or other means necessary to facilitate managed HIPAA transactions standards clinical workflow through APIs? appropriate access and exchange of EHI • To the extent that patients have a and code sets be necessary to address vary significantly depending on the right to price information within a the movement of price information in a purpose for which the information will standardized way? be used. For example, the technologies reasonable time in advance of care, how • would such reasonableness be defined How can price transparency be and services that support a payer’s for: achieved for care delivered through access to EHI to assess clinical value Æ Scheduled care, including how far value based arrangements, including at will likely differ from those that support in advance should such pricing be accountable care organizations, a patient’s access to EHI via a available for patients still shopping for demonstrations and other risk-sharing smartphone app. That is, to deter care, in addition to those who have arrangements? information blocking in these and many • already scheduled care; What future requirements should other potential uses of EHI—and, by Æ Emergency care, including how and the Department consider regarding the extension, the many and diverse means when transparent prices should be inclusion of price information in a of access and exchange that support disclosed to patients and what sort of patient’s EHI, particularly as it relates to such uses. exceptions might be appropriate, such the amount paid to a health care This is consistent with the way these as for patients in need of immediate provider by a patient (or on behalf of a terms are employed in the information stabilization; patient) as well as payment calculations blocking provision and in other relevant Æ Ambulance services, including air for the future provision of health care to statutory provisions. For example, ambulance services; and such patient? section 3022(a)(2) of the PHSA Æ Unscheduled inpatient care, such • If price information is included in contemplates a broad range of purposes as admissions subsequent to an EHI, could that information be useful in for which EHI may be accessed, emergency visit? subsequent rulemaking that the exchanged, and used—from treatment, • How would price information vary Department may consider in order to care delivery, and other permitted based on the type of health insurance reduce or prevent surprise medical purposes, to exporting complete and/or payment structure being utilized, billing, such as requirements relating to: information sets and transitioning and what, if any, challenges would such Æ The provision of a single bill that between health IT systems, to variation create to identifying the price includes all health care providers supporting innovations and information that should be made involved in a health care service, advancements in health information available for access, exchange, or use? including their network status; access, exchange, and use. Separately,

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00092 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7515

the Cures Act and the HITECH Act may implicate the information blocking definition realizes that intent and, if not, contemplate many different purposes provision, we propose definitions of any changes we should consider. for and means of accessing, exchanging, access, exchange, and use in § 171.102. 5. Practices That May Implicate the and using EHI, which include, but are We emphasize the interrelated nature of Information Blocking Provision not limited to, quality improvement, the definitions. For example, the guiding medical decisions at the time definition of ‘‘use’’ includes the ability To meet the definition of information and place of care, reducing medical to read, write, modify, manipulate, or blocking, a practice must be likely to errors and health disparities, delivering apply EHI to accomplish a desired interfere with, prevent, or materially patient-centered care, and supporting outcome or to achieve a desired discourage access, exchange, or use of public health and clinical research purpose, while ‘‘access’’ is defined as EHI. In this section and elsewhere in activities.107 the ability or means necessary to make this preamble, we discuss various types In addition to these statutory EHI available for use. As such, of hypothetical practices that could provisions, we have considered how the interference with ‘‘access’’ would implicate the provision. We do this to terms access, exchange, and use have include, for example, an interference illustrate the scope of the information been defined or used in existing that prevented a health care provider blocking provision and to explain our regulations and other relevant health IT from writing EHI to its health IT or from interpretation of various statutory industry contexts. While those modifying EHI stored in health IT, concepts. However, we stress that the definitions have specialized meanings whether by the provider itself or by, or types of practices discussed in this and are not controlling here, they are via, a third-party app. We encourage preamble are illustrative, not instructive insofar as they illustrate the comment on these definitions. In exhaustive, and that many other types of breadth with which these terms have particular, commenters may wish to practices could also implicate the been understood in other contexts. For consider whether these definitions are provision. Nor does the fact that we example, the HIPAA Privacy Rule broad enough to cover all of the have not identified or discussed a defines an individual’s right of access to potential purposes for which EHI may particular type of practice imply that it include the right to have a copy of all be needed and ways in which it could is less serious than those that are or part of their PHI transmitted directly conceivably be used, now and in the discussed in this preamble. Indeed, to them or any person or entity he or she future. because information blocking may take designates, in any form and format many forms, it is not possible—and we (including electronically) that the b. Interoperability Elements do not attempt—to anticipate or catalog individual requests and that the covered In this proposed rule, we use the term the many potential types of practices entity holding the information can ‘‘interoperability element’’ to refer to that may raise information blocking readily produce (45 CFR 164.524). In a any means by which EHI can be concerns. different context, the HIPAA Security accessed, exchanged, or used. We clarify We emphasize that any analysis of Rule defines ‘‘access’’ as the ability or that the means of accessing, exchanging, information blocking necessarily the means necessary to read, write, and using EHI are not limited to requires a careful consideration of the modify, or communicate data/ functional elements and technical individual facts and circumstances, information or otherwise use any system information but also encompass including whether the practice was resource (45 CFR 164.304). The HIPAA technologies, services, policies, and required by law, whether the actor had Rules also define the term ‘‘use,’’ which other conditions 108 necessary to the requisite statutory knowledge, and includes the sharing, employment, support the many potential uses of EHI whether an exception applies. When we application, utilization, examination, or as described above. Because of the state that a practice would implicate the analysis of individually identifiable evolving nature of technology and the provision or could violate the provision, health information within an entity that diversity of privacy laws and we are expressing a conclusion that the maintains the information (45 CFR regulations, institutional arrangements, type of practice is one that would be 160.103). and policies that govern the sharing of likely to interfere with, prevent, or As the examples and discussion above EHI, we will not provide an exhaustive materially discourage access, exchange, demonstrate, the concepts of access, list of interoperability elements. or use of EHI, and that further analysis exchange, and use are used in a variety However, we believe that it is useful to of these and other statutory elements of contexts to refer to a broad spectrum define this term, both because of its would therefore be warranted to of activities. We believe that the types importance for analyzing the likelihood determine whether a violation has of access, exchange, and use described of interference under the information occurred. We highlight this distinction above would be promoted under the blocking provision, and because some of because to implicate the information information blocking provision, as the proposed exceptions to the blocking provision is not necessarily to would other types of access, exchange, provision contain conditions concerning violate it, and that each case will turn or use not specifically contemplated in the availability and provision of on its own unique facts. For example, a these or other regulations. Further, we interoperability elements. Therefore, we practice that seemingly meets the note that the information blocking propose to define ‘‘interoperability statutory definition of information provision would also extend to element’’ in § 171.102. As noted, our blocking would not be information innovations and advancements in health intent is to capture all of the potential blocking if it was required by law, if one information access, exchange, and use means by which EHI may be accessed, or more elements of the definition were that may occur in the future (see section exchanged, or used for any relevant not met, or if was covered by one of the 3022(a)(2) of the PHSA). purposes; both now and as technology proposed exceptions. Consistent with the above, and to and other conditions evolve. We seek We propose in section VIII.D of this convey the full breadth of activities that comment on whether the proposed preamble to establish seven exceptions to the information blocking provision 107 See section 3001(b) of the PHSA; see also 108 See ONC, Connecting Health and Care for the for certain reasonable and necessary section 3009(a)(3) of the PHSA (enumerating Nation: A Shared Nationwide Interoperability activities. If an actor can establish that reporting criteria relating to access, exchange, and Roadmap at x–xi, https://www.healthit.gov/topic/ use of EHI for a broad and diverse range of interoperability/interoperability-roadmap (Oct. an exception applies to each practice for purposes). 2015) [hereinafter ‘‘Interoperability Roadmap’’]. which a claim of information blocking

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00093 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7516 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

has been made, including that the actor implicate the information blocking interfere with access, exchange, or use satisfied all applicable conditions of the provision. of EHI. We caution that these situations exception at all relevant times, then the Relatedly, to avoid potential are not exhaustive and that other practice would not constitute ambiguity and clearly communicate the circumstances may also give rise to a information blocking. full range of potential practices that very high likelihood of interference Based on early discussions with could implicate the information under the information blocking stakeholders during the development of blocking provision, we propose to provision. In each case, ONC will this proposed rule, we are aware that codify a definition of ‘‘interfere with’’ in consider the totality of the the generality with which the § 171.102, consistent with our circumstances in evaluating whether a information blocking provision interpretation set forth above. practice is likely to implicate the statute describes practices that are likely to b. Likelihood of Interference and to give rise to a violation. interfere with, prevent, or materially discourage access, exchange, or use of The information blocking provision is i. Observational Health Information EHI may leave some uncertainty as to preventative in nature. That is, the Although the information blocking the scope of the information blocking information blocking provision provision applies to all EHI, we believe provision and the types of practices that proscribes practices that are likely to that information blocking concerns are will implicate enforcement by ONC interfere with (including preventing or especially pronounced when the and/or OIG. To provide additional materially discouraging) access, conduct at issue has the potential to clarity on this point, we elaborate our exchange, or use of EHI—whether or not interfere with the access, exchange, or understanding of these important such harm actually materializes. By use of EHI that is created or maintained statutory concepts below. including both the likely and the actual during the practice of medicine or the effects of a practice, the information delivery of health care services to a. Prevention, Material Discouragement, blocking provision encourages patients. We refer to such information in and Other Interference individuals and entities to avoid this section of the preamble collectively The information blocking provision engaging in practices that undermine as ‘‘observational health information.’’ and its enforcement subsection do not interoperability, and to proactively Such information includes, but is not define the terms ‘‘interfere with,’’ promote access, exchange, and use of limited to, health information about a ‘‘prevent,’’ and ‘‘materially discourage,’’ EHI. patient that could be captured in a and use these terms collectively and We believe that a practice would patient record within an EHR and other without differentiation. Based on our satisfy the information blocking clinical information management interpretation of the information provision’s ‘‘likelihood’’ requirement if, systems; as well as information blocking provision and the ordinary under the circumstances, there is a maintained in administrative and other meanings of these terms in the context reasonably foreseeable risk that the IT systems when the information is of EHI, we do not believe they are practice will interfere with access, clinically relevant, directly supports mutually exclusive, but that prevention exchange, or use of EHI. For example, patient care, or facilitates the delivery of and material discouragement are best where an actor refuses to share EHI or health care services to consumers. We understood as types of interference, and to provide access to certain note that there is a special need for that use of these terms in the statute to interoperability elements, it is timely, electronic access to this define information blocking illustrates reasonably foreseeable that such actions information and that, moreover, the the desire to reach all practices that an will interfere with access, exchange, or clinical and operational utility of this actor knows, or should know, are likely use of EHI. As another example, it is information is often highly dependent to prevent, materially discourage, or reasonably foreseeable that a health care on multiple actors exercising varying otherwise interfere with the access, provider may need to access forms and degrees of control over the exchange, or use of EHI. Consistent with information recorded in a patient’s information itself or the technological, this understanding, in this preamble to electronic record that could be relevant contractual, or other means by which it the proposed rule, we use the terms to the treatment of that patient. For this can be accessed, exchanged, and used. ‘‘interfere with’’ and ‘‘interference’’ as reason, a policy or practice that limits Against these indications, practices that inclusive of prevention, material timely access to such information in an adversely impact the access, exchange, discouragement, and other forms of appropriate electronic format creates a or use of observational health interference that implicate the reasonably foreseeable likelihood of information will almost always information blocking provision. interfering with the use of the implicate the information blocking We believe that interference could information for these treatment provision. take many forms. In addition to the purposes. We note that observational health prevention or material discouragement Whether the risk of interference is information may be technically of access, exchange, or use, we propose reasonably foreseeable will depend on structured or unstructured (such as that interference could include practices the particular facts and circumstances ‘‘free text’’). Therefore, in general, that increase the cost, complexity, or attending the practice or practices at clinicians’ notes would constitute other burden associated with accessing, issue. Because of the number and observational health information, at exchanging, or using EHI. Additionally, diversity of potential practices, and the least insofar as the notes contain interference could include practices that fact that different practices will present observations or conclusions about a limit the utility, efficacy, or value of EHI varying risks of interfering with access, patient or the patient’s care. In contrast, that is accessed, exchanged, or used, exchange, or use of EHI, we do not we believe certain types of EHI are such as by diminishing the integrity, attempt to anticipate all of the potential qualitatively distinct from observational quality, completeness, or timeliness of ways in which the information blocking health information, such as EHI that is the data. We refer readers to section provision could be implicated. created through aggregation, algorithms, VIII.C.5.c of this preamble below for a Nevertheless, to assist with compliance, and other techniques that transform discussion of these and other potential we clarify certain circumstances in observational health information into practices that could interfere with which, based on our experience, a fundamentally new data or insights that access, exchange, or use and thereby practice will almost always be likely to are not obvious from the observational

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00094 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7517

information alone. This could include, • Providing patients with access to most EHI is currently stored in EHRs for example, population-level trends, their EHI and the ability to exchange and other source systems that use predictive analytics, risk scores, and and use it without special effort (see proprietary data models or formats. EHI used for comparisons and section VII.B.4). Knowledge of the data models, formats, benchmarking activities. Similarly, • Ensuring that health care or other relevant technical information internally developed quality measures professionals, care givers, and other (e.g., proprietary APIs) is necessary to and care protocols are generally distinct authorized persons have the EHI they understand the data and make efficient from observational health information. need, when and where they need it, to use of it in other applications and In general, we believe that practices that make treatment decisions and technologies. Because this information pertain solely to the creation or use of effectively coordinate and manage is routinely treated as confidential or these transformative data and insights patient care and can use the EHI they proprietary, the developer’s cooperation would not usually present the very high may receive from other sources. is required to enable uses of the EHI that likelihood of interference described • Ensuring that payers and other go beyond the capabilities provided by above. However, we emphasize that, entities that purchase health care the developer’s technology. This depending on the specific facts at issue, services can obtain the information they includes the capability to export practices related to electronic non- need to effectively assess clinical value complete information sets and to observational health information (a type and promote transparency concerning migrate data in the event that a user of EHI), such as price information, could the quality and costs of health care decides to switch to a different still be subject to the information services. technology. blocking provision. We seek comment • Ensuring that health care providers Separate from these contractual and on this proposed approach and can access, exchange, and use EHI for intellectual property issues, users may encourage commenters to identify quality improvement and population become ‘‘locked in’’ to a particular potential practices related to non- health management activities. technology, HIE, or HIN for financial or observational health information that • Supporting access, exchange, and business reasons. For example, many could raise information blocking use of EHI for patient safety and public health care providers have invested concerns. health purposes. significant resources to adopt EHR Finally, we clarify that merely The need to ensure that EHI is readily technologies—including costs for collecting, organizing, formatting, or available and usable for these purposes deployment, customization, data processing observational health is paramount. Therefore, practices that migration, and training—and have information maintained in EHRs and increase the cost, difficulty, or other tightly integrated these technologies other source systems does not change burden of accessing, exchanging, or into their information management the fundamental nature of that EHI or using EHI for these purposes would strategies, clinical workflows, and obligations under the information almost always implicate the information business operations. As a result, they blocking provisions. Likewise, the mere blocking provision. Individuals and may be reluctant to switch to other fact that EHI is stored in a proprietary entities that develop health IT or have technologies due to the significant cost format or has been combined with a role in making these technologies and and disruption this would entail. confidential or proprietary information services available should consider the Another important driver of does not alter the actor’s obligations impact of their actions and take steps to technological dependence is the under the information blocking support interoperability and avoid ‘‘network effects’’ of health IT adoption, provisions to facilitate access, exchange, impeding the availability or use of EHI. which are amplified by a reliance on technologies and approaches that are and use of the EHI in response to a iii. Control Over Essential not standardized and do not enable request. For example, the information Interoperability Elements; Other seamless interoperability. Consequently, blocking provision would be implicated Circumstances of Reliance or if an actor were to assert proprietary health care providers and other health Dependence rights in medical vocabularies or code IT users may gravitate towards and sets in a way that was likely to interfere An actor may have substantial control become reliant on the proprietary with the access, exchange, or use of over one or more interoperability technologies, HIEs, or HINs that have observational health information stored elements that provide the only been adopted by other individuals and in such formats. However, as noted in reasonable means of accessing, entities with whom they have the section VIII.D.6 of this preamble, under exchanging, or using EHI for a particular greatest need to exchange EHI. These the exception for licensing of purpose. In these circumstances, any effects may be especially pronounced interoperability elements on reasonable practice by the actor that could impede within particular product or geographic and non-discriminatory terms, an actor the use of the interoperability areas. For example, a HIN that facilitates could charge a royalty for access to elements—or that could unnecessarily certain types of exchange or transactions proprietary data or data coded in a increase the cost or other burden of may be so widely adopted that it is a de proprietary manner so long as that using the elements—would almost facto industry standard. A similar royalty were offered on reasonable and always implicate the information phenomenon may occur within a non-discriminatory terms pursuant to blocking provision. particular geographic area once a critical the conditions outlined in the The situation described above is most mass of hospitals, physicians, or other exception. likely when customers or users are providers adopt a particular EHR dependent on an actor’s technology or technology, HIE, or HIN. ii. Purposes for Which Information May services, which can occur for any In these and other analogous be Needed number of reasons. For example, circumstances of reliance or We believe the information blocking technological dependence may arise dependence, there is a heightened risk provision will almost always be from legal or commercial relations, such that an actor’s conduct will interfere implicated when a practice interferes as a health care provider’s reliance on with access, exchange, or use of EHI. To with access, exchange, or use of EHI for its EHR developer to ensure that EHI assist with compliance, we highlight the certain purposes, including but not managed on its behalf is accessible and following common scenarios, based on limited to: usable when it is needed. Relatedly, our outreach to stakeholders, in which

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00095 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7518 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

actors exercise control over key are illustrative only and do not provide proposed exception applies, and readers interoperability elements.109 an exhaustive list or comprehensive are encouraged to familiarize • Health IT developers of certified description of practices that may themselves with section VIII.D of this health IT that provide EHR systems or implicate the information blocking preamble. other technologies used to capture EHI provision and its penalties. We also • A health system’s internal policies at the point of care are in a unique reiterate that to implicate the provision or procedures require staff to obtain an position to control subsequent access to is not necessarily to violate it, and that individual’s written consent before and use of that information. each case will turn on its own unique sharing any of a patient’s EHI with • HINs and HIEs may be in a unique facts. For instance, a practice that unaffiliated providers for treatment position to control the flow of seemingly meets the statutory definition purposes even though obtaining an information among particular persons or of information blocking would not be individual’s consent is not required by for particular purposes, especially if the information blocking if it was required state or federal law. • HIN or HIE has achieved significant by law, if one or more elements of the An EHR developer’s software adoption in a particular geographic area definition were not met, or if it was license agreement prohibits a customer or for a particular type of health covered by one of the proposed from disclosing to its IT contractors information use case. exceptions for certain reasonable and certain technical interoperability • Similar control over EHI may be necessary activities detailed in section information without which the exercised by other entities, such as VIII.D of this preamble. For the customer and its IT contractors cannot health IT developers of certified health purposes of the following discussion, efficiently export and convert EHI for we do not consider the applicability of use in other applications. IT, that supply or control proprietary • technologies, platforms, or services that any exceptions proposed in section A HIN’s participation agreement are widely adopted by a class of users VIII.D of this preamble; we therefore prohibits entities that receive EHI or that are a ‘‘de facto standard’’ for strongly encourage readers to review through the HIN from transmitting that certain types of EHI exchanges or that section in conjunction with the EHI to entities who are not participants of the HIN. transactions. discussion of practices in this section • An EHR developer sues to prevent • Health care providers within health below. a clinical data registry from providing systems and other entities that provide i. Restrictions on Access, Exchange, or interfaces to physicians who use the health IT platforms, infrastructure, or Use developer’s EHR technology and wish to information sharing policies may have a The information blocking provision submit EHI to the registry. The EHR degree of control over interoperability or establishes penalties, including civil developer claims that the registry is the movement of data within a monetary penalties, or requires infringing the developer’s copyright in geographic area that is functionally appropriate disincentives, for practices its database because the interface equivalent to the control exercised by a that restrict access, exchange, or use of incorporates data mapping that dominant health IT developer, HIN, or EHI for permissible purposes. For references the table headings and rows HIE. example, section 3022(a)(2)(A) of the of the EHR database in which the EHI To avoid violating the information PHSA states that information blocking is stored. blocking provision, actors with control may include practices that restrict Access, exchange, or use of EHI can over interoperability elements should be authorized access, exchange, or use for also be restricted in less formal ways. careful not to engage in practices that treatment and other permitted purposes The information blocking provision exclude persons from the use of those under applicable law. Section would be implicated, for example, elements or create artificial costs or 3022(a)(2)(C)(i) of the PHSA states that where an actor simply refuses to other impediments to their use. information blocking may include exchange or to facilitate the access or We encourage comment on these and implementing health IT in ways that are use of EHI, either as a general practice other circumstances that may present an likely to restrict the access, exchange, or or in isolated instances. The refusal may especially high likelihood that a use of EHI with respect to exporting be expressly stated, or it may be implied practice will interfere with access, complete information sets or in from the actor’s conduct, as where the exchange, or use of EHI within the transitioning between health IT systems. actor ignores requests to share EHI or meaning of the information blocking One means by which actors may provide interoperability elements; gives provision. restrict access, exchange, or use of EHI implausible reasons for not doing so; or c. Examples of Practices Likely To is through formal restrictions. These insists on terms or conditions that are so Interfere With Access, Exchange, or Use may be expressed in contract or license objectively unreasonable that they of EHI terms, EHI sharing policies, amount to a refusal to provide access, organizational policies or procedures, or exchange, or use of the EHI. Some To further clarify the scope of the other instruments or documents that set examples of informal restrictions information blocking provision, below forth requirements related to EHI or include, but are not limited to: we describe several types of practices health IT. Additionally, in the absence • A health IT developer of certified that would be likely to interfere with of an express contractual restriction, an health IT refuses to license access, exchange, or use of EHI. These actor may achieve the same result by interoperability elements that are examples clarify and expand on those exercising intellectual property or other reasonably necessary for the developer’s set forth in section 3022(a)(2) of the rights in ways that restrict access, customers, their IT contractors, and PHSA. exchange, or use. As an illustration, the other health IT developers to develop Because information blocking can following non-exhaustive examples and deploy software that will work with take many forms, we emphasize that the illustrate types of formal restrictions the certified health IT. categories of practices described below that would likely implicate the • A health system incorrectly claims information blocking provision. As that the HIPAA Rules or other legal 109 As an important clarification, we note that requirements preclude it from control over interoperability elements may exist stated above, the examples throughout with or without the actor’s ability to manipulate the this section VIII.C.5.c. are presented exchanging EHI with unaffiliated price of the interoperability elements in the market. without consideration to whether a providers.

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00096 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7519

• An EHR developer ostensibly to each case and would need to consider third party, the developer’s customers allows third-party developers to deploy the applicability of an exception. (e.g., health care providers) choose not apps that are interoperable with its EHR We propose that the information to enable this capability. system. However, as a condition of blocking provision would be implicated • A health care provider has the doing so, the third-party developers if an actor were to deploy technological capability to provide same-day access to must provide their source code and measures that limit or restrict the ability EHI in a form and format requested by grant the EHR developer the right to use to reverse engineer the functional a patient or a patient’s health care it for its own purposes—terms that aspects of technology in order to provider, but takes several days to almost no developer would willingly develop means for extracting and using respond. accept. EHI maintained in the technology. This • A provider notifies its EHR may include, for example, employing iii. Impeding Innovations and developer of its intent to switch to technological protection measures that, Advancements in Access, Exchange, or another EHR system and requests a if circumvented, would trigger liability Use or Health IT-Enabled Care Delivery complete export of its EHI. The under the Digital Millennium Copyright The information blocking provision developer will provide only the EHI in Act (see 17 U.S.C. 1201) or other laws. encompasses practices that create a PDF format, even though it already The following hypothetical situations impediments to innovations and can and does produce the data in a illustrate some (though not all) of the advancements to the access, exchange, commercially reasonable structured types of practices described above and and use of EHI, including care delivery format. which would implicate the information enabled by health IT (section We emphasize that restrictions on blocking provision. • 3022(a)(2)(C)(ii) of the PHSA). access, exchange, or use that are A health system implements Importantly, the information blocking required by law would not implicate the locally-hosted EHR technology certified provision would be implicated and information blocking provision. to proposed § 170.315(g)(10) (the health penalties may apply if an actor were to Moreover, we recognize that some system acts as an API Data Provider as engage in exclusionary, discriminatory, restrictions, while not required by law, defined by § 170.102). As required by or other practices that impede the proposed § 170.404(b)(2), the technology may be reasonable and necessary for the development, dissemination, or use of developer provides the health system privacy and security of individuals’ EHI; interoperable technologies and services with the capability to automatically such practices may qualify for that enhance access, exchange, or use of publish its production endpoints (i.e., protection under the exceptions EHI. proposed in section VIII.D.2 and 3 of the internet servers that an app must Most acutely, the information this preamble. ‘‘call’’ and interact with in order to request and exchange patient data). The blocking provision would be implicated ii. Limiting or Restricting the health system chooses not to enable this if an actor were to refuse to license or Interoperability of Health IT capability, however, and provides the allow the disclosure of interoperability The information blocking provision production endpoint information only elements to persons who require those includes practices that restrict the to apps it specifically approves. This elements to develop and provide access, exchange, or use of EHI in prevents other applications—and interoperable technologies or services— various ways (see section 3022(a)(2) of patients that use them—from accessing including those that might complement the PHSA). These practices could data that should be made readily or compete with the actor’s own include, for example, disabling or accessible via standardized APIs. technology or services. The same would restricting the use of a capability that • A hospital directs its EHR be true if the actor were to allow access enables users to share EHI with users of developer to configure its technology so to interoperability elements but were to other systems or to provide access to that users cannot easily send electronic restrict their use for these purposes. The EHI to certain types of persons or for patient referrals and associated EHI to following examples, which are not certain purposes that are legally unaffiliated providers, even when the exhaustive, illustrate practices that permissible. In addition, the user knows the Direct address and/or would likely implicate the information information blocking provision would identity (i.e., National Provider blocking provision by interfering with be implicated where an actor configures Identifier) of the unaffiliated provider. access, exchange, or use of EHI: or otherwise implements technology in • An EHR developer that prevents • A health IT developer of certified ways that limit the types of data (such as by way of imposing exorbitant health IT refuses to license an API’s elements that can be exported or used fees unrelated to the developer’s costs, interoperability elements, to grant the from the technology. Other practices or by some technological means) a third- rights necessary to commercially that would be suspect include party clinical decision support (CDS) distribute applications that use the configuring capabilities in a way that app from writing EHI to the records API’s interoperability elements, or to removes important context, structure, or maintained by the EHR developer on provide the related services necessary to meaning from the EHI, or that makes the behalf of a health care provider (despite enable the use of such applications in data less accurate, complete, or usable the provider authorizing the third-party production environments. for important purposes for which it may app developer’s use of EHI) because the • An EHR developer of certified be needed. Likewise, implementing EHR developer: (1) Offers a competing health IT requires third-party capabilities in ways that create CDS software to the third-party app; and applications to be ‘‘vetted’’ for security unnecessary delays or response times, (2) includes functionality (e.g., APIs) in before use but does not promptly or that otherwise limit the timeliness of its health IT that would provide the conduct the vetting or conducts the EHI accessed or exchanged, would third party with the technical capability vetting in a discriminatory or interfere with the access, exchange, and to modify those records as desired by exclusionary manner. use of that information and would the health care provider. • A health IT developer of certified therefore implicate the information • Although an EHR developer’s health IT refuses to license blocking provision. We note that any patient portal offers the capability for interoperability elements that other conclusions regarding such interference patients to directly transmit or request software applications require to would be based on fact-finding specific for direct transmission of their EHI to a efficiently access, exchange, and use

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00097 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7520 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

EHI maintained in the developer’s that it will be providing such facilitate the exchange of EHI with users technology. capabilities free of charge in the next of competing technologies or services. Rather than restricting release of its product. In reality, the We clarify that not all instances of interoperability elements, an actor may capabilities it is developing are more differential treatment would necessarily insist on terms or conditions that are limited in scope and are still 12–18 constitute a discriminatory practice that burdensome and discourage their use. months from being production-ready. implicates the information blocking These practices would implicate the • A health system insists that local provision. For example, different fee information blocking provision for the physicians adopt its EHR platform, structures or other terms may reflect reasons described above. Consider the which provides limited connectivity genuine differences in the cost, quality, following non-exhaustive examples: with competing hospitals and facilities. or value of the EHI and the effort • An EHR developer of certified The health system threatens to revoke required to provide access, exchange, or health IT maintains an ‘‘app store’’ admitting privileges for physicians that use. We also note that, in certain through which other developers can do not comply. circumstances, it may be reasonable and have ‘‘apps’’ listed that run natively on Similar concerns would arise were an necessary for an actor to restrict or the EHR developer’s platform. However, actor to engage in discriminatory impose reasonable and non- if an app ‘‘competes’’ with the EHR practices—such as imposing discriminatory terms or conditions on developer’s apps or apps it plans to unnecessary and burdensome the use of interoperability elements, develop, the developer requires that the administrative, technical, contractual, or even though such practices could app developer grant the developer the other requirements on certain persons or implicate the information blocking right to use the app’s source code. classes of persons—that interfere with provision. For this reason, we propose • A health care provider engages a access and exchange or EHI by in section VIII.D.6 of this preamble to systems integrator to develop an frustrating or discouraging efforts to establish a narrow exception that would interface engine. However, the enable interoperability. The following apply to these types of practices. provider’s license agreement with its non-exhaustive examples illustrate EHR developer prohibits it from iv. Rent-Seeking and Other some ways this could occur: Opportunistic Pricing Practices disclosing technical documentation that • the systems integrator needs to perform An HIN charges additional fees, Certain practices that artificially the work. The EHR developer states that requires more stringent testing or increase the cost and expense associated it will only permit the systems certification requirements, or imposes with accessing, exchanging, and using integrator to access the documentation if additional terms for participants that are EHI will implicate the information all of its employees sign a broad non- competitors, are potential competitors, blocking provision. Such practices are compete agreement that would or may use EHI obtained via the HIN in plainly contrary to the information effectively bar them from working for a way that facilitates competition with blocking provision and the concerns the HIN. that motivated its enactment. any other health IT companies. • The information blocking provision A health care provider imposes one An actor may seek to extract profits or would be implicated also if an actor set of fees and terms to establish capture revenue streams that would be were to discourage efforts to develop or interfaces or data sharing arrangements unobtainable without control of a use interoperable technologies or with several registries and exchanges, technology or other interoperability services by exercising its influence over but offers another more costly or elements that are necessary to enable or customers, users, or other persons, as in significantly onerous set of terms to facilitate access, exchange, or use of the following non-exhaustive examples: establish substantially similar interfaces EHI. As discussed in section • An EHR developer of certified and arrangements with an HIE or HIN VIII.C.5.b.iii of this proposed rule, most health IT maintains an ‘‘app store’’ that is used primarily by health plans EHI is currently stored in EHRs and through which other developers can that purchase health care services from other source systems that use have ‘‘apps’’ listed that run natively on the provider at negotiated reduced rates. proprietary data models or formats; this the EHR developer’s platform. The EHR • A health IT developer of certified puts EHR developers (and other actors developer charges app developers a health IT charges customers fees, that control data models or standards) in substantial fee for this service unless an throttles speeds, or limits the number of a unique position to block access to app developer agrees not to deploy the records they can export when (including the export and portability of) app in any other EHR developers’ app exchanging EHI with a regional HIE that EHI for use in competing systems or stores. supports exchange among users of applications, or to charge rents for • A hospital is working with several competing health IT products, but does access to the basic technical information health IT developers to develop an not impose like fees or limitations when needed to accomplish the access, application that will enable ambulatory its customers exchange EHI with exchange, or use of EHI for these providers who use different EHR enterprise HIEs that primarily serve purposes. These information blocking systems to access and update patient users of the developer’s own concerns may be compounded to the data in the hospital’s EHR system from technology. extent that EHR developers do not within their ambulatory EHR • As a condition of disclosing disclose, in advance, the fees they will workflows. The inpatient EHR interoperability elements to third-party charge for interfaces, data export, data developer, being a health IT developer developers, an EHR developer requires portability, and other interoperability- of certified health IT, pressures the third-party developers to enter into related services (see 80 FR 62719; 80 FR hospital to abandon this project, stating business associate agreements with all 16880–81). We note that these concerns that if it does not it will no longer of the EHR developer’s covered entity are not limited to EHR developers. receive the latest updates and features customers, even if the work being done Other actors who exercise substantial for its inpatient EHR system. is not for the benefit of the covered control over EHI or essential • A health IT developer of certified entities. interoperability elements may engage in health IT discourages customers from • A health IT developer of certified analogous behaviors that would procuring data integration capabilities health IT takes significantly longer to implicate the information blocking from a third-party developer, claiming provide or update interfaces that provision.

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00098 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7521

To illustrate, we provide the not limited to these types of practices. a particular implementation approach following non-exhaustive examples, We interpret the definition of has been broadly adopted in a relevant which reflect some of the more common information blocking to encompass any industry segment, deviations from that types of rent-seeking and opportunistic fee that materially discourages or approach would be suspect unless behaviors of which we are aware and otherwise imposes a material strictly necessary to achieve substantial that are likely to interfere with access, impediment to access, exchange, or use efficiencies. exchange, or use of EHI: of EHI. We use the term ‘‘fee’’ in the To further illustrate these types of • An EHR developer of certified broadest possible sense to refer to any health IT charges customers a fee to present or future obligation to pay practices that would implicate the provide interfaces, connections, data money or provide any other thing of information blocking provision, we export, data conversion or migration, or value and propose to include this provide the following non-exhaustive other interoperability services, where definition in § 171.102. We believe this examples of conduct that would be the amount of the fee exceeds the actual scope may be broader than necessary to likely to interfere with access, exchange, costs that the developer reasonably address genuine information blocking or use of EHI: incurred to provide the services to the concerns and could unnecessarily • An EHR developer of certified particular customer(s). diminish investment and innovation in health IT implements the C–CDA for • An EHR developer of certified interoperable technologies and services. receiving transitions of care summaries health IT charges a fee to perform an Therefore, as discussed in section but only sends transitions of care export using the EHI export capability VIII.D.4 of this preamble, we propose to summaries in a proprietary or outmoded proposed in § 170.315(b)(10) for the create an exception that, subject to format. purposes of switching health IT systems certain conditions, would permit the • or to provide patients access to EHI. recovery of costs that are reasonably A health IT developer of certified • An EHR developer of certified incurred to provide access, exchange, health IT adheres to the ‘‘required’’ health IT charges more to export or use and use of EHI. We refer readers to that portions of a widely adopted industry EHI in certain situations or for certain section for additional details regarding standard but chooses to implement purposes, such as when a customer is this proposal. proprietary approaches for ‘‘optional’’ transitioning to a competing technology parts of the standard when other or attempting to export data for use with v. Non-Standard Implementation interoperable means are readily a HIE, third-party application, or other Practices available. technology or service that competes Section 3022(a)(2)(B) of the PHSA Even where no standards exist for a with the revenue opportunities states that information blocking may particular purpose, actors should not associated with the EHR developer’s include implementing health IT in non- design or implement health IT in non- own suite of products and services. standard ways that substantially standard ways that unnecessarily • An EHR developer of certified increase the complexity or burden of health IT interposes itself between a accessing, exchanging, or using EHI. In increase the costs, complexity, and customer and a third-party developer, general, this type of interference is other burden of accessing, exchanging, insisting that the developer pay a likely to occur when, despite the or using EHI. For example, an EHR licensing fee, royalty, or other payment availability of generally accepted developer of certified health IT designs in exchange for permission to access the technical, policy, or other approaches its database tables in a way that is EHR system or related documentation, that are suitable for achieving a unreasonably difficult to ‘‘map’’ to a where the fee is not reasonably particular implementation objective, an non-proprietary format, which is a necessary to cover any additional costs actor does not implement the standard, necessary prerequisite to converting the the EHR developer incurs from the does not implement updates to the EHI to a format that can be used in other third-party developer’s activities. standard, or implements the standard in software applications. When a customer • An analytics company provides a way that materially deviates from its requests the capability to export EHI to services to the customers of an EHR formal specifications. These practices a clinical data registry, the EHR developer of certified health IT, lead to unnecessary complexity and developer quotes substantial costs including de-identifying customer EHI burden, such as the additional cost and resulting from the need to write custom and combining it with other data to effort required to implement and code to enable this functionality. Based identify areas for quality improvement. maintain ‘‘point-to-point’’ connections, on these facts, the fees do not reflect The EHR developer insists on a revenue custom-built interfaces, and one-off costs that are reasonably incurred to sharing arrangement whereby it would trust agreements. provide the service and are instead the receive a percentage of the revenue While each case will necessarily result of the developer’s impractical generated from these activities in return depend on its individual facts, and design choices. We are aware that some for facilitating access to its customers’ while we recognize that the actors attribute certain non-standard EHI, which turns out to be development and adoption of standards implementations on legacy systems that across the health IT industry is an disadvantageous to customers. The the actor did not themselves design but ongoing process, we propose that the revenue the EHR developer would which have to be integrated into the information blocking provision would receive exceeds its reasonable costs of actor’s health IT. Such instances will be be implicated in at least two distinct facilitating the access to EHI. considered on a case by case basis. The information blocking provision sets of circumstances. First, information would clearly be implicated by these blocking may arise where an actor Again, we reiterate that information and other practices by which an actor chooses not to adopt, or to materially blocking can take many forms and that profits from its unreasonable control deviate from, relevant standards, the practices (and categories of over EHI or interoperability elements implementation specifications, and practices) described above do not without adding any efficiency to the certification criteria adopted by the provide an exhaustive list or health care system or serving any other Secretary under section 3004 of the comprehensive description of practices procompetitive purpose. But the reach PHSA. Second, even where no federally that may implicate the information of the information blocking provision is adopted or identified standard exists, if blocking provision.

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00099 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7522 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

6. Applicability of Exceptions implementation of the security policy is blocking but that are reasonable and a. Reasonable and Necessary Activities reasonable and necessary under the necessary to further the underlying circumstances, such conduct would be public policies of the information As discussed above, section 3022(a)(3) considered a ‘‘practice’’ that implicates blocking provision. authorizes the Secretary to identify, the information blocking provision. The seven proposed exceptions are through notice and comment However, it may later be determined based on three related policy rulemaking, reasonable and necessary that such conduct is reasonable and considerations. First, each exception is activities that do not constitute necessary and would then be considered limited to certain activities that clearly information blocking for purposes of the an ‘‘activity.’’ Due to these types of advance the aims of the information definition set forth in section 3022(a)(1). scenarios, we contend that the better blocking provision. These reasonable Separately, the Cures Act identifies at approach is to use one term—practice— and necessary activities include section 3022(a)(1) practices that throughout the proposed rule and providing appropriate protections to contravene the definition of information clarify when describing the conduct at prevent harm to patients and others; blocking. Following this Cures Act issue whether it is a practice that is promoting the privacy and security of terminology, conduct that implicates the information blocking, a practice that EHI; promoting competition and information blocking provision and that implicates the information blocking innovation in health IT and its use to does not fall within one of the provision, or a practice that is provide health care services to exceptions described in section VIII.D of reasonable and necessary and not consumers, and to develop more this preamble, or does not meet all information blocking. efficient means of health care delivery; conditions for an exception, would be and allowing system downtime in order considered a ‘‘practice.’’ Conduct that b. Treatment of Different Types of to implement upgrades, repairs, and falls within an exception and meets all Actors other changes to health IT. Second, each the applicable conditions for that The proposed exceptions would apply exception addresses a significant risk exception would be considered an to health care providers, health IT that regulated actors will not engage in ‘‘activity.’’ The challenge with this developers of certified health IT, HIEs, these beneficial activities because of distinction is that when examining and HINs who engage in certain uncertainty concerning the breadth or conduct that is the subject of an practices covered by an exception, applicability of the information blocking information blocking claim— an actor’s provided that all applicable conditions provision. Finally, each exception is actions that likely interfered with of the exception are satisfied at all subject to strict conditions to ensure access, exchange, or use of EHI—it can relevant times and for each practice for that it is limited to activities that are be illusory to distinguish, on its face, which the exception is sought. The reasonable and necessary. conduct that is a practice and conduct exceptions are generally applicable to The first three exceptions, set forth in that is an activity. Indeed, conduct that all actors. However, in some instances VIII.D.1–D.3, extend to certain activities implicates the information blocking we propose conditions within an that are reasonable and necessary to provision but falls within an exception exception that apply to a particular type prevent harm to patients and others; could nonetheless be considered of actor. promote the privacy of EHI; and information blocking in the event that promote the security of EHI, subject to the actor has not satisfied the conditions c. Establishing That Activities and strict conditions to prevent the applicable to that exception. Practices Meet the Conditions of an exceptions from being misused. We While we acknowledge the Exception believe that without these exceptions, terminology used in the Cures Act, we We propose that, in the event of an actors may be reluctant to engage in the propose to use the term ‘‘practice’’ investigation of an information blocking types of reasonable and necessary throughout this proposed rule when we complaint, an actor must demonstrate activities described below, and that this describe conduct that is likely to that an exception is applicable and that could erode trust in the health IT interfere with, prevent, or materially the actor met all relevant conditions of ecosystem and undermine efforts to discourage access, exchange, or use of the exception at all relevant times and provide access and facilitate the electronic health information, regardless for each practice for which the exchange and use of EHI for important of whether that conduct meets the exception is sought. We consider this purposes. Such a result would be conditions for an exception to the allocation of proof to be a substantive contrary to the purpose of the information blocking provision. condition of the proposed exceptions. information blocking provision and the Consistent with this approach, when As a practical matter, we propose that broader policies of the Cures Act. identifying reasonable and necessary actors are in the best position to The next three exceptions, set forth in activities in §§ 171.200 through 171.206, demonstrate compliance with the VIII.D.4–D.6, address activities that are we describe practices that, if all the conditions of the proposed exceptions reasonable and necessary to promote applicable conditions are met, are and to produce the detailed evidence competition and consumer welfare. reasonable and necessary and not necessary to demonstrate that First, we propose to permit the recovery information blocking. We have taken compliance. We request comment about of certain types of reasonable costs this approach, in part, because we the types of documentation and/or incurred to provide technology and believe that to adopt the terminology of standardized methods that an actor may services that enable access to EHI and activity to describe conduct that may or use to demonstrate compliance with the facilitate the exchange and use of that may not be information blocking would exception conditions. information, provided certain confuse the reader and obfuscate our conditions are met. Second, we propose intent in certain circumstances. As an D. Proposed Exceptions to the to permit an actor to decline to provide illustration, a health care provider may Information Blocking Provision access, exchange, or use of EHI in a implement an organizational security We propose to establish seven manner that is infeasible, subject to a policy that limits access, exchange, or exceptions to the information blocking duty to provide a reasonable alternative. use of certain information to certain provision. The exceptions would apply And, third, we propose an exception users (e.g., role-based access). Prior to to certain activities that may technically that would permit an actor to license determining whether the meet the definition of information interoperability elements on reasonable

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00100 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7523

and non-discriminatory terms. These benefits.113 The technological taken by HHS under the information exceptions would be subject to strict dependence resulting from these blocking provision would be conditions to ensure that they do not practices can be a barrier to entry by independent from the antitrust laws and extend protection to practices that raise would-be competitors. It can also make would not prevent FTC or DOJ from information blocking concerns. independent providers vulnerable to taking action with regard to the same The last exception, set forth in acquisition or induce them into actor or conduct. VIII.D.7, recognizes that it may be exclusive arrangements that enhance the We request comment on the following reasonable and necessary for actors to market power of incumbent providers, seven proposed exceptions, including make health IT temporarily unavailable while preventing the formation of whether they will achieve our stated for the benefit of the overall clinically-integrated products and policy goals. performance of health IT. This networks that offer more choice and 1. Preventing Harm exception would permit an actor to better value to consumers and make the operation of health IT purchasers of health care services. We propose to establish an exception unavailable in order to implement Section 3022(a)(5) of the PHSA to the information blocking provision upgrades, repairs, and other changes. provides that the Secretary may consult for practices that are reasonable and As context for the exceptions with the Federal Trade Commission necessary to prevent harm to a patient proposed below in VIII.D.4–D.6, we note (FTC) in defining practices that do not or another person, provided certain that addressing information blocking is constitute information blocking because conditions are met. The exception and critical for promoting competition and they are necessary to promote corresponding conditions are set forth innovation in health IT and for the competition and consumer welfare. We in the proposed regulation text in delivery of health care services to appreciate the expertise and informal § 171.201. consumers. Indeed, the information technical assistance of FTC staff, which This proposed exception would blocking provision itself expressly we have taken into consideration in acknowledge the public interest in addresses practices that impede developing the exceptions described in protecting patients and other persons innovations and advancements in health VIII.D.4–D.6 of this preamble. We note against unreasonable risks of harm that, information access, exchange, and use, that the language in the Cures Act in certain narrowly defined including care delivery enabled by regarding information blocking is circumstances described below, justify health IT (section 3022(a)(2)(C)(ii) of the substantively and substantially different practices that are likely to interfere with PHSA). As discussed in section from the language and goals in the access, exchange, or use of EHI and that VIII.C.5.b.iii of this preamble, health IT antitrust laws enforced by the FTC. We would implicate the information developers of certified health IT, HIEs, view the Cures Act as authorizing ONC blocking provision in the absence of an HINs, and, in some instances, health and OIG to regulate conduct that may be exception. care providers may exploit their control considered permissible under the The exception would be subject to over interoperability elements to create antitrust laws. On this basis, this strict conditions, which we believe are barriers to entry for competing proposed rule requires that actors who necessary to prevent patient safety from technologies and services that offer control interoperability elements being used as a pretext for information greater value for health IT customers cooperate with individuals and entities blocking or as a post hoc rationalization and users, provide new or improved that require those elements for the for practices that are not reasonable and capabilities, and enable more robust purpose of developing, disseminating, necessary to address material risks of access, exchange, and use of EHI.110 and enabling technologies and services harm to a patient or another person. More than this, information blocking that can interoperate with the actor’s We have adopted the terminology of may harm competition not just in health technology. ‘‘patient’’ to denote the context in which IT markets, but also in markets for We emphasize that ONC is taking this the threat of harm arises. That is, this health care services.111 Dominant approach because we view patients as proposed exception has been designed providers in these markets may leverage having an overwhelming interest in EHI to recognize certain practices taken for their control over technology to limit about themselves, and particularly the benefit of recipients of health care— patient mobility and choice.112 They observational health information (see those individuals whose EHI is at may also pressure independent the discussion in section VIII.C.4.b of issue—and other persons whose providers to adopt expensive, hospital- this preamble). As such, access to EHI, information may be recorded in that EHI centric technologies that do not suit and the EHI itself, should not be traded or who may be at risk of harm because their workflows, limit their ability to or sold by those actors who are of the access, use, or exchange of EHI. share information with unaffiliated custodians of EHI or who control its The use of the term ‘‘patient’’ does not providers, and make it difficult to adopt access, exchange, or use. We emphasize require, other than in the context of the or use alternative technologies that that such actors should not be able to risk of harm determined by a licensed could offer greater efficiency and other charge fees for providing electronic health care professional (see access, exchange, or use of patients’ § 171.201(a)(3)), that an actor seeking to 110 See also Martin Gaynor, Farzad Mostashari, EHI. We propose that actors should be benefit from this exception needs to and Paul B. Ginsberg, Making Health Care Markets required to share EHI unless they are have a clinician-patient relationship Work: Competition Policy for Health Care, 16–17 with the individual (or individuals) at (Apr. 2017), available at http://heinz.cmu.edu/ prohibited from doing so under an news/news-detail/index.aspx?nid=3930. existing law or are covered by one of the risk of harm. Indeed, a health IT 111 See, e.g., Keynote Address of FTC exceptions detailed in this preamble. In developer of certified health IT would Chairwoman Edith Ramirez, Antitrust in Healthcare addition, any remedy sought or action be able to benefit from this exception in Conference Arlington, VA (May 12, 2016), available connection with practices undertaken at https://www.ftc.gov/system/files/documents/ public_statements/950143/160519antitrust 113 See, e.g., Healthcare Research Firm Toughens for the benefit of individuals receiving healthcarekeynote.pdf. Survey Standards as More CIOs Reap the Profits of (or having received, or expected to 112 See, e.g., Martin Gaynor, Farzad Mostashari, Reselling Vendor Software, Black Book, available at receive) care from a health care provider and Paul B. Ginsberg, Making Health Care Markets http://www.prweb.com/releases/2015/02/ that uses the developer’s health IT. Work: Competition Policy for Health Care, 16–17 prweb12530856.htm; Arthur Allen, Connecticut (Apr. 2017), available at http://heinz.cmu.edu/ Law Bans EHR-linked Information Blocking, Similarly, an HIE or HIN that exchanges news/news-detail/index.aspx?nid=3930. Politico.com (Oct. 29, 2015). or facilitates the exchange of EHI would

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00101 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7524 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

be able to benefit from this exception in linked to a patient when the patient’s quality and integrity and support health connection with the activities carried record is exchanged. However, this IT applications properly identifying and out by the HIE or HIN for or at the recognized risk does not extend to matching patient records or EHI. direction of a health care provider. purported accuracy issues arising from Accurately identifying patients and the incompleteness of a patient’s correctly attributing their EHI to them is Patient Harm Risks That Would Be a complex task and involves layers of Cognizable Under This Exception electronic health record generally. Electronic health records, like the paper safeguards, including verification of a Consistent with the definition of charts they replaced, are inevitably patient’s identity, proper registration in information blocking, we have imperfect records. Many patients see health IT systems, physical identified certain risks to patient harm multiple health care providers and so it identification such as wristbands, and that arise in the context of access, is unlikely that any single health care usability and implementation decisions exchange, or use of EHI. To qualify for provider’s record will provide a such as ensuring the display of a this proposed exception, an actor’s complete picture of a patient’s health. patient’s name and date of birth on practice must respond to a risk that is Some patients intentionally keep certain every screen of the patient’s electronic cognizable under this exception. information secret even from their chart. When a clinician or other health Risk of Corrupt or Inaccurate Data Being health care providers, and others fail to IT user may know or reasonably suspect Recorded or Incorporated in a Patient’s share potentially critical information that specific EHI in a patient’s record is Electronic Health Record with their health care providers because or may be misattributed, either within a they forget to, or simply do not local record or as received through EHI The exception may apply to practices understand its clinical significance. exchange, it would be reasonable for that prevent harm arising from them to avoid sharing or incorporating corrupted or inaccurate EHI being While the access, exchange, or use of the EHI that they know would, or recorded or incorporated in a patient’s EHI in these situations could give rise reasonably suspect could, propagate electronic health record. Users of health to the risk of harm if the EHI was relied errors in the patient’s records and thus IT systems strive to maintain accurate on without qualification, such reliance pose the attendant risks to the patient. electronic health records by carefully does not accord with our understanding As discussed below, an actor’s response inputting EHI and verifying existing of clinical practice, as the risk of to this risk would need to be no broader EHI. Occasionally a clinician or other incompleteness resulting from patients than necessary to mitigate the risk of user of health IT is presented with EHI having multiple providers, or from harm arising from the potentially that, due to a failure of the technology, errors of omission by patients and their misidentified record or misattributed is either entirely incorrect or contains care providers, is not unique to data. A health IT developer of certified inaccurate information. At other times, electronic health records or their health IT could not, for example, refuse EHI could become corrupted. In these interoperable exchange. Therefore, the to provide a batch export on the basis cases, the sharing or integration of such risk that the EHI a given health care that the exported records may contain a EHI could lead to inaccuracies in the provider holds for a given patient may misidentified record. Similarly, a health patient’s electronic health record that not be a perfectly complete record of care provider that identified that a then run the risk of being propagated that patient’s health or care will not be particular piece of information had been further. We note, however, that known recognized as being sufficient to support misattributed to a patient would not be inaccuracies in some data within a an actor qualifying for this exception in excused from exchanging or providing record may not be sufficient justification the face of a claim of information access to all other EHI about the patient to withhold the entire record if the blocking. that had not been misattributed. remainder of the patient’s EHI could be We also acknowledge that certain effectively shared without also federal and state laws, such as 42 CFR Determination by a Licensed Health presenting the known incorrect or part 2 and state medical record laws, Care Professional That the Disclosure of corrupted information as if it were require an actor to obtain an EHI Is Reasonably Likely To Endanger trustworthy. Also, we would expect that individual’s written consent before Life or Physical Safety once information is known to be sharing health information. However, The exception may permit certain inaccurate or corrupted, a health care we propose that an actor would not be restrictions on the disclosure of an provider holding that record would, for able to benefit from this exception on individual’s EHI in circumstances example, take action to cure the the basis of a perceived risk arising from where a licensed health care inaccuracy or corruption. We exchanging or providing access to EHI professional has determined, in the understand that in the ordinary course when the EHI exchanged or made exercise of professional judgment, that of practice, and consistent with accessible does not include certain the disclosure is reasonably likely to professional and legal standards for information due to a patient’s decision endanger the life or physical safety of clinical record keeping, health care not to consent to its disclosure. For the patient or another person. This providers take appropriate action to example, this exception would not would include the situation where a remediate known problems with EHI recognize an actor’s conduct in not covered entity elected not to treat a and restore a record as a whole to be providing access, exchange, or use of a person as the personal representative of safely usable, and therefore safely patient’s electronic health record on the an individual in situations of potential sharable. basis that the patient’s failure to consent abuse or endangerment, including in This recognized risk is limited to to the disclosure of substance abuse accordance with 45 CFR 164.502(g)(5). corruption and inaccuracies caused by treatment information made the In certain cases, the clinician may have performance and technical issues patient’s record incomplete and thus individualized knowledge stemming affecting health IT. For example, this inaccurate. from the clinician-patient relationship exception may be relevant if certified that, for a particular patient and for that health IT were to incorrectly present an Risk of Misidentifying a Patient or patient’s circumstances, harm could old and superseded version of a Patient’s Electronic Health Information result if certain EHI were shared or medication list, or when only partial The exception may apply to practices transmitted electronically. Consistent copies of laboratory tests are being that are designed to promote data with the HIPAA Privacy Rule, a

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00102 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7525

decision not to provide access, by hospital administrators without clinical or production environments of exchange, or use of EHI on this basis meaningful input from the medical staff, health IT. In these circumstances, in would be subject to any right that an IT department, and front-line clinicians lieu of demonstrating that a practice affected individual is afforded under who would implement, and thus be conformed to the actor’s policies and applicable federal or state laws to have affected by, the policy and are in the that the policies met the conditions the determination reviewed and best position to gauge how effective it described above, the actor could justify potentially reversed. will be at mitigating patient safety risks. the practice or practices directly by We request comment on whether the Third, we propose that the policy making a finding in each case, based on categories of harm described above must have been implemented in a the particularized facts and capture the full range of safety risks that consistent and non-discriminatory circumstances, that the practice is might arise directly from accessing, manner. As part of this condition, the necessary and no broader than exchanging, or using EHI. We also actor must have taken reasonable steps necessary to mitigate the risk of harm. request comment on whether we should to educate its directors, officers, To do so, we propose that the actor consider other types of patient safety employees, contractors, and authorized would need to show that the practices risks related to data quality and integrity personnel on how to apply the policy were approved on a case-by-case basis concerns, or that may have a less and to provide appropriate oversight to by an individual with direct knowledge proximate connection to EHI but that ensure that the policy is not applied in of the relevant facts and circumstances could provide a reasonable and an arbitrary, discriminatory, or and who had relevant clinical, necessary basis for an actor to restrict or otherwise inappropriate manner. This technical, or other appropriate otherwise impede access, exchange, or condition would not be met if, for expertise. Such an individual would use of EHI in appropriate circumstances. example, a policy or practice were based need to reasonably conclude, on the We ask that commenters provide on factors that lacked a direct and basis of those particularized facts and detailed rationale for any suggested substantial correlation with the circumstances and his/her expertise and revisions to these categories, including particular risk of harm at issue. best professional judgment, that the additional conditions that may be Last, we propose that the policy must practice was necessary, and no broader necessary to ensure that the exception is have been be no broader than necessary than necessary, to mitigate the risk of tailored and does not extend protection for the specific risk or type of risk at harm to a patient or other persons. to practices that are not reasonable and issue. For example, as evidence that the We propose that a licensed health necessary to promote patient safety and policy is no broader than necessary, the care professional’s independent and that could present information blocking policy would need to identify the individualized judgment about the concerns. relevant risks and follow an approach to safety of the actor’s patients or other mitigating those risks that is based on persons would be entitled to substantial Reasonable Belief That Practice Was current patient safety evidence and best deference under this proposed Necessary to Directly and Substantially practices, supplemented by input from exception. So long as the clinician Reduce the Likelihood of Harm clinical, technical, and other staff or actually considered all of the relevant To qualify for this exception, an actor others who are in the best position to facts and determined that, under the must have had a reasonable belief that make judgments about the policy’s particular circumstances, the practice the practice or practices will directly effectiveness, as discussed above. was necessary to protect the safety of and substantially reduce the likelihood Further evidence that the policy was no the clinician’s patient or other person, of harm to a patient or another person. broader than necessary would be we would not second-guess the As discussed above, the type of risk whether the actor considered alternative clinician’s judgment. To provide further must also be cognizable under this approaches and reasonably concluded clarity on this point, we provide the exception. that, under the circumstances, those following illustration. An actor could meet this condition in approaches were either inadequate to A clinician suspects that a patient is two ways. address the identified risks of harm or at risk of domestic abuse. The patient would not have reduced the likelihood has recently visited the clinic for a Qualifying Organizational Policy of interference with access, exchange, or pregnancy test, and tells the clinician In most cases, we anticipate that the use of EHI. For example, a tailored that the potential father is not her actor would demonstrate that the response to the existence of corrupted current partner. The test returns a practices it engaged in were consistent data would necessarily permit all positive result. The clinician notes that with an organizational policy that was uncorrupted EHI to continue to be in the patient’s electronic health record, objectively reasonable and no broader accessed, used, and exchanged. This her partner has been given access to than necessary for the type of patient condition would not be met, for view her test results. The clinician, safety risks at issue. In these example, if an actor’s policy imposed a considering all factors for this particular circumstances, we propose that an blanket ban on the sharing of EHI with situation and particular patient, and actor’s policy would need to satisfy the users of different technologies or with aware of the clinic’s policy towards the following requirements. health care providers who are not part restriction of electronic health First, we propose that the policy must of a particular health system, HIE, or information sharing, concludes that be in writing. HIN. releasing this result electronically could Second, it must have been developed place the patient at risk of harm. The with meaningful input from clinical, Qualifying Individualized Finding clinician thus chooses not to release the technical, and other appropriate staff or We recognize that some health care test result electronically and plans to others who have expertise or insight providers (such as small practices) may deliver the result to the patient in a safe relevant to the risk of harm that the not have comprehensive and formal manner. The exception would apply in policy addresses. This condition would policies governing all aspects of EHI and this case because the clinician not be met if, for example, a hospital patient safety. Additionally, even if an reasonably believes, based on the imposed top-down information sharing organizational policy exists, it may not relationship with this particular patient policies or workflows established by the anticipate all of the potential risks of and the clinician’s best clinical hospital’s EHR developer and approved harm that could arise in real-world judgment, that the restriction is

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00103 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7526 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

necessary to prevent harm to the exception. The sub-exceptions have, to that the term ‘‘use’’ has the meaning patient. a large extent, been crafted to closely defined in 45 CFR 160.103. Similarly, We seek public comment on whether mirror privacy-protective practices that we refer in a few cases to an this proposed exception is appropriate are recognized under state and federal individual’s right of access under 45 and adequately balances the interest of privacy laws. In this way, the privacy CFR 164.524, in which case the term promoting access, exchange, and use of sub-exceptions to the information ‘‘access’’ should be understood in that EHI with legitimate concerns about the blocking provision would recognize as HIPAA Privacy Rule context. For risk of harm to patients and others. In reasonable and necessary practices that purposes of section 3022 of the PHSA, addition to any other relevant issues, we are engaged in by actors consistent with however, the term ‘‘access’’ includes, specifically request feedback on privacy laws, provided that certain but is broader than, an individual’s whether the exception is broad enough conditions are met. We have proposed access to their PHI as provided for by to prevent harm to patients and others four sub-exceptions that address the the HIPAA Privacy Rule (see section and, if not, what additional risks we following privacy protective practices: VIII.C.4.a of this preamble). should address should we finalize this (1) Not providing access, exchange, or Finally, the term ‘‘individual’’ is proposal; and whether there are use of EHI when a state or federal law defined by the HIPAA Rules at 45 CFR additional safeguards the Secretary requires that a condition be satisfied 160.103. Separately, under the should adopt in order to prevent before an actor provides access, information blocking enforcement practices that attempt to undermine the exchange, or use of EHI, and the provision, the term ‘‘individual’’ is used policy goal of the exception. We also condition is not satisfied (proposed in to refer to actors that are health IT seek comment on whether there are § 171.202(b)); (2) not providing access, developers of certified health IT, HINs, customary practices (e.g., standards of exchange, or use of EHI when the actor or HIEs, (see section 3022(b)(2)(A) of the care) that advance patient safety is a health IT developer of certified PHSA). For purposes of this exception concerns but which actors do not, as a health IT that is not covered by the (and only this exception), we use matter of practice, record in HIPAA Privacy Rule in respect to a neither of these definitions. Instead, the documented policies, and which should practice (proposed in § 171.202(c)); (3) a term ‘‘individual’’ encompasses any or be taken into account when assessing covered entity, or a business associate all of the following: (1) An individual the reasonableness of a practice under on behalf of a covered entity, denying defined by 45 CFR 160.103; (2) a person this exception. an individual’s request for access to who is the subject of EHI that is being accessed, exchanged or used; (3) a 2. Promoting the Privacy of EHI their electronic PHI in the circumstances provided in 45 CFR person who legally acts on behalf of an We propose to establish an exception 164.524(a)(1), (2), or (3) (proposed at individual or person described in (1) or to the information blocking provision § 171.202(d)); and (4) not providing (2), including as a personal for practices that are reasonable and access, exchange, or use of EHI pursuant representative, in accordance with 45 necessary to protect the privacy of an to an individual’s request, in certain CFR 164.502(g); or (4) a legal individual’s EHI, provided certain situations (proposed in § 171.202(e)). representative authorized to make conditions are met. The exception and The rationale for each sub-exception is health care decisions on behalf of a corresponding conditions are set forth described in detail below. person or an executor or administrator in the proposed regulation text in An actor would need to satisfy at least who can act on behalf of the deceased’s § 171.202. We note that any practice one sub-exception in order that a estate under state or other law. engaged in to protect the privacy of an purportedly privacy-protective practice We clarify that (2) varies from (1) individual’s EHI must be consistent that interferes with access, exchange, or because there could be individuals who with applicable laws related to health use of EHI not be subject to the could be the subject of EHI that is being information privacy, including the information blocking provision. Each accessed, exchanged, or used under (2), HIPAA Privacy Rule as applicable, as sub-exception has conditions that must but who would not be the subject of PHI well as with other applicable laws and be met in order that an actor’s practice under (1). The purpose of (2) is to regulations, such as the HITECH Act, 42 qualifies for protection under the sub- include EHI that would be accessed, CFR part 2, and state laws. This exception. exchanged or used by entities that are exception to the information blocking not subject to HIPAA (e.g., non-covered provision does not alter an actor’s Specific Terminology Used for the entities and non-business associates). obligation to comply with these and Purposes of This Proposed Exception These entities could include, for other applicable laws. We note that this proposed exception example, health IT developers or data We believe this exception is necessary and our discussion below uses certain analytics companies that have access to to support basic trust and confidence in terms that are defined by the HIPAA EHI, but are not business associates. health IT infrastructure. Without this Rules 114 but that, for purposes of this We also clarify that (3) encompasses exception, there would be a significant exception, may have a broader meaning a person with legal authority to act on risk that actors would share EHI in in the context of the information behalf of the individual, which includes inappropriate circumstances, such as blocking provision and its a person who is a personal when an individual has taken implementing regulations as set forth in representative as defined under the affirmative steps to request that the EHI this Proposed Rule. In general, the terms HIPAA Privacy Rule. We included the not be shared, or when an actor has ‘‘access,’’ ‘‘exchange,’’ and ‘‘use’’ have component of legal authority to act in been unable to obtain reasonable the meaning explained in section (3) because the HIPAA Privacy Rule assurances as to an individual’s VIII.C.4.a of this preamble. However, in gives rights to parents or legal guardians identity. some instances we refer to ‘‘use’’ in the in certain circumstances where they are In contrast to the other exceptions context of a disclosure or use of ePHI not the ‘‘personal representative’’ for defined in this proposed rule, this under the HIPAA Privacy Rule, in their child(ren). For instance, a non- proposed exception has been structured which case we have explicitly stated custodial parent who has requested a with discrete ‘‘sub-exceptions.’’ An minor child’s medical records under a actor’s practice must qualify for a sub- 114 45 CFR part 160 and subparts A, C, and E of court-ordered divorce decree may have exception in order to be covered by this part 164. legal authority to act on behalf of the

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00104 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7527

child even if he or she is not the child’s ePHI in most circumstances. The not be able to rely on an individual’s ‘‘personal representative.’’ Further, in information blocking provision, on the expressed privacy preference in limited circumstances and if permitted other hand, requires that an actor circumstances where the access, under state law, a family member may provide access to, exchange, or use of exchange, or use is required by law. have legal authority to act on behalf of EHI unless they are prohibited from For these reasons, we propose that the a patient to make health care decisions doing so under an existing law or are proposed sub-exception in § 171.202(e) in emergency situations even if that covered by one of the exceptions would generally permit an actor to give family member may not be the ‘‘legal detailed in this preamble. To illustrate, effect to individuals’ expressed privacy representative’’ or ‘‘personal the HIPAA Privacy Rule permits health preferences, including their desire not representative’’ of the patient. care providers to exchange ePHI for to permit access, exchange, or use of We have adopted this specialized treatment purposes, but does not require their EHI. For example, provided that usage to ensure that this privacy them to do so. Under the information corresponding conditions have been exception extends protection to blocking provision, unless an exception met, a health care provider could honor information about, and respects the to information blocking applies, or the a patient’s request not to share their EHI privacy preferences of, all individuals, interference is required by law, a in circumstances in which the HIPAA not only those individuals whose EHI is primary care provider would be Privacy Rule would permit (though not protected as ePHI by HIPAA covered required to exchange ePHI with a require) the provider to disclose the entities and business associates. specialist who requests it to treat an information, such as for treatment purposes. At the same time, however, Interaction Between Information individual who was a common patient we believe that the privacy exception Blocking, the Exception for Promoting of the provider and the specialist, even must be tailored to ensure that the Privacy of EHI, and the HIPAA if the primary care provider offered protection of an individual’s privacy is Privacy Rule patient care services in competition with the specialist’s practice, or would not used as a pretext for information Having consulted extensively with the usually refer its patients to another blocking. Accordingly, we propose that HHS Office for Civil Rights (OCR), who specialist due to an existing business this exception, which is discussed more enforce the HIPAA Privacy, Security relationship. fully below, would be subject to strict and Breach Notification Rules, we have conditions. developed the information blocking Promoting Patient Privacy Rights provision to advance our shared goals of As discussed above, the information Privacy Practices Required by Law preventing information blocking for blocking provision would not require Because the information blocking nefarious or self-interested purposes that actors provide access, exchange, or provision excludes from the definition while maintaining and upholding use of EHI in a manner that is not of information blocking practices that existing privacy rights and protections permitted under the HIPAA Privacy are required by law (section 3022(a)(1) for individuals. The proposed exception Rule or other privacy laws. As such, the of the PHSA), privacy-protective for promoting the privacy of EHI (also privacy-protective controls existing practices that are required by law do not referred to as ‘‘the privacy exception’’) under HIPAA would not be weakened implicate the information blocking operates in a manner consistent with the by the information blocking provision. provision and do not require coverage framework of the HIPAA Privacy Rule. Moreover, we have structured the from an exception. For example, the We designed these exceptions to ensure privacy exception to ensure that actors HIPAA Privacy Rule requires that a that individual privacy rights are not can engage in reasonable and necessary covered entity must agree to the request diminished as a consequence of the practices that advance the privacy of an individual to restrict disclosure of information blocking provision, and to interests of individuals. protected health information (PHI) ensure that the information blocking For example, we believe that, unless about the individual to a health plan if provision does not require the use or required by law, actors should not be the disclosure is for the purpose of disclosure of EHI in a way that would compelled to share EHI against patients’ carrying out payment or health care not be permitted under the HIPAA wishes or without adequate safeguards operations and not otherwise required Privacy Rule. Our intent is that the out of a concern that restricting the by law and the PHI pertains solely to a information blocking provision does not access, exchange, or use of the EHI health care item or service for which the conflict with the HIPAA Privacy Rule. would constitute information blocking. individual, or person other than the Indeed, the sub-exception proposed in This could seriously undermine health plan on behalf of the individual, § 171.202(d) reflects a policy judgment patients’ trust and confidence in the has paid the covered entity in full.115 If that an actor’s denial of access to an privacy of their EHI and diminish the an individual made such a request and individual consistent with the limited willingness of patients, providers, and met all requirements of the HIPAA conditions for such denials that are other entities to provide or maintain Privacy Rule, the actor would be described in the HIPAA Privacy Rule at health information electronically in the required by law not to exchange the 45 CFR 164.524(a)(1), (2), and (3) is first place. In addition, such outcomes individual’s EHI to a health plan. In this reasonable under the circumstances. We would undermine and not advance the situation, the actor’s interference with believe this resolves any potential goals of the information blocking access, exchange, or use would not be conflict between limitations on an provision and be inconsistent with the information blocking and as such, the individual’s right of access under the broader policy goal of the Cures Act to actor would not need to benefit from HIPAA Privacy Rule and the facilitate trusted exchange of EHI. this exception. information blocking provision. Trusted exchange requires not only that Practices that are ‘‘required by law’’ We note that the information blocking EHI be shared in accordance with can be distinguished from other provision may operate to require that applicable law, but also that it be shared practices that an actor engages in actors provide access, exchange, or use in a manner that effectuates individuals’ pursuant to a privacy law, but which are of EHI in situations that HIPAA does expressed privacy preferences. We note not ‘‘required by law.’’ Such privacy not. This is because the HIPAA Privacy and discuss below that an individual’s laws are typically framed in a way that Rule permits, but does not require, expressed privacy preferences will not covered entities to use and disclose be controlling in all cases. An actor will 115 45 CFR 164.522(a)(1)(vi).

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00105 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7528 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

conditions the making of a ‘‘disclosure’’ To illustrate how we propose this sub- is not authorized to receive it. Where an on the satisfying of specific conditions, exception would operate, we provide actor cannot verify the identity or but does not expressly require that the the following examples. We note that authority of a person requesting access actor engage in a practice that interferes this list of examples is not exhaustive to EHI, and such verification is required with access, exchange, or use of EHI. and that preconditions required by law by law before the actor can provide For example, the HIPAA Privacy Rule that control access, exchange, or use of access, exchange, or use of the EHI, the provides that a covered entity may use EHI that are not listed below would still actor’s refusal to provide access, or disclose PHI in certain circumstances qualify under this proposed sub- exchange, or use will, subject to the where the individual concerned has exception so long as all conditions are conditions discussed herein, be authorized the disclosure.116 The effect met. reasonable and necessary and will not of this requirement is that the covered • Certain federal and state laws be information blocking. entity should not use or disclose the PHI require that a person provide consent • Under the HIPAA Privacy Rule, a in the absence of an individual’s before his or her EHI can be accessed, health care provider may share authorization. However, because the exchanged, or used for specific information with another health care requirement does not prohibit the actor purposes. Although the HIPAA Privacy provider for a quality improvement from exchanging the EHI in all Rule does not have consent project if it has verified that the circumstances, the actor would be at requirements for an individual (as that requesting entity has a relationship with risk of engaging in a practice that was term is defined in the HIPAA Privacy the person whose information is being information blocking unless an Rule) when a covered entity or business requested. Where the actor could not exception applied. For this reason, we associate is using or disclosing ePHI for establish if the relationship existed, it have included a sub-exception, treatment, payment or health care would not be information blocking for addressed in § 171.202(b) and discussed operations, some state laws and federal the actor to refuse to provide access, below, that provides that an actor will laws and regulations do require that a exchange, or use, subject to the not be engaging in information blocking person’s consent be obtained by the conditions discussed herein. if a state or federal privacy law imposes disclosing party/entity before disclosing We seek comments generally on this a precondition to the provision of certain health information. For example, proposed sub-exception. More access, exchange, or use, and that for some sensitive health conditions specifically, we seek comment on how precondition has not been satisfied. such as HIV/AIDS, mental health, or this proposed sub-exception would be genetic testing, state laws may impose a exercised by actors in the context of Sub-Exception To Proposed Privacy higher standard for disclosure of such state laws. We are aware that actors that Exception: Precondition Not Satisfied information (i.e., require consent) than operate across state lines or in multiple State and federal privacy laws that is required under the HIPAA Privacy jurisdictions sometimes adopt permit the disclosure of PHI often Rule. Additionally, under 42 CFR part 2, organization-wide privacy practices that impose conditions that must be satisfied federally-assisted ‘‘Part 2 programs’’ conform with the most restrictive prior to a disclosure being made. We generally are required to obtain a privacy laws regulating their business. propose to establish a sub-exception to person’s consent to disclose or re- In order to ensure that the information the information blocking provision that disclose patient-identifying information blocking provision does not diminish recognizes that an actor will not be related to the person’s substance use the privacy rights of individuals being engaging in information blocking if an disorder, such as treatment for serviced by such actors, we are actor does not provide access, exchange, addiction. The exception would operate considering the inclusion of an or use of EHI because a necessary to clarify an actor’s compliance accommodation in this sub-exception precondition required by law has not obligations in these situations. It would that would recognize an actor’s been satisfied. This exception will apply not be considered information blocking observance of a legal precondition that to all instances where an actor’s ability to refuse to provide access, exchange, or the actor is required by law to satisfy in to provide access, exchange, or use is use of EHI if the actor has not received at least one state in which it operates. ‘‘controlled’’ by a legal obligation to the person’s consent, subject to We believe this approach would be satisfy a condition, or multiple conditions discussed herein. consistent with practices already in conditions, prior to providing that • If an actor is required by law to place for multi-state health care access, exchange, or use. To be covered obtain an individual’s HIPAA systems. For example, some states by this exception, the actor must authorization before providing access, require specific consent requirements comply with conditions, which are exchange, or use of the individual’s EHI, before exchanging sensitive health discussed below. then the individual’s refusal to provide information such as a patient’s mental The nature of the preconditions that an authorization would justify the health condition. As a result, the health an actor must satisfy in order to provide actor’s refusal to provide access, care system will utilize one consent access, exchange, or use of EHI will exchange, or use of EHI. The actor’s form for multi-jurisdiction purposes in depend on the privacy laws that refusal would, subject to conditions order to meet various federal and state regulate the actor. An actor that is discussed herein, be protected under law requirements. However, in the event regulated by a restrictive state privacy this exception. that we did adopt such an • law may need to satisfy more conditions The HIPAA Privacy Rule, and many accommodation, we would also need to than an actor regulated by a less state privacy laws, authorize the carefully consider how to ensure that restrictive state privacy law, before disclosure of PHI in certain before the use of the most stringent providing access, exchange, or use. circumstances only once the identity restriction is applied in all jurisdictions, Similarly, certain state privacy laws and authority of the person requesting the actor has provided all privacy may impose standards for meeting the information has been verified. We protections afforded by that law across preconditions that are more rigorous acknowledge that it is reasonable and its entire business. This type of than the laws in force elsewhere. necessary that actors take appropriate approach would ensure that an actor steps, consistent with federal and state cannot take advantage of a more- 116 45 CFR 164.508 (Uses and disclosures for laws, to ensure that EHI is not disclosed restrictive privacy law for the benefit of which an authorization is required). to the wrong person or to a person who this exception while not also fulfilling

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00106 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7529

the privacy-protective obligations of the organizational policies and procedures policies and procedures, such policies law being relied on. We seek comment that identify the criteria to be used by and procedures must be in writing, and on whether there is a need for ONC to the actor and, as applicable, the steps specify the criteria to be used by the adopt such an accommodation for actors that the actor will take, in order to actor, and, if applicable, the steps that operating in multiple states, and satisfy the precondition. Most actors are the actor will take, in order to satisfy the encourage commenters to identify any covered entities or business associates precondition relied on by the actor not additional conditions that should attach for the purposes of the HIPAA Privacy to provide access, exchange, or use of to the provision of such an Rule, and are already required to have EHI. It would not be sufficient for an accommodation. We also request policies and procedures and training actor to simply identify the existence of comment on our proposed approach to programs in place that address how PHI the precondition in their organizational dealing with varying state privacy laws and ePHI is used (as that term is defined policies and procedures. throughout this proposed sub-exception. in 45 CFR 160.103, as amended) and We acknowledge that certain We also recognize that under the disclosed. As such, we expect that the preconditions may be outside the direct patchwork of state privacy laws, some overwhelming majority of actors will control of the actor. For example, the states have enacted laws that more already be in a position to meet this requirement that an actor receive a valid comprehensively identify the condition, or would be able to meet this authorization before releasing EHI in circumstance in which an individual or condition with modest additional effort. certain circumstances would be a entity can and cannot provide access, However, we acknowledge that some precondition to be satisfied by the exchange, or use of EHI. We are actors may not, for whatever reason, individual, and the actor may have little considering to what extent health care have privacy policies and practices in ability to influence the nature of the providers that are not regulated by the place, or may have implemented authorization that it receives. For HIPAA Privacy Rule, and would rely privacy policies and practices that do preconditions of this nature, the actor’s instead on state laws for this sub- not sufficiently address the criteria to be policies and procedures would only exception, would be able to benefit from used, and steps to be taken, to satisfy a need to identify the criteria that the this sub-exception when engaging in precondition relied on by the actor. As actor will apply and the steps that the practices that interfere with access, such, we propose to provide an actor will take to facilitate the exchange, or use of EHI for the purpose alternative basis on which to qualify, in satisfaction of the precondition, such as of promoting patient privacy. We seek part, for this sub-exception. We propose identifying the requirements for a valid comment on any challenges that may be to permit actors to instead document, on authorization and the follow up steps (if encountered by health care providers a case-by-case basis, the criteria used by any) to be taken in response to receipt that are not regulated as covered entities the actor to determine when the of an authorization that does not meet under the HIPAA Privacy Rule when precondition will be satisfied, any those requirements. In contrast, where seeking to take advantage of this criteria that were not met, and the the satisfaction of a precondition relies proposed sub-exception. We also seek reason why the criteria were not met. solely on an actor, such as the comment on whether there exists a class These alternative conditions, which are ‘‘minimum necessary’’ determination of health care provider that is not discussed in detail below, ensure that made by HIPAA covered entities (or regulated by any federal or state privacy this sub-exception does not protect their business associates) when law that prescribes preconditions that practices that are post hoc exchanging EHI that is ePHI, the actor’s must be satisfied in connection with the rationalizations used to justify improper policies and procedures would need to disclosure of EHI, and whether any such practices, whilst also ensuring that particularize the steps that the actor will class of health care provider would actors do not face any pressure to take in order to ensure that it satisfies benefit from a sub-exception similar to disclose EHI in the situation where they the precondition. Where the that proposed in § 171.202(c) for health do not have privacy policies and precondition falls somewhere in IT developers of certified health IT. practices in place, or where their between and relies on actions taken by both the actor and an individual, the Conditions To Be Met To Qualify for the privacy policies and practices do not actor’s policies and procedures would Sub-Exception respond to the requirements of this condition. need to address how the actor would do In most circumstances, an actor Separately, we propose that if the the things necessary within its control, would be in a position to influence precondition that an actor purports to which would include the steps it should whether a precondition is satisfied. For have been satisfied relies on the take to facilitate all actions needed to be example, an actor could deprive a provision of a consent or authorization taken by an individual. person of the opportunity to take some from an individual, it is a condition of Take, for example, the situation where step that is a prerequisite for the this sub-exception that the actor must an actor needed to determine whether exchange of their EHI, could assume the have done all things reasonably the subject individual had a relationship existence of a fact prejudicial to the necessary within its control to provide with a requesting entity as a granting of access without seeking to the individual with a meaningful precondition to exchanging EHI. The discover the truth or otherwise of the opportunity to provide that consent or actor’s policies and practices should, at fact, or could make a determination that authorization. minimum, identify the criteria to be a precondition was not satisfied without We reiterate, again, that the applied, being the evidence that the properly informing itself of all relevant information blocking provision does not actor would need in order to satisfy information. As such, we propose that require the provision of access, itself of the existence of a relationship, this exception would be subject to exchange, or use of EHI in a manner that such as receipt of a Medicare or other conditions that ensure that the would not be permitted under the insurance number, or other indicia of a protection of an individual’s privacy is HIPAA Privacy Rule. relationship such as the establishment not used as a pretext for information of a doctor-patient relationship. blocking. Organizational Policies and Procedures An actor would only be eligible to We propose that an actor can qualify, If an actor seeks to qualify for this benefit from this sub-exception if it has in part, for this sub-exception by sub-exception, in part, by implementing followed its processes and policies. implementing and conforming to and conforming to organizational Continuing the above example, an actor

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00107 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7530 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

that chose not to provide access to EHI documented but not applied. Proper interest at issue (discussed below), those on the basis that insufficient evidence implementation would involve making criteria would need to be directly had been provided to establish the the policies and processes available to relevant to satisfying the precondition. existence of the relationship, would all decision makers, and facilitating For example, if the precondition at issue need to show that its decision was based workforce and contractor understanding was the provision of a valid HIPAA on the applicable criteria specified in and consistent implementation of the authorization, the actor’s documented the actor’s policy and practices. actor’s policies and procedures such as record should reflect, at minimum, that Using a different example, and as by providing training. This condition the authorization would need to meet discussed above, the HIPAA Privacy ensures that this sub-exception does not each of the requirements specified for a Rule generally requires covered entities protect practices that are post hoc valid authorization at 45 CFR (and their business associates) to take rationalizations used to justify improper 164.508(c). The record would then need reasonable steps to limit the use or practices. to document the criteria that had not disclosure of, and requests for, PHI to As discussed above, to the extent been met, and the reason so. Continuing the minimum necessary to accomplish existing state and federal laws apply to the example, the actor could record that the intended purpose.117 Satisfying the a given actor, we expect an actor to the authorization did not contain the ‘‘minimum necessary’’ requirement is a already have procedures in place to name or other specific identification of precondition to be met under the address those legal requirements. the person making the request because HIPAA Privacy Rule before an actor Indeed, the HIPAA Privacy Rule the authorization only disclosed the exchanges ePHI for many purposes. The requires that covered entities have person’s first initial rather than first determination of what constitutes the policies and procedures and training name, and the actor had records about ‘‘minimum necessary’’ is a fact based programs in place that address how PHI multiple people with that same initial judgment made by an actor. To allow and ePHI are used (as those terms are and last name. covered entities the flexibility to defined in 45 CFR 160.103) and We believe that this condition will address their unique circumstances, the disclosed. Moreover, this exception is provide the transparency necessary to HIPAA Privacy Rule requires covered only enlivened when an actor asserts demonstrate whether the actor has entities (and their business associates) that its conduct was carried out to satisfied the conditions applicable to to make their own assessment of what satisfy a precondition, and we expect this exception. Moreover, it will ensure ePHI is reasonably necessary for a that such conduct should be considered that a decision to not provide access, particular purpose, given the and deliberate. exchange, or use of EHI is considered characteristics of their business and We seek comment on this proposed and deliberate, and therefore reasonable workforce. To qualify for this proposed condition generally, and specifically, on and necessary. sub-exception, the actor’s privacy whether an actor’s organizational policies and procedures would need to policies and procedures provide a We seek comment on this proposed identify criteria for making a ‘‘minimum sufficiently robust and reliable basis for condition. necessary’’ determination for both evaluating the bona fides, Meaningful Opportunity To Provide routine and non-routine disclosures and reasonableness, and necessity of Consent or Authorization requests, including identifying the practices engaged in to satisfy circumstances under which disclosing preconditions required by state or If the precondition that an actor the entire medical record is reasonably federal privacy laws. purports to have satisfied relies on the provision of a consent or authorization necessary. For actors that are covered Documenting Criteria and Rationale entities or business associates, the from an individual, it is a condition of development of policies and procedures If an actor’s practice does not conform this sub-exception that the actor must for the making of minimum necessary to an actor’s organizational policies and have done all things reasonably determinations for requesting, using and procedures as required by necessary within its control to provide disclosing PHI is already a requirement § 171.202(b)(1), we propose that that an the individual with a meaningful of the HIPAA Privacy Rule, so we actor can seek to qualify for this sub- opportunity to provide that consent or expect that actors will already have exception, in part, by documenting how authorization. This condition will be such policies and procedures in place. it reached its decision that it would not relevant when, for example, a state If an actor implemented its provide access, use, or exchange of EHI privacy law or the HIPAA Privacy Rule organizational policies and procedures on the basis that a precondition had not requires an individual to provide their for making ‘‘minimum necessary’’ been satisfied. Such documentation consent and/or HIPAA authorization determinations consistent with the must be created on a case-by-case basis. before identifiable information can be HIPAA Privacy Rule, and otherwise met An actor will not satisfy this condition accessed, exchanged, or used for the other conditions of this exception, a if, for instance, it sought to document a specific purposes. For instance, a state decision to exchange the minimum general practice that it had applied to all law may require that an individual necessary information but less instances where the precondition had provide consent before a hospital can information than requested by another not been satisfied. Rather, the record share her treatment information entity would satisfy this sub-exception created by the actor must address the electronically with another treating and not be considered information specific circumstances of the specific health care provider. Under this blocking. practice (or interference) at issue. scenario, the hospital’s refusal to Finally, an actor’s policies and The record created by the actor must exchange the EHI in the absence of the procedures must be implemented. This identify the criteria used by the actor to individual’s consent would be ensures that an actor can only satisfy determine when the precondition is reasonable and necessary and would not this condition by reference to privacy satisfied. That is, it must identify the be information blocking, so long as the policies and practices that individuals objective criteria that the actor applied hospital had provided the individual in fact benefit from, and not by policies to determine whether the precondition with a meaningful opportunity to and procedures that have been had been satisfied. Consistent with the provide that consent and where the condition to this sub-exception that the criteria and other conditions of this 117 45 CFR 164.502(b). practice must be tailored to the privacy proposed exception were met.

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00108 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7531

In the context of the provision of individual to not provide the consent or developed a considered response that is consent, a meaningful opportunity authorization. This does not mean that tailored to protecting and promoting the would ordinarily require that an actor the hospital cannot inform an privacy of EHI. For example, the HIPAA provide the individual with a legally individual about the advantages and Privacy Rule at 45 CFR 164.514(h) compliant consent form; make a disadvantages of exchanging EHI and requires that, in certain circumstances, reasonable effort to inform an individual any associated risks, so long as the the disclosure of PHI is only authorized that she has the right to consent to the information communicated is accurate once the identity and authority of the disclosure of her EHI; and provide the and legitimate. However, an actor would person requesting the information has individual with sufficient information not meet this condition in the event that been verified. The privacy issue to be and educational material it misled an individual about the nature addressed in this instance is the risk (commensurate with the circumstances of the consent to be provided, dissuaded that PHI will be disclosed to the wrong of the disclosure). It would be best individuals from providing consent in individual, or an unauthorized person. practice for an actor to also inform the respect of disclosures to the actor’s If an actor chooses not to provide individual about the revocability of any competitors, or imposed onerous access, exchange, or use of EHI on the consent given, if and as provided in the requirements to effectuate consent that basis that the actor’s identity relevant state or federal privacy law, were unnecessary and not required by verification requirements have not been and the actor’s processes for acting on law. satisfied, the actor’s practice must be any revocation. We seek comment on whether the tailored to the specific privacy risks at We are considering addressing this proposed condition requiring the issue. This would require that the actor condition in further detail, whether by provision of a meaningful opportunity ensure that it does not impose identity way of additional guidance or in and prohibiting improper verification requirements that are regulation text. To this end, we seek encouragement or inducement should unreasonably onerous under the comments regarding what actions an apply to preconditions beyond the circumstances. actor should take, within the actor’s precondition that an individual provide control, to provide an individual with a consent or authorization. We seek To illustrate, a policy where a driver’s meaningful opportunity to provide a comment on whether the conditions license was the only accepted required consent or authorization, and specified for this sub-exception, when government-issued form of whether different expectations should taken in total, are sufficiently identification would not be a practice arise in the context of a consent versus particularized and sufficiently strict to that is tailored to the privacy risk at a HIPAA authorization. For example, ensure that actors that are in a position issue because the provider’s preference commenters may wish to provide to influence whether a precondition is for one form of government-issued comment on the actions to be taken to satisfied will not be able to take identification over another does not ensure that an individual has a advantage of this sub-exception and meaningfully manage the privacy risk. meaningful opportunity to satisfy a seek protection for practices that do not Similarly, it may be unreasonable for an precondition that the individual provide promote the privacy of EHI. We also actor to require the production of a HIPAA authorization. Specifically, in seek comment on whether we should documentation demonstrating the the context of a requirement that the adopt a more tailored approach to parent-child relationship unless the authorization be signed, what effort conditioning the availability of this actor was in possession of information should be expected from actors in exception. For example, we are that suggested that an adult might not seeking signatures from: (i) Persons considering whether different have authority to be the child’s legal acting for the patient where the patient conditions should apply depending on: representative. To do otherwise would is unable to sign a form; (ii) former (i) The nature of the EHI at issue; (ii) the be to apply an onerous requirement in patients whose EHI is being requested circumstances in which the EHI is being all instances of parent-child from third parties; or (iii) patients that access, exchanged, or used; (iii) the relationships, which is insufficiently are not in a facility, such as patients of interest being protected by the tailored to the privacy risk being individual physicians? precondition; or (iv) the nature of the managed. Finally, it may be We clarify that after providing the precondition to be satisfied. unreasonable for an actor to insist that individual with a meaningful Commenters are encouraged to identify the individual produce original opportunity to consent or provide scenarios in which the application of identification if the individual was able authorization, we believe that it is the the conditions applicable to this sub- to furnish a scanned copy of their form individual’s responsibility to complete exception, as proposed, give rise to of identification that the actor could any required documentation before an unnecessary burden, or would require reasonably rely on. actor is able to access, exchange, or use activities that do not advance the dual For the purposes of this sub- the individual’s EHI. We do not expect policy interests of preventing exception, we clarify that engaging in an the actor to ‘‘chase’’ the individual information blocking and promoting interference on the basis that a despite using its best efforts provide the privacy and security. individual with an opportunity to sign precondition has not been satisfied a consent or authorization form. So long Practice Must Be Tailored to the would be a practice that addresses a as the actor has provided the individual Specific Privacy Risk or Interest Being privacy risk or interest, and so tailoring with a meaningful opportunity to Addressed that interference to satisfy a consent, the actor will have fulfilled this To qualify for this sub-exception, an precondition can satisfy this condition. aspect of the eligibility requirements of actor’s privacy-protective practice must Controls on access, exchange, or use this sub-exception. be tailored to the specific privacy risks arising under privacy laws serve a Separately, to qualify for this sub- that the practice actually addresses. privacy interest and so this condition exception, to the extent that the This condition necessarily presupposes will be met so long as the actor’s precondition at issue was the provision that an actor has carefully evaluated the practice is tailored to the risk or interest of a consent or authorization by an privacy requirements imposed on the being addressed. individual, the actor must not have actor, the privacy interests to be We seek comment on this proposed improperly encouraged or induced the managed by the actor, and has condition.

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00109 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7532 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

Practice Must Be Implemented in a operation of the actor’s health IT have developed this sub-exception for Consistent and Non-Discriminatory product or service (referred to hereafter the express purpose of addressing Manner as ‘‘non-covered actors’’). We expect privacy-protective practices that are not We propose that in order for a that the class of actors to which this regulated by the HIPAA Privacy Rule, practice to qualify for this sub- proposed sub-exception applies will be we acknowledge that there may be other exception, the practice must be very small. The vast majority of health privacy laws implicated by the practice implemented in a consistent and non- IT developers of certified health IT in question. If the actor’s practice operate as business associates to health discriminatory manner. This condition contravenes a state or federal privacy care providers or health plans, are law, but otherwise satisfies this would provide basic assurance that the regulated by the HIPAA Privacy Rule, proposed sub-exception, the actor purported privacy practice is directly and will be able to benefit from the would not be entitled to benefit from related to a specific privacy risk and is exception proposed in § 171.202(b) to this sub-exception. not being used to interfere with access, the extent that the HIPAA Privacy Rule exchange, or use of EHI for other Practice Must Implement Privacy Policy (or applicable state privacy law) purposes to which this exception does imposes preconditions to the provision In order to qualify for this sub- not apply. of access, exchange, or use of EHI. exception, the practice engaged in by This condition requires that the However, we recognize that direct-to- the non-covered actor—the interference actor’s privacy-protective practices must consumer health IT products and with access, exchange, or use of EHI— be based on objective criteria that apply services are a growing sector of the must also implement a process uniformly for all substantially similar health IT market. This class of health IT described in the actor’s organizational privacy risks. An actor could not, for is often not regulated by the HIPAA privacy policy. This requires that a non- example, implement an organizational Privacy Rule, but could be certified covered actor must have documented in privacy policy that imposed under the Program. We note that the detail in its organizational privacy unreasonably onerous requirements on a privacy practices of consumer-facing policy the processes and procedures certain class of individuals or entities health IT products and services are that the actor will use to determine without a legitimate justification for typically regulated by the Federal Trade when the actor will not provide access, doing so. For example, an actor that Commission Act (FTC Act). However, exchange, or use of EHI. For example, a offered a patient-facing software the FTC Act applies to acts and non-covered actor that proposed to application (app) would not be able to practices that are unfair and deceptive require the provision of written consent benefit from this exception if it refused (15 U.S.C. 45(a)(1)), and does not for the use or disclosure of EHI would to exchange EHI with a competitor app prescribe privacy requirements to be need to describe in its organizational on the basis of an individual’s failure to adopted or followed that can be privacy policy the processes and meet onerous authorization leveraged for the purpose of recognizing procedures to be utilized by the actor to requirements that applied only to health reasonable and necessary privacy- implement that privacy-protective information exchange with the protective practices in this proposed practice in order that the practice be competitor app and did not apply to, for rule.118 considered reasonable and necessary example, the exchange of EHI with As discussed in section VIII.C.2.b, and qualify for this sub- exception. A health care providers. This condition where a health IT developer of certified privacy policy that was prepared at a provides basic assurance that the health IT offers a health IT product or high level—for example, that simply purported privacy-protective practice is service not regulated by the HIPAA stated that written consent was not being used to interfere with access, Privacy Rule, such product or service is required—would not qualify. To build exchange, or use of EHI for other subject to the information blocking on this example, a non-covered actor’s purposes to which this proposed provision. We want to ensure that non- consent policy would need to describe exception does not apply. covered actors that engage in reasonable the specific requirements that are We request comment on this proposed and necessary privacy-protective imposed on individuals when giving condition. practices that interfere with the access, consent, together with the processes and procedures to be followed by the non- Sub-Exception to Proposed Privacy exchange, or use of EHI can seek covered actor to ensure that the Exception: Health IT Developer of coverage under this proposed sub- individual has a meaningful choice over Certified Health IT Not Covered by exception. As such, we propose that a whether to consent. Compliance with HIPAA non-covered actor will not engage in information blocking if the actor does this condition ensures that this sub- The sub-exception proposed in not provide access, exchange, or use of exception recognizes only legitimate § 171.202(b) recognizes as reasonable EHI where the practice implements a practices that have been tailored to the and necessary the activities engaged in process that is described in the actor’s privacy needs of the individuals that by actors consistent with the controls organizational privacy policy and has use the non-covered actor’s health IT, placed on access, exchange, or use of been disclosed to any individual or and does not recognize practices that are EHI by federal and state privacy laws. entity that uses the actor’s health IT. a pretext or after-the-fact rationalization Importantly, that sub-exception is This proposed sub-exception is for actions that interfere with access, limited to actors that are subject to those proposed in § 171.202(c). exchange, or use of EHI. federal and state privacy laws; an actor As a threshold requirement of this It necessarily follows that the non- that is not regulated by HIPAA or a state sub-exception, the actor’s practice of covered actor’s practice must implement privacy law cannot benefit from the interfering with access, exchange, or use its documented organizational privacy exception proposed in § 171.202(b). of EHI must comply with any applicable policy. For example, if a non-covered We propose to establish a sub- state or federal privacy laws. While we actor chose not to provide access, exception to the information blocking exchange, or use of EHI on the basis that provision that would apply to actors 118 See HHS, Examining Oversight of the Privacy it could not verify the identity of the that are health IT developers of certified & Security of Health Data Collected by Entities Not individual requesting the EHI, the non- Regulated by HIPAA, https://www.healthit.gov/ health IT but not regulated by the sites/default/files/non-covered_entities_report_ covered actor would need to be able to HIPAA Privacy Rule in respect to the june_17_2016.pdf. demonstrate that it implemented the

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00110 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7533

part of its organizational privacy policy privacy- protective practices that it will when describing their privacy practices that dealt with identity verification. implement in its product, or when and processes to user of health IT. Practices that diverge from an actor’s providing its service, there is a risk that Sub-Exception to Proposed Privacy documented policies or practices, or this proposed sub-exception will give Exception: Denial of an Individual’s deference to policies and processes that which are not addressed in an actor’s Request for Their Electronic Protected are post hoc rationalizations used to organizational privacy policy, would Health Information in the justify improper practices. This not qualify for this proposed sub- Circumstances Provided in 45 CFR condition also serves as a check on the exception. 164.524(a)(1), (2), and (3) nature of the interferences that a non- Practice Must Have Been Disclosed to covered actor writes into its We propose a limited sub-exception Users organizational privacy policies; to the information blocking provision A non-covered actor that seeks to transparency will help to ensure that a that would permit a covered entity or benefit from this proposed sub- non-covered actor takes a balanced business associate to deny an exception must also ensure that it has approach to protecting privacy interests individual’s request for access to their previously disclosed the privacy- on one hand, and pursuing business PHI in the circumstances provided protective practice to the individuals interests that might be inconsistent with under 45 CFR 164.524(a)(1), (2), and (3). and entities that use, or will use, the the information blocking provision, on We believe this exception would avoid health IT. These users are affected by the other hand. We hope that this a potential conflict between the HIPAA the practices engaged in by a non- requirement will foster a quasi-market Privacy Rule and the information covered actor but may otherwise have based measure of when a privacy- blocking provision. Specifically, the no visibility of the non-covered actor’s protective practice is ‘‘reasonable and HIPAA Privacy Rule contemplates approach to protecting the privacy of necessary,’’ and ensure that any circumstances under which covered EHI. We expect that non-covered actors departure made by a non-covered actor entities, and in some instances business will seek to satisfy this condition by from privacy practices that are associates, may deny an individual using a privacy notice.119 We emphasize recognized by state or federal law is access to PHI and distinguishes those that the disclosure must be meaningful. transparent and open. grounds for denial which are reviewable In assessing whether a non-covered It will be a matter for non-covered from those which are not. This actor’s disclosure was meaningful, actors to determine the most appropriate exception applies to both the regard will be paid to whether the way to communicate its privacy ‘‘unreviewable grounds’’ and disclosure was in plain language and practices to users. We believe that it ‘‘reviewable grounds’’ of access. The conspicuous, including whether the would be reasonable that non- covered ‘‘unreviewable grounds’’ for denial for disclosure was located in a place, and actors would, at minimum, post their individuals include situations presented in a manner, that is accessible privacy notices, or otherwise describe involving: (1) Certain requests that are and obvious to the individuals and their privacy-protective practices, on made by inmates of correctional entities that use, or will use, the health their websites. institutions; (2) information created or IT. obtained during research that includes Practice Must Be Tailored to Privacy treatment, if certain conditions are met; To qualify for this sub-exception, a Risk and Implemented in a Non- non-covered actor would not be (3) denials permitted by the Privacy Act; Discriminatory Manner and (4) information obtained from non- required to disclose its organizational Finally, we propose that in order for health care providers pursuant to privacy policy to its customers or to the a practice to qualify for this sub- promises of confidentiality. In addition, public generally. Rather, the non- exception, an actor’s practice must be two categories of information are covered actor need only describe, with tailored to the specific privacy risks that expressly excluded from the individual sufficient detail and precision to be the practice actually addresses, and right of access: (1) Psychotherapy notes, readily understood by users of the non- must be implemented in a consistent which are the personal notes of a mental covered actor’s health IT, the privacy- and non-discriminatory manner. These health care provider documenting or protective practices that the non- conditions also apply to the exception analyzing the contents of a counseling covered actor has adopted and will proposed in § 171.202(b), and the session that are maintained separate observe. This is necessary because a discussion above addressing these from the rest of the patient’s medical non-covered actor that is not subject to conditions in connection with record (see 45 CFR 164.524(a)(1)); and prescribed privacy standards in § 171.202(b) applies to this proposed (2) information compiled in reasonable connection with the provision of health exception in § 171.202(c). We refer anticipation of, or for use in, a civil, IT will have significant flexibility in the readers to the above discussion and criminal, or administrative action or privacy-protective practices that it invite comments on these proposed proceeding (see 45 CFR 164.501). adopts. If an actor is not required to conditions. The ‘‘reviewable grounds’’ of access inform the individuals and entities that We seek comment on this proposed as described in § 164.524(a)(3), which use, or will use, the health IT, about the sub-exception generally. Specifically, provides that a covered entity may deny we seek comment on whether HIEs or access provided that the individual is 119 ONC has provided a Model Privacy Notice (MPN) that is a voluntary, openly available resource HINs would benefit from a similar sub- given a right to have such denials designed to help developers clearly convey exception. We also seek comment on reviewed under certain circumstances. information about their privacy and security whether the conditions applicable to One such circumstance is when a policies to their users. Similar to the FDA Nutrition this sub-exception are sufficient to licensed health care professional, in the Facts Label, the MPN provides a snapshot of a company’s existing privacy practices encouraging ensure that non-covered actors cannot exercise of professional judgment, transparency and helping consumers make take advantage of this exception by determines that the access requested is informed choices when selecting products. The engaging in practices that are reasonably likely to endanger the life or MPN does not mandate specific policies or inconsistent with the promotion of physical safety of the individual or substitute for more comprehensive or detailed privacy policies. See https://www.healthit.gov/ individual privacy. We also seek another person. In addition, if access is topic/privacy-security-and-hipaa/model-privacy- comment on the level of detail that non- denied, then the individual has the right notice-mpn. covered actors should be required to use to have the denial reviewed by a

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00111 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7534 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

licensed health professional who is to concerns, if expressed by an individual purposes of this sub-exception unless act as a reviewing official and did not and agreed to by an actor, would be and until it is subsequently revoked by participate in the original decision to reasonable and necessary, and an actor’s the individual. We believe this deny access (see generally 45 CFR conduct in abiding by its agreement approach would minimize compliance 164.524(a)(3)). would, if all conditions are met, be an burdens for actors while also respecting We propose that if an actor who is a exception to the information blocking individuals’ requests. We propose that covered entity or business associate provision. once the individual makes the request, denies an individual’s request for access This proposed sub-exception would she should not, subject to the to their PHI on the basis of these not apply under circumstances where requirements of applicable federal or unreviewable and reviewable grounds, an actor interferes with a use or state laws and regulations, have to and provided the denial of access disclosure of EHI that is required by continually reiterate her privacy complies with the requirements of the law, including when EHI is required by preferences, such as having to re-submit HIPAA Privacy Rule in each case, then the Secretary to enforce HIPAA under a request every year. Likewise, we the actor would qualify for this 45 CFR 164.502(a)(2)(ii) and 45 CFR propose that once the actor has exception and these practices would not 164.502(a)(4)(i). Stated differently, this documented an individual’s request, the constitute information blocking. sub-exception would not operate to actor should not have to repeatedly The following example illustrates this permit an actor to refuse to provide reconfirm and re-document the request. proposed sub-exception. An individual access, exchange, or use of EHI when We seek comment, however, regarding is a patient of a psychiatrist who is a that access, exchange, or use is required whether this approach is too permissive HIPAA covered entity. The patient has by law. This sub-exception recognizes and could result in unintended requested all of his electronic health and supports the public policy objective consequences. We also seek comment files from the psychiatrist. The of the HIPAA Privacy Rule, which on this proposed sub-exception psychiatrist maintains separately from identifies uses and disclosures of EHI generally, including on effective ways the electronic health record a file for which the public interest in the for an individual to revoke his or her containing psychotherapy notes disclosure of the individual’s privacy request for purposes of this sub- regarding the patient. The psychiatrist information outweighs the individual’s exception. grants access to the patient by providing interests in controlling the information. We also propose that in order for a a copy of the information in his This sub-exception would permit an practice to qualify for this sub- electronic health record, but does not actor not to share EHI if the following exception, an actor’s practice must be provide the patient’s psychotherapy conditions are met: (1) The individual implemented in a consistent and non- notes. Under this example, the made the request to the actor not to have discriminatory manner. This condition psychiatrist would meet the his or her EHI accessed, exchanged, or would provide basic assurance that the requirements of this proposed exception used; (2) the individual’s request was purported privacy practice is directly since the HIPAA Privacy Rule provides initiated by the individual without any related to the risk of disclosing EHI that covered entities can deny improper encouragement or inducement contrary to the wishes of an individual, individuals access to their by the actor; and (3) the actor or its and is not being used to interfere with psychotherapy notes and provides that agent documents the request within a access, exchange, or use of EHI for other this is an unreviewable grounds for reasonable time period. purposes to which this exception does denial. To qualify for this sub-exception, the not apply. This condition requires that We seek comment on this proposed request that the individual’s EHI not be the actor’s privacy-protective practice sub-exception. accessed, exchanged, or used must come must be based on objective criteria that from the individual. Moreover, the Sub-Exception to Proposed Privacy apply uniformly for all substantially individual must have made the request Exception: Respecting an Individual’s similar privacy risks. independently and without any We note that under the HIPAA Request Not To Share Information improper encouragement or inducement Privacy Rule, individuals have the right We propose to establish an exception by the actor. For example, it would be to request restrictions on how a covered to the information blocking provision improper to encourage individuals not entity will use (as that term is defined that would, in certain circumstances, to share information with unaffiliated in 45 CFR160.103) and disclose PHI permit an actor not to provide access, providers on the basis of generalized or about them for treatment, payment, and exchange, or use of EHI if an individual speculative risks of unauthorized health care operations pursuant to 45 has specifically requested that the actor disclosure. On the other hand, if the CFR 164.522(a)(1). Under § 164.522(a), a not do so. This sub-exception is actor was aware of a specific privacy or covered entity is not required to agree proposed in § 171.202(e). We believe security risk, it would not be improper to an individual’s request for a this sub-exception is necessary to to inform individuals of that risk. restriction (other than in the case of a ensure that actors are confident that Likewise, an actor would be permitted disclosure to a health plan under they can respect individuals’ privacy to provide an individual with general § 164.522(a)(1)(vi)), but is bound by any choices without engaging in information information about her privacy rights and restrictions to which it agrees. blocking, and to promote public options, including for example, the We wish to clarify that, for the confidence in the health IT option to not provide consent, provided purposes of this proposed sub- infrastructure by effectuating patients’ the information is presented accurately, exception, the actor may give effect to preference about how and under what does not omit important information, an individual’s request not to have an circumstances their EHI will be and is not presented in a way that is actor disclose EHI even if state or accessed, exchanged, and used. We likely to improperly influence the federal laws would allow the actor not recognize that individuals may have individual’s decision about how to to follow the individual’s request. This concerns about permitting their EHI to exercise their rights. is consistent with our position that, be accessed, exchanged, or used If an individual submits a request to absent improper encouragement or electronically under certain an actor not to disclose her EHI, and the inducement, and subject to appropriate circumstances. As a matter of public actor agrees with and documents the conditions, it should not be considered policy, we think that these privacy request, the request would be valid for information blocking to give effect to

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00112 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7535

patients’ individual preferences about The Cures Act directs the National As such, we propose that actors how their EHI will be shared or not. As Coordinator, in consultation with the would be able to satisfy this exception an illustration, if an individual requests HHS Office for Civil Rights (OCR), to through practices that implement either that her EHI not be accessed, exchanged, issue guidance on common ‘‘security security policies and practices or used by a physician to help train new barriers’’ that prevent the trusted developed by the actor, or case-by-case staff at a hospital, the physician may exchange of EHI (section 3022(c)(2) of determinations made by the actor. agree not to use the individual’s EHI for the PHSA). However, the Cures Act also Whether a security-motivated practice this purpose despite the fact it would seeks to promote the security of EHI, meets this exception would be not be required by law to agree to such which it defines as an element of determined on a case-by-case basis a restriction. Provided the physician has interoperability (section 3000(9)(A) of using a fact-based analysis of the not encouraged or induced the the PHSA) and a target area for the conditions set forth below. This individual to make this request, this policy development to be undertaken by approach offers the most appropriate sub-exception would apply to the the Health Information Technology framework for analyzing security physician’s refusal to disclose the Advisory Committee (section practices, which are necessarily driven information to staff for training 3002(b)(2)(B)(ii) of the PHSA). The by and must be tailored to actors’ purposes. inclusion of these provisions promote individual circumstances. We seek comments on this sub- broader access, exchange, and use of We wish to emphasize that the exception generally. Specifically, we EHI while at the same time continuing security-based practices implemented seek comment on what would be to promote the confidentiality, integrity, by a single physician office with limited considered a reasonable time frame for and availability of EHI through security technology resources, for example, will documentation. In addition, we also practices that are appropriate and be different to those implemented by a seek comment on how this sub- tailored to identified vulnerabilities and large health system, and that this exception would affect public health risks. difference does not affect an actor’s disclosures and health care research, if To qualify for this exception, we ability to qualify for this exception. The an actor did not share a patient’s EHI propose that an actor’s conduct must fact-based approach we propose will due to a privacy preference, including satisfy threshold conditions. As allow each actor to implement policies, any effects on preventing or controlling discussed in detail below, the particular procedures, and technologies that are diseases, injury, or disability, and the security-related practice must be appropriate for its particular size, reporting of disease, injury, and vital directly related to safeguarding the organizational structure, and risks to events such as births or deaths, and the confidentiality, integrity, and individuals’ EHI. A fact-based analysis also aligns with conduct of public health surveillance availability of EHI, implemented the HIPAA Security Rule 120 and health care research. consistently and in a non- concerning discriminatory manner, and tailored to the security of ePHI. The HIPAA 3. Promoting the Security of EHI identified security risks. Security Rule does not dictate the security measures that a covered entity We propose to establish an exception While the importance of security or business associate must implement, to the information blocking provision practices cannot be overstated, this but instead requires the entity to that would permit actors to engage in proposed exception would not apply to develop security practices and practices that are reasonable and all practices that purport to secure EHI. implement administrative, physical, and necessary to promote the security of Rather, this exception will only be technical safeguards that take into EHI, subject to certain conditions. available when the actor’s security- account the entity’s size, complexity, Without this exception, actors may be based practice satisfies the conditions and capabilities; technical, hardware, reluctant to implement security applicable to this exception. We do not and software infrastructure; the costs of measures or engage in other activities believe it would be appropriate to security measures; and the likelihood that are reasonable and necessary for prescribe a ‘‘maximum’’ level of security and possible impact of potential risks to safeguarding the confidentiality, or to dictate a one-size-fits-all approach ePHI. Under the HIPAA Security Rule, integrity, and availability of EHI. This for all actors that may not be covered entities and business associates could undermine the ultimate goals of appropriate in all circumstances and are required to conduct an accurate and the information blocking provision by may not accommodate new threats, thorough assessment of the potential discouraging best practice security countermeasures, and best practices in a risks and vulnerabilities to the protocols and diminishing the reliability rapidly changing security landscape. confidentiality, integrity, and of the health IT ecosystem. Indeed, security infrastructure varies availability of ePHI held by the covered Robust security protections are from organization to organization, and entity or business associate. Once critical to promoting patients’ and other there exist diverse approaches and covered entities and business associates stakeholders’ trust and confidence that technology solutions to managing have completed the risk assessment, EHI will be collected, used, and shared security risks. We do not intend for this they must take security measures in a manner that protects individuals’ proposed exception to dictate a specific sufficient to reduce identified risks and privacy and complies with applicable security approach when an actor’s vulnerabilities to reasonable and legal requirements. Public confidence in security posture must be agile and its appropriate levels (45 CFR the security of their EHI has been practices iterative. Moreover, effective 164.308(a)(1)(ii)). We note, however, challenged, however, by the growing security best practices focus on the that while our approach is consistent incidence of cyber-attacks in the health mitigation and remediation of risks to a with the regulation of security practices care sector. More than ever, health care reasonable and acceptable level, and not under the HIPAA Security Rule, the fact providers, health IT developers, HIEs the elimination of all vulnerabilities, so that a practice complies with the HIPAA and HINs must be vigilant to mitigate organizations should have the flexibility Security Rule does not establish that it security risks and implement to assess what vulnerabilities to address and how best to address them while appropriate safeguards to secure the EHI 120 The HIPAA Security Rule is located at 45 CFR they collect, maintain, access, use, and ensuring the confidentiality, integrity, part 160 and Subparts A and C of Part 164 and 68 exchange. and availability of EHI. FR 8333.

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00113 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7536 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

meets the conditions of this proposed the actor’s organizational security consistently and in a non- exception to the information blocking policy, risk assessments, and other discriminatory manner. However, we provision. The HIPAA Security Rule relevant documentation, which most believe an identity proofing requirement and this proposed exception have actors are already required to develop would not be tailored if it were not different focuses. The HIPAA Security pursuant to requirements under the based on an objectively reasonable Rule establishes a baseline by requiring HIPAA Rules.121 However, we propose security risk assessment and a careful certain entities to ensure the that the documentation of an actor’s consideration of alternative approaches confidentiality, integrity, and decision-making would not necessarily that could adequately address the availability of ePHI by implementing be dispositive. For example, if the specific risk of patient misidentification security measures, among other practice had the practical effect of in a less restrictive fashion. safeguards, that the entities determine disadvantaging competitors or steering As a final example, an actor’s decision are sufficient to reduce risks and referrals, this could be evidence that the to deny access to the EHI it maintains vulnerabilities to a reasonable and practice was not directly related to the may be reasonable if the practice appropriate level. In contrast, the safeguarding the confidentiality, responds to a request for EHI from a purpose of this exception to the integrity, and availability of EHI. We patient-facing website or application information blocking provision is to propose that such an inference would that causes the actor’s system to raise a provide flexibility for reasonable and also not be warranted where the actor malicious software detection alert or if necessary security practices while has not met the other conditions of this the request comes from a website or screening out practices that purport to exception proposed below, as where the application listed on a security promote the security of EHI but that are actor’s policies were not developed or ‘‘blacklist.’’ However, we propose that unreasonably broad, onerous on those implemented in a reasonable manner; the actor’s response must be tailored to seeking access to the EHI, are not its security policies or practices were the specific threat. Among other things, applied consistently across/within an not tailored to specific risks; or it the denial of access must be limited to organization, or otherwise may applied its security policies or practices the patient and/or their personal unreasonably interfere with access, in an inconsistent or discriminatory software. So as to ensure that the exchange, or use of EHI. manner. response is properly tailored, it would We propose the following conditions be best practice for actors to ensure that that must be met for an activity or The Practice Must Be Tailored to the they communicate to those persons practice to qualify for this exception. Specific Security Risk Being Addressed whose access was denied the reason for To qualify for this exception, we the denial of access, and communicate The Practice Must Be Directly Related propose that an actor’s security-related objective timeframes (if feasible to do To Safeguarding the Confidentiality, practice must be tailored to specific so) and other parameters for when Integrity, and Availability of EHI security risks that the practice actually access would be granted or restored. As a threshold condition, the addressed. This condition necessarily Moreover, we propose that, to the extent proposed exception would not apply to presupposes that an actor has carefully that the practice implements an any practices that are not directly evaluated the risk posed by the security organizational security policy, the related to safeguarding the security of threat and developed a considered policy must align with applicable EHI. In assessing the practice, we would response that is tailored to mitigating consensus-based standards or best consider whether and to what extent the the vulnerabilities of the actor’s health practices for responding to these types practice directly addressed specific IT or other related systems. For of incidents. Disagreement with the security risks or concerns. We would example, the awareness of a security individual about the worthiness of the also consider whether the practice vulnerability in a particular HIE’s third party as a recipient of EHI, or even served any other purposes and, if so, technology may justify a health care concerns about what the third party whether those purposes were merely provider’s suspending access to EHI might do with the EHI, except for incidental to the overriding security from that organization or by participants reasons such as those listed in the purpose or provided an objectively of that HIE, but only for the period in ‘‘preventing harm’’ exception, are not distinct, non-security-related rationale which the threat persists. In contrast, a acceptable reasons to deny an for engaging in the practice. response that suspended access by all individual’s request. We note that it should not be HIEs or that persisted even after the HIE Practice Must Be Implemented in a particularly difficult or onerous for an had addressed the security vulnerability actor to demonstrate, as contemplated Consistent and Non-Discriminatory in its technology would not be tailored Manner above, that its practice was directly to address specific risks and would not related to a specific security risk or meet this condition. We propose that in order for a concern. For example, the actor may As another example, it may be practice to qualify for this proposed show that the practice was a direct reasonable for a health care provider to exception, the actor’s practice must response to a known security incident refuse to grant access to EHI when an have been implemented in a consistent or threat; or that the practice directly individual has been unable to prove her and non-discriminatory manner. This related to the need to verify a person’s identity. However, the actor’s identity condition would provide basic identity before granting access to EHI; or proofing practice would have to be assurance that the purported security that the practice was directly related to tailored to address risks specifically practice is directly related to a specific ensuring the integrity of EHI. associated with the disclosure of EHI to security risk and is not being used to The salient issue under this unauthorized individuals. For example, interfere with access, exchange, or use condition, therefore, would be whether identity proofing requirements might be of EHI for other purposes to which this the security practice was actually tailored if the practice is based on a risk exception does not apply. necessary and directly related to assessment and best practice policies As an illustration solely of the non- safeguarding EHI. To that end, we and procedures and is applied discriminatory manner condition, would consider the actor’s purported consider a health IT developer of basis for adopting the particular security 121 45 CFR 164.306(d)(3)(ii)(B)(1); 45 CFR certified health IT that offers apps to its practice, which could be evidenced by 164.316(b)(1). customers via an app marketplace. If the

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00114 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7537

developer requires that third-party apps was reasonable, the policy would have critical infrastructure (https://ics- sold (or made available) via the to meet the following conditions. cert.us-cert.gov/). developer’s app marketplace meet • Risks identified and assessed. The As a point of clarification, we note certain security requirements, those actor’s security policy must be informed that an actor’s compliance with the security requirements must be imposed by an assessment of the security risks HIPAA Security Rule (if applicable to in a non-discriminatory manner. This facing the actor. While we do not the actor) would be relevant to, but not would mean, for example, that if a propose any requirements as to a risk dispositive of, whether the actor’s developer imposed a requirement that assessment, we note that a good risk policies and procedures were third-party apps include two-factor assessment would use an approach objectively reasonable for the purpose of authentication for patient access, the consistent with industry standards,122 this exception. An actor’s developer would need to ensure that the and would incorporate elements such as documentation of its security policies same requirement was imposed on, and threat and vulnerability analysis, data and procedures for compliance with the met by, all other apps, including any collection, security measures, likelihood Security Rule may not offer a basis to apps made available by the developer of occurrence, impact, level of risk, and evaluate whether the actor’s security itself. To note, such a developer final reporting.123 practices unnecessarily interfere with requirement must also meet the other • Consensus-based standards or best access, use, or exchange of EHI. For conditions of this exception (e.g., the practice guidance. The actor’s policy example, it could be difficult to condition that the practice be tailored to must align with one or more applicable determine whether a practice the specific security risk being consensus-based standards or best unnecessary interferes with exchange of addressed). practice guidance. At present, examples EHI based on a review of the customized of relevant best practices for PHI data flow diagram the actor Practices That Implement an development of security policies prepared as part of its Security Rule risk Organizational Security Policy include, but are not limited to: NIST– analysis. We believe that a documented As discussed above, an actor’s 800–53 Rev. 5; the NIST Cybersecurity policy that provides explicit references approach to information security Framework; and NIST SP 800–100, SP to consensus-based standards and best management will reflect the actor’s 800–37 Rev. 2, SP 800–39, as updated practice guidance (such as the NIST particular size, organizational structure, and as interpreted through formal Cybersecurity Framework) offer an and risk posture. Because of this, it is guidance. Best practice guidance on objective and robust means for ONC and important that actors develop and security policies is also developed by the OIG to evaluate the reasonableness implement organizational policies that consensus standards bodies such as ISO, of a particular security control for the secure EHI. We propose that, where an IETF, or IEC. HIPAA covered entities purpose of this exception. actor has documented security policies and business associates may be able to We recognize that, as a practical that align with applicable consensus- leverage their HIPAA Security Rule matter, some actors (such as small based standards, and where the policies compliance activities and can, if they health care providers or those with are implemented in a consistent and choose, align their security policy with limited resources) may have non-discriminatory manner, a practice’s those parts of the NIST Cybersecurity organizational security policies that are conformity with such policies would Framework that are referenced in the less robust or that otherwise fall short of provide a degree of assurance that the HIPAA Security Rule Crosswalk to NIST the minimum conditions proposed practice was reasonable and necessary Cybersecurity Framework to satisfy this above. As discussed immediately below, to address specific security risks and condition. Relevant consensus-based we propose that in these circumstances thus should not constitute information standards and frameworks provide an actor could still benefit from this blocking. Conversely, a practice that actors of varying size and resources with proposed exception by demonstrating went beyond an actor’s established the flexibility needed to apply the right that the practice at issue was objectively policies or practices by imposing security controls to the right reasonable under the circumstances, security controls that were not information systems at the right time to without regard to a formal policy. documented, would not qualify for this adequately address risk. Practices That Do Not Implement an exception under this condition • Objective timeframes and other Organizational Security Policy (although the actor may be able to parameters. We propose that the actor’s qualify under the alternative basis for security policy must provide objective While we expect that most security practices that do not implement a timeframes and common terminology practices engaged in by an actor will security policy). Further, such practices used for identifying, responding to, and implement an organizational policy, we would be suspect under the information addressing security incidents. Examples recognize that EHI security may present blocking provision if there were of acceptable sources for development novel and unexpected threats that even indications that the actor’s security- of a security response plan include: a best-practice risk assessment and related justifications were a pretext or NIST Incident Response Procedure security policy cannot anticipate. If a after-the-fact rationalizations for its (https://csrc.nist.gov/publications/ practice that does not implement an actions or was otherwise unreasonable detail/sp/800-61/rev-2/final), US–CERT organizational policy is to qualify for under the circumstances. for interactions with government this exception, however, it must meet We reiterate that, to the extent that an systems (https://www.us-cert.gov/ certain conditions. The actor’s practice actor seeks to justify a practice on the government-users/reporting- must, based on the particularized facts basis of its organizational security requirements), and ISC–CERT for and circumstances, be necessary to policies, such policies must be in mitigate the security risk. Importantly, writing and implemented in a consistent 122 See OCR, Guidance on Risk Analysis, https:// we propose that the actor would have to and non-discriminatory manner. As www.hhs.gov/hipaa/for-professionals/security/ demonstrate that it considered noted above, what a policy requires will guidance/guidance-risk-analysis/ reasonable and appropriate alternatives depend on the facts and circumstances. index.html?language=es. that could have reduced the likelihood 123 ONC and OCR have jointly launched the HHS However, we propose that to support a HIPAA Security Risk Assessment (SRA) Tool, of interference with access, exchange, or presumption that a practice conducted https://www.healthit.gov/providers-professionals/ use of EHI, and that there were no pursuant to the actor’s security policy security-risk-assessment-tool. reasonable and appropriate alternatives

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00115 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7538 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

that were less likely to interfere with 4. Recovering Costs Reasonably Incurred models, capabilities, service levels, and access, exchange or use of EHI. We propose to establish an exception other factors, we concluded that these We note that an actor’s consideration to the information blocking provision factors alone could not adequately of reasonable and appropriate that would permit the recovery of explain all of the variation in prices that alternatives will depend on the urgency certain costs reasonably incurred to we had observed. Based on these and and nature of the security threat in provide access, exchange, or use of EHI. other indications, we concluded that question. We anticipate that an actor’s The exception and corresponding some actors were engaging in opportunistic pricing practices or, in qualification for this exception would conditions are set forth in the proposed some cases, charging prices designed to accommodate exigent circumstances. regulation text in § 171.204. We deter connectivity or exchange with For example, we would not expect an interpret the definition of information blocking to include any fee that is likely competing technologies or services. actor to delay the implementation of a In the time since we published the to interfere with the access, exchange, or security measure in response to an Information Blocking Congressional use of EHI (see discussion in section emergency on the basis that it has not Report, these practices have persisted VIII.C.4.c.iv). We anticipate that this yet been able to initiate a fully realized and, in certain respects, become more interpretation may be broader than risk assessment process. However, we pronounced. In a national survey of HIE necessary to address genuine expect that in these exigent executives published in 2017, 47% of information blocking concerns and circumstances, where the actor has respondents reported that EHR could have unintended consequences implemented a security practice without developers ‘‘often/routinely’’ charge on innovation and competition. first considering whether there were high fees for exchange that are unrelated reasonable and appropriate alternatives Specifically, unless we establish an to cost, and another 40% reported that exception, actors may be unable to that were less likely to interfere with they ‘‘sometimes’’ do.124 Meanwhile, we access, exchange or use of EHI, the actor recover costs that they reasonably incur have continued to receive credible would expeditiously make any to develop technologies and provide evidence of rent-seeking and other necessary changes to the practice based services that enhance interoperability. opportunistic behaviors, such as fees for on the actor’s consideration of This could undermine the ultimate data export and data portability that are reasonable and appropriate alternatives goals of the information blocking not plausibly related to any reasonable that are less likely to interfere with provision by diminishing incentives to time, materials, or other costs that a access, exchange or use of EHI. We invest in, develop, and disseminate developer would reasonably incur to propose that the exception would apply interoperable technologies and services provide these services. And, while some in these instances so long as an actor that enable more robust access, practices described in the Information takes these steps and complies with all exchange, and use of EHI. Therefore, we Blocking Congressional Report have other applicable conditions. propose to establish an exception that become less prevalent (such as the would permit the recovery of certain We encourage comment on these charging of per-transaction fees), other costs that we believe are unlikely to practices have emerged that are equally conditions and our overall approach to present information blocking concerns this proposed exception, including concerning. and would generally promote As just one illustration, some EHR whether our proposal provides adequate innovation, competition, and consumer developers have begun conditioning flexibility for actors to implement welfare, provided certain conditions are access or use of customer EHI on measures that are commensurate to the met. We note that complying with the revenue-sharing or royalty agreements threats they face, the technology requirements of this exception would that bear no plausible relation to the infrastructure they possess, and their not prevent an actor from making a costs incurred by the EHR developer to overall security profiles and, equally profit in connection with the provision grant access to the EHI. We have also important, whether this exception of access, exchange, or use of EHI. heard of discriminatory pricing policies adequately mitigates the risk that actors Indeed, the costs recoverable under this that have the obvious purpose and effect will adopt security policies that are proposed exception could include a of excluding competitors from the use of unnecessarily restrictive or engage in reasonable profit, provided that all interoperability elements. Many of the practices that unreasonably interfere applicable conditions were met. industry stakeholders who shared their with access, exchange, or use of EHI. The exception would be subject to perspectives with us in listening Commenters are encouraged to propose strict conditions to prevent its potential sessions prior to this proposed rule, additional conditions that may be misuse. Specifically, we are concerned including several health IT developers necessary to ensure that the exception is that a broad or insufficiently tailored of certified health IT, condemned these tailored and does not extend protection exception for the recovery of costs could practices and urged us to swiftly to practices that are not reasonable and protect rent-seeking, opportunistic fees, address them. necessary to promote the security of EHI and exclusionary practices that interfere In light of these concerns, we propose and that could present information with the access, exchange, and use of that this exception would apply only to blocking concerns. We also seek EHI. These practices fall within the the recovery of certain costs and only comment on whether the use of definition of information blocking and when the actor’s methods for recovering consensus-based standards and reflect some of the most serious such costs comply with certain guidance provides an appropriate concerns that motivated its enactment conditions at all relevant times. As reference point for the development of (see section VIII.B of this preamble). For discussed in more detail below, these security policies. Finally, commenters example, in the Information Blocking conditions would require that the costs may wish to offer an alternative basis for Congressional Report, we cited evidence the actor recovered were reasonably identifying practices that do not offer a of wide variation in fees charged for security benefit (compared with health IT products and services. While 124 Julia Adler-Milstein and Eric Pfeifer, available alternatives) but that cause an we cautioned that the issue of fees is Information Blocking: Is It Occurring And What information blocking harm by nuanced, and that variations in fees Policy Strategies Can Address It?, 95 Milbank Quarterly 117, 124–25 (Mar. 2017), available at interfering with access, exchange, or use could be attributable in part to different http://onlinelibrary.wiley.com/doi/10.1111/1468- of EHI. technology architectures, service 0009.12247/full.

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00116 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7539

incurred and did not reflect costs that of technology in production required to provide services and incur are speculative or subjective. Actors environments, may vary based on the costs that are unique to a particular would also be required to allocate costs technology design or architecture, customer, it would not need to in an appropriate manner and to use individual customer needs, local distribute those costs among other objective and permissible criteria when implementation conditions, and other customers that had deployed charging fees to recover those costs. factors. An analysis of costs would also technology. Further, the exception would not apply account for different distribution and In addition, the exception would not to certain fees, such as those based on service models under which the costs apply if the method by which the actor the profit or revenue associated with the are calculated. We seek comment on recovers its costs is based, in any part, use of EHI (either being earned by the these and other considerations that may on whether the requestor or other actor, or that could be realized by be relevant to assessing the person is a competitor, potential another individual or entity) that exceed reasonableness of costs incurred for competitor, or will be using the EHI in the actor’s reasonable costs for purposes of this exception. providing access, exchange, or use of a way that facilitates competition with Method for Recovering Costs the EHI. We specify certain prohibited the actor. The use of such criteria would fees below. To qualify for the exception, we be suspect because it suggests the fee Finally, the exception would provide propose that the method by which the the actor is charging is not based on its additional conditions applicable to fees actor seeks to recover its costs must be reasonable costs to provide the services charged in connection with: (1) The reasonable and non-discriminatory. This and may have the purpose or effect of certified APIs described in § 170.404; would require that the actor base its excluding or creating impediments for and (2) the EHI export capability recovery of costs on objective and competitors, business rivals, or other proposed in § 170.315(b)(10) for the verifiable criteria that are uniformly persons engaged in developing or purposes of switching health IT or to applied for all substantially similar or enabling the use of interoperable provide patients their electronic health similarly situated classes of persons and technologies and services. information. We emphasize that access requests. We emphasize that this Last, we propose that the method by to EHI that is provisioned by supplying proposal does not mean that the actor which the actor recovers its costs must some form of physical media, such as must apply the same prices or price not be based on the sales, profit, paper copies (where the EHI is printed terms for all persons or classes of revenue, or other value that the out), or where EHI is copied onto a CD persons to whom it provides the requestor or other persons derive or may or flash-drive, would not be a practice services. However, any differences in derive from the access to, exchange of, that implicated the information blocking prices or price terms would have to be or use of electronic health information, provision provided that the fee(s) based on actual differences in the costs including the secondary use of such charged for that access complied with that the actor incurred or other information, that exceeds the actor’s HIPAA (45 CFR 164.524(c)(4)). reasonable and non-discriminatory reasonable costs for providing access, Our intention with this exception is criteria. We further propose to require exchange, or use of electronic health not to set any particular cost that would that the method by which the actor information. We emphasize that such be considered ‘‘reasonably incurred,’’ recovers its costs must be reasonably revenue-sharing or profit-sharing but rather to allow the market to define related to the actor’s costs of providing arrangements would only be acceptable the appropriate price so long as certain the type of access, exchange, or use to, and covered by the exception if such methods are followed and certain or at the request of, the person or entity arrangements are designed to provide an criteria are met. to whom the fee is charged. alternative way to recover the costs We also propose that the method by reasonably incurred for providing Requirement That Costs Be Reasonably which the actor recovers its costs must services. Incurred be reasonably allocated among all Regardless of the type of cost at issue, customers to whom the technology or We seek comment on these conditions a basic condition of this proposed service is supplied, or for whom the and other issues we should consider in exception is that any costs the actor technology is supported. A reasonable assessing whether the methodology by seeks to recover must have been allocation of costs would require that which an actor distributes costs and reasonably incurred to provide the the actor allocate its costs in accordance charges fees should be considered relevant interoperability elements to with criteria that are reasonable and reasonable and necessary for purposes enable access, exchange, or use of EHI. between only those customers that of this exception. In particular we are Ultimately, whether a cost was either cause the costs to be incurred or considering whether to introduce reasonably incurred will depend on the benefit from the associated supply or specific factors and methods for particular facts and circumstances. We support of the technology. If an actor assessing when profit will be believe this fact-based approach is developed technology that could be reasonable. For example, should the appropriate in light of the considerable supplied to multiple customers with pro-competitive or efficiency-adding diversity in the types of costs that actors minimal tailoring, the core costs of aspect of an actor’s approach to might incur and the range of factors that developing its technology should be providing access, exchange, or use of could bear on the reasonableness of allocated between those customers EHI be taken into account when those costs. For example, the costs of when recovered as a fee. The actor assessing the reasonableness of the developing software may vary with the would not be permitted to recover the profit recovered by an actor? We also purposes it is intended to serve, the total of its core costs from each ask commenters to consider whether settings in which it will be deployed, customer. Similarly, when an actor uses there are specific use cases for which the types and scope of capabilities shared facilities and resources to actors’ profits should be limited or included, and the extent to which these support the usage of technology, it prohibited. We request that commenters development efforts build on existing would need to ensure that those shared provide as much detail as possible when development efforts and know-how. costs were reasonably allocated between describing methods for quantifying Additionally, the costs of providing all of the customers that benefited from profits and evaluating their services, including the implementation them. However, whenever an actor is reasonableness.

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00117 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7540 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

Costs Specifically Excluded considered a ‘‘cost’’ in the sense that, recouping capital for data access, We propose that certain costs should were it not for the information blocking storage, or infrastructure; or other costs be explicitly excluded from this provision, the actor could charge a not listed above even if such costs are exception regardless of the method for royalty or other fee for the use of its authorized by state law. intangible assets. For this reason, in recovering the costs. We have proposed Individual Electronic Access section VIII.D.6, we propose to permit these excluded costs, which are detailed an actor to license most interoperability We propose that this exception would below, in an effort to provide additional elements on reasonable and non- not apply if the actor charged a fee clarity about the scope of this exception discriminatory terms, subject to certain based in any part on the electronic and to create guardrails for preventing conditions. For purposes of this more access by an individual or their personal potential misuse of the exception. general exception, however, we believe representative, agent, or designee to the Costs Due to Non-Standard Design or it would be inappropriate to permit an individual’s EHI. Such fees are Implementation Choices actor to charge a fee based on these distinguished from the cost-based fees considerations, which are inherently that a covered entity is permitted to We propose that this exception would charge individuals for the provision of not permit the recovery of any cost that subjective and could invite the kinds of rent-seeking and opportunistic pricing copies of ePHI under HIPAA (45 CFR the actor incurred due to the health IT practices that fall squarely within the 164.524(c)(4)), and similar allowable being designed or implemented in non- definition of information blocking. We costs under state privacy laws, which standard ways that unnecessarily clarify that an actor’s practices could would not be excluded from the costs increase the complexity, difficulty or qualify for both this exception recoverable under this exception. To be burden of accessing, exchanging, or (recovering costs reasonably incurred) clear, access to EHI that is provisioned using EHI. To the extent that such costs and the exception for licensing of by supplying some form of physical can be reasonably avoided, we believe interoperability elements on reasonable media, such as paper copies (where the that actors should internalize the costs and non-discriminatory terms in section EHI is printed out), or where EHI is of such behaviors, which do not benefit VIII.D.6. In that case, the actor could copied onto a CD or flash-drive, would consumers, and which create recover costs under both exceptions. not be a practice that implicated the unnecessary impediments to access, Second, and for similar reasons, an information blocking provision exchange, and use of EHI. As an actor would not be permitted to recover provided that the fee(s) charged for that illustration, if a health IT developer of costs that are speculative. The exception access complied with HIPAA (45 CFR certified health IT designed its database would not apply to ‘‘opportunity costs,’’ 164.524(c)(4)). tables or other aspects of its technology such as the revenues that an actor could A fee based on electronic access by an in ways that make exporting or have earned had it not provided the individual or their personal converting EHI to other formats interoperability elements. We clarify representative, agent, or designee to the difficult, the developer could not claim that the exclusion of opportunity costs individual’s EHI, in contrast, would that its costs to provide data conversion would not preclude an actor from arise if an actor sought to impose on services to customers are reasonably recovering its reasonable forward- individuals, or their personal incurred. Such costs would not be looking cost of capital. We believe these representatives, agents, or designees, a eligible under this exception (and might costs are relatively concrete and that fee that operated as a toll for the implicate the information blocking permitting their recovery will protect provision of electronic access. For provision for the reasons noted in incentives for actors to invest in example, a health care provider that section VIII.C.4.c.v of this preamble). developing and providing charges individuals a fee in order that We welcome comments on the interoperability elements. the individuals be given access to their exclusion of these types of costs. EHI via the health care provider’s Fee Prohibited by 45 CFR 164.524(c)(4) Subjective or Speculative Costs patient portal or another mode of web- We also propose that the exception based delivery, would not be able to We propose to limit this exception to would not apply to fees prohibited by benefit from this exception. Similarly, the recovery of costs that an actor 45 CFR 164.524(c)(4). The HIPAA where an individual authorizes a actually incurred to provide the relevant Privacy Rule permits a covered entity to consumer-facing app to retrieve EHI on interoperability element or group of impose a reasonable, cost-based fee if the individual’s behalf, it would be elements (which may comprise either the individual requests a copy of the impermissible for an actor to charge the products or services). We propose that PHI (or agrees to receive a summary or app or its developer a fee to access or this exception would not permit the explanation of the information). The fee use APIs that enable access to the recovery of certain types of costs that may include only the cost of: (1) Labor individual’s EHI. This would be true are subjective or speculative. We note for copying the PHI requested by the whether the actor is a supplier of the two important examples of this individual, whether in paper or API technology or an individual or limitation. electronic form; (2) supplies for creating entity that has deployed the API First, an actor would not be permitted the paper copy or electronic media (e.g., technology, such as a health care to recover any costs associated with CD or USB drive) if the individual provider. intangible assets (including depreciation requests that the electronic copy be or loss of value), other than the actual provided on portable media; (3) postage, Export and Portability of EHI development or acquisition costs of when the individual requests that the Maintained in EHR Systems such assets. For example, an actor could copy, or the summary or explanation, be The definition of information not charge a customer a fee based on the mailed; and (4) preparation of an blocking specifically mentions purported ‘‘cost’’ of allowing the explanation or summary of the PHI, if transitions between health IT systems customer to use the actor’s patented agreed to by the individual (45 CFR and the export of complete information technology, computer software, 164.524(c)(4)). The fee may not include sets as protected forms of access, databases, trade secrets, copyrighted costs associated with verification; exchange, and use (see section works, and the like. We understand that documentation; searching for and 3022(a)(2)(C)(i) of the PHSA). In our the customer’s use of the asset could be retrieving the PHI; maintaining systems; experience, health care providers

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00118 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7541

frequently encounter rent-seeking and production environment, or to provide Certification must comply with all opportunistic pricing practices in these additional services in connection with requirements of that condition for all and other contexts in which they are this capability other than those practices and at all relevant times in attempting to export EHI from their reasonably necessary to enable its order to qualify for this exception. systems for use in connection with other intended use. For example, this We also believe that a health care technologies or services that compete condition would not preclude a provider that acts as an API Data with or could reduce the revenue developer from charging a fee to Provider, should be subject to the same opportunities associated with an EHR perform an export of EHI via the developer’s own suite of products and capability of health IT certified to the constraints. For example, the API services. As discussed in section proposed § 170.315(b)(10) for a third- Condition of Certification prohibits a VIII.C.5.b.iii of this preamble, most EHI party analytics company. We emphasize health IT developer from charging a is currently maintained in EHRs and once again that these excluded fees are usage fee to patient-oriented apps. We other source systems that use distinguished from the cost-based fees believe information blocking concerns proprietary data models or formats; this that a covered entity is permitted to would arise if a provider were to charge puts EHR developers in a unique charge individuals for the provision of such a fee, notwithstanding the fact that position to block the export and copies of ePHI under HIPAA (45 CFR the provider is not subject to the portability of EHI for use in competing 164.524(c)(4)), and similar allowable certification requirements. For this systems or applications, or to charge costs under state privacy laws, which reason, we propose that, if the actor is rents for access to the basic technical would not be excluded from the costs an API Data Provider, the actor is only information needed to facilitate the recoverable under this exception. permitted to charge the same fees that conversion or migration of data for these We note that, because this an API Technology Supplier is purposes. The concerns are certification criterion provides only a permitted to charge to recover costs compounded by the fact that EHR baseline capability for exporting data, consistent with the permitted fees developers rarely disclose in advance we anticipate that health IT developers specified in the Condition of the fees they will charge for data export of certified health IT will need to Certification in § 170.404. In other and data portability services (see 80 FR provide other data portability services to words, to the extent that a provider is 62719; 80 FR 16880–81). facilitate the smooth transition of health an API Data Provider, the provider will For the reasons above, we propose care providers between different health not qualify for this exception if it that fees charged for the export, IT systems. We propose that such fees charges any fee that a health IT conversion, or migration of data from an may qualify for protection under the developer of certified health IT would EHR technology would not qualify for exception, but only if they meet the be prohibited from charging under the the exception unless they also meet two other conditions described above and in API Condition of Certification. additional conditions. proposed § 171.205(a). First, we propose that health IT Second, we propose that the Application of the Exception to developers of certified health IT would, exception would not apply to a fee to Individual Practices for purposes of this exception, be export or convert data from an EHR precluded from charging a fee to technology unless such fee was agreed We clarify that the conditions of this perform an export of EHI via the to in writing at the time the technology exception, including those governing capability of health IT certified to the was acquired, meaning when the EHR the methodology and criteria by which proposed 2015 Edition ‘‘EHI export’’ developer and the customer entered into an actor calculates and distributes its certification criterion (§ 170.315(b)(10)) a contract or license agreement for the costs, must be satisfied for each and for the purposes of switching health IT EHR technology. This condition is every fee that an actor charges to a systems or to provide patients their EHI. designed to promote the disclosure of customer, requestor, or other person. As part of the ‘‘Assurances’’ Condition fees upfront and thereby reduce the For example, if an actor uses a cost of Certification, health IT developers potential for actors to engage in allocation methodology that does not that produce and electronically manage installed-base opportunism or meet the requirements of the exception, EHI would need to be certified to the attempting to use fees to discourage data each fee charged on the basis of that ‘‘EHI export’’ criterion and provider the portability. methodology would be a suspect functionality to its customers (see Compliance With the Condition of practice under the information blocking § 170.402(a)(4) and section VII.B.2.b of Certification Specific to API Technology provision. All applicable conditions of this preamble). As described in section Suppliers and API Data Providers the exception must be met at all relevant IV.C.1 of this preamble, the ‘‘EHI times for each practice. export’’ certification criterion is We note that health IT developers of intended to provide a baseline certified health IT subject to the API We request comment on this proposed capability to export EHI from certified Condition of Certification proposed in exception. Specifically, we ask health IT in a commercially reasonable § 170.404 may not charge certain types commenters to consider alternate format in support of transitioning of EHI of fees and are subject to more specific approaches to the exception that would between health IT systems and patient cost accountability provisions than also achieve the goal of allowing actors access. Fees or limitations associated apply generally under this proposed to recover certain types of costs that with the use of this capability (as exception. We believe that the failure of would promote innovation, competition distinguished from deployment or other developers to comply with these and consumer welfare and that are costs reasonably incurred by the additional requirements would impose unlikely to present information blocking developer) would not receive protection impediments to consumer and other concerns. In assessing other potential under the exception and may be suspect stakeholder access to EHI without approaches to this exception, we under the information blocking special effort and would be suspect encourage commenters to contemplate provision. We clarify that this condition under the information blocking such considerations as enforceability, would not preclude a developer from provision. We propose, therefore, that a potential burden on the parties, and charging a fee to deploy the EHI export health IT developer of certified health overall effectiveness in meeting the capability in a health care provider’s IT subject to the API Condition of above stated goals.

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00119 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7542 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

5. Responding To Requests That are defined circumstances when doing so encourage commenters to be as detailed Infeasible would be infeasible (or impossible) and and specific as possible. We propose to establish an exception when the actor otherwise did all that it In determining whether these or other to the information blocking provision reasonably could do under the types of burdens are substantial, we would consider the actor’s particular that would permit an actor to decline to circumstances to facilitate alternative circumstances, including the type of provide access, exchange, or use of EHI means of accessing, exchanging, and actor; the nature and purpose of its in a manner that is infeasible, provided using the EHI. We believe this approach business or other activities; and the certain conditions are met. The is principled and tailored in a manner financial, technical, and other resources exception and corresponding conditions that will promote basic fairness and and expertise at its disposal. In are set forth in the proposed regulation encourage parties to work cooperatively addition, we would also consider any text in § 171.205. We propose that this to implement efficient solutions to offsetting benefits to the actor of exception would not apply when a interoperability challenges. Importantly, providing the requested access, response is required by law. As to ensure that the exception is not used inappropriately, we propose a exchange, or use, such as facilitating the discussed in section VIII.C.5 of this actor’s compliance with statutory and preamble, we propose that the structured, fact-based approach for determining whether a request was in regulatory requirements. Due to the information blocking provision would variability of circumstances, ONC be implicated if an actor were to refuse fact ‘‘infeasible’’ within the meaning of this exception. This approach would be would take a fact-specific approach to to facilitate access, exchange, or use of these analyses. EHI, either as a general practice or in limited to a consideration of factors specifically delineated in the exception As an illustration, a small physician isolated instances. However, we believe practice with limited financial and that in certain circumstances legitimate and that focus the infeasibility inquiry on the immediate and direct financial technical resources may find it practical challenges beyond an actor’s burdensome to accommodate requests control may limit its ability to comply and operational challenges of facilitating access, exchange, and use, as from other providers to establish and with requests for access, exchange, or maintain outbound interfaces from the use. In some cases, the actor may not distinguished from more remote, indirect, or speculative types of injuries. practice’s EHR system that it neither have—and may be unable to obtain—the needs for its own health care activities requisite technological capabilities, We encourage comment on these and nor to comply with any regulatory legal rights, financial resources, or other other aspects of this proposal, which are requirements. In contrast, a large health means necessary to provide a particular described in more detail below. system with a well-resourced IT form of access, exchange, or use. In i. Infeasibility of Request department may be in a position to other cases, the actor may be able to accommodate such requests without comply with the request, but only by To qualify for this proposed significant disruption to its business incurring costs or other burdens that are exception, in addition to meeting other and at relatively minimal additional clearly unreasonable under the conditions, we propose that compliance expense relative to its overall IT budget. circumstances. with the request for access, exchange, or Similarly, custom development or other Actors confronted with these types of use must be infeasible. We propose a activities that might be burdensome for practical challenges may be concerned two-step test that an actor would need a health care provider with limited about their exposure under the to meet in order to demonstrate that a technical expertise may not result in a information blocking provision, which request was infeasible. substantial burden for a health IT could lead to inefficient outcomes. For Complying With the Request Would developer, exchange, or network whose example, health care providers may feel Impose a Substantial Burden on the business is to develop and provide compelled to entertain requests to Actor technological solutions. enable or support means of exchange or We clarify that the exception focuses use that would be disruptive to health Under the first step of the infeasibility solely on the immediate and direct care operations or that are not test, the actor would need to show that financial and operational challenges of financially sustainable. In some of these complying with the particular request in facilitating access, exchange, or use. The instances, the actor may be able, but the manner requested would impose a exception does not apply—and we reluctant, to offer alternative means that substantial burden on the actor that is would give no weight—to any putative would meet the requestor’s needs while unreasonable under the circumstances. burdens that an actor experiences that reducing the burden on the actor, We anticipate that in most cases an relate primarily to the actor’s pursuit of leading to more efficient outcomes actor would meet this requirement by an economic advantage, such as its overall. Actors could also be forced into showing that it did not have, and could ability to charge higher prices, capture a ‘‘reactive’’ posture that limits their not readily obtain, the requisite additional revenue streams, maintain or ability to make holistic decisions and to technological capabilities, legal rights, increase its market share, or otherwise implement health IT in a considered, or other means necessary to facilitate pursue its own economic interests. To scalable way that facilitates robust the particular type of access, exchange, the extent that these interests merit an interoperability and information or use requested. Additionally, the exception under the information sharing. These outcomes would be requirement could be met by showing blocking provision, they are addressed counterproductive to the policies the that, had it complied with the request, under the exceptions proposed in information blocking provision the actor would have experienced a §§ 171.204 and 171.206. In the same encompasses. significant disruption to its health care way, the exception would not apply to The proposed exception would or business activities or would have any putative burdens that are more alleviate some of these concerns while incurred significant unbudgeted costs. appropriately examined under another safeguarding against pretextual and We would also consider other analogous proposed exception. For example, an other unreasonable refusals to provide outcomes that impact the actor’s health actor could not claim that it is access, exchange, or use of EHI. The care or business activities in a direct burdensome to implement a tailored exception would permit an actor to and substantial way. We seek comment organizational patient safety policy decline a request in certain narrowly- on what those outcomes might be and under proposed § 171.201(b) or to

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00120 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7543

develop and implement policies and this preamble, certain types of EHI— impose only a minimal burden on the procedures for satisfying preconditions namely, observational health requestor and other persons’ use of the imposed by state or federal privacy laws information—give rise to a heightened EHI. In contrast, if the actor conditions for the provision of access, exchange, or risk of interference under the critical technology or infrastructure for use of EHI under proposed § 171.202(b). information blocking provision. For accessing, exchanging, or using EHI, or purposes of this exception and the if its control over other interoperability The Burden Imposed on the Actor information blocking provision more elements means that EHI cannot be Would Be Plainly Unreasonable Under generally, the actor has a strong duty to efficiently accessed, exchanged, or used the Circumstances facilitate the availability and use of this without the actor’s cooperation, To show that a request for access, information, which may be needed for requiring the requestor to pursue other exchange, or use was infeasible, the important activities for which timely means of access, exchange, or use would actor must not only demonstrate that and complete access to EHI is essential, likely be unrealistic and represent an complying with the request would have such as providing patients with their insurmountable burden. resulted in a substantial burden, as EHI; enabling the use of EHI for One final consideration would inform described above; the actor must also treatment and care coordination; and our analysis. We would consider the demonstrate that requiring it to comply making EHI available for quality balancing of relative burdens in with the request—and thus to assume improvement and population health conjunction with the actor’s control the substantial burden demonstrated management activities. over interoperability elements. As an under the first part of the test—would Next, we would consider the severity example, a dominant health IT have been plainly unreasonable under of the burdens that the actor would have developer of certified health IT or the circumstances. Whether it would experienced to provide the access, network that refuses to facilitate a have been plainly unreasonable for the exchange, or use of EHI in the manner particular form of access, exchange, or actor to assume the burden of providing requested. For this purpose, we would use with other entities would have to access, exchange, or use will be highly consider both the burden on the actor of demonstrate an extreme burden relative dependent on the particular facts and complying with the specific request at to the need for access, exchange, or use circumstances. While for this reason we issue as well as the burden the actor in order to qualify for this exception. do not believe that bright-line rules would experience if it was required to This exacting standard would also apply would be appropriate, we do propose to comply with similar types of requests. in other circumstances of dependence or rely primarily on the following key We would also consider the observed or reliance on the actor to facilitate access, factors enumerated in proposed likely frequency of such requests. As exchange, or use. For example, a § 171.205(a)(1): already discussed, we anticipate that the dominant health system that provides • The type of EHI and the purposes extent of any burden would depend in local health IT infrastructure would for which it may be needed; part on the particular circumstances of have to demonstrate an extreme • The cost to the actor of complying the actor. In addition, in considering the hardship to justify denying with the request in the manner burden to the actor, we would also interconnection requests or access to requested; consider any offsetting benefits to the interoperability elements. Likewise, • The financial, technical, and other actor of providing the requested access, where the actor is a business associate resources available to the actor; exchange, or use. of a covered entity, or owes some other • Whether the actor provides Having ascertained the nature and special duty to the requestor, the actor comparable access, exchange, or use to severity of any burdens that the actor could not qualify for this exception itself or to its customers, suppliers, would assume to provide the requested unless the cost or burden it would have partners, and other persons with whom access, exchange, or use, we would borne was so extreme in comparison to it has a business relationship; balance these burdens against the the marginal benefits to the requestor • Whether the actor owns or has countervailing costs to the requestor and that the request was clearly control over a predominant technology, other persons (including consumers) unreasonable by any objective measure. platform, health information exchange, who would be harmed by the actor’s We acknowledge that there may be or health information network through refusal to provide the requested access, situations when complying with a which EHI is accessed or exchanged; exchange, or use. Importantly, we request for access, exchange, or use • Whether the actor maintains ePHI would consider whether the requestor would be considered infeasible because on behalf of a covered entity, as defined and other persons could have obtained an actor is unable to provide such in 45 CFR 160.103, or maintains EHI on the EHI from other sources or through access, exchange, or use due to behalf of the requestor or another person other means, including those made unforeseeable or unavoidable whose access, exchange, or use of EHI available by the actor as an circumstances that are outside the will be enabled or facilitated by the accommodation to the requestor, as actor’s control. For example, an actor actor’s compliance with the request; discussed in more detail below. If could seek coverage under this • Whether the requestor and other alternative means were available, we exception if it is unable to provide relevant persons can reasonably access, would examine the extent to which they access, exchange, or use of EHI due to exchange, or use the information from would have been appropriate for the a natural disaster (such as a hurricane, other sources or through other means; purposes for which the EHI or tornado or earthquake) or war. These are and interoperability elements were needed just a couple examples of such • The additional cost and burden to and the extent to which requiring the circumstances and are by no means an the requestor and other relevant persons requestor to pursue these alternative exhaustive list. of relying on alternative means of means would impose additional costs or We emphasize that, consistent with access, exchange, or use. burdens on the requestor and other the requirements for demonstrating that As these factors suggest, the starting persons. For example, if the EHI was activities and practices meet the point for our inquiry would be to readily available through other means conditions of an exception proposed in identify the type of EHI at issue and the that were equally efficacious, the actor’s section VIII.C.6.c of this preamble, the purposes for which it may be needed. refusal to provide yet one more means actor would need to produce evidence As explained in section VIII.C.5.b.i. of of access, exchange, or use might and ultimately prove that complying

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00121 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7544 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

with the request for access, exchange, or Finally, the actor must have worked improvements we could make to the use in the manner requested would have with the requesting party in a timely proposed process. imposed a clearly unreasonable burden manner to identify and provide a 6. Licensing of Interoperability Elements on the actor under the circumstances. reasonable alternative means of on Reasonable and Non-Discriminatory We note that there are certain accessing, exchanging, or using the EHI, Terms circumstances that we propose would as applicable. The actor’s failure to meet not constitute a burden to the actor for any of these conditions would We propose to establish an exception purposes of this exception and shall not disqualify the actor from the exception to the information blocking provision be considered in determining whether and could also be evidence that the that would permit actors to license complying with a request would have actor knew that it was engaging in interoperability elements on reasonable been infeasible. We propose that it practices that contravened the and non-discriminatory (RAND) terms, would not be considered a burden if information blocking provision. provided that certain conditions are providing the requested access, We clarify that the duty to timely met. The exception and corresponding exchange, or use in the manner respond and provide reasonable conditions are set forth in the proposed requested would have (1) facilitated cooperation would necessarily be regulation text in § 171.206. As competition with the actor; or (2) assessed from the standpoint of what is discussed in section VIII.C.5.a of this prevented the actor from charging a fee. objectively reasonable for an individual preamble, the information blocking Throughout this proposed rule, we have or entity in the actor’s position. For provision would be implicated if an highlighted that one of the goals of the example, we would not expect a small actor were to refuse to license or allow information blocking section is to physician practice to provide the same the disclosure of interoperability promote competition, and allowing the level of engagement and technical elements to persons who require those argument that a request is infeasible assistance to third parties as a large elements to develop and provide because it facilitates competition with hospital or health system with interoperable technologies or services— the actor would be antithetical to this considerable health IT resources and including those that might complement goal. Similarly, an argument that a expertise at its disposal. In some or compete with the actor’s own request is infeasible because it prevents circumstances, it may even be difficult technology or services. Moreover, the the actor from charging a fee would also for a small practice to comply with any information blocking provision would be outside the scope of this exception request for access, exchange, and use be implicated if the actor licensed such because such a result would not that is more complicated than a simple interoperability elements subject to constitute a substantial, unreasonable request for a patient’s personal health terms or conditions that have the burden that this exception seeks to information. If there are such requests— purpose or effect of excluding or address. and there could be—then small discouraging competitors, rivals, or We request comment on the practices may be both unable to comply other persons from engaging in these structured, fact-based approach we have with such requests and poorly situated pro-competitive and interoperability- proposed for determining whether a to assist requesting parties with enhancing activities. Thus, this request was in fact ‘‘infeasible’’ within alternatives. We provide these examples licensing requirement would apply in the meaning of this exception. We to emphasize that we will look at the both vertical and horizontal encourage comment on, among other specific facts and circumstances of each relationships. For instance, it would issues, whether the factors we have case to determine what is objectively apply when a developer in a vertical specifically delineated above properly reasonable. relationship to the actor—a network in focus the infeasibility inquiry; whether We believe that these conditions will this example—wants to use our approach to weighing these factors minimize the risk that this exception interoperability elements in order to is appropriate; and whether there are could protect improper refusals to access the EHI maintained in the actor’s additional burdens, distinct from the provide interoperability elements, network. The requirement would also immediate and direct financial and including naked refusals to deal as well apply when a rival network in a operational challenges contemplated as other practices, such as improper horizontal relationship to the actor above, that are similarly concrete and delays in access or exchange that would (network) wants to use interoperability should be considered under the fact- present information blocking concerns. elements so that its network can be based rubric of this exception. Additionally, the requirements for an compatible with the applications that actor to timely respond and document have already been developed for use ii. Duty to Timely Respond and Provide its justifications for declining a request with the actor’s network. Reasonable Cooperation in writing would prevent an actor from We note that some licensees do not In addition to demonstrating that a using post hoc rationalizations to justify require the interoperability elements to particular request or class of requests these and other improper practices. develop products or services that can be was infeasible, we propose that an actor Finally, we believe that establishing a interoperable with the actor’s health IT. would have to show that it satisfied clear duty under the exception for actors For instance, there may be firms that several additional conditions. to deal on reasonable terms with parties simply want to license the actor’s Specifically, to qualify for this seeking to access, exchange, or use EHI technology for use in developing their exception, the actor must have timely will encourage parties to cooperate to own interoperability elements. Their responded to all requests relating to identify and implement efficient interest would be for access to the access, exchange, and use of EHI, solutions to interoperability challenges, technology itself—not for the use of the including but not limited to requests to thereby avoiding disputes that could technology to interoperate with either establish connections and to provide lead to information blocking. the actor or its customers. This may be interoperability elements. Further, for We encourage comment on the the case, for example, if the relevant any request that the actor claims was additional conditions and related intellectual property included patents infeasible, the actor must have provided considerations described above. that were applicable to other the requestor with a detailed written Specifically, we request comment information technology applications explanation of the reasons why the actor regarding potential obstacles to outside of health IT. In such cases, the could not accommodate the request. satisfying these conditions and actor’s licensing of its patents in such a

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00122 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7545

context would not implicate the their innovations and earn returns on i. Reasonable and Non-Discriminatory information blocking provision. the investments they have made to (RAND) Terms Below are examples of situations that develop, maintain, and update those would implicate the information We propose to require, as a condition innovations. This in turn will protect of this exception, that any terms upon blocking provision (these examples are future incentives to invest in, develop, not exhaustive): which an actor licenses interoperability • and disseminate interoperable elements must be reasonable and non- An actor refuses to negotiate a technologies and services. Conversely, if license after receiving a request from a discriminatory (RAND). As discussed actors cannot (or believe they cannot) developer. below, commitments to license • An actor offers a license at the protect and commercialize their technology on RAND terms are request of a developer, but only at a innovations, they may not engage in frequently required in the context of royalty rate that exceeds a RAND rate. these productive activities that improve standards development organizations • An actor offers a license to a access, exchange, and use of EHI. (SDOs), and we believe that the competitor at a royalty rate significantly While we believe this exception is practical and policy considerations that higher than was offered to a party not necessary to promote competition and have led SDOs to adopt these policies in direct competition with the actor. are related in many respects to the • consumer welfare, we are highly An actor files a patent infringement sensitive to the danger that actors will information blocking concerns presented when an actor exploits lawsuit against a developer without first continue to use their contractual and IP offering to negotiate a license on RAND control over interoperability elements to rights to interfere with access, exchange, terms. extract economic rents or impede the and use of EHI, undermining the There are compelling reasons for this development or use of interoperable prohibition. In our experience, information blocking provision’s technologies and services. contractual and intellectual property fundamental objectives. For this reason, We recognize that strong legal rights are frequently used to extract the exception would be subject to strict protections for IP rights can promote rents for access to EHI or to prevent conditions to ensure, among other competition and innovation.125 competition from developers of things, that actors license Nevertheless, IP rights can also be interoperable technologies and services interoperability elements on RAND misused in ways that undermine these (see section VIII.C.5.c.iv. of this terms and that they do not impose goals.126 We believe this potential for preamble). These practices frustrate collateral terms or engage in other abuse is heightened when the IP rights access, exchange, and use of EHI and practices that would impede the use of pertain to functional aspects of stifle competition and innovation in the the interoperability elements or technology that are essential to enabling health IT sector. As a case in point, even otherwise undermine the intent of this interoperability. As an important following the enactment of the Cures exception. example, a technology developer may Act, some EHR developers are We acknowledge that preventing encourage the inclusion of its selectively prohibiting—whether intellectual property holders from technology in an industry standard expressly or through commercially created by an SDO while not disclosing unreasonable terms—the disclosure or extracting rents for access to EHI may differ from standard intellectual that it has IP rights in that technology. use of technical interoperability After the SDO incorporates the property policy. Absent specific information required for third-party technology into its standard, and circumstances, IP holders are generally applications to be able to access, industry begins to make investments exchange, and use EHI maintained in free to negotiate with prospective tied to the standard, the IP-holder may EHR systems. This limits health care licensees to determine the royalty to then assert its IP rights and demand providers’ use of the EHI maintained on practice their IP, and this negotiated royalties or license terms that it could their behalf to the particular capabilities royalty frequently reflects the value the not have achieved before the standard and use cases that their EHR developer licensee would obtain from exercising was adopted because companies would happens to support. More than this, by those rights. However, in the context of incur substantial switching costs to limiting the ability of providers to EHI, we propose that a limitation on abandon initial designs or adopt choose what applications and rents is essential due to the likelihood different products.127 To address these technologies they can use with their that rents will frustrate access, EHR systems, these practices close off exchange, and use of EHI, particularly 125 See FTC and DOJ Antitrust Guidelines for the the market to innovative applications because of the power dynamics that Licensing of Intellectual Property, at 2 (2017), and services that providers and other exist in the health IT market. https://www.ftc.gov/system/files/documents/ stakeholders need to deliver greater public_statements/1049793/ip_guidelines_ We remind readers that actors are not 2017.pdf. value and choice to health care required to seek the protection of this 126 See Assessment Techs. of WI, LLC v. purchasers and consumers. (or any other) exception. If an actor does WIREdata, Inc., 350 F.3d 640, 644–45 (7th Cir. Despite these serious concerns, we 2003); Sega Enterprises Ltd. v. Accolade, Inc., 977 recognize that the definition of not want to license a particular F.2d 1510, 1520–28 (9th Cir. 1992); Sony Computer information blocking may be broader technology, it may choose to comply Entertainment, Inc. v. Connectix Corp., 203 F.3d with the information blocking provision 596, 602–08 (9th Cir. 2000); Bateman v. than necessary and could have Mnemonics, Inc., 79 F.3d 1532, 1539–40 n. 18 (11th unintended consequences. In contrast to in another way, such as by developing Cir. 1996); Atari Games Corp. v. Nintendo of the practices described above, we and providing alternative means of America, Inc., 975 F.2d 832, 842–44 (Fed. Cir. believe it is generally appropriate for accessing, exchanging, and using EHI 1992). that are similarly efficient and 127 See DOJ and FTC, Antitrust Enforcement and actors to license their intellectual Intellectual Property Rights: Promoting Innovation property (IP) on RAND terms that do not efficacious. The purpose of this and Competition, at 37–40 (Apr. 2017), https:// block interoperability. Provided certain exception is not to dictate a licensing www.ftc.gov/sites/default/files/documents/reports/ conditions are met, we believe that scheme for all, or even most, health IT, antitrust-enforcement-and-intellectual-property- but rather to provide a tailored ‘‘safe rights-promoting-innovation-and-competition- these practices would further the goals report.s.department-justice-and-federal-trade- of the information blocking provision by harbor’’ that will provide clear commission/p040101promotinginnovationand allowing actors to protect the value of expectations for those who desire it. competitionrpt0704.pdf.

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00123 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7546 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

types of concerns, while balancing the with this condition, any terms or However, there could be other situations legitimate interests and incentives of IP conditions under which the actor when the requestor and actor each make owners, many SDOs now have policies discloses or allows the use of counteroffers, which would extend the requiring members who contribute interoperability elements must meet negotiations. technologies to a standard to voluntarily several requirements set forth below. We request comment on whether 10 commit to license that technology on These requirements apply to both price business days is an appropriate amount RAND terms and will consider whether terms (such as royalties and license fees) of time for the actor to respond to the firms have made voluntary RAND and other terms, such as conditions or requestor. In proposing this timeframe, commitments when weighing whether limitations on access to interoperability we considered the urgency of certain to include their technology in elements or the purposes for which they requests to license interoperability standards.128 While this commitment to can be used. elements and our expectation that license on RAND terms is voluntary as developers would have standard Responding To Requests compared to our proposed requirement licenses at their disposal that could be to use RAND terms, it serves to illustrate We propose that, upon receiving a adapted in these situations. We how RAND terms can be used to address request to license or use interoperability considered proposing response such concerns. elements, an actor would be required to timeframes ranging from 5 business Similar concerns arise when actors respond to the requestor within 10 days to 15 business days. We also who control proprietary interoperability business days from receipt of the considered proposing two separate elements demand royalties or license request. We note that the request could timeframes for: (1) Negotiating with the terms from competitors or other persons be made to ‘‘license’’ or ‘‘use’’ the requestor; and (2) offering the license. If who are technologically dependent on interoperability elements because a commenters prefer a different response the use of those interoperability requestor may not always know that timeframe or approach than proposed, elements. As discussed in section ‘‘license’’ is the legal mechanism for we request that commenters explain VIII.C.5 of this preamble, to the extent ‘‘use’’ when making the request. This their rationale with as much detail as that the interoperability elements are provision is intended to ensure that a possible. essential to enable the efficient access, requestor is given an opportunity to In addition, we query whether we exchange, or use of EHI by particular license and use interoperability should create set limits for: (1) The persons or for particular purposes, any elements. As such, the requirement for amount of time the requestor has to practice by the actor that could impede responding to requests should not be accept the actor’s initial offer or make a the use of the interoperability elements limited to requests to ‘‘license.’’ counteroffer; (2) if the requestor makes for that purpose—or that could In order to meet this requirement, the a counteroffer, the amount of time the unnecessarily increase the cost or other actor would be required to respond to actor has to accept the requestor’s burden of using the elements for that the requestor within 10 business days counteroffer or make its own purpose—would give rise to an obvious from the receipt of the request by: (1) counteroffer; and (3) an allowable risk of interference with access, Negotiating with the requestor in a number of counteroffers in negotiations. RAND fashion to identify the exchange, or use of EHI under the Scope of Rights information blocking provision. interoperability elements that are We believe that a RAND requirement needed; and (2) offering an appropriate To qualify for this proposed would balance the need for robust IP license with RAND terms, consistent exception, we propose that the actor protections with the need to ensure that with its other obligations under this must license the requested this proposed exception does not permit exception. We emphasize that, in order interoperability elements with all rights actors to exercise their IP or other to qualify for this proposed exception, necessary to access and use the proprietary rights in inappropriate ways the actor is only required to negotiate interoperability elements for the with the requestor in a RAND fashion following purposes, as applicable: that block the development, adoption, • or use of interoperable technologies and and to offer a license with RAND terms. All rights necessary to access and services. The exercise of IP rights in The actor is not required to grant a use the interoperability elements for the these ways is incompatible with the license in all instances. For example, purpose of developing products or information blocking provision, which the actor would not be required to grant services that are interoperable with the protects the investments that taxpayers a license if the requestor refuses an actor’s health IT or with health IT under and the health care industry have made actor’s offer to license interoperability the actor’s control and/or any third to adopt technologies that will enable elements on RAND terms. party who currently uses the actor’s We emphasize that there would be the efficient sharing of EHI to benefit interoperability elements to interoperate circumstances under which the actor consumers and the health care system. with the actor’s health IT or health IT could pursue legal action against parties While actors are entitled to protect and under the actor’s control. These rights that infringe its intellectual property exercise their IP rights, to benefit from would include the right to incorporate whilst complying with this exception. this exception to the information and use the interoperability elements in For instance, an actor could bring legal blocking provision they must do so in the licensee’s own technology to the action if a firm appropriates the actor’s a reasonable and non-discriminatory extent necessary to accomplish this intellectual property without requesting manner that does not undermine these purpose. a license or after refusing to accept a • All rights necessary to market, offer, efforts and impede the appropriate flow license on RAND terms. and distribute the interoperable of EHI. We do not propose a set timeframe for Accordingly, we propose that, to products and services described above when the negotiations must be resolved qualify for this exception, an actor must to potential customers and users, because it is difficult to predict the license requested interoperability including the right to copy or disclose duration of such negotiations. For elements on RAND terms. To comply the interoperability elements as instance, there could be situations when necessary to accomplish this purpose. • All rights necessary to enable the 128 See, e.g., Microsoft Corp. v. Motorola, Inc., No. the actor and requestor meet once and C10–1823JLR, 2013 WL 2111217, at *6 (W.D. Wash. the actor makes a RAND offer that is use of the interoperable products or Apr. 25, 2013). immediately accepted by the requestor. services in production environments,

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00124 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7547

including using the interoperability contrary to the goals of the information Ventures, LLC Patent Litig.; 132 and elements to access and enable the blocking provision. Realtek Semiconductor Corp. v. LSI exchange and use of electronic health In evaluating the actor’s assertions Corp 133). However, we have adapted the information. and evidence that the royalty was factors to the information blocking We request comment on whether reasonable, we propose that ONC may context as follows. In the SDO context, these rights are sufficiently inclusive to consider the following factors: the RAND requirement mitigates the support licensees in developing • The royalties received by the actor risk that patent-holders will engage in interoperable technologies, bringing for the licensing of the proprietary ‘‘hold up’’—that is, charging excessive them to market, and deploying them for elements in other circumstances royalties that do not reflect the value of use in production environments. We comparable to RAND-licensing their contributions to the standard, but also request comment on the breadth of circumstances. rather reflect the costs associated with • these required rights and if they should The rates paid by the licensee for switching to alternative technologies be subject to any limitations that would the use of other comparable proprietary after a standard is adopted—and that the elements. not interfere with the uses we have • cumulative effect of such royalties will described above. The nature and scope of the license. make the standard too expensive to • The effect of the proprietary implement—a problem called ‘‘royalty Reasonable Royalty elements in promoting sales of other stacking.’’ 134 To address the risks of products of the licensee and the As a condition of this exception, we hold-up and royalty stacking in the licensor, taking into account only the propose that if an actor charges a royalty standards development context, a RAND for the use of interoperability elements, contribution of the elements themselves and not of the enhanced interoperability license should compensate a patentee the royalty base and rate must be that they enable. for their technical contribution to the reasonable. Consistent with the • The utility and advantages of the technology embodied in a standard, but requirements for demonstrating that actor’s interoperability element over the should not compensate them for mere activities and practices meet the existing technology, if any, that had inclusion in the standard. conditions of an exception proposed in been used to achieve a similar level of Similarly, in the context of section VIII.C.6.c, the actor would need access, exchange, or use of EHI. information blocking, we propose the to show that the royalty base was • The contribution of the elements to RAND inquiry focuses on whether the reasonable and that the royalty was the technical capabilities of the royalty demanded by the actor within a reasonable range for the licensee’s products, taking into account represents the independent value of the interoperability elements at issue. only the value of the elements actor’s proprietary technology. We Importantly, we note that the themselves and not the enhanced propose that if the actor has licensed the reasonableness of any royalties would interoperability that they enable. interoperability element through a be assessed solely on basis of the • The portion of the profit or of the standards development organization in independent value of the actor’s selling price that may be customary in accordance with such organization’s technology to the licensee’s the particular business or in comparable policies regarding the licensing of product,129 not on any strategic value businesses to allow for the use of the standards-essential technologies on stemming from the actor’s control over proprietary elements or analogous reasonable and non-discriminatory essential means of accessing, elements that are also covered by RAND terms, the actor may charge a royalty exchanging, or using electronic health commitments. that is consistent with such policies. information. For instance, the • The portion of the realizable profit Rather than asking whether the royalty reasonableness of royalties could not be that should be credited to the inappropriately captures additional assessed based on the strategic value proprietary elements as distinguished value derived from the technology’s stemming from the adoption of the from non-proprietary elements, the inclusion in the industry standard, we technology by customers or users, the manufacturing process, business risks, would ask whether the actor is charging switching costs associated with the significant features or improvements a royalty that is not based on the value technology, or other circumstances of added by the licensee, or the strategic of its technology (embodied in the technological dependence described value resulting from the network effects, interoperability elements) but rather elsewhere in this preamble (see section switching costs, or other effects of the includes the strategic value stemming VIII.C.5). We note that ‘‘strategic value’’ adoption of the actor’s technology. from the adoption of that technology by would stem from the actor’s control over • The opinion testimony of qualified customers or users. Thus, under this essential means of accessing, experts. proposed approach and the factors set • exchanging, or using electronic health The amount that a licensor and a forth above, we would consider the information. Limiting a reasonable licensee would have agreed upon (at the technical contribution of the actor’s royalty to the value of the technology time the licensee began using the interoperability elements to the isolated from strategic value is similar elements) if both were considering the licensee’s products—such as any in concept to apportionment of RAND obligation under this exception proprietary capabilities or features that reasonable royalties for the infringement and its purposes, and had been the licensee uses in its product—but of standard essential patents (SEPs).130 reasonably and voluntarily trying to would screen out any functional aspects In our context, permitting an actor to reach an agreement. of the actor’s technology that are used charge a royalty on the basis of these These factors mirror those used by only to establish interoperability and considerations would effectively allow courts that have examined the enable EHI to be accessed, exchanged, reasonableness of royalties charged the actor to extract rents on access, and used. Additionally, we propose that exchange, and use of EHI, which is pursuant to a commitment to an SDO to license standard-essential technologies 132 MDL 2303, 2013 WL 5593609 (N.D.Ill. Oct. 3, 129 See Ericsson, Inc. v. D-Link Systems, Inc., 773 on RAND terms (see Microsoft Corp. v. 2013). 131 F.3d 1201, 1226; 1232 (Fed. Cir. 2014). Motorola, Inc.; In re Innovatio IP 133 Case No. 5:12–cv–03451–RMW, 2014 WL 130 See, e.g., Georgia-Pacific Corp. v. United 46997 (N.D.Cal. Jan. 6, 2014). States Plywood Corp., 318 F. Supp 1116 (S.D.N.Y. 131 Case No. 10–cv–1823 JLR, 2013 WL 2111217 134 Microsoft Corp. v. Motorola, Inc., 864 1970) (utilizing the more common approach). (W.D.Wash. Apr. 25, 2013). F.Supp.2d 1023, 1027 (W.D.Wash. 2012).

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00125 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7548 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

to address the potential risk of royalty uniformly for all substantially similar or vary its terms and conditions based on stacking we would need to consider the similarly situated classes of persons and subjective criteria, such as whether it aggregate royalties that would apply if requests. This requirement addresses a thinks an app will be ‘‘popular’’ or is a owners of other essential root cause of information blocking. In ‘‘good fit’’ for its ecosystem. Nor could interoperability elements made royalty order to be considered non- it offer different terms or conditions on demands of the implementer. discriminatory, such criteria would the basis of objective criteria that are not Specifically, we propose that, to qualify have to be objective and verifiable, not competitively neutral, such as whether for this exception, the actor must grant based on the actor’s subjective judgment an app ‘‘connects to’’ other technologies licenses on terms that are objectively or discretion. We emphasize that this or services, provides capabilities that commercially reasonable taking into proposal does not mean that the actor the EHR developer plans to incorporate account the overall licensing situation, must apply the same terms for all in a future release of its technology, or including the cost to the licensee of persons or classes of persons requesting enables an efficient means for customers obtaining other interoperability a license. However, any differences in to export data for use in other databases elements that are important for the terms would have to be based on actual or technologies that compete directly viability of the products for which it is differences in the costs that the actor with the EHR developer. Similarly, the seeking to license interoperability incurred or other reasonable and non- EHR developer could not set different elements from the actor. discriminatory criteria. Moreover, we terms or conditions based on how much We clarify that, as proposed, this propose that any criteria upon which an revenue or other value the app might condition would not preclude an actor actor varies its terms or conditions generate from the information it collects from licensing its interoperability would have to be both competitively through the APIs, such as by elements pursuant to an existing RAND neutral—meaning that the criteria are introducing a revenue-sharing commitment to an SDO. We also note not based in any part on whether the requirement for apps that use data for that, in addition to complying with the requestor or other person is a secondary purposes that are very requirements described above, to meet competitor, potential competitor, or will lucrative and for which the EHR this proposed condition any royalties be using EHI obtained via the developer would like a ‘‘piece of the charged must meet the condition, interoperability elements in a way that pie.’’ Such practices would disqualify proposed separately below, that any facilitates competition with the actor— the actor from this exception and would license terms be non-discriminatory. and neutral as to the revenue or other implicate the information blocking We request comment on these aspects value that the requestor may be derived provision. of the proposed exception. Commenters from access, exchange, or use of the EHI are encouraged to consider, in The foregoing conditions are not obtained via the interoperability intended to limit an actor’s flexibility to particular, whether the factors and elements, including any secondary use approach we have described will be set different terms based on legitimate of such EHI. We believe these administrable and appropriately balance differences in the costs to different limitations are necessary in light of the the unreasonable blocking by actors of classes of persons or in response to potential for actors to use their control the use of essential interoperability different classes of requests, so long as over interoperability elements to engage elements with the need to provide any such classification was in fact based in discriminatory practices that create adequate assurance to investors and on neutral criteria (in the sense unreasonable barriers or costs for innovators that they will be able to earn described above) that are objectively persons seeking to develop, offer, or use a reasonable return on their investments verifiable and were applied in a interoperable technologies to expand in interoperable technologies. If our consistent manner for persons and/or access and enhance the exchange and proposed approach does not adequately requests within each class. As an use of EHI. balance these concerns or would not important example, the proposed achieve our stated policy goals, we ask To clarify our expectations for this condition would not preclude a covered that commenters suggest revisions or proposed condition, we provide the actor from pursuing strategic alternative approaches. We ask that following illustration. Consider an EHR partnerships, joint ventures, co- such comments be as detailed as developer that establishes an ‘‘app marketing agreements, cross-licensing possible and provide rigorous economic store’’ through which third-party agreements, and other similar types of justifications for any suggested revisions developers can license the EHR commercial arrangements under which or alternative approaches. developer’s proprietary APIs, which we it provides more favorable terms than assume are separate from the APIs for other persons with whom it has a Non-Discriminatory Terms required by the API Condition of more arms-length relationship. In these We propose that for this exception to Certification proposed in § 170.404. The instances the actor should have no apply the terms on which an actor EHR developer could charge a difficulty identifying substantial and licenses and otherwise provides reasonable royalty and impose other verifiable efficiencies that demonstrate interoperability elements must be non- reasonable terms to license these that any variations in its terms and discriminatory. This requirement would interoperability elements. The terms conditions were based on objective and apply to both price and non-price terms, and conditions could vary based on neutral criteria. We do note an and thus would apply to the royalty neutral, objectively verifiable, and important caveat, however, specifically terms discussed immediately above as uniformly applied criteria. These might that a health IT developer of certified well as other types of terms that may be include, for example, significantly health IT who is an ‘‘API Technology included in licensing agreements or greater resources consumed by certain Supplier’’ under the Condition of other agreements related to the types of apps, such as those that export Certification proposed in § 170.404 provision or use of interoperability large volumes of data on a continuous would not be permitted to offer different elements. basis, or the heightened risks associated terms in connection with the APIs To comply with this condition, the with apps designed to ‘‘write’’ data to required by that Condition of terms on which the actor licensed the the EHR database or to run natively Certification. As discussed in section interoperability elements must be based within the EHR’s user interface. In VII.B.4 of this preamble, we propose on criteria that the actor applied contrast, the EHR developer could not that API Technology Suppliers are

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00126 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7549

required to make these APIs available RAND obligations under this exception. extent possible commenters provide on terms that are no less favorable than We clarify that this condition would not detailed economic rationale in support provided to their own customers, preclude an actor and a willing licensee of their comments. suppliers, partners, and other persons from agreeing to such an arrangement, Non-Disclosure Agreement with whom they have a business so long as the arrangement was not relationship. As noted below towards required. We propose that an actor would be the end of our discussion of this Fourth, the actor must not condition permitted under this exception to exception to the information blocking the use of interoperability elements on require a licensee to agree to a provision, the exception incorporates a requirement or agreement to license, confidentiality or non-disclosure the API Condition of Certification’s grant, assign, or transfer the licensee’s agreement (NDA) to protect the actor’s requirements in full for all health IT own IP to the actor. We believe it is trade secrets, provided that the NDA is developers subject to that condition. inconsistent with the actor’s RAND no broader than necessary to prevent the We welcome comments on the licensing obligations under this unauthorized disclosure of the actor’s foregoing condition and requirements. exception, and would raise information trade secrets. Further, we propose that blocking concerns, for an actor to use its the actor would have to identify (in the Collateral Terms control over interoperability elements as NDA) the specific information that it We propose five additional conditions leverage to obtain a ‘‘grant back’’ of IP claims as trade secrets, and that such that would reinforce the requirements of rights or other consideration whose information would have to meet this exception discussed above. These value may exceed that of a reasonable definition of a trade secret under additional conditions would provide royalty. Consistent with our approach applicable law. We believe these bright-line prohibitions for certain types under other conditions of this safeguards are necessary to ensure that of collateral terms or agreements that we exception, this condition would not the NDA is not used to impose believe are inherently likely to interfere preclude an actor and a willing licensee restrictions or burdensome requirements with access, exchange, or use of EHI. We from agreeing to a cross-licensing, co- that are not actually necessary to protect propose that any attempt to require a marketing, or other agreement if they so the actor’s trade secrets and that impede licensee or its agents or contractors to choose. However, the actor cannot the use of the interoperability elements. do or agree to do any of the following require the licensee to enter into such an The use of an NDA for such purposes would disqualify the actor from this agreement. The actor must offer the would preclude an actor from qualifying exception and would be suspect under option of licensing the interoperability for this exception and would implicate the information blocking provision. elements without a promise to provide the information blocking provision. We First, the actor must not require the consideration beyond a reasonable note that if the actor is a health IT licensee or its agents or contractors to royalty. We note that in the SDO developer of certified health IT, it may not compete with the actor in any context, it can sometimes be consistent be subject to the Condition of product, service, or market, including with RAND terms to require that an SEP Certification proposed in § 170.403, markets for goods and services, licensee also grant a cross-license to any which prohibits certain health IT technologies, and research and SEPs that it holds, provided that the developer prohibitions and restrictions development. We are aware that such cross-license is limited to patents on communications about a health IT agreements have been used to either essential to the licensed standard. In developer’s technology and business directly exclude suppliers of this way, this condition differs from practices. This exception would not in interoperable technologies and services licensing in the SDO context. any way abrogate the developer’s from the market or to create exclusivity Finally, the actor must not condition obligations to comply with that that reduces the range of technologies the use of interoperability elements on condition. and options available to health care a requirement or agreement to pay a fee We encourage comment on this providers and other health IT customers of any kind whatsoever unless the fee condition of the proposed exception. and users. meets either the narrowly crafted ii. Additional Requirements Relating to Second, and for similar reasons, the condition to this exception for a the Provision of Interoperability actor must not require the licensee or its reasonable royalty, or, alternatively, the Elements agents or contractors to deal exclusively fee satisfies the separate exception with the actor in any product, service, proposed in § 171.204, which permits In addition to the conditions or market, including markets for goods the recovery of certain costs reasonably described above, we propose that an and services, technologies, and research incurred. As noted in section VIII.D.4, actor’s practice would need to comply and development. that exception generally does not allow with additional conditions that ensure Third, the actor must not require the for the recovery of royalties or other fees that actors who license interoperability licensee or its agents or contractors to associated with intangible assets. elements on RAND terms do not engage obtain additional licenses, products, or However, the exception does allow for in separate practices that impede the services that are not related to or can be the reasonable and actual development use of those elements or otherwise unbundled from the requested and acquisition costs of such assets. undermine the intent of this exception. interoperability elements. This We request comment on the These conditions are analogous to the condition reinforces the condition categorical exclusions outlined above. conditions described in our proposal described earlier requiring that any In particular, we encourage commenters above concerning collateral terms but royalties charged by the actor for the use to weigh in on our assumption that address a broader range of practices that of interoperability elements be these practices are inherently likely to may not be effected through the license reasonable. Without this condition, we interfere with access, exchange, or use agreements themselves or that occur believe that an actor could require a of EHI. We also encourage commenters separately from the licensing licensee to take a license to additional to suggest any conceivable benefits that negotiations and other dealings between interoperability elements that the these practices might offer for the actor and the licensee. Specifically, licensee does not need or want, which interoperability or for competition and we propose that an actor would not could enable the actor to extract consumers that we might have qualify for this exception if it engaged royalties that are inconsistent with its overlooked. Again, we ask that to the in a practice that had the purpose or

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00127 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7550 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

effect of impeding the efficient use of requirements of those Conditions of cause interference with its access, the interoperability elements to access, Certification for all practices and at all exchange, and use. Without this specific exchange, or use EHI for any relevant times. Several of the exception, there could be a significant permissible purpose; or the efficient requirements of these conditions mirror risk that actors may refrain from development, distribution, deployment, those of this exception. However, in conducting maintenance and or use of an interoperable product or some instances the Conditions of improvements of health IT out of fear service for which there is actual or Certification provide additional or more that if the purpose was not for potential demand. As an illustration, the specific requirements that apply to the preventing harm, promoting security, or exception would not apply if the provision of interoperability elements for another reason covered by the other developer licensed its proprietary APIs by developers of certified health IT. For exceptions, then their actions might for use by third-party apps but then example, developers subject to the API contravene the information blocking prevented or delayed the use of those Condition of Certification must make provision. apps in production environments by, for certain public APIs available on terms This exception would apply to the example, restricting or discouraging that are royalty free and no less unavailability of health IT occasioned customers from enabling the use of the favorable than provided to themselves by both planned and unplanned apps, or engaging in ‘‘gate keeping’’ and their customers, suppliers, partners, maintenance and improvements. practices, such as requiring apps to go and other persons with whom they have Planned maintenance or improvements through a vetting process and then a business relationship. These more are typically carried out at regular applying that process in a prescriptive requirements reflect the intervals and address routine repairs, discriminatory or unreasonable manner. specific obligations of health IT updates, or new releases. Unplanned Finally, to ensure the actor’s developers under the Program, maintenance or improvements respond commitments under this exception are including the duty to facilitate the to urgent or time-sensitive issues, which durable, we propose one additional access, exchange, and use of cannot wait for the occurrence of a pre- safeguard: An actor cannot avail itself of information from patients’ electronic planned time period to implement the this exception if, having licensed the health records without special effort. A required maintenance or improvements. interoperability elements, the actor health IT developer of certified health This proposed exception makes changes to the elements or its IT’s failure to comply with these and acknowledges that the performance of technology that ‘‘break’’ compatibility or other certification requirements that health IT is often measured by service otherwise degrade the performance or specifically support interoperability level agreements that provide flexibility interoperability of the licensee’s would, in addition to precluding the to ensure that system availability is products or services. We believe this developer from invoking this exception, balanced with essential maintenance condition is crucial given the ease with be significant evidence of information and improvements. Where the provision which an actor could make subtle blocking. of health IT is subject to an allowance ‘‘tweaks’’ to its technology or related for maintenance or improvement that services that could disrupt the use of the 7. Maintaining and Improving Health IT has been agreed to by the recipient of licensee’s compatible technologies or Performance that health IT, we propose that neither services and result in substantial We propose to establish an exception that agreement, nor the performance of competitive and consumer injury. to the information blocking provision it, should constitute information We clarify and emphasize that this for certain practices that are reasonable blocking, provided that certain proposed condition would in no way and necessary to maintain and improve conditions are met. prevent an actor from making the overall performance of health IT, To ensure that the actor’s practice of improvements to its technology or provided certain conditions are met. making health IT, and in turn EHI, responding to the needs of its own The proposed exception would unavailable for the purpose of carrying customers or users. However, to benefit recognize as reasonable and necessary out maintenance or improvements is from the exception, the actor’s practice the practice of an actor making health IT reasonable and necessary, we have would need to be necessary to under its control temporarily identified conditions that must be accomplish these purposes and the actor unavailable to maintain or improve the satisfied at all relevant times to qualify must have afforded the licensee a health IT. The exception and for this exception. reasonable opportunity under the corresponding conditions are set forth Unavailability of Health IT Must Be for circumstances to update its technology in the proposed regulation text in no Longer Than Necessary To Achieve to maintain interoperability. We also § 171.207. the Maintenance or Improvements for recognize that an actor may have to EHI should be accessible and usable Which the Health IT was Made suspend access or make other changes on demand by those that need it. Unavailable immediately and without prior notice in However, in order for this to happen, response to legitimate privacy, security, the health IT through which EHI is Any unavailability of health IT must or patient safety-related exigencies. accessed, exchanged, or used must be for a period of time no longer than Such practices would be governed by perform properly and efficiently. This necessary to achieve the maintenance or the exceptions proposed in section requires that health IT be maintained improvement purpose for which the VIII.D of this preamble and thus would and in some instances improved. The health IT is made unavailable. This not need to qualify for this exception. performance of such maintenance and condition recognizes the critical improvements sometimes requires that importance of access to EHI and ensures iii. Compliance With Conditions of health IT is temporarily taken offline, that health IT is not made unavailable Certification which can interfere with the access, for longer than needed. For example, a As a final condition of this proposed exchange, and use of EHI. We believe health IT developer of certified health exception, we propose that health IT this exception is necessary to ensure IT that has the right under its contract developers of certified health IT who are that actors are not deterred from with a large health system to take its subject to the Conditions of Certification maintaining and improving the overall system offline for four hours each proposed in §§ 170.402, 170.403, and performance of health IT because month to conduct routine maintenance 170.404 must comply with all temporary unavailability of EHI may would not qualify for this exception if

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00128 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7551

an information blocking claim was health IT, HIE, or HIN, must be agreed same health care provider was to receive made about a period of unavailability to by the individual or entity to whom a new release of the health IT during which no maintenance was the health IT is supplied. The developer’s software, which was to be performed. availability of health IT is typically implemented by the developer and Making this evaluation for unplanned addressed in a written contract or other which required that the health IT be maintenance or improvements will be written agreements, that puts the taken offline by the developer for 6 more difficult, because unplanned recipient of the health IT on notice hours, then that unavailability, or an maintenance or improvements are about the level of EHI and health IT allowance for it, would need to be the typically initiated in response to a threat unavailability that can be expected for subject of prior agreement. or risk that needs to be responded to on users of the health IT. By such Unavailability of health IT initiated by an urgent basis and for so long as the agreements, the recipient of the health a recipient of health IT (rather than the threat or risk persists. However, if, for IT willfully agrees to that level of supplier of the health IT) would still example, an HIE identified a software planned and unplanned unavailability need to satisfy the other conditions of failure (not identified as a safety or (typically referred to in health IT this exception, including that the security risk) that required immediate contracts as ‘‘downtime’’). Some health unavailability be for a period of time no remediation necessitating the actor take IT contracts address the question of longer than necessary to achieve the its health IT offline, the actor would be system availability by way of an maintenance or improvements for expected to bring the health IT back ‘‘uptime warranty’’ that specifies the which the health IT was made online as soon as possible after the issue maximum amount of unavailability for unavailable. was resolved. a specified period and the timing of any We note that this condition would need to be satisfied by any HIE or HIN Unavailability of Health IT for planned unavailability. We acknowledge that in some cases, that sought to benefit from this Maintenance or Improvements Must Be health IT needs to be taken offline or exception in connection with any Implemented in a Consistent and Non- maintenance or improvements on an interference with access, exchange, or Discriminatory Manner urgent basis and in a way that is not use occasioned by an HIE or HIN We propose that any unavailability of expressly permitted under a health IT making its health IT unavailable for the health IT occasioned by the conduct of contract. An actor may still satisfy this purposes of conducting maintenance or maintenance or improvements must be proposed condition so long as the improvements. An HIE would need to implemented in a consistent and non- maintenance or improvements are have secured the agreement of those discriminatory manner. This condition agreed to by the recipient of the health individuals or entities that use its provides a basic assurance that when IT. This could be achieved by way of an exchange services, and a HIN would health IT is made unavailable for the oral agreement reached between the need to have obtained the agreement of purpose of performing maintenance or parties by telephone, but we note that the network’s participants. improvements that the unavailability is because an actor must demonstrate that Interaction With Preventing Harm and not abused by the actor that controls the it satisfies the requirements of this Promoting Security Exceptions health IT. For example, a health IT exception, it would be best practice for developer of certified health IT would an actor to ensure the agreement was in When health IT is made unavailable not qualify for this exception if the writing or, at minimum, for maintenance or improvements aimed developer, using a standard contract contemporaneously documented. at preventing harm to a patient or other that provided a flexible allowance for This proposed condition of this person, or securing EHI, an actor must planned maintenance or improvements, exception only applies when the comply with the conditions specified in initiated planned maintenance or unavailability of health IT is caused by proposed § 171.201 or § 171.203 improvements for a customer with an a health IT developer of certified health respectively, in order to qualify for an expiring health IT contract during a IT, HIE, or HIN. In these circumstances, exception to the information blocking time when users might reasonably be it is the supplier of the health IT that provision. This condition ensures that expected to access EHI, but conducted controls if and when health IT is this exception cannot be used to avoid planned maintenance or improvements intentionally taken offline for compliance with conditions applicable for new customers in the middle of the maintenance or improvements. This under other exceptions. For example, if night. However, this condition does not condition does not apply when health part of an EHR system was taken offline require that actors conduct planned IT is made unavailable for maintenance in response to a health IT developer of maintenance or improvements or improvements at the initiative of a certified health IT being alerted to the simultaneously, or require that every recipient (or customer) of health IT, risk of corrupt or inaccurate data being health IT contract provide the same because in that case, the unavailability recorded or incorporated in a patient’s promises in regard to planned has, for the purpose of this exception, health record, any decision to make the maintenance or improvements. Indeed, nothing to do with the supplier. When EHR unavailable on this basis to a recipient of health IT may agree to a it is a customer of health IT that initiates conduct unplanned maintenance or longer window for unavailability in unavailability, the unavailability would improvements would need to accord exchange for a reduced fee for system not need to be the subject of an with the conditions of the proposed maintenance, which would not agreement with the supplier of that exception for preventing harm (see contravene this condition. health IT, nor anyone else, in order for § 171.201 and section VIII.D.1 of this the customer of health IT to benefit from proposed rule). Similarly, unavailability Unavailability of Health IT for this exception. For example, a health occasioned by maintenance or Maintenance or Improvements Must Be care provider that locally hosts and improvements initiated to secure EHI in Agreed maintains its health IT (being software response to a suspected malware attack In order to benefit from this supplied by a health IT developer) would need to either be implemented in exception, we propose that the would not need to satisfy this condition accordance with the actor’s unavailability of health IT due to if it interfered with access to EHI by organizational security policy that maintenance or improvements initiated taking the health IT offline temporarily satisfied the requirements of the by a health IT developer of certified to conduct maintenance. However, if the proposed exception for promoting the

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00129 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7552 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

security of EHI or if the practice did not access, exchange, or use of EHI, but interoperability at section 3000(10) of implement an organizational security which are designed to appropriately the PHSA, and the conditions of policy, the actor must have made a accommodate the customer’s limited certification required by section determination in each case, based on the resources, or to assure the performance 3001(c)(5)(D) of the PHSA). particularized facts and circumstances, of certain health IT functionality. We expect that any proposal would be consistent with the requirements of the We expect that most reasonable and narrowly framed such that contract exception (see § 171.203(d) and section necessary commercial arrangements that terms, policies, or other practices that VIII.D.3 of this proposed rule). affect access, exchange, or use of EHI are not strictly necessary to comply with could be recognized under one or more the Common Agreement would not Request for Comment of the existing exceptions. However, we qualify for the exception. Similarly, we We seek comment on this exception seek comment on whether there exists a expect that the proposal would provide generally. Specifically, we seek class of legitimate commercial that an actor could benefit from this comment on whether the proposed arrangements that could implicate the exception only if the practice or conditions impose appropriate information blocking provision, but practices that the actor pursued were no limitations on actor-initiated health IT which would not benefit from the broader than necessary under the maintenance or improvements that lead existing proposed exceptions. circumstances. These limitations would to EHI unavailability. Our goal is to ensure that the exception is narrowly E. Additional Exceptions—Request for ensure that the exception is not abused, tailored to practices that are most likely Information while at the same time recognizing to promote trusted exchange without reasonable commercial arrangements 1. Exception for Complying With unnecessarily impeding access, entered into by parties for the proper Common Agreement for Trusted exchange, or use of EHI. maintenance and improvement of health Exchange We ask commenters to provide IT. To support full network-to-network feedback on this potential exception to We are also considering whether to exchange of EHI, section 3001(c)(9)(A) the information blocking provision to be expand this exception to capture a of the PHSA, added by section 4003 of considered for inclusion in future broader class of practices that are the the Cures Act, directs the National rulemaking. Commenters should subject of reasonable commercial Coordinator to convene public-private consider whether such an exception is agreements and which, in the absence of partnerships to develop or support a necessary, given the scope of the other an exception, may be considered trusted exchange framework (Trusted exceptions proposed in this NPRM, and information blocking. That is, to extend Exchange Framework), including a whether there could be any negative this exception or create new exceptions common agreement for a common set of effects of such an exception. We ask for additional types of practices that rules for trusted exchange between HINs commenters to consider the appropriate interfere with access, exchange, or use (Common Agreement). The most recent scope of this exception, which could of EHI, but that are the subject of free draft Trusted Exchange Framework was include which actors could benefit from agreement and which are reasonable released for public comment on January the exception and the conditions that and necessary. For example, we are 5, 2018,135 however, a new draft will be should apply in order to qualify for the considering whether a practice taken by released in the coming months. exception. an actor to throttle or meter the We are considering whether we 2. New Exceptions availability or performance of health IT, would should propose, in a future where agreed to by the recipient of that rulemaking, a narrow exception to the We welcome comment on any health IT, could ever be a practice that information blocking provision for potential new exceptions we should we recognize as not being information practices that are necessary to comply consider for future rulemaking. blocking if such practice does not with the requirements of the Common Commenters should consider the policy otherwise qualify under an existing Agreement. Such an exception may goals and structure of the proposed exception. support adoption of the Common exceptions in this proposed rule when As discussed in section VIII.C.5 of Agreement and encourage other entities providing comment. We ask that this preamble, we are aware that actors to participate in trusted exchange commenters provide rationale for any can use commercial agreements to through HINs that enter into the proffered exceptions to the information materially discourage, and in some Common Agreement. It would do so by blocking provisions and any conditions instances outright prohibit, certain providing protection if there are an actor would need to meet to qualify instances of access, exchange, or use of practices that are expressly required by for the proffered exception. EHI. For example, a HIN might use a the Common Agreement, or that are participation agreement to prohibit F. Complaint Process necessary to implement such entities that receive EHI through the Section 3022(d)(3)(A) of the PHSA requirements, that might implicate the HIN from transmitting that EHI to directs the National Coordinator to information blocking provision and entities who are not participants of the implement a standardized process for would not qualify for another exception. HIN. Such an arrangement would not be the public to submit reports on claims We note that such an exception would reasonable or necessary because there is of health information blocking. Such be consistent with the complementary no legitimate justification for it. reports could be submitted regarding roles of the information blocking However, we are also aware of any practice by health care providers, provision and other provisions of the commercial arrangements that are not health IT developers, exchanges, or Cures Act that support interoperability motivated by anti-competitive networks that may constitute and enhance the trusted exchange of considerations but that nonetheless information blocking under section EHI (including the interoperable have the effect of interfering with the 3022(a). These practices include, but are network exchange provisions at section access, exchange, or use of EHI. For not limited to, health IT products or 3001(c)(9) of the PHSA, the definition of example, a health IT developer of developers of such products (or other certified health IT may agree to 135 ONC, Draft Trusted Exchange Framework, entities offering such products to health commercial terms with a customer that https://www.healthit.gov/sites/default/files/draft- care providers) not being interoperable have the effect of interfering with trusted-exchange-framework.pdf. or resulting in information blocking;

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00130 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7553

and false statements by developers of confidential or proprietary business aggregation of clinical data. CDC, certified health IT that they have not information? SAMHSA, FDA, HRSA, and USDA also engaged in information blocking. fund state and local public health G. Disincentives for Health Care Section 3022(d)(3)(B) further requires jurisdictions to collect clinical data from Providers—Request for Information that this complaint process provide for health care providers. As noted in the the collection of such information as the Section 3022(b)(2)(B) of the PHSA Cures Act, there are also a wide range originating institution, location, type of provides that any health care provider of clinician-led quality and specialty transaction, system and version, determined by the OIG to have clinical data registries. Compounding timestamp, terminating institution, committed information blocking shall these reporting requirements and locations, system and version, failure be referred to the appropriate agency to options is, as reported by health care notice, and other related information. be subject to appropriate disincentives providers, a lack of standardization We intend to implement and evolve using authorities under applicable across electronic infrastructure that has this complaint process by building on federal law, as the Secretary sets forth led to a comparatively slow adoption of existing mechanisms, including the through notice and comment health IT systems among registries. This complaint process currently available at rulemaking. However, we note that lack of interoperability impacts not only https://www.healthit.gov/healthit- these disincentives may not cover the data exchange between health care feedback. However, we request full range of conduct within the scope providers, but is a significant barrier to comment on this approach and any of section 3022(a)(1). We request the integration and potential use of alternative approaches that would best information on disincentives or if clinical data received from a registry for effectuate this aspect of the Cures Act. modifying disincentives already quality improvement or clinical care. In addition to any other comments that available under existing HHS programs For these reasons outlined above, we the public may wish to submit, we and regulations would provide for more believe it is appropriate to explore specifically request comment on the effective deterrents. multiple approaches to advancing following issues: We also seek information on the health IT interoperability for • What types of information are most implementation of section 3022(d)(4) of bidirectional exchange with registries in important to collect in order to identify the PHSA, which provides that in order to mitigate risks based on factors potential instances of information carrying out section 3022(d) of the like feasibility and readiness, potential blocking? PHSA, the Secretary shall, to the extent unintended burden on health care • What types of information are possible, not duplicate penalty providers, and the need to focus on contemplated by the following structures that would otherwise apply priority clinical use cases. ONC is in the process of conducting research and categories delineated in section with respect to information blocking analysis to determine what evidence- 3022(d)(3)(B): The originating and the type of individual or entity based use cases should be supported institution; location; type of transaction; involved as of the day before December and what standards are available to system and version; timestamp; 13, 2016—enactment of the Cures Act. support such use cases. We are also terminating institution; locations; IX. Registries Request for Information considering the overall maturity of system and version; failure notice; and technology adoption within the market other related information? Section 4005 (a) and (b) of the Cures to support identified standards and the • What types of information or data Act focuses on interoperability and bidirectional exchange between EHRs use of certified EHRs and clinical data elements should be collected under registries for these identified use cases each of the above categories? and registries, including clinician-led clinical data registries. ONC is in the near term, as well as identifying • What additional types of approaching these provisions from glide paths for the potential future information beyond the above may be several angles to address the technical development of enterprise solutions. relevant to complaints and allegations of capability of EHRs to exchange data In the 2015 Edition final rule, we information blocking, especially with registries in accordance with included certification criteria and practices that involve contractual or applicable recognized standards. Based standards that are applicable for specific other business practices for which some on stakeholder engagement and public use cases for bidirectional exchange of the categories of technical or comments on prior ONC regulations, we such as Immunization Information transactional information above may not have identified a wide range of areas Systems. In this proposed rule, we have apply? where the use of standards could proposed processes for updating • How can ONC encourage and significantly improve bidirectional standards as well as new policies streamline the collection of such exchange with registries for a range of related to real world testing that would information so as to minimize burden purposes, including public health, help ensure that functionalities are and encourage the submission of quality reporting, and care quality implemented in a manner that is complaints, especially complaints about improvement. technically feasible in a practice setting. practices that raise the types of As discussed in the ‘‘Strategy on In addition, we have worked with information blocking concerns Reducing Regulatory and federal partners to advance health IT described in this proposed rule? Administrative Burden Relating to the policies related to bidirectional • How can ONC facilitate the Use of Health IT and EHRs’’ draft report exchange with registries in a manner inclusion of sufficient detail and released by ONC for public comment in that supports and reflects the current granularity in complaints to enable December of 2018,136 health care market place while encouraging effective investigations? providers are faced with a myriad of innovation and increased adoption. For • What safeguards should be federal public health reporting example, we have worked with CMS to provided to support adequate requirements and options that rely on enhance guidance for QCDRs under the confidentiality and handling of both bidirectional exchange and MIPS to support health IT innovation information that could: (1) Identify the and partnership with health IT source of the complaint or allegation; (2) 136 https://www.healthit.gov/topic/usability-and- organizations. We are also working with contain other individually identifiable provider-burden/strategy-reducing-burden-relating- the CDC and states to support information; and (3) contain use-health-it-and-ehrs. enhancements to PDMP integration as a

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00131 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7554 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

priority use case for standards-based therapies for particular diseases, Similarly, the Fiscal Year 2018 health IT solutions. We believe these conditions, or exposures; Appropriations Bill 138 also included efforts can help to address the near term • Support an overall approach to data language regarding patient matching. need to support high priority use cases quality, including the systematic The Committee is aware that a challenge for bidirectional exchange between collection of clinical and other health inhibiting the safe and secure electronic health care providers and registries. care data, using standardized data exchange of health information is the lack of In this proposed rule, we propose to elements and procedures to verify the a consistent approach to matching patient data. The Committee encourages ONC to adopt new standards and capabilities for completeness and validity of those data; certified APIs that have the potential to engage with stakeholders on private-sector • Improve and enhance the ability of led initiatives to develop a coordinated change how certain types of information providers to leverage feedback from a strategy that will promote patient safety by exchange are done, including the registry to improve patient care; and accurately identifying patients to their health potential to exchange information with • information. clinical data and public health Address a sufficiently wide range of use cases to warrant the prioritization of Section 4007 of the 21st Century registries. In this request for information Cures Act (Pub. L. 114–255) directs the (RFI), we are seeking information on technical innovation on API-based options over the continued development Government Accountability Office how health IT solutions and the (GAO) to conduct a study on patient proposals throughout this rule can aid of use-case-specific solutions in future rulemaking. matching. Specifically, the GAO was bidirectional exchange with registries charged to review the policies and for a wide range public health, quality We also welcome any other comments activities of the Office of the National reporting, and clinical quality stakeholders may have on Coordinator for Health Information improvement initiatives. For example, implementation of the registries Technology (ONC) and other relevant in December of 2018, in the ‘‘Strategy on provisions under section 4005 of the stakeholders, including standards Reducing Regulatory and Cures Act. development organizations, developers, Administrative Burden Relating to the X. Patient Matching Request for providers, suppliers, payers, quality Use of Health IT and EHRs’’ draft report, Information organizations, States, health information we noted that HL7 was working on an technology policy and technical experts, update to the FHIR standard to support Patient matching is a critical and other appropriate entities. The GAO API access to request data on component to interoperability and the report, Approaches and Challenges to populations of patients, which could nation’s health information technology Electronically Matching Patients’ potentially address additional use cases, infrastructure. Accurate patient Records across Providers, was released including supporting payer needs, matching helps health care providers in January 2019.139 In this report, GAO public health and quality improvement access and share the right information describes (1) stakeholders’ patient efforts, and health research on the right patient when and where it record matching approaches and related organizations. As discussed in section is needed. challenges; and (2) efforts to improve VII.4, FHIR Release 4 has now been patient record matching identified by 85 Inaccurate patient matching can published and updated associated compromise safety, privacy, and lead to stakeholders. Stakeholders said more implementation specifications are increased health care costs, as could be done to improve patient record expected to follow. FHIR Release 4 has acknowledged in the Departments of matching, and identified several efforts several key improvements, including Labor, Health and Human Services, and that could improve matching. For certain foundational aspects in the Education, and Related Agencies example, some said that implementing standard and ‘‘FHIR resources’’ Appropriation Bill, 2017: 137 common standards for recording designated as ‘‘normative’’ for the first demographic data; sharing best practices time. This will lead to a cycle of more The Committee is aware that one of the most significant challenges inhibiting the and other resources; and developing a mature US FHIR Core profiles aligned public-private collaboration effort could with Release 4 and additional safe and secure electronic exchange of health information is the lack of a consistent patient each improve matching. Stakeholders’ implementation guidance that explicitly data matching strategy. With the passage of views varied on the roles ONC and specifies how to handle populations of the HITECH Act, a clear mandate was placed others should play in these efforts and patient data (batch exports) via FHIR to on the Nation’s healthcare community to the extent to which the efforts would more efficiently enable population and adopt electronic health records and health improve matching. Multiple learning health system-oriented exchange capability. Although the Committee stakeholders emphasized that no single services. continues to carry a prohibition against HHS using funds to promulgate or adopt any final effort would solve the challenge of We seek comment on use cases where patient record matching. an API using FHIR Release 4 might standard providing for the assignment of a unique health identifier for an individual Patient matching may be defined as support improved exchange between a until such activity is authorized, the the linking of one patient’s data within provider and a registry. Specifically, we Committee notes that this limitation does not and across health care providers in seek comment on how the use of this prohibit HHS from examining the issues order to obtain a comprehensive and standard might: around patient matching. Accordingly, the longitudinal view of that patient’s • Reduce the burden of implementing Committee encourages the Secretary, acting health care. At a minimum, this is multiple solutions for various types of through the Office of the National accomplished by linking multiple exchange, while still supporting the Coordinator for Health Information demographic data fields such as name, Technology and CMS, to provide technical variability needed to exchange birth date, sex, phone number, and information with registries devoted to assistance to private-sector led initiatives to develop a coordinated national strategy that the care of a population defined by a will promote patient safety by accurately 138 https://appropriations.house.gov/ particular disease, condition, exposure, identifying patients to their health uploadedfiles/23920.pdf. 139 or therapy; information. U.S. Government Accountability Office, • Approaches and Challenges to Electronically Allow for the collection of detailed, Matching Patients’ Records across Providers, GAO– standardized data on an ongoing basis 137 https://www.congress.gov/114/crpt/hrpt699/ 19–197, https://www.gao.gov/assets/700/ for medical procedures, services, or CRPT-114hrpt699.pdf. 696426.pdf.

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00132 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7555

address. For this reason, accurate and within and across providers. We also • Recent research suggests that standardized data capture and exchange intend to review the responses to this involving patients in patient matching and optimized algorithm performance RFI in concert with the GAO report once may be a viable and effective solution to are critical components to the accurate published. increase the accuracy of matching, and patient matching. With this in mind, We specifically seek input on the giving patients access to their own ONC has taken several steps to better following: clinical information empowers understand the patient matching • It is a common misconception that engagements and improved health landscape and to identify areas where technology alone can solve the problem outcomes. We seek comment on ONC can assist in standards and of poor data quality, but even the most potential solutions that include patients technical development, coordination, advanced, innovative technical through a variety of methods and and innovation. For example, in 2017, approaches are unable to overcome data technical platforms in the capture, ONC launched the Patient Matching quality issues. Thus, we seek input on update and maintenance of their own Algorithm Challenge, where six winners the potential effect that data collection demographic and health data, including were awarded total prize winnings of standards may have on the quality of privacy criteria and the role of providers $75,000.140 The goals of this challenge as educators and advocates. health data that is captured and stored • were to bring about greater transparency and the impact that such standards may In addition, we seek input on and data on the performance of existing have on accurate patient matching. We standardized metrics for the patient matching algorithms, spur the also seek input on other solutions that performance evaluation of available adoption of performance metrics for may increase the likelihood of accurate patient matching algorithms. Health IT patient matching algorithm developers, data capture, including the developers are each relying on a number and positively impact other aspects of implementation of technology that of patient matching algorithms, patient matching such as deduplication supports the verification and however, without the adoption of agreed and linking. In addition, in 2018, ONC authentication of certain demographic upon metrics for the evaluation of showcased innovative technical and data elements such as mailing address, algorithm performance across the non-technical approaches to matching as well as other efforts that support industry, existing matching approaches through hosting a patient matching track ongoing data quality improvement cannot be accurately evaluated or at ONC’s Second Interoperability efforts. compared across systems or over time. 141 • At the same time, we seek input on Forum. • In concert with the GAO study In this Request for Information (RFI), transparent patient matching indicators referenced above, we seek input on we seek comment on additional such as database duplicate rate, what additional data elements could be opportunities that may exist in the duplicate creation rate, and true match patient matching space and ways that defined to assist in patient matching as rate, for example, that are necessary for ONC can lead and contribute to well as input on a required minimum assessment and reporting. The current coordination efforts with respect to set of elements that need to be collected lack of consensus, adoption, and patient matching. ONC and CMS and exchanged. We encourage transparency of such indicators makes collaborated to jointly issue stakeholders to review the Patient communication, reporting, and cross- complementary requests for information Demographic Record Matching section provider or cross-organizational regarding patient matching. ONC is of the Interoperability Standards comparisons impossible, impedes a full 143 particularly interested in ways that Advisory and comment on the and accurate assessment of the extent of patient matching can facilitate improved standards and implementation the problem, prohibits informed patient safety, better care coordination, specifications outlined. Public decision making, limits research on and advanced interoperability. comments and subject matter feedback complementary matching methods, and Inaccurate patient matching can lead to on all sections of the Interoperability inhibits progress and innovation in this inappropriate and unnecessary care; Standards Advisory are accepted year area. unnecessary burden on both patients round. • There are a number of emerging • and providers to correct Also in alignment with the GAO private-sector led approaches in patient misidentification, time consuming and study, we seek input on whether and matching that may prove to be effective, expensive burden on health systems to what requirements for electronic health and we seek input on these approaches, detect and reconcile duplicate patient records could be established to assure in general. A number of matching records and improper record merges; data used for patient matching is services that leverage referential and poor oversite into fraud and abuse. collected accurately and completely for matching technology have emerged in Per a survey by the College of every patient. For instance, the adopted the market recently, yet evaluations of Healthcare Information Management 2015 Edition ‘‘transitions of care’’ this type of approach has either not Executives, one in five providers named certification criterion (§ 170.315(b)(1)) been conducted or has not been made lack of an appropriate patient matching currently includes patient matching public. Other innovative technical strategy as the primary reason for requirements for first name, last name, approaches such as biometrics, machine inadvertent illness or injury.142 We previous name, middle name, suffix, learning and artificial intelligence, or consider this a quality of care and date of birth, address, phone number, locally developed unique identifier patient safety issue and seek stakeholder and sex. These requirement also include efforts, when used in combination with input on creative, innovative, and format constraints for some of the data. non-technical approaches such as effective approaches to patient matching • There are unique matching issues patient engagement, supportive policies, related to pediatrics and we seek data governance, and ongoing data 140 https://www.hhs.gov/about/news/2017/11/08/ comment on innovative and effective quality improvement efforts may hhs-names-patient-matching-algorithm-challenge- technical or non-technical approaches enhance capacity for matching. winners.html. that could support accurate pediatric • Finally, ONC seeks input on new 141 https://www.healthit.gov/news/events/oncs- data that could be added to the United 2nd-interoperability-forum. record matching. 142 https://chimecentral.org/wp-content/uploads/ States Core Data for Interoperability 2014/11/Summary_of_CHIME_Survey_on_Patient_ 143 https://www.healthit.gov/isa/patient- (USCDI) or further constrained within it Data.pdf. demographic-record-matching. in order to support patient matching.

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00133 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7556 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

XI. Incorporation by Reference proposing standards and in this guide. This guide describes The Office of the Federal Register has implementation specifications for additional conformance statements and established requirements for materials adoption, including describing any constraints for EHR data submissions (e.g., standards and implementation exceptions in the proposed adoption of that are required for reporting specifications) that agencies propose to standards and implementation information to the CMS for the Hospital incorporate by reference in the Code of specifications. Over the years of Inpatient Quality Reporting Program Federal Regulations (79 FR 66267; 1 adopting standards and implementation 2019 Reporting Period. The purpose of CFR 51.5(a)). Specifically, § 51.5(a) specifications for certification, we have this guide is to serve as a companion to requires agencies to discuss, in the worked with SDOs, such as HL7, to the base HL7 QRDA I STU R5 for preamble of a proposed rule, the ways make the standards we propose to entities such as Eligible Hospitals (EH), that the materials it proposes to adopt, and subsequently adopt and Critical Access Hospitals (CAH), and incorporate by reference are reasonably incorporate by reference in the Federal vendors to submit QRDA I data for available to interested parties or how it Register, available to interested consumption by CMS systems including worked to make those materials stakeholders. As described above, this for Hospital Quality Reporting (HQR). reasonably available to interested includes making the standards and • CMS Implementation Guide for parties; and summarize, in the preamble implementation specifications available Quality Reporting Document of the proposed rule, the material it through no-cost memberships and no- Architecture Category III Eligible proposes to incorporate by reference. cost subscriptions. Clinicians and Eligible Professionals To make the materials we intend to As required by § 51.5(a), we provide Programs Implementation Guide for incorporate by reference reasonably summaries of the standards we propose 2019, October 8, 2018 available, we provide a uniform to adopt and subsequently incorporate by reference in the Code of Federal URL: https://ecqi.healthit.gov/system/ resource locator (URL) for the standards _ _ _ _ _ Regulations. We also provide relevant files/2019 CMS QRDA III Eligible and implementation specifications. In Clinicians_and_EP_IG-508.pdf. many cases, these standards and information about these standards and implementation specifications This is a direct access link. implementation specifications are Summary: The Health Level Seven directly accessible through the URLs throughout the preamble. We have organized the following International (HL7) Quality Reporting provided. In instances where they are Document Architecture (QRDA) defines not directly available, we note the steps standards and implementation specifications that we propose to adopt constraints on the HL7 Clinical and requirements necessary to gain Document Architecture Release 2 (CDA access to the standard or through this rulemaking according to the sections of the Code of Federal R2). QRDA is a standard document implementation specification. In most of format for the exchange of electronic these instances, access to the standard Regulation (CFR) in which they would be codified and cross-referenced for clinical quality measure (eCQM) data. or implementation specification can be QRDA reports contain data extracted gained through no-cost (monetary) associated certification criteria and requirements that we propose to adopt. from electronic health records (EHRs) participation, subscription, or and other information technology membership with the applicable We note, in certain instances, that we request comment in this proposed rule systems. The reports are used for the standards developing organization exchange of eCQM data between (SDO) or custodial organization. In on multiple standards or implementation specifications that we systems for quality measurement and certain instances, where noted, access reporting programs. This QRDA guide requires a fee or paid membership. As are considering for adoption and incorporation by reference for particular contains the Centers for Medicare & an alternative, a copy of the standards Medicaid Services (CMS) supplemental may be viewed for free at the U.S. use cases. We include all of these standards and implementation implementation guide to the HL7 Department of Health and Human Implementation Guide for CDA Release Services, Office of the National specifications in this section of the preamble. 2: Quality Reporting Document Coordinator for Health Information Architecture, Category III, STU Release Technology, 330 C Street SW, Content Exchange Standards and 2.1 (June, 2017) for the 2019 Washington, DC 20201. Please call (202) Implementation Specifications for performance period. This HL7 base 690–7171 in advance to arrange Exchanging Electronic Health standard is referred to as the HL7 inspection. Information—45 CFR 170.205 QRDA–III STU R2.1. The National Technology Transfer • ® and Advancement Act (NTTAA) of 1995 CMS Implementation Guide for • Health Level 7 (HL7 ) CDA R2 IG: C– (15 U.S.C. 3701 et seq.) and the Office Quality Reporting Document CDA Templates for Clinical Notes R1 of Management and Budget (OMB) Architecture Category I Hospital Quality Companion Guide, Release 1 (C–CDA Circular A–119 require the use of, Reporting Implementation Guide for 2.1 Companion Guide), March 2017 2019, May 4, 2018 wherever practical, technical standards URL: http://www.hl7.org/implement/ that are developed or adopted by URL: https://ecqi.healthit.gov/system/ standards/product_brief.cfm?product_ voluntary consensus standards bodies to files/QRDA_HQR_2019_CMS_IG_final_ id=447. carry out policy objectives or activities, 508.pdf. Access requires a ‘‘user account’’ and with certain exceptions. The NTTAA This is a direct access link. a license agreement. There is no and OMB Circular A–119 provide Summary: This guide is a CMS monetary cost for a user account and exceptions to selecting only standards Quality Reporting Document license agreement. developed or adopted by voluntary Architecture Category I (QRDA I) Summary: The Companion Guide to consensus standards bodies, namely implementation guide to the HL7 Consolidated Clinical Document when doing so would be inconsistent Implementation Guide for CDA Release Architecture (C–CDA) provides with applicable law or otherwise 2: Quality Reporting Document supplemental guidance to the Health impractical. As discussed in section IV Architecture Category I, Release 1, STU Level Seven (HL7) CDA® R2 IG: C–CDA of this preamble, we have followed the Release 5 (published December 2017), Templates for Clinical Notes STU NTTAA and OMB Circular A–119 in referred to as the HL7 QRDA I STU R5 Release 2.1 in support of the ONC 2015

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00134 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7557

Edition Health IT Certification Criteria prescription requests, New prescription • Health Level 7 (HL7®) Fast Healthcare (2015 Edition) Certified Electronic response denials, Prescription transfer Interoperability Resources (FHIR®) Health Record Technology message, Prescription fill indicator Release 2.0 Draft Standard for Trial Use requirements. This guide provides change, Prescription recertification, Risk (DSTU), Version 1.0.2–7202, October 24, additional technical clarification and Evaluation and Mitigation Strategy 2015 practical guidance to assist (REMS) initiation request, REMS URL: http://hl7.org/fhir/DSTU2/ implementers to support best practice initiation response, REMS request, and index.html. implementations of the 2015 Edition REMS response. This is a direct access link. Health Information Technology (Health United States Core Data for Summary: The Fast Healthcare IT) Certification Criteria, 2015 Edition Interoperability Resources (FHIR) Draft Base Electronic Health Record (EHR) Interoperability—45 CFR 170.213 • Standard for Trial Use (DSTU) Release Definition, and ONC Health IT The United States Core Data for 2.0, Version 1.0.2 is designed to enable Certification. Interoperability (USCDI), Version 1 (v1) information exchange to support the • Health Level 7(HL7®) CDA R2 URL: https://www.healthit.gov/ provision of health care in a wide Implementation Guide: C–CDA USCDI. variety of settings. The specification Supplemental Templates for Unique This is a direct access link. builds on and adapts modern, widely Device Identification (UDI) for Summary: The United States Core used, RESTful practices to enable the Implantable Medical Devices, Release Data for Interoperability (USCDI) provision of integrated health care 1–US Realm establishes a minimum set of data across a wide range of teams and URL: http://www.hl7.org/implement/ classes that are required to be organizations. HL7 FHIR solutions are standards/product_brief.cfm?product_ interoperable nationwide and is built from a set of modular components id=486. designed to be expanded in an iterative called ‘‘Resources’’. These Resources Access requires a ‘‘user account’’ and and predictable way over time. Data can easily be assembled into working a license agreement. There is no classes listed in the USCDI are systems that solve real world clinical monetary cost for a user account and represented in a technically agnostic and administrative problems at a license agreement. manner. fraction of the price of existing Summary: The Implementation Guide alternatives. HL7 FHIR is suitable for Application Programming Interface contains guidance, supporting material use in a wide variety of contexts (e.g., Standards—45 CFR 170.215 and new templates to implement mobile phone apps, cloud support for Unique Device Identifiers • HL7® FHIR® Foundation, Argonaut communications, EHR-based data (UDIs) for implantable medical devices. Data Query Implementation Guide sharing, and server communication in The IG identifies changes needed to the Server, Version 1.0.2, December 15, large institutional health care C–CDA to better facilitate the exchange 2016 providers). All resources have the of the individual UDI components in the following features in common: A URL URL: http://www.fhir.org/guides/ health care system when devices are that identifies it; common metadata; a argonaut/r2/Conformance-server.html. implanted in a patient. The UDI human-readable XHTML summary; a set This is a direct access link. components include the Device of defined common data elements; and Identifier (DI) and the following Summary: This profile defines the an extensibility framework to support individual production identifiers (PI): expected capabilities of an Argonaut variation in health care. Data Query server when conforming to The lot or batch number, serial number, • Health Level 7 (HL7®) Version 3.0.1 manufacturing date, expiration date, the Argonaut Data Query IG. The conformance resource includes the Fast Healthcare Interoperability and distinct identification code. ® complete list of actual profiles, RESTful Resources Specification (FHIR ) Release • National Council for Prescription operations, and search parameters 3 Standard for Trial Use (STU), April Drug Programs (NCPDP), Script supported by Argonaut Data Query 19, 2017 Standard Implementation Guide, Servers. Servers have the option of URL: http://hl7.org/fhir/STU3/ Version 2017071 (Approval Date for choosing from this list to access index.html. ANSI: July 28, 2017) necessary data based on their local use This is a direct access link. URL: http://www.ncpdp.org/ cases and other contextual Summary: The Fast Healthcare ® Standards/Standards-Info. requirements. Interoperability Resources (FHIR ) ® ® Standard for Trial Use (STU) Release 3 Access requires registration, • HL7 FHIR Foundation, Argonaut leverages the latest web standards and membership fee, a user account, and Data Query Implementation Guide, applies a tight focus on implementation. license agreement to obtain a copy of Version 1.0.0, December 23, 2016 the standard. FHIR solutions are built from a set of Summary: SCRIPT standards are URL: http://www.fhir.org/guides/ modular components called developed for transmitting prescription argonaut/r2/. ‘‘Resources’’. These resources can easily information electronically between This is a direct access link. be assembled into working systems that prescribers, pharmacies, payers, and Summary: The Argonaut Data Query solve real world clinical and other entities for new prescriptions, Implementation Guide is based upon administrative problems at a fraction of changes of prescriptions, prescription the core FHIR DSTU Release 2.0 API the price of existing alternatives. FHIR refill requests, prescription fill status and documents security and is suitable for use in a wide variety of notifications, cancellation notifications, authorization, data element query of the contexts—mobile phone apps, cloud relaying of medication history, ONC Common Clinical Data Set, and communications, EHR-based data transactions for long-term care, document query of static documents. sharing, server communication in large electronic prior authorization and other This specification describes four use institutional health care providers, and transactions. New transactions in this cases and sets search expectations for much more. This third STU release update include Prescription drug each. Argonaut uses the SMART Guide includes a significant increase in the administration message, New for apps that connect to EHR data. number of supported resources as well

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00135 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7558 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

as revisions to previously published Data for Interoperability (USCDI) the End-User in an interoperable and resources reflecting implementer standard. REST-like manner. This specification feedback and increased maturity and defines the core OpenID Connect • SMART Application Launch stability. functionality: Authentication built on Framework Implementation Guide top of OAuth 2.0 and the use of Claims • Health Level 7 (HL7®) Version 4.0.0 Release 1.0.0, November 13, 2018 to communicate information about the Fast Healthcare Interoperability URL: http://hl7.org/fhir/smart-app- End-User. It also describes the security Resources Specification (FHIR®) Release launch/. and privacy considerations for using 4, December 27, 2018 This is a direct access link. OpenID Connect. URL: http://hl7.org/fhir/R4/. Summary: SMART on FHIR provides This is a direct access link. reliable, secure authorization for a XII. Response to Comments Summary: The Fast Healthcare variety of app architectures through the Because of the large number of public Interoperability Resources (FHIR®) use of the OAuth 2.0 standard. This comments normally received in Release 4 provides the first set of Authorization Guide supports the four response to Federal Register normative FHIR resources. This uses cases defined for Phase 1 of the documents, we are not able to normative designation means that the Argonaut Project. This profile is acknowledge or respond to them future changes will be backward intended to be used by developers of individually. We will consider all compatible for the first time. These apps that need to access FHIR resources comments we receive by the date and resources define the content and by requesting access tokens from OAuth time specified in the DATES section of structure of core health data which can 2.0 compliant authorization servers. The this preamble, and, when we proceed be used by developers to build profile defines a method through which with a subsequent document, we will standardized applications. Release 4 an app requests authorization to access respond to the comments in the provides new standard operation on a FHIR resource, and then uses that preamble of that document. how to obtain data from multiple authorization to retrieve the resource. We note that, throughout this patients via FHIR. API services that Other Health Insurance Portability and proposed rule, we identified areas focus on multiple patients would enable Accountability Act (HIPAA)-mandated where we need more information before health care providers to manage various security mechanisms, such as end-user making a proposal (i.e., requests for internal patient populations as well as authentication, session time-out, information). We note that comments external services a health care provider security auditing, and accounting of we receive in response to these requests may contract for to support quality disclosures, are outside the scope of this for information will not necessarily be improvement, population health profile. addressed in the final rule, but will be management, and cost accountability used to inform future rulemaking. • IETF OAuth 2.0 Dynamic Client vis-a`-vis the provider’s partners (e.g., Registration Protocol (RFC 7591), July XIII. Collection of Information health plans). 2015 Requirements • ® Health Level 7 (HL7 ) URL: https://tools.ietf.org/html/ The Paperwork Reduction Act of 1995 Implementation Specification—FHIR rfc7591. (PRA) requires agencies to provide a 60- Profile: Consent2Share FHIR Consent This is a direct access link. day notice in the Federal Register and Profile Design, December 11, 2017 Summary: This specification defines solicit public comment on a proposed URL: https://gforge.hl7.org/gf/project/ mechanisms for dynamically registering collection of information before it is cbcc/frs/?action=FrsRelease OAuth 2.0 clients with authorization submitted to the Office of Management View&release_id=1259. servers. Registration requests send a set and Budget for review and approval. In The standard can be accessed through of desired client metadata values to the order to fairly evaluate whether an this link. authorization server. The resulting information collection should be Summary: The Consent2Share FHIR registration responses return a client approved by the OMB, section Consent Profile Design provides identifier to use at the authorization 3506(c)(2)(A) of the PRA requires that instructions for using the FHIR server and the client metadata values we solicit comment on the following ‘‘Consent’’ resource to capture a record registered for the client. The client can issues: of a health care consumer’s privacy then use this registration information to 1. Whether the information collection preferences. Implementing an instance communicate with the authorization is necessary and useful to carry out the of the FHIR Consent resource based on server using the OAuth 2.1 protocol. proper functions of the agency; this guide allows for a patient consent This specification also defines a set of 2. The accuracy of the agency’s to permit or deny identified recipient(s) common client metadata fields and estimate of the information collection or recipient role(s) to perform one or values for clients to use during burden; more actions regarding a patient’s health registration. 3. The quality, utility, and clarity of information for specific purposes and the information to be collected; and • OpenID Connect Core 1.0 periods of time. 4. Recommendations to minimize the Incorporating Errata Set 1, November 8, information collection burden on the • API Resource Collection in Health 2014 affected public, including automated (ARCH) Version 1 URL: http://openid.net/specs/openid- collection techniques. URL: https://www.healthit.gov/ARCH. connect-core-1_0.html. Under the PRA, the time, effort, and This is a direct access link. This is a direct access link. financial resources necessary to meet Summary: The API Resource Summary: OpenID Connect 1.0 is a the information collection requirements Collection in Health (ARCH) is an simple identity layer on top of the referenced in this section are to be implementation specification that list a OAuth 2.0 protocol. It enables Clients to considered. We explicitly seek, and will set of base FHIR resources that Health verify the identity of the End-User based consider, public comment on our IT Modules would need to support. The on the authentication performed by an assumptions as they relate to the PRA ARCH aligns with, and is directed by, Authorization Server, as well as to requirements summarized in this the data policy specified in the US Core obtain basic profile information about section. To comment on the collection

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00136 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7559

of information or to obtain copies of the ONC–ACBs will face minimum burden these conclusions and the supporting supporting statements and any related in complying with these new proposed rationale on which they are based. For forms for the proposed paperwork requirements. costs estimates of these proposed new collections referenced in this section, As proposed for § 170.523(t), ONC– regulatory requirements, we refer email your comment or request, ACBs would ensure health IT readers to section XIV. (Regulatory including your address and phone developers opting to take advantage of Impact Analysis) of this proposed rule. number to [email protected], or the Standard Version Advancement call the Reports Clearance Office at Process flexibility per § 170.405(b)(5) B. Health IT Developers provide timely advance written notice (202) 690–6162. Written comments and We propose in 45 CFR to the ONC–ACB and all affected recommendations for the proposed 170.580(a)(2)(iii) that ONC may take customers. ONC–ACBs would maintain information collections must be directed action against a health IT developer for a record of the date of issuance and the to the OS Paperwork Clearance Officer failure to comply with Conditions and content of developers’ notices, and at the above email address within 60 Maintenance of Certification timely post content of each notice days. requirements. We proposed to generally received publicly on the CHPL use the same processes previously A. ONC–ACBs attributed to the certified Health IT codified in regulation (§§ 170.580 and We propose to add new ONC–ACB Module(s) to which it applies. We 170.581) to take administrative collection and reporting requirements believe this will require minimal effort enforcement action. These processes for the certification of health IT to the on behalf of ONC–ACBs as the would require health IT developers to 2015 Edition (and any subsequent submission part will be electronically submit information to ONC to facilitate edition certification) in § 170.523(p), (q), facilitated via the CHPL. and conclude its review. The PRA, (t), and § 170.550(1). In the 2015 Edition proposed rule (80 As proposed for §§ 170.550(l), ONC– FR 16894), we estimated fewer than ten however, exempts these information ACBs would not be able to certify health annual respondents for all of the collections. Specifically, 44 U.S.C. IT until they review and verify health IT regulatory ‘‘collection of information’’ 3518(c)(1)(B)(ii) excludes collection developers’ attestations confirming that requirements that applied to the ONC– activities during the conduct of the developers are compliant with AA and ONC–ACBs, including those administrative actions or investigations Conditions and Maintenance of previously approved by OMB. In the involving the agency against specific Certification requirements. ONC–ACBs 2015 Edition final rule (80 FR 62733), individuals or entities. would also submit the health IT we concluded that the regulatory We propose in 45 CFR 170.402(b)(1) developer attestations to ONC as ‘‘collection of information’’ that a health IT developer must, for a proposed by § 170.523(q). We believe requirements for the ONC–AA and the period of 10 years beginning from the this will require minimal effort on ONC–ACBs were not subject to the PRA date each of a developer’s health IT is behalf of ONC–ACBs as the ONC under 5 CFR 1320.3(c). We continue to first certified under the ONC Health IT submission part will be electronically estimate less than ten annual Certification Program, retain all records facilitated via the CHPL. respondents for all of the proposed and information necessary to As proposed for § 170.523(p)(3), regulatory ‘‘collection of information’’ demonstrate initial and ongoing ONC–ACBs would be required to collect requirements for ONC–ACBs under Part compliance with the requirements of the and report certain information to ONC 170 of Title 45, including those ONC Health IT Certification Program. related to real world testing plans and previously approved by OMB and We believe it will take approximately results. ONC–ACBs would be required proposed in this proposed rule. two hours per week on average to to verify that the health IT developer Accordingly, the regulatory ‘‘collection comply with our proposed record submits an annual, publicly available of information’’ requirements under the retention requirement. We welcome real world testing plan and perform a Program described in this section are comments if stakeholders believe more completeness check for both real world not subject to the PRA under 5 CFR or less time should be included in our testing plans and results. We believe 1320.3(c). We welcome comments on estimate.

TABLE 4—ESTIMATED ANNUALIZED TOTAL BURDEN HOURS FOR HEALTH IT DEVELOPERS TO COMPLY WITH RECORDS 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

XIV. Regulatory Impact Analysis stakeholders include the: (1) Proposals While much of the costs of this to update the 2015 Edition health IT proposed rule will fall on health IT A. Statement of Need certification criteria; (2) proposals developers that seek to certify health IT This proposed rule is necessary to related to Conditions and Maintenance under the ONC Health IT Certification meet our statutory responsibilities of Certification for a health IT Program (Program), we believe the under the 21st Century Cures Act (Cures developer; (3) proposals related to implementation and use of health IT Act) and to advance HHS policy goals oversight for the Conditions and certified to the 2015 Edition (including to promote interoperability and mitigate Maintenance of Certification; and (4) the new criteria in this proposed rule), burden for stakeholders. Proposals that proposals related to information compliance with the Conditions and could result in monetary costs for blocking. Maintenance of Certification, and the

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00137 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7560 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

limited exceptions to information 1. Executive Orders 12866 and 13563— Maintenance of Certification; and (5) blocking proposed would ultimately Regulatory Planning and Review information blocking. result in significant benefits for health Analysis In accordance with Executive Order 12866, we have included the RIA care providers and patients. We outline Executive Orders 12866 on Regulatory summary table as Table 25. In addition, some of these benefits below. We Planning and Review and 13563 on we have included a summary to meet emphasize in this regulatory impact Improving Regulation and Regulatory analysis (RIA) that we believe this the regulatory reform analysis Review direct agencies to assess all proposed rule would create requirements under Executive Order costs and benefits of available regulatory opportunities for new market entrants 13771. alternatives and, if regulation is and would remove barriers to We note that we have rounded all necessary, to select regulatory interoperability and electronic health estimates to the nearest dollar and that approaches that maximize net benefits information exchange, which would all estimates are expressed in 2016 (including potential economic, greatly benefit health care providers and dollars as it is the most recent data environmental, public health and safety patients. available to address all cost and benefit effects, distributive impacts, and We note in this RIA that there were estimates consistently. We also note that equity). A regulatory impact analysis instances in which we had difficulty estimates presented in the following (RIA) must be prepared for major rules quantifying certain benefits due to a ‘‘Employee Assumptions and Hourly with economically significant effects lack of applicable studies and/or data. Wage,’’ ‘‘Quantifying the Estimated ($100 million or more in any one year). However, in such instances, we Number of Health IT Developers and OMB has determined that this proposed highlight the significant qualitative Products,’’ and ‘‘Number of End Users rule is an economically significant rule benefits of our proposals to advance an that Might Be Impacted by ONC’s as the potential costs associated with interoperable health system that Proposed Regulations’’ sections are used this proposed rule could be greater than empowers individuals to use their throughout this RIA. electronic health information (EHI) to $100 million per year. Accordingly, we For proposals where research the fullest extent and enables health have prepared an RIA that to the best of supported direct estimates of impact, we care providers and communities to our ability presents the costs and estimated the benefits. For proposals deliver smarter, safer, and more efficient benefits of this proposed rule. where no such research was identified care. 2. Executive Order 13771—Reducing to be available, we developed estimates B. Alternatives Considered Regulation and Controlling Regulatory based on a reasonable proxy. Costs We note that interoperability can We assessed whether there are positively impact patient safety, care Executive Order 13771 on Reducing alternatives to our proposals, coordination, and improve health care Regulation and Controlling Regulatory specifically our proposals concerning processes and health outcomes.144 Costs was issued on January 30, 2017 EHI export, application programming However, achieving interoperability is a and directs agencies to repeal two interfaces (APIs), and real world testing. function of a number of factors existing regulations for each new We have been unable to identify including the capability of the regulation issued in fiscal year (FY) alternatives that would appropriately technology used by health care 2017 and thereafter. It further directs implement our responsibilities under providers. Therefore, to assess the agencies, via guidance issued by the the Cures Act and support benefits of our proposals, we must first Office of Management and Budget interoperability. We believe our consider how to assess their respective (OMB), that the total incremental costs proposals take the necessary steps to effects on interoperability holding other of all regulations should be no greater fulfill the mandates specified in the factors constant. than zero in FY 2018. The analysis Public Health Service Act (PHSA), as For the purpose of this analysis, we required by Executive Order 13771, as amended by the Health Information used regression analysis to calculate the supplemented by Executive Order Technology for Economic and Clinical impact of our real world testing and API 13777, adds additional requirements for Health (HITECH) Act and the Cures Act, proposals on interoperability. We analysis of regulatory actions. The new in the least burdensome way. We are, assumed that the real world testing and requirements under Executive Orders however, open to less burdensome API proposals would collectively have 13771 and 13777 do not change or alternatives that meet statutory the same impact on interoperability as reduce existing requirements under requirements and our goals. health IT certified to the 2014 Edition. Executive Orders 12866 or 13563. Accordingly, we welcome comments on Therefore, we estimated linear our assessment and any alternatives we a. Costs and Benefits probability models that identified the should consider. impact of 2014 Edition certified health We have estimated the potential 145 C. Overall Impact monetary costs and benefits of this IT on hospitals’ interoperability. We We have examined the impact of this proposed rule for health IT developers, used data from the 2014 and 2015 proposed rule as required by Executive health care providers, patients, ONC- American Hospital Association (AHA) Order 12866 on Regulatory Planning Authorized Certification Bodies (ONC– Annual Survey Information Technology and Review (September 30, 1993), ACBs), ONC-Authorized Testing Supplement (IT Supplement), which Executive Order 13563 on Improving Laboratories (ONC–ATLs), and the consists of an analytic sample of 4,866 Regulation and Regulatory Review federal government (i.e., ONC), and observations of non-federal acute care (February 2, 2011), Executive Order have broken those costs and benefits out 144 https://www.qualityforum.org/Publications/ 13771 on Reducing Regulation and into the following categories: (1) 2017/09/Interoperability_2016-2017_Final_ Controlling Regulatory Costs, the Deregulatory actions (no associated Report.aspx. Regulatory Flexibility Act (5 U.S.C. 601 costs); (2) updates the 2015 Edition 145 The interoperability dependent variable is a et seq.), section 202 of the Unfunded Health IT certification criteria; (3) binary indicator for whether a hospital routinely sends, receives, and integrates summary of care Mandates Reform Act of 1995 (2 U.S.C. Conditions and Maintenance of records electronically outside of its system and 1532), and Executive Order 13132 on Certification for a health IT developer; finds any health information electronically outside Federalism (August 4, 1999). (4) oversight for the Conditions and of its system.

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00138 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7561

hospitals that responded to the IT data limitations, we believe this OMB requested that agencies generate Supplement.146 We controlled for approach allows us to estimate the cost and benefit estimates in 2016 additional factors such as participation benefits of our proposals without double dollars under Executive Order 13771. If in a health information exchange counting the impact each proposal we were to represent wage estimates in organization, hospital characteristics, might have on interoperability. 2017 dollars, then costs and benefits, and urban/rural status. More Employee Assumptions and Hourly including net benefits, would increase specifically, we used the following Wage by 4%. For our final rule, we will explanatory variables: consider using 2017 and even 2018 We have made employee assumptions Edition = 1 if a hospital adopted 2014 Edition dollars, if available, for our cost and EHR, 0 otherwise about the level of expertise needed to benefit estimates. complete the proposed requirements in RHIO = 1 if a hospital participates in health We welcome comments on our information exchange organization, 0 this section. For wage calculations for otherwise federal employees and ONC–ACBs, we methodology for estimating labor costs. Government = 1 if a hospital is publically have correlated the employee’s expertise Quantifying the Estimated Number of owned, 0 otherwise with the corresponding grade and step Health IT Developers and Products Alt_teaching = 1 if a hospital is teaching, 0 of an employee classified under the otherwise General Schedule (GS) Federal Salary In this section, we describe the Nonprofit = 1 if a hospital is not for profit, Classification, relying on the associated 0 otherwise methodology used to assess the Largebed = 1 if a hospital has more than 399 employee hourly rates for the potential impact of new 2015 Edition beds, 0 otherwise Washington, DC locality pay area as certification criteria on the availability Medbed = 1 if a hospital’s number of beds published by the Office of Personnel of certified products in the health IT is between 100 and 399, 0 otherwise Management for 2016.148 We have market. This analysis is based on the Urban_rural = 1 if a hospital is urban, 0 assumed that overhead costs (including number of certified health IT products otherwise benefits) are equal to 100% of pre-tax (i.e., Health IT Modules), product CAH = 1 if a hospital is critical access, 0 wages. Therefore, we have doubled the capability, and the number of health IT otherwise employee’s hourly wage to account for developers that left, merged, and/or Year = year of the data (2014 and 2015) overhead costs. We have concluded that S = state fixed effects entered the health IT market between a 100% expenditure on benefits is an the establishment of the Program and We found a statistically significant appropriate estimate based on research implementation of the 2011 Edition and marginal effect of using 2014 Edition 149 conducted by HHS. the implementation of the 2014 certified health IT associated with a five We have used Bureau of Labor Edition.150 percentage point increase in Statistics (BLS) data to calculate private interoperability.147 sector employee wage estimates (e.g., Market consolidation may occur as a While we acknowledge that there health IT developers, health care result of a natural evolvement of a new might be shared benefits across providers, HINs, attorneys, etc.), as we industry.151 We account for this factor proposals, we have taken steps to ensure believe BLS provides the most accurate in our analysis. In Table 5 below, we that the benefits attributed to each and comprehensive wage data for quantify the extent to which the proposal is unique to the proposal private sector positions. Just as with the certified health IT market consolidated referenced. We assumed that this General Schedule Federal Salary between the 2011 Edition and 2014 marginal effect is true for our proposals Classification calculations, we have Edition. We found that the number of and distributed the 5% benefit across assumed that overhead costs (including health IT developers certifying products our real world testing and API proposals benefits) are equal to 100% of pre-tax between the 2011 Edition and 2014 at (.1–1%) to (1–4%) respectively. wages. Edition decreased by 22.1% and the Moreover, the number of providers All wage estimates (GS and BLS) have number of products available decreased impacted is proposal specific. Given been calculated in 2016 dollars because by 23.2%.

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

Market 2011 Edition 2014 Edition consolidation (%)

Health IT Developers ...... 1,017 792 ¥22.1 Products ...... 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.

Not all products are certified to all of available in the Program. Modular developer to present a product for the edition’s certification criteria certification allows a health IT certification to a narrower scope of

146 American Hospital Association Health IT Planning and Evaluation (ASPE), Guidelines for J. David Cummins and Maria Rubio-Misas, Supplement Survey, http://www.ahadata.com/aha- Regulatory Impact Analysis, at 28–30 (2016), Deregulation, Consolidation, and Efficiency: healthcare-database/. available at https://aspe.hhs.gov/system/files/pdf/ Evidence from the Spanish Insurance Industry, _ 147 Results were similar when we used logit or 242926/HHS RIAGuidance.pdf. Journal of Money, Credit and Banking, Vol. 38, No. 150 Probit specifications. Availability of 2014 CEHRT for Meaningful 2 (Mar. 2006), at 323–55; Martin Gaynor and Users Providers, Health IT Policy Committee Data 148 Deborah Haas-Wilson, Change, Consolidation, and https://www.opm.gov/policy-data-oversight/ Update (Sept. 9, 2015), available at http:// pay-leave/salaries-wages/salary-tables/pdf/2016/ www.healthit.gov/FACAS/sites/faca/files/HITPC_ Competition in Health Care Markets, The Journal of DCB_h.pdf. Data_Update_Presentation_Final_2015-09-09.pdf. Economic Perspectives, Vol. 13, No. 1 (Winter 149 See U.S. Department of Health and Human 151 See Graeme K. Deans, Fritz Kroeger, and 1999), at 141–64. Services, Office of the Assistant Secretary for Stefan Zeisel, The Consolidation Curve (Dec. 2002);

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00139 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7562 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

specific use cases, which may be products and health IT developers in the 2014 totals reflect a realistic impacted at differing levels or may not the market, we have assumed: estimate of the currently available be impacted by the proposals in this 1. Products capable of recording EHI products and their developers that proposed rule. Therefore, we have will include new certification criteria. could include the new 2015 certification estimated the number of 2015 Edition We assume that products capable of criteria. recording patient health data will be the certified health IT products and health 3. Market consolidation rates denoted types of products most likely to be IT developers impacted by each in Table 5 hold constant. We assume impacted by and include the new proposal using proxies from historical that the rate of market consolidation for proposed certification criteria. data. Using the rates identified in Table products (¥23.2%) and health IT 2. Products capable of recording EHI ¥ 5, we then applied our estimate for data available in 2015 equal the number developers ( 22.1%) from the 2011 market consolidation to estimate the of products available in 2014. In 2014, Edition to the 2014 Edition holds number 2015 Edition certified health IT there were 710 products by 588 constant for the 2015 Edition. products and health IT developers that developers capable of recording EHI. As shown in Table 6 below, based on would be impacted by our policies in Since the new criteria involve the access the assumptions 1–3 above, we have this proposed rule. Specifically, to to and movement and exchange of EHI, estimated the total number of 2015 estimate the number of 2015 Edition we used only products that record EHI products (545) and their developers as a basis for our estimates. We believe (458).

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

Number of Number of Scenario health IT 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 practices 154 and 4,519 hospitals 155 will good faith effort to complete Impacted by ONC’s Proposed be impacted. randomized surveillance and the circumstances permitted for exclusion Regulations (1) Deregulatory Actions from this requirement found in For the purpose of this analysis, the Costs § 170.556(c)(5). population of end users differs We do not expect costs to be These proposals would reduce burden according to the regulatory action associated with the deregulatory action on health care providers by reducing proposed. In many cases, the end user proposals. their exposure to randomized in-the- population impacted is the number of Benefits field surveillance of their health IT hospitals and health care providers that products. Health care providers possess certified health IT. Due to data We expect the proposals for expressed concern about the time limitations, our analysis regarding the deregulatory actions to result in commitment to support ONC–ACB number of hospitals and health care significant benefits for health IT randomized surveillance of health IT providers impacted by the regulatory developers, providers, ONC–ACBs, products, particularly if no non- action is based on the number of ONC–ATLs, and ONC. These expected conformities with certified health IT hospitals and health care providers that benefits are detailed below. were found. Providers have generally have historically participated in the 1.1 Removal of the Randomized stated that reactive surveillance (e.g., Centers for Medicare & Medicaid Surveillance Minimum Threshold complaint-based surveillance) is a more Services (CMS) EHR Incentive Requirements logical and economical approach to surveillance of health IT products Programs. Although there are We have proposed to revise implemented in a health care setting. limitations to this approach, § 170.556(c) by revising the requirement participants in the CMS EHR Incentive that ONC–ACBs must conduct in-the- The proposal in this proposed rule Programs represent an adequate sample field, randomized surveillance and in its would provide health IT developers on which to base our estimates.152 We place specify that ONC–ACBs may more time to focus on interoperability. estimate 439,187 health care conduct in-the-field, randomized It would also provide ONC–ACBs more providers 153 in 95,470 clinical surveillance. We have further proposed time to respond to reactive surveillance, to remove § 170.556(c)(2), which including health care provider complaints about certified health IT. In 152 See Office of the National Coordinator for specifies that ONC–ACBs must conduct Health Information Technology, Office-based randomized surveillance for a minimum the 2015 Edition final rule, we did not Health Care Professionals Participating in the CMS of 2% of certified health IT products per independently estimate the costs for EHR Incentive Programs (Aug. 2017), year. We have also proposed to remove randomized surveillance. Rather, we dashboard.healthit.gov/quickstats/pages/FIG- the requirement that ONC–ACBs make a relied on prior regulatory cost estimates Health-Care-Professionals-EHR-Incentive- for all surveillance actions. One of our Programs.php; Office of the National Coordinator for Health Information Technology, Hospitals 154 This number was estimated based on the de- ONC–ACBs charges a $3,000 annual fee Participating in the CMS EHR Incentive Programs duplicated number of practices that had at least one per product for surveillance due to the (Aug. 2017), dashboard.healthit.gov/quickstats/ clinician participate in the CMS Medicare new randomized surveillance pages/FIG-Hospitals-EHR-Incentive-Programs.php. Electronic Health Record Incentive Program. requirements and to help normalize 153 This estimate is the total number of eligible 155 This estimate is the total number of eligible providers that ever participated in the CMS hospitals that ever participated in the CMS their revenue stream during down Medicare and Medicaid Electronic Health Record Medicare Electronic Health Record Incentive cycles between certification editions. Incentive Program. Program. Using this fee as a cost basis and

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00140 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7563

assuming it would apply to all certified 1.2 Removal of the 2014 Edition From are the direct result of 2014 Edition health IT (as opposed to the market- the Code of Federal Regulations certification maintenance; however, our adjusted universe of health IT that is We have proposed to remove the 2014 research indicates that it is significantly used in other calculations in this RIA), Edition certification criteria from the less profitable for ONC–ACBs to we estimate that our proposal to remove Code of Federal Regulations, which maintain 2014 Edition certification the randomized surveillance ‘‘2% would directly benefit health IT criteria (e.g., through ICS attestation and minimum threshold’’ requirements developers, ONC–ACBs, ONC–ATLs, reactive surveillance) than to certify would result in cost savings between and ONC and indirectly benefit health new 2014 Edition certified health IT $6.8 and $13.7 million for all care providers. When looking at the cost products. stakeholders. To arrive at this estimate, savings for removing the 2014 Edition We also attempted to identify a we multiplied the $3,000 annual fee per certification criteria, we considered the potential reduction in maintenance and product for surveillance by the total current costs for maintaining those administrative costs as a result of number of products certified to the 2014 certifications and their surveillance removing 2014 Edition certification Edition which was 4,559 products at the (reactive), as well as the maintenance criteria. We could not obtain data to time ($3,000 * 4,559 = $13.7 million). and administrative costs associated with conduct a full quantitative analysis We anticipate the number of products supporting customer use of certified specific to the reduction of health IT certified for 2014 to decrease to a little health IT for CMS EHR Incentive developer and health care provider costs as half of the original count over time. Program participation. The estimates related to supporting and maintaining Therefore, we estimated the low end to below consider ONC analysis of the the 2014 Edition. We seek comment on be half of the $13.7 million (.5 * $13.7 financial sustainability of ONC–ACBs methods to quantify potential costs for million = $6.8 million). This estimate is maintaining and supporting products to based on feedback we received from our and reflect data from as late as 2015. We estimate that health IT developers previous editions. ONC–ATL and ONC–ACB stakeholders. would realize monetary savings from no ONC–ACBs performed randomized We did conduct a review of academic longer supporting the 2014 Edition surveillance an average of 22 times the literature and qualitative analysis certification criteria due to a reduction first year the requirement was in effect. regarding potential savings from no The following year surveillance was in activities related to maintaining longer supporting the 2014 Edition. We performed an average of 2 times. We certification and surveillance. We are looked at data in IT industry systems as cannot predict how many randomized aware that one of our ONC–ACBs whole, which showed that upgrading surveillance events the ONC–ACBs will charges an inherited certified status outdated legacy systems saves resources perform now that we are not enforcing (ICS) fee of $1,000. This fee has been otherwise spent on maintaining the requirement. It will be completely at applied over the last calendar year. Over compatibilities to multiple systems and the discretion of the ONC–ACBs. that time period, the number of new, also increases quality and efficiency.156 We note that we considered other unique 2014 Edition products has been Furthermore, as technology evolves, potential benefits that we were unable declining (24 products in the last newer software and products allow for to quantify. We considered that health calendar year, and no new products in smoother updates compared to their care provider burden may decrease from the last four months) compared to the predecessors. Newer products provide the elimination of the 2% minimum number of ICS certifications (569). Just better security features that are able to threshold requirements because a assuming the cost of continued ICS address both new and existing issues. In provider would previously aid the certification, health IT developers addition, older software has an ONC–ACB in software demonstrations. would be paying approximately increased risk of failure, which, in the However, we acknowledge that in the $569,000 each year to keep their 2014 health IT industry, increases risk to long term and moving forward, Edition products up-to-date. patient safety. providers will likely be the party We are not aware of comparable fees charged by ONC–ATLs; however, based From the implementer’s perspective, reporting more of the complaints that the research indicates that retaining could result in reactive surveillance. We on our experience with the Program, we expect health IT developers would legacy systems tends to inhibit also considered that an additional scalability and growth for businesses. benefit of the proposal would be realize similar cost savings associated with ONC–ATL maintenance of the The perpetuity of outdated legacy reduced burden on ONC–ACBs. systems increases connection and Feedback from ONC–ACBs indicates testing component associated with ICS. system integration costs and limits the that having to meet a set number of Thus, we estimate an additional ability to realize increased efficiency surveillance activities in 12 months can $569,000 cost savings for health IT through IT implementation. Newer be quite burdensome, especially when developers due to the reduced testing products are developed to current factoring in the active engagement requirements. specifications and updated standards, necessary from provider participants. A recent study conducted by ONC which decreases barriers and marginal Last, we considered the potential benefit indicates that 2014 Edition ICS cost of ancillary product to health IT developers in having more certification is not profitable for ONC– implementation and increases the surveillance focused on situations ACBs, which is why one ONC–ACB accessibility of data in ancillary dealing with actual end-user concerns charged an additional $3,000 annual fee and/or difficulties. Health IT developers per product for surveillance for 2015 systems—including via mobile devices have indicated that they benefit from Edition certifications. In 2015, the net and the latest applications. Finally, such surveillance, as feedback about income for ONC–ACBs dropped 99% office staff in a health care setting would conformance and capability can from about $5,310,000 in 2014 to no longer need to be trained to improve their products. $67,000 due to a decline in revenue accommodate differing data access We welcome comments on potential from a drop in new 2014 Edition means, methods, and relevant certified health IT products without a 156 James Crotty and Ivan Horrocks, Managing legacy system costs: A case study of a meta- comparative studies and data that we significant drop in expenses. We do not assessment model to identify solutions in a large could use to better quantify these have enough information to calculate financial services company, Applied Computing benefits. what percentage of ONC–ACB expenses and Informatics (2017), at 1–9.

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00141 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7564 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

needs or workarounds required to studies and data that we could use to benefits for a GS–13, Step 1 employee integrate to the legacy product.157 quantify these benefits. located in Washington, DC is The research also indicates that We also expect that health care approximately $88.30. Therefore, we retaining legacy software would not be providers would benefit from this estimate the annual cost savings to be beneficial or profitable to the health IT proposal because such action would $3,238. market. Prolonging backwards likely motivate health IT developers to We estimate that ONC would commit compatibility of newer products to certify health IT products to the 2015 approximately eight hours of staff time legacy systems encourages market Edition, thus enabling providers to use to develop the Federal Register Notice, fragmentation.158 Limiting the most up-to-date and supported which would include approximately: fragmentation encourages innovation systems to care for patients. The 2015 Four hours for drafting and review by an and attracts more developers by Edition certification criteria facilitates analyst at the GS–13, Step 1 level; two reducing barriers and the marginal cost greater interoperability for several hours for review and analysis by senior of development to multiple platforms. clinical health information purposes certification staff at the GS–14, Step 1 Health IT stakeholders have expressed and enables health information level; and two hours for review and that system fragmentation increases the exchange, including APIs, through new submittal for publication by Immediate cost to develop and maintain health IT and enhanced certification criteria, Office staff at the GS–15, Step 1 level. connectivity for data exchange and to standards, and implementation The hourly wage with benefits for a GS– integrate software supporting specifications. The certification criteria 13, Step 1 employee located in administrative and clinical processes, as also allow for updates to documents and Washington, DC is approximately well as limiting the feasibility of data standards and focus on the $88.30. The hourly wage with benefits developing products to support establishment of an interoperable health for a GS–14, Step 1 employee located in specialty clinical care. This direct information infrastructure. We welcome Washington, DC is approximately feedback suggests that fragmentation is comments on potential means, methods, $104.34. The hourly wage with benefits having a negative impact on the and relevant comparative studies and for a GS–15, Step 1 employee located in interoperability and usability of health data that we could use to quantify these Washington, DC is approximately IT systems for health care providers. We benefits. $122.74. Therefore, we estimate the intend to encourage the health IT annual cost savings to be $269. 1.3 Removal of the ONC-Approved market to keep progressing with a Additionally, we estimate a cost of $477 Accreditor From the ONC Health IT baseline expectation of functionalities to publish each page in the Federal Certification Program that evolve over time. This requires Register, which includes operational limiting fragmentation by no longer We expect ONC to realize monetary costs. The Federal Register Notice for supporting outdated or obsolete legacy cost savings from the proposal to ONC–AAs requires, on average, one software.159 remove the ONC- Approved Accreditor page in the Federal Register (every three We also estimate that additional (ONC–AA) from the Program. We expect years), so we estimate an additional savings could be realized by reducing ONC to realize costs savings from no annual cost savings of $159. regulatory complexity and burden longer: (1) Developing and publishing a We estimate that ONC would commit caused by having two certification Federal Register Notice and listserv; (2) approximately two hours of staff time by editions. For example, in the 2015 monitoring the open application period an analyst at the GS–13, Step 1 level to Edition final rule, we added new and reviewing and making decisions draft, review, and publish the listserv to requirements, such as disclosure and regarding applications; and (3) oversight announce the Federal Register Notice. transparency requirements, that applied and enforcement of the ONC–AA. We The hourly wage with benefits for a GS– to all certified product editions. This have calculated the estimated annual 13, Step 1 employee located in required significant effort by health IT cost savings for this proposal, taking Washington, DC is approximately developers and ONC–ACBs to execute into consideration that the ONC–AA $88.30. Therefore, we estimate the the requirements, and both groups renewed its status every three years. annual cost savings to be $59. found it challenging to complete the The ONC–AA’s expertise is in the We estimate that ONC would commit task in the original timeframe provided ISO/IEC 17065 standard. Therefore, to approximately 25 hours of staff time to by ONC. We have observed that the task effectively collaborate with the ONC– manage the open application process, of managing two different editions AA for Program activities, ONC review applications and reach within different rules increases allocates resources for working with the application decisions, which would complexity and burden for ONC staff, ONC–AA and informing the ONC–AA of include approximately: 20 hours by an contractors, ONC–ACBs, CMS programs scheme requirements and applicable analyst at the GS–13, Step 1 level; three referencing the certification criteria, and policy interpretations, which we have hours by senior certification staff at the other stakeholders, as compared to our and can provide directly to the ONC– GS–14, Step 1 level; and two hours for proposal to remove the 2014 Edition ACBs. The amount of ONC resources review and approval by Immediate certification criteria. However, we are allocated depends on current Program Office staff at the GS–15, Step 1 level. unable to estimate these benefits activities and need. For our The hourly wage with benefits for a GS– because we have no means for calculations, we used the estimated 13, Step 1 employee located in quantifying the benefits gained from hours for collaborating with and Washington, DC is approximately only using the 2015 Edition. We informing an ONC–AA in 2017 (using $88.30. The hourly wage with benefits welcome comments on potential means, 2016 wage estimates). We estimate that for a GS–14, Step 1 employee located in methods, and relevant comparative ONC spent approximately 110 hours Washington, DC is approximately collaborating with the ONC–AA in $104.34. The hourly wage with benefits 157 Id. 2017, which includes (all at the GS–13, for a GS–15, Step 1 employee located in 158 Il-Horn Hann, Byungwan Koh, and Marius F. Step 1 level): Annual assessments; Washington, DC is approximately Niculescu, The Double-Edged Sword of Backward providing appropriate guidance; $122.74. Therefore, we estimate the Compatibility: The Adoption of Multigenerational Platforms in the Presence of Intergenerational implementing new requirements and annual cost savings to be $775. Services, Inform. Systems Res. (2016), at 112–30. initiatives; and consultations as Taking all of these potential costs 159 Id. necessary. The hourly wage with savings into consideration, we estimate

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00142 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7565

the overall annual costs savings for our cost for testing per criterion and incorporate the Common Clinical Data proposal to remove the ONC–AA from determined subsequent cost savings. In Set and essentially the same data input the Program to be $4,500. 2017, only about five to ten percent of and validation requirements as the products have been tested and certified transitions of care criterion 1.4 Removal of Certain 2015 Edition compared to the number of certified (§ 170.315(b)(1)). The removal of these Certification Criteria 2014 Edition products. Therefore, up to two criteria would not affect the test In section III.B.4 of this proposed rule, 90 to 95 percent of products remain to data and software maintenance costs, as we propose to remove the following be tested and certified to the 2015 the same test data and software certification criteria from the 2015 Edition. validation elements remain in Edition: § 170.315(b)(4) ‘‘Common We estimate the total cost savings by § 170.315(b)(1) and the Common Clinical Data Set summary—create;’’ multiplying the number of health IT Clinical Data Set used in other criteria. (b)(5) ‘‘Common Clinical Data Set developers who developed products for ONC–ACBs could realize minimal summary—receive’’, § 170.315(a)(10) certification to a certain criterion by the savings, as they would need to conduct ‘‘Drug formulary and preferred drug list estimated cost per criterion, $475. We slightly less surveillance based on the checks,’’ § 170.315(a)(11) ‘‘Smoking then took five percent of that number to two products that are currently certified status,’’§ 170.315(a)(13) ‘‘Patient- figure out the high end for the cost to these criteria. We expect these specific education resources’’ and savings. We then took 10 percent to potential cost savings to be de minimis § 170.315(e)(2) ‘‘Secure messaging.’’ figure out the low end. The five percent and have therefore not estimated them. For determining calculations for the was derived from looking at the number Taking all these potential costs majority of the proposed removal of of unique developers who have at least savings into consideration, we estimate certain 2015 Edition certification one active 2014 Edition product and the the overall annual costs savings for our criteria, we used the assumptions number of unique developers who have proposal to remove the Common below. For the proposed removal of at least one active 2015 Edition. The Clinical Data Set summary record § 170.315(b)(4) Common Clinical Data denominator is the number of unique certification criteria from the 2015 Set summary—create and (b)(5) developers who have at least one active Edition to be $4,238. We welcome Common Clinical Data Set summary— 2014 Edition product, which is 793. The comments on the above estimates and receive, we took a slightly different numerator is the number of unique methods we could use to better quantify approach discussed in section 1.4.1. developers who have at least one active these benefits. In the 2015 Edition final rule, we 2015 Edition product and one active estimated the costs for developing and 1.4.2 Drug Formulary and Preferred 2014 edition product, which is 41. (41/ Drug List Checks preparing health IT to meet the 2015 793 = 0.0517024 or 5 percent). Edition certification criteria. The We propose to remove the 2015 development and preparation costs we 1.4.1 Common Clinical Data Set Edition ‘‘drug formulary and preferred estimated were derived through a health Summary Record Criteria drug list checks’’ criterion in IT developer per criterion cost. We We propose to remove the Common § 170.315(a)(10)). To calculate the cost estimated the development and Clinical Data Set summary—create savings for removing this criterion, we preparation costs over a four-year period (§ 170.315(b)(4)) and Common Clinical used the 2015 Edition estimated costs and we projected the costs would be Data Set summary—receive for development and preparation for unevenly distributed. In figuring out the (§ 170.315(b)(5)) criteria. this criterion which were between cost savings for the deregulatory actions, We expect ONC to realize cost savings $15,750 and $31,500. We believe that we initially used the distribution from associated with internal infrastructure 35% of developers would be still newly the 2015 Edition, but then adjusted the support and maintenance, which would certifying in 2018 and 15% in 2019 and percentages of development and include actions such as (1) developing applied the proportions respectively. preparation costs due to current and maintaining information regarding We estimated the cost of development empirical and anecdotal evidence. The these criteria on the ONC website; (2) and preparation costs to be between distribution was reevaluated to account creating documents related to these $5,512.50 and $11,025 for 2018 and for 2019 and we estimate the actual criteria and making those documents $2,362.50 and $4,725 for 2019. We development and preparation 508 compliant; (3) updating, revising, calculated the cost per month for years distribution for 2018 to be 35% and for and supporting Certification Companion 2018 and 2019 and using the high point 2019 to be 15%. We took the average Guides, test procedures, and test tools; estimates, estimated the development development and preparation cost and (4) responding to inquiries and preparation costs over a 6 to 12 estimates (low and high) per criterion concerning these criteria. Based on ONC month period between August 2018 to from Table 14 of the 2015 Edition final data on the number of inquiries received August 2019 to be between $4,068.75 rule (80 FR 62737). We then used our since early 2016, we estimate and $6,825. new distribution to figure out the cost approximately 12 annual inquiries To calculate the cost for testing for per year for years 2018 and 2019. We about § 170.315(b)(4) and (5) this criterion, we multiplied the 5 took the total estimated costs for 2018 respectively (24 total inquiries for two developers that we estimated in the and 2019 and divided that by 12 to criteria). We estimate it will take an 2015 Edition to develop products to this determine the cost savings per month analyst at the GS–13, Step 1 level an criterion by our estimated cost to test and took a range of 6–12 months. average of two hours to conduct all tasks per criterion of $475. The estimated cost To determine the testing costs of the associated with each inquiry. The per criterion was based on what one deregulatory actions, we took the hourly wage with benefits for a GS–13, ONC–ATL charged for testing and number of health IT developers who Step 1 employee located in Washington, averaged per criterion. To be develop products for certification for the DC is approximately $88.30. Therefore, conservative in our calculations, we identified criteria from the 2015 Edition we estimate the annual cost savings to reduced the number by 10% and 5% final rule and then figured out the be $4,238. respectively resulting in $2,137.50 and average cost per criterion. Based on the We do not expect cost savings $2,256.25. costs that one of the ONC–ATLs charges associated with software maintenance Taking these estimated costs into for testing, we estimated the average because both of these criteria account we expect cost savings to

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00143 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7566 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

remove the 2015 Edition ‘‘drug preparation costs over a 6 to 12 month ONC–ACBs to ensure that certified formulary and preferred drug list period, within August 2018 to August health IT includes a detailed description checks’’ criterion to be between 2019. We estimated the costs to be of all known material information $8,962.50 and $9,081.25. between $850,395 at 6 months and concerning limitations that a user may $1,360,632 at 12 months. To calculate encounter in the course of 1.4.3 Smoking Status the testing cost for this criterion, we implementing and using the certified We propose to remove the 2015 multiplied the estimates from the 2015 health IT, whether to meet ‘‘meaningful Edition ‘‘smoking status’’ criterion Edition of 249 developers that we use’’ objectives and measures or to (§ 170.315(a)(11)), which would include estimated would develop products to achieve any other use within the scope removing it from the 2015 Edition Base this criterion by our estimated cost to of the health IT’s certification. We also EHR definition. To calculate the cost test per criterion of $475. The estimated propose to remove § 170.523(k)(1)(iv)(B) savings for removing this criterion, we cost per criterion was based on what and (C), which state that the types of used the 2015 Edition estimated costs of one ONC–ATL charged for testing and information required to be disclosed developing and preparing the criterion averaged per criterion. To be include but are not limited to: (B) to the 2015 Edition, between $15,750 conservative, we reduced the number by Limitations, whether by contract or and $31,500 and estimated that 35% of 10% and 5% respectively resulting in otherwise, on the use of any capability developers would be newly certified in $106,447.50 and $112,361.25. Taking to which technology is certified for any 2018 and 15% in 2019. We estimated these estimated costs into account, we purpose within the scope of the the cost of development and preparation expect the cost savings of removing the technology’s certification; or in costs to be between $5,512.50 and 2015 Edition ‘‘Patient-specific education connection with any data generated in $11,025 for 2018 and $2,362.50 and resources’’ criterion to be between the course of using any capability to $4,725 for 2019. We calculated the cost $1,467,079.50 and $1,472,993.25. which health IT is certified; (C) per month for years 2018 and 2019 and Limitations, including but not limited to 1.4.5 Secure Messaging using the high point estimates, technical or practical limitations of estimated the development and We propose to remove the 2015 technology or its capabilities, that could preparation costs over a 6 to 12 month Edition ‘‘secure messaging’’ criterion prevent or impair the successful period between August 2018 and (§ 170.315(e)(2)). To estimate the cost implementation, configuration, August 2019. We estimated the costs to savings of removing this criterion, we customization, maintenance, support, or be between $4,068.75 at 6 months and used the estimates from the 2015 use of any capabilities to which $6,825 at 12 months. Edition final rule for development and technology is certified; or that could To calculate the cost for testing for preparation costs which is between prevent or limit the use, exchange, or this criterion, 5 developers were $1,552,320 and $3,104,640. We portability of any data generated in the estimated in the 2015 Edition to develop estimated that 35% of developers would course of using any capability to which products to this criterion. We multiplied be still newly certifying in 2018 and technology is certified. the 5 developers by our estimated cost 15% in 2019 and applied the To calculate the savings related to to test per criterion of $475. This proportions respectively. We estimated removing these two disclosure estimated cost per criterion was based the cost of development and preparation requirements, we estimated 830 on what one ONC–ATL charged for costs to be between $543,312 and products certified to the 2015 Edition. testing and averaged per criterion. To be $1,086,624 for 2018 and $232,848 and We did so by applying the market conservative, we reduced the number by $465,696 for 2019. We then calculated consolidation rate of ¥23.2% which 10% and 5% respectively resulting in the cost per month for years 2018 and was the rate observed between 2011 and $2,137.50 and $2,256.25. 2019 and using the high point estimates, 2014 Editions. Assuming that an ONC– Taking these estimated costs into estimated the development and ACB spends 1 hour on average account we expect cost savings to preparation costs over a 6 to 12 month reviewing costs, limitations and remove the 2015 Edition ‘‘smoking period, between August 2018 to August mandatory disclosures, we estimate the status’’ criterion to be between 2019 to be between $401,016 at 6 time saved by no longer having to $8,962.50 and $9,081.25. months and $672,672 at 12 months. To review the limitations to be two-thirds calculate the cost for testing this 1.4.4 Patient-Specific Education of an hour. The hourly wage with criterion, we multiplied the 246 Resources benefits for a GS–13, Step 1 employee developers that we estimated in the located in Washington, DC is We propose to remove the 2015 2015 Edition would develop products to approximately $88.30 and we assume Edition ‘‘patient-specific education this criterion by our estimated cost to this to be the hourly rate for an ONC– resources’’ certification criterion test per criterion of $475. The estimated ACB reviewer. We multiplied 830, the (§ 170.315(a)(13)). To estimate the cost cost per criterion was based on what projected number of certified products, of removing this criterion, we used the one ONC–ATL charged for testing and by two- thirds of an hour and the 2015 Edition estimated costs for averaged per criterion. To be assumed hourly rate and calculated the development and preparation which is conservative, we reduced the number by cost savings to be $48,859. between $4,709,880 and $6,279,840. We 10% and 5%, respectively, resulting in (2) Updates to the 2015 Edition believe that 35% of developers would $105,165 and $111,007.50. Taking these Certification Criteria be still newly certifying in 2018 and estimated costs into account, we 15% in 2019 and applied the estimate the cost savings of removing The following section details the costs proportions respectively. We estimated the 2015 Edition ‘‘Secure messaging’’ and benefits for updates to the 2015 the cost of development and preparation criterion to be between $777,837 and Edition health IT certification criteria, to be between $1,648,458 and $783,678.50. which includes (1) costs and benefits to $2,197,944 for 2018 and $706,482 and update certain 2015 Edition criteria to $941,976 for 2019. We calculated the 1.5 Removal of Certain Certification due to the adoption of the United States cost per month for years 2018 and 2019 Requirements Core Data for Interoperability (USCDI) and using the high point estimates, We propose to remove as a standard and (2) costs for new 2015 estimated the development and § 170.523(k)(1)(iii)(B), which requires Edition criteria for electronic health

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00144 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7567

information export, API, privacy and the CCDS, which will require updates to develop support for the additional security, and Data Segmentation for the Consolidated Clinical Document USCDI data element in the C–CDA Privacy (DS4P)-Send and Data Architecture (C–CDA) standard and standard and affected certification Segmentation for Privacy-Receive, and updates to the following certification criteria. We recognize that health IT consent management for APIs. criteria: § 170.315(b)(1) (transitions of developer costs will vary; however, our care); (e)(1) (view, download, and estimates in this section assume all 2.1 United States Core Data for transmit to 3rd party); (g)(6) health IT developers will incur the costs Interoperability (Consolidated CDA creation noted in Table 7. In order to advance interoperability performance); (f)(5) (transmission to 2. A proxy is needed to project the by ensuring compliance with new public health agencies—electronic case number of 2015 Edition certified health structured data and code sets that reporting); and (g)(9) (application IT products. We estimate that 545 support the data, we propose in this access—all data request). From our products from 458 developers will be proposed rule to remove the ‘‘Common analysis of the C–CDA standard, we affected by our proposal. Our proxy is Clinical Data Set’’ definition and its conclude that the requirements of based on the number of 2014 Edition references from the 2015 Edition and ‘‘Provenance’’ data class are already met certified health IT products that are replace it with the ‘‘United States Core by the existing C–CDA standard, and capable of recording patient data.160 Data for Interoperability’’ (USCDI) will not require any new development. There were 710 products by 588 standard, naming Version 1 (v1) in Therefore, we have estimated the developers with at least one 2014 § 170.213 and incorporating it by proposed cost to health IT developers to Edition product capable of recording reference in § 170.299. The USCDI v1 add support for ‘‘Clinical Notes’’ data patient data. We then multiplied these establishes a minimum set of data class in C–CDA, and the necessary numbers by our certified health IT classes (including structured data) that updates to the affected certification market consolidation estimates of are required for health IT to be criteria. These estimates are detailed in ¥22.1% and ¥23.2% to project the interoperable nationwide and is Table 7 below and are based on the number of 2015 developers and designed to be expanded in an iterative following assumptions: products, respectively. and predictable way over time. 1. Health IT developers will use the 3. According to the May 2016 BLS The USCDI v1 adds 2 new data same labor costs and data models. Table occupational employment statistics, the classes, ‘‘Clinical Notes’’ and 7 shows the estimated labor costs per mean hourly wage for a ‘‘Software ‘‘Provenance’’ that were not defined in product for a health IT developer to Developer’’ is $50.14.161

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

Lower Upper Tasks Details bound hours bound hours Remarks

Update C–CDA creation)...... New development to support 800 1,800 (1) Lower bound assumes health ‘‘Clinical Notes’’ for C–CDA and IT already has developed C– C–CDA 2.1 Companion Guide. CDA R2.1 into their system and only needs to be updated for new data class. (2) Upper bound estimates effort 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 200 600 Necessary updates to health IT to ‘‘Clinical Notes’’ for C–CDA and support the new data class to C–CDA 2.1Companion Guide. meet the criteria requirements. § 170.315(b)(6) (data export)...... New development to support 300 800 Necessary updates to health IT to ‘‘Clinical Notes’’ for C–CDA and support the new data class to C–CDA 2.1 Companion Guide. meet the criteria requirements. § 170.315(e)(1) (view, download, New development to support 400 1,000 Necessary updates to health IT to and transmit to 3rd party). ‘‘Clinical Notes’’ for C–CDA and support the new data class to C–CDA 2.1Companion Guide. meet the criteria requirements. § 170.315(g)(6) (Consolidated CDA New development to support 200 600 170.315(b)(1) and § 170.315(g)(6) creation performance). ‘‘Clinical Notes’’ for C–CDA and are related and may be devel- C–CDA 2.1 Companion Guide. oped together.

Total Hours ...... 1,900 4,800

Hourly Rate ...... $100.28

Cost per Product ...... $190,532 $481,344

Total Cost (545 products) ...... $103.8M $262.3M

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

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00145 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7568 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

We estimate that the cost to a health 2.2 Electronic Health Information product for a health IT developer to IT developer to develop support for the Export develop and maintain the electronic additional USCDI data element would We have proposed a new 2015 Edition health information export functionality. range from $190,532 to $481,344. certification criterion for ‘‘electronic We recognize that health IT developer Therefore, assuming 545 products, we health information export’’ in costs will vary; however, our estimates estimate that the total annual cost to all § 170.315(b)(10). The intent of this in this section assume all health IT health IT developers would, on average, criterion is to provide patients and developers will incur the costs noted in range from $103.8 million to $262.3 health IT users a means to efficiently Table 8. million. This would be a one-time cost export the entire electronic record for a 2. A proxy is needed to project the to developers per product that is single patient or all patients in a number of 2015 Edition certified health certified to the specified certification computable, electronic format. Further, IT products containing the ‘‘electronic criteria and would not be perpetual. it would facilitate the receiving health health information export’’ certification criterion. We estimate that 545 products We believe this proposal would IT system’s interpretation and use of the EHI to the extent reasonably practicable from 458 developers will contain the benefit health care providers, patients, using the health IT developer’s existing ‘‘electronic health information export’’ and the industry as a whole. Clinical technology. This outcome would criterion. To develop these estimates we notes and provenance were included in promote exchange, access, and use of first identified a proxy for the number the draft USCDI v1 based on significant electronic health information. It would of health IT developers that may create feedback from the industry, which also facilitate health care providers’ a 2015 Edition certified health IT highly regarded their desirability as part ability to switch health IT systems or product containing the ‘‘electronic of interoperable exchanges. The free text migrate electronic health information health information export’’ criterion. portion of the clinical notes was most for use in other technologies. This Our proxy is based on the number of often relayed by clinicians as the data proposed criterion supports two specific 2014 Edition certified health IT they sought, but were often missing use cases. First, it supports the export products that are capable of recording during electronic health information for a single patient that would need to patient data.162 We based our estimates exchange. Similarly, the provenance of be enabled upon valid request from a on these products because data must be data was also referenced by stakeholders user or a patient. Second, the EHI export captured to be exported under the as a fundamental need to improve the functionality for all patients’ data would proposed criterion. There were 710 trustworthiness and reliability of the support a health care provider or health products by 588 developers with at least data being exchanged. We expect system in switching health IT systems. one 2014 Edition product capable of recording patient data. We then improvements to interoperable Costs exchange of information and data multiplied these numbers by our certified health IT market consolidation provenance to significantly benefit This section describes the estimated estimates of ¥22.1% and ¥23.2% to providers and patients. However, we are costs of the ‘‘electronic health project the number of 2015 developers not aware of an approach for information export’’ certification criterion. The cost estimates are based and products, respectively. quantifying these benefits and welcome on the following assumptions: 3. According to the May 2016 BLS comments on potential approaches to 1. Health IT developers will use the occupational employment statistics, the quantifying these benefits. same labor costs and data models. Table mean hourly wage for a ‘‘Software 8 shows the estimated labor costs per Developer’’ is $50.14.163

TABLE 8—ESTIMATED LABOR COSTS TO DEVELOP AND MAINTAIN THE ELECTRONIC HEALTH INFORMATION EXPORT CRITERION PER PRODUCT

Lower Upper Activity bound hours bound 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 and exporting the EHI in a single patient and for all patients. The lower bound assumes that the developer format (per product). health IT developer already has a 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 document the data output. This still as- sumes that the developer will be able to use the format of their choice. Note: This is a one-time cost to develop the export capability. Task 2: Maintaining the Data Dic- 80 800 This is the annual maintenance cost charged by health IT developers to tionary and performing export provide C–CDA feed to providers. This is a yearly update to products when requested (per product). that are typically modest. The lower bound estimate assumes the ef- fort when there are only minor changes to the product. The upper bound estimate assumes the effort when the product supports a sub- stantial number of new data classes.

162 We defined ‘‘products capable of recording Demographics ((a)(5)), Medication List ((a)(7)), 163 https://www.bls.gov/oes/2016/may/ patient data’’ as any 2014 Edition product that was Medication Allergy List ((a)(8)), Problem List oes439061.htm. certified for at least one of the following criteria: ((a)(6)), and Family Health History ((a)(12)).

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00146 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7569

TABLE 8—ESTIMATED LABOR COSTS TO DEVELOP AND MAINTAIN THE ELECTRONIC HEALTH INFORMATION EXPORT CRITERION PER PRODUCT—Continued

Lower Upper Activity bound hours bound hours Remarks

Task 3: Maintaining the software to 80 800 This is the annual cost to update the software that would generate the perform the electronic health in- data access files. The lower bound estimates the cost to maintain the formation export (per product). software when there are minor changes to the product, including up- dates to underlying software (e.g., database versions, operating sys- tems, etc.). The upper bound estimate accounts for substantial re- working of the export software program to support new data classes or new data formats.

Total Labor Hours ...... 320 3,200

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

Estimated Developer labor hours salary Projected lower bound (per hour) products

Task 1 ...... 160 $100.28 545

Example Calculation: 160 hours × $100.28 × 545 products = $8,744,416.

TABLE 10—TOTAL COST TO DEVELOP AND MAINTAIN THE ELECTRONIC HEALTH INFORMATION EXPORT CRITERION [2016 Dollars]

Estimated cost Activity Lower bound Upper bound

Task 1 (545 products) ...... $8,744,416 $87,444,160 Task 2 (545 products) ...... 4,372,208 43,722,080 Task 3 (545 products) ...... 4,372,208 43,722,080

Total (545 products) ...... 17,488,832 174,888,320

Based on the stated assumptions and information export functionality 2. Health IT consultants 164 will use costs outlined in Table 8, the total compared to performing data export the same labor costs and data models. estimated cost for health IT developers without the electronic health Table 11 shows the estimated labor to develop products to the electronic information export functionality. The costs per product for a hospital or health health information export certification benefit calculations below are based on care provider to hire a health IT criterion will range from $17.5 million the following assumptions: consultant to perform data export to $174.9 million. Assuming 458 health 1. On average, 5% of providers and without the electronic health IT developers, there would be an hospitals switch their health IT information export functionality. We average cost per health IT developer annually. Using CMS Medicare EHR recognize that these costs will vary Incentive Program data from years ranging from $38,185 to $381,852. The based on the size of the hospital or 2013–2016, we estimate the rate of midpoint of ranges stated is used as the clinical practice. primary estimate of costs and benefits. providers (hospitals and eligible We note that the development costs, professionals) that changed their health 3. According to the May 2016 BLS which equal half of the total, would be IT developer. We believe that the occupational employment statistics, the a one-time cost and would not be electronic health information export mean hourly wage for a ‘‘Software perpetual. functionality would help alleviate the Developer’’ is $50.14.165 burden of switching between health IT Benefits systems by making data more portable. There are a number of benefits to the Thus, the benefit calculations are based 164 ‘‘Health IT consultant’’ refers to a technical electronic health information export on assumptions regarding the number of expert that a hospital or provider will hire to migrate their data from a legacy system to a new functionality. In our analysis, we have clinical practices (n = 4,774) and EHR. calculated the benefits in terms of the hospitals (n = 226) that are projected to 165 https://www.bls.gov/oes/2016/may/ reduced costs of the electronic health switch products in a year. oes439061.htm.

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00147 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7570 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

TABLE 11—COST PER PROVIDER TO PERFORM DATA EXPORT WITHOUT ELECTRONIC HEALTH INFORMATION EXPORT FUNCTIONALITY WHEN SWITCHING HEALTH IT PRODUCTS

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

Task 1: Understanding and map- 320 3,200 The lower bound is an estimate for a small provider practice using the ping the data in health IT data- standard instance of a certified health IT product with no base into standard terms. customization and use of nationally recognized content standards. The upper bound estimates a medium to large practice with substan- tial local customization of content. Task 2: Exporting the data from the 160 1,600 The lower bound assumes that the certified health IT product is capable health IT into a format that can be of exporting most of the data into standard output format such as C– subsequently used to import. CDA. The upper bound estimates the case where a large amount of data is not easily exported by the certified 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 12 provides an example calculation for how we calculated our total costs presented in table 13.

TABLE 12—EXAMPLE CALCULATION FOR THE LOWER BOUND ESTIMATED COST TO PROVIDERS TO HIRE A HEALTH IT CONSULTANT TO PERFORM TASK 1 WITHOUT THE ELECTRONIC HEALTH INFORMATION FUNCTIONALITY [2016 Dollars]

Estimated Estimated Developer annual labor hours salary number of lower bound (per hour) health IT switches

Task 1 ...... 320 $100.28 5,000

Example Calculation 320 hours × $100.28 × 5,000 switches = $160,448,000

TABLE 13—TOTAL COST TO PROVIDERS TO PERFORM DATA EXPORT WITHOUT THE ELECTRONIC HEALTH INFORMATION EXPORT FUNCTIONALITY WHEN SWITCHING HEALTH IT PRODUCTS [2016 Dollars]

Estimated cost Activity Lower bound Upper bound

Task 1 ...... $160,448,000 $1,604,480,000 Task 2 ...... 80,224,000 802,240,000

Total Cost Savings (5,000 switches) ...... 240,672,000 2,406,720,000

We multiplied the costs to switch practices would range from $65.8 criterion. Our proposal also includes a health IT by the estimated number of million to $2.2 billion. The midpoint of detailed Condition of Certification and hospitals and clinical practices affected. ranges stated is used as the primary associated Maintenance of Certification Thus the estimated annual benefit, in estimate of costs and benefits. requirements, as well as a proposal to modify the Base EHR definition. terms of cost savings to hospitals and 2.3 Application Programming clinical practices would range from Interfaces Costs $240.7 million to $2.4 billion. If we Our proposals regarding APIs in this This section describes the potential assume, based on our upper bound proposed rule reflect the full depth and costs of the API certification criterion. estimates above, that the total cost to scope of what we believe is necessary to The cost estimates below are based on health IT developers is $174.9 million implement the API Condition of the following assumptions: and that increased developer costs are Certification. We propose to include 1. Health IT developers will use the passed to customers, then the net new standards, new implementation same labor costs and data models. Table benefit to hospitals and clinical specifications, and a new certification 14 shows the estimated labor costs per

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00148 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7571

product for a health IT developer to proxy to determine the number of health proxy for products capability of sending develop and maintain an API. We IT developers that may develop an API patient data. The 2015 Edition required recognize that health IT developer costs for the certification to the 2015 edition. API functionality achieves a similar end will vary; however, we have assumed in There were 598 products and 506 by allowing providers to retrieve patient our calculations that all health IT developers with at least one 2014 data from secure data servers hosted by developers will incur the costs noted in Edition certified health IT product that other developers, as well as providing Table 14. could perform transitions of care. We patients access to their medical records 2. A proxy is needed to project then multiplied this number by our through third-party applications number of 2015 Edition certified health certified health IT market consolidation connected to these same secure servers. IT products containing the API estimates of ¥22.1% and ¥23.2% to 3. According to the May 2016 BLS certification criterion. We estimate that project the number of 2015 developers occupational employment statistics, the 459 products from 394 developers will and products, respectively. We believe mean hourly wage for a ‘‘Software contain the API criterion. We used a this estimate serves as a reasonable Developer’’ is $50.14.166

TABLE 14—ESTIMATED LABOR HOURS TO DEVELOP AND MAINTAIN API

Estimated labor hours Tasks Details Remarks Lower bound Upper bound

Task 1: Develop sup- (1) New development to support ‘‘Clinical 1,500 3,500 (1) Lower bound assumes health IT al- port for Fast Notes’’, ‘‘Provenance’’, ‘‘Address’’ and ready has developed FHIR DSTU2 and Healthcare Inter- ‘‘Telecon’’. (2) Only ‘‘Mandatory’’ and SMART for 2015 and only needs to be operability Re- ‘‘Must Support’’ elements are required updated for additional resources. (2) sources (FHIR®) for each of the ARCH resources. Upper bound assumes new develop- API and ARCH 1.0 ment for all resources. (per product). Task 2: Development (1) New registration server development 1,000 2,500 (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. (2) Develop- only needs to update it to support the ment of portal and managing the appli- API Maintenance of Certification re- cation registration system. quirements. (2) Upper bound is new development of an application registra- tion service and portal. Task 3: Update (1) This is an estimate for adding one or 1,200 2,000 (1) Lower bound assumes developers are ARCH and FHIR two new data elements to USCDI and already supporting the elements and standards as part making it a requirement. (2) Support for also have been testing API-enabled of regular API API-enabled services for data on a sin- services for data on a single patient maintenance (per gle patient and multiple patients, as and multiple patients. (2) Upper bound product). well as SMART Backend Services as assumes new development for USCDI part of FHIR 4. updates and API-enabled services for data on a single patient and multiple patients. Task 4: Update Appli- This would be yearly updates and main- 400 1,300 (1) Lower bound estimates hours to keep cation Registration tenance of the portal to keep it running. it running with junior staff. (2) Upper Server and Portal We do not anticipate any major bound estimates small updates and (per developer). changes to the standard and will be adds in developer and quality assur- primarily driven by usage and devel- ance resources. oper interest. Other costs (50% per (1) Server costs. (2) Software costs (e.g., $5,000 $25,000 (1) Estimated as monetized costs and not product, 50% per databases, application servers, portal as hours; most of the costs would be developer). technology). one-time procurement costs plus yearly maintenance. Note: One-time cost.

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

166 https://www.bls.gov/oes/2016/may/ oes439061.htm.

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00149 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7572 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

TABLE 15—EXAMPLE CALCULATION FOR THE LOWER BOUND ESTIMATED COST TO DEVELOPERS TO PERFORM TASK 1 TO DEVELOP API [2016 Dollars]

Estimated Developer labor hours salary Projected lower bound (per hour) products

Task 1 ...... 1,500 $100.28 459

Example Calculation: 1,500 hours × $100.28 × 459 products = $69,042,780

TABLE 16—TOTAL COST TO DEVELOP AND MAINTAIN API [2016 Dollars]

Estimated cost Activity Lower bound Upper bound

Task 1 (459 products) ...... $69,042,780 $161,099,820 Task 2 (394 developers) ...... 39,510,320 98,775,800 Task 3 (459 products) ...... 55,234,224 92,057,040 Task 4 (394 developers) ...... 15,804,128 51,363,416 Other Costs (394 developers) ...... 985,000 4,925,000 Other Costs (459 products) ...... 1,147,500 5,737,500

Total (459 products and 394 developers) ...... 181,723,952 413,958,576

We note that we have proposed to the health IT industry.167 The The benefit calculations are based on adopt in § 170.404(b)(3) a specific measurement concepts developed the following assumptions: requirement that an API Technology include a multi-part approach analyzing 1. Benefits noted in academic Supplier must support the publication not only adoption of health IT literature are assumed accurate. of Service Base URLs for all of its functionalities supporting information Estimates of the benefits are based on customers regardless of whether they exchange but the downstream impact of estimates obtained from peer reviewed are centrally managed by the API these technologies on data academic literature. ONC reviewed Technology Supplier or locally completeness, data integration, and academic articles for validity; however, deployed. The API Technology Supplier supports for core functions of patient models were not replicated. must make such information publicly care. The benefits of our API proposal 2. Hospitals and eligible professionals that have participated in the CMS EHR available at no charge. Thus, we are are similarly multifaceted. In the Incentive Programs will be impacted: placing the responsibility of publishing analysis below, we quantify benefits in the following three areas: Estimates are based on the assumption the URLs on health IT developers and • Reduction in provider burden that 439,187 health care providers and/ those costs are captured in the associated with locating patient data; or 4,519 hospitals would be affected by registration portal cost estimation in this • Reduced costs related to reductions this regulatory action. RIA. in duplicate lab tests, readmissions, 3. Estimates on the impact of APIs on Based on the stated assumptions and emergency room (ER) visits, and adverse rates of interoperability (1% to 4%) are costs outlined in Table 16, the total drug events due to increased based on ONC analysis. To identify the estimated costs for health IT developers interoperability. We focused on these impact of the API proposal on to develop and maintain a product to outcomes for two reasons: (i) Evidence interoperability, we used regression the API criterion would range from in literature indicates that health analysis. Specifically, we estimated $181.7 million to $414.0 million with an information exchange impacts the linear probability models that identified average cost per developer ranging from chosen measures; and (ii) cost of care the impact of 2014 Edition certified EHR $461,228 to $1,050,656. We note that associated with these measures is high on hospitals’ interoperability (whether a the ‘‘other costs,’’ which account for and the impact of health information hospital sends, receives, finds, and $2.1 million to $10.7 million of this exchange is likely to result in significant integrates summary of care records). total are one-time costs and are not benefits in the form of cost reduction. Using data from the American Hospital • perpetual. The midpoint of ranges stated Increase in the number of Association (AHA) from years 2014 to is used as the primary estimate of costs individuals with access to their health 2015 in the model, we controlled for and benefits. information. hospital size, profit status, participation in a health information organization, Benefits 167 Health IT Buzz Blog, Measuring and state and year fixed effects. The Interoperability: Listening and Learning, https:// marginal effect of using a 2014 Edition The Medicare Access and CHIP www.healthit.gov/buzz-blog/electronic-health-and- certified health IT equated to a 5% Reauthorization Act (MACRA) tasks medical-records/interoperability-electronic-health- and-medical-records/measuring-interoperability- increase in interoperability. This is an ONC with measuring interoperability in listening-learning/. upper bound estimate. For the purpose

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00150 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7573

of this analysis, we assume that one to that the benefits attributed to each number of hours providers spend in four percentage points would be a proposal is unique to the proposal their EHR, there is evidence that the reasonable range for API’s marginal referenced. We assumed that this introduction of EHRs is associated with impact on interoperability. marginal effect is true for our proposals time saved. Amusan et al found that As noted previously, there might be and distributed the 5% benefit across EHR and computerized provider order shared benefits across certain proposals our real world testing and API proposals entry (CPOE) implementation was and we have taken steps to ensure that at (.1–1%) to (1–4%) respectively. associated with 3.69 minutes of time the benefits attributed to each proposal Moreover, the number of providers saved five months post are unique to the proposal referenced. impacted is proposal specific. Given implementation.170 Additionally, Adler- Specifically, we used regression data limitations, we believe this Milstein et al found that an increase in analysis to calculate the impact of our approach allows us to estimate the EHR use resulted in a 5.3% increase in real world testing and API proposals on benefits of our proposals without double interoperability. We assumed that the work relative value units per clinician counting the impact each proposal 171 collective impact of real world testing might have on interoperability. work day. Using this evidence, we and API proposals on interoperability The first table below shows benefits of estimate the potential impact of APIs on would not exceed the impact of 2014 APIs for providers where we monetize providers’ time ranges from 1%–5%.172 Edition certified health IT. Therefore, the impact of APIs as total amount Because the benefit of time saved is not we estimated linear probability models saved by reducing provider time spent limited to interoperable exchange of that identified the impact of 2014 with the health IT. Sinsky et al found health information among providers but Edition certified health IT on hospitals’ physicians spend 27% of their total time includes additional benefits such as interoperability.168 We controlled for on direct clinical face time with increased patient knowledge, we used additional factors such as participation patients, and 49.2% of their time on evidence from the literature to calculate in a health information exchange EHR and desk work.169 Outside office the time saved benefit. Thus, the impact organization, hospital characteristics, hours, physicians spend another 1 to 2 of APIs on provider time is expected to and urban/rural status. We found the hours of personal time each night doing represent a larger impact (5%) than the marginal effect of using 2014 Edition additional computer and other clerical impact of APIs on health outcomes certified health IT was a five percentage work. Based on this study, we assume (1%–4%) and cost. This is primarily point increase in interoperability. that providers spend, on average, 6 because provider behavior is more While we acknowledge that there hours per day with their EHR (4 hours directly affected by this improvement. might be shared benefits across of an 8 hour work day and 2 hours proposals, we have taken steps to ensure outside of office hours). Despite the Benefits of APIs TABLE 17—BENEFIT OF API PROVIDERS [2016 Dollars]

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

Reduction in pro- 439,187 providers ...... 95 1 5 d 6 260 $651M $3.3B vider time spent in health IT by improving usability and interoperability. 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 benefit is a product of number affected physicians, hourly wage, hours saved from EHR improvements, hours worked with EHR, and number of working days in a year. d 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.

TABLE 18—BENEFIT OF API FOR PATIENTS AND PAYERS [2016 Dollars]

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

Duplicate testing ...... 439,187 providers ...... b 0.09 0.01 0.04 c 200 Bil- 100 $180M $720M lion. Avoidable hospitaliza- 4,519 hospitals ...... b 0.09 0.01 0.04 d $41B ...... 100 37M 148M tions and readmis- sions.

168 American Hospital Association Health IT 170 Amusan, Tongen, Speedie, and Mellin, A 172 The calculation for these estimates are as Supplement Survey, http://www.ahadata.com/aha- time-motion study to evaluate the impact of EMR follows: 1% leverages Amusan et al.’s lower bound healthcare-database/. and CPOE implementation on physician efficiency, estimate of 3.69 minutes. Assuming 6 hours (or 360 J. Healthcare Inf. Manag. (Fall 2008), at 31–7. 169 Christine Sinsky et al., Allocation of Physician minutes) per day, this amounts to approximately 171 Julia Adler-Milstein and Robert S. Huckman, Time in Ambulatory Practice: A Time and Motion 1% of time saved. The upper bound estimate of 5% The Impact of Electronic Health Record Use on leverages Adler-Milstein’s estimate of a 5.3% Study in 4 Specialties, Ann Intern Med. (Dec. 6, Physician Productivity, Am J Manag Care (Nov. 19, 2016), at 753–60. 2013). estimate (rounded to 5%).

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00151 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7574 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

TABLE 18—BENEFIT OF API FOR PATIENTS AND PAYERS—Continued [2016 Dollars]

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

E visits ...... 100% of visits affected b 0.09 0.01 0.04 e Cost per 100 48M 194M ER visit $1,233, 131M visits. Adverse drug events .. 20% of events affected f 22% 0.01 0.04 g $30 bil- 20 13M 53M lion. a Total benefit is a product of total cost, % of total cost impacted, overall impact of interoperability, and impact of API. 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.

Based on the above calculations, we We expect additional benefits from down health care prices. For instance, a estimate the annual benefit to health the use of APIs could be derived from recent study by the Minnesota care providers for the use of the increased patient, and eventually payer, Department of Health showed that the proposed API capabilities would, on access to EHI. APIs make it easier for pricing for knee replacement surgery, average, range from $651 million to $3.3 patients to transmit data to and from which is a standard procedure in many billion. We estimate the annual benefit different sources. According to the hospitals, can vary significantly across for patients and payers would, on Health Information National Trends practices in the same locality. The average, range from $278 million to Survey,173 half of Americans were Minnesota study showed that Minnesota million to $1.1 billion. Therefore, we offered access to an online medical insurers paid as much as $47,000 for a estimate the total annual benefit of APIs record by a provider or insurer in 2017. patient’s total knee replacement and as to, on average, range from $929 million However, among those who were little as $6,200—a nearly eight-fold to $4.4 billion. If we assume, based on offered access, only 53% accessed their price difference. In addition to total our cost estimates, an annual cost to record at least once within the last year, knee replacements, the study found that health IT developers of $414 million and only 3.6% of individuals who total hip replacement costs ranged from and that increased developer costs are accessed their record reported $6,700 to $44,000, a 61⁄2-fold difference. passed to customers, then the net transmitting their data to a service or Typical vaginal baby delivery ranged benefit to hospitals/providers would application. The proportion of from $2,900 to $12,300, while C-section range from $515 million to $3.3 billion. individuals accessing their online deliveries ranged from $4,700 to The midpoint of ranges stated is used as health information and transmitting $22,800. Another study by Premier in the primary estimate of benefits. their information to third parties is conjunction with Wake Forest expected to grow as APIs become more University Medical Center found similar As we stated above, for Table 17, we widespread and make more data results. Among 350 hospitals, the assume APIs provide both patients and available in a computable format. average cost of primary knee implants clinicians with increased access to EHI, Growing evidence suggests that patients was $4,464. Yet, 50% of the hospitals which will have a direct impact on who have access to their EHI are more paid between $4,066 and $5,609 on the physicians by making their work more likely to adhere to medical orders devices. Further, the same group of efficient. Extrapolating the numbers including screening hospitals paid an average of $5,252 for from literature, we assume this recommendations.174 Thus, we expect primary hip implants, but 50% of the technology will improve physicians’ such patients would ultimately realize hospitals paid between $4,759 and time by 1%–5%. Also as stated above, improved health outcomes. $6,463. The studies illustrated the for Table 18, we assume APIs affect In addition, the use of APIs to support secretive nature of pricing in the health utilization through marginal the exchange and analysis of payment care market, as well as the extreme improvements in interoperability. For related data (including price variations in price that can exist for the this reason, in addition to APIs, we information) would improve cost same procedure within the same needed to incorporate the impact of transparency in the market, increase the locality.175 176 While this study was the interoperability on each of the availability of valuable information for outcomes. We request comment on payers and patients, and likely drive 175 Glenn Howatt, That surgery will cost you these assumptions. Specifically, $6,200. Or maybe $47,000, Star Tribune (Jan. 3, whether they are appropriate and 173 These estimates were derived from Health 2018), available at http://www.startribune.com/ Information National Trends Survey 5, Cycle 1 that-surgery-will-cost-you-6-200-or-maybe-47-000/ whether there are alternative (2017). 467894173/. assumptions or bases upon which we 174 See https://www.ncbi.nlm.nih.gov/pmc/ 176 Bakalar, Catherine and Czajka, Robin (2018) should make our assumptions. articles/PMC5391175/. Margin of Excellence: Total Joint Replacements

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00152 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7575

first-ever local study of insurance the health IT developer should explain Management,179 recommends the use of company payments to hospitals for how it supports MFA. and provides the requirements for using those four common procedures, similar multi-factor authenticators. Based on Costs pricing variations have been well these reports and other anecdotal documented in other, broader studies in These criteria are not intended to evidence, we believe encrypting recent years.177 We expect that making place additional burden on health IT authentication credentials and such price information available to developers as they do not require new supporting MFA are established best insurers through APIs would drive development or implementation. Rather, practices among industry developers, health care prices down, which could a health IT developer is only required to including health IT developers. As lead to significant benefits across the attest to whether they encrypt described above, we propose to require health care continuum. authentication credentials or support health IT developers to attest to whether While the examples above emphasize MFA. We expect the costs associated they encrypt authentication credentials. procedures that tend to have defined with attesting to these criteria to be de We do not have access to published end points, the eventual population minimis because we do not expect literature that details how health IT health queries would more broadly additional forms to be required and developers are already encrypting allow payers and analytics firms expect minimal effort would be required authentication credentials and working for employers to to complete the attestation. We welcome supporting MFA industry-wide, but we computationally examine the care comments on these expectations. The believe the majority of health IT providers render. Not only is price midpoint of ranges stated is used as the developers, or around 80%, are taking transparency currently missing from the primary estimate of costs and benefits. such actions. We assume that building marketplace, but for most inpatient care, this functionality is in the future project the actual details of care are largely Benefits plans for the remaining 20% because, as unobtainable through any APIs. As stated previously, we are not noted previously, adopting these However, we are not aware of an requiring health IT developers to capabilities is an industry best practice. approach for quantifying these types of encrypt authentication credentials or Health IT developers that have not yet benefits and welcome comments on support MFA. Instead, we are requiring adopted these capabilities are likely potential approaches to quantifying they attest to whether they support the already making financial investments to these benefits. certification criteria or not. By requiring get up to speed with industry standards. 2.4 New Privacy and Security an attestation, we are promoting We believe our proposal may motivate Certification Criteria transparency, which might motivate these health IT developers to speed their implementation process, but we have To be certified to the new privacy and some health IT developers that do not currently encrypt authentication not attributed a monetary estimate to security certification criteria, encrypt this potential benefit because our rule is credentials or support MFA to do so. If authentication credentials not a direct cause of health IT health IT developers are motivated by (§ 170.315(d)(12)) and multi-factor developers adopting these capabilities. this criteria and ultimately do encrypt authentication (MFA) (§ 170.315(d)(13)), By the time we release the final rule, authentication credentials and/or we are proposing to require health IT many more, or perhaps all, health IT support MFA, we acknowledge that developers to assess their Health IT developers will likely already be there would be costs to do so; however, Modules’ capabilities and attest ‘‘yes’’ or encrypting authentication credentials we assume that the benefits would ‘‘no’’ to the certification criteria. As and supporting MFA. We welcome substantially exceed the costs. specified in section IV.C.3 of this comments on this expectation and any Encrypting authentication credentials proposed rule, we are proposing to means or methods we could use to and adopting MFA would reduce the make these certification criteria quantify these benefits. applicable to all Health IT Modules likelihood that authentication under the Program. For encrypt credentials would be compromised and 2.5 Data Segmentation for Privacy- authentication credentials and multi- would eliminate an unnecessary use of Send and Data Segmentation for factor authentication, we are proposing IT resources. Encrypting authentication Privacy-Receive; and Consent to require a simple attestation. For MFA, credentials and adopting MFA could Management for APIs we are also proposing to require that if directly reduce providers’ operating/ We propose to remove the current the health IT developer attests to support costs, which would reduce their 2015 Edition Data Segmentation for supporting MFA, the health IT administrative and financial burden. Privacy (DS4P)-send (§ 170.315(b)(7)) developer would need to explain how it Encrypting authentication credentials and DS4P-receive (§ 170.315(b)(8)) supports MFA. We also request public would also help decrease costs and certification criteria which apply the comment on whether there is value in burden by reducing the number of DS4P standard at the document level. adopting an MFA criterion and whether password resets due to possible We propose to replace these two criteria phishing or other vulnerabilities. with three new 2015 Edition DS4P [White Paper] May 24, 2018, http:// According to Verizon’s 2017 Data _ certification criteria (two for C–CDA and offers.premierinc.com/rs/381-NBB-525/images/WC Breach Investigations Report, 81% of CM_TotalJoint_2018_05_04.pdf. one for FHIR) that would support a 177 See e.g., Elisabeth Rosenthal, The $2.7 Trillion hacking-related breaches leveraged more granular approach to privacy Medical Bill; Colonoscopies Explains Why U.S. either stolen and/or weak passwords.178 tagging data for health information Leads the World in Health Expenditures, The New The Verizon report encourages exchange supported by either the C– York Times (June 1, 2013), available at http:// customers to vary their passwords and www.nytimes.com/2013/06/02/health/ CDA- or FHIR-based exchange colonoscopies-explain-why-us-leads-the-world-in- use two-factor authentication. Also, standards. In place of the removed 2015 health-expenditures.html?pagewanted=all; Steve NIST Special Publication 800–63B: Edition DS4P criteria, we propose to Twedt, Hospitals’ charges can vary greatly for Digital Identity Guidelines, adopt new DS4P-send (§ 170.315(b)(12)) similar services, Pittsburgh Post-Gazette (May 9, Authentication and Lifecycle 2013), available at http://www.post-gazette.com/ and DS4P-receive (§ 170.315(b)(13)) business/businessnews/2013/05/09/Hospitals- charges-can-vary-greatly-for-similar-services/ 178 http://www.verizonenterprise.com/verizon- 179 https://pages.nist.gov/800-63-3/sp800- stories/201305090300. insights-lab/dbir/2017/. 63b.html.

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00153 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7576 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

criteria that would remain based on the appropriately apply security labels to and develop a STU3 compatible FHIR C–CDA and the HL7 DS4P standard. data and/or develop access control server. These criteria would include capabilities. Moreover, developers will 2. As with the two DS4P criteria, we capabilities for applying the DS4P likely incur costs to upgrade health IT anticipate developers will need standard at the document, section, and to generate a security-labeled C–CDA approximately 1,500–2,500 hours to entry level. We also propose to adopt a conforming to the DS4P standard. We upgrade databases and/or other backend third 2015 Edition DS4P certification estimate developers will need 400–600 infrastructure to appropriately apply criterion ‘‘consent management for hours per criterion to make these security labels to data and/or develop APIs’’ (§ 170.315(g)(11)) that requires upgrades on systems that had access control capabilities. We expect health IT to be capable of responding to previously certified to the document- that this would be a one-time cost. requests for data through an API in level DS4P criteria, or 720–1,220 hours 3. Because certification to this accordance with the Consent per criterion for systems that are criterion is voluntary and because Implementation Guide. Our primary implementing these criteria for the first supporting this criterion requires purpose for proposing to remove and time. We believe this work would be implementation of a version of FHIR replace them, in lieu of proposing to performed by a ‘‘Software Developer.’’ (STU3) that does not align with the revise them, is to provide clarity to According to the May 2016 BLS other API criterion in this rule (based on stakeholders as to the additional occupational employment statistics, the DSTU2), we estimate the number of functionality enabled by health IT mean hourly wage for software products that will support this criterion certified to the new criteria. developer is $50.14. As noted is approximately 5% of the total number of 2015 certified products. We used a Costs previously, we have assumed that overhead costs (including benefits) are proxy to determine the number of health We anticipate this proposal could equal to 100% of pre-tax wages, so the IT developers that may develop an API result in up-front costs to health IT hourly wage including overhead costs is for the 2015 Edition. There were 598 developers as this new criteria would $100.28. Therefore, we estimate the total products and 506 developers with at require the health IT to support all three cost to developers could range from least one 2014 Edition certified product levels—document, section, and entry— $2,306,440 to $7,430,748. We note that that could perform transitions of care. as specified in the current DS4P this would be a one-time cost. The We then multiplied this number by our standard. However, we note that these midpoint of ranges stated is used as the certified health IT market consolidation ¥ ¥ criteria are not being required in any primary estimate of costs and benefits. estimates of 22.1% and 23.2% to program at this time. As of the project the number of 2015 developers beginning of the third quarter of the Additionally, our proposal supports and products, respectively; we estimate 2018 CY, only about 20 products the capability to respond to requests for that 459 products from 394 developers (products with multiple certified patient consent information through an will contain the API criterion. versions were counted once) were API compatible with FHIR Release 3. In Therefore, we anticipate 23 products certified to the current 2015 Edition order to meet the ‘‘consent management from 20 developers will certify to the DS4P certification criteria. We estimate for APIs’’ criteria, developers would ‘‘consent management for APIs’’ that 10–15 products will implement the demonstrate compatibility with the criterion. We believe this work would new DS4P criteria. Developers may need standards framework used for the be performed by a ‘‘Software to perform fairly extensive health IT Consent Implementation Guide. We Developer.’’ upgrades to support the more complex have estimated costs associated with 4. According to the May 2016 BLS and granular data tagging requirements this aspect of our proposal using the occupational employment statistics, the under these criteria. We anticipate following assumptions: mean hourly wage for a ‘‘Software developers will need approximately 1. We estimate developers will require Developer’’ is $50.14. 1,500–2,500 hours to upgrade databases 1,500–3,500 hours to upgrade health IT Our cost estimates are explained in and/or other backend infrastructure to to align with the FHIR STU3 data model the table below.

TABLE 19—COSTS RELATED TO DATA SEGMENTATION FOR PRIVACY USING API [2016 Dollars]

Lower bound Upper bound Tasks Details hours hours Assumptions Remarks

Task 1: Enhance health IT to Enhance health IT to align with 1,500 3,500 ...... This is a one-time cost align with the FHIR STU3 data the FHIR STU3 data model for health IT systems model and develop a STU3 and develop a STU3 compat- to align with the FHIR compatible FHIR server. ible FHIR server. STU3 data model and develop a STU3 com- patible FHIR server. Task 2: Enhancements to health Enhancements to health IT to 1,500 2,500 ...... This is a one-time cost IT to upgrade databases and/ upgrade databases and/or for health IT systems or other backend infrastructure other backend infrastructure to support data seg- to appropriately apply security to appropriately apply security mentation for discrete labels to data and/or develop labels to data and/or develop data. access control capabilities. access control capabilities.

Total Labor Hours ...... 3,000 6,000

Hourly Rate ...... $100.28

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00154 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7577

TABLE 19—COSTS RELATED TO DATA SEGMENTATION FOR PRIVACY USING API—Continued [2016 Dollars]

Lower bound Upper bound Tasks Details hours hours Assumptions Remarks

Cost per Product ...... $300,840 $601,680

Total Cost (23 products) ...... $6,919,320 $13,838,640

We believe this proposal involving and ONC to be significant; however, we 3.2.2 Records and Information standardized APIs, as well as the are unable to quantify these benefits at Retention voluntary nature of the proposal, would this time because we do not have We propose that, as a Maintenance of significantly mitigate health IT adequate information to support Certification requirement, a health IT developer costs. We also expect quantitative estimates. We welcome developer must, for a period of 10 years developers to see a return on their comments regarding potential beginning from the date of certification, investment in developing and preparing approaches for quantifying these retain all records and information their health IT for these certification benefits. necessary that demonstrate initial and criteria given the benefits to (3) Conditions and Maintenance of ongoing compliance with the interoperable exchange. We welcome Certification requirements of the ONC Health IT comments on this analysis. We anticipate potential costs for ONC 3.1 Information Blocking Certification Program. In an effort to related to this proposal associated with: reduce administrative burden, we also For a discussion of the costs and propose, that in situations where (1) Developing and maintaining benefits of the exceptions to information information regarding these new criteria applicable certification criteria are blocking proposed in this rule, please removed from the Code of Federal on the ONC website; (2) creating see section (5) of this RIA. documents related to these new criteria Regulations before the 10 years have and making those documents 508 3.2 Assurances expired, records must only be kept for 3 years from the date of removal for compliant; (3) updating, revising, and We are proposing that health IT supporting Certification Companion developers must make certain those certification criteria and related Guides, test procedures, and test tools; assurances as Conditions and Program provisions unless that and (4) responding to inquiries Maintenance of Certification: (1) timeframe would exceed the overall 10- concerning these criteria. We estimate Assurances regarding the electronic year retention period. This ‘‘3-year from an ONC analyst at the GS–13, Step 1 health information export certification the date of removal’’ records retention level staff would devote, on average, 200 criterion in § 170.315(b)(10) and (2) period also aligns with the records hours to the above tasks annually. The assurances regarding retaining records retention requirements for ONC–ACBs hourly wage with benefits for a GS–13, and information. and ONC–ATLs under the Program. Step 1 employee located in Washington, Currently, there are no existing DC is approximately $88.30. Therefore, 3.2.1 Electronic Health Information regulatory requirements regarding we estimate the annual costs to be Export record and information retention by $17,660. We propose, as a Condition of health IT developers. We expect the Certification requirement, that a health costs to developers to retain the records Benefits IT system that produces and and information described above to be We believe leveraging the DS4P electronically manages electronic health mitigated due to the following factors. standard’s ability to allow for both information must be certified to the First, we expect that health IT document level and more granular 2015 Edition ‘‘electronic health developers are already keeping the tagging would offer functionality that is information export’’ certification majority of their records and more valuable to providers and patients, criterion in § 170.315(b)(10). Further, as information in an electronic format. especially given the complexities of the a Maintenance of Certification Second, we expect that health IT privacy landscape for multiple care and requirement, health IT developers must developers already have systems in specialty settings. We also believe this comply with this proposed Condition of place for retaining records and proposal would benefit providers, Certification requirement within 24 information. Last, we expect that some patients, and ONC because it would months of a subsequent final rule’s developers may already be retaining support more complete records, effective date or at the time of records and information for extended contribute to patient safety, and certification if the health IT developer periods of time due to existing enhance care coordination. We believe never previously certified health IT to requirements of other programs, this proposal could also reduce burden the 2015 Edition. As another including for those programs their for providers by enabling an automated Maintenance of Certification customers participate in. For instance, option, rather relying on case-by-case requirement, we propose that health IT Medicaid managed care companies are manual redaction and subsequent developers must provide all of their required to keep records for ten years workarounds to transmit redacted customers with the functionality from the effective date of a contract. documents. We emphasize that health included in § 170.315(b)(10). We estimate that each health IT care providers already have processes For a detailed discussion of the costs developer will, on average, spend two and workflows to address their existing and benefits of the assurances regarding hours each week to comply with our compliance obligations, which could be the electronic health information export proposed record retention requirement. made more efficient and cost effective certification criterion in We expect that a health IT developer’s through the use of health IT. We expect § 170.315(b)(10), please see section 2.2 office clerk could complete the record these benefits for providers, patients, of this RIA above. retention responsibilities. According to

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00155 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7578 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

the May 2016 BLS occupational cost. We welcome comments on these documentation necessary to interact employment statistics, the mean hourly cost estimates. with the APIs in production freely and wage for an office clerk is $15.87.180 As In order to meet the Cures Act publicly accessible. We expect that the noted previously, we have assumed that requirement that health IT developers API Technology Suppliers would overhead costs (including benefits) are do not prohibit or restrict perform the following tasks related to equal to 100% of pre-tax wages, so the communication regarding health IT, transparency of business and technical hourly wage including overhead costs is some health IT developers would documentation and would devote the $31.74. Therefore, we estimate the eventually need to amend their following number of hours annually to annual cost per developer would, on contracts to reflect such a change. Many such task: (1) Health Level 7’s (HL7®) average, be $3,301 and the total annual standard form health IT contracts limit Fast Healthcare Interoperability cost for all health IT developers (458 the ability of users to voluntarily Resources (FHIR®) API documentation health IT developers have products discuss problems or report usability and (the vendor would most likely point to certified to the 2015 Edition that are safety concerns that they experience the HL7 FHIR standard for API capable of recording patient health data) when using their health IT. This type of documentation) (estimated eight hours); would, on average, be $1.5 million. We discussion or reporting is typically (2) patient application registration note that this is a perpetual cost. We prohibited through broad documentation, which would include a welcome comments on these cost confidentiality, nondisclosure, and development effort to create a website estimates. intellectual property provisions in the that manages the application vendor’s standard form health IT registration activity (estimated 40 3.3 Prohibition or Restriction of contract. Some standard form health IT hours); (3) publication of the FHIR Communications Costs contracts may also include non- Endpoint—Base URLs for all centrally disparagement clauses that prohibit managed providers (estimated 40 Health IT developers would need to customers from making statements that hours); (4) publication of FHIR notify their customers about the could reflect negatively on the health IT Endpoints for provider-managed APIs unenforceability of communications and developer. These practices are often (estimated 160 hours); and (5) API cost contract provisions that violate this referred to colloquially in the industry information documentation, which Condition of Certification. Generally, as ‘‘gag clauses.’’ We expect would typically be documented as a health IT developers should already amendments to these clauses to be tiered rate based on usage or some form have mechanisms in place, whether via accomplished in the normal course of of monthly rate (estimated 40 hours). online postings, email, mail, or phone, business, such as when renegotiating We believe each of the above tasks for alerting customers to changes in contracts or updating them for HIPAA would be performed by a ‘‘Software their policies and procedures. Such or other compliance requirements. As Developer.’’ According to the May 2016 alerts should be standard practice. such, we do not estimate any direct or BLS occupational employment However, we have estimated the indirect costs for health IT developers to statistics, the mean hourly wage for potential costs for health IT developers amend their contracts to comply with software developer is $50.14 182 As to draft the notice and mail the notice this condition of certification. noted previously, we have assumed that as appropriate. We estimate that a overhead costs (including benefits) are health IT developer’s office clerk will Benefits equal to 100% of pre-tax wages, so the commit (overall) approximately 40 We expect health care providers to hourly wage including overhead costs is hours to drafting and mailing notices benefit from this proposal. There is $100.28. Therefore, we estimate the cost when necessary. According to the May growing recognition that these practices per developer to be $28,881. As noted 2016 BLS occupational employment of prohibiting or restricting in section 2.3 of this RIA, we estimate statistics, the mean hourly wage for an communication do not promote health that 459 products from 394 developers 181 office clerk is $15.87. As noted IT safety or good security hygiene and will contain the API criterion. previously, we have assumed that that health IT contracts should support Therefore, we estimate the total overhead costs (including benefits) are and facilitate the transparent exchange developer total would be $11.4 million. equal to 100% of pre-tax wages, so the of information relating to patient care. We note that this is a one-time cost and hourly wage including overhead costs is We are unable to estimate these benefits would not be perpetual. $31.74. Therefore, we estimate the because we do not have adequate 3.6 Real World Testing annual cost per developer to be $1,270 information to determine the prevalence and the total cost for all health IT of gag clauses and other such restrictive The objective of real world testing is developers (792 health IT developers practices, nor do we have a means to to verify the extent to which deployed certified to the 2014 Edition) to be $1 quantify the value to providers of being health IT products in operational million. We note that this is a one-time able to freely communicate and share production settings are demonstrating cost and would not be perpetual. information. We welcome comments on compliance to certification criteria and We also note that mailing is one approaches to quantify these benefits. functioning with the intended use cases option for delivery, along with other for continued maintenance of 3.4 Application Programming means such as email. We do not have certification. Real world testing should Interfaces information concerning how health IT ensure certified health IT products have developers will deliver their notices. We For a discussion of the costs and the ability to share electronic health have estimated a total cost for all benefits of the new API criterion, please information between other systems. Real developers to mail the notices see section 2.3 of this RIA. world testing should assess that the (including postage) to be $80,000. 3.5 Transparency Requirements for certified health IT is meeting the Again, we note that this is a one-time Application Programming Interfaces intended use case(s) of the certification criteria to which it is certified within We propose as part of the Conditions 180 See https://www.bls.gov/oes/2016/may/ the workflow, health IT architecture, oes439061.htm. and Maintenance of Certification that 181 See https://www.bls.gov/oes/2016/may/ API Technology Suppliers be required 182 See https://www.bls.gov/oes/2016/may/ oes439061.htm. to make specific business and technical oes439061.htm.

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00156 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7579

and care/practice setting in which the developer to perform real world testing. perform either (or both) transitions of health IT is implemented. We note that We recognize that health IT developer care and/or send any type of public we expect real world testing would take costs will vary; however, our estimates health data. We then multiplied these about three months of the year to in this section assume all developers numbers by our estimates for certified perform. will incur the costs noted in Table 20. health IT market consolidation by 2. Proxy needed to project the number ¥22.1% and ¥23.2% to project number Costs of 2015 Edition products impacted by of 2015 developers and products, This section describes the potential real world testing. We estimate that 523 respectively. We believe this estimate costs of the real world testing products from 429 developers will be serves as a reasonable proxy for requirements in this proposed rule. The impacted by real world testing. We used products impacted by real world testing, costs estimates are based on the a proxy to determine developers that as these products primarily focus on following assumptions: would be subject to real world testing interoperability. 1. Health IT developers will use the There were 681 products and 551 The tables below describe the various same labor costs. Table 20 shows the developers with at least one of its 2014 costs to health IT developers to perform estimated labor costs for a health IT Edition certified products that could real world testing by task.

TABLE 20—ESTIMATED COST TO HEALTH IT DEVELOPERS TO PERFORM REAL WORLD TESTING a [2016 Dollars]

Tasks and labor category Hours Rate Total

Task 1: Design Real World Testing Approach and Submit Plan (per developer) ...... $33,817 15–1133 Software Developers, Systems Software ...... 80 106.34 8,507.20 15–1143 Computer Network Architects ...... 120 100.24 12,028.80 15–1121 Computer Systems Analysts ...... 80 88.10 7,048.00 15–1199 Computer Occupations, All Other ...... 40 85.46 3,418.40 27–3042 Technical Writers ...... 40 70.36 2,814.40 Task 2: Prepare Staff and Environments (per developer) ...... 14,646 15–1121 Computer Systems Analysts ...... 40 88.10 3,524.00 15–1142 Network and Computer Systems Administrators ...... 40 81.26 3,250.40 15–1152 Computer Network Support Specialists ...... 40 65.16 2,606.40 15–1199 Computer Occupations, All Other ...... 40 85.46 3,418.40 15–1122 Information Security Analysts ...... 20 92.34 1,846.80 Task 3: Perform Testing (per product) ...... 31,577 15–1121 Computer Systems Analysts ...... 80 88.10 7,048.00 15–1133 Software Developers, Systems Software ...... 40 106.34 4,253.60 15–1199 Computer Occupations, All Other ...... 160 85.46 13,673.60 15–1142 Network and Computer Systems Administrators ...... 40 81.26 3,250.40 15–1141 Database Administrators ...... 40 83.78 3,351.20 Task 4: Collect Results and Prepare-Submit Report (per developer) ...... 20,118 15–1199 Computer Occupations, All Other ...... 120 85.46 10,255.20 15–1121 Computer Systems Analysts ...... 80 88.10 7,048.00 27–3042 Technical Writers ...... 40 70.36 2,814.40

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

Total Cost ...... 100,307 a Labor rates in this chart are from the BLS. See https://www.bls.gov/oes/2016/may/oes439061.htm.

TABLE 21—REAL WORLD TESTING TOTAL ANNUAL COST [2016 Dollars]

Task Calculation Total cost

Task 1 ...... $33,817 × 429 developers ...... $14,507,407 Task 2 ...... $14,646 × 429 developers ...... 6,283,134 Task 3 ...... $31,577 × 523 products ...... 16,514,666 Task 4 ...... $20,118 × 429 developers ...... 8,630,450 Other Direct Costs ...... $150 × 429 developers ...... 78,450

Total Cost ...... 46,014,108

Based on the stated assumptions and Benefits and ancillary technologies such as costs outlined in the above tables, we There are a number of benefits that picture archiving and communications estimate the total annual cost for real can be attributed to real world testing. systems (PACS) or specialty specific world testing would, on average, be $46 Real world testing may impact the interfaces. Real world testing might also million with an average cost per effective integration of varied health IT have an effect on the effective developer of $107,259. systems, including integration of implementation of workflows in a certified health IT with non-certified clinical setting. In this analysis, we have

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00157 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7580 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

calculated the benefits in the following certified EHR on hospitals’ would collectively have the same categories: interoperability (whether a hospital impact on interoperability as use of 1. Provider time saved documenting sends, receives, finds, and integrates 2014 Edition certified health IT. in their EHR due to improved usability. summary of care records). Using data Therefore, we estimated linear 2. Increased provider satisfaction with from the AHA from years 2014–2015 in probability models that identified the their EHR resulting in fewer providers the model, we controlled for hospital impact of 2014 Edition certified health incurring the costs of switching size, profit status, participation in a IT on hospitals’ interoperability.183 We products. health information organization, and controlled for additional factors such as 3. Benefits related to reductions in state and year fixed effects. The participation in a health information duplicate lab tests, readmissions, ER marginal effect of using a 2014 Edition exchange organization, hospital visits, and adverse drug events due to was a five percentage point increase in characteristics, and urban/rural status. increased interoperability. We focused interoperability. This is an upper bound We found the marginal effect of using on these outcomes for two reasons: (i) estimate. For the purpose of this 2014 Edition certified health IT was a Evidence in literature indicate that analysis, we assume 0.1% to 1% would five percentage point increase in health information exchange impacts be a reasonable range for real world interoperability. the chosen measures; and (ii) cost of testing to impact interoperability. While we acknowledge that there care associated with these measures is 4. Impact of real world testing is also might be shared benefits across high and the impact of health based on the estimated number of proposals, we have taken steps to ensure information exchange is likely to result providers that switch health IT that the benefits attributed to each in significant benefits in the form of developers (rate = 5%). Using CMS proposal is unique to the proposal reduced costs. Medicare EHR Incentive Program data referenced. We assumed that this The benefit calculations are based on from years 2013–2016, we estimate the marginal effect is true for our proposals the following assumptions: rate of providers (hospitals and eligible and distributed the 5% benefit across 1. Benefits noted in academic professionals) that changed their health our real world testing and API proposals literature are assumed accurate and IT developer. at (.1–1%) to (1–4%) respectively. results were not externally validated. 5. Estimates of the rate of eligible Moreover, the number of providers Estimates of the benefits associated with professionals (10%) and hospitals (5%) impacted is proposal specific. Given the benefits are based on estimates that will be impacted by real world data limitations, we believe this obtained from the academic literature. testing are based on ONC complaint approach allows us to estimate the Staff reviewed the academic articles for data. Because real world testing is benefits of our proposals without double validity, but estimates were not designed to improve usability and counting the impact each proposal replicated to confirm accuracy. interoperability of products, we assume might have on interoperability. 2. Hospitals and eligible professionals that those eligible professionals and The first table below shows benefits of that participate in the CMS EHR hospitals most likely to be impacted are real world testing for providers where Incentive Program will be impacted. those who currently use products by we monetize the impact of real world Estimates are based on the assumption health IT developers with complaints. testing as total amount saved by that 439,187 health care providers and/ As noted previously in this analysis, reducing provider time spent with the or 4,519 hospitals will be affected by we acknowledge that there might be health IT. The impact of real world this regulatory action. shared benefits across certain proposals testing on provider time is expected to 3. Estimates of the impact of real and have taken steps to ensure that the represent a larger impact (5%) than the world testing on rates of interoperability benefits attributed to each proposal are impact of real world testing on health (0.1 to 1%) are based on ONC analysis. unique to the proposal referenced. outcomes (1%–4%) and cost. This is To identify the impact of real world Specifically, we used regression primarily because provider behavior is testing on interoperability, we used analysis to calculate the impact of our more directly affected by improvements regression analysis. Specifically, we real world testing and API proposals on in interoperability. estimated linear probability models that interoperability. We assumed that the identified impact of 2014 Edition real world testing and API proposals Benefits of Real World Testing TABLE 22—BENEFIT OF REAL WORLD TESTING FOR PROVIDERS [2016 Dollars]

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

Reduction in provider 43,919 providers or 95 1 5 e 6 260 $65M $325M time spent in 10% d (based on health IT by im- complaint data). proving usability and interoperability. Administrative time Using a rule of 0.75 14.52 1 5 e 6 260 7M 37M spent in health IT administrative by improving bill- staff per provider,f ing, patient match- 32,939 personnel. ing, product inte- gration.

183 American Hospital Association Health IT Supplement Survey, http://www.ahadata.com/aha- healthcare-database/.

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00158 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7581

TABLE 22—BENEFIT OF REAL WORLD TESTING FOR PROVIDERS—Continued [2016 Dollars]

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

Number of providers Number 2,195; Cost ...... 33M 154M switching health of Switching Min = IT g. $15,000, Max = $70,000.

Total Benefit ...... 105M 516M 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 vendor is a product of 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. f 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. g 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.

TABLE 23—BENEFIT OF REAL WORLD TESTING FOR PATIENTS AND PAYERS [2016 Dollars]

Overall interop Impact of real world testing Total benefit a Population impact Percent of (per year) Benefit type affected (marginal Total cost total cost effect) Min Max impacted Min Max

Duplicate testing ... 35,607 providers .. b 0.09 0.001 0.01 200 Billion c ...... 10 $18M $180M Avoidable hos- 5% of hospitals (n b 0.09 0.001 0.01 $41B d ...... 5 0.2M 1.8M pitalizations and = 226). readmissions. ER visits ...... 5% of visits af- b 0.03 0.001 0.01 Cost per ER visit 5 2M 2.4M fected. $1,233, 131M visits e. Adverse drug 5% of events af- f 0.22 0.001 0.01 $30 billion g ...... 5 0.33M 3.3M events. fected.

Total Benefit ...... 2.6M 25.6M a Total benefit is a product of total cost, % 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. fM.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 that increased health IT developer costs We specifically solicit comment on the benefits outlined in Table 22 above, we are passed to customers, then the net general ratio of cloud-based to non- estimate the total annual benefit for real benefit to hospitals/providers would cloud-based deployments within the world testing to providers would, on range from $63.3 million to $495.5 health care ecosystem and specific cost average, range from $105 million to million. variations in performing real world $516 million. Based on the stated We recognize that health IT testing based on the type of deployment. assumptions and benefits outlined in developers may deploy their systems in We also request comment on our Table 23 above, we estimate the total a number of ways, including cloud- assumptions about the burden to annual benefit for patients and payers based deployments, and seek comment providers in time spent assisting health would, on average, range from $4.3 on whether our cost estimates of real IT developers since we encourage health million to $25.5 million. Therefore, we world testing should factor in such IT developers to come up with ways to estimate the total benefit of real world methods of system deployment. For perform real world testing that mitigate testing would, on average, range from example, we request feedback about provider disruption. $109.3 million to $541.5 million. If we whether health IT developers would assume, based on our cost estimates, the incur reduced real world testing costs average annual costs to health IT through cloud-based deployments as developers would be $46 million and opposed to other deployment methods.

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00159 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7582 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

3.6.1 Real World Testing Maintenance world testing plans and results to ONC 3.8 Attestations Requirements for public availability. The hourly wage The Cures Act requires that a health We propose to revise the Principle of with benefits for a GS–13, Step 1 IT developer, as a Condition and Proper Conduct in § 170.523(m) to employee located in Washington, DC is Maintenance of Certification under the require ONC–ACBs to collect, no less approximately $88.30. Therefore, we Program, provide to the Secretary an than quarterly, all updates successfully estimate the annual cost to ONC–ACBs attestation to all the Conditions and made to standards in certified health IT to comply with the submission and Maintenance of Certification specified pursuant to the developers having opted reporting requirements under in the Cures Act, except for the ‘‘EHR to avail themselves of the Standards §§ 170.523(m) and 170.550(l) to be reporting program’’ Condition of Version Advancement Process $143,891. Certification. It also requires that a flexibility under the real world testing Throughout the RIA we have used 830 health IT developer attest to ensuring Condition of Certification. Under products as our 2015 Edition Projection. that its health IT allows for health § 170.523(p), ONC–ACBs will be We came up with this projection by information to be exchanged, accessed, ¥ responsible for: (1) Reviewing and multiplying a 23.2% market and used in the manner described by confirming that applicable health IT consolidation rate from the total number the API Condition of Certification. We developers submit real world testing of products certified to 2014 Edition. propose to implement the Cures Act plans in accordance with This assumption was based on the ‘‘attestations’’ Condition of Certification § 170.405(b)(1); (2) reviewing and market consolidation rate observed in § 170.406 by requiring health IT confirming that applicable health IT between the 2011 and 2014 Editions. developers to attest to the developers submit real world testing We have estimated the number of 2015 aforementioned conditions. For the results in accordance with Edition products that will certify each purposes of estimating the potential § 170.405(b)(2); and (3) submitting real criteria included in the real world burden of these attestations on health IT world testing plans by December 15 and testing Condition of Certification. We developers, ONC–ACBs, and ONC, we results by April 1 of each calendar year assume that there will be a cost are estimating that all health IT to ONC for public availability. In associated with a notice for each developers under the Program will addition, under § 170.523(t), ONC–ACBs certified criteria (even if an individual submit an attestation biannually. As will be required to: (1) Maintain a product were to update the same noted previously in this RIA, there are record of the date of issuance and the standard across multiple criteria that 792 health IT developers certified to the content of developers’ notices; and (2) use that standard). This estimation was 2014 Edition. timely post content of each notice on calculated by multiplying the current We estimate it will take a health IT the CHPL. percent of 2015 Edition products that developer employee approximately one Using the information from the ‘‘Real certify a criteria by the estimated hour on average to prepare and submit World Testing’’ section of this RIA, we number of total 2015 Edition products each attestation to the ONC–ACB. estimate that 429 developers will be (830). According to the May 2016 BLS impacted by real world testing. We We assume that the amount of time occupational employment statistics, the estimate that, on average, it will take an for an ONC–ACB staff person to (1) mean hourly wage for a software 184 ONC–ACB employee at the GS–13, Step maintain a record of the date of issuance developer is $50.14 Therefore, we 1 level approximately 30 minutes to and the content of developers’ notices; estimate the annual cost including collect all updates made to standards in and (2) to timely post content of each overhead costs to be $79,422. We propose that attestations would be Health IT Modules in accordance with notice on the CHPL can be anywhere submitted to ONC–ACBs on behalf of § 170.523(m). The hourly wage with from 30 minutes to 1 hour. ONC and the Secretary. We assume benefits for a GS–13, Step 1 employee The hourly wage with benefits for a there will be three ONC–ACBs as this is located in Washington, DC is GS–13, Step 1 employee located in the current number of ONC–ACBs, and approximately $88.30. Since the Washington, DC is approximately we also assume an equal distribution in collection must occur no less than $88.30. This was the hourly rate we responsibilities among ONC–ACBs. quarterly, we assume it occurs, on used for the RIA, so it’s consistent with ONC–ACBs would have two average, four times per year. Therefore, prior calculations. This wage is used to responsibilities related to attestations. we estimate the annual cost to ONC– determine the ONC–ACB time cost to One responsibility we propose in complete this requirement under ACBs to comply with the collection § 170.523(q) is that an ONC–ACB must § 170.523(t). Our minimum estimate for requirements under § 170.523(m) to be review and submit the health IT the amount of time to comply is 30 $139,867. developers’ attestations to ONC. We We estimate that, on average, it will minutes per notice. If 25% of certified estimate it will take an ONC–ACB take an ONC–ACB employee at the GS– products update any of the applicable employee at the GS–13, Step 1 level 13, Step 1 level approximately 1 hour to standards, we estimate it will cost approximately 30 minutes on average to $58,807. If all products update any of review and confirm that applicable review and submit each attestation to health IT developers submit real world the applicable standards, we estimate it ONC. The other responsibility we testing plans in accordance with will cost $235,231. Our maximum propose in § 170.550(l) is that before § 170.405(b)(1). We estimate that, on estimate for the amount of time to issuing a certification, an ONC–ACB average, it will take an ONC–ACB comply is 1 hour per notice. If 25% of would need to ensure that the health IT employee at the GS–13, Step 1 level certified products update any of the developer of the Health IT Module has approximately 30 minutes to review and applicable standards, we estimate it will met its responsibilities related to the confirm that applicable health IT cost $117,615. If all products update any Conditions and Maintenance of developers submit real world testing of the applicable standards, we estimate Certification requirements as solely results in accordance with it will cost $470,462. Our lower bound evidenced by its attestation. We § 170.405(b)(2). We estimate that, on estimate for the cost of this requirement estimate it will take an ONC–ACB average, it will take an ONC–ACB is $58,807. Our upper bound estimate employee at the GS–13, Step 1 level for the cost of this requirement is 184 See https://www.bls.gov/oes/2016/may/ approximately 30 minutes to submit real $470,462. oes439061.htm.

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00160 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7583

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

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00161 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7584 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

necessary. The hourly wage with complexity, between 40 and 160 hours developers’ actions conform with the benefits for a GS–15, Step 1 employee of staff time to conduct each appeal. requirements of the Cures Act and located in Washington, DC is This would include the time to Conditions and Maintenance of approximately $122.74. Therefore, represent ONC in the appeal and Certification requirements in based on the estimate of between 12 and support the costs for the hearing officer. §§ 170.400–406. Specifically, ONC’s 18 cases each year, we estimate ONC’s We assume that the expertise of a GS– direct review of health IT developer annual costs would on, average range, 15, Step 1 federal employee(s) would be actions will facilitate ONC’s ability to from $11,783 to $176,745. We note that necessary. The hourly wage with require comprehensive corrective action some reviews and inquiries may cost benefits for a GS–15, Step 1 employee by health IT developers to address non- less and some may cost more than this located in Washington, DC is conforming actions determined by ONC. estimated cost range. Further, we note approximately $122.74. Therefore, If ONC ultimately implements a that these costs would be perpetual. based on the estimate on between three certification ban and/or terminates a We welcome comments on our and five cases each year, we estimate certification(s), such action will serve to estimated costs and any comparable the cost for ONC to conduct an appeal protect the integrity of the Program and processes and costs that we could use to would, on average, range from $14,729 users of health IT. While we do not have improve our cost estimates. to $98,192. We note that some appeals available means to quantify the benefits may cost less and some may cost more of ONC direct review of health IT ONC Review and Inquiry Following the than this estimated cost range. Further, Issuance of a Notice of Non-Conformity developer actions, we note that ONC we note that these costs would be direct review supports and enables the and the Health IT Developer Contests perpetual. ONC’s Findings National Coordinator to fulfill his Based on the above estimates, we responsibilities under the HITECH Act As discussed in section VII.C of this estimate the total annual costs for health and Cures Act, instills public preamble, we propose to permit a health IT developers related to ONC review confidence in the Program, and protects IT developer to appeal an ONC and inquiry into health IT developer public health and safety. determination to issue a certification actions would, on average, range from ban and/or terminate a certification $15,858 to $98,672. We estimate the (5) Information Blocking under § 170.581(a)(2)(iii). This category total annual costs for ONC related to Costs of cost calculations captures cases that ONC review and inquiry into health IT We expect ONC to incur an annual require review and inquiry following developer actions would, on average, cost for issuing guidance related to the ONC’s issuance of a notice of non- range from $44,212 to $380,737. information blocking ‘‘reasonable and conformity and where the health IT We welcome comments on our necessary’’ exceptions. We assume that developer contests ONC’s finding and estimated costs and any comparable the guidance would be provided by files an appeal. We estimate that ONC processes and costs that we could use to ONC staff with the expertise of a GS–15, will, on average, conduct between three improve our cost estimates. Step 1 federal employee(s). The hourly and five of these reviews annually. Costs for ONC–ACBs We estimate that a ‘‘Computer wage with benefits for a GS–15, Step 1 Systems Analyst’’ for the health IT We also note that ONC–ACBs could employee located in Washington, DC is developer may commit, on average and realize costs associated with the new approximately $122.74. We estimate it depending on complexity, between 20 proposed reporting requirement in the would take ONC staff between 200 and and 80 hours to provide the required Principles of Proper Conduct in 400 hours to develop the guidance. information to appeal a certification ban § 170.523(s) that they report, at a Therefore, we estimate the annual cost and/or termination under minimum, on a weekly basis to the to ONC would, on average, range from § 170.581(a)(2)(iii) and respond to any National Coordinator any circumstances $98,192 to $196,384. requests from the hearing officer. that could trigger ONC direct review per Benefits According to the May 2016 BLS § 170.580(a)(2). We estimate that, on Information blocking not only occupational employment statistics, the average, it will take an ONC–ACB interferes with effective health mean hourly wage for a computer employee at the GS–13, Step 1 level information exchange, but also systems analyst is $44.05.186 Assuming approximately 30 minutes to prepare negatively impacts many important that overhead costs (including benefits) the report. The hourly wage with aspects of health and health care. To are equal to 100% of pre-tax wages, the benefits for a GS–13, Step 1 employee make informed health care decisions, hourly wage including overhead costs is located in Washington, DC is providers and individuals must have $88.10. Therefore, we estimate the approximately $88.30. Since the timely access to information in a form annual cost, including overhead costs, collection must occur no less than that is usable. When health information for a health IT developer to appeal a weekly, we will assume it occurs, on is unavailable, decisions can be certification ban and/or termination average, 52 times per year. Therefore, impaired—and so too the safety, quality, under § 170.581(a)(2)(iii) would, on given that there are currently three and effectiveness of care provided to average, range from $5,286 to $35,240. ONC–ACBs, we estimate the annual cost patients. Information blocking impedes We note that some health IT developers’ to ONC–ACBs to comply with the progress towards reforming health care costs are expected to be less and some reporting requirement under delivery and payment because sharing health IT developers’ costs are expected § 170.523(s) would, on average, be information seamlessly across the care to be more than this estimated cost $6,889. continuum is fundamental to moving to range. Further, we note that these costs Benefits a person-centered, high-performing would be perpetual. This proposed rule’s provisions for health care system. Information We estimate that ONC would commit, ONC direct review of the Conditions blocking can undermine consumers’ on average and depending on and Maintenance of Certification confidence in their health care providers by preventing individuals 186 See https://www.bls.gov/oes/2016/may/ requirements would promote health IT oes439061.htm. https://www.bls.gov/oes/2016/may/ developers’ accountability for their from accessing their health information oes439061.htm. actions and ensure that health IT and using it to make informed decisions

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00162 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7585

about their health and health care. electronic health information with developing and using interoperable Information blocking also prevents providers outside their hospital technologies and services to improve advances in biomedical and public system.189 There is also emerging health care efficiency and value. health research, which require the evidence related to the negative impacts Overall, the proposed exceptions are ability to analyze information from of information blocking at the market accommodating to legitimate industry many sources in order to identify public level on hospitals’ health information practices for health IT developers, health risks, develop new treatments exchange activity.190 Health information hospitals, and health care providers and cures, and enable precision exchange activity among hospitals who and, we believe, would ease the burden medicine. are using a dominant health IT and compliance costs for these parties. In addition, information blocking is a developer within a given hospital Due to limited data and research practice that is profoundly anti- referral region was found to be available, we have only estimated the consumer and anti-competition. significantly higher compared to those benefits of our information blocking Information blocking can be used to that are using a non-dominant health IT proposals for payers, specifically increase revenue, escalate prices, and developer, particularly in more patients and insurers. In order to prevent market competition both for competitive markets where dominant quantify the magnitude of information current and future competitors and for health IT developers had a smaller share blocking and the benefits of restricting new services. For instance, a study of the market. As information blocking information blocking, we estimated the released in 2017 about the prevalence of diminishes and information blocking following expression, which gives us information blocking and how to becomes less prevalent, such gaps in the imposed cost of information address it assessed the perceived rates of exchange and barriers to blocking for each health outcome: [% motivations for information blocking. exchange of health information should providers that engage in cross-vendor The study found that respondents diminish. Considering the above exchange] × [marginal effect (ME) of perceived that information-blocking motivations for and consequences of information blocking] × [ME effect of practices by health IT developers were information blocking, we believe health interoperability] × [total cost of health often motivated by a desire to maximize care providers and patients will benefit outcome]. short-term revenue and to increase the greatly from compliance with the We extracted the ‘‘ME effect of likelihood that providers will select information blocking definition. Our interoperability’’ and ‘‘cost of health their health IT instead of a competitor’s proposal would promote the free flow of outcomes’’ from academic literature (see health IT. Among hospitals and health electronic health information when and citations in Table 24). We used a proxy systems, the most frequent perceived where it is needed. of the ‘‘percent of providers engaged in motivation was also related to We have also included provisions in cross-vendor exchange’’ with the improving revenue, namely to this proposed rule that would establish ‘‘percent of hospitals engaged in cross- strengthen their competitive position in exceptions to the definition of vendor referral of patients outside their the market, followed by accommodating information blocking, which we system’’ (82% in 2015). more important internal priorities than estimate will generate significant net We estimated the ‘‘ME of information health information exchange.187 benefits. As noted above, section 3022 blocking’’ through the following According to leaders of health of the PHSA defines information research design. We looked at hospitals information exchange efforts, blocking broadly section 3022(a)(3) that switched vendors and examined information blocking is relatively instructs authorizes the Secretary to their referral patterns before and after widespread.188 Half of leaders of health identify reasonable and necessary the switch. If hospitals that switched information exchange efforts (n = 60) activities that would be considered vendors also had to change their referral nationwide reported that they routinely establish exceptions to the definition of patterns, this could be evidence of encountered information blocking by information blocking. In this rule, we information blocking. To operationalize health IT developers. The top three propose to establish several exceptions. this experiment, we estimated the types of information blocking practices The exceptions, if finalized, would following equation: they encountered on a routine basis create clear guidelines for industry Y = b * S + r + h + e. included: regarding pro-competitive and other • In this equation, the variables are as Deployment of products with beneficial activities and would enable follows: limited interoperability (49%); stakeholders to determine more easily • • Y = Percent of referrals to providers using High fees for health information and with greater certainty whether their a vendor to which the hospital switched exchange unrelated to cost (47%); and activities are excepted from the • • Making third-party access to b = Estimate of interest, which reflects the information blocking definition. The change in referral to the vendors after the standardized data difficult (42%). additional clarity provided by the switch relative to hospitals that did not Many hospitals have experienced the exceptions would make it easier for switch. After controlling for hospital and negative impacts of health IT developer these regulated entities to comply with year fixed, this is essentially an interaction information blocking practices. In 2015, the statute—resulting in reduced effect of the year with the switch. • almost half of hospitals (46%) compliance costs—and would result in S = Indicator for whether hospital switched nationwide reported difficulty increased predictability, which would vendor • r = Year exchanging data with providers whose allow regulated entities to more health IT system differed from theirs • h = Hospital fixed effects effectively plan and invest resources in • and one-quarter of hospitals reported e = Error term (every regression has an error term) paying additional costs to exchange 189 Vaishali Patel, JaWanna Henry, Yuriy Pylypchuk, and Talisha Searcy, Interoperability We used CMS referral data and linked 187 Julia Adler-Milstein and Eric Pfeifer, among U.S. Non-federal Acute Care Hospitals in it with Healthcare Information and Information Blocking: Is It Occurring And What 2015, ONC Data Brief, No.36 (May 2016). Management Systems Society (HIMSS) Policy Strategies Can Address It?, 95 Milbank 190 Jordan Everson and Julia Adler-Milstein, and AHA data for information on Quarterly 117 (Mar. 2017) at 124–5, available at Engagement In Hospital Health Information http://onlinelibrary.wiley.com/doi/10.1111/1468- Exchange Is Associated With Vendor Marketplace hospitals’ vendors and other 0009.12247/full. Dominance, Health Affairs. 35, No. 7 (2016), at characteristics. Our estimate for ‘‘b’’ is 188 Id. 1286–93. 0.4 percentage points, meaning if a

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00163 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7586 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

hospital switches to vendor X, the information blocking. One source of having the same vendor. Nevertheless, referrals to hospitals with that vendor difficulties could be explained by to keep our estimates conservative, we increases by a rate of 0.4 percentage technological challenges where inherent reduced our estimates by a factor of five. points. This number we interpret as a software differences among vendors Hence, we use 0.08 percentage points as proxy for the extent to which difficulties hinder cross vendor exchange. An the ‘‘ME of information blocking.’’ in cross vendor exchange hinder patient additional reason for this result could be Our estimates are detailed in the table care. However, our finding does not attributed to contractual agreements below. imply that difficulties in cross vendor where vendors may incentivize their exchange can be entirely attributed to clients to exchange with other clients

TABLE 24—BENEFITS OF PROHIBITING AND/OR DETERRING INFORMATION BLOCKING [2016 Dollars]

Overall Percent of Marginal Percent of interop impact providers effect of Benefit type total cost Total cost susceptible to Benefit a impacted (marginal information information effect) blocking blocking

Duplicate testing ...... 100 200 Billion b ...... c 0.09 82 0.08 $1.1B Avoidable hospitalizations 100 $41B d ...... 0.09 82 0.08 242M and readmissions. ER visits ...... 100 Cost per ER visit $1,233, 0.03 82 0.08 317M 131M visits e. Adverse drug events ...... 100 $30 billion f ...... 0.22 82 0.08 86M

Total benefit per year ...... 1.8B a Total benefit is a product of % of total cost impacted, total cost, overall interop impact, percent of providers susceptible to information block- ing, and marginal effect of information blocking. 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.

We request comment on our approach $311,000. We estimate the government (8) Total Annual Net Benefit to estimating these benefits, as well as (ONC) costs to be between $44,800 and We estimate the total annual net the benefit estimates in the table above. $269,000 while saving $4,500. In benefit for this proposed rule for the (6) Total Annual Cost Estimate addition, to the above mentioned cost first year after it is finalized (including savings that are attributable to specific one-time costs), based on the estimates We estimate that the total annual cost stakeholder groups, we estimate to an outlined above, would range from $2.7 for this proposed rule for the first year additional cost savings of $6.8 million billion to $8.2 billion with an average after it is finalized (including one-time to $13.7 million to all stakeholders net benefit of $5.5 billion. We estimate costs), based on the cost estimates affected by this proposal. We are unable the total perpetual annual net benefit for outlined above and throughout this RIA, to attribute these amounts to specific this proposed rule (starting in year two), would, on average, range from $365 stakeholder groups. based on the estimates outlined above, million to $919 million with an average would range from $2.9 billion to $8.7 annual cost of $642 million. We (7) Total Annual Benefit Estimate billion with an average net benefit of estimate that the total perpetual cost for $5.8 billion. this proposed rule (starting in year two), We estimate the total annual benefit based on the cost estimates outlined for this proposed rule, based on the b. Accounting Statement and Table above, would, on average, range from benefit estimates outlined above, would When a rule is considered an $228 million to $452 million with an range from $3.08 billion to $9.15 billion economically significant rule under average annual cost of $340 million. We with an average annual benefit of $6.1 Executive Order 12866, we are required also include estimates based on the billion. We attribute between $756 to develop an accounting statement stakeholder group affected. We estimate million and $3.8 billion in benefits to indicating the classification of the the total costs to health IT developers to hospitals and clinicians. We attribute expenditures associated with the be between $373 million and $933 between $2.1 billion and $2.9 billion to provisions of the proposed rule. million (including one-time and payers and patients. Our estimates Monetary annual benefits are presented perpetual costs) with $569,000 in cost include benefits attributed to the whole as discounted flows using 3% and 7% savings. We estimate the total costs to health care system, not just to the factors in Table 25 below. We are not ONC–ACBs to be between $213,000 and stakeholders mentioned above. able to explicitly define the universe of

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00164 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7587

all costs, but have provided an average costs. This proposed rule requires no of likely costs of this proposed rule as federal annual monetized transfers. well as a high and low range of likely

TABLE 25—E.O. 12866 SUMMARY TABLE [In $ millions, 2016 time period]

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

Present Value of Quantified Costs ...... 1,557 1,043 2,070 1,394 934 1,853 Non-quantified Costs ...... Text ...... Present Value of Quantified Benefits ...... 27,998 14,100 41,896 25,067 12,624 37,509 Non-quantified Benefits ...... Text ...... Present Value of Net Benefits ...... 2,456 1,129 37,620 2,190 1,011 33,681 Annualized Quantified Costs ...... 330 355 433 318 365 422 Non-quantified Costs ...... Text ...... Annualized Quantified Benefits...... 5,935 2,989 8,881 5,714 2,878 8,550 Non-quantified Benefits ...... Text ...... Annualized Net Quantified Benefits ...... 5,184 2,304 7,975 4,991 2,838 8,128

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

Year 1 Year 2 Year 3 Year 4 Year 5

Costs ...... $641,853,087 $339,870,993 $339,870,993 $339,870,993 $339,870,993 Net Benefits ...... 5,471,742,914 5,773,725,008 5,773,725,008 5,773,725,008 5,773,725,008

Year 6 Year 7 Year 8 Year 9 Year 10

Costs ...... $339,870,993 $339,870,993 $339,870,993 $339,870,993 $339,870,993 Net Benefits ...... 5,773,725,008 5,773,725,008 5,773,725,008 5,773,725,008 5,773,725,008

3. Regulatory Flexibility Act considering the size and resources of SBA related to NAICS code 541511, it The Regulatory Flexibility Act (RFA) small entities when meeting security appears that many health IT developers requires agencies to analyze options for requirements to qualify for the that pursue certification of their health regulatory relief of small businesses if a ‘‘promoting the security of electronic IT under the Program are privately held rule has a significant impact on a health information’’ exception. We refer or owned and do not regularly, if at all, make their specific annual receipts substantial number of small entities. readers to section VIII for our publicly available. As a result, it is The Small Business Administration information blocking-related proposals difficult to locate empirical data related (SBA) establishes the size of small and welcome comments on their to many of these health IT developers to businesses for federal government impacts on small entities. correlate to the SBA size standard. programs based on average annual While health IT developers that However, although not perfectly receipts or the average employment of a pursue certification of their health IT correlated to the size standard for firm.191 The entities that are likely to be under the Program represent a small NAICS code 541511, we do have directly affected by the requirements in segment of the overall information information indicating that over 60% of this proposed rule requirements are technology industry, we believe that health IT developers that have had health IT developers. We note that the many health IT developers impacted by the requirements proposed in this Complete EHRs and/or Health IT proposed reasonable and necessary Modules certified to the 2011 Edition activities that do not constitute proposed rule most likely fall under the North American Industry Classification have less than 51 employees. information blocking provide We estimate that the proposed flexibilities and relief for health IT System (NAICS) code 541511 ‘‘Custom Computer Programming Services.’’ 192 requirements in this proposed rule developers of certified health IT, health would have effects on health IT The SBA size standard associated with information networks, health developers, some of which may be small this NAICS code is set at $27.5 million information exchanges, and health care entities, that have certified health IT or annual receipts or less. There is enough providers in relation to the information are likely to pursue certification of their data generally available to establish that blocking provision of the Cures Act. health IT under the Program. We between 75% and 90% of entities that These proposed reasonable and believe, however, that we have are categorized under the NAICS code necessary activities also take into proposed the minimum amount of 541511 are under the SBA size standard. account the potential burden on small requirements necessary to accomplish We also note that with the exception of entities to meet these ‘‘exceptions’’ to our primary policy goal of enhancing aggregate business information available information blocking, such as with interoperability. Further, as discussed in through the U.S. Census Bureau and the section XIV.B of this RIA above, there 191 The SBA references that annual receipts are no appropriate regulatory or non- means ‘‘total income’’ (or in the case of a sole 192 https://www.sba.gov/sites/default/files/files/ proprietorship, ‘‘gross income’’) plus ‘‘cost of goods Size_Standards_Table_2017.pdf. https:// regulatory alternatives that could be sold’’ as these terms are defined and reported on www.sba.gov/sites/default/files/files/Size_ developed to lessen the compliance Internal Revenue Service tax return forms. Standards_Table_2017.pdf. burden associated with this proposed

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00165 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7588 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

rule because many of the proposals are extent permitted by law, be offset by the ■ b. Amend the definition of ‘‘2015 derived directly form legislative elimination of existing costs associated Edition Base EHR’’ by revising mandates in the Cures Act. with at least two prior regulations.’’ The paragraph (3); Additionally, we have attempted to Department believes that this rule is a ■ c. Add, in alphabetical order, the offset some of the burden imposed on significant regulatory action as defined definitions for ‘‘API Data Provider’’, health IT developers in this proposed by Executive Order 12866 which ‘‘API Technology Supplier’’, and ‘‘API rule with cost saving proposals through imposes costs, and therefore is User’’; deregulatory actions (see proposed considered a regulatory action under ■ d. Remove the definitions of section III). Executive Order 13771. The Department ‘‘Common Clinical Data Set’’, and We do not believe that the proposed estimates that this rule generates $275 ‘‘Complete EHR, 2014 Edition’’; and requirements of this proposed rule million in annualized costs at a 7% ■ e. Add, in alphabetical order, the would create a significant impact on a discount rate, discounted relative to definitions for ‘‘Fee’’, ‘‘Interoperability’’, substantial number of small entities, but 2016, over a perpetual time horizon. and ‘‘Interoperability element’’. request comment on whether there are OMB reviewed this proposed rule. The revisions and additions read as small entities that we have not follows: identified that may be affected in a List of Subjects § 170.102 Definitions. significant way by this proposed rule. 45 CFR Part 170 Additionally, the Secretary proposes to * * * * * Computer technology, Electronic certify that this proposed rule would not health record, Electronic information 2015 Edition Base EHR * * * have a significant impact on a system, Electronic transactions, Health, (3) Has been certified to the substantial number of small entities. Health care, Health information certification criteria adopted by the 4. Executive Order 13132—Federalism technology, Health insurance, Health Secretary in— Executive Order 13132 establishes records, Hospitals, Incorporation by (i) Section 170.315(a)(1), (2), or (3); certain requirements that an agency reference, Laboratories, Medicaid, (5); (9); (14); (b)(1); (c)(1); (g)(7) and (9); must meet when it promulgates a Medicare, Privacy, Reporting and and (h)(1) or (2); (ii) Section 170.315(g)(8) or (10) until proposed rule (and subsequent final recordkeeping requirements, Public [24 months from the final rule’s rule) that imposes substantial direct health, Security. effective date]; and requirement costs on state and local 45 CFR Part 171 (iii) Section 170.315(b)(10) and (g)(10) governments, preempts state law, or Computer technology, Electronic on and after [24 months from the final otherwise has federalism implications. rule’s effective date]. Nothing in this proposed rule imposes health record, Electronic information substantial direct compliance costs on system, Electronic transactions, Health, * * * * * state and local governments, preempts Health care, Health care provider, API Data Provider refers to the state law, or otherwise has federalism Health information exchange, Health organization that deploys the API implications. We are not aware of any information technology, Health technology created by the ‘‘API state laws or regulations that are information network, Health insurance, Technology Supplier’’ and provides contradicted or impeded by any of the Health records, Hospitals, Privacy, access via the API technology to data it proposals in this proposed rule. We Reporting and recordkeeping produces and electronically manages. In welcome comments on this assessment. requirements, Public health, Security. some cases, the API Data Provider may For the reasons set forth in the contract with the API Technology 5. Unfunded Mandates Reform Act of preamble, 45 CFR subtitle A, subchapter Supplier to perform the API deployment 1995 D, is proposed to be amended as service on its behalf. However, in such Section 202 of the Unfunded follows: circumstances, the API Data Provider Mandates Reform Act of 1995 requires retains control of what and how that agencies assess anticipated costs PART 170—HEALTH INFORMATION information is disclosed and so for the and benefits before issuing any rule that TECHNOLOGY STANDARDS, purposes of this definition is considered imposes unfunded mandates on state, IMPLEMENTATION SPECIFICATIONS, to be the entity that deploys the API local, and tribal governments or the AND CERTIFICATION CRITERIA AND technology. private sector requiring spending in any CERTIFICATION PROGRAMS FOR API Technology Supplier refers to a one year of $100 million in 1995 dollars, HEALTH INFORMATION health IT developer that creates the API updated annually for inflation. The TECHNOLOGY technology that is presented for testing current inflation-adjusted statutory and certification to any of the ■ 1. The authority citation for part 170 threshold is approximately $150 certification criteria adopted or continues to read as follows: million. While the estimated potential proposed for adoption at § 170.315(g)(7) cost effects of this proposed rule reach Authority: 42 U.S.C. 300jj–11; 42 U.S.C through (11). the statutory threshold, we do not 300jj–14; 5 U.S.C. 552. API User refers to persons and entities that use or create software applications believe this proposed rule imposes ■ 2. Revise § 170.101 to read as follows: unfunded mandates on state, local, and that interact with the APIs developed by tribal governments or the private sector. § 170.101 Applicability. the ‘‘API Technology Supplier’’ and We welcome comments on these The standards, implementation deployed by the ‘‘API Data Provider.’’ conclusions. specifications, and certification criteria An API User includes, but is not limited adopted in this part apply to Health IT to, third-party software developers, 6. Executive Order 13771 Reducing Modules and the testing and developers of software applications Regulation and Controlling Regulatory certification of such Health IT Modules. used by API Data Providers, and Costs ■ 3. Amend § 170.102 as follows: patients and health care providers that Executive Order 13771 (January 30, ■ a. Remove the definitions of ‘‘2014 use apps that connect to API technology 2017) requires that the costs associated Edition Base EHR’’, and ‘‘2014 Edition on their behalf. with significant new regulations ‘‘to the EHR certification criteria’’; * * * * *

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00166 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7589

Fee is defined as it is in § 171.102 of Architecture Category I Hospital Quality Release 3 Standard for Trial Use (STU) this subchapter. Reporting Implementation Guide for 3 (v3.0.1) (incorporated by reference in * * * * * 2019 (incorporated by reference in § 170.299). Interoperability is, with respect to § 170.299). (2) Implementation specification— health information technology, such * * * * * FHIR consent resources. HL7 health information technology that— (k) * * * Consent2Share FHIR Consent Profile (i) Enables the secure exchange of (3) CMS Implementation Guide for Design (incorporated by reference in electronic health information with, and Quality Reporting Document § 170.299). use of electronic health information Architecture Category III Eligible ■ 12. Amend § 170.299 as follows: from, other health information Clinicians and Eligible Professionals ■ a. Remove and reserve paragraphs technology without special effort on the Programs Implementation Guide for (c)(2), (3), (d)(2), (7), and (8); part of the user; 2019 (incorporated by reference in ■ b. Add paragraphs (e)(4) and (5); (ii) Allows for complete access, § 170.299). ■ c. Remove and reserve paragraphs exchange, and use of all electronically * * * * * (f)(3), (6), (7), (10), and (11); accessible health information for ■ d. Add paragraphs (f)(30) through authorized use under applicable state or § 170.207 [Amended] (36); federal law; and ■ 8. Amend § 170.207 by removing and ■ e. Redesignate paragraphs (o) through (iii) Does not constitute information reserving paragraphs (d)(2), (e)(2), (g)(1), (r) and (g) through (n) as paragraphs (q) blocking as defined in § 171.103 of this (h), and (j). through (t) and (h) through (o), subchapter. respectively; Interoperability element is defined as § 170.210 [Amended] ■ f. Add new paragraph (g) and it is in § 171.102 of this subchapter. ■ 9. Amend § 170.210 by removing and paragraph (i)(4); * * * * * reserving paragraphs (a)(1) and (c)(1). ■ g. Remove and reserve newly ■ 10. Add § 170.213 to read as follows: redesignated paragraph (k)(1); § 170.200 [Amended] ■ h. Add paragraph (l)(3); § 170.213 United States Core Data for ■ ■ 4. Amend § 170.200 by removing the Interoperability i. Remove and reserve newly phrase ‘‘Complete EHRs and.’’ redesignated paragraph (m)(3); Standard. United States Core Data for ■ j. Add paragraphs (n)(5) and (6); § 170.202 [Amended] Interoperability (USCDI), Version 1 (v1) ■ k. Add new paragraph (p); and ■ 5. Amend § 170.202 by removing and (incorporated by reference in § 170.299). ■ ■ l. Remove and reserve newly reserving paragraph (a)(1). 11. Add § 170.215 to read as follows: redesignated paragraphs (s)(4), and (5). The additions and revisions read as § 170.204 [Amended] § 170.215 Application Programming Interface Standards. follows: ■ 6. Amend § 170.204 by removing and The Secretary adopts the following reserving paragraphs (b)(1) and (2), and § 170.299 Incorporation by reference. application programming interface (API) by removing paragraph (c). standards and associated * * * * * ■ 7. Amend § 170.205 as follows: (e) * * * ■ a. Remove and reserve paragraphs implementation specifications: (a)(1) Standard. HL7 Fast Healthcare (4) CMS Implementation Guide for (a)(1) and (2); Quality Reporting Document ■ b. Add paragraph (a)(4)(i) and add and Interoperability Resources (FHIR) Draft Standard for Trial Use (DSTU) 2 Architecture Category I Hospital Quality reserve paragraph (a)(4)(ii); Reporting Implementation Guide for ■ (v1.0.2–7202) (incorporated by reference c. Add paragraph (b)(1); 2019, May 4, 2018, IBR approved for ■ in § 170.299). d. Remove and reserve paragraphs § 170.205(h). (d)(2), (d)(3), (e)(3), (h)(1), (i)(1), and (j); (2) Implementation specifications. API Resource Collection in Health (5) CMS Implementation Guide for and Quality Reporting Document ■ e. Add paragraphs (h)(3) and (k)(3). (ARCH) Version 1 (incorporated by Architecture Category III Eligible The revisions read as follows: reference in § 170.299). (3) Implementation specifications— Clinicians and Eligible Professionals § 170.205 Content exchange standards FHIR profiles. Argonaut Data Query Programs Implementation Guide for and implementation specifications for Implementation Guide Version 1.0.0 2019, October 8, 2018, IBR approved for exchanging electronic health information. (incorporated by reference in § 170.299). § 170.205(k). (a) * * * (4) Implementation specifications— (f) * * * (4) * * * (30) HL7 CDA Release 2 ® FHIR server conformance. Argonaut (i) Standard. HL7 CDA R2 Data Query Implementation Guide Implementation Guide: C–CDA Implementation Guide: C–CDA Server (incorporated by reference in Templates for Clinical Notes R1 Templates for Clinical Notes R1 § 170.299). Companion Guide, Release 1, March Companion Guide, Release 1 (5) Implementation specification— 2017, IBR approved for § 170.205(a). (incorporated by reference in § 170.299). Application authorization. HL7 SMART (31) HL7 Fast Healthcare (ii) [Reserved] Application Launch Framework Interoperability Resources (FHIR®) * * * * * Implementation Guide Release 1.0.0, Release 2.0, Draft Standard for Trial Use (b) * * * including mandatory support for (DSTU) Version 1.0.2–7202, October 24, (1) Standard. National Council for ‘‘refresh tokens,’’ ‘‘Standalone Launch,’’ 2015, IBR approved for § 170.215(a). Prescription Drug Programs (NCPDP), and ‘‘EHR Launch’’ requirements (32) HL7 Fast Healthcare Script Standard Implementation Guide, (incorporated by reference in § 170.299). Interoperability Resource Specification Version 2017071 (incorporated by (b) Application authentication. (FHIR®) Release 3 Standard for Trial reference in § 170.299). Standard. OpenID Connect Core 1.0 Use (STU), Version 3.0.1, February 21, * * * * * incorporating errata set 1 (incorporated 2017, IBR approved for § 170.215(c). (h) * * * by reference in § 170.299). (33) HL7 Fast Healthcare (3) CMS Implementation Guide for (c)(1) Standard. HL7 Fast Healthcare Interoperability Resources Specification Quality Reporting Document Interoperability Resources (FHIR) (FHIR®) Release 4, Version 4.0.0,

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00167 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7590 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

December 27, 2018, IBR approved for § 170.314 [Removed and Reserved] (1) Assessment and plan of treatment. § 170.215. ■ 15. Remove and reserve § 170.314. In accordance with the ‘‘Assessment (34) HL7 Implementation ■ 16. Amend § 170.315 as follows: and Plan Section (V2)’’ of the standard Specification—FHIR Profile: ■ a. Remove and reserve paragraphs specified in § 170.205(a)(4) and (a)(4)(i); Consent2Share FHIR Consent Profile (a)(6) through (8), (10); (11); and (13); or in accordance with the ‘‘Assessment Design, December 11, 2017, IBR ■ b. In paragraphs (b)(1)(ii)(A) Section (V2)’’ and ‘‘Plan of Treatment approved for § 170.215(c). introductory text, (b)(1)(ii)(A)(2), (3), Section (V2)’’ of the standard specified (35) HL7 CDA R2 Implementation (b)(1)(ii)(B) and (C), remove the in § 170.205(a)(4) and (a)(4)(i). Guide: C–CDA Supplemental Templates reference ‘‘§ 170.205(a)(3) and (2) Goals. In accordance with the for Unique Device Identification (UDI) § 170.205(a)(4)’’ and add in its place the ‘‘Goals Section’’ of the standard for Implantable Medical Devices, reference ‘‘§ 170.205(a)(3), (a)(4), and specified in § 170.205(a)(4) and (a)(4)(i). Release 1—US Realm, November 15, (a)(4)(i)’’; (3) Health concerns. In accordance 2018, IBR approved for § 170.205. ■ c. In paragraph (b)(1)(iii) introductory with the ‘‘Health Concerns Section’’ of (36) HL7 SMART Application Launch text, remove the reference the standard specified in § 170.205(a)(4) Framework Implementation Guide ‘‘§ 170.205(a)(4)’’ and add in its place and (a)(4)(i). Release 1.0.0, November 13, 2018, IBR the reference ‘‘§ 170.205(a)(3), (a)(4), (4) Unique device identifier(s) for a approved for § 170.215(a). and (a)(4)(i)’’; patient’s implantable device(s). In (g) HL7® FHIR® Foundation. 3300 ■ d. Revise paragraph (b)(1)(iii)(A); accordance with the ‘‘Product Instance’’ Washtenaw Avenue, Suite 227, Ann ■ e. In paragraph (b)(2)(i) and (ii), in the ‘‘Procedure Activity Procedure Arbor, MI 48104; Telephone (734) 677– remove the reference ‘‘§ 170.205(a)(3) Section’’ of the standard specified in 7777 or https://www.fhir.org/. and § 170.205(a)(4)’’ and add in its place § 170.205(a)(4) and (a)(4)(i). (1) Argonaut Data Query the reference ‘‘§ 170.205(a)(3), (a)(4), * * * * * Implementation Guide. Version 1.0.0, and (a)(4)(i)’’; (4) [Reserved] December 23, 2016, IBR approved for ■ f. Remove and reserve paragraphs (5) [Reserved] § 170.215(a). (b)(4) through (8); (6) [Reserved] (7) [Reserved] (2) Argonaut Data Query ■ g. Revise paragraph (b)(9); Implementation Guide Server, Version ■ (8) [Reserved] h. Add paragraphs (b)(10), (11), (12), (9) Care plan. Enable a user to record, 1.0.2, December 15, 2016, IBR approved (13), change, access, create, and receive care for § 170.215(a). ■ i. Revise paragraph (c)(3); plan information in accordance with: ■ * * * * * j. Add paragraphs (d)(12), and (13); (i) The Care Plan document template, ■ (i) * * * k. Revise paragraph (e)(1)(i)(A)(1); including the Health Status Evaluations ■ (4) OAuth 2.0 Dynamic Client l. In paragraph (e)(1)(i)(B)(1)(ii) and and Outcomes Section and Registration Protocol (RFC 7591), July (e)(1)(i)(B)(2) introductory text, remove Interventions Section (V2), in the 2015, IBR approved for § 170.215. the reference ‘‘§ 170.205(a)(4)’’ and add standard specified in § 170.205(a)(4); * * * * * in its place the reference and (l) * * * ‘‘§ 170.205(a)(4) and (a)(4)(i)’’; (ii) The standard in § 170.205(a)(4)(i). (3) National Council for Prescription ■ m. Remove and reserve paragraph (10) Electronic health information Drug Programs (NCPDP), Script (e)(1)(ii)(B); export. (i) Single patient electronic Standard Implementation Guide, ■ n. Remove and reserve paragraph health information export. Version 2017071 (Approval Date for (e)(2); (A) Enable a user to timely create an ANSI: July 28, 2017), IBR approved for ■ o. Revise paragraphs (f)(5)(iii)(B)(1), export file(s) with all of a single § 170.205(b). (g)(6) introductory text, (g)(6)(i) and (iv); patient’s electronic health information ■ p. Revise paragraphs (g)(1) and (g)(2) * * * * * the health IT produces and (n) * * * by removing ‘‘EHR Incentive Programs’’ electronically manages on that patient. (5) ONC United States Core Data for and adding in its place ‘‘Promoting (B) A user must be able to execute this Interoperability (USCDI), Version 1 (v1), Interoperability Programs’’; capability at any time the user chooses ■ q. Revising paragraph (g)(3)(i); and without subsequent developer February 11, 2019, IBR approved for ■ § 170.213; available at https:// r. In paragraphs (g)(6)(ii) and (iii), assistance to operate. www.healthit.gov/USCDI. Remove the reference ‘‘§ 170.205(a)(4)’’ (C) Limit the ability of users who can (6) API Resource Collection in Health and add in its place the reference create such export file(s) in at least one ‘‘§ 170.205(a)(4) and (a)(4)(i)’’; of these two ways: (ARCH) Version 1, February 1, 2019, ■ IBR approved for § 170.215(a); available s. Revise paragraph (g)(6)(iv); (1) To a specific set of identified ■ t. Remove paragraphs (g)(7)(ii)(A)(3); at https://www.healthit.gov/ARCH. users. ■ u. Revise paragraph (g)(9)(i)(A); (2) As a system administrative * * * * * ■ v. Remove paragraph (g)(9)(ii)(A)(3); function. (p) OpenID Foundation, 2400 Camino and (D) The export file(s) created must be Ramon, Suite 375, San Ramon, CA ■ w. Add paragraphs (g)(10) and (g)(11). electronic and in a computable format. 94583, Telephone +1 925–275–6639, The revisions and additions read as (E) The export file(s) format, http://openid.net/. follows: including its structure and syntax, must (1) OpenID Connect Core 1.0 be included with the exported file(s). Incorporating Errata Set 1, November 8, § 170.315 2015 Edition health IT (ii) Database export. Create an export 2014, IBR approved for § 170.215(b). certification criteria. of all the electronic health information (2) [Reserved] * * * * * the health IT produces and * * * * * (b) * * * electronically manages. (1) * * * (A) The export created must be § 170.300 [Amended] (iii) * * * electronic and in a computable format. ■ 14. Amend § 170.300 in paragraphs (a) (A) The data classes expressed in the (B) The export’s format, including its and (c) by removing the phrase standard in § 170.213 and, including as structure and syntax must be included ‘‘Complete EHRs and’’. specified for the following data: with the export.

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00168 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7591

(iii) Documentation. The export record formatted in accordance with the specified in § 170.205(a)(4) and (a)(4)(i); format(s) used to support single patient standard adopted in § 170.205(a)(4) and or in accordance with the ‘‘Assessment electronic health information export as (a)(4)(i) that is tagged as restricted at the Section (V2)’’ and ‘‘Plan of Treatment specified in paragraph (b)(10)(i) of this document, section, and entry (data Section (V2)’’ of the standard specified section and database export as specified element) level and subject to restrictions in § 170.205(a)(4) and (a)(4)(i). in paragraph (b)(10)(ii) of this section on re-disclosure according to the (ii) Goals. In accordance with the must be made available via a publicly standard adopted in § 170.205(o)(1). ‘‘Goals Section’’ of the standard accessible hyperlink. (13) Data segmentation for privacy— specified in § 170.205(a)(4) and (a)(4)(i). (11) Electronic prescribing. (i) Enable receive. Enable a user to: (iii) Health concerns. In accordance a user to perform all of the following (i) Receive a summary record that is with the ‘‘Health Concerns Section’’ of prescription-related electronic formatted in accordance with the the standard specified in § 170.205(a)(4) transactions in accordance with the standard adopted in § 170.205(a)(4) and and (a)(4)(i). standard specified in § 170.205(b)(1) (a)(4)(i) that is tagged as restricted at the (iv) Unique device identifier(s) for a and, at a minimum, the version of the document, section, and entry (data patient’s implantable device(s). In standard specified in § 170.207(d)(3) as element) level and subject to restrictions accordance with the ‘‘Product Instance’’ follows: on re-disclosure according to the in the ‘‘Procedure Activity Procedure (A) Ask mailbox (GetMessage). standard adopted in § 170.205(o)(1); and Section’’ of the standard specified in (B) Relay acceptance of transaction (ii) Preserve privacy markings to § 170.205(a)(4) and (a)(4)(i). (Status). ensure fidelity to the tagging based on * * * * * (C) Error response (Error). consent and with respect to sharing and (ii) * * * (D) Create new prescriptions (NewRx, re-disclosure restrictions. (B) [Reserved] NewRxRequest, (c) * * * * * * * * NewRxResponseDenied). (3) Clinical quality measures—report. (E) Change prescriptions (f) * * * Enable a user to electronically create a (RxChangeRequest, RxChangeResponse). (5) * * * (F) Renew prescriptions data file for transmission of clinical (iii) * * * (RxRenewalRequest, quality measurement data in accordance (B) * * * RxRenewalResponse). with the implementation specifications (1) The data classes expressed in the (G) Resupply (Resupply). specified in § 170.205(h)(3) and (k)(3). standard in § 170.213. (H) Return receipt (Verify). * * * * * * * * * * (I) Cancel prescriptions (CancelRx, (d) * * * (g) Design and performance—(1) CancelRxResponse). * * * * * Automated numerator recording. For (J) Receive fill status notifications (12) Encrypt authentication each Promoting Interoperability (RxFill, RxFillIndicatorChange). credentials. Health IT developers must Programs percentage-based measure, (K) Drug administration assess their Health IT Modules’ technology must be able to create a (DrugAdministration). capabilities and make one of the report or file that enables a user to (L) Transfer (RxTransferRequest, following attestations: review the patients or actions that RxTransferResponse, (i) ‘‘Yes.’’ Health IT Module encrypts would make the patient or action RxTransferConfirm). stored authentication credentials in eligible to be included in the measure’s (M) Recertify (Recertification). numerator. The information in the (N) Request and receive medication accordance with standards adopted in report or file created must be of history (RxHistoryRequest, § 170.210(a)(2). sufficient detail such that it enables a RxHistoryResponse). (ii) ‘‘No.’’ Health IT Module does not (O) Complete risk evaluation and encrypt stored authentication user to match those patients or actions mitigation strategy transactions credentials. to meet the measure’s denominator (REMSInitiationRequest, (13) Multi-factor Authentication. limitations when necessary to generate REMSInitiationResponse, Health IT developers must assess their an accurate percentage. (2) Automated measure Calculation. REMSRequest, and REMSResponse). Health IT Modules’ capabilities and (ii) For each transaction listed in make one of the following attestations: For each Promoting Interoperability paragraph (b)(11)(i) of this section, the (i) ‘‘Yes.’’ Health IT Module supports Programs percentage-based measure that technology must be able to receive and authentication through multiple is supported by a capability included in transmit the reason for the prescription elements the identity of the user with a technology, record the numerator and using the diagnosis elements in DRU industry recognized standards. denominator and create a report Segment. (ii) ‘‘No.’’ Health IT Module does not including the numerator, denominator, (iii) Optional. For each transaction support authentication through multiple and resulting percentage associated with listed in paragraph (b)(11)(i) of this elements the identity of the user with each applicable measure. section, the technology must be able to industry recognized standards. (3) * * * receive and transmit the reason for the (e) * * * (i) User-centered design processes prescription using the indication (1) * * * must be applied to each capability elements in the SIG Segment. (i) * * * technology includes that is specified in (iv) Limit a user’s ability to prescribe (A) * * * the following certification criteria: all oral liquid medications in only (1) The data classes expressed in the Paragraphs (a)(1) through (5), (9), and metric standard units of mL (i.e., not cc). standard in § 170.213 (which should be (14); and (b)(2), (3), and (11). (v) Always insert leading zeroes in their English (i.e., non-coded) * * * * * before the decimal point for amounts representation if they associate with a (6) Consolidated CDA creation less than one and must not allow vocabulary/code set), including as performance. The following technical trailing zeroes after a decimal point specified for the following data: and performance outcomes must be when a user prescribes medications. (i) Assessment and plan of treatment. demonstrated related to Consolidated (12) Data segmentation for privacy— In accordance with the ‘‘Assessment CDA creation. The capabilities required send. Enable a user to create a summary and Plan Section (V2)’’ of the standard under paragraphs (g)(6)(i) through (iv) of

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00169 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7592 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

this section can be demonstrated in (2) Goals. In accordance with the (vii) Documentation. (A) The API(s) tandem and do not need to be ‘‘Goals Section’’ of the standard must include complete accompanying individually addressed in isolation or specified in § 170.205(a)(4) and (a)(4)(i). documentation that contains, at a sequentially. This certification (3) Health concerns. In accordance minimum: criterion’s scope includes only the data with the ‘‘Health Concerns Section’’ of (1) API syntax, function names, classes expressed in the standard in the standard specified in § 170.205(a)(4) required and optional parameters § 170.213. and (a)(4)(i). supported and their data types, return (i) Reference C–CDA match. Create a (4) Unique device identifier(s) for a variables and their types/structures, data file formatted in accordance with patient’s implantable device(s). In exceptions and exception handling the standard adopted in § 170.205(a)(4) accordance with the ‘‘Product Instance’’ methods and their returns. and (a)(4)(i) that matches a gold- in the ‘‘Procedure Activity Procedure (2) The software components and standard, reference data file, including Section’’ of the standard specified in configurations that would be necessary as specified for the following data: § 170.205(a)(4) and (a)(4)(i). for an application to implement in order (10) Standardized API for patient and (A) Assessment and plan of treatment. to be able to successfully interact with population services. The following In accordance with the ‘‘Assessment the API and process its response(s). technical outcomes and conditions must (3) All applicable technical and Plan Section (V2)’’ of the standard be met through the demonstration of specified in § 170.205(a)(4) and (a)(4)(i); requirements and attributes necessary application programming interface for an application to be registered with or in accordance with the ‘‘Assessment technology. Section (V2)’’ and ‘‘Plan of Treatment an authorization server. (i) Data response. Respond to requests (B) The documentation used to meet Section (V2)’’ of the standard specified for data (based on an ID or other token) in § 170.205(a)(4) and (a)(4)(i). paragraph (g)(10)(vii)(A) of this section for each of the resources referenced by must be available via a publicly (B) Goals. In accordance with the the standard adopted in § 170.215(a)(1) accessible hyperlink. ‘‘Goals Section’’ of the standard and implementation specifications specified in § 170.205(a)(4) and (a)(4)(i). (11) Consent management for APIs. (i) adopted in § 170.215(a)(2) and (3). Respond to requests for data in (C) Health concerns. In accordance (ii) Search support. Respond to search accordance with: requests for data consistent with the with the ‘‘Health Concerns Section’’ of (A) The standard adopted in search criteria included in the the standard specified in § 170.205(a)(4) § 170.215(c)(1); and and (a)(4)(i). implementation specification adopted in § 170.215(a)(4). (B) The implementation specification (D) Unique device identifier(s) for a adopted in § 170.215(c)(2). patient’s implantable device(s). In (iii) App registration. Enable an application to register with the (ii) Documentation. (A) The API(s) accordance with the ‘‘Product Instance’’ must include complete accompanying in the ‘‘Procedure Activity Procedure technology’s ‘‘authorization server.’’ (iv) Secure connection. Establish a documentation that contains, at a Section’’ of the standard specified in minimum: § 170.205(a)(4) and (a)(4)(i). secure and trusted connection with an application that requests data in (1) API syntax, function names, * * * * * accordance with the standard adopted required and optional parameters (iv) Completeness verification. Create in § 170.215(a)(5). supported and their data types, return a data file for each of the applicable (v) Authentication and app variables and their types/structures, document templates referenced in authorization—1st time connection. The exceptions and exception handling paragraph (g)(6)(ii) of this section first time an application connects to methods and their returns. without the omission of any of the data request data the technology: (2) The software components and classes expressed in the standard in (A) Authentication. Demonstrates that configurations that would be necessary § 170.213. user authentication occurs during the for an application to implement in order * * * * * process of authorizing the application to to be able to successfully interact with (8) [Reserved] access FHIR resources in accordance the API and process its response(s). (3) All applicable technical (9) * * * with the standard adopted in § 170.215(b). requirements and attributes necessary (i) * * * (B) App authorization. Demonstrates for an application to be registered with (A) Respond to requests for patient that a user can authorize applications to an authorization server. data (based on an ID or other token) for access a single patient’s data as well as (B) The documentation used to meet all of the data classes expressed in the multiple patients data in accordance paragraph (g)(11)(ii)(A) of this section standard in § 170.213 at one time and with the implementation specification must be available via a publicly return such data (according to the adopted in § 170.215(a)(5) and issue a accessible hyperlink. specified standards, where applicable) refresh token that is valid for a period * * * * * in a summary record formatted of at least 3 months. ■ 17. Add subpart D to part 170 to read according to the standard specified in (vi) Authentication and app as follows: § 170.205(a)(4) and (a)(4)(i) following authorization—Subsequent connections. the CCD document template, including Demonstrates that an application can Subpart D—Conditions and Maintenance of Certification for Health IT Developers as specified for the following data: access a single patient’s data as well as (1) Assessment and plan of treatment. multiple patients data in accordance Sec. In accordance with the ‘‘Assessment with the implementation specification 170.400 Basis and scope. and Plan Section (V2)’’ of the standard adopted in § 170.215(a)(5) without 170.401 Information blocking. 170.402 Assurances. specified in § 170.205(a)(4) and (a)(4)(i); requiring re-authorization and re- 170.403 Communications. or in accordance with the ‘‘Assessment authentication when a valid refresh 170.404 Application programming Section (V2)’’ and ‘‘Plan of Treatment token is supplied and issue a new interfaces. Section (V2)’’ of the standard specified refresh token for new period no shorter 170.405 Real world testing. in § 170.205(a)(4) and (a)(4)(i). than 3 months. 170.406 Attestations.

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00170 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7593

Subpart D—Conditions and provide all of its customers of certified (ii) Permitted prohibitions and Maintenance of Certification for Health health IT with the health IT certified to restrictions. For communications about IT Developers the certification criterion in one or more of the subject matters § 170.315(b)(10) within 24 months of enumerated in paragraph (a)(1) of this § 170.400 Basis and scope. this final rule’s effective date or within section that is not entitled to This subpart implements section 12 months of certification for a health IT unqualified protection under paragraph 3001(c)(5)(D) of the Public Health developer that never previously (a)(2)(i) of this section, a health IT Service Act by setting forth certain certified health IT to the 2015 Edition, developer may prohibit or restrict Conditions and Maintenance of whichever is longer. communications only as expressly Certification requirements for health IT permitted by paragraphs (a)(2)(ii)(A) developers participating in the ONC § 170.403 Communications. through (F) of this section. Health IT Certification Program. (a) Condition of Certification. (1) A (A) Developer employees and health IT developer may not prohibit or § 170.401 Information blocking. contractors. A health IT developer may restrict the communication regarding— prohibit or restrict the communications (a) Condition of Certification. A health (i) The usability of its health IT; of the developer’s employees or IT developer must not take any action (ii) The interoperability of its health contractors. that constitutes information blocking as IT; (B) Non-user-facing aspects of health defined in 42 U.S.C. 300jj–52 and (iii) The security of its health IT; IT. A health IT developer may prohibit (iv) Relevant information regarding § 171.103. or restrict communications that disclose users’ experiences when using its health (b) Maintenance of Certification. information about non-user-facing IT; [Reserved] aspects of the developer’s health IT. (v) The business practices of (C) Intellectual property. A health IT § 170.402 Assurances. developers of health IT related to developer may prohibit or restrict (a) Condition of Certification. (1) A exchanging electronic health communications that would infringe the health IT developer must provide information; and assurances satisfactory to the Secretary (vi) The manner in which a user of the intellectual property rights existing in that the health IT developer will not health IT has used such technology. the developer’s health IT (including take any action that constitutes (2) A health IT developer must not third-party rights), provided that— information blocking as defined in 42 engage in any practice that prohibits or (1) A health IT developer does not U.S.C. 300jj–52 and § 171.103, unless restricts a communication regarding the prohibit or restrict, or purport to for legitimate purposes specified by the subject matters enumerated in prohibit or restrict, communications Secretary; or any other action that may paragraph (a)(1) of this section, unless that would be a fair use of a copyright inhibit the appropriate exchange, the practice is specifically permitted by work; and access, and use of electronic health this paragraph and complies with all (2) A health IT developer does not information. applicable requirements of this prohibit the communication of (2) A health IT developer must ensure paragraph. screenshots of the developer’s health IT, that its health IT certified under the (i) Unqualified protection for certain subject to the limited restrictions ONC Health IT Certification Program communications. A health IT developer described in paragraph (a)(2)(ii)(D) of conforms to the full scope of the must not prohibit or restrict any person this section. certification criteria. or entity from communicating any (D) Screenshots. A health IT (3) A health IT developer must not information or materials whatsoever developer may require persons who take any action that could interfere with (including proprietary information, communicate screenshots to— a user’s ability to access or use certified confidential information, and (1) Not alter screenshots, except to capabilities for any purpose within the intellectual property) when the annotate the screenshot, resize it, or to scope of the technology’s certification. communication is about one or more of redact the screenshot in accordance (4) A health IT developer that the subject matters enumerated in with § 170.403(a)(2)(ii)(D)(3) or to manages electronic health information paragraph (a)(1) of this section and is conceal protected health information; must certify health IT to the certification made for any of the following (2) Not infringe the intellectual criterion in § 170.315(b)(10). purposes— property rights of any third parties, (b) Maintenance of Certification. (1) A (A) Making a disclosure required by provided that— health IT developer must retain all law; (i) The developer has used all records and information necessary to (B) Communicating information about reasonable endeavors to secure a license demonstrate initial and ongoing adverse events, hazards, and other (including the right to sublicense) in compliance with the requirements of the unsafe conditions to government respect to the use of the third-party ONC Health IT Certification Program agencies, health care accreditation rights by communicators for purposes of for: organizations, and patient safety the communications protected by this (i) A period of 10 years beginning organizations; Condition of Certification; from the date each of a developer’s (C) Communicating information about (ii) The developer does not prohibit or health IT is first certified under the cybersecurity threats and incidents to restrict, or purport to prohibit or restrict, Program; or government agencies; communications that would be a fair (ii) If for a shorter period of time, a (D) Communicating information about use of a copyright work; period of 3 years from the effective date information blocking and other (iii) The developer has put all that removes all of the certification unlawful practices to government potential communicators on sufficient criteria to which the developer’s health agencies; or written notice of each aspect of its IT is certified from the Code of Federal (E) Communicating information about screen display that contains third-party Regulations. a health IT developer’s failure to comply content that cannot be communicated (2) A health IT developer that must with a Condition of Certification, or because the reproduction would comply with the requirements of with any other requirement of this part, infringe the third-party’s intellectual paragraph (a)(4) of this section must to ONC or an ONC–ACB. property rights; and

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00171 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7594 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

(iv) Communicators are permitted to § 170.404 Application programming (C) Application developer verification. communicate screenshots that have interfaces. An API Technology Supplier is been redacted to not disclose third-party The following Condition of permitted to institute a process to verify content; and Certification applies to developers of the authenticity of application (3) Redact protected health Health IT Modules certified to any of developers so long as such process is information, unless the individual has the certification criteria adopted in objective and the same for all provided all necessary consents or § 170.315(g)(7) through (11). application developers and completed (a) Condition of Certification. (1) authorizations or the communicator is within 5 business days of receipt of an General. An API Technology Supplier otherwise authorized, permitted, or application developer’s request to must publish APIs and must allow required by law to disclose the register their software application for health information from such protected health information. use with the API Technology Supplier’s technology to be accessed, exchanged, API technology. (E) Pre-market testing and and used without special effort through (3) Permitted fees conditions. (i) development. A health IT developer the use of APIs or successor technology General conditions. (A) All fees related may prohibit or restrict communications or standards, as provided for under to API technology not otherwise that disclose information or knowledge applicable law, including providing permitted by this section are prohibited solely acquired in the course of access to all data elements of a patient’s from being imposed by an API participating in pre-market product electronic health record to the extent Technology Supplier. development and testing activities permissible under applicable privacy (B) For all permitted fees, an API carried out for the benefit of the laws. Technology Supplier must: developer or for the joint benefit of the (2) Transparency conditions. (i) (1) Ensure that fees are based on developer and communicator. A General. The business and technical objective and verifiable criteria that are developer must not, once the subject documentation published by an API uniformly applied for all substantially health IT is released or marketed for Technology Supplier must be complete. similar or similarly situated classes of purposes other than product All documentation published pursuant persons and requests. development and testing, and subject to to paragraph (a)(2)(ii) of this section (2) Ensure that fees imposed on API the permitted prohibitions and must be published via a publicly Data Providers are reasonably related to restrictions described in paragraph accessible hyperlink that allows any the API Technology Supplier’s costs of (a)(2)(ii) of this section, prohibit or person to directly access the supplying and, if applicable, supporting restrict communications about matters information without any preconditions API technology to, or at the request of, enumerated in paragraph (a)(1) of this or additional steps. the API Data Provider to whom the fee section. (ii) Terms and conditions. (A) is charged. (3) Ensure that the costs of supplying (b) Maintenance of Certification. (1) Material information. The API and, if applicable, supporting the API Notice. Health IT developers must issue Technology Supplier must publish all technology upon which the fee is based a written notice to all customers and terms and conditions for its API are reasonably allocated among all those with which it has agreements technology, including any fees, customers to whom the API technology containing provisions that contravene restrictions, limitations, obligations, is supplied, or for whom the API paragraph (a) of this section: registration process requirements, or other similar requirements that would technology is supported. (i) Within six months of the effective be needed to: (4) Ensure that fees are not based in date of the final rule that any (1) Develop software applications to any part on whether the requestor or communication or contract provision interact with the API technology; other person is a competitor, potential that contravenes paragraph (a) of this (2) Distribute, deploy, and enable the competitor, or will be using the API section will not be enforced by the use of software applications in technology in a way that facilitates health IT developer. production environments that use the competition with the API Technology (ii) Within one year of the final rule, API technology; Supplier. and annually thereafter until paragraph (3) Use software applications, (ii) Permitted fee—Development, (b)(2)(ii) of this section is fulfilled, that including to access, exchange, and use deployment, and upgrades. An API any communication or contract electronic health information by means Technology Supplier is permitted to provision that contravenes paragraph (a) of the API technology; charge fees to an API Data Provider to of this section will not be enforced by (4) Use any electronic health recover the costs reasonably incurred by the health IT developer. information obtained by means of the the API Technology Supplier to develop, deploy, and upgrade API (2) Contracts and agreements. (i) A API technology; and (5) Register software applications. technology for the API Data Provider. health IT developer must not establish (B) API fees. Any and all fees charged (iii) Permitted fee—Supporting API or enforce any contract or agreement by an API Technology Supplier for the uses for purposes other than patient that contravenes paragraph (a) of this use of its API technology must be access. An API Technology Supplier is section. described in detailed, plain language. permitted to charge fees to an API Data (ii) If a health IT developer has a The description of the fees must include Provider to recover the incremental contract or agreement in existence at the all material information, including but costs reasonably incurred by the API time of the effective date of this final not limited to: Technology Supplier to support the use rule that contravenes paragraph (a) of (1) The persons or classes of persons of API technology deployed by or on this section, then the developer must in to whom the fee applies; behalf of the API Data Provider. This a reasonable period of time, but not later (2) The circumstances in which the permitted fee does not include: than two years from the effective date of fee applies; and (A) Any costs incurred by the API this rule, amend the contract or (3) The amount of the fee, which for Technology Supplier to support uses of agreement to remove or void the variable fees must include the specific the API technology that facilitate a contractual provision that contravenes variable(s) and methodology(ies) that patient’s ability to access, exchange, or paragraph (a) of this section. will be used to calculate the fee. use their electronic health information;

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00172 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7595

(B) Costs associated with intangible API technology in a production Supplier must provide notice and a assets (including depreciation or loss of environment, including: reasonable opportunity for its API Data value), except the actual development or (1) For the purposes of developing Provider customers and registered acquisition costs of such assets; or products or services that are designed to application developers to update their (C) Opportunity costs, except for the be interoperable with the API applications to preserve compatibility reasonable forward-looking cost of Technology Supplier’s health with API technology and to comply capital. information technology or with health with applicable terms and conditions. (iv) Permitted fee—Value-added information technology under the API (b) Maintenance of Certification. (1) services. An API Technology Supplier is Technology Supplier’s control; Registration for production use. An API permitted to charge fees to an API User (2) Any marketing, offering, and Technology Supplier with health IT for value-added services supplied in distribution of interoperable products certified to the certification criterion connection with software that can and services to potential customers and adopted in § 170.315(g)(10) must interact with the API technology, users that would be needed for the API register and enable all applications for provided that such services are not technology to be used in a production production use within 1 business day of necessary to efficiently and effectively environment; and completing its verification of an develop and deploy such software. (3) Enabling the use of the application developer’s authenticity, (v) Record-keeping requirements. An interoperable products or services in pursuant to paragraph (a)(2)(ii)(C) of this API Technology Supplier must keep for production environments, including section. inspection detailed records of any fees accessing and enabling the exchange (2) Service Base URL publication. API charged with respect to the API and use of electronic health Technology Supplier must support the technology, the methodology(ies) used information. publication of Service Base URLs for all to calculate such fees, and the specific (B) An API Technology Supplier must of its customers, regardless of those that costs to which such fees are attributed. not condition any of the rights described are centrally managed by the API (4) Openness and pro-competitive in paragraph (a)(4)(ii)(A) of this section Technology Supplier or locally conditions. General condition. An API on the requirement that the recipient of deployed by an API Data Provider, and Technology Supplier must grant an API the rights do, or agree to do, any of the make such information publicly Data Provider the sole authority and following: available (in a computable format) at no autonomy to permit API Users to (1) Pay a fee to license such rights, charge. interact with the API technology including but not limited to a license (3) Rollout of (g)(10)-Certified APIs. deployed by the API Data Provider. fee, royalty, or revenue-sharing An API Technology Supplier with API technology previously certified to the (i) Non-discrimination. (A) An API arrangement. (2) Not compete with the API certification criterion in § 170.315(g)(8) Technology Suppler must provide API Technology Supplier in any product, must provide all API Data Providers technology to API Data Providers on service, or market. with such API technology deployed terms that are no less favorable than it (3) Deal exclusively with the API with API technology certified to the provides to itself and its own customers, Technology Supplier in any product, certification criterion in § 170.315(g)(10) suppliers, partners, and other persons service, or market. within 24 months of this final rule’s with whom it has a business (4) Obtain additional licenses, effective date. relationship. products, or services that are not related (B) The terms on which an API to or can be unbundled from the API § 170.405 Real world testing. Technology Supplier provides API technology. (a) Condition of Certification. A health technology must be based on objective (5) License, grant, assign, or transfer IT developer with Health IT Modules to and verifiable criteria that are uniformly any intellectual property to the API be certified to any one or more 2015 applied for all substantially similar or Technology Supplier. Edition certification criteria in similarly situated classes of persons and (6) Meet additional developer or § 170.315(b), (c)(1) through (3), (e)(1), (f), requests. product certification requirements. (g)(7) through (11), and (h) must (C) An API Technology Supplier must (7) Provide the API Technology successfully test the real world use of not offer different terms or service on Supplier or its technology with those Health IT Module(s) for the basis of: reciprocal access to application data. interoperability (as defined in 42 U.S.C. (1) Whether the API User with whom (iii) Service and support obligations. 300jj(9) and § 170.102) in the type of an API Data Provider has a relationship An API Technology Supplier must setting in which such Health IT is a competitor, potential competitor, or provide all support and other services Module(s) would be/is marketed. will be using electronic health reasonably necessary to enable the (b) Maintenance of Certification. (1) information obtained via the API effective development, deployment, and Real world testing plan submission. A technology in a way that facilitates use of API technology by API Data health IT developer must submit an competition with the API Technology Providers and their API Users in annual real world testing plan to its Supplier. production environments. ONC–ACB via a publicly accessible (2) The revenue or other value the API (A) Changes and updates to API hyperlink no later than December 15 of User with whom an API Data Provider technology. An API Technology each calendar year for each of its has a relationship may derive from Supplier must make reasonable efforts certified 2015 Edition Health IT access, exchange, or use of electronic to maintain the compatibility of its API Modules that include certification health information obtained by means of technology and to otherwise avoid criteria referenced in paragraph (a) of API technology. disrupting the use of API technology in this section. (ii) Rights to access and use API production environments. (i) The plan must be approved by a technology. (A) An API Technology (B) Changes to terms and conditions. health IT developer authorized Supplier must have and, upon request, Except as exigent circumstances require, representative capable of binding the must grant to API Data Providers and prior to making changes or updates to health IT developer for execution of the their API Users all rights that may be its API technology or to the terms and plan and include the representative’s reasonably necessary to access and use conditions thereof, an API Technology contact information.

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00173 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7596 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

(ii) The plan must include all health certified to § 170.315(b)(1), (e)(1), (g)(6), (1) Having not taken any action that IT certified to the 2015 Edition through (f)(5), and/or (g)(9) prior to the effective constitutes information blocking as August 31st of the preceding year. date of this final rule must: defined in 42 U.S.C. 300jj–52 and (iii) The plan must address the (i) Update their certified health IT to § 171.103; following for each of the certification be compliant with the revised versions (2) Having provided assurances criteria identified in paragraph (a) of of these criteria adopted in this final satisfactory to the Secretary that they this section that are included in the rule; and will not take any action that constitutes Health IT Module’s scope of (ii) Provide its customers of the information blocking as defined in 42 certification: previously certified health IT with U.S.C. 300jj–52 and § 171.103, unless (A) The testing method(s)/ certified health IT that meets paragraph for legitimate purposes specified by the methodology(ies) that will be used to (b)(3)(i) of this section within 24 months Secretary; or any other action that may demonstrate real world interoperability of the effective date of this final rule. inhibit the appropriate exchange, and conformance to the certification (4) C–CDA Companion Guide access, and use of electronic health criteria’s requirements, including Updates. A health IT developer with information; scenario- and use case-focused testing; health IT certified to § 170.315(b)(1), (3) Not prohibiting or restricting the (B) The care setting(s) that will be (b)(2), (b)(9), (e)(1), (g)(6), and/or (g)(9) communications regarding— tested for real world interoperability prior to the effective date of this final (i) The usability of its health IT; and an explanation for the health IT rule must: (ii) The interoperability of its health developer’s choice of care setting(s) to (i) Update their certified health IT to IT; test; be compliant with the revised versions (iii) The security of its health IT; (C) The timeline and plans for any of these criteria adopted in this final (iv) Relevant information regarding voluntary updates to standards and rule; and users’ experiences when using its health implementation specifications that the (ii) Provide its customers of the IT; National Coordinator has approved previously certified health IT with (v) The business practices of through the Standards Version certified health IT that meets paragraph developers of health IT related to Advancement Process. (b)(4)(i) of this section within 24 months exchanging electronic health (D) A schedule of key real world of the effective date of this final rule. information; and testing milestones; (5) Voluntary standards and (vi) The manner in which a user of the (E) A description of the expected implementation specifications updates. health IT has used such technology; and outcomes of real world testing; A health IT developer subject to (4) Having published application (F) At least one measurement/metric paragraph (a) of this section that programming interfaces (APIs) and associated with the real world testing; voluntary updates its certified health IT allowing health information from such and technology to be accessed, exchanged, (G) A justification for the health IT to a new version of an adopted standard and used without special effort through developer’s real world testing approach. that is approved by the National (2) Real world testing results Coordinator through the Standards the use of application programming reporting. A health IT developer must Version Advancement Process must: interfaces or successor technology or submit real world testing results to its (i) Provide advance notice to all standards, as provided for under ONC–ACB via a publicly accessible affected customers and its ONC–ACB— applicable law, including providing hyperlink no later than January 31 each (A) Expressing its intent to update the access to all data elements of a patient’s calendar year for each of its certified software to the more advanced version electronic health record to the extent 2015 Edition Health IT Modules that of the standard approved by the permissible under applicable privacy include certification criteria referenced National Coordinator; laws; in paragraph (a) of this section. The real (B) The developer’s expectations for (5) Ensuring that its health IT allows world testing results must report the how the update will affect for health information to be exchanged, following for each of the certification interoperability of the affected Health IT accessed, and used, in the manner criteria identified in paragraph (a) of Module as it is used in the real world; described in paragraph (a)(4) of this this section that are included in the (C) Whether the developer intends to section; and Health IT Module’s scope of continue to support the certificate for (6) Having undertaken real world certification: the existing certified Health IT Module testing of its Health IT Module(s) for (i) The method(s) that was used to version for some period of time and how interoperability (as defined in 42 U.S.C. demonstrate real world interoperability; long or if the existing certified Health IT 300jj(9)) in the type of setting in which (ii) The care setting(s) that was tested Module version will be deprecated; and such Health IT Module(s) will be/is for real world interoperability; (ii) Successfully demonstrate marketed. (iii) The voluntary updates to conformance with approved more recent (b) Maintenance of Certification. (1) A standards and implementation versions of the standard(s) or health IT developer must attest to specifications that the National implementation specification(s) compliance with §§ 170.401 through Coordinator has approved through the included in applicable 2015 Edition 170.405 at the time of certification. Standards Version Advancement certification criterion specified in (2) A health IT developer must attest Process. paragraph (a) of this section. semiannually to compliance with (iv) A list of the key milestones met §§ 170.401 through 170.405 for all its during real world testing; § 170.406 Attestations. health IT that had an active certification (v) The outcomes of real world testing (a) Condition of Certification. A health at any time under the ONC Health IT including a description of any IT developer must provide the Secretary Certification Program during the prior challenges encountered during real with an attestation of compliance with six months. world testing; and the Conditions and Maintenance of (vi) At least one measurement/metric Certification requirements specified in § 170.501 [Amended] associated with the real world testing. §§ 170.401 through 170.405 at the time ■ 18. Amend § 170.501 as follows: (3) USCDI Updates for C–CDA. A of certification. Specifically, a health IT ■ a. In paragraph (a) remove the phrase health IT developer with health IT developer must attest to: ‘‘Complete EHRs’’;

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00174 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7597

■ b. In paragraph (b) remove the phrase (3) Documentation that confirms that (i) ONC–ATL; ‘‘Complete EHRs and’’; and the applicant has been accredited to (ii) ONC–ATL, NVLAP-accredited ■ c. Remove and reserve paragraph (c). ISO/IEC 17065, with an appropriate testing laboratory under the ONC Health scope, by any accreditation body that is IT Certification Program, and/or an § 170.502 [Amended] a signatory to the Multilateral ONC–ATCB for the purposes of ■ 19. Amend § 170.502 as follows: Recognition Arrangement (MLA) with performing gap certification; or ■ a. In the definition of ‘‘Deployment the International Accreditation Forum (2) Evaluated by it for compliance site’’, remove the phrase ‘‘Complete (IAF) (incorporated by reference in with a conformance method approved EHR,’’; § 170.599). by the National Coordinator. ■ b. In the definition of ‘‘Development * * * * * site’’, remove the phrase ‘‘Complete * * * * * ■ 25. Amend § 170.523 as follows: (k) Disclosures. *** EHR,’’; ■ (1) * * * ■ a. Revise paragraph (a); c. In the definition of ‘‘Gap ■ b. In paragraph (f) introductory text, (ii) For a Health IT Module certified certification’’, remove the phrase add a header and remove the phrase, to 2015 Edition health IT certification ‘‘Complete EHR or’’; ‘‘Complete EHRs,’’; criteria, the information specified by ■ d. Remove the definition of ‘‘ONC- ■ c. Removing and reserve paragraph paragraphs (f)(1)(i), (vi) through (viii), Approved Accreditor or ONC–AA’’; (f)(2); (xv), and (xvi) of this section as ■ e. In the definition of ‘‘ONC- ■ d. Revise paragraphs (g) and (h); applicable for the specific Health IT Authorized Certification Body or ONC– ■ e. In paragraph (k) introductory text, Module. ACB’’, remove the phrase ‘‘Complete remove the phrase ‘‘Complete EHRs (iii) In plain language, a detailed EHRs,’’; and and’’; description of all known material ■ f. In the definition of ‘‘ONC- ■ f. In paragraph (k)(1) introductory information concerning additional types Authorized Testing Lab or ONC–ATL’’, text, add a header and remove the of costs or fees that a user may be remove the phrase ‘‘Complete EHRs phrase ‘‘Complete EHR or’’; required to pay to implement or use the and’’. ■ g. Remove paragraphs (k)(1)(ii)(B), and Health IT Module’s capabilities, (k)(1)(iii)(B); whether to meet provisions of HHS § 170.503 [Removed and Reserved] ■ h. Revise paragraph (k)(1)(iii)(A); programs requiring the use of certified ■ 20. Remove and reserve § 170.503. ■ i. Remove paragraphs (k)(1)(iv)(B) and health IT or to achieve any other use § 170.504 [Removed and Reserved] (C); within the scope of the health IT’s ■ j. Remove and reserve paragraphs certification. The additional types of ■ 21. Remove and reserve § 170.504. (k)(2) and (3); costs or fees required to be disclosed ■ 22. Revise § 170.505 to read as ■ k. Revise paragraph (k)(4); include but are not limited to costs or follows: ■ l. Revise paragraphs (m)(1) and (2); fees (whether fixed, recurring, ■ m. Add paragraphs (m)(3) and (4)); § 170.505 Correspondence. transaction-based, or otherwise) ■ n. In paragraph (o), remove the phrase (a) Correspondence and imposed by a health IT developer (or ‘‘Complete EHR or’’; and any third party from whom the communication with ONC or the ■ o. Add paragraphs (p) through (t). National Coordinator shall be conducted The revisions and additions read as developer purchases, licenses, or by email, unless otherwise necessary or follows: obtains any technology, products, or specified. The official date of receipt of services in connection with its certified any email between ONC or the National § 170.523 Principles of proper conduct for health IT) to purchase, license, Coordinator and an applicant for ONC– ONC–ACBs. implement, maintain, upgrade, use, or ACB status, an applicant for ONC–ATL * * * * * otherwise enable and support the use of status, an ONC–ACB, an ONC–ATL, (a) Accreditation. Maintain its capabilities to which health IT is health IT developer, or a party to any accreditation in good standing to ISO/ certified; or in connection with any data proceeding under this subpart is the IEC 17065 (incorporated by reference in generated in the course of using any date on which the email was sent. § 170.599). capability to which health IT is (b) In circumstances where it is * * * * * certified. necessary for an applicant for ONC– (f) Reporting. *** * * * * * ACB status, an applicant for ONC–ATL (2) [Reserved] (2) [Reserved] status, an ONC–ACB, an ONC–ATL, (g) Records retention. (1) Retain all (3) [Reserved] health IT developer, or a party to any records related to the certification of (4) A certification issued to a Health proceeding under this subpart to Complete EHRs and Health IT Modules IT Module based solely on the correspond or communicate with ONC to an edition of certification criteria applicable certification criteria adopted or the National Coordinator by regular, beginning with the codification of an by the ONC Health IT Certification express, or certified mail, the official edition of certification criteria in the Program must be separate and distinct date of receipt for all parties will be the Code of Federal Regulations through a from any other certification(s) based on date of the delivery confirmation to the minimum of 3 years from the effective other criteria or requirements. address on record. date that removes the applicable edition * * * * * from the Code of Federal Regulations; (m) * * * § 170.510 [Amended] and (1) All adaptations of certified Health ■ 23. Amend § 170.510 by removing (2) Make the records available to HHS IT Modules; paragraph (a) and redesignating upon request during the retention (2) All updates made to certified paragraphs (b) and (c) as paragraphs (a) period described in paragraph (g)(1) of Health IT Modules affecting the and (b). this section; capabilities in certification criteria to ■ 24. Amend § 170.520 by revising (h) Testing. Only certify Health IT which the ‘‘safety-enhanced design’’ paragraph (a)(3) to read as follows: Modules that have been: criteria apply; (1) Tested, using test tools and test (3) All updates made to certified § 170.520 Application. procedures approved by the National Health IT Modules in compliance with (a) * * * Coordinator, by an: § 170.405(b)(3) and (4); and;

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00175 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7598 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

(4) All voluntary standards updates (2) Make the records available to HHS (ix) If applicable, any criterion successfully made to certified Health IT upon request during the retention adopted in § 170.315 is also certified to Modules per § 170.405(b)(5). period described in paragraph (f)(1) of the certification criteria specified in * * * * * this section; § 170.315(d)(12) and/or (13). (p) Real world testing. (1) Review and * * * * * * * * * * confirm that applicable health IT (l) Conditions of Certification developers submit real world testing § 170.545 [Removed and Reserved] Attestations. Before issuing a plans in accordance with ■ 27. Remove and reserve § 170.545. certification, ensure that the health IT § 170.405(b)(1). ■ 28. Amend § 170.550 as follows: developer of the Health IT Module has (2) Review and confirm that ■ a. Add paragraph (e); met its responsibilities under subpart D applicable health IT developers submit ■ b. Remove and reserve paragraph (f); of this part. real world testing results in accordance ■ c. Add paragraph (g)(5); with § 170.405(b)(2). ■ d. Revise paragraphs (h)(3)(i), (iii), (v), § 170.555 [Amended] (3) Submit real world testing plans by (vii); and ■ 29. Amend § 170.555 as follows: December 15 of each calendar year and ■ e. Add paragraphs (h)(3)(ix) and (l). ■ a. In paragraph (a), remove the results by April 1 of each calendar year The additions and revisions read as reference ‘‘Complete EHRs and/or’’; to ONC for public availability. follows: ■ b. Revise paragraph (b)(1); and (q) Attestations. Review and submit ■ c. In paragraph (b)(2), remove the health IT developer Conditions and § 170.550 Health IT Module certification. reference ‘‘certified Complete EHR or’’. Maintenance of Certification attestations * * * * * The revisions read as follows: made in accordance with § 170.406 to (e) ONC–ACBs must provide an ONC for public availability. option for certification of Health IT § 170.555 Certification to newer versions (r) Test results from ONC–ATLs. Modules to any one or more of the of certain standards. Accept test results from any ONC–ATL criteria referenced in § 170.405(a) based * * * * * that is: on newer versions of standards included (b) * * * (1) In good standing under the ONC in the criteria which have been (1) ONC–ACBs are not required to Health IT Certification Program, and approved by the National Coordinator certify Complete EHRs and/or Health IT (2) Compliant with its ISO 17025 for use in certification through the Module(s) according to newer versions accreditation requirements. Standards Version Advancement of standards adopted and named in (s) Information for direct review. Process. subpart B of this part, unless: Report to ONC, no later than a week (f) [Reserved] (i) The National Coordinator identifies after becoming aware of, any (g) * * * a new version through the Standards information that could inform whether (5) Section 170.315(b)(10) when the Version Advancement Process and a ONC should exercise direct review health IT developer of the health IT health IT developer voluntarily elects to under § 170.580(a). presented for certification produces and update its certified health IT to the new (t) Standards Voluntary Advancement electronically manages electronic health version in accordance with Process Module Updates Notices. information. § 170.405(b)(5); or Ensure health IT developers opting to (h) * * * (ii) The new version is incorporated take advantage of the Standards Version (3) * * * by reference in § 170.299. Advancement Process flexibility per (i) Section 170.315(a)(1) through (3), * * * * * § 170.405(b)(5) provide timely advance (5) through (8), (11), and (12) are also ■ 30. Amend § 170.556 as follows: written notice to the ONC–ACB and all certified to the certification criteria ■ a. Revise paragraph (a) introductory affected customers. specified in § 170.315(d)(1) through (7). text; (1) Maintain a record of the date of Section 170.315(a)(4), (9), (10), and (13) ■ b. In paragraph (b) introductory text, issuance and the content of developers’ are also certified to the certification remove the phrase ‘‘certified Complete § 170.405(b)(5) notices; and criteria specified in § 170.315(d)(1) EHR or’’; (2) Timely post content of each through (3), and (5) through (7). ■ c. Revise paragraph (c) introductory § 170.405(b)(5) notice received publicly text; on the CHPL attributed to the certified * * * * * ■ d. In paragraph (c)(1), remove the Health IT Module(s) to which it applies. (iii) Section 170.315(c) is also ■ 26. Amend § 170.524 as follows: certified to the certification criteria phrases ‘‘certified Complete EHR or’’ ■ a. Revise paragraph (f); and specified in § 170.315(d)(1), (2)(i)(A), and ‘‘Complete EHR or’’; ■ b. In paragraph (h)(3), remove the (B), (ii) through (v), (3), and (5); ■ e. Remove and reserve paragraph phrase ‘‘Complete EHRs and/or’’. The * * * * * (c)(2); ■ f. In paragraph (c)(3), remove the revisions and additions read as follows: (v) Section 170.315(e)(2) and (3) is phrase ‘‘certified Complete EHRs and’’; also certified to the certification criteria § 170.524 Principles of proper conduct for ■ g. In paragraphs (c)(4)(i) and (ii), specified in § 170.315(d)(1), (d)(2)(i)(A), ONC–ATLs. remove the phrase ‘‘certified Complete (B), (ii) through (v), (3), (5), and (9); * * * * * EHR or’’; (f) Records retention. (1) Retain all * * * * * ■ h. Remove paragraphs (c)(5) and (6); records related to the testing of (vii) Section 170.315(g)(7) through ■ i. In paragraph (d)(1), remove the Complete EHRs and/or Health IT (11) is also certified to the certification phrase ‘‘Complete EHR or’’; Modules to an edition of certification criteria specified in § 170.315(d)(1) and ■ j. In paragraph (d)(3)(ii), remove the criteria beginning with the codification (9); and (d)(2)(i)(A), (2)(i)(B), 2(ii) phrase ‘‘certified Complete EHR or’’; of an edition of certification criteria in through (v), or (10); ■ k. In paragraph (d)(5) introductory the Code of Federal Regulations through (viii) Section 170.315(h) is also text, remove the phrase ‘‘Complete EHR a minimum of 3 years from the effective certified to the certification criteria or’’; date that removes the applicable edition specified in § 170.315(d)(1), (2)(i)(A), ■ l. In paragraph (d)(6), remove the from the Code of Federal Regulations; (2)(i)(B), (2)(ii) through (v), and (3); and phrases ‘‘certified Complete EHR or’’ and * * * * * and ‘‘Complete EHR or’’;

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00176 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7599

■ m. In paragraph (e)(3), remove the surveillance ‘‘in the field’’ as necessary selected Health IT Modules to which it phrase ‘‘Complete EHR or’’; and to assess whether a certified Health IT has issued a certification. ■ n. In paragraph (f), remove the phrase Module continues to conform to the * * * * * ‘‘certified Complete EHR or’’. The requirements in subparts A, B, C and E (2) [Reserved] revisions and additions read as follows: of this part once the certified Health IT * * * * * Module has been implemented and is in § 170.556 In-the-field surveillance and use in a production environment. §§ 170.560, 170.565, and 170.570 maintenance of certification for Health IT. * * * * * [Amended] (a) In-the-field surveillance. (c) Randomized surveillance. During ■ 31. In the table below, for each section Consistent with its accreditation to ISO/ each calendar year surveillance period, and paragraph indicated in the first two IEC 17065 and the requirements of this an ONC–ACB may conduct in-the-field columns, remove the phrase indicated subpart, an ONC–ACB must initiate surveillance for certain randomly in the third column:

Section Paragraphs Remove

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

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

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00177 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7600 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

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

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00178 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7601

will be effective immediately after the Authority: 42 U.S.C. 300jj–52; 5 U.S.C. networks in a manner that allows the following applicable occurrence: 552. information to be accessed and used. (i) The expiration of the 10-day period Fee means any present or future for filing a statement of intent to appeal Subpart A—General Provisions obligation to pay money or provide any in § 170.580(g)(3)(i) if the health IT § 171.100 Statutory basis and purpose. other thing of value. Health care provider has the same developer does not file a statement of (a) Basis. This part implements meaning as ‘‘health care provider’’ at 42 intent to appeal. section 3022 of the Public Health (ii) The expiration of the 30-day U.S.C. 300jj. Service Act, 42 U.S.C. 300jj–52. Health Information Exchange or HIE period for filing an appeal in (b) Purpose. The purpose of this part means an individual or entity that § 170.580(g)(3)(ii) if the health IT is to establish exceptions for reasonable enables access, exchange, or use of developer files a statement of intent to and necessary activities that do not electronic health information primarily appeal, but does not file a timely appeal. constitute ‘‘information blocking,’’ as (iii) A final determination to issue a between or among a particular class of defined by section 3022(a)(1) of the certification ban per § 170.580(g)(7) if a individuals or entities or for a limited Public Health Service Act, 42 U.S.C. health IT developer files an appeal set of purposes. 300jj–52. timely. Health Information Network or HIN (d) Reinstatement. The certification of § 171.101 Applicability. means an individual or entity that a health IT developer’s health IT subject This part applies to health care satisfies one or both of the following— to the prohibition in paragraph (a) of providers, health IT developers of (1) Determines, oversees, administers, this section may commence once the certified health IT, health information controls, or substantially influences following conditions are met. exchanges, and health information policies or agreements that define (1) A health IT developer must networks, as those terms are defined in business, operational, technical, or other request ONC’s permission in writing to § 171.102. conditions or requirements for enabling participate in the ONC Health IT or facilitating access, exchange, or use of Certification Program. § 171.102 Definitions. electronic health information between (2) The request must demonstrate that For purposes of this part: or among two or more unaffiliated the customers affected by the certificate Access means the ability or means individuals or entities. termination, certificate withdrawal, or necessary to make electronic health (2) Provides, manages, controls, or non-compliance with a Condition or information available for use, including substantially influences any technology Maintenance of Certification have been the ability to securely and efficiently or service that enables or facilitates the provided appropriate remediation. locate and retrieve information from any access, exchange, or use of electronic (3) For non-compliance with a and all source systems in which the health information between or among Condition or Maintenance of information may be recorded or two or more unaffiliated individuals or Certification requirement, the non- maintained. entities. compliance must be resolved. Actor means a health care provider, Health IT developer of certified health (4) ONC is satisfied with the health IT health IT developer of certified health IT means an individual or entity that developer’s demonstration under IT, health information exchange, or develops or offers health information paragraph (d)(2) of this section that all health information network. technology (as that term is defined in 42 affected customers have been provided API Data Provider is defined as it is U.S.C. 300jj(5)) and which had, at the with appropriate remediation and grants in § 170.102. time it engaged in a practice that is the reinstatement into the ONC Health IT API Technology Supplier is defined as subject of an information blocking Certification Program. it is in § 170.102. claim, health information technology ■ 35. Add part 171 to read as follows: Electronic Health Information (EHI) (one or more) certified under the ONC means— Health IT Certification Program. PART 171—INFORMATION BLOCKING (1) Electronic protected health Information blocking is defined as it Subpart A—General Provisions information; and is in § 171.103 and 42 U.S.C. 300jj– (2) Any other information that Sec. 52(a). 171.100 Basis and purpose. identifies the individual, or with respect Interfere with means to prevent, 171.101 Applicability. to which there is a reasonable basis to materially discourage, or otherwise 171.102 Definitions. believe the information can be used to inhibit access, exchange, or use of 171.103 Information blocking. identify the individual and is electronic health information. Interoperability element means— Subpart B—Exceptions for Reasonable and transmitted by or maintained in Necessary Activities That Do Not Constitute electronic media, as defined in 45 CFR (1) Any functional element of a health Information Blocking 160.103, that relates to the past, present, information technology, whether or future health or condition of an hardware or software, that could be 171.200 Availability and effect of used to access, exchange, or use exceptions. individual; the provision of health care 171.201 Exception—Preventing harm. to an individual; or the past, present, or electronic health information for any 171.202 Exception—Promoting the privacy future payment for the provision of purpose, including information of electronic health information. health care to an individual. transmitted by or maintained in 171.203 Exception—Promoting the security Electronic media is defined as it is in disparate media, information systems, of electronic health information. 45 CFR 160.103. health information exchanges, or health 171.204 Exception—Recovering costs Electronic protected health information networks. reasonably incurred. information (ePHI) is defined as it is in (2) Any technical information that 171.205 Exception—Responding to requests 45 CFR 160.103. describes the functional elements of that are infeasible. 171.206 Exception—Licensing of Exchange means the ability for technology (such as a standard, interoperability elements on reasonable electronic health information to be specification, protocol, data model, or and non-discriminatory terms. transmitted securely and efficiently schema) and that a person of ordinary § 171.207 Exception—Maintaining and between and among different skill in the art may require to use the improving health IT performance. technologies, systems, platforms, or functional elements of the technology,

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00179 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7602 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

including for the purpose of developing Subpart B—Exceptions for Reasonable (a) Meaning of ‘‘individual’’ in this compatible technologies that and Necessary Activities That Do Not section. The term ‘‘individual’’ as used incorporate or use the functional Constitute Information Blocking in this section means one or more of the elements. following— § 171.200 Availability and effect of (1) An individual as defined by 45 (3) Any technology or service that exceptions. may be required to enable the use of a CFR 160.103. A practice shall not be treated as (2) Any other natural person who is compatible technology in production information blocking if the actor the subject of the electronic health environments, including but not limited satisfies an exception to the information information being accessed, exchanged, to any system resource, technical blocking provision by meeting all or used. infrastructure, or health information applicable requirements and conditions (3) A person who legally acts on exchange or health information network of the exception at all relevant times. behalf of a person described in element. paragraph (a)(1) or (2) of this section, (4) Any license, right, or privilege that § 171.201 Exception—Preventing harm. including as a personal representative, may be required to commercially offer To qualify for this exception, each in accordance with 45 CFR 164.502(g). and distribute compatible technologies practice by an actor must meet the (4) A person who is a legal and make them available for use in following conditions at all relevant representative of and can make health production environments. times. care decisions on behalf of any person (a) The actor must have a reasonable (5) Any other means by which described in paragraph (a)(1) or (2) of belief that the practice will directly and electronic health information may be this section. substantially reduce the likelihood of accessed, exchanged, or used. (5) An executor, administrator or harm to a patient or another person other person having authority to act on Permissible purpose means a purpose arising from— behalf of a deceased person described in for which a person is authorized, (1) Corrupt or inaccurate data being paragraph (a)(1) or (2) of this section or permitted, or required to access, recorded or incorporated in a patient’s the individual’s estate under State or exchange, or use electronic health electronic health record; other law. information under applicable law. (2) Misidentification of a patient or (b) Precondition not satisfied. If the Person is defined as it is in 45 CFR patient’s electronic health information; actor is required by a state or federal 160.103. or privacy law to satisfy a condition prior (3) Disclosure of a patient’s electronic to providing access, exchange, or use of Protected health information is health information in circumstances defined as it is in 45 CFR 160.103. electronic health information, the actor where a licensed health care may choose not to provide access, Practice means one or more related professional has determined, in the exchange, or use of such electronic acts or omissions by an actor. exercise of professional judgment, that health information if the precondition Use means the ability of health IT or the disclosure is reasonably likely to has not been satisfied, provided that— a user of health IT to access relevant endanger the life or physical safety of (1) The actor’s practice— electronic health information; to the patient or another person, provided (i) Conforms to the actor’s comprehend the structure, content, and that, if required by applicable federal or organizational policies and procedures meaning of the information; and to read, state law, the patient has been afforded that: write, modify, manipulate, or apply the any right of review of that (A) Are in writing; information to accomplish a desired determination. (B) Specify the criteria to be used by outcome or to achieve a desired (b) If the practice implements an the actor and, as applicable, the steps purpose. organizational policy, the policy must that the actor will take, in order that the be— precondition can be satisfied; and § 171.103 Information blocking. (1) In writing; (C) Have been implemented, (2) Based on relevant clinical, including by taking reasonable steps to Information blocking means a practice technical, and other appropriate ensure that its workforce members and that— expertise; its agents understand and consistently (a) Except as required by law or (3) Implemented in a consistent and apply the policies and procedures; or covered by an exception set forth in non-discriminatory manner; and (ii) Has been documented by the subpart B of this part, is likely to (4) No broader than necessary to actor, on a case-by-case basis, interfere with, prevent, or materially mitigate the risk of harm. identifying the criteria used by the actor discourage access, exchange, or use of (c) If the practice does not implement to determine when the precondition electronic health information; and an organizational policy, an actor must would be satisfied, any criteria that (b) If conducted by a health make a finding in each case, based on were not met, and the reason why the information technology developer, the particularized facts and criteria were not met; and health information exchange, or health circumstances, and based on, as (2) If the precondition relies on the information network, such developer, applicable, relevant clinical, technical, provision of consent or authorization exchange, or network knows, or should and other appropriate expertise, that the from an individual, the actor: (i) Did all things reasonably necessary know, that such practice is likely to practice is necessary and no broader within its control to provide the interfere with, prevent, or materially than necessary to mitigate the risk of individual with a meaningful discourage the access, exchange, or use harm. opportunity to provide the consent or of electronic health information; or § 171.202 Exception—Promoting the authorization; and (c) If conducted by a health care privacy of electronic health information. (ii) Did not improperly encourage or provider, such provider knows that such To qualify for this exception, each induce the individual to not provide the practice is unreasonable and is likely to practice by an actor must satisfy at least consent or authorization. interfere with, prevent, or materially one of the sub-exceptions in paragraphs (3) The actor’s practice is— discourage access, exchange, or use of (b) through (e) of this section at all (i) Tailored to the specific privacy risk electronic health information. relevant times. or interest being addressed; and

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00180 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7603

(ii) Implemented in a consistent and (c) The practice must be implemented requestor or other persons derive or may non-discriminatory manner. in a consistent and non-discriminatory derive from the access to, exchange of, (c) Health IT developer of certified manner. or use of electronic health information, health IT not covered by HIPAA. If the (d) If the practice implements an including the secondary use of such actor is a health IT developer of certified organizational security policy, the information, that exceeds the actor’s health IT that is not required to comply policy must— reasonable costs for providing access, with the HIPAA Privacy Rule when (1) Be in writing; exchange, or use of electronic health engaging in a practice that promotes the (2) Have been prepared on the basis information. privacy interests of an individual, the of, and directly respond to, security (c) Costs specifically excluded. This actor may choose not to provide access, risks identified and assessed by or on exception does not apply to— exchange, or use of electronic health behalf of the actor; (1) Costs that the actor incurred due information provided that the actor’s (3) Align with one or more applicable to the health IT being designed or practice— consensus-based standards or best implemented in non-standard ways that (1) Complies with applicable state or practice guidance; and unnecessarily increase the complexity, federal privacy laws; (4) Provide objective timeframes and difficulty or burden of accessing, (2) Implements a process that is other parameters for identifying, exchanging, or using electronic health described in the actor’s organizational responding to, and addressing security information; privacy policy; incidents. (2) Costs associated with intangible (3) Had previously been meaningfully (e) If the practice does not implement assets (including depreciation or loss of disclosed to the persons and entities an organizational security policy, the value), other than the actual that use the actor’s product or service; actor must have made a determination development or acquisition costs of (4) Is tailored to the specific privacy in each case, based on the particularized such assets; risk or interest being addressed; and facts and circumstances, that: (3) Opportunity costs, except for the (5) Is implemented in a consistent and (1) The practice is necessary to reasonable forward-looking cost of non-discriminatory manner. mitigate the security risk to the (d) Denial of an individual’s request capital; electronic health information; and (4) A fee prohibited by 45 CFR for their electronic protected health (2) There are no reasonable and 164.524(c)(4); information in the circumstances appropriate alternatives to the practice (5) A fee based in any part on the provided in 45 CFR 164.524(a)(1), (2), that address the security risk that are electronic access by an individual or and (3). If an individual requests their less likely to interfere with, prevent, or their personal representative, agent, or electronic protected health information materially discourage access, exchange designee to the individual’s electronic under 45 CFR 164.502(a)(1)(i) or 45 CFR or use of electronic health information. health information; 164.524, the actor may deny the request (6) A fee to perform an export of in the circumstances provided in 45 § 171.204 Exception—Recovering costs electronic health information via the CFR 164.524(a)(1), (2), or (3). reasonably incurred. (e) Respecting an individual’s request capability of health IT certified to To qualify for this exception, each § 170.315(b)(10) of this subchapter for not to share information. In practice by an actor must meet the circumstances where not required or the purposes of switching health IT or following conditions at all relevant to provide patients their electronic prohibited by law, an actor may choose times. not to provide access, exchange, or use health information; or (a) Types of costs to which this (7) A fee to export or convert data of an individual’s electronic health exception applies. This exception is information if— from an EHR technology, unless such limited to the actor’s costs reasonably fee was agreed to in writing at the time (1) The individual requests that the incurred to provide access, exchange, or actor not provide such access, exchange, the technology was acquired. use of electronic health information. (d) Compliance with the Conditions of or use; (b) Method for recovering costs. The (2) Such request is initiated by the Certification. (1) Notwithstanding any method by which the actor recovers its other provision of this exception, if the individual without any improper costs— encouragement or inducement by the actor is a health IT developer subject to (1) Must be based on objective and the Conditions of Certification in actor; verifiable criteria that are uniformly (3) The actor or its agent documents § 170.402(a)(4) or § 170.404 of this applied for all substantially similar or the request within a reasonable time subchapter, the actor must comply with similarly situated classes of persons and period; and all requirements of such conditions for (4) The actor’s practice is requests; all practices and at all relevant times. (2) Must be reasonably related to the implemented in a consistent and non- (2) If the actor is an API Data actor’s costs of providing the type of discriminatory manner. Provider, the actor is only permitted to access, exchange, or use to, or at the charge the same fees that an API § 171.203 Exception—Promoting the request of, the person or entity to whom Technology Supplier is permitted to security of electronic health information. the fee is charged; charge to recover costs consistent with To qualify for this exception, each (3) Must be reasonably allocated the permitted fees specified in the practice by an actor must meet the among all customers to whom the Condition of Certification in § 170.404 following conditions at all relevant technology or service is supplied, or for of this subchapter. times. whom the technology is supported; (a) The practice must be directly (4) Must not be based in any part on § 171.205 Exception—Responding to related to safeguarding the whether the requestor or other person is requests that are infeasible. confidentiality, integrity, and a competitor, potential competitor, or To qualify for this exception, each availability of electronic health will be using the electronic health practice by an actor must meet the information. information in a way that facilitates following conditions at all relevant (b) The practice must be tailored to competition with the actor; and times. the specific security risk being (5) Must not be based on the sales, (a) Request is infeasible. (1) The actor addressed. profit, revenue, or other value that the must demonstrate, in accordance with

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00181 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7604 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

paragraph (a)(2) of this section, that reasons why the actor cannot technology to the licensee’s products, complying with the request in the accommodate the request. not on any strategic value stemming manner requested would impose a (d) Provision of a reasonable from the actor’s control over essential substantial burden on the actor that is alternative. The actor must work with means of accessing, exchanging, or unreasonable under the circumstances, the requestor in a timely manner to using electronic health information. taking into consideration— identify and provide a reasonable (iii) If the actor has licensed the (i) The type of electronic health alternative means of accessing, interoperability element through a information and the purposes for which exchanging, or using the electronic standards development organization in it may be needed; health information. accordance with such organization’s (ii) The cost to the actor of complying policies regarding the licensing of with the request in the manner § 171.206 Exception—Licensing of standards-essential technologies on requested; interoperability elements on reasonable and non-discriminatory terms. reasonable and non-discriminatory (iii) The financial, technical, and terms, the actor may charge a royalty other resources available to the actor; To qualify for this exception, each that is consistent with such policies. (iv) Whether the actor provides practice by an actor must meet the (3) Non-discriminatory terms. The comparable access, exchange, or use to following conditions at all relevant terms (including royalty terms) on itself or to its customers, suppliers, times. which the actor licenses and otherwise partners, and other persons with whom (a) Responding to requests. Upon provides the interoperability elements it has a business relationship; receiving a request to license or use must be non-discriminatory and comply (v) Whether the actor owns or has interoperability elements, the actor must with the following requirements. control over a predominant technology, respond to the requestor within 10 (i) The terms must be based on platform, health information exchange, business days from receipt of the objective and verifiable criteria that are or health information network through request by: uniformly applied for all substantially which electronic health information is (1) Negotiating with the requestor in similar or similarly situated classes of accessed or exchanged; a reasonable and non-discriminatory persons and requests. (vi) Whether the actor maintains fashion to identify the interoperability (ii) The terms must not be based in electronic protected health information elements that are needed; and any part on— on behalf of a covered entity, as defined (2) Offering an appropriate license (A) Whether the requestor or other in 45 CFR 160.103, or maintains with reasonable and non-discriminatory person is a competitor, potential electronic health information on behalf terms. competitor, or will be using electronic of the requestor or another person (b) Reasonable and non- health information obtained via the whose access, exchange, or use of discriminatory terms. The actor must interoperability elements in a way that electronic health information will be license the interoperability elements facilitates competition with the actor; or enabled or facilitated by the actor’s described in paragraph (a) of this (B) The revenue or other value the compliance with the request; section on terms that are reasonable and requestor may derive from access, (vii) Whether the requestor and other non-discriminatory. exchange, or use of electronic health relevant persons can reasonably access, (1) Scope of rights. The license must information obtained via the exchange, or use the electronic health provide all rights necessary to access interoperability elements, including the information from other sources or and use the interoperability elements for secondary use of such electronic health through other means; and the following purposes, as applicable. information. (viii) The additional cost and burden (i) Developing products or services (4) Collateral terms. The actor must to the requestor and other relevant that are interoperable with the actor’s not require the licensee or its agents or persons of relying on alternative means health IT, health IT under the actor’s contractors to do, or to agree to do, any of access, exchange, or use. control, or any third party who of the following. (2) The following circumstances do currently uses the actor’s (i) Not compete with the actor in any not constitute a burden to the actor for interoperability elements to interoperate product, service, or market. purposes of this exception and shall not with the actor’s health IT or health IT (ii) Deal exclusively with the actor in be considered in determining whether under the actor’s control. any product, service, or market. the actor has demonstrated that (ii) Marketing, offering, and (iii) Obtain additional licenses, complying with a request would have distributing the interoperable products products, or services that are not related been infeasible. and/or services to potential customers to or can be unbundled from the (i) Providing the requested access, and users. requested interoperability elements. exchange, or use in the manner (iii) Enabling the use of the (iv) License, grant, assign, or transfer requested would have facilitated interoperable products or services in to the actor any intellectual property of competition with the actor. production environments, including the licensee. (ii) Providing the requested access, accessing and enabling the exchange (v) Pay a fee of any kind whatsoever, exchange, or use in the manner and use of electronic health except as described in paragraph (b)(2) requested would have prevented the information. of this section, unless the practice meets actor from charging a fee. (2) Reasonable royalty. If the actor the requirements of the exception in (b) Responding to requests. The actor charges a royalty for the use of the § 171.204. must timely respond to all requests interoperability elements described in (5) Non-disclosure agreement. The relating to access, exchange, or use of paragraph (a) of this section, the royalty actor may require a reasonable non- electronic health information, including must be reasonable and comply with the disclosure agreement that is no broader but not limited to requests to establish following requirements. than necessary to prevent unauthorized connections and to provide (i) The royalty must be non- disclosure of the actor’s trade secrets, interoperability elements. discriminatory, consistent with provided— (c) Written explanation. The actor paragraph (b)(3) of this section. (i) The agreement states with must provide the requestor with a (ii) The royalty must be based solely particularity all information the actor detailed written explanation of the on the independent value of the actor’s claims as trade secrets; and

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00182 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7605

(ii) Such information meets the of § 171.201 at all relevant times to Recommendation 1: Use Biometric-Specific definition of a trade secret under qualify for an exception. Norms for Growth Curves and Support Growth Charts for Children applicable law. (c) Security-related practices. If the (c) Additional requirements relating unavailability of health IT for Alignment With Children’s EHR Format to the provision of interoperability maintenance or improvements is Stakeholders identified alignment with the elements. The actor must not engage in initiated by an actor in response to a Children’s EHR Format Requirement as any practice that has any of the security risk to electronic health follows: following purposes or effects. information, the actor does not need to Title: Use biometric-specific norms for growth curves. (1) Impeding the efficient use of the satisfy the requirements of this section, interoperability elements to access, Children’s EHR Format: Req-2044—Release but must comply with all requirements Package 2015 Priority List. exchange, or use electronic health of § 171.203 at all relevant times to Topic(s): Primary Care Management, Well information for any permissible qualify for an exception. Child/Preventive Care. purpose. Description: The system shall include the (2) Impeding the efficient Dated: January 22, 2019. ability to use pediatric age-specific norms for development, distribution, deployment, Alex M. Azar II, weight, height/length, head circumference, or use of an interoperable product or Secretary, Department of Health and Human and BMI to calculate and display growth service for which there is actual or Services. percentiles and plot them over time on standardized Centers for Disease Control and potential demand. Note: The following appendix will not Prevention/World Health Organizations (3) Degrading the performance or appear in the Code of Federal Regulations. (CDC/WHO) growth curves as appropriate. interoperability of the licensee’s products or services, unless necessary to Alignment With 2015 Edition Certification Appendix: Pediatric Technical Criteria improve the actor’s technology and after Worksheets affording the licensee a reasonable ONC believes this recommendation is opportunity to update its technology to These worksheets contain information on supported by the 2015 Edition definition and how each recommendation corresponds to criteria listed below: maintain interoperability. Common Clinical Data Set* (CCDS) (d) Compliance with conditions of the Children’s EHR Format and to the existing or proposed new ONC certification including optional pediatric vital sign data certification. Notwithstanding any other elements with the reference range/scale or criteria. We invite readers to use these provision of this exception, if the actor growth curve for BMI percentile per age and worksheets to inform public comment on the is a health IT developer subject to the sex for youth 2–20 years of age, weight for recommendations, the inclusion of specific conditions of certification in §§ 170.402, age per length and sex for children less than items from the Children’s EHR Format,193 170.403, or 170.404 of this subchapter, three years of age, and head occipital-frontal and the identified certification criteria as circumference for children less than three the actor must comply with all they relate specifically to use cases for years of age. requirements of such conditions for all pediatric care and sites of service. Demographic criterion requires the ability practices and at all relevant times. We welcome public comment on the to record birth sex in accordance with HL7 Version 3 (‘‘Administrative Gender’’) and a § 171.207 Exception—Maintaining and identified certification criteria for each null flavor value attributed as follows: Male improving health IT performance. recommendation. Specifically, we seek comment for each recommendation on the (M); female (F); and unknown (UNK). To qualify for this exception, each Clinical Decision Support (CDS) can be following four broad questions: practice by an actor must meet the • used to develop a variety of tools to enhance Q1. What relevant gaps, barriers, safety decision-making in the pediatric clinical following conditions at all relevant concerns, and/or resources (including times. workflow including contextually relevant available best practices, activities, and tools) reference information, clinical guidelines, (a) Maintenance and improvements to may impact or support feasibility of the condition-specific order sets, alerts, and health IT. An actor may make health IT recommendation in practice? reminders, among other tools. under its control temporarily • Q2. How can the effective use of IT Application Programming Interfaces unavailable in order to perform support each recommendation as involves criteria including the ‘‘application access— maintenance or improvements to the provider training, establishing workflow, and patient selection’’, ‘‘application access—data health IT, provided that the actor’s other related safety and usability category request’’, and ‘‘application access— practice is— considerations? all data request’’ which can help address many of the challenges currently faced by (1) For a period of time no longer than • Q3. Should any of the recommendations caregivers accessing pediatric health data. necessary to achieve the maintenance or not be included? improvements for which the health IT • Q4. Should any of the functional criteria Alignment With Proposed New or Updated was made unavailable; listed under the ‘‘Alignment with 2015 Certification Criteria (2) Implemented in a consistent and Edition Certification Criteria’’ and the ONC believes this recommendation is non-discriminatory manner; and ‘‘Alignment with Proposed New or Updated supported by the proposed new and updated (3) If the unavailability is initiated by Certification Criteria’’ be removed as a certification criteria in this proposed rule: a health IT developer of certified health correlated item to support any of the United States Core Data for Interoperability recommendations? (USCDI): The USCDI (§ 170.213) which IT, HIE, or HIN, agreed to by the enables the inclusion of pediatric vital sign individual or entity to whom the health Commenters are encouraged to reference the specific recommendation number (110) data elements, including the reference range/ IT developer of certified health IT, HIE, scale or growth curve for BMI percentile per with the corresponding question number in or HIN supplied the health IT. age and sex, weight for age per length and their response. For example, (b) Practices that prevent harm. If the sex, and head occipital-frontal ‘‘Recommendation 1. Q3.’’ Commenters are circumference. unavailability of health IT for highly encouraged to use the template ONC maintenance or improvements is Application Programming Interfaces has created to support public comment on (APIs): § 170.315(g)(10), would require the initiated by an actor in response to a the proposed rule. use of Health Level 7 (HL7®) Fast Healthcare risk of harm to a patient or another Interoperability Resources (FHIR®) standards person, the actor does not need to 193 https://healthit.ahrq.gov/health-it-tools-and- and several implementation specifications to satisfy the requirements of this section, resources/pediatric-resources/childrens-electronic- establish standardized application but must comply with all requirements health-record-ehr-format. programming interfaces (APIs) for

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00183 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7606 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

interoperability purposes and to permit 3rd Recommendation 2: Compute Weight-Based New or Updated Criterion Alignment: party software developers to connect to the Drug Dosage Electronic prescribing. electronic health record (EHR) through the 2. Title: Alert based on age-specific norms. Alignment With Children’s EHR Format certified API technology. Children’s EHR Format: Req-2013—Release Stakeholders identified alignment with the Package 2015 Priority List. Supplemental Children’s Format Children’s EHR Format Requirement as Topic(s): Primary Care Management, Well Requirements for Recommendation 1 follows: Child/Preventive Care. We seek feedback about the relevance of Title: Compute weight-based drug dosage. Description: The system shall provide the the following potential supplemental Children’s EHR Format: Req-2012—Release ability to present alerts for lab results outside Children’s EHR Format requirements and Package 2015 Priority List. of pediatric-specific normal value ranges. their correlation to Recommendation 1. Topic(s): Medication Management. 2015 Edition Criterion Alignment: Clinical 1. Title: Allow unknown patient sex. Description: The system shall compute decision support (CDS). Children’s EHR Format: Req-2009—Release drug dose, based on appropriate dosage New or Updated Criterion Alignment: API. ranges, using the patient’s body weight and Package 2015 Priority List. body surface area, and shall display the Recommendation 3: Ability To Document All Topic(s): Prenatal Screening, Birth dosing weight and weight-based dosing Guardians and Caregivers Information, Genetic information. strategy (when applicable) on the Alignment With Children’s EHR Format Description: The system shall provide the prescription. ability to record a patient’s sex as male, Stakeholders identified alignment with the female, or unknown, and shall allow it to be Alignment With 2015 Edition Certification Children’s EHR Format Requirement as updated. Criterion follows: 2015 Edition Criterion Alignment: ONC believes this recommendation is Title: Ability to access family history, Demographics. supported by the 2015 Edition criterion listed including all guardians and caregivers. New or Updated Criterion Alignment: below: Children’s EHR Format: Req-2006—Release USCDI. • Electronic Prescribing criterion: Package 2015 Priority List. 2. Title: Record Gestational Age Topic(s): Child Abuse Reporting, Primary —Provides the ability to send and receive the Care Management, Parents and Guardians, Assessment and Persist in the EHR. specified prescription transactions and Family Relationship Data. Children’s EHR Format: Requirement Req- electronically per the NCPDP SCRIPT Description: The system shall provide the 2019—Release Package 2015 Priority List. Version 10.6 Standard Implementation ability to record information about all Topic(s): Well Child/Preventive Care, Recommendations and using RxNorm guardians and caregivers (biological parents, Growth Data. vocabulary codes foster parents, adoptive parents, guardians, Description: The system shall capture and —Limits the ability to prescribe all oral, surrogates, and custodians), siblings, and display assigned gestational age as well as liquid medications in only metric standard case workers, with contact information for the diagnosis of SGA (Small for Gestational units of mL (i.e., not cc) each. Age) or LGA (Large for Gestational Age) Includes an optional Structured and when appropriate. Codified Sig Format, which has the Alignment With 2015 Edition Certification 2015 Edition Criterion Alignment: capability to exchange weight-based dosing Criteria Common Clinical Data Set (CCDS). calculations within the NCPDP SCRIPT 10.6 ONC believes this recommendation is New or Updated Criterion Alignment: standard. supported by the 2015 Edition criteria listed USCDI. below, and ONC believes this priority also is Alignment With Proposed New or Updated 3. Title: Support growth charts for supported by health IT beyond what is Certification Criteria children. included in the certification program. Children’s EHR Format: Requirement Req- ONC believes this recommendation is • Care Plan: Criteria includes the ability to 2042—Release Package: 2015 Priority List. supported by the proposed new and updated record, change, access, create, and receive Topic(s): Growth Data. certification criteria in this proposed rule: care plan information according to the care • United States Core Data for plan document template in the HL7 Description: The system shall support ® display of growth charts that plot selected Interoperability (USCDI): The USCDI implementation guide for CDA Release 2: growth parameters such as height, weight, (§ 170.213) which enables the inclusion of Consolidated CDA Templates for Clinical head circumference, and BMI (entered with pediatric vital sign data elements, including Notes (US Realm), draft standard for Trial appropriate precision or computed as the reference range/scale or growth curve for Use Release 2.1 (including the sections for described in Req-2019) along with BMI percentile per age and sex, weight for health status evaluations and outcomes and for interventions (V2)). appropriate sets of norms provided by the age per length and sex, and head occipital- • Transitions of Care: Criteria includes the CDC or in a compatible tabular format frontal circumference. • ability to create, receive, and properly (typically based on Lambda-Mu-Sigma [LMS] Electronic Prescribing: (§ 170.315(b)(11)) which supports improved patient safety and consumer interoperable documents using a curve fitting computational method). prescription accuracy, workflow efficiencies, common content and transport standard that 2015 Edition Criterion Alignment: and increase configurability of systems include key health data that should be Common Clinical Data Set (CCDS), Clinical including functionality that would support accessible and available for exchange. Decision Support (CDS). pediatric medication management. • Application Programming Interfaces New or Updated Criterion Alignment: criteria including the ‘‘application access— USCDI, API. Supplemental Children’s Format patient selection’’, ‘‘application access—data Title: Provide alerts for out-of-range Requirements for Recommendation 2 category request’’, and ‘‘application access— biometric data. We seek feedback about the relevance of all data request’’ which can help address Children’s EHR Format: Requirement Req- the following potential Children’s EHR many of the challenges currently faced by 2045—Release Package 2015 Priority List. Format requirements and their correlation to caregivers accessing pediatric health data. Topic(s): Primary Care Management, Well Recommendation 2. • Transitions of Care criteria includes the Child/Preventive Care. 1. Title: Rounding for administrable doses. ability to create and to receive interoperable Description: The system shall include the Children’s EHR Format: Req-2035—Release documents using a comment content ability to provide alerts for weight, length/ Package 2015 Priority List. standard that include key health data that height, head circumference, and BMI data Topic(s): Medication Management. should be accessible and available for points that fall outside two standard Description: The system shall enable exchange to support the care of children deviations of CDC/WHO pediatric data. calculated doses (e.g., weight-based) to be across care settings. 2015 Edition Criterion Alignment: Clinical rounded to optimize administration • Demographic criterion requires the Decision Support (CDS). convenience. ability to record various demographic New or Updated Criterion Alignment: 2015 Edition Criterion Alignment: information for a patient including potential USCDI, API. Electronic prescribing. supports for patient and parental matching.

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00184 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7607

Alignment With Proposed New or Updated New or Updated Criterion Alignment: API. summary record (formatted to Consolidated Certification Criteria 3. Title: Authorized non-clinician viewers CDA Release 2.1) that is document—level ONC believes tis priority is supported by of EHR data. tagged as restricted and subject to re- the proposed new and updated certification Children’s EHR Format: Req-2032—Release disclosure restrictions using the HL7 criteria in this proposed rule: Package 2015 Priority List. Implementation Guide: Data Segmentation • United States Core Data for Topic(s): Child Welfare, Patient Portals for Privacy (DS4P), Release 1. Requires the Interoperability (USCDI): The USCDI (PHR). ability to separate the document-level tagged (§ 170.213) which enables the inclusion of Description: The system shall have the document from other documents received. ability to identify members of the care team pediatric vital sign data elements, including Requires the ability to view the restricted (including professional and nonprofessional the reference range/scale or growth curve for document without having to incorporate any members) and indicate their roles/ BMI percentile per age and sex, weight for relationships to the child. of the data from the document. age per length and sex, and head occipital- • 2015 Edition Criterion Alignment: Care Transitions of Care criteria includes the frontal circumference. plan criterion, authentication, access control, ability to create, receive, and properly • Data Segmentation for Privacy: (two for and authorization. consumer interoperable documents using a C–CDA ((§ 170.315(b)(12)) and New or Updated Criterion Alignment: API. common content and transport standard that (§ 170.315(b)(13)) and one for FHIR 4. Title: Document decision-making include key health data that should be (§ 170.315(g)(11))) could provide authority of patient representative. accessible and available for exchange. functionality to address the concerns Children’s EHR Format: Req-2030: Release Alignment With Proposed New or Updated multiple stakeholders expressed regarding Package: 2015 Priority List. the need to restrict granular pediatric health Topic(s): Security and Confidentiality. Certification Criteria data at production based on the intended Description: The system shall have the ONC believes this recommendation is recipient of the data. ability to store, retrieve, and display supported by the proposed new and updated • Application Programming Interfaces information about an individual’s right to certification criteria in this proposed rule: (APIs): § 170.315(g)(10), would require the authorize care, to release information, and to • United States Core Data for use of Health Level 7 (HL7®) Fast Healthcare ® authorize payment for care on behalf of the Interoperability (USCDI): The USCDI Interoperability Resources (FHIR ) standards patient, including time restrictions or other and several implementation specifications to (§ 170.213) which enables the inclusion of limitations. This includes storing copies of pediatric vital sign data elements, including establish standardized application the relevant consent and authorization forms programming interfaces (APIs) for the reference range/scale or growth curve for in compliance with state and federal rules, BMI percentile per age and sex, weight for interoperability purposes and to permit 3rd and also includes cases of child foster care, age per length and sex, and head occipital- party software developers to connect to the state social services agencies, guardians, electronic health record (EHR) through the frontal circumference. guarantors, and those recognized to have full • certified API technology. or partial authority. The system shall allow Data Segmentation for Privacy: (two for for multiple individuals. C–CDA ((§ 170.315(b)(12)) and Supplemental Children’s EHR Format (§ 170.315(b)(13)) and one for FHIR Requirements for Recommendation 3 2015 Edition Criterion Alignment: Patient health information capture. (§ 170.315(g)(11))) would provide We seek feedback about the relevance of New or Updated Criterion Alignment: Data functionality to address the concerns the following potential supplemental segmentation. multiple stakeholders expressed regarding Children’s EHR Format requirements and the need to restrict granular pediatric health their correlation to Recommendation 3. Recommendation 4: Segmented Access to data at production based on the intended Information 1. Title: Ability to document parental recipient of the data. (guardian) notification or permission. Alignment With Children’s EHR Format • Application Programming Interfaces Children’s EHR Format: Req-2008: Release (APIs): § 170.315(g)(10), would require the Package: 2015 Priority List. Stakeholders identified alignment with the use of Health Level 7 (HL7®) Fast Healthcare Topic(s): Security and Confidentiality, Children’s EHR Format Requirement as Interoperability Resources (FHIR®) standards Parents and Guardians, and Family follows: and several implementation specifications to Relationship Data. Title: Segmented access to information. establish standardized application Description: The system shall provide the Children’s EHR Format: Req-2041: Release ability to document parental (guardian) Package: 2015 Priority List. programming interfaces (APIs) for notification or permission for consenting Topic(s): Security and Confidentiality. interoperability purposes and to permit 3rd minors to receive some treatments as Description: The system shall provide party software developers to connect to the required by institutional policy or users the ability to segment health care data electronic health record (EHR) through the jurisdictional law. in order to keep information about minor certified API technology. consent services private and distinct from 2015 Edition Criterion Alignment: Data other content of the record, such that it is not Supplemental Children’s Format segmentation for privacy—send criterion, exposed to parents/guardians without the Requirements for Recommendation 4 data segmentation for privacy—receive minor’s authorization. criterion, and/or the patient health We seek feedback about the relevance of information capture criterion, view, Alignment With 2015 Edition Certification the following potential Children’s EHR download, and transmit (VDT) to third-party, Criteria Format requirements and their correlation to Recommendation 4. and Application Programming Interface ONC believes this recommendation is (API). 1. Title: Problem-specific age of consent. supported by the 2015 Edition Criteria listed Children’s EHR Format: Req-2039: Release New or Updated Criterion Alignment: Data below, and ONC believes this Package: 2015 Priority List. segmentation for privacy. recommendation is supported by health IT Topic(s): Security and Confidentiality. 2. Title: Record parental notification of beyond what is included in the certification newborn screening diagnosis. program Description: The system shall provide the Children’s EHR Format: Req-2016: Release • Data Segmentation for Privacy criteria: ability to access legal guidelines on consent Package: 2015 Priority List. Æ Data segmentation for privacy—send requirements for reference, where available, Topic(s): Newborn Screening. criterion provides the ability to create a and to record the age of consent for a specific Description: The system shall be able to summary record (formatted to Consolidated treatment when these differ based on legal track that the child’s legal guardians were CDA (C–CDA) Release 2.1) that is tagged at guidelines. notified of any newborn screening-related the document level as restricted and subject 2015 Edition Criterion Alignment: diagnosis. to re-disclosure restrictions using the HL7 Demographics, care plan criterion, data 2015 Edition Criterion Alignment: Implementation Guide: Data Segmentation segmentation for privacy—send, data Question: View, download, and transmit for Privacy (DS4P), Release 1. segmentation for privacy—receive. (VDT) to third-party, secure messaging, Æ Data segmentation for privacy—receive New or Updated Criterion Alignment: Application Programming Interface (API). criterion requires the ability to receive a USCDI, data segmentation.

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00185 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7608 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

Recommendation 5: Synchronize the reference range/scale or growth curve for patient selection’’, ‘‘application access—data Immunization Histories With Registries BMI percentile per age and sex, weight for category request’’, and ‘‘application access— age per length and sex, and head occipital- all data request’’ which can help address Alignment With Children’s EHR Format frontal circumference. many of the challenges currently faced by Stakeholders identified alignment with the • Application Programming Interfaces caregivers accessing pediatric health data. Children’s EHR Format Requirement as (APIs): § 170.315(g)(10), would require the ONC believes this priority could also be follows: use of Health Level 7 (HL7®) Fast Healthcare supported by health IT beyond what is Title: Synchronize immunization histories Interoperability Resources (FHIR®) standards included in the certification program. with registry. and several implementation specifications to ONC notes that per the National Council Children’s EHR Format: Req-2011*: establish standardized application for Prescription Drug Programs (NCPDP), Release Package: 2015 Priority List. programming interfaces (APIs) for dose-range checking should be based on Topic(s): Registry Linkages, interoperability purposes and to permit 3rd industry drug database products and are not Immunizations. party software developers to connect to the intrinsic to SCRIPT. Description: The system shall support electronic health record (EHR) through the updating and reconciling a child’s certified API technology. Alignment With Proposed New or Updated immunization record with information Certification Criteria Supplemental Children’s Format received from immunization information • United States Core Data for Requirements for Recommendation 5 systems or other health information Interoperability (USCDI): The USCDI exchanges (HIEs). We seek feedback about the relevance of (§ 170.213) which enables the inclusion of Title: Use established immunization the following potential Children’s EHR pediatric vital sign data elements, including messaging standards. Format requirements and their correlation to the reference range/scale or growth curve for Children’s EHR Format: Req-2028 Release Recommendation 5. BMI percentile per age and sex, weight for Package: 2015 Priority List. 1. Title: Produce completed forms from age per length and sex, and head occipital- Topic(s): Registry Linkages, EHR data. frontal circumference. Immunizations. The Children’s EHR Format: Req-2027 • Application Programming Interfaces Description: (A) The system shall use the Release Package: 2015 Priority List. (APIs): § 170.315(g)(10), would require the messaging standards established through Topic(s): Well Child/Preventive Care, use of Health Level 7 (HL7®) Fast Healthcare meaningful use requirements to send data to Immunizations. Interoperability Resources (FHIR®) standards immunization information systems or other Description: The system shall produce and several implementation specifications to HIEs. (B) The system shall use the messaging reports (e.g., for camp, school, or child care) establish standardized application standards established through meaningful of a child’s immunization history, including programming interfaces (APIs) for use requirements to receive data from the following elements: Child’s name, date of interoperability purposes and to permit 3rd immunization information systems or other birth and sex, date the report was produced, party software developers to connect to the HIEs. antigen administered, date administered, electronic health record (EHR) through the route of administration (when available), and certified API technology. Alignment With 2015 Edition Certification an indication of whether a vaccine was Criterion refused or contraindicated. Recommendation 7: Transferrable Access ONC believes this recommendation is 2015 Edition Certification Alignment: Authority Transmission to immunization registries, supported by the 2015 Edition Criterion Alignment With Children’s EHR Format listed below: View, Download and Transmit (VDT), • Transmission to Immunization Registries Application Programming Interface (API). Stakeholders identified alignment with the criterion, which: New or Updated Criterion Alignment: API. Children’s EHR Format Requirement as Æ Provides the ability to create follows: Recommendation 6: Age- and Weight- Title: Transferrable access authority. immunization information according to the Specific Single-Dose Range Checking implementation guide for Immunization Children’s EHR Format: Req-2026: Release Messaging Release 1.5, and the July 2015 Alignment With Children’s EHR Format Package: 2015 Priority List. Topic(s): School-Based Linkages, Security addendum, using CVX codes for historical Stakeholders identified alignment with the and Confidentiality, Patient Portals and vaccines and NDC codes for newly Children’s EHR Format Requirements as Patient Health Records (PHR). administered vaccines. follows: Description: The system shall provide a Æ Provides the ability to request, access, Title: Age- and weight-specific single-dose and display the evaluated immunization range checking. mechanism to enable access control that history and forecast from an immunization Children’s EHR Format: Req-2037: Release allows a transferrable access authority (e.g., registry for a patient in accordance with the Package: 2015 Priority List. to address change in guardian, child reaching HL7 2.5.1 standard, the HL7 2.5.1. IG for Topic(s): Medication Management. age of maturity, etc.). Immunization Messaging, Release 1.5, and Description: The system shall provide Alignment With 2015 Edition Certification July 2015 addendum. medication dosing decision support that Criterion • View, Download, and Transmit to Third detects a drug dose that falls outside the Party (VDT) criterion, which: minimum-maximum range based on the ONC believes this recommendation is Æ Provides the ability for patients (and patient’s age, weight, and maximum supported by the 2015 Edition criterion their authorized representatives) to view, below. recommended adult dose (if known) or • download, and transmit their health maximum recommended pediatric dose (if View, Download, and Transmit to Third information to a third party via internet- known), for a single dose of the medication. Party (VDT) criterion, which: Æ based technology consistent with one of the Provides the ability for patients (and Web Content Accessibility Guidelines Alignment With 2015 Edition Certification their authorized representatives) to view, (WCAG) 2.0 Levels A or AA. Criteria download, and transmit their health Æ Requires the ability for patients (and ONC believes this recommendation is information to a third party via internet- their authorized representatives) to view, at supported by the 2015 Edition criterion listed based technology consistent with one of the a minimum, the Common Clinical Data Set, below: Web Content Accessibility Guidelines laboratory test report(s), and diagnostic image Clinical Decision Support (CDS) can be (WCAG) 2.0 Levels A or AA. reports. used to develop a variety of tools to enhance Æ Requires the ability for patients (and decision-making in the pediatric clinical their authorized representatives) to view, at Alignment With Proposed New or Updated workflow including contextually relevant a minimum, the Common Clinical Data Set, Certification Criteria reference information, clinical guidelines, laboratory test report(s), and diagnostic image • United States Core Data for condition-specific order sets, alerts, and reports. Interoperability (USCDI): The USCDI reminders, among other tools. Application Programming Interfaces (§ 170.213) which enables the inclusion of Application Programming Interfaces criteria including the ‘‘application access— pediatric vital sign data elements, including criteria including the ‘‘application access— patient selection’’, ‘‘application access—data

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00186 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7609

category request’’, and ‘‘application access— Consolidated CDA Templates for Clinical • Clinical Quality Measures criteria for all data request’’ which can help address Notes (US Realm), draft standard for Trial record and export, import and calculate, and many of the challenges currently faced by Use Release 2.1 (including the sections for filter criteria: caregivers accessing pediatric health data. health status evaluations and outcomes and Æ Record and export criterion ensures that for interventions (V2)). health IT systems can record and export Alignment With Proposed New or Updated • Transitions of Care criteria includes the CQM data electronically; the export Certification Criterion ability to create and to receive interoperable functionality gives clinicians the ability to • Data Segmentation for Privacy: (two for documents using a comment content export their results to multiple programs. C–CDA ((§ 170.315(b)(12)) and standard that include key health data that Æ import and calculate criterion supports (§ 170.315(b)(13)) and one for FHIR should be accessible and available for streamlined clinician processes through the (§ 170.315(g)(11))) would provide exchange to support the care of children importing of CQM data in a standardized functionality to address the concerns across care settings. format and ensures that health IT systems multiple stakeholders expressed regarding • Demographic criterion requires the can correctly calculate eCQM results using a the need to restrict granular pediatric health ability to record various demographic standardized format. data at production based on the intended information for a patient including potential Æ filter criterion supports the capability for recipient of the data. supports for patient and parental matching. a clinician to make a query for eCQM results • Application Programming Interfaces • Family Health History criterion permits using or a combination of data captured by (APIs): § 170.315(g)(10), would require the the ability to record, change, and access a the certified health IT for quality use of Health Level 7 (HL7®) Fast Healthcare patient’s family health history (according to improvement and quality reporting purposes. Interoperability Resources (FHIR®) standards the September 2015 release of SNOMED CT®, • Application Programming Interfaces and several implementation specifications to U.S. edition). criteria including the ‘‘application access— establish standardized application • Social, Psychological, and Behavioral patient selection’’, ‘‘application access—data programming interfaces (APIs) for Data criteria capture information (also category request’’, and ‘‘application access— interoperability purposes and to permit 3rd known as social determinants of health) that all data request’’ which can help address party software developers to connect to the can help to provide a more complete view of many of the challenges currently faced by electronic health record (EHR) through the a mother’s overall health status. caregivers accessing pediatric health data. certified API technology. Alignment With Proposed New or Updated Alignment With Proposed New or Updated Supplemental Children’s Format Certification Criteria Certification Criteria Requirements for Recommendation 7 • United States Core Data for ONC believes this recommendation is We seek feedback about the relevance of Interoperability (USCDI): The USCDI supported by the proposed new and updated the following potential Children’s EHR (§ 170.213) which enables the inclusion of certification criteria in this proposed rule: Format requirements and their correlation to pediatric vital sign data elements, including • Application Programming Interfaces Recommendation 7. the reference range/scale or growth curve for (APIs): § 170.315(g)(10), would require the 1. Title: Age of emancipation. BMI percentile per age and sex, weight for use of Health Level 7 (HL7®) Fast Healthcare The Children’s EHR Format: Requirement age per length and sex, and head occipital- Interoperability Resources (FHIR®) standards Req-2040 Release Package: 2015 Priority List. frontal circumference. and several implementation specifications to Topic(s): Security and Confidentiality. • Application Programming Interfaces establish standardized application Description: The system shall provide the (APIs): § 170.315(g)(10), would require the programming interfaces (APIs) for ability to record the patient’s emancipated use of Health Level 7 (HL7®) Fast Healthcare interoperability purposes and to permit 3rd minor status. Interoperability Resources (FHIR®) standards party software developers to connect to the 2015 Edition Criterion Alignment: and several implementation specifications to electronic health record (EHR) through the Demographic. establish standardized application certified API technology. New or Updated Criterion Alignment: Data programming interfaces (APIs) for Recommendation 10: Flag Special Health segmentation. interoperability purposes and to permit 3rd Care Needs party software developers to connect to the Recommendation 8: Associate Maternal electronic health record (EHR) through the Health Information and Demographics With Alignment With Children’s EHR Format certified API technology. Newborn Stakeholders identified alignment with the Recommendation 9: Track Incomplete Children’s EHR Format Requirement as Alignment With Children’s EHR Format Preventative Care Opportunities follows: Stakeholders identified alignment with the Title: Flag special health care needs. Children’s EHR Format Requirement as Alignment With Children’s EHR Format The Children’s EHR Format: Req-2014: follows: Stakeholders identified alignment with the Release Package: 2015 Priority List. Title: Associate mother’s demographics Children’s EHR Format Requirement as Topic(s): Children with Special Health with newborn. follows: Care Needs. Children’s EHR Format: Req-2021: Release Title: Track incomplete preventive care Description: The system shall support the Package: 2015 Priority List opportunities. ability for providers to flag or un-flag Topic(s): Patient Identifier, Parents and Children’s EHR Format: Req-2024: Release individuals with special health care needs or Guardians and Family Relationship Data. Package: 2015 Priority List. complex conditions who may benefit from Description: The system shall provide the Topic(s): Well Child/Preventive Care. care management, decision support, and care ability to associate identifying parent or Description: The system shall generate a planning, and shall support reporting. guardian demographic information, such as list on demand for any children who have Alignment With 2015 Edition Certification relationship to child, street address, missed recommended health supervision Criteria telephone number, and/or email address for visits (e.g., preventive opportunities), each individual child. according to the frequency of visits ONC believes this recommendation is recommended in Bright FuturesTM. supported by the 2015 Edition criterion Alignment With the 2015 Edition below. Certification Criterion Alignment With 2015 Edition Certification • Problem List criterion contains the ONC believes this recommendation is Criteria patient’s current health problems, injuries, supported by the 2015 Edition criterion ONC believes this recommendation is chronic conditions, and other factors that below: supported by the 2015 Edition criterion affect the overall health and well-being of the • Care Plan: Criteria includes the ability to below: patient. record, change, access, create, and receive Clinical Decision Support (CDS) criterion • Clinical Decision Support (CDS) can be care plan information according to the care includes configuration that enables used to develop a variety of tools to enhance plan document template in the HL7 interventions based on various CCDS data decision-making in the pediatric clinical implementation guide for CDA® Release 2: elements, including vital signs. workflow including contextually relevant

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00187 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7610 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

reference information, clinical guidelines, DEPARTMENT OF HEALTH AND CMS–9115–P, P.O. Box 8016, Baltimore, condition-specific order sets, alerts, and HUMAN SERVICES MD 21244–8016. reminders, among other tools. Please allow sufficient time for mailed • Clinical Quality Measures criteria for Centers for Medicare & Medicaid comments to be received before the record and export, import and calculate, and Services close of the comment period. filter criteria: 3. By express or overnight mail. You Æ Record and export criterion ensures that 42 CFR Parts 406, 407, 422, 423, 431, may send written comments to the health IT systems can record and export 438, 457, 482, and 485 following address ONLY: Centers for CQM data electronically; the export Medicare & Medicaid Services, functionality gives clinicians the ability to Office of the Secretary Department of Health and Human export their results to multiple programs. Services, Attention: CMS–9115–P, Mail Æ import and calculate criterion supports 45 CFR Part 156 Stop C4–26–05, 7500 Security streamlined clinician processes through the Boulevard, Baltimore, MD 21244–1850. importing of CQM data in a standardized [CMS–9115–P] For information on viewing public format and ensures that health IT systems comments, see the beginning of the can correctly calculate eCQM results using a RIN 0938–AT79 SUPPLEMENTARY INFORMATION section. standardized format. FOR FURTHER INFORMATION CONTACT: Æ filter criterion supports the capability for Medicare and Medicaid Programs; Patient Protection and Affordable Care Alexandra Mugge, (410) 786–4457, for a clinician to make a query for eCQM results issues related to interoperability, CMS using or a combination of data captured by Act; Interoperability and Patient Access for Medicare Advantage health IT strategy, technical standards the certified health IT for quality and patient matching. improvement and quality reporting purposes. Organization and Medicaid Managed Care Plans, State Medicaid Agencies, Natalie Albright, (410) 786–1671, for Alignment With Proposed New or Updated CHIP Agencies and CHIP Managed issues related to Medicare Advantage. John Giles, (410) 786–1255, for issues Certification Criteria Care Entities, Issuers of Qualified related to Medicaid. ONC believes this recommendation is Health Plans in the Federally- Emily Pedneau, (301) 492–4448, for supported by the proposed new and updated Facilitated Exchanges and Health Care issues related to Qualified Health Plans. certification criteria in this proposed rule: Providers Meg Barry, (410) 786–1536, for issues • United States Core Data for related to CHIP. Interoperability (USCDI): The USCDI AGENCY: Centers for Medicare & Medicaid Services (CMS), HHS. Thomas Novak, (202) 322–7235, for (§ 170.213) which enables the inclusion of issues related to trust exchange pediatric vital sign data elements, including ACTION: Proposed rule. networks and payer to payer the reference range/scale or growth curve for SUMMARY: This proposed rule is coordination. BMI percentile per age and sex, weight for Sharon Donovan, (410) 786–9187, for age per length and sex, and head occipital- intended to move the health care issues related to federal-state data frontal circumference. ecosystem in the direction of • interoperability, and to signal our exchange. Application Programming Interfaces Daniel Riner, (410) 786–0237, for (APIs): § 170.315(g)(10), would require the commitment to the vision set out in the ® 21st Century Cures Act and Executive issues related to Physician Compare. use of Health Level 7 (HL7 ) Fast Healthcare Ashley Hain, (410) 786–7603, for ® Order 13813 to improve access to, and Interoperability Resources (FHIR ) standards issues related to hospital public and several implementation specifications to the quality of, information that Americans need to make informed reporting. establish standardized application Melissa Singer, (410) 786–0365, for health care decisions, including data programming interfaces (APIs) for issues related to provider directories. interoperability purposes and to permit 3rd about health care prices and outcomes, CAPT Scott Cooper, USPHS, (410) party software developers to connect to the while minimizing reporting burdens on 786–9465, for issues related to hospital electronic health record (EHR) through the affected plans, health care providers, or and critical access hospital conditions certified API technology. payers. of participation. [FR Doc. 2019–02224 Filed 2–22–19; 4:15 pm] DATES: To be assured consideration, Lisa Bari, (410) 786–0087, for issues BILLING CODE 4150–45–P comments must be received at one of related to advancing interoperability in the addresses provided below, no later innovative models. than 5 p.m. on May 3, 2019. Russell Hendel, (410) 786–0329, for ADDRESSES: In commenting, please refer issues related to the Collection of to file code CMS–9115–P. Because of Information or the Regulation Impact staff and resource limitations, we cannot Analysis sections. accept comments by facsimile (FAX) SUPPLEMENTARY INFORMATION: transmission. Inspection of Public Comments: All Comments, including mass comment comments received before the close of submissions, must be submitted in one the comment period are available for of the following three ways (please viewing by the public, including any choose only one of the ways listed): personally identifiable or confidential 1. Electronically. You may submit business information that is included in electronic comments on this regulation a comment. We post all comments to http://www.regulations.gov. Follow received before the close of the the ‘‘Submit a comment’’ instructions. comment period on the following 2. By regular mail. You may mail website as soon as possible after they written comments to the following have been received: http:// address ONLY: Centers for Medicare & www.regulations.gov. Follow the search Medicaid Services, Department of instructions on that website to view Health and Human Services, Attention: public comments.

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00188 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2