[Federal Register Volume 85, Number 85 (Friday, May 1, 2020)]
[Rules and Regulations]
[Pages 25642-25961]
From the Federal Register Online via the Government Publishing Office [www.gpo.gov]
[FR Doc No: 2020-07419]
[[Page 25641]]
Vol. 85
Friday,
No. 85
May 1, 2020
Part III
Book 2 of 2 Books
Pages 25641-26318
Department of Health and Human Services
-----------------------------------------------------------------------
45 CFR Parts 170 and 171
21st Century Cures Act: Interoperability, Information Blocking, and the
ONC Health IT Certification Program; Final Rule
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and
Regulations
[[Page 25642]]
-----------------------------------------------------------------------
DEPARTMENT OF HEALTH AND HUMAN SERVICES
Office of the Secretary
45 CFR Parts 170 and 171
RIN 0955-AA01
21st Century Cures Act: Interoperability, Information Blocking,
and the ONC Health IT Certification Program
AGENCY: Office of the National Coordinator for Health Information
Technology (ONC), Department of Health and Human Services (HHS).
ACTION: Final rule.
-----------------------------------------------------------------------
SUMMARY: This final rule implements certain provisions of the 21st
Century Cures Act, including Conditions and Maintenance of
Certification requirements for health information technology (health
IT) developers under the ONC Health IT Certification Program (Program),
the voluntary certification of health IT for use by pediatric health
care providers, and reasonable and necessary activities that do not
constitute information blocking. The implementation of these provisions
will advance interoperability and support the access, exchange, and use
of electronic health information. The rule also finalizes certain
modifications to the 2015 Edition health IT certification criteria and
Program in additional ways to advance interoperability, enhance health
IT certification, and reduce burden and costs.
DATES:
Effective date: This final rule is effective on June 30, 2020.
Incorporation by reference: The incorporation by reference of
certain publications listed in the rule was approved by the Director of
the Federal Register as of June 30, 2020.
Compliance date: Compliance with 45 CFR 170.401, 170.402(a)(1), and
45 CFR part 171 is required by November 2, 2020.
FOR FURTHER INFORMATION CONTACT: Michael Lipinski, Office of Policy,
Office of the National Coordinator for Health Information Technology,
202-690-7151.
SUPPLEMENTARY INFORMATION:
Table of Contents
I. Executive Summary
A. Purpose of Regulatory Action
B. Summary of Major Provisions and Clarifications
1. Deregulatory Actions for Previous Rulemakings
2. Updates to the 2015 Edition Certification Criteria
a. Adoption of the United States Core Data for Interoperability
(USCDI) as a Standard
b. Electronic Prescribing
c. Clinical Quality Measures--Report
d. Electronic Health Information (EHI) Export
e. Application Programming Interfaces
f. Privacy and Security Transparency Attestations
g. Security Tags and Consent Management
3. Modifications To the ONC Health IT Certification Program
4. Health IT for the Care Continuum
5. Conditions and Maintenance of Certification Requirements
6. Information Blocking
C. Costs and Benefits
II. Background
A. Statutory Basis
1. Standards, Implementation Specifications, and Certification
Criteria
2. Health IT Certification Program(s)
B. Regulatory History
C. General Comments on the Proposed Rule
III. Deregulatory Actions for Previous Rulemakings
A. Background
1. History of Burden Reduction and Regulatory Flexibility
2. Executive Orders 13771 and 13777
B. Deregulatory Actions
1. Removal of Randomized Surveillance Requirements
2. Removal of the 2014 Edition From the Code of Federal
Regulations
3. Removal of the ONC-Approved Accreditor From the Program
4. Removal of Certain 2015 Edition Certification Criteria and
Standards
a. 2015 Edition Base EHR Definition Certification Criteria
b. Drug-Formulary and Preferred Drug Lists
c. Patient-Specific Education Resources
d. Common Clinical Data Set Summary Record--Create; and Common
Clinical Data Set Summary Record--Receive
e. Secure Messaging
5. Removal of Certain ONC Health IT Certification Program
Requirements
a. Limitations Disclosures
b. Transparency and Mandatory Disclosures Requirements
6. Recognition of Food and Drug Administration Processes
a. FDA Software Precertification Pilot Program
b. Development of Similar Independent Program Processes--Request
for Information
IV. Updates To the 2015 Edition Certification Criteria
A. Standards and Implementation Specifications
1. National Technology Transfer and Advancement Act
2. Compliance With Adopted Standards and Implementation
Specifications
3. ``Reasonably Available'' to Interested Parties
B. Revised and New 2015 Edition Criteria
1. The United States Core Data for Interoperability Standard
(USCDI)
a. USCDI 2015 Edition Certification Criteria
b. USCDI Standard--Data Classes Included
c. USCDI Standard--Relationship to Content Exchange Standards
and Implementation Specifications
2. Clinical Notes C-CDA Implementation Specification
3. Unique Device Identifier(s) for a Patient's Implantable
Device(s) C-CDA Implementation Specification
4. Electronic Prescribing Criterion
a. Electronic Prescribing Standard and Certification Criterion
b. Electronic Prescribing Transactions
5. Clinical Quality Measures--Report Criterion
6. Electronic Health Information (EHI) Export Criterion
a. Single Patient Export To Support Patient Access
b. Patient Population Export to Support Transitions Between
Health IT Systems
c. Scope of Data Export
d. Export Format
e. Initial Step Towards Real-Time Access
f. Timeframes
g. 2015 Edition ``Data Export'' Criterion in Sec. 170.315(b)(6)
7. Standardized API for Patient and Population Services
Criterion
8. Privacy and Security Transparency Attestations Criteria
a. Encrypt Authentication Credentials
b. Multi-Factor Authentication
9. Security Tags and Consent Management Criteria
a. Implementation With the Consolidated CDA Release 2.1
b. Implementation With the Fast Healthcare Interoperability
Resources (FHIRr) Standard
10. Auditable Events and Tamper-Resistance, Audit Reports, and
Auditing Actions on Health Information
C. Unchanged 2015 Edition Criteria--Promoting Interoperability
Programs Reference Alignment
V. Modifications To the ONC Health IT Certification Program
A. Corrections
1. Auditable Events and Tamper Resistance
2. Amendments
3. View, Download, and Transmit to 3rd Party
4. Integrating Revised and New Certification Criteria Into the
2015 Edition Privacy and Security Certification Framework
B. Principles of Proper Conduct for ONC-ACBs
1. Records Retention
2. Conformance Methods for Certification Criteria
3. ONC-ACBs To Accept Test Results From Any ONC-ATL in Good
Standing
4. Mandatory Disclosures and Certifications
C. Principles of Proper Conduct for ONC-ATLs--Records Retention
VI. Health IT for the Care Continuum
A. Health IT for Pediatric Setting
1. Background and Stakeholder Convening
2. Recommendations for the Voluntary Certification of Health IT
for Use in Pediatric Care
a. 2015 Edition Certification Criteria
b. New or Revised Certification Criteria
[[Page 25643]]
B. Health IT and Opioid Use Disorder Prevention and Treatment--
Request for Information
VII. Conditions and Maintenance of Certification Requirements for
Health IT Developers
A. Implementation
B. Provisions
1. Information Blocking
2. Assurances
a. Full Compliance and Unrestricted Implementation of
Certification Criteria Capabilities
b. Certification to the ``Electronic Health Information Export''
Criterion
c. Records and Information Retention
d. Trusted Exchange Framework and the Common Agreement--Request
for Information
3. Communications
a. Background and Purpose
b. Condition of Certification Requirements
c. Maintenance of Certification Requirements
4. Application Programming Interfaces
a. Statutory Interpretation and API Policy Principles
b. API Standards and Implementation Specifications
c. Standardized API for Patient and Population Services
d. API Condition of Certification Requirements
e. API Maintenance of Certification Requirements
5. Real World Testing
a. Unit of Analysis at which Testing Requirements Apply
b. Applicability of Real World Testing Condition and Maintenance
of Certification Requirements
c. Testing Plans, Methods, and Results Reporting
d. Submission Dates
e. Real World Testing Pilot Year
f. Health IT Modules Certified But Not Yet Deployed
g. Standards Version Advancement Process (SVAP)
h. Updating Already Certified Health IT Leveraging SVAP
Flexibility
i. Health IT Modules Presented for Certification Leveraging SVAP
Flexibility
j. Requirements Associated With All Health IT Modules Certified
Leveraging SVAP Flexibility
k. Advanced Version Approval for SVAP
l. Real World Testing Principles of Proper Conduct for ONC-ACBs
m. Health IT Module Certification & Certification to Newer
Versions of Certain Standards
6. Attestations
7. EHR Reporting Criteria Submission
C. Compliance
D. Enforcement
1. ONC Direct Review of the Conditions and Maintenance of
Certification Requirements
2. Review and Enforcement Only by ONC
3. Review Processes
a. Initiating Review and Health IT Developer Notice
b. Relationship With ONC-ACBs and ONC-ATLs
c. Records Access
d. Corrective Action
e. Certification Ban and Termination
f. Appeal
g. Suspension
h. Proposed Termination
4. Public Listing of Certification Ban and Terminations
5. Effect on Existing Program Requirements and Processes
6. Coordination With the Office of Inspector General
7. Applicability of Conditions and Maintenance of Certification
Requirements for Self-Developers
VIII. Information Blocking
A. Statutory Basis
B. Legislative Background and Policy Considerations
1. Purpose of the Information Blocking Provision
2. Policy Considerations and Approach to Information Blocking
3. General Comments Regarding Information Blocking Exceptions
C. Relevant Statutory Terms and Provisions
1. ``Required by Law''
2. Health Care Providers, Health IT Developers, Exchanges, and
Networks
a. Health Care Providers
b. Health IT Developers of Certified Health IT
c. Health Information Networks and Health Information Exchanges
3. Electronic Health Information
4. Price Information--Request for Information
5. Interests Promoted by the Information Blocking Provision
a. Access, Exchange, and Use of EHI
b. Interoperability Elements
6. Practices That May Implicate the Information Blocking
Provision
a. Prevention, Material Discouragement, and Other Interference
b. Likelihood of Interference
c. Examples of Practices Likely to Interfere With Access,
Exchange, or Use of EHI
7. Applicability of Exceptions
a. Reasonable and Necessary Activities
b. Treatment of Different Types of Actors
c. Establishing That Activities and Practices Meet the
Conditions of an Exception
D. Exceptions to the Information Blocking Definition
1. Exceptions That Involve not Fulfilling Requests To Access,
Exchange, or Use EHI
a. Preventing Harm Exception--When will an actor's practice that
is likely to interfere with the access, exchange, or use of EHI in
order to prevent harm not be considered information blocking?
b. Privacy Exception--When will an actor's practice of not
fulfilling a request to access, exchange, or use EHI in order to
protect an individual's privacy not be considered information
blocking?
c. Security Exception--When will an actor's practice that is
likely to interfere with the access, exchange, or use of EHI in
order to protect the security of EHI not be considered information
blocking?
d. Infeasibility Exception--When will an actor's practice of not
fulfilling a request to access, exchange, or use EHI due to the
infeasibility of the request not be considered information blocking?
e. Health IT Performance Exception--When will an actor's
practice that is implemented to maintain or improve health IT
performance and that is likely to interfere with the access,
exchange, or use of EHI not be considered information blocking?
2. Exceptions That Involve Procedures for Fulfilling Requests To
Access, Exchange, or Use EHI
a. Content and Manner Exception--When will an actor's practice
of limiting the content of its response to or the manner in which it
fulfills a request to access, exchange, or use EHI not be considered
information blocking?
b. Fees Exception--When will an actor's practice of charging
fees for accessing, exchanging, or using EHI not be considered
information blocking?
c. Licensing Exception--When will an actor's practice to license
interoperability elements in order for EHI to be accessed,
exchanged, or used not be considered information blocking?
E. Additional Exceptions--Request for Information
1. Exception for Complying With Common Agreement for Trusted
Exchange
2. New Exceptions
F. Complaint Process
G. Disincentives for Health Care Providers--Request for
Information
IX. Registries Request for Information
X. Patient Matching Request for Information
XI. Incorporation by Reference
XII. Collection of Information Requirements
A. ONC-ACBs
B. Health IT Developers
XIII. Regulatory Impact Analysis
A. Statement of Need
B. Alternatives Considered
C. Overall Impact
1. Executive Orders 12866 and 13563--Regulatory Planning and
Review Analysis
2. Executive Order 13771--Reducing Regulation and Controlling
Regulatory Costs
a. Costs and Benefits
b. Accounting Statement and Table
3. Regulatory Flexibility Act
4. Executive Order 13132--Federalism
5. Unfunded Mandates Reform Act of 1995
Regulation Text
I. Executive Summary
A. Purpose of Regulatory Action
ONC is responsible for the implementation of key provisions in
Title IV of the 21st Century Cures Act (Cures Act) that are designed to
advance interoperability; support the access, exchange, and use of
electronic health information (EHI); and address occurrences of
information blocking. This final rule implements certain provisions of
the Cures Act, including Conditions and Maintenance of Certification
requirements for health information technology (health IT)
[[Page 25644]]
developers, the voluntary certification of health IT for use by
pediatric health providers, and reasonable and necessary activities
that do not constitute information blocking. The final rule also
implements parts of section 4006(a) of the Cures Act to support
patients' access to their EHI in a form convenient for patients, such
as making a patient's EHI more electronically accessible through the
adoption of standards and certification criteria and the implementation
of information blocking policies that support patient electronic access
to their health information at no cost. Additionally, the final rule
modifies the 2015 Edition health IT certification criteria and ONC
Health IT Certification Program (Program) in other ways to advance
interoperability, enhance health IT certification, and reduce burden
and costs.
In addition to fulfilling the Cures Act's requirements, the final
rule contributes to fulfilling Executive Order (E.O.) 13813. The
President issued E.O. 13813 on October 12, 2017, to promote health care
choice and competition across the United States. Section 1(c) of the
E.O., in relevant part, states that government rules affecting the
United States health care system should re-inject competition into
health care markets by lowering barriers to entry and preventing abuses
of market power. Section 1(c) also states that government rules should
improve access to and the quality of information that Americans need to
make informed health care decisions. For example, as mentioned above,
the final rule establishes application programming interface (API)
requirements, including for patients' access to their health
information without special effort. The API approach also supports
health care providers' independence to choose the ``provider-facing''
third-party services they want to use to interact with the certified
API technology they have acquired. In addition, the final rule provides
the Secretary of Health and Human Services' (Secretary) interpretation
of the information blocking definition as established in the Cures Act
and the application of the information blocking provision by
identifying reasonable and necessary activities that would not
constitute information blocking. Many of these activities focus on
improving patient and health care provider access to EHI and promoting
competition.
B. Summary of Major Provisions and Clarifications
1. Deregulatory Actions for Previous Rulemakings
Since the inception of the Program, we have aimed to implement and
administer the Program in the least burdensome manner that supports our
policy goals. Throughout the years, we have worked to improve the
Program with a focus on ways to reduce burden, offer flexibility to
both developers and providers, and support innovation. This approach
has been consistent with the principles of E.O. 13563 on Improving
Regulation and Regulatory Review (February 2, 2011), which instructs
agencies to ``periodically review its existing significant regulations
and determine whether any such regulations should be modified,
streamlined, expanded, or repealed so as to make the agency's
regulatory program more effective or less burdensome in achieving the
regulatory objectives.'' To that end, we have historically, where
feasible and appropriate, taken measures to reduce burden within the
Program and make the Program more effective, flexible, and streamlined.
We reviewed and evaluated existing regulations and identified ways
to administratively reduce burden and implement deregulatory actions
through guidance. In this final rule, we have finalized new
deregulatory actions that will reduce burden for health IT developers,
providers, and other stakeholders. We have finalized five deregulatory
actions in section III.B: (1) Removal of a requirement to conduct
randomized surveillance on a set percentage of certified products,
allowing ONC-Authorized Certification Bodies (ONC-ACBs) more
flexibility to identify the right approach for surveillance actions;
(2) removal of the 2014 Edition from the Code of Federal Regulations
(CFR); (3) removal of the ONC-Approved Accreditor (ONC-AA) from the
Program; (4) removal of certain 2015 Edition certification criteria;
and (5) removal of certain Program requirements. We have not finalized
a sixth deregulatory action we proposed, related to recognition of the
Food and Drug Administration (FDA) Software Precertification Program,
as comments and the early stage of development of the FDA program
indicate finalization would be premature at this time.
2. Updates to the 2015 Edition Certification Criteria
This final rule updates the 2015 Edition to remove several
certification criteria. It also updates some certification criteria to
reflect standard and implementation specification updates. In
consideration of public comments, the final rule adds only two new
technical certification criteria and two new attestation-structured
privacy and security certification criteria.
a. Adoption of the United States Core Data for Interoperability (USCDI)
as a Standard
We noted in the Proposed Rule that, as part of continued efforts to
ensure the availability of a minimum baseline of data classes that
could be commonly available for interoperable exchange, ONC adopted the
2015 Edition ``Common Clinical Data Set'' (CCDS) definition and used
the CCDS shorthand in several certification criteria. However, the CCDS
definition also began to be used colloquially for many different
purposes. As the CCDS definition's relevance grew outside of its
regulatory context, it was often viewed as a ceiling to the industry's
collective data set for access, exchange, and use. In addition, we
noted in the NPRM that as we continue to move toward value-based care,
the inclusion of additional data classes beyond the CCDS would be
necessary. In order to advance interoperability, we proposed to remove
the CCDS definition and its references from the 2015 Edition and
replace it with the ``United States Core Data for Interoperability
\1\'' (USCDI). We proposed to adopt the USCDI as a standard, naming
USCDI Version 1 (USCDI v1) in Sec. 170.213 and incorporating it by
reference in Sec. 170.299. The USCDI standard would establish a set of
data classes and constituent data elements required to support
interoperability nationwide. To achieve the goals set forth in the
Cures Act, we indicated that we intended to establish and follow a
predictable, transparent, and collaborative process to expand the
USCDI, including providing stakeholders with the opportunity to comment
on the USCDI's expansion. We also noted that once the USCDI is adopted
by the Secretary in regulation, health IT developers would be allowed
to take advantage of a new proposed flexibility we called the
``Standards Version Advancement Process'' (SVAP) (see 84 FR 7497
through 7500, see also section VII.B.5 of this final rule). In order to
advance interoperability, we have finalized the adoption of the USCDI
standard. Because the USCDI is adopted as a standard and the SVAP is
finalized, the SVAP will allow a developer to voluntarily have their
products certified to newer, National Coordinator approved versions of
the
[[Page 25645]]
USCDI in the future without waiting for rulemaking to update the
version of the USCDI listed in the regulations.
---------------------------------------------------------------------------
\1\ https://www.healthit.gov/uscdi.
---------------------------------------------------------------------------
b. Electronic Prescribing
We have finalized an update to the electronic prescribing National
Council for Prescription Drug Programs (NCPDP) SCRIPT standard in 45
CFR 170.205(b) from NCPDP SCRIPT standard version 10.6 to NCPDP SCRIPT
standard version 2017071 for the electronic prescribing certification
criterion (Sec. 170.315(b)(3)). ONC and the Centers for Medicare &
Medicaid Services (CMS) have historically maintained aligned e-Rx and
medication history (MH) standards to ensure that the current standard
for certification to the electronic prescribing criterion supports use
of the current Part D e-Rx and MH standards. This helps advance
alignment with CMS' program standards.
In a final rule published April 16, 2018, CMS finalized its update
of its Part D standards to NCPDP SCRIPT standard version 2017071 for e-
Rx and MH, effective January 1, 2020 (83 FR 16440). In addition to
continuing to reference the transactions previously included in Sec.
170.315(b)(3), and in keeping with CMS' final rule, we have adopted all
of the additional NCPDP SCRIPT standard version 2017071 transactions
that CMS adopted in 42 CFR 423.160(b)(2)(iv). Furthermore, we have
adopted the same electronic Prior Authorization (ePA) request and
response transactions supported by NCPDP SCRIPT standard 2017071
proposed by CMS in the Medicare Program; Secure Electronic Prior
Authorization for Medicare Part D proposed rule (84 FR 28450). Some
adopted transactions are required to demonstrate conformance to the
updated Sec. 170.315(b)(3) criterion, while other transactions are
optional.
c. Clinical Quality Measures--Report
In this final rule, we have removed the Health Level 7
(HL7[supreg]) Quality Reporting Document Architecture (QRDA) standard
requirements in the 2015 Edition ``Clinical Quality Measures--report''
criterion in Sec. 170.315(c)(3) and, in their place, required Health
IT Modules to support the CMS QRDA Implementation Guide (IGs).\2\ This
will help reduce the burden for health IT developers and remove
certification requirements that do not support quality reporting for
CMS programs.
---------------------------------------------------------------------------
\2\ https://ecqi.healthit.gov/qrda-quality-reporting-document-
architecture.
---------------------------------------------------------------------------
d. Electronic Health Information (EHI) Export
We proposed to adopt a new 2015 Edition certification criterion,
referred to as ``EHI export'' in Sec. 170.315(b)(10) in the Proposed
Rule. The criterion's proposed conformance requirements were intended
to provide a means to export the entire EHI a certified health IT
product produced and electronically managed to support two contexts:
(1) Single patient EHI export and (2) for patient EHI export when a
health care provider is switching health IT systems. The proposals did
not require the exported data to be in a specific standardized format.
Rather, we proposed to require that such an export be in a computable,
electronic format made available via a publicly accessible hyperlink.
We noted that this transparency would facilitate the subsequent
interpretation and use of the exported information.
We have finalized the criterion with modifications in response to
public comment. We have refined the scope of data a Health IT Module
certified to Sec. 170.315(b)(10) must export, and aligned the
criterion to the definition of EHI we finalized in Sec. 170.102 and
Sec. 171.102. The finalized criterion requires a certified Health IT
Module to electronically export all of the EHI, as defined in Sec.
171.102, that can be stored at the time of certification by the
product, of which the Health IT Module is a part. We finalized the 2015
Edition Cures Update ``EHI export'' criterion in Sec. 170.315(b)(10)
but did not finalize its inclusion in the 2015 Edition Base Electronic
Health Record (EHR) definition, as proposed. Our intention with this
criterion, in combination with other criteria set forth in this final
rule, is to advance the interoperability of health IT as defined in
section 4003 the Cures Act, including the ``complete access, exchange,
and use of all electronically accessible health information.''
e. Application Programming Interfaces (APIs)
We have adopted a new API certification criterion in Sec.
170.315(g)(10) to replace the ``application access--data category
request'' certification criterion (Sec. 170.315(g)(8)), and added it
to the updated 2015 Edition Base EHR definition. This new
``standardized API for patient and population services'' certification
criterion focuses on supporting two types of API-enabled services: (1)
Services for which a single patient's data is the focus and (2)
services for which multiple patients' data are the focus. The API
certification criterion requires the use of the Health Level 7
(HL7[supreg]) Fast Healthcare Interoperability Resources (FHIR[supreg])
standard Release 4 and references several standards and implementation
specifications adopted in Sec. 170.213 and Sec. 170.215 to support
standardization and interoperability. This certification criterion will
align industry efforts around FHIR Release 4 and advance
interoperability of API-enabled ``read'' services for single and
multiple patients.
f. Privacy and Security Transparency Attestations
We have adopted two new privacy and security certification criteria
requiring transparency attestations from developers of certified health
IT as part of the updated 2015 Edition privacy and security
certification framework. The attestations will serve to identify
whether or not certified health IT supports encrypting authentication
credentials and/or multi-factor authentication (MFA). While these
criteria provide increased transparency, they do not require new
development or implementation to take place. As part of ONC's ongoing
commitment to advance transparency about certified health IT products,
ONC will list the developers' attestation responses on the Certified
Health IT Product List (CHPL).
g. Security Tags and Consent Management
In the 2015 Edition final rule (80 FR 62646, Oct. 16, 2015), we
adopted two ``data segmentation for privacy'' (DS4P) certification
criteria, one for creating a summary record according to the DS4P
standard (Sec. 170.315(b)(7)) and one for receiving a summary record
according to the DS4P standard (Sec. 170.315(b)(8)). Certification to
these 2015 Edition DS4P criteria only required security tagging of
Consolidated-Clinical Document Architecture (C-CDA) documents at the
document level. As noted in the 2015 Edition final rule (80 FR 62646),
certification to these criteria is not linked to meeting the Certified
EHR Technology definition (CEHRT) used in CMS programs.
Since the 2015 Edition final rule, the health care industry has
engaged in additional field testing and implementation of the DS4P
standard. Stakeholders also shared with ONC--through public forums,
listening sessions, and correspondence--that only tagging C-CDA
documents at the document level did not permit providers the
flexibility to address more complex use cases for representing patient
privacy preferences. Based on public comment, in this final rule, we
[[Page 25646]]
have changed the names of the two current 2015 Edition DS4P criteria to
Security tags--Summary of Care (send) and Security tags--Summary of
Care (receive). We also updated the requirements for these criteria to
support security tagging at the document, section, and entry levels.
This change better reflects the purpose of these criteria and enables
adopters to support a more granular approach to security tagging
clinical documents for exchange.
In finalizing this more granular approach for security tagging
Consolidated Clinical Document Architecture (C-CDA) documents, we note
that we do not specify rules or requirements for the disposition of
tagged data or any requirements on health care providers related to
data segmentation for privacy. The use cases for which health IT
certified to these criteria might be implemented would be driven by
other applicable Federal, State, local, or tribal law and are outside
the scope of the certification criteria. We recognize that the tagging
of documents is not a fully automated segmentation of the record but
rather a first, technological step or tool to support health IT
developers implementing technology solutions for health care providers
to replace burdensome manual processes for tagging sensitive
information.
We also proposed to adopt a new 2015 Edition certification
criterion, ``consent management for APIs'' in Sec. 170.315(g)(11), to
support data segmentation and consent management through an API in
accordance with the Consent Implementation Guide (IG). However, in
response to comments, we have chosen not to finalize our proposal for
this criterion at this time.
3. Modifications to the ONC Health IT Certification Program
In this final rule, we have finalized corrections to the 2015
Edition privacy and security certification framework (80 FR 62705) and
relevant regulatory provisions. We also have finalized corrections to
the relevant current Certification Companion Guides (CCGs). We have
adopted new and revised Principles of Proper Conduct (PoPC) for ONC-
ACBs. We have finalized clarification that the records retention
provision includes the ``life of the edition'' as well as three years
after the retirement of an edition related to the certification of
Complete EHRs and Health IT Modules. We also have finalized revisions
to the PoPC in Sec. 170.523(h) to clarify the basis for certification,
including to permit a certification decision to be based on an
evaluation conducted by the ONC-ACB for Health IT Modules' compliance
with certification criteria by use of conformity methods approved by
the National Coordinator for Health Information Technology (National
Coordinator). We also have finalized the addition of Sec. 170.523(r)
to require ONC-ACBs to accept test results from any ONC-Authorized
Testing Laboratory (ONC-ATL) in good standing under the Program and
compliant with the ISO/IEC 17025 accreditation requirements consistent
with the requirements set forth in Sec. Sec. 170.520(b)(3) and
170.524(a). We believe these new and revised PoPC provide necessary
clarifications for ONC-ACBs and promote stability among the ONC-ACBs.
We also have finalized the update of Sec. 170.523(k) to broaden the
requirements beyond just the Medicare and Medicaid EHR Incentive
Programs (now renamed the Promoting Interoperability (PI) Programs and
referenced as such hereafter) and provided other necessary
clarifications.
We have finalized a revised PoPC for ONC-ATLs. The finalized
revision clarifies that the records retention provision includes the
``life of the edition'' as well as three years after the retirement of
an edition related to the certification of Complete EHRs and Health IT
Modules.
4. Health IT for the Care Continuum
Section 4001(b) of the Cures Act includes two provisions related to
supporting health IT across the care continuum. The first instructs the
National Coordinator to encourage, keep, or recognize through existing
authorities the voluntary certification of health IT for use in medical
specialties and sites of service where more technological advancement
or integration is needed. The second outlines a provision related to
the voluntary certification of health IT for use by pediatric health
providers to support the health care of children. These provisions
align closely with our core purpose to promote interoperability and to
support care coordination, patient engagement, and health care quality
improvement initiatives. Advancing health IT that promotes and supports
patient care when and where it is needed continues to be a primary goal
of the Program. This means health IT should support patient
populations, specialized care, transitions of care, and practice
settings across the care continuum.
We have explored how we might work with the health IT industry and
with specialty organizations to collaboratively develop and promote
health IT that supports medical specialties and sites of service. Over
time, we have taken steps to make the Program modular, more open and
accessible to different types of health IT, and better able to advance
functionality that is generally applicable to a variety of care and
practice settings. We considered a wide range of factors specific to
the provisions in the Cures Act to support providers of health care for
children. These include: The evolution of health IT across the care
continuum, the costs and benefits associated with health IT, the
potential regulatory burden and compliance timelines, and the need to
help advance health IT that benefits multiple medical specialties and
sites of service involved in the care of children. In consideration of
these factors, and to advance implementation of section 4001(b) of the
Cures Act specific to pediatric care, we held a listening session where
stakeholders could share their clinical knowledge and technical
expertise in pediatric care and pediatric sites of service. Through the
information learned at this listening session and our analysis of the
health IT landscape for pediatric settings, we identified existing 2015
Edition criteria, as well as new or revised 2015 Edition criteria
proposed in the Proposed Rule, that could benefit providers of
pediatric care and pediatric settings. In this final rule, we have
identified the already existing 2015 Edition certification criteria and
the new or revised 2015 Edition criteria adopted in this final rule
that support the voluntary certification of health IT for pediatric
care and pediatric settings. We also elaborate on our next steps to
support pediatric care and pediatric settings through the development,
adoption, certification, and use of health IT, including the continued
support of a pediatrics health IT web page on www.healthit.gov/pediatrics and the future development of informational resources.
We also recognize the significance of the opioid epidemic
confronting our nation and the importance of helping to support the
health IT needs of health care providers committed to preventing
inappropriate access to prescription opioids and to providing safe,
appropriate treatment. Therefore, we requested public comment on how
our existing Program requirements and the proposals in the Proposed
Rule may support use cases related to Opioid Use Disorder (OUD)
prevention and treatment and if there were additional areas that we
should consider for effective implementation of health IT to help
address OUD prevention and treatment. We received over 100
[[Page 25647]]
comments in responses to this RFI, which we are actively reviewing.
5. Conditions and Maintenance of Certification Requirements
We have established in this final rule, certain Conditions and
Maintenance of Certification requirements for health IT developers
based on the Conditions and Maintenance of Certification requirements
outlined in section 4002 of the Cures Act. The Program's Conditions and
Maintenance of Certification requirements express initial requirements
for health IT developers and their certified Health IT Module(s) as
well as ongoing requirements that must be met by both health IT
developers and their certified Health IT Module(s) under the Program.
In this regard, we have implemented the Cures Act Conditions of
Certification requirements with further specificity as it applies to
the Program and implemented any accompanying Maintenance of
Certification requirements as standalone requirements to ensure that
the Conditions of Certification requirements are not only met but
continually being met through the Maintenance of Certification
requirements. In this rule, we capitalize ``Conditions of
Certification'' and ``Maintenance of Certification'' when referring to
Conditions and Maintenance of Certification requirements established
for the Program under section 4002 of the Cures Act for ease of
reference and to distinguish from other conditions.
Information Blocking
Section 4002 of the Cures Act requires that a health IT developer,
as a Condition and Maintenance of Certification requirement under the
Program, not take any action that constitutes information blocking as
defined in section 3022(a) of the Public Health Service Act (PHSA). We
have adopted the information blocking Condition of Certification
requirement in Sec. 170.401 as proposed. As finalized, the Condition
of Certification requirement prohibits any health IT developer under
the Program from taking any action that constitutes information
blocking as defined by section 3022(a) of the PHSA. We have also
finalized that definition in Sec. 171.103.
Assurances
Section 4002 of the Cures Act also requires that a health IT
developer, as a Condition of Certification requirement under the
Program, provide assurances to the Secretary that, unless for
legitimate purpose(s) as specified by the Secretary, the developer will
not take any action that constitutes information blocking as defined in
section 3022(a) of the PHSA or any other action that may inhibit the
appropriate exchange, access, and use of EHI. We have finalized our
proposed implementation of this provision through several Conditions of
Certification and accompanying Maintenance of Certification
requirements, which are set forth in Sec. 170.402. We have also
adopted more specific Conditions and Maintenance of Certification
requirements, which are also set forth in Sec. 170.402, for certified
health IT developers to provide assurances to the Secretary that it
does not take any other action that may inhibit the appropriate
exchange, access, and use of EHI. These requirements serve to provide
further clarity under the Program as to how health IT developers must
meet our requirements as promulgated under the Cures Act.
Communications
The Cures Act also requires as a Condition and Maintenance of
Certification requirement under the Program that health IT developers
do not prohibit or restrict communications about certain aspects of the
performance of health IT and the developers' related business
practices. We have finalized (in Sec. 170.403) provisions that permit
developers to impose certain types of limited prohibitions and
restrictions that strike a balance between the need to promote open
communication about health IT, and related developer business
practices, with the need to protect the legitimate business interests
of health IT developers and others. The provisions identify certain
narrowly-defined types of communications, such as communications
required by law, made to a government agency, or made to a defined
category of safety organization, which will receive ``unqualified
protection'' under our Program. Under this policy, developers will be
prohibited from imposing any prohibitions or restrictions on such
protected communications. Based on public comment received, we have
also finalized provisions that allow health IT developers certified
under the Program to place limitations on certain types of
communications, including screenshots and video.
We have adopted Maintenance of Certification requirements proposed
in Sec. 170.403(b) with modifications. A health IT developer must not
impose or enforce any contractual requirement that contravenes the
requirements of this Condition of Certification. Furthermore, if a
health IT developer has contracts/agreements in existence that
contravene the requirements of this Condition of Certification, the
developer must notify all affected customers, other persons, or
entities that the prohibition or restriction within the contract/
agreement will not be enforced by the health IT developer. In response
to comments, we have finalized in Sec. 170.403(b)(2)(ii) that health
IT developers are required to amend their contracts/agreements to
remove or make void such provisions only when the contracts/agreements
are next modified for other purposes and not within the proposed period
of time from the effective date of this final rule.
Application Programming Interfaces (APIs)
As a Condition of Certification requirement in section 4002 of the
Cures Act requires health IT developers to publish APIs that allow
``health information from such technology to be accessed, exchanged,
and used without special effort through the use of APIs or successor
technology or standards, as provided for under applicable law.'' The
Cures Act's API Condition of Certification requirement also states that
a developer must, through an API, ``provide access to all data elements
of a patient's electronic health record to the extent permissible under
applicable privacy laws.'' The Cures Act's API Condition of
Certification requirement in section 4002 includes several key phrases
and requirements for health IT developers that go beyond the technical
functionality of the Health IT Modules they present for certification.
This final rule captures both the technical functionality and behaviors
necessary to implement the Cures Act API Condition of Certification
requirement. Specifically, we have adopted new standards, new
implementation specifications, a new certification criterion, and have
modified the Base EHR definition. In addition, we have finalized
detailed Condition and Maintenance of Certification requirements for
health IT developers.
Real World Testing
The Cures Act also added a new Condition and Maintenance of
Certification requirement that health IT developers must successfully
test the real world use of health IT for interoperability in the
type(s) of setting(s) in which such technology would be marketed. This
provision is critical to advancing transparency regarding Health IT
Modules' performance and to users having information that could be
crucial to
[[Page 25648]]
their decisions to acquire certified health IT.
As discussed in section VII.B.5 of this final rule, we have
established in Sec. 170.405 real world testing Condition and
Maintenance of Certification requirements that include Maintenance of
Certification requirements to update Health IT Modules certified to
certain certification criteria (see Sec. 170.405(b)(3) through (7) and
section IV.B of this final rule preamble) to ensure this certified
technology meets its users' needs for widespread and continued
interoperability.
As finalized, real world testing Condition and Maintenance of
Certification requirements apply to health IT developers with one or
more Health IT Module(s) certified to specific certification criteria
focused on interoperability and data exchange that are listed in Sec.
170.405(a), as discussed in section VII.B.5 of this final rule. Under
these Condition and Maintenance of Certification requirements, health
IT developers must submit publicly available annual real world testing
plans as well as annual real world testing results for health IT
certified to the criteria identified in Sec. 170.405(a). We have also
finalized a flexibility that we have named the Standards Version
Advancement Process (SVAP). Under this flexibility, health IT
developers will have the option to update their health IT that is
certified to the criteria identified in Sec. 170.405(a) to use more
advanced version(s) of the adopted standard(s) or implementation
specification(s) included in the criteria, provided such versions are
approved by the National Coordinator for use in health IT certified
under the Program. Similarly, we have finalized our proposal (84 FR
7497 through 7500) that health IT developers presenting health IT for
initial certification to one of the criteria listed in Sec. 170.405(a)
would have the option to certify to National Coordinator-approved newer
version(s) of one or more of the Secretary-adopted standards or
implementation specifications applicable to the criterion. All health
IT developers voluntarily opting to avail themselves of the SVAP
flexibility must ensure that their annual real world testing plans and
real world testing results submissions address all the versions of all
the standards and implementation specifications to which each Health IT
Module is certified. In addition, we have finalized in Sec.
170.405(b)(8)(i) the requirement that health IT developers with
existing certifications to criteria listed in Sec. 170.405(a) who wish
to avail themselves of the SVAP flexibility must notify both their ONC-
ACB and their affected customers of their plans to update their
certified health IT, and the update's anticipated impact on their
existing certified health IT and customers, specifically including but
not limited to whether, and if so for how long, the health IT developer
intends to continue supporting the prior version(s) \3\ of the
standard(s) to which the Health IT Module has already been certified,
in addition to the National Coordinator-approved newer version(s)
included in a planned update.
---------------------------------------------------------------------------
\3\ In the near term, many of these prior versions are likely to
be the same versions adopted by the Secretary and incorporated by
reference in subpart B of 45 CFR part 170. Over time, however, we
anticipate increasing frequency of prior versions certified
including National Coordinator-approved newer versions of these
Secretary-adopted standards.
---------------------------------------------------------------------------
We have finalized our proposal (84 FR 7501) to establish in Sec.
170.523(p) a new PoPC for ONC-ACBs that requires ONC-ACBs to review and
confirm that each health IT developer with one or more Health IT
Module(s) certified to any one or more of the criteria listed in Sec.
170.405(a) submits real world testing plans and real world results on a
timeframe that allows for the ONC-ACB to confirm completeness of all
plans and results by applicable annual due dates. The specific annual
due dates finalized in Sec. 170.523(p) differ from those proposed as,
and for the reasons, discussed in section VII.B.5 of this final rule
preamble. Once completeness is confirmed, ONC-ACBs must make the plans
available to ONC and the public via the Certified Health IT Product
List (CHPL).\4\ We have also finalized, with clarifying revisions, the
PoPC proposed in Sec. 170.523(m) to require ONC-ACBs to aggregate and
report to ONC no less than quarterly all updates successfully made to
support National Coordinator-approved newer versions of Secretary-
adopted standards in certified health IT pursuant to the developers
having voluntarily opted to avail themselves of the SVAP flexibility.
We also finalize in Sec. 170.523(t) the new PoPC for ONC-ACBs that
requires them to ensure that developers seeking to take advantage of
the SVAP flexibility provide the advance notice required in Sec.
170.405(b)(8) to all affected customers and its ONC-ACB, and comply
with all other applicable requirements.
---------------------------------------------------------------------------
\4\ Although real world testing plans and results will not be
immediately available upon publication of this final rule, an
overview of the CHPL is available at https://chpl.healthit.gov/#/resources/overview (last accessed 07/12/2019). For additional
information on how to navigate the CHPL, please refer to the CHPL
Public User Guide.
---------------------------------------------------------------------------
Attestations
Section 4002(a) of the Cures Act requires that a health IT
developer, as Condition and Maintenance of Certification requirements
under the Program, provide to the Secretary an attestation to all of
the other Conditions of Certification required in section 3001(c)(5)(D)
of the PHSA, except for the ``EHR reporting criteria submission''
Condition of Certification requirement in Sec. 3001(c)(5)(D)(vii). We
have finalized regulation text implementing the Cures Act's
``attestations'' Condition of Certification requirement in Sec.
170.406. Under Sec. 170.406 as finalized by this rule, health IT
developers will attest twice a year to compliance with the Conditions
and Maintenance of Certification requirements (except for the EHR
reporting criteria submission requirement, which would be metrics
reporting requirements separately implemented through a future
rulemaking). We believe requiring attestations every six months under
Sec. 170.406(b) will properly balance the need to support appropriate
enforcement with our desire to limit the burden on health IT
developers. In this regard, we have also identified methods to make the
process as simple and efficient for health IT developers as possible
(e.g., 30-day attestation window, web-based form submissions, and
attestation alert reminders).
We have also finalized that attestations will be submitted to ONC-
ACBs. We have finalized a new PoPC in Sec. 170.523(q) that an ONC-ACB
must review these submissions for completion and share the health IT
developers' attestations with us. We would then make the attestations
publicly available through the CHPL.
EHR Reporting Criteria Submission
The Cures Act specifies that health IT developers be required, as
Condition and Maintenance of Certification requirements under the
Program, to submit reporting criteria on certified health IT in
accordance with the EHR Reporting Program established under section
3009A of the PHSA, as added by the Cures Act. We have not yet
established an EHR Reporting Program. Once we establish such program,
we will undertake rulemaking to propose and implement the associated
Condition and Maintenance of Certification requirements for health IT
developers.
Enforcement
Section 4002(a) of the Cures Act adds (in section 3001(c)(5)(D) of
the PHSA) Program requirements aimed at addressing health IT
developers' actions and business practices through the Conditions and
Maintenance of Certification requirements, which expands the current
focus of the
[[Page 25649]]
Program requirements beyond the certified health IT itself. Equally
important, Cures Act section 4002(a) also provides that the Secretary
may encourage compliance with the Conditions and Maintenance of
Certification requirements and take action to discourage noncompliance.
We, therefore, have finalized our proposed enforcement framework for
the Conditions and Maintenance of Certification requirements in
Sec. Sec. 170.580 and 170.581 to encourage consistent compliance with
the requirements. More specifically, we have finalized our proposed
corrective action process in Sec. 170.580 for ONC to review potential
or known instances where a Condition or Maintenance of Certification
requirement under the Program has not been met or is not being met by a
health IT developer. We have also finalized in Sec. Sec. 170.580 and
170.581 our proposal to utilize, with minor modifications, the
processes previously established for ONC direct review of certified
health IT in the enforcement of the Conditions and Maintenance of
Certification requirements. Where we identify noncompliance, our first
priority will be to work with the health IT developer to remedy the
matter through a corrective action process. However, under certain
circumstances, ONC may ban a health IT developer from the Program and/
or terminate the certification of one or more of its Health IT Modules.
6. Information Blocking
Section 4004 of the Cures Act added section 3022 of the PHSA (42
U.S.C. 300jj-52, ``the information blocking provision''). Section
3022(a)(1) of the PHSA defines practices that constitute information
blocking when engaged in by a health care provider, or a health
information technology developer, exchange, or network. Section
3022(a)(3) authorizes the Secretary to identify, through notice and
comment rulemaking, reasonable and necessary activities that do not
constitute information blocking for purposes of the definition set
forth in section 3022(a)(1).
We identify eight reasonable and necessary activities as exceptions
to the information blocking definition, each of which does not
constitute information blocking for purposes of section 3022(a)(1) of
the PHSA. The exceptions apply to certain activities that are likely to
interfere with, prevent, or materially discourage the access, exchange,
or use of EHI, but that would be reasonable and necessary if certain
conditions are met.
In developing and finalizing the final exceptions, we were guided
by three overarching policy considerations. First, the exceptions are
limited to certain activities that we believe are important to the
successful functioning of the U.S. health care system, including
promoting public confidence in health IT infrastructure by supporting
the privacy and security of EHI, and protecting patient safety and
promoting competition and innovation in health IT and its use to
provide health care services to consumers. Second, each exception is
intended to address a significant risk that regulated individuals and
entities (i.e., health care providers, health IT developers of
certified health IT, health information networks, and health
information exchanges) will not engage in these reasonable and
necessary activities because of potential uncertainty regarding whether
they would be considered information blocking. Third, and last, each
exception is intended to be tailored, through appropriate conditions,
so that it is limited to the reasonable and necessary activities that
it is designed to exempt.
The eight exceptions are set forth in section VIII.D of this final
rule. The five exceptions finalized in Sec. Sec. 171.201-205, and
discussed in section VIII.D.1.a-e of this final rule, involve not
fulfilling requests to access, exchange, or use EHI. These exceptions
are intended to prevent harm and protect patient safety, promote the
privacy and security of EHI, excuse an actor from responding to
requests that are infeasible, and address activities that are
reasonable and necessary to promote the performance of health IT. The
three exceptions finalized in Sec. Sec. 171.301-303, and discussed in
section VIII.D.2.a-c of this final rule, involve procedures for
fulfilling requests to access, exchange, or use EHI. These exceptions
describe when an actor's practice of limiting the content of its
response to or the manner in which it responds to a request to access,
exchange, or use EHI will not be considered information blocking; when
an actor's practice of charging fees, including fees that result in a
reasonable profit margin, for accessing, exchanging, or using EHI will
not be considered information blocking; and when an actor's practice to
license interoperability elements for EHI to be accessed, exchanged, or
used will not be considered information blocking.
An actor will not be subject to enforcement actions under the
information blocking provision for civil monetary penalties (CMP) or
appropriate disincentives if the actor's practice satisfies at least
one exception. In order to satisfy an exception, each relevant practice
by an actor at all relevant times must meet all of the applicable
conditions of the exception. However, failure to meet the conditions of
an exception does not automatically mean a practice constitutes
information blocking. A practice failing to meet all conditions of an
exception only means that the practice would not have guaranteed
protection from CMPs or appropriate disincentives. The practice would
instead be evaluated on a case-by-case basis to assess the specific
facts and circumstances (e.g., whether the practice would be considered
to rise to the level of an interference, and whether the actor acted
with the requisite intent) to determine whether information blocking
has occurred.
In addition to establishing the exceptions, we have defined and
interpreted terms that are present in section 3022 of the PHSA (such as
the types of individuals and entities covered by the information
blocking provision). We have also finalized new terms and definitions
that are necessary to implement the information blocking provision. We
have codified the information blocking section in a new part of title
45 of the Code of Federal Regulations, part 171.
C. Costs and Benefits
Executive Orders 12866 on Regulatory Planning and Review (September
30, 1993), and 13563 on Improving Regulation and Regulatory Review
(February 2, 2011), direct agencies to assess all costs and benefits of
available regulatory alternatives and, if regulation is necessary, to
select regulatory approaches that maximize net benefits (including
potential economic, environmental, public health and safety effects,
distributive impacts, and equity). A regulatory impact analysis (RIA)
must be prepared for major rules with economically significant effects
($100 million or more in any one year). OMB has determined that this
final rule is an economically significant rule as the costs associated
with this final rule could be greater than $100 million per year.
Accordingly, we have prepared an RIA that to the best of our ability
presents the costs and benefits of this final rule.
We have estimated the potential monetary costs and benefits of this
final rule for health IT developers, health care providers, patients,
ONC-ACBs, ONC-ATLs, and the Federal Government (i.e., ONC), and have
broken those costs and benefits out into the following categories: (1)
Deregulatory actions (no associated costs); (2) updates to the 2015
Edition health IT certification criteria; (3) Conditions and
Maintenance of Certification requirements for a health
[[Page 25650]]
IT developer; (4) oversight for the Conditions and Maintenance of
Certification requirements; and (5) information blocking.
We note that we have rounded all estimates to the nearest dollar
and all estimates are expressed in 2017 dollars as it is the most
recent data available to address all cost and benefit estimates
consistently. We also note that we did not have adequate data to
quantify some of the costs and benefits within this RIA. In those
situations, we have described the non-quantified costs and benefits of
our provisions; however, such costs and benefits have not been
accounted for in the monetary cost and benefit totals below.
We estimated that the total cost for this final rule for the first
year after it is finalized (including one-time costs), based on the
cost estimates outlined above and throughout this RIA, would, on
average, range from $953 million to $2.6 billion with an average annual
cost of $1.8 billion. We estimate that the total perpetual cost for
this final rule (starting in year two), based on the cost estimates
outlined above, would, on average, range from $366 million to $1.3
billion with an average annual cost of $840 million.
We estimated the total annual benefit for this final rule, based on
the benefit estimates outlined above, would range from $1.2 billion to
$5.0 billion with primary estimated annual benefit of $3.1 billion.
II. Background
A. Statutory Basis
The Health Information Technology for Economic and Clinical Health
(HITECH) Act, Title XIII of Division A and Title IV of Division B of
the American Recovery and Reinvestment Act of 2009 (the Recovery Act)
(Pub. L. 111-5), was enacted on February 17, 2009. The HITECH Act
amended the Public Health Service Act (PHSA) and created ``Title XXX--
Health Information Technology and Quality'' (Title XXX) to improve
health care quality, safety, and efficiency through the promotion of
health IT and electronic health information (EHI) exchange.
The 21st Century Cures Act (hereinafter the ``Cures Act'') was
enacted on December 13, 2016, to accelerate the discovery, development,
and delivery of 21st century cures, and for other purposes. The Cures
Act, Pub. L. 114-255, included Title IV--Delivery, which amended
portions of the HITECH Act (Title XIII of Division A of Pub. L. 111-5)
by modifying or adding certain provisions to the PHSA relating to
health IT.
1. Standards, Implementation Specifications, and Certification Criteria
The HITECH Act established two new Federal advisory committees, the
HIT Policy Committee (HITPC) and the HIT Standards Committee (HITSC).
Each was responsible for advising the National Coordinator for Health
Information Technology (National Coordinator) on different aspects of
standards, implementation specifications, and certification criteria.
Section 3002 of the PHSA, as amended by section 4003(e) of the
Cures Act, replaced the HITPC and HITSC with one committee, the Health
Information Technology Advisory Committee (HIT Advisory Committee or
HITAC). After that change, section 3002(a) of the PHSA established that
the HITAC would advise and recommend to the National Coordinator on
different aspects of standards, implementation specifications, and
certification criteria, relating to the implementation of a health IT
infrastructure, nationally and locally, that advances the electronic
access, exchange, and use of health information. Further described in
section 3002(b)(1)(A) of the PHSA, this included providing the National
Coordinator with recommendations on a policy framework to advance
interoperable health IT infrastructure, updating recommendations to the
policy framework, and making new recommendations, as appropriate.
Section 3002(b)(2)(A) identified that in general, the HITAC would
recommend to the National Coordinator, for purposes of adoption under
section 3004 of the PHSA, standards, implementation specifications, and
certification criteria and an order of priority for the development,
harmonization, and recognition of such standards, specifications, and
certification criteria. Similar to the process previously required of
the former HITPC and HITSC, the HITAC will develop a schedule for the
assessment of policy recommendations for the Secretary to publish in
the Federal Register.
Section 3004 of the PHSA identifies a process for the adoption of
health IT standards, implementation specifications, and certification
criteria and authorizes the Secretary to adopt such standards,
implementation specifications, and certification criteria. As specified
in section 3004(a)(1), the Secretary is required, in consultation with
representatives of other relevant Federal agencies, to jointly review
standards, implementation specifications, and certification criteria
endorsed by the National Coordinator under section 3001(c), and
subsequently determine whether to propose the adoption of any grouping
of such standards, implementation specifications, or certification
criteria. The Secretary is required to publish all determinations in
the Federal Register.
Section 3004(b)(3) of the PHSA, which is titled Subsequent
Standards Activity, provides that the Secretary shall adopt additional
standards, implementation specifications, and certification criteria as
necessary and consistent with the schedule published by the HITAC. We
consider this provision in the broader context of the HITECH Act and
Cures Act to continue to grant the Secretary the authority and
discretion to adopt standards, implementation specifications, and
certification criteria that have been recommended by the HITAC and
endorsed by the National Coordinator, as well as other appropriate and
necessary health IT standards, implementation specifications, and
certification criteria.
2. Health IT Certification Program(s)
Under the HITECH Act, section 3001(c)(5) of the PHSA provides the
National Coordinator with the authority to establish a program or
programs for the voluntary certification of health IT. Specifically,
section 3001(c)(5)(A) specifies that the National Coordinator, in
consultation with the Director of the National Institute of Standards
and Technology (NIST), shall keep or recognize a program or programs
for the voluntary certification of health IT that is in compliance with
applicable certification criteria adopted under this subtitle (i.e.,
certification criteria adopted by the Secretary under section 3004 of
the PHSA). The certification program(s) must also include, as
appropriate, testing of the technology in accordance with section
13201(b) of the HITECH Act. Overall, section 13201(b) of the HITECH Act
requires that with respect to the development of standards and
implementation specifications, the Director of National Institute of
Standards and Technology (NIST) shall support the establishment of a
conformance testing infrastructure, including the development of
technical test beds. The same HITECH Act provision (section 13201(b))
also indicates that the development of this conformance testing
infrastructure may include a program to accredit independent, non-
Federal laboratories to perform testing.
Section 4001 of the Cures Act amended section 3001(c)(5) of the
PHSA to instruct the National Coordinator to encourage, keep, or
recognize, through
[[Page 25651]]
existing authorities, the voluntary certification of health IT under
the program for use in medical specialties and sites of service for
which no such technology is available or where more technological
advancement or integration is needed. Section 3001(c)(5)(C)(iii) in
particular identifies that the Secretary, in consultation with relevant
stakeholders, shall make recommendations for the voluntary
certification of health IT for use by pediatric health providers to
support the care of children, as well as adopt certification criteria
under section 3004 to support the voluntary certification of health IT
for use by pediatric health providers. The Cures Act further amended
section 3001(c)(5) of the PHSA by adding section 3001(c)(5)(D), which
provides the Secretary with the authority to require, through notice
and comment rulemaking, Conditions and Maintenance of Certification
requirements for the Program.
B. Regulatory History
The Secretary issued an interim final rule with request for
comments on January 13, 2010, (75 FR 2014), which adopted an initial
set of standards, implementation specifications, and certification
criteria. On March 10, 2010, we published a proposed rule (75 FR 11328)
that proposed both a temporary and permanent certification program for
the purposes of testing and certifying health IT. A final rule
establishing the temporary certification program was published on June
24, 2010, (75 FR 36158), and a final rule establishing the permanent
certification program was published on January 7, 2011, (76 FR 1262).
We have issued multiple rulemakings since these initial rulemakings to
update standards, implementation specifications, certification
criteria, and the certification program, a history of which can be
found in the October 16, 2015 final rule titled, ``2015 Edition Health
Information (Health IT) Certification Criteria, 2015 Edition Base
Electronic Health Record (EHR) Definition, and ONC Health IT
Certification Program Modifications'' (80 FR 62602) (``2015 Edition
final rule''). A final rule corrections and clarifications notice was
published for the 2015 Edition final rule on December 11, 2015, (80 FR
76868), to correct preamble and regulatory text errors and clarify
requirements of the Common Clinical Data Set (CCDS), the 2015 Edition
privacy and security certification framework, and the mandatory
disclosures for health IT developers.
The 2015 Edition final rule established a new edition of
certification criteria (``2015 Edition health IT certification
criteria'' or ``2015 Edition'') and a new 2015 Edition Base EHR
definition. The 2015 Edition established the capabilities and specified
the related standards and implementation specifications that CEHRT
would need to include to, at a minimum, support the achievement of
``meaningful use'' by eligible clinicians, eligible hospitals, and
critical access hospitals under the Medicare and Medicaid EHR Incentive
Programs (EHR Incentive Programs) (now referred to as the Promoting
Interoperability (PI) Programs) \5\ when the 2015 Edition is required
for use under these and other programs referencing the CEHRT
definition. The 2015 Edition final rule also made changes to the ONC
HIT Certification Program. The final rule adopted a proposal to change
the Program's name to the ``ONC Health IT Certification Program'' from
the ONC HIT Certification Program, modified the Program to make it more
accessible to other types of health IT beyond EHR technology and for
health IT that supports care and practice settings beyond the
ambulatory and inpatient settings, and adopted new and revised PoPC for
ONC-ACBs.
---------------------------------------------------------------------------
\5\ https://www.federalregister.gov/d/2018-16766/p-4.
---------------------------------------------------------------------------
After issuing a proposed rule on March 2, 2016, (81 FR 11056), we
published a final rule titled, ``ONC Health IT Certification Program:
Enhanced Oversight and Accountability'' (81 FR 72404) (``EOA final
rule'') on October 19, 2016. The EOA final rule finalized modifications
and new requirements under the Program, including provisions related to
our role in the Program. The final rule created a regulatory framework
for our direct review of health IT certified under the Program,
including, when necessary, requiring the correction of non-conformities
found in health IT certified under the Program and suspending and
terminating certifications issued to Complete EHRs and Health IT
Modules. The final rule also sets forth processes for us to authorize
and oversee accredited testing laboratories under the Program. In
addition, it includes provisions for expanded public availability of
certified health IT surveillance results.
On March 4, 2019, the Secretary published a proposed rule titled,
``21st Century Cures Act: Interoperability, Information Blocking, and
the ONC Health IT Certification Program'' (84 FR 7424) (``Proposed
Rule''). The Proposed Rule proposed to implement certain provisions of
the Cures Act that would advance interoperability and support the
access, exchange, and use of electronic health information and is the
subject of this final rule.
C. General Comments on the Proposed Rule
Comments. Numerous commenters expressed support for the overall
direction of the Proposed Rule. Numerous commenters also expressed
support for the policy goals expressed in the Proposed Rule, including:
Reduced health care costs; improved public health surveillance;
improved care coordination, continuity of care, and shared access of
data between patient and provider; improved quality and patient safety;
increased cost and quality transparency; greater efficiencies; and
better health outcomes for patients. A few commenters also commended
our interest in ways to use health IT to address opioid use disorders.
Many commenters also appreciated detailed context for the provisions in
the Proposed Rule. Many commenters stated that the proposed provisions
and standards will provide opportunities for innovation as well as
increase the ability of health care providers to connect new tools and
services to their systems.
A number of commenters commended our responsiveness to the health
care community, including patients, in drafting the rule. A few
commenters suggested that the existing language in the rule should
remain mostly unchanged as ONC drafts the final rule. Many commenters
commended us for collaborating with public- and private-sector partners
in developing the Proposed Rule. Specifically, some commenters
expressed appreciation for our work with CMS and their companion
Interoperability and Patient Access Proposed Rule. A number of
commenters shared that they look forward to working with us and CMS as
the health care industry progresses toward an interoperable system,
making it easier for small independent practices and providers to move
to value-based care.
Response. We appreciate the support expressed by many commenters.
This final rule maintains the direction of the Proposed Rule, and we
too look forward to ongoing collaboration with public and private
sector partners as we implement the provisions of this final rule.
Comments. A few commenters recommended that the final rule include
additional resources to assist with readability and ease of
understanding.
Response. We thank commenters for their feedback. As we did with
the
[[Page 25652]]
Proposed Rule, we are providing resources such as infographics, fact
sheets, webinars, and other forms of educational materials and
outreach. Many of the education materials can be found on
www.HealthIT.gov/curesrule.
Comments. Several commenters expressed the opinion that the use of
EHRs--and health IT, more generally--has negatively affected the
quality of health care delivery and that the Proposed Rule will
exacerbate this issue. Some of these commenters stated that the need to
input information into EHRs during office visits has resulted in
clinicians spending less time communicating with patients, and some
noted the impact of data entry on clinician burnout. A few commenters
made a similar point that use of EHRs has reduced productivity and, as
a result, increased health care spending.
Response. We thank commenters for their feedback. We are aware of
the challenges stakeholders have experienced in using EHRs and health
IT more broadly. In the Cures Act, Congress identified the importance
of easing regulatory and administrative burdens associated with the use
of EHRs and health IT. Specifically, through section 4001(a) of the
Cures Act, Congress directed the Department of Health and Human
Services to establish a goal, develop a strategy, and provide
recommendations to reduce EHR-related burdens that affect care
delivery.
To that end, on November 28, 2018, we, in partnership with CMS,
released a draft Strategy on Reducing Regulatory and Administrative
Burden Relating to the Use of Health IT and EHRs \6\ for public
comment. This draft strategy reflects input HHS received through
several wide-reaching listening sessions, written input, and
stakeholder outreach. We released the final report on February 21,
2020. Reflective of public comment, the final Strategy on Reducing
Regulatory and Administrative Burdens Relating to the Use of Health IT
and EHRs \7\ targets burdens tied to regulatory and administrative
requirements that HHS can directly impact through the rulemaking
process. The report's strategies, recommendations, and policy shifts
aim to give clinicians more time to focus on what matters--caring for
their patients. Based on stakeholder input, the final strategy outlines
three overarching goals designed to reduce clinician burden: (1) Reduce
the effort and time required to record health information in EHRs for
clinicians; (2) reduce the effort and time required to meet regulatory
reporting requirements for clinicians, hospitals, and health care
organizations; and (3) improve the functionality and intuitiveness
(ease of use) of EHRs.
---------------------------------------------------------------------------
\6\ https://www.healthit.gov/sites/default/files/page/2018-11/Draft%20Strategy%20on%20Reducing%20Regulatory%20and%20Administrative%20Burden%20Relating.pdf.
\7\ https://www.healthit.gov/sites/default/files/page/2020-02/BurdenReport_0.pdf.
---------------------------------------------------------------------------
In addition to the final strategy mentioned above, we refer readers
to section III of this final rule, Deregulatory Actions for Previous
Rulemakings, for more information on how we have worked to improve the
Program with a focus on ways to reduce burden, offer flexibility to
both health IT developers and providers, and support innovation.
Comments. We received several comments from a variety of
stakeholders to extend the 60-day comment period for the Proposed Rule,
stating that due to the depth and complexity of the policies proposed,
it would be critical for the public to have extended time to provide
sufficient and thoughtful comments to advance shared goals and shape
the interoperability landscape.
Response. In response to stakeholder inquiries to extend the 60-day
public comment period and based on the stated goals of the Proposed
Rule to improve interoperability and patient access to health
information for the purposes of promoting competition and better care,
we extended the comment period for the Proposed Rule for an additional
30 days which ended on June 3, 2019.
Comments. A number of commenters recommended delaying the final
rule by issuing an Interim Final Rule (IFR) with comment. Commenters
noted that many organizations are providing comments that include new
information blocking exceptions and that we will not be able to
incorporate such suggestions into the final rule without an opportunity
for comment. Several commenters stated that an IFR was appropriate due
to the significance and breadth of the Proposed Rule, as well the
magnitude of changes proposed and that an IFR would allow for
additional opportunity for stakeholder comment.
Several commenters recommended that ONC consider issuing a
Supplemental Notice of Proposed Rulemaking (SNPRM) to seek additional
comments on the information blocking provisions. Some of these
commenters stated that new definitions and terms introduced in the
Proposed Rule need additional clarification and an SNPRM would enable
ONC to propose such clarifications and seek feedback on modified
proposals.
Response. We recognize the importance of allowing enough time for
comment given the breadth of the Proposed Rule and acknowledge the
comments requesting the issuance of an IFR or a SNPRM. We believe that
the advance posting of the Proposed Rule on the ONC website, the
initial 60-day comment period, and the 30-day extension, provided
adequate time for comment, especially given the large volume of
comments received.
As discussed in the information blocking section of the Proposed
Rule (84 FR 7508), after hearing from stakeholders and based on our
findings from our 2015 Report to Congress,\8\ we concluded that
information blocking is a serious problem and recommended that Congress
prohibit information blocking and provide penalties and enforcement
mechanisms to deter these harmful practices. Congress responded by
enacting the Cures Act on December 13, 2016, with many provisions
specifying a need for swift implementation. It has been three years
since the Cures Act was enacted and information blocking remains a
serious concern. This final rule includes provisions that will address
information blocking and cannot be further delayed.
---------------------------------------------------------------------------
\8\ https://www.healthit.gov/sites/default/files/reports/info_blocking_040915.pdf.
---------------------------------------------------------------------------
We have taken multiple actions to address some expressed concerns
regarding the timing of the Conditions and Maintenance of Certification
requirements as well as the comprehensiveness of the information
blocking proposals. These actions include some burden reduction by
removing certain certification criteria, narrowing the scope of certain
certification criteria, and increasing the compliance timeline with
criteria. For purposes of information blocking, we have established
compliance date for 45 CFR part 171 that is six months, rather than
sixty days, after the date this final rule publishes in the Federal
Register. We have also focused the scope of EHI, and provided new and
revised exceptions that are actionable and reduce burden. One of these
new exceptions (see Sec. 171.301(a) and section VIII.D.2.a of this
final rule) includes a provision by which, until 24 months after this
rule is published in the Federal Register, an actor's conduct can
satisfy the conditions of the Content and Manner Exception (Sec.
171.301) if they provide at least the content that is within the USCDI
in response to a request for access, exchange, or use of EHI. Because
of these reasons and those noted above, we decline to issue an IFR or
SNPRM. Rather, we have issued this final rule to support
interoperability, empower patient control of their health care, and
instill competition in health care markets.
[[Page 25653]]
III. Deregulatory Actions for Previous Rulemakings
A. Background
1. History of Burden Reduction and Regulatory Flexibility
Since the inception of the ONC Health IT Certification Program
(Program), we have aimed to implement and administer the Program in the
least burdensome manner that supports our policy goals. Through the
years, we have worked to improve the Program with a focus on ways to
reduce burden, offer flexibility, and support innovation. This approach
has been consistent with the principles of Executive Order (E.O.) 13563
on Improving Regulation and Regulatory Review (February 2, 2011), which
instructs agencies to periodically review its existing significant
regulations and ``determine whether any such regulations should be
modified, streamlined, expanded, or repealed so as to make the agency's
regulatory program more effective or less burdensome in achieving the
regulatory objectives.'' To that end, we have historically taken
measures where feasible and appropriate to reduce burden within the
Program and make the Program more effective, flexible, and streamlined.
For example, in the 2014 Edition final rule (77 FR 54164, Sept. 4,
2012), we revised the certified electronic health record technology
(CEHRT) definition to provide flexibility and create regulatory
efficiencies by narrowing required functionality to a core set of
capabilities (i.e., the Base EHR definition) plus the additional
capabilities each eligible clinician, eligible hospital, and critical
access hospital needed to successfully achieve the applicable objective
and measures under the EHR Incentive Programs (now referred to as the
Promoting Interoperability (PI) Programs). ONC has also supported more
efficient testing and certification methods and reduced regulatory
burden through the adoption of a gap certification policy. As explained
in the 2014 Edition final rule (77 FR 54254) and the 2015 Edition final
rule (80 FR 62681), as modified by the 2015 final rule with corrections
and clarifications at 80 FR 76868, where applicable, gap certification
allows for the use of a previously certified health IT product's test
results for certification criteria identified as unchanged. Developers
have been able to use gap certification for more efficient
certification of their health IT when updating from the 2011 Edition to
the 2014 Edition and from the 2014 Edition to the 2015 Edition.
ONC introduced further means to reduce regulatory burden, increase
regulatory flexibility, and promote innovation in the 2014 Edition
Release 2 final rule (79 FR 54430) published on September 11, 2014. The
2014 Edition Release 2 final rule established a set of optional 2014
Edition certification criteria that provided flexibility and
alternative certification pathways for health IT developers and
providers based on their specific circumstances. The 2014 Edition
Release 2 final rule also simplified the Program by discontinuing the
use of the ``Complete EHR'' certification concept beginning with the
2015 Edition (79 FR 54443).
In the 2015 Edition final rule, we did not ``carry forward''
certain 2014 Edition certification criteria into the 2015 Edition, such
as the ``image results,'' ``patient list creation,'' and ``electronic
medication administration record'' criteria. We determined that these
criteria did not advance functionality or support interoperability (80
FR 62682 through 62684). We also did not require all health IT to be
certified to the ``meaningful use measurement'' certification criteria
for ``automated numerator recording'' and ``automated measure
calculation'' (80 FR 62604 and 62605), which the 2014 Edition had
previously required. Based on stakeholder feedback and Program
administration observations, we also permitted testing efficiencies for
the 2015 Edition ``automated numerator recording'' and ``automated
measure calculation'' criteria by removing the live demonstration
requirement of recording data and generating reports (80 FR 62703).
Health IT developers may now self-test their Health IT Modules'
capabilities and submit the resulting reports to the ONC-Authorized
Testing Laboratory (ONC-ATL) to verify compliance with the ``meaningful
use measurement'' criterion.\9\ In order to further reduce burden for
health IT developers, in our 2015 Edition final rule, we adopted a more
straightforward approach to privacy and security certification
requirements and clarified which requirements apply to each criterion
within the regulatory functional areas (80 FR 62605).
---------------------------------------------------------------------------
\9\ https://www.healthit.gov/test-method/automated-numerator-recording and https://www.healthit.gov/test-method/automated-measure-calculation.
---------------------------------------------------------------------------
2. Executive Orders 13771 and 13777
On January 30, 2017, the President issued E.O. 13771 on Reducing
Regulation and Controlling Regulatory Costs, which requires agencies to
identify deregulatory actions. This order was followed by E.O. 13777,
titled ``Enforcing the Regulatory Reform Agenda'' (February 24, 2017).
E.O. 13777 provides further direction on implementing regulatory reform
by identifying a process by which agencies must review and evaluate
existing regulations and make recommendations for repeal or
simplification.
In order to implement these regulatory reform initiatives and
policies, ONC reviewed and evaluated existing regulations in the year
leading to the issuance of the 21st Century Cures Act:
Interoperability, Information Blocking, and the ONC Health IT
Certification Program Proposed Rule (Proposed Rule) (84 FR 7424 through
7610). During our review, we sought to identify ways to further reduce
administrative burden, to implement deregulatory actions through
guidance, and to put forth deregulatory actions in this final rule that
will reduce burden for health IT developer, providers, and other
stakeholders.
Prior to publishing the Proposed Rule, on August 21, 2017, ONC
issued Relied Upon Software Program Guidance.\10\ Health IT developers
are permitted to use ``relied upon software'' \11\ to demonstrate
compliance with certification criteria adopted at 45 CFR part 170,
subpart C. Historically, in cases where a Health IT Module is paired
with multiple ``relied upon software'' products for the same
capability, health IT developers were required to demonstrate
compliance for the same certification criterion with each of those
``relied upon software'' products in order for the products to be
listed on the Certified Health IT Product List (CHPL). With the
guidance issued on August 21, 2017, health IT developers could
demonstrate compliance with only one ``relied upon software'' product
for a criterion/capability. Once the health IT developer demonstrates
compliance with a minimum of one ``relied upon software'' product, the
developer can have multiple, additional ``relied upon software''
products for the same criterion/capability listed on the CHPL (https://chpl.healthit.gov/). This approach reduces burden for health IT
developers, ONC-ATLs, and ONC-Authorized Certification Bodies (ONC-
ACBs).
---------------------------------------------------------------------------
\10\ https://www.healthit.gov/sites/default/files/relieduponsoftwareguidance.pdf.
\11\ ``Relied upon'' software is defined in the 2011 final rule
establishing the permanent certification program (76 FR 1276).
---------------------------------------------------------------------------
On September 21, 2017, ONC announced a deregulatory action to
reduce the overall burden for testing
[[Page 25654]]
health IT to the 2015 Edition certification criteria.\12\ ONC reviewed
the 2015 Edition test procedures and changed 30 of the 2015 Edition
test procedures from requiring ONC-ATL evaluation to requiring only
attestation by health IT developers that their product has capabilities
conformant with those specified in the associated certification
criterion/criteria.\13\ This deregulatory action reduced burden and
costs program-wide, while still maintaining the Program's high level of
integrity and assurances. The total testing cost savings for health IT
developers have been estimated between $8.34 and $9.26 million. ONC-
ATLs also benefitted by having more time and resources to focus on
tool-based testing (for interoperability-oriented criteria) and being
responsive to any retesting requirements that may arise from ONC-ACB
surveillance activities. Health care providers and other users of
certified health IT did not lose confidence in the Program because
health IT developers were still required to meet certification criteria
requirements and maintain their products' conformance to the full scope
of the associated criteria, including when implemented in the field and
in production use. ONC and ONC-ACBs continue to conduct surveillance
activities and respond to end-user complaints.
---------------------------------------------------------------------------
\12\ https://www.healthit.gov/buzz-blog/healthit-certification/certification-program-updates-support-efficiency-reduce-burden/.
\13\ https://www.healthit.gov/sites/default/files/policy/selfdeclarationapproachprogramguidance17-04.pdf.
---------------------------------------------------------------------------
B. Deregulatory Actions
In the Proposed Rule, we proposed (84 FR 7434 through 7439) and
sought comment on six specific deregulatory actions. Having considered
the comments received on the proposals, which are summarized below, we
have decided to finalize five of the six proposed deregulatory actions
and not to finalize the proposal to recognize the FDA Software
Precertification Pilot Program. We refer readers to section XIII
(Regulatory Impact Analysis) of this final rule for a discussion of the
estimated cost savings from these finalized deregulatory actions.
1. Removal of Randomized Surveillance Requirements
ONC-ACBs are required under Sec. 170.556 to conduct surveillance
of certified health IT to ensure that health IT continues to conform
with and function as required by the full scope of the certification
requirements. Surveillance is categorized as either reactive
surveillance (for example, complaint-based surveillance) or randomized
surveillance. Previously finalized regulations in Sec. 170.556(c)(2)
required ONC-ACBs to proactively surveil two percent of the
certificates they issue annually. As discussed in the Proposed Rule, in
the time since the two percent randomized surveillance requirement was
finalized, stakeholders had expressed concern that the benefits of in-
the-field, randomized surveillance may not outweigh the time commitment
required by providers, particularly if no non-conformities are found
(84 FR 7434). We noted in the Proposed Rule that, in general, health
care providers had expressed that reactive surveillance (e.g.,
surveillance based on user complaints) is a more logical and economical
approach to surveillance. Consistent with our September 21, 2017,
exercise of enforcement discretion on implementation of randomized
surveillance by ONC-ACBs,\14\ we proposed in the Proposed Rule to
eliminate certain regulatory randomized surveillance requirements (84
FR 7434).
---------------------------------------------------------------------------
\14\ https://www.healthit.gov/sites/default/files/ONC_Enforcement_Discretion_Randomized_Surveillance_8-30-17.pdf.
---------------------------------------------------------------------------
In the Proposed Rule, we specifically proposed to revise Sec.
170.556(c) by changing the requirement that ONC-ACBs must conduct in-
the-field, randomized surveillance to specify that ONC-ACBs may conduct
in-the-field, randomized surveillance (84 FR 7434). We further proposed
to remove Sec. 170.556(c)(2), which specified that ONC-ACBs must
conduct randomized surveillance for a minimum of two percent of
certified health IT products per year. We also proposed to remove the
requirements in Sec. 170.556(c)(5) regarding the exclusion and
exhaustion of selected locations for randomized surveillance.
Additionally, we proposed to remove the requirements in Sec.
170.556(c)(6) regarding the consecutive selection of certified health
IT for randomized surveillance. As noted in the Proposed Rule, without
these regulatory requirements, ONC-ACBs would still be required to
perform reactive surveillance, and would be permitted to conduct
randomized surveillance of their own accord, using the methodology
identified by ONC with respect to scope (Sec. 170.556(c)(1)),
selection method (Sec. 170.556(c)(3)), and the number and types of
locations for in-the-field surveillance (Sec. 170.556(c)(4)).
Comments. A substantial number of commenters supported removing the
requirements for randomized surveillance. Many commenters supported the
proposal to revise Sec. 170.556(c) by changing the requirement that
ONC-ACBs must conduct in-the-field, randomized surveillance to specify
that ONC-ACBs may conduct in-the-field, randomized surveillance,
including the removal of Sec. 170.556(c)(2). Commenters noted that
since ONC-ACBs would still be required to perform reactive
surveillance, and would be permitted to conduct randomized surveillance
of their own accord, the regulatory requirement to conduct randomized
surveillance on a specified portion of certified health IT would be
unnecessary. Commenters supporting this proposal praised the
deregulatory action as allowing more flexibility for ONC-ACBs. A number
of commenters were generally supportive of the proposal and applied the
caveat that if an ONC-ACB did voluntarily conduct randomized
surveillance, they should not do so repeatedly on the same Health IT
Module. These commenters indicated a preference that the requirements
in Sec. 170.556(c)(6) regarding the consecutive selection of certified
health IT for randomized surveillance remain. Several commenters were
supportive of removing randomized surveillance requirements and
indicated they found this appropriate in view of the Conditions and
Maintenance of Certification enhancements to the Program as directed by
the Cures Act, while others noted that reactive surveillance may be
more effective in surfacing and correcting non-conformities. A number
of commenters did not support the proposal, with many expressing
concerns that this could be or be perceived to be a reduction in
oversight of developers or could reduce providers' confidence that
certified Health IT Modules would meet their needs. While a majority of
commenters speaking to surveillance burdens on health care providers
indicated the removal of mandatory randomized surveillance would, on
the whole, reduce burden on health care providers, several expressed
concerns about whether providers can discern when a product does not
meet certification requirements or know where and how to report their
concerns about their certified health IT's conformance to Program
requirements. A few commenters suggested that the increased emphasis on
reactive surveillance (particularly in some commenters' view because
ONC is removing randomized surveillance requirements in advance of the
full implementation of the EHR Reporting Program called for by section
4002 of
[[Page 25655]]
the Cures Act) indicates a need for additional guidance to help
providers and particularly clinicians understand how to recognize and
report potential non-conformities in the certified health IT they use.
Response. We thank commenters for their input and reiterate our
continued commitment to sustaining the integrity of our Program,
including ensuring robust oversight of certified health IT products
while avoiding unnecessary burdens on all program stakeholders. Having
considered all comments received, in context of the totality of updates
we proposed to the Program, we have concluded that the removal of the
regulatory requirements for ONC-ACBs to conduct randomized surveillance
is consistent with enhancing Program efficiency while maintaining its
efficacy. We leave ONC-ACBs the option to conduct randomized
surveillance as they determine necessary or appropriate to support
continued conformance to Program requirements by Health IT Modules they
have certified. We also note that ONC-ACBs that choose to conduct
randomized surveillance will still be required to use the methodology
identified by ONC with respect to scope (Sec. 170.556(c)(1)),
selection method (Sec. 170.556(c)(3)), and the number and types of
locations for in-the-field surveillance (Sec. 170.556(c)(4)). While we
appreciate concerns that removal of requirements in Sec. 170.556(c)(6)
regarding the consecutive selection of certified health IT creates a
potential that the same Health IT Module(s) could be selected for
randomized surveillance in consecutive years, we are unaware of
evidence suggesting that ONC-ACBs choosing to implement randomized
surveillance would do so in a manner that would tend to erode its
efficacy by over-sampling some products at the expense of under-
sampling others. Rather than retain a regulatory provision intended to
counterbalance a regulatory requirement for randomized surveillance of
a required minimum percent of certified products each year, we believe
it is more appropriate at this time to remove the restriction on
consecutive selection of the same Health IT Module(s) or location(s)
for randomized surveillance and monitor the results of this and other
Program enhancements finalized in this rule for any indication that we
may need to further adjust regulatory requirements in the future.
We thank commenters for bringing to our attention that health care
providers may be uncertain about how or where they can engage the ONC
Health IT Certification Program for assistance when the certified
health IT they rely on is not performing its certified functions as
they expect and their health IT developer is unresponsive or fails to
resolve non-conformities with Program requirements. Reactive
surveillance by ONC-ACBs, informed and focused by end-user complaints,
has always been an essential component of the Program's oversight and
assurance of continued conformity of certified Health IT Modules when
deployed in the field. While we encourage users to begin seeking
troubleshooting and issue resolution support from the developer of
their health IT--because the developer is often in the best position to
act most promptly to resolve problems with their products'
performance--we also encourage the user to share their concerns with
the ONC-ACB that certified the health IT in question when the developer
has not addressed users' concerns that their certified health IT is not
performing as it is certified to perform. As we recognize that users
may in some circumstances need, or for purposes potentially including
but not limited to their own preferences may wish, to share their
concerns about their certified health IT's performance or other health
IT matters directly with ONC, we invite health IT users and all other
interested parties to share their health IT-related feedback or
concerns with ONC through the Health IT Feedback Form on our
HealthIT.gov website.\15\ Depending on the nature of a specific
feedback message, we may contact the submitter for additional
information and, in some instances, may share the information provided
with other appropriate entities--such as but not limited to the ONC-
ACBs who certify the products about which we receive feedback, as they
are often in the best position to assess and respond to feedback
expressing concerns about conformance of specific certified criteria
used by Health IT Modules in production environments. All information
submitted through the Health IT Feedback Form is carefully reviewed and
helps us to improve our awareness and ability to address health IT-
related issues and challenges. Also, we note for clarity that persons
sharing health IT-related concerns with ONC via the Health IT Feedback
Form have the option to remain anonymous and this option has been
chosen by some submitters. However, we wish to note that anonymous
submissions will prevent us from acquiring additional information to
fully follow up on a matter if the submission does not include
sufficient detail on which to act. In general, submitters should
provide as much detail as possible about the developer, product name,
and version of the certified health IT as well as their specific
concerns about the certified health IT's performance.
---------------------------------------------------------------------------
\15\ https://www.healthit.gov/form/healthit-feedback-form.
---------------------------------------------------------------------------
2. Removal of the 2014 Edition From the Code of Federal Regulations
In the March 4, 2019 Proposed Rule, we also proposed to remove the
2014 Edition from the Code of Federal Regulations (CFR), which includes
standards and functionality now significantly outmoded (84 FR 7434). We
noted that removal of the 2014 Edition would make the 2015 Edition the
new baseline for health IT certification. The 2015 Edition, including
the additional certification criteria, standards, and requirements
adopted in this final rule, will better enable interoperability and the
access, exchange, and use of electronic health information, as
discussed in the Proposed Rule (84 FR 7434), and its adoption and
implementation by providers is expected to yield the estimated costs
savings described (84 FR 7563 and 7564) within the Regulatory Impact
Analysis (section XIV) of the Proposed Rule and in the Regulatory
Impact Analysis section (section XIII) of this final rule.
To implement the removal of the 2014 Edition from the CFR, we
proposed (84 FR 7434 and 7435) to remove the 2014 Edition certification
criteria (Sec. 170.314) and related standards, terms, and requirements
from the CFR. In regard to terms, we proposed to retire the 2014
Edition-related definitions found in Sec. 170.102, including the
``2014 Edition Base EHR,'' ``2014 Edition EHR certification criteria,''
and ``Complete EHR, 2014 Edition.'' As explained in the 2015 Edition
final rule (80 FR 62719), the ability to maintain Complete EHR
certification is only permitted with health IT certified to the 2014
Edition certification criteria. Because this concept was discontinued
for the 2015 Edition, we proposed (84 FR 7435) to remove Sec. 170.545
and any references to Complete EHR from the regulation text in
conjunction with the removal of the 2014 Edition. We also proposed (84
FR 7435) to remove references to the 2014 Edition from the Common
Clinical Data Set (CCDS) definition and effectively replace it with a
new government-unique standard, the United States Core Data for
Interoperability (USCDI). We proposed (84 FR 7435) to remove the
standards and implementation specifications found in Sec. Sec.
170.200, 170.202, 170.204, 170.205, 170.207, 170.210, and 170.299 that
are only
[[Page 25656]]
referenced in the 2014 Edition certification criteria. Adopted
standards that are also referenced in the 2015 Edition would remain.
Finally, we proposed (84 FR 7435) to remove requirements in Sec.
170.550(f) and any other requirements in subpart E, Sec. Sec. 170.500
through 170.599, which are specific to the 2014 Edition and do not
apply to the 2015 Edition.
As discussed in the Proposed Rule (84 FR 7435), in order to avoid
regulatory conflicts, we took into consideration the final rule
released by CMS on November 16, 2017, titled ``Medicare Program; CY
2018 Updates to the Quality Payment Program; and Quality Payment
Program: Extreme and Uncontrollable Circumstance Policy for the
Transition Year'' (82 FR 53568). This Quality Payment Program (QPP)
final rule permits eligible clinicians to use EHR technology certified
to either the 2014 or 2015 Edition certification criteria, or a
combination of the two for the CY 2018 performance period. This QPP
final rule also states that the 2015 Edition certified EHR technology
(CEHRT) will be required starting with the CY 2019 QPP program year (82
FR 53671). Therefore, we proposed (84 FR 7435) the effective date of
removal of the 2014 Edition certification criteria and related
standards, terms, and requirements from the CFR would be the effective
date of this final rule.
Comments. The majority of the comments received supported removing
the 2014 Edition certification criteria from the Code of Federal
Regulations. Commenters supporting the removal noted that it will
reduce confusion and acknowledges that standards and functionality in
the 2014 Edition are now significantly outmoded. Some commenters
requested the removal be delayed until the end of CY 2019.
Response. We thank commenters for their support. We have finalized
the removal of the 2014 Edition from the CFR as proposed, including
making the removal effective as of the effective date of this final
rule (60 days after the rule is published in the Federal Register). The
2015 Edition was the sole edition permitted to meet the CEHRT
definition beginning in the CY 2019 program year. This final rule is
published in CY 2020. Therefore, the removal is not in conflict with
CMS' regulatory requirements for QPP.
To finalize removal of the 2014 Edition from the CFR, we have
removed, effective as of the effective date of this final rule, the
2014 Edition certification criteria in Sec. 170.314. We also finalized
removal of terms and definitions specific to the 2014 Edition from
Sec. 170.102, including the ``2014 Edition Base EHR,'' ``2014 Edition
EHR certification criteria,'' and ``Complete EHR, 2014 Edition''
definitions. As explained in the 2015 Edition final rule (80 FR 62719),
the ``Complete EHR'' concept was discontinued for the 2015 Edition.
Therefore, in conjunction with the removal of the 2014 Edition, we also
remove in this final rule Sec. 170.545 and all other references to
``Complete EHR'' from the regulation text. Moreover, in finalizing the
removal of the 2014 Edition from the CFR, we also finalize removal of
the standards and implementation specifications found in Sec. Sec.
170.200, 170.202, 170.204, 170.205, 170.207, 170.210, and 170.299 that
are referenced only in the 2014 Edition certification criteria. Adopted
standards that are also referenced in the 2015 Edition, as modified by
this final rule, remain in the CFR. We also retained the CCDS
definition in Sec. 170.102 but removed the standards and
implementation specifications that reference the 2014 Edition.
Additionally, we finalized the removal of requirements in Sec.
170.550(f) and any other requirements in subpart E, Sec. Sec. 170.500
through 170.599, that are specific to the 2014 Edition and do not apply
to the 2015 Edition.
3. Removal of the ONC-Approved Accreditor From the Program
We proposed to remove the ONC-AA from the Program (84 FR 7435). The
ONC-AA's role is to accredit certification bodies for the Program and
to oversee the ONC-ACBs. However, years of experience and changes with
the Program have led ONC to conclude that, in many respects, the role
of the ONC-AA to oversee ONC-ACBs is now duplicative of ONC's
oversight. More specifically, ONC's experience with administering the
Principles of Proper Conduct (PoPC) for ONC-ACBs as well as issuing
necessary regulatory changes (e.g., ONC-ACB surveillance and reporting
requirements in the 2015 Edition final rule) has demonstrated that ONC
on its own has the capacity to provide the appropriate oversight of
ONC-ACBs. Therefore, we believe removal of the ONC-AA will reduce the
Program's administrative complexity and burden.
Comments. All but one commenter specifically addressing this
proposal were in support of removing the ONC-AA. The one commenter
opposed to the proposal stated concerns related to de-coupling
accreditation to ISO/IEC 17065 standards (an internationally recognized
standard for bodies certifying products, processes, and services to
provide assurance of compliance with specified requirements such as
initial testing, inspection, and quality management systems) from
specific assessment of a certification body's ability to apply their
accredited ISO/IEC 17065 capabilities to the Program's certification
scheme requirements. The commenter noted that this might place a
greater burden on ONC staff than did the Program structure that
included an ONC-AA. Finally, one of the commenters in support of
removing the ONC-AA from the Program requested additional clarification
about criteria and processes that will be used for accreditation of
certification bodies following removal of the ONC-AA from the Program.
Response. We thank all commenters for their thoughtful feedback.
Upon consideration of all comments received on this proposal, we have
finalized it as proposed. As noted in the preamble to the Proposed Rule
(84 FR 7435), ONC's experience with administering the PoPC for ONC-ACBs
as well as issuing necessary regulatory changes (e.g., ONC-ACB
surveillance and reporting requirements in the 2015 Edition final rule)
has demonstrated that ONC on its own has the capacity to provide the
appropriate oversight of ONC-ACBs. Therefore, we believe removal of the
ONC-AA will reduce the Program's administrative complexity and burden
while maintaining its effectiveness. We anticipate providing updated
information about ONC's updated processes for approval and oversight of
certification bodies through familiar mechanisms including but not
necessarily limited to the HealthIT.gov website prior to the effective
date of this final rule, and on an ongoing basis as needed or otherwise
appropriate to ensure effective transparency about this aspect of the
Program.
To finalize this deregulatory action, we have removed the
definition for ``ONC-Approved Accreditor or ONC-AA'' from Sec.
170.502. We also removed Sec. Sec. 170.501(c), 170.503, and 170.504
regarding requests for ONC-AA status, ONC-AA ongoing responsibilities,
and reconsideration for requests for ONC-AA status. Regarding
correspondence and communication with ONC, we have revised Sec.
170.505 to remove specific references to the ``ONC-AA'' and
``accreditation organizations requesting ONC-AA status.'' We also have
finalized our proposal to sunset the policies reflected in the final
rule titled ``Permanent Certification Program for Health Information
Technology; Revisions to ONC-Approved Accreditor Processes'' (76 FR
72636), and to remove Sec. 170.575, which established a process for
addressing instances where the ONC-AA engages in improper conduct or
does not perform its
[[Page 25657]]
responsibilities under the Program. Because the regulations promulgated
in this prior final rule relate solely to the role of the ONC-AA, we
have finalized the removal of those requirements. Accordingly, we also
revised the application process for ONC-ACB status in Sec.
170.520(a)(3) to require documentation, with an appropriate scope, that
confirms that the applicant has been accredited to ISO/IEC 17065 by any
accreditation body that is a signatory to the Multilateral Recognition
Arrangement (MLA) with the International Accreditation Forum (IAF), in
place of the ONC-AA accreditation documentation requirements.
Similarly, instead of requiring the ONC-AA to evaluate the conformance
of ONC-ACBs to ISO/IEC 17065, we revise Sec. 170.523(a) to simply
require ONC-ACBs to maintain accreditation in good standing to ISO/IEC
17065. This means that ONC-ACBs would need to continue to comply with
ISO/IEC 17065 and requirements specific to the ONC Health IT
Certification Program scheme.
4. Removal of Certain 2015 Edition Certification Criteria and Standards
Having reviewed and analyzed the 2015 Edition, we proposed to
remove certain certification criteria and standards as discussed in the
Proposed Rule (84 FR 7435 through 7437) and below. We stated (84 FR
7435) that we believe the removal of these criteria and standards will
reduce burden and costs for health IT developers and health care
providers by eliminating the need to: Design and meet specific
certification functionalities; prepare, test, and certify health IT in
certain instances; adhere to associated reporting and disclosure
requirements; maintain and update certifications for certified
functionalities, and participate in routine surveillance (84 FR 7435).
Although we did not expressly state it in the Proposed Rule preamble,
the burdens and costs reduced by removal of certain criteria from the
2015 Edition would be those associated with the needs we discussed in
the preamble (84 FR 7435) specifically in connection to the criteria we
proposed to remove, which are those that had been set forth in Sec.
170.315(a)(6), (7) and (8), (10) and (11), and (13), (b)(4) and (5),
and (e)(2) (as the text of 45 CFR part 170 stood prior to this final
rule).
a. 2015 Edition Base EHR Definition Certification Criteria
We proposed to remove certain certification criteria from the 2015
Edition that had been included in the 2015 Edition Base EHR definition.
As discussed in the preamble to the Proposed Rule (84 FR 7435), the
removal of these criteria supports burden and cost reductions for
health IT developers and health care providers by eliminating the need
to: Design and meet these specific certification functionalities;
prepare, test, and certify health IT in certain instances; adhere to
associated reporting and disclosure requirements; maintain and update
certifications for these specific certified functionalities; and
participate in surveillance of health IT certified to these criteria
and standards.
i. Problem List
We proposed to remove the 2015 Edition ``problem list''
certification criterion (Sec. 170.315(a)(6)) from the 2015 Edition (84
FR 7436). As we noted in the Proposed Rule, the functionality in this
criterion was first adopted as a 2011 Edition certification criterion
to support the associated meaningful use Stage 1 objective and measure
for recording problem list information. This 2015 Edition ``problem
list'' criterion functionally remains relatively the same as the 2011
Edition and has exactly the same functionality as the 2014 Edition
``problem list'' criterion. We proposed to remove this criterion
because the criterion no longer supports the ``recording'' objective
and measure of the CMS PI Programs as such objective and measure no
longer exist.\16\ Additionally, we stated the functionality is
sufficiently widespread among health care providers since it has been
part of certification and the Certified EHR Technology definition since
the 2011 Edition and has not substantively changed with the 2015
Edition. Furthermore, we stated in the Proposed Rule that the
functionality is essential to clinical care and would be in EHR systems
absent certification, particularly considering the limited
certification requirements.
---------------------------------------------------------------------------
\16\ By stating in the NPRM that the objective and measure no
longer exist, we meant in the CMS PI (formerly EHR Incentive)
Programs. The authority citation for this statement is the December
15, 2015 CMS Final Rule ``Medicare and Medicaid Programs; Electronic
Health Record Incentive Program-Stage 3 and Modifications to
Meaningful Use in 2015 Through 2017'' (80 FR 62761 and 62785).
---------------------------------------------------------------------------
Comments. A number of commenters expressed support for removing the
``problem list'' certification criterion from the 2015 Edition and
``Base EHR'' definition. Several of those expressing support for the
removal of this criterion specifically noted that the inclusion of the
same data elements in the USCDI should suffice to ensure continued
ability of certified health IT to record and facilitate access and
exchange of these data. However, a few commenters expressed concern
that removing this and other requirements would be a disincentive to
maintain the functionality in the future, and some commenters expressed
concern about ONC's ability to continue to provide effective oversight
and require correction if developers do not ensure the functionalities
perform safely and effectively. Commenters stated that while many
developers will still continue to support the functionalities proposed
for removal, eliminating the certification requirement may allow for
developers to provide a ``stripped-down'' product at a lower price
point and, in absence of CEHRT definition to guide the providers,
mislead independent and small providers into unwittingly acquiring
certified health IT that does not fully meet their needs.
Response. As discussed in the preamble to the Proposed Rule, a
criterion specific to the ``problem list'' functionality was first
adopted in the 2011 Edition, specifically to ensure support for the
associated meaningful use Stage 1 objective and the measure for
recording problem list information under the CMS PI Programs. The
``recording'' objective and measure is no longer a part of the CMS PI
Programs. However, the functionality remains widespread among EHR
systems used by health care providers. While this prevalence may be due
in part to its inclusion in the Certified EHR Technology definition,
without substantive changes, since the 2011 Edition, we believe the
more significant reason that this functionality is widely available is
because it is essential to clinical care, and therefore, that the
market will and should drive its continued presence in EHR systems
regardless of certification requirements. While we also appreciate the
concerns of commenters about the need for health IT to support the
accurate recording of patients' problems and the standards-based
exchange of that information, we reiterate that the interoperability-
focused criteria that will remain in the Base EHR definition and
reference the USCDI will ensure that any system of certified health IT
meeting the Base EHR definition is capable of using and exchanging data
on a patient's problems using content, format, and other standards
applicable to each mode of exchange (e.g., standardized API and C-CDA).
Moreover, these interoperability-focused criteria will be subject not
only to the Program's familiar initial certification testing and in-
the-field reactive surveillance requirements but also to the new
Condition and
[[Page 25658]]
Maintenance of Certification requirements for developers to test
annually their certified Health IT Modules' interoperability
performance in the types of real world settings for which they are
sold.
After consideration of all comments received, and for the reasons
noted in the preamble to the Proposed Rule and above, we have finalized
the removal of the ``problem list'' certification criterion (Sec.
170.315(a)(6)). We further note that upon the effective date of this
final rule, the ``problem list'' certification criterion is removed
from the 2015 Edition and the criterion will no longer be included in
the 2015 Edition ``safety-enhanced design'' criterion. This criterion,
in Sec. 170.315(g)(3), specifies the user-centered design testing that
must be applied to particular EHR functionality submitted for
certification. However, in response to specific commenters' concerns
about the impact of removing the functionally-based problem list
criterion on our ability to take action where developers may retain the
functionality, but fail to ensure it does not pose a danger to patient
safety or public health, we note that our responsibility, pursuant to
section 3001(b) of the PHSA, includes ensuring certified health IT does
not pose a risk to patient safety or public health, and is not limited
to measuring the conformity of the health IT to specific certification
criteria. As discussed in the ``ONC Health IT Certification Program:
Enhanced Oversight and Accountability'' (EOA) rule which was proposed
in 81 FR 11056, and finalized in 81 FR 72404 in 2016, ONC has the
authority to address suspected or confirmed non-conformities to the
requirements under the ONC Health IT Certification Program if the
certified health IT is causing or contributing to serious risks to
public health or safety (81 FR 72406). The EOA final rule established
in Sec. 170.580 a regulatory framework for ONC's direct review of
health IT certified under the Program, which expressly addresses the
potential for ONC to initiate direct review if we have a reasonable
belief that certified health IT may not conform to the requirements of
the Program because the certified health IT may be causing or
contributing to conditions that present a serious risk to public health
or safety.
With respect to health care providers' selection of certified
health IT products, we would encourage all providers to consider the
Base EHR or Certified EHR Technology (CEHRT) definition as a useful
starting point. Certain health care payment programs, including the CMS
PI Programs, require the use of certified health IT. CMS refers to the
minimum set of required certification functionalities that the health
IT used by eligible clinicians must have in order to qualify for the
CMS incentive programs as CEHRT.
Using certified health IT improves care coordination through the
electronic exchange of clinical-care documents. It provides a baseline
assurance that the technology will perform clinical-care and data-
exchange functions in accordance with interoperability standards and
user-centered design.
ii. Medication List
We proposed to remove the 2015 Edition ``medication list''
certification criterion (Sec. 170.315(a)(7)) (84 FR 7436). As we noted
in the Proposed Rule, the 2015 Edition ``medication list'' criterion
remains functionally the same as the 2011 Edition and 2014 Edition
``medication list'' criteria. As also discussed in the Proposed Rule, a
functionally-based ``medication list'' criterion was first adopted as a
2011 Edition certification criterion to support the associated
meaningful use Stage 1 objective and measure for recording medication
list information. The ``medication list'' criterion that we proposed to
remove does not require use of a specific vocabulary standard to record
medications.
Comments. Comments on the proposal to remove the ``medication
list'' criterion were somewhat mixed. While a number of comments
expressed support for the removal of the ``medication list'' criterion
from the 2015 Edition as duplicative of medication data included in the
USCDI a number of commenters expressed concerns with, and a few
commenters indicated opposition to, the removal of the ``medication
list'' criterion. A few commenters raised concerns specific to
elimination of the ``medication list'' criterion in view of the need to
respond to the opioids crisis. One commenter expressed concern in the
context of both the medication list and the drug-formulary and
preferred drug lists criteria as to whether the removal of these
criteria could potentially impact patients' drug costs. Several
comments also expressed the same concerns for eliminating the
``medication list'' that were expressed in regard to removal of the
``problem list'' criterion, which are summarized above, regarding
whether developers will continue to include the functionality and
maintain its safe performance.
Response. We thank commenters for their input. Upon consideration
of all comments received on this proposal, we have finalized the
removal of the ``medication list'' criterion (Sec. 170.315(a)(7)). The
``recording'' objective and measure of the CMS PI Programs that the
``medication list'' criterion was originally adopted to support has
since been retired from the CMS Programs. However, the functionality
remains widespread among EHR systems used by health care providers.
While this prevalence may be due in part to its inclusion in the
Certified EHR Technology definition since the 2011 Edition, we believe
this functionality is widely available and used in more significant
part because it is essential to clinical care and, therefore, the
market will and should drive its continued presence in EHR systems
regardless of certification requirements. While we also appreciate the
concerns of commenters about the need for health IT to support
clinicians' ability to access, maintain, use, and exchange accurate and
up-to-date information on their patients' current medication lists and
medication history, we repeat for clarity and emphasis that the
interoperability-focused criteria that will remain in the Base EHR
definition, and their inclusion of the USCDI, will ensure that any
system of certified health IT meeting the Base EHR definition is
capable of using and exchanging data on a patient's medications using
content, format, and other standards applicable to each mode of
exchange (e.g., standardized API consistent with Sec. 171.315(g)(10),
or exchange of C-CDA documents using the transport standards and other
protocols in Sec. 171.202). We recognize the critical importance of
providers' and patients' ability to have, use, and exchange medications
information to avoid harms that can arise from interactions and
duplications of therapeutic effects amongst newly prescribed drugs and
those the patient may already be taking. While the clinical importance
of maintaining and referencing current, reconciled medication lists is
not limited to those medications with significant risks of misuse or
dependency, we agree that it is highlighted by the urgent need to
ensure opioids are prescribed and used only with due care when
clinically necessary. We believe this clinical importance supports the
expectation that the market will ensure this functionality is
maintained and will drive innovations that improve its usability for
the clinicians who use it in the course of caring for their patients.
Moreover, the inclusion of medication information in interoperability-
focused criteria in Sec. 170.405(a) will ensure certified health IT
can access, use, and exchange medications data according to
[[Page 25659]]
applicable content and formatting standards, which the ``medication
list'' functionality did not ensure. This interoperability of the data
is critical to reducing clinician burden related to manually entering
updated drug lists and necessary to enable use of medication
information by clinical decision support functionalities. The
interoperability-focused criteria will also be subject not only to the
Program's familiar initial certification testing and in-the-field
reactive surveillance requirements but also to the new Condition and
Maintenance of Certification requirements for developers to test
annually their certified Health IT Modules' interoperability
performance in the types of real world settings for which they are
marketed.
We note that once removed from the 2015 Edition, the criterion will
no longer be included in the 2015 Edition ``safety-enhanced design''
criterion in Sec. 170.315(g)(3). However, as noted above in context of
the ``problem list'' criterion, ONC's responsibility, pursuant to
section 3001(b) of the PHSA, includes ensuring certified health IT does
not pose a risk to patient safety or public health. Our responsibility
for certified health IT and patient safety or public health is not
limited to measuring the conformity of the health IT to specific
certification criteria. As discussed in the EOA rule, ONC has the
authority to address suspected or confirmed non-conformities to the
requirements under the Health IT Certification Program if the certified
health IT is causing or contributing to serious risks to public health
or safety (81 FR 72406). The EOA final rule established in Sec.
170.580 a regulatory framework for ONC's direct review of health IT
certified under the Program, which expressly addresses the potential
for ONC to initiate direct review if we have a reasonable belief that
certified health IT may not conform to the requirements of the Program
because the certified health IT may be causing or contributing to
conditions that present a serious risk to public health or safety.
iii. Medication Allergy List
We proposed to remove the 2015 Edition ``medication allergy list''
certification criterion (Sec. 170.315(a)(8)). The functionality in
this criterion was first adopted as a 2011 Edition certification
criterion to support the associated meaningful use Stage 1 objective
and measure for recording medication allergies information. The
criterion does not require use of a vocabulary standard to record
medication allergies, and does not directly support interoperability as
the criterion does not require representation of medication allergies
in standardized nomenclature. The criterion no longer supports a
``recording'' objective and measure of the CMS PI Programs as such
objective and measure no longer exist. This 2015 Edition ``medication
allergy list'' criterion remains functionally the same as the 2011
Edition and 2014 Edition ``medication allergy list'' criteria. The
functionality is essential to clinical care and would be in EHR systems
absent certification.
Comments. Comments on the proposed removal of the ``medication
allergy list'' criterion were mixed, with several commenters supportive
of the removal noting that the criterion would be redundant now that
medication allergy data will be included in the USCDI. Commenters
expressed concern with the removal of the criterion and questioned the
ubiquity of the medication allergy list functionality and whether
health IT developers would continue to support the functionality if not
required by ONC regulations.
Response. We thank commenters for their input. Upon consideration
of all comments received on this proposal, we have finalized the
removal of the ``medication allergy list'' certification criterion
(Sec. 170.315(a)(8)). The ``recording'' objective and measure of the
CMS PI Programs that this criterion was originally adopted to support
has since been retired from the CMS Programs. However, the
functionality remains widespread among EHR systems. While this
prevalence may be due in part to its inclusion in the Certified EHR
Technology definition since the 2011 Edition, its importance to
clinical care suggests the market will drive ongoing availability and
enhancement of this functionality over time. Furthermore, because
medication allergies are included in the USCDI, all systems of
certified health IT meeting the Base EHR definition will be required to
be able to exchange and use medication allergy information according to
applicable content and formatting standards, which the ``medication
allergies'' criterion did not ensure. This interoperability is critical
to reducing clinician burden related to manually entering updated drug
lists and necessary to enable use of medication information by clinical
decision support functionalities. We believe that requiring the
interoperability of medication allergy information will facilitate
innovation and improvement in health IT's ability to meet clinicians'
and patients' needs more than would the continuation of the
``medication allergies'' functionally-based criterion.
We note that once removed from the 2015 Edition, the ``medication
allergy list'' criterion will also no longer be included in the 2015
Edition ``safety-enhanced design'' criterion. However, as noted in
context of removed criteria above, ONC's responsibility, pursuant to
section 3001(b) of the PHSA includes ensuring certified health IT does
not pose a risk to patient safety or public health. Our responsibility
for certified health IT and patient safety or public health is not
limited to measuring the conformity of the health IT to specific
certification criteria. As discussed in the EOA rule, ONC has the
authority to address suspected or confirmed non-conformities to the
requirements under the Health IT Certification Program if the certified
health IT is causing or contributing to serious risks to public health
or safety (81 FR 72406). The EOA final rule established in Sec.
170.580 a regulatory framework for ONC's direct review of health IT
certified under the Program, which expressly addresses the potential
for ONC to initiate direct review if we have a reasonable belief that
certified health IT may not conform to the requirements of the Program
because the certified health IT may be causing or contributing to
conditions that present a serious risk to public health or safety.
iv. Smoking Status
We proposed to remove the 2015 Edition ``smoking status'' criterion
(Sec. 170.315(a)(11)), which would include removing it from the 2015
Edition Base EHR definition (84 FR 7436). We had previously adopted a
2015 Edition ``smoking status'' certification criterion that does not
reference a standard. However, the CCDS definition, which we proposed
to remove from regulation in favor of adopting the new USCDI standard,
required smoking status to be coded in accordance with a standard value
set of eight SNOMED CT[supreg] codes defined in Sec. 170.207(h). As
with other functionality that was included in 2014 Edition, we believe
this functionality is now widespread. Further, smoking status data will
continue to be required to be available for access and exchange via the
USCDI.
Comments. Comments on this proposal were mixed, with a number of
commenters expressing support for the removal of ``smoking status''
criterion in the Program and several noting that it is not needed or
duplicative in the context of Program requirements to support the
USCDI. A few commenters stated concerns that eliminating the
requirement would provide a
[[Page 25660]]
disincentive for developers to maintain the function in the future.
Several commenters expressing concerns about removal of this criterion
noted its importance to patient care and to public health, raising
points such as the use of smoking status as a key determinant to
classify cases of some reportable conditions, such as carbon monoxide
poisoning. Concerns raised by commenters opposed to removing smoking
status data from providers' EHR systems included potential for
additional provider burden, such as that related to providing complete
case reporting data and responding to public health requests for
additional information on patient smoking status during case
investigation processes.
Response. We thank commenters for their input. Upon consideration
of the comments, we have finalized the removal of the ``smoking
status'' criterion (Sec. 170.315(a)(11)). While we continue to believe
that accurate, up-to-date information on a patient's smoking status and
history has significant clinical value, we believe that its importance
to clinical care provides adequate motivation for the market to drive
ongoing availability and enhancement of this functionality over time.
Because smoking status information is included in the USCDI, all
systems of certified health IT meeting the Base EHR definition will now
be required to be able to exchange and use smoking status information
according to applicable content and formatting standards. The ``smoking
status'' recording functionality criterion we have removed did not
ensure smoking status information was captured in a structured,
interoperable manner and interoperability of this data is critical to
reducing clinician burden related to maintaining complete, current
smoking status information. It is also necessary to enable use of
smoking status information by clinical decision support and public
health reporting functionalities. We believe that interoperability and
exchange of smoking status information through the interoperability-
focused certification criteria that reference the USCDI standard will
better facilitate innovation and improvement in health IT's ability to
meet clinicians' and patients' needs than would continuation of the
``smoking status'' functionally-based recording criterion.
Removal of Specific USCDI Smoking Status Code Set
Along with the ``smoking status'' criterion, we proposed to remove
the requirement to code smoking status according to the eight smoking
status SNOMED CT[supreg] codes referenced in the value set adopted in
Sec. 170.207(h). These eight codes reflected an attempt to capture
smoking status in a consistent manner. Stakeholder feedback indicated
that these eight codes do not appropriately and accurately capture all
clinically relevant patient smoking statuses. Accordingly, we proposed
to no longer require use of only the specific eight SNOMED CT[supreg]
codes for representing smoking status and remove the value set standard
by deleting and reserving Sec. 170.207(h).
Comments. Comments specifically addressing this proposal were
generally supportive of removing the specific value set of eight SNOMED
CT[supreg] codes, though many also noted the importance of continuing
to require health IT certified under the Program to retain the ability
to include or access, exchange, and use appropriately standardized
smoking status information. Several comments made specific suggestions
related to broadening or revising the vocabulary standard requirements
for smoking status information going forward. Other commenters
suggested adding other forms of tobacco use, including smokeless and
second hand, as well as e-cigarette (vaping) use.
Response. We appreciate all commenters' input and note that no
comments received raised concerns that are not addressed by inclusion
of smoking status information in the USCDI, which all interoperability-
focused criteria within the 2015 Edition Base EHR definition, as
revised through this final rule, reference. As is the case with patient
problems, medications, and medication allergies, we believe having
smoking status information available for standards-based exchange is an
important facilitator of better care and more effective public health
reporting with less data-related burden on clinicians and less need for
follow-up by public health professionals to compensate for case
reporting data that is incomplete or is not fully interoperable. As is
the case with the other removed criteria that were focused on internal
recording capabilities, we believe the market can, will, and should be
the primary driver for the ongoing maintenance and enhancement of
functionalities for end users to record or modify these data.
Furthermore, the Program's focus is more appropriately spent on
ensuring that certified health IT supports interoperable access, use,
and exchange of these data as the key facilitator for more coordinated
patient care and for ongoing innovation and improvement in both
provider- and patient-facing functionalities. Because comments on
revisions or enhancements to smoking status data standardization moving
forward are outside the scope of this section, we will not address them
in specific detail here. However, we note that the USCDI v1 references
as the standard for smoking status information SNOMED CT[supreg], U.S.
Edition.\17\
---------------------------------------------------------------------------
\17\ For more information on finalized policy regarding adoption
of the USCDI standard, see section IV.B.1 of this final rule. USCDI
v1 can be accessed freely and directly in its entirety at https://www.healthit.gov/isa/sites/isa/files/inline-files/USCDIv12019revised2.pdf.
---------------------------------------------------------------------------
Having considered all comments received on this proposal, we have
finalized the removal of the eight-code value set standard and removed
and reserved Sec. 170.207(h).
b. Drug-Formulary and Preferred Drug List Checks
We proposed to remove the 2015 Edition ``drug-formulary and
preferred drug list checks'' criterion in Sec. 170.315(a)(10).
Comments. Some commenters expressed concern that this criterion's
removal could negatively impact prescribers' ability to help their
patients manage their prescription drug expenses. Although several
commenters supported the removal of this criterion in principle, a
number of comments expressed concerns about the effect of removal of
the ``drug-formulary and preferred drug list checks'' and other
criteria from the Program on health care providers' ability to comply
with CMS and State-specific regulatory requirements for successful
participation in the Medicare Quality Payment Program (QPP), or the
Medicare or Medicaid PI Programs. One commenter, noting that the Drug-
Formulary and Preferred Drug List Checks criterion is associated with
the CMS e-prescribing objective measures that CMS has finalized for
2019 and subsequent performance years specifically, recommended
coordination with CMS to ensure alignment across the policies
maintained by these two components of HHS.
Response. We thank commenters for their input. As discussed in the
Proposed Rule (84 FR 7437), the 2015 Edition ``drug-formulary and
preferred drug list checks'' criterion does call for functionality to
check drug formulary and preferred drug lists, but does not require use
of any specific interoperability standards. The 2015 Edition ``drug-
formulary and preferred drug list checks'' criterion does not include
functionality or advance interoperability beyond what was required by
the 2014 Edition ``drug-formulary checks'' criterion. While we
[[Page 25661]]
believe this functionality is fairly ubiquitous now due in part to the
widespread adoption of health IT certified to the 2014 Edition, we do
not believe it is necessary to continue to require certification to it
under the Program in order to ensure it remains widely available.
Instead, we believe, prescribers' and patients' interest in assuring
patients can get the medications they need at the best available value
will provide adequate motivation for the market to drive ongoing
availability and enhancement of this functionality over time, including
through increasing use of relevant interoperability standards essential
to making this functionality more affordable and seamlessly reliable at
scale than is feasible in the absence of interoperability driven by
ubiquitous use of open standards. Because the ``drug-formulary and
preferred drug list checks'' criterion we proposed to remove does not
require use of standards or directly drive interoperability, we do not
believe its continued inclusion in the Program would provide sufficient
value to providers or patients to justify the burden on developers and
providers of meeting Program compliance requirements specific to this
criterion. We also recognize the importance of ensuring alignment
between ONC Health IT Certification Program regulations and the CMS
regulations that reference them. We have been and will continue to work
in close partnership with our CMS colleagues to ensure that our
regulations remain aligned, and that we provide affected stakeholders
with the information they need to understand how the rules work
together and how to succeed under CMS' PI Programs using health IT
certified under ONC's Program. We, therefore, permit ONC-ACBs to issue
certificates for this criterion up until January 1, 2022 to align with
the requirements of the CMS Medicaid PI Program, as this criterion is
associated with measures under the Medicaid program that will continue
through 2021; after 2021 there will be no further incentives under the
Medicaid Promoting Interoperability Program (84 FR 42592). We have not
finalized our proposal to remove the criterion from the CFR but
included a provision in Sec. 170.550(m)(1) to only allow ONC-ACBs to
issue certificates for this criterion until January 1, 2022.
c. Patient-Specific Education Resources
We proposed to remove the 2015 Edition ``patient-specific education
resources'' certification criterion in Sec. 170.315(a)(13) (84 FR
7437). We stated that, based on the number of health IT products that
have been certified for this functionality as part of 2014 Edition
certification and already for 2015 Edition, we believe that health IT's
ability to identify appropriate patient education materials is
widespread now among health IT developers and their customers (e.g.,
health care providers). We also noted that we have recently seen
innovative advancements in this field, including the use of automation
and algorithms to provide appropriate education materials to patients
in a timely manner. These advancements help limit clinical workflow
interruptions and demonstrate the use and promise of health IT to
create efficiencies and improve patient care. As such, we stated that
removal of this criterion would prevent certification from creating an
unnecessary burden for developers and providers and an impediment to
innovation.
Comments. Some commenters expressed concern related to this
functionality not yet being consistently used by all providers and to
whether removal of this criterion may create a barrier to successful
participation for providers in the Medicaid PI Program. One commenter
noted that providers' workflow changes to use this functionality are
substantial and expressed concern related to providers potentially not
undertaking such changes if the criteria were not required to be
included in health IT and used by providers.
Response. While we continue to recognize the importance of patient
and provider interaction to promote positive health outcomes, we also
believe that this criterion, narrowly focused on a specific
functionality not connected to interoperability, is no longer the best
way to encourage innovation and advancement in health IT's ability to
support clinician-patient interactions and relationships.
Having reviewed all comments received on this proposal, we have
decided not to remove the ``patient-specific education resources''
criterion from the Program at this time. We recognize the importance of
ensuring alignment between ONC Health IT Certification Program
regulations and the CMS regulations that reference them. We will
continue to work in close partnership with our CMS colleagues to ensure
that our regulations remain aligned and that we provide affected
stakeholders with the information they need to understand how the rules
work together and how to succeed under CMS incentive programs using
health IT certified under ONC's Program. CMS has identified this
criterion as supporting the patient electronic access to health
information objective and measure, which is expected to remain
operational for Medicaid until January 1, 2022; after 2021, there will
be no further incentives under the Medicaid Promoting Interoperability
Program (84 FR 42592). We, therefore, will permit ONC-ACBs to issue
certificates for this criterion up until January 1, 2022, to align with
the requirements of the CMS Medicaid PI Program (84 FR 42592). We have
included a provision in Sec. 170.550(m)(1) to only allow ONC-ACBs to
issue certificates for this criterion until January 1, 2022.
d. Common Clinical Data Set Summary Record--Create; and Common Clinical
Data Set Summary Record--Receive
As stated in the proposed rule (84 FR 7437), we assessed the number
of products certified to the 2015 Edition ``Common Clinical Data Set
summary record--create'' (Sec. 170.315(b)(4)) and ``Common Clinical
Data Set summary record--receive'' (Sec. 170.315(b)(5)) criteria that
have not also been certified to the 2015 Edition ``transitions of
care'' criterion (Sec. 170.315(b)(1)) that also requires health IT be
capable of creating and receiving Common Clinical Data Set (CCDS)
Summary Records using the same interoperability standards. We explained
that, based on our findings of only two unique products certified only
to these criteria and not to the ``transitions of care'' criterion at
the time of the drafting of the Proposed Rule, there appears to be
little market demand for certification to 2015 Edition ``Common
Clinical Data Set summary record--create'' (Sec. 170.315(b)(4)) and
``Common Clinical Data Set summary record--receive'' (Sec.
170.315(b)(5)) criteria alone. Therefore, we proposed to remove these
certification criteria from the 2015 Edition.
Comments. The comments we received on this proposal supported this
removal.
Response. We thank commenters for their support and have finalized
removal of the 2015 Edition ``Common Clinical Data Set summary record--
create'' (Sec. 170.315(b)(4)) and ``Common Clinical Data Set summary
record--receive'' (Sec. 170.315(b)(5)) criteria.
e. Secure Messaging
We proposed to remove the 2015 Edition ``secure messaging''
criterion (Sec. 170.315(e)(2)). As explained in the Proposed Rule (84
FR 7437), ONC strongly supports patient and provider communication, as
well as protecting the privacy and security of patient information, but
no longer believes that a separate certification criterion focused
[[Page 25662]]
on a health IT's ability to send and receive secure messages between
health care providers and patients is necessary. This criterion would
also no longer be associated with an objective or measure under the CMS
PI Programs based on proposals and determinations in recent CMS
rulemakings (83 FR 41664; 83 FR 35929).
Comments. Several comments specifically referencing this proposal
were supportive of removing this criterion. A number of commenters
expressed concern with the removal of the ``secure messaging''
criterion, including whether removal of this criterion may create a
barrier to successful participation for providers in the CMS PI
Programs. Other commenters expressed concerns about continued
availability of secure digital endpoints for health care providers.
Some commenters noted that some providers and patients might prefer to
continue using ``secure messaging'' functionality in lieu of other
options for a variety of purposes for which they currently use it,
while others expressed concern that the separate ``secure messaging''
functionality will disappear from the market if no longer supported by
ONC requirements. Commenters expressed that options for data access and
exchange, such as portals and APIs, might satisfy providers' and
patients' needs for interoperable communication. However, commenters
expressed a concern that these options may not ensure continued
availability to new market entrants' health IT without requiring the
technology to interact with developer- or system-specific interfaces.
Response. We thank commenters for their input. Having reviewed all
comments received on this proposal, we have decided not to remove the
``secure messaging'' criterion from the Program at this time. We
recognize the importance of ensuring alignment between ONC Health IT
Certification Program regulations and the CMS regulations that
reference them. We will continue to work in close partnership with our
CMS colleagues to ensure that our regulations remain aligned and that
we provide affected stakeholders with the information they need to
understand how the rules work together and how to succeed under CMS
incentive programs using health IT certified under ONC's Program. CMS
has identified this criterion as supporting the coordination of care
through patient engagement objective and measure, which is expected to
remain operational for Medicaid until January 1, 2022; after 2021 there
will be no further incentives under the Medicaid Promoting
Interoperability Program (84 FR 42592). We, therefore, will permit ONC-
ACBs to issue certificates for this criterion up until January 1, 2022
to align with the requirements of the CMS Medicaid PI Program (84 FR
42592). We have included a provision in Sec. 170.550(m)(1) to only
allow ONC-ACBs to issue certificates for this criterion until January
1, 2022.
Limiting certificates to this criterion for this period will help
spur further innovations in patient engagement while helping to reduce
regulatory burdens and costs for health IT developers and health care
providers. The other 2015 Edition certification criteria that support
patient engagement, such as the 2015 Edition ``view, download, and
transmit to 3rd party,'' ``API,'' and ``patient health information
capture'' certification criteria better support interoperability and
innovation in patient engagement. We have seen developers integrate
secure messaging functionality as part of other patient engagement
features, such as patient portals, and integrate messaging with access
to and exchange of clinical and administrative data. These integrated
technologies currently in use offer more comprehensive options for
providers and patients to interact and share information via a secure
platform and may render the separate ``secure messaging'' criterion and
functionality redundant to robust integrated options. We also believe
removing the standalone ``secure messaging'' criterion will encourage
the market to pursue other innovative means of offering patient
engagement and interaction functionalities that providers and patients
want, with the convenience and efficiency they demand. Thus, we believe
that the removal of this criterion will help reduce burden and costs
without negative impact on current or future innovations in patient
engagement and secure information exchange. In response to the concern
about new market entrants being able to receive data needed to serve
their customers, we note that the ``view, download, and transmit to 3rd
party'' criterion remains available for patients who wish to send their
health information to a third party of the patient's choice. Other
remaining interoperability-focused criteria, such as ``transitions of
care,'' ensure that systems of health IT certified to at least those
criteria remaining in the ``Base EHR'' definition will remain capable
of supporting providers' use of new entrant and other third party
health IT of their choosing without requiring that health IT to
integrate or interface with their certified health IT.
5. Removal of Certain ONC Health IT Certification Program Requirements
We proposed to remove certain mandatory disclosure requirements and
a related attestation requirement under the Program. As discussed in
the Proposed Rule (84 FR 7437), we believe removal of these
requirements will reduce costs and burden for Program stakeholders,
particularly for health IT developers and ONC-ACBs.
a. Limitations Disclosures
We proposed to remove Sec. 170.523(k)(1)(iii)(B), which requires
ONC-ACBs to ensure that certified health IT includes a detailed
description of all known material information concerning limitations
that a user may encounter in the course of implementing and using the
certified health IT, whether to meet ``meaningful use'' objectives and
measures or to achieve any other use within the scope of the health
IT's certification. We proposed to remove Sec. 170.523(k)(1)(iv)(B)
and (C), which state that the types of information required to be
disclosed include, but are not limited to: (B) Limitations, whether by
contract or otherwise, on the use of any capability to which technology
is certified for any purpose within the scope of the technology's
certification; or in connection with any data generated in the course
of using any capability to which health IT is certified; (C)
limitations, including but not limited to technical or practical
limitations of technology or its capabilities, that could prevent or
impair the successful implementation, configuration, customization,
maintenance, support, or use of any capabilities to which technology is
certified; or that could prevent or limit the use, exchange, or
portability of any data generated in the course of using any capability
to which technology is certified.
Comments. Most of the comments specifically referencing this
proposal were supportive. A few commenters raised concerns regarding
the utility of mandatory disclosures to health care providers, their
health information exchange partners, and ONC, with some commenters
offering suggestions for how ONC could use disclosures information in
the future. A few commenters' concerns specifically referenced the
disclosure of costs information.
Response. We thank commenters for their input. We have finalized
removal of Sec. 170.523(k)(1)(iii)(B) and Sec. 170.523(k)(1)(iv)(B)
and (C), as proposed (84 FR 7437 and 7438). As
[[Page 25663]]
discussed in the Proposed Rule (84 FR 7438), these specific disclosure
requirements are superseded by the Cures Act information blocking
provision and Conditions of Certification requirements, which we
proposed to implement in the same Proposed Rule (84 FR 7424). As also
noted in the Proposed Rule (84 FR 7438), we proposed (84 FR 7465 and
7466) a complementary Condition of Certification requirement that
developers would be prohibited from taking any action that could
interfere with a user's ability to access or use certified capabilities
for any purpose within the scope of the technology's certification
discussed further in section VII.2.
We also note here to ensure clarity that we did not propose, and
have not finalized, a complete removal of the transparency requirements
in Sec. 170.523(k)(1). Requirements under Sec. 170.523(k)(1) other
than those specifically proposed for removal will remain in place. The
transparency requirements remaining in place include: Sec.
170.523(k)(1)(iii)(A), which describes the plain language detailed
description of all known material information concerning additional
types of costs that a user may be required to pay to implement or use
the Complete EHR or Health IT Module's capabilities, whether to meet
meaningful use objectives and measures, or to achieve any other use
within the scope of the health IT's certification; and Sec.
170.523(k)(1)(iv)(A) specification that the types of information
required by Sec. 170.523(k)(1)(iii) include, but are not limited to,
additional types of costs or fees (whether fixed, recurring,
transaction-based, or otherwise) imposed by a health IT developer (or
any third party from whom the developer purchases, licenses, or obtains
any technology, products, or services in connection with its certified
health IT) to purchase, license, implement, maintain, upgrade, use, or
otherwise enable and support the use of capabilities to which health IT
is certified; or in connection with any data generated in the course of
using any capability to which health IT is certified.
b. Transparency and Mandatory Disclosures Requirements
We proposed to remove the Principle of Proper Conduct (PoPC) in
Sec. 170.523(k)(2), which requires ONC-ACBs to ensure health IT
developers' adherence to a requirement that the health IT developer
submit an attestation that it will disclose all of the information in
its mandatory disclosures per Sec. 170.523(k)(1) to specified parties
(e.g., potential customers or anyone inquiring about a product quote or
description of services). As discussed in the Proposed Rule (84 FR
7438), we believe this provision is no longer necessary and that its
removal is appropriate to further reduce administrative burden for
health IT developers and ONC-ACBs.
Comments. The majority of commenters specifically discussing this
proposal expressed support for the removal of the PoPC in Sec.
170.523(k)(2). A few commenters expressed concern that the high degree
of transparency ONC noted in the Proposed Rule might not be maintained
as they noted a possibility that the PoPC requiring the ONC-ACBs to
ensure the developers submitted an attestation, and, in turn, the
developers' obligation to make the attestation, may be driving the
currently observed levels of transparency.
Response. We thank commenters for their input. We have decided to
finalize the removal of the PoPC in Sec. 170.523(k)(2). We appreciate
the importance of holding health IT developers accountable for meeting
all requirements of participation in the Program, including meeting or
exceeding the minimum required transparency disclosures. We believe
that the needed transparency and accountability will be maintained and
enhanced by certain Condition and Maintenance of Certification
requirements we have finalized in this rule, which include the
assurances and attestations specifically discussed in section VII.2 in
relation to this proposed removal of Sec. 170.523(k)(2). We believe
that the removal of the PoPC requirements in Sec. 170.523(k)(2) will
likely aid in the avoidance of unnecessary costs and burden for Program
stakeholders, particularly health IT developers and ONC-ACBs.
6. Recognition of Food and Drug Administration Processes
Section 618 of the Food and Drug Administration Safety and
Innovation Act (FDASIA), Public Law 112-144, required that the Food and
Drug Administration (FDA), in consultation with ONC and the Federal
Communications Commission (FCC) (collectively referred to as ``the
Agencies'' \18\ for this final rule), develop a report containing a
proposed strategy and recommendations on an appropriate, risk-based
regulatory framework pertaining to health IT, including mobile medical
applications, that promotes innovation, protects patient safety, and
avoids regulatory duplication. The FDASIA Health IT Report of April
2014,\19\ contained a proposed strategy and recommendations on an
appropriate, risk-based regulatory framework pertaining to health IT
that promotes innovation, protects patient safety, and avoids
regulatory duplication. Public comments, received prior to the report's
publication and after,\20\ recommended that health IT developers/
manufacturers apply a single process that satisfies the requirements of
all agencies, and existing safety and quality-related processes,
systems, and standards should be leveraged for patient safety in health
IT. On July 27, 2017, FDA announced a voluntary Software
Precertification Pilot Program as part of a broader Digital Health
Innovation Action Plan.\21\ It was developed in order to create a
tailored approach toward recognizing the unique characteristics of
digital technology by looking first at the firm, rather than primarily
at each product of the firm, as is currently done for traditional
medical products. The FDA plans to explore whether and how pre-
certified companies that have demonstrated a culture of quality,
patient safety, and organizational excellence could bring certain types
of digital health products to market either without FDA premarket
review or with a more streamlined FDA premarket review.
---------------------------------------------------------------------------
\18\ ONC is not an agency, but an office within the Department
of Health and Human Services.
\19\ https://www.fda.gov/downloads/AboutFDA/CentersOffices/OfficeofMedicalProductsandTobacco/CDRH/CDRHReports/UCM391521.pdf.
\20\ https://www.federalregister.gov/documents/2013/05/30/2013-12817/food-and-drug-administration-safety-and-innovation-act-fdasia-request-for-comments-on-the, https://blogs.fda.gov/fdavoice/index.php/2014/04/fda-seeks-comment-on-proposed-health-it-strategy-that-aims-to-promote-innovation/ and https://www.regulations.gov/document?D=FDA-2014-N-0339-0001.
\21\ https://www.fda.gov/MedicalDevices/DigitalHealth/DigitalHealthPreCertProgram/Default.htm.
---------------------------------------------------------------------------
a. FDA Software Precertification Pilot Program
We proposed (84 FR 7438 and 7439) to establish processes that would
provide health IT developers that can document holding pre-
certification under the FDA Software Precertification Pilot Program
with exemptions to the ONC Health IT Certification Program's
requirements for testing and certification of its health IT to the 2015
Edition ``quality management systems'' criterion (Sec. 170.315(g)(4))
and the 2015 Edition ``safety-enhanced design'' criterion (Sec.
170.315(g)(3)), as these criteria are applicable to the health IT
developer's health IT presented for
[[Page 25664]]
certification. We also stated that such a ``recognition'' could,
depending on the final framework of the FDA Software Precertification
Pilot Program, be applicable to the functionally-based 2015 Edition
``clinical'' certification criteria (Sec. 170.315(a)). We noted in the
Proposed Rule that the proposed ``recognition'' could also be
appropriate to address any or all of the following functionally-based
2015 Edition criteria in the event their proposed removal were not
finalized: ``problem list'' (Sec. 170.315(a)(6)), ``medication list''
(Sec. 170.315(a)(7)), ``medication allergy list'' (Sec.
170.315(a)(8)), ``drug-formulary and preferred drug list checks''
(Sec. 170.315(a)(10)),'' and ``smoking status'' (Sec.
170.315(a)(11)).
We noted (84 FR 7439) that despite proffered benefits including
alignment with both EOs 13563 and 13771 regarding deregulatory, less
burdensome, and more effective regulatory schemes and programs, and
serving as a regulatory relief for those health IT developers
qualifying as small businesses under the Regulatory Flexibility Act (84
FR 7587 and 7588), there may be reasons not to adopt such a
``recognition'' approach. We noted as examples of such reasons that
stakeholders may not agree that the FDA Software Precertification
Program sufficiently aligns with our Program, and that stakeholders may
have operational concerns. Accordingly, we welcomed comments on these
and other aspects of our proposed ``recognition'' approach, including
the 2015 Edition certification criteria that should be eligible for
``recognition.''
Comments. The majority of commenters commended ONC's efforts to
recognize the FDA Software Precertification Program. However, most
commenters expressed concerns that FDA's program was not yet mature
enough to assess the degree of alignment to the ONC Health IT
Certification Program. Many commenters expressed concerns that the FDA
Software Precertification Pilot Program focuses on development and
business practices, with a potential for streamlining requirements for
pre-market clearance of specific functionalities, while ONC's
certification Program focuses less on development practices and more on
certification of individual software products as meeting Program-
specified requirements for functionality and interoperability,
including conformance with specific interoperability standards. Many of
these commenters indicated that until the FDA program is more fully
mature they would prefer to reserve judgment on how recognition could
or should be structured to satisfy the needs of ONC's Program at lower
burden on those developers for whom dual participation is a need or an
appealing option. Several commenters noted potential for recognition of
developers who achieve precertification status under the FDA's program
to streamline or offer them a low-burden option for satisfying certain
requirements under ONC's Program. However, several commenters urged
that obtaining FDA precertification status should not be the only way a
developer could satisfy any requirement under ONC's Program, noting
that a developer of one or more certified Health IT Modules that is
newer to the market or simply smaller and not engaged in development of
software subject to FDA regulation could find the FDA Software
Precertification Program's requirements a higher hurdle to entering or
remaining in the ONC-certified health IT market sector than the ONC
requirements the recognition might replace.
Response. Considering commenters' concerns and the maturity of the
FDA Software Precertification Program--which remains in a pilot phase
at the time this final rule is being drafted--we have decided not to
finalize recognition of the FDA Software Precertification Program at
this time. However, we anticipate continuing to consult and coordinate
with our colleagues at FDA and to monitor the details and experience of
the FDA Software Precertification Program as it continues to mature. We
continue to believe that there may be potential for recognition of the
FDA Software Precertification Program to contribute in the future to
our ongoing goals of reducing burden and promoting innovation while
maintaining or enhancing the assurance that the ONC Health IT
Certification Program provides, but we have not finalized our proposal
at this time.
b. Development of Similar Independent Program Processes--Request for
Information
In the Proposed Rule (84 FR 7439), we included a request for
information (RFI) related to the development of similar independent
processes to those of the FDA Software Precertification Program for
purposes of our Program. We received 21 comments on this RFI and
appreciate the input provided by commenters. We will continue to
consider whether to develop similar independent processes and whether
this should be included in future rulemaking.
IV. Updates to the 2015 Edition Certification Criteria
In order to capture and share patient data efficiently, health care
providers need health IT that store data in structured formats.
Structured data allows health care providers to easily retrieve and
transfer patient information, and use health IT in ways that can aid
patient care. We proposed to update the 2015 Edition by adopting a
limited set of revised and new 2015 Edition certification criteria,
including new standards, to support these objectives. Some of these
criteria and standards are included in the Certified EHR Technology
(CEHRT) definition used for participation in HHS Programs, such as the
Promoting Interoperability (PI) Programs (formerly the EHR Incentive
Programs), some are required to be met for participation in the ONC
Health IT Certification Program, and some, though beneficial, are
unassociated with the CEHRT definition and not required for
participation in any HHS program, including the ONC Health IT
Certification Program (Program).
Comments. We received a few comments in support of our approach to
modify the 2015 Edition health IT certification criteria. One commenter
commended ONC for proposing logical updates to the 2015 Edition
certification criteria, rather than overhauling the Program or
establishing a new edition of certification, stating iterative changes
will provide stability and allow the industry to adapt to new market
forces. Commenters stated that this incremental approach best serves
the health care provider and health IT developer community. One
commenter applauded ONC for proposing logical updates to the 2015
Edition health IT certification criteria and recommended that ONC
continue to seek to maximize the impact of these certification changes
and pursue all opportunities to simplify existing criteria.
However, a number of commenters requested that ONC put forth a new
edition and suggested varied approaches to a new edition. Commenters
suggested that ONC clearly delineate the difference between the
editions by creating a new naming convention for the updated criteria,
such as a version number. Others recommended a 2020 Edition or the
corresponding year in which this rule is effective. Still other
commenters recommended the proposed updated 2015 Edition be renamed to
the 2021 Edition instead of renamed with a Release 2 at end of the
existing name. Some commenters identified the scope of the proposed
[[Page 25665]]
changes as the reason ONC should establish the updates as a new edition
of certification criteria rather than simply updating the 2015 Edition.
However, the majority of commenters recommending a new edition based
their concern on the potential confusion among providers who purchase
and use certified health IT resulting from different products available
under the same label.
Response. We thank commenters for their input on the tradeoffs
associated with modifying the current 2015 Edition versus creating a
new edition. We considered a variety of factors when we framed our
proposals. First, we reviewed the scope of each proposed update and the
cumulative scope of the proposals overall for health IT developers and
sought to identify whether it would be more appropriate to require
health IT developers participating in the Program to implement updates
to Health IT Modules certified to the 2015 Edition or to test and
certify health IT products to an entirely new edition of certification
criteria. Second, we considered the impact that either approach would
have on health care providers, including how such updated Health IT
Modules or products certified to a new edition would be implemented by
providers participating in CMS programs.
We have considered the impact on health IT developers related to
the scope of the individual updates as well as the cumulative scope of
all updates to the 2015 Edition adopted in this final rule (see also
section XIII Regulatory Impact Analysis). In this final rule, we have
only adopted two new technical certification criteria in Sec.
170.315(b)(10) and Sec. 170.315(g)(10) to which health IT developers
seeking to upgrade their products will need to present Health IT
Modules for certification. Unlike the new criteria introduced in prior
certification edition rulemakings, both of these new criteria are an
expansion or modification of existing criteria within the 2015 Edition
which are currently in use in certified health IT. The new criteria in
Sec. 170.315(b)(10) relates to the 2015 Edition criteria in Sec.
170.315(b)(6) with an expansion of the data and a removal of the
specificity for the standard requirement. The new Standardized API
criteria in Sec. 170.315(g)(10) relates to the 2015 Edition API
criteria with an expansion of security requirements and the addition of
applicable standards. For the remainder of the updated criteria, a
developer would not be required to present a Health IT Module for
certification in order to update a certified product in accordance with
this final rule. Instead, a health IT developer would update their
certified Health IT Module, notify the ONC-ACB that they have done so,
and make the update available their customers. Additionally, unlike
prior certification edition rulemakings, the certification criteria
updated to address compliance with the USCDI do not include new
functionality nor do they require a complete redesign of Health IT
Modules certified to such certification criteria. As noted in the
Proposed Rule, the updates to the CCDS to create the USCDI were
intentionally limited to a modest expansion that most health IT
developers already supported, were already working toward, or should be
capable of updating their health IT to support in a timely manner.
Please see Table 1 for a list of all certification criteria changes.
In consideration of the impact our approach would have on health
care providers, we note that impact and potential burden for providers
is of particular importance given that CY2019 was the first performance
year where eligible clinicians (ECs), eligible hospitals, dual-eligible
hospitals, and critical access hospitals (CAHs) participating in CMS
programs--including the CMS Promoting Interoperability Program and the
Quality Payment Program/Merit-based Incentive Payment System--were
required to use health information technology certified to the 2015
Edition to meet the requirements of the CMS CEHRT definition. If we
were to adopt a new edition of certification criteria, CMS programs
would have to consider establishing a new CEHRT definition and a
subsequent requirement for program participants who have only recently
completed a full edition update to their technology used for program
participation. Historically, with a new edition of certification
criteria, health IT developers have packaged Health IT Modules
certified to new, modified, and unchanged criteria into a wholly new
certified product. Historical data indicates that these complete
updates to the edition are particularly challenging for both health IT
developers seeking certification and for health care providers as they
place deadlines for a significant number of health IT developers to
support and implement new products for a significant number of health
care providers simultaneously. As a result, the burden of updating the
technology is compounded for both health IT developers and health care
providers. While ONC does not itself place any such requirements on
health care providers, we believe the risk of such significant burden
must be considered in health IT policy decisions.
Further, we believe the scope of the updates and the impact on
health IT developers and health care providers must be considered in
tandem--meaning that an entirely new edition should only be established
when the scope of the updates is significant enough to warrant the
impacts of implementation. When the scope of updates does not warrant
implementation of an entirely new edition of certification criteria, we
believe it is appropriate to update the existing criteria. For example
the 2015 Edition included new criteria that were neither built upon nor
updated to existing criteria in the 2014 Edition, which was
significantly different than the 2011 Edition. In contrast, health IT
developers have been able to employ regular or cyclical updates without
modifying all Health IT Modules certified to unchanged criteria in
order to implement updates to existing certification criteria such as
the annual updates to CMS eCQMs or for changes made to public health
reporting standards. In such cases, the changes may be implemented by
health IT developers in the manner most appropriate for their product
and their customers, such as through routine service and maintenance
rather than a completely new implementation.
In order to understand the impact these updates would have on
participants in the CMS programs which reference them for use by
program participants, we compare these updates to the current
definition of CEHRT established by CMS at 42 CFR 495.4 for eligible
hospitals, CAHs and Medicaid eligible professionals and at 42 CFR
414.1305 for eligible clinicians in MIPS. For 2019 and subsequent
years, the CMS CEHRT definition specifies the use of EHR technology
certified to 2015 Edition including technology that meets the 2015
Edition Base EHR definition in Sec. 170.102, as well as other
certified technology necessary to be a meaningful user. The updates
finalized in this final rule impact both certification criteria
included in the Base EHR definition as well as criteria required for
applicable objectives and measures. Specifically, this final rule
updates several criteria currently applicable for certified Health IT
Modules used by CMS program participants for the CMS objectives and
measures necessary to be a meaningful user, including:
Revisions to the electronic prescribing criterion in Sec.
170.315(b)(3) to reference an updated e-prescribing standard;
[[Page 25666]]
Revisions relating to the drug-formulary and preferred
drug list checks criterion in Sec. 170.315(a)(10) to include at
170.550(m)(1) to only allow ONC-ACBs to issue certificates for this
criterion until January 1, 2022;
Replacement of the API criterion in Sec. 170.315(g)(8)
with a new API criterion in Sec. 170.315(g)(10) referencing an API
standard and related security standards;
Revisions to several criteria to reference the USCDI and
implement other standards updates (see Table 1 for specifics); and
Revisions to Sec. 170.315(c)(3), to update quality
reporting standards.
In general, health IT developers have 24 months from the
publication date of the final rule to make technology certified to
these updated criteria available to their customers, and during this
time developers may continue supporting technology certified to the
prior version of certification criteria for use by their customers. For
providers participating in CMS programs, this means they can continue
to use the certified technology they have available to them to support
program participation and can work with their developers to implement
any updates in a manner that best meets their needs.
For the revisions to electronic prescribing criterion in Sec.
170.315(b)(3) and to the quality reporting standards, in Sec.
170.315(c)(3), the updates adopted for certified health IT align
specifically with changes already required by CMS for use by health
care providers. This means health IT developers are already
implementing and supporting these updates. The implementation of these
updates is driven by other requirements and so repackaging such updates
in a new edition (or a new product) would create a redundancy and could
have unintended cost burden on health care providers. For the updates
to the criteria referencing the USCDI, as noted previously, we based
the USCDI on the existing CCDS with modest expansion that most health
IT developers already supported, were already working toward, or should
be capable of updating their health IT to support in a timely manner.
Finally, for the removal of the drug-formulary and preferred drug list
checks in Sec. 170.315(a)(10), we note that the removal from the
Program has negligible impact on health care providers.
First, as discussed in past CMS regulations related to the use of
these functionalities by participants in CMS programs, health care
providers have noted that while formulary checks are a promising
approach, the utility of the specific functionality that is certified
is not necessarily consistently applicable for all prescriptions (80 FR
62833). Second, as it does not remove the product from the market, any
providers who are using the current functionality may continue to use
the technology for their purposes. For the replacement of the API
criterion in Sec. 170.315(g)(8) with a new Standardized API criterion
in Sec. 170.315(g)(10) referencing an API standard and related
security standards, we reiterate that health IT developers have 24
months from the date of publication of this final rule to update their
technology and make such available to their customers. The 2015 Edition
final rule adopted an API criterion in Sec. 170.315(g)(8) which was
implemented by many health IT developers using the underlying standard
adopted in this final rule for the Standardized API criterion in Sec.
170.315(g)(10). This common use impacted our decision to adopt the
standard in our update to the 2015 Edition (see also section VII.B.4.c
Standardized API for Patient and Population Services). We, therefore,
believe that both the scope of the updates and the potential impact on
health IT developers and health care providers do not constitute
sufficient justification for the potential burden associated with
adopting an entirely new edition of certification criteria. Instead, we
believe it is most reasonable and effective for these updates to be
part of the existing 2015 Edition as modified in this final rule.
We acknowledge the concerns of commenters who expressed the
potential risk of confusion about the updates among their customers and
how to best communicate that a product meets the updated version of a
given certification criterion. We strongly encourage health IT
developers to work with their customers to promote understanding of
these updates. In addition, we have taken several mitigating steps.
First, we revisited our proposed regulatory structure and revised it so
that the structure more clearly reflects if a change is updating the
previously adopted standard, or a more significant change to the
criterion such as adding a new standard. This maintains the prior 2015
Edition regulatory structure for the majority of the updates except for
Sec. 170.315(b)(10) and (g)(10) as discussed previously, and
establishes a more clear sense of scope.
Second, in order to support effective communication of the updates,
we are implementing a practical approach to facilitate transparency
using the Certified Health IT Product List (CHPL),\22\ which is the
tool that health care providers and the general public may use to
identify the specific certification status of a product at any given
time, to explore any certification actions for a product, and to obtain
a CMS Certification ID for a product used when participating in CMS
programs. While we retain the overall 2015 Edition title, we will
distinguish the 2015 Edition certification criteria from the new or
revised criteria adopted in this final rule by referring to the new or
revised criteria as the 2015 Edition Cures Update on the CHPL for
products that are certified. The CHPL will also differentiate to what
standards the health IT will be certified and will allow health care
providers to identify if and when a specific Health IT Module has been
updated. This will help to eliminate some of the confusion among
providers who are seeking to understand the certification and update
the status of the product they are currently using. It can also be a
resource for providers who may be making a new purchase of certified
health IT to make an informed decision about which products support the
most up to date available standards and functionality.
---------------------------------------------------------------------------
\22\ ONC Certified Health IT Product List: https://chpl.healthit.gov.
---------------------------------------------------------------------------
We further note that, while in the past ONC has largely relied on
creating a new edition to implement changes to certification criteria,
in each case, those changes included some updates to existing criteria,
but also criteria containing functionality and standards that were
entirely new and did not build on the prior edition. In addition, the
Cures Act set in motion a shift for the ONC Health IT Certification
Program by including Conditions and Maintenance of Certification
requirements which allowed for processes such as the Standards Version
Advancement Process (SVAP) flexibility within real world testing, which
allows better alignment to industry efforts for standards advancement
while maintaining accountability. These new provisions help to remove
barriers for standards development and version updates, which limit a
health IT developer's ability to provide individually relevant, timely,
and innovative solutions to their clients. This change is consistent
with our approach to adopt incremental updates in this final rule
rather than to adopt a complete new edition of certification criteria.
This final rule is the first time we have executed on the concept of
Maintenance of Certification requirements for existing certificates,
and we foresee the potential for future
[[Page 25667]]
rulemakings to include incremental updates to certification criteria
when such updates are appropriate.
Please see Table 1 for a list of all certification criteria
changes.
Table 1--2015 Edition Cures Update
----------------------------------------------------------------------------------------------------------------
Impact on CMS
New/revised/ removed/ 2015 Edition cures promoting
Certification criteria Reference time- limited update--timing interoperability
certification (PI) programs
----------------------------------------------------------------------------------------------------------------
Problem list................. Sec. Removed............. Effective date of Removed from 2015
170.315(a)(6). final rule (60 days Edition Base EHR
after publication). definition.
Medication list.............. Sec. Removed............. Effective date of Removed from 2015
170.315(a)(7). final rule (60 days Edition Base EHR
after publication). definition.
Medication allergy list...... Sec. Removed............. Effective date of Removed from 2015
170.315(a)(8). final rule (60 days Edition Base EHR
after publication). definition.
Drug Formulary and Preferred Sec. Time-limited ONC-ACBs only PI Measures:
Drug List Checks. 170.315(a)(10). Certification. permitted to issue --e-Rx
certificates for ---Query of PDMP
this criterion Operational for
until January 1, Medicaid until
2022. January 1, 2022.
Smoking status............... Sec. Removed............. Effective date of Removed from 2015
170.315(a)(11). final rule (60 days Edition Base EHR
after publication). definition.
Patient-specific Education Sec. Time-limited ONC-ACBs only Operational for
Resource. 170.315(a)(13). Certification. permitted to issue Medicaid until
certificates for January 1, 2022
this criterion Supports Patient
until January 1, Electronic Access
2022. to Health
Information
Objective Measure.
Transitions of Care.......... Sec. Revised............. Update to USCDI/C- PI Measures:
170.315(b)(1). CDA companion guide --Support
within 24 months Electronic Referral
after the Loops by Sending
publication date of Health Information
final rule. --Support
Electronic Referral
Loops by Receiving
and Incorporating
Health Information.
Clinical information Sec. Revised............. Update to USCDI/C- PI Measures:
reconciliation and 170.315(b)(2). CDA companion guide --Support
incorporation. within 24 months Electronic Referral
after the Loops by Receiving
publication date of and Incorporating
final rule. Health Information.
Electronic prescribing....... Sec. Revised............. Update standard PI Measures:
170.315(b)(3). within 24 months --e-Prescribing.
after the
publication of
final rule.
Common Clinical Data Set Sec. Removed............. Effective date of
summary record--create. 170.315(b)(4). final rule (60 days
after publication).
Common Clinical Data Set Sec. Removed............. Effective date of
summary record--receive. 170.315(b)(5). final rule (60 days
after publication).
Data Export.................. Sec. Time-limited ONC-ACBs may only Removed from 2015
170.315(b)(6). Certification. issue certificates Edition Base EHR
until 36 months definition
after the effective date of
publication date of the final rule (60
the final rule. days after
publication).
Security tags--summary of Sec. Revised............. Document, section,
care--send. 170.315(b)(7). and entry (data
element) level; or
Document level for
the period until 24
months after
publication date of
final rule.
Security tags--summary of Sec. Revised............. Document, section,
care--receive. 170.315(b)(8). and entry (data
element) level; or
Document level for
the period until 24
months after
publication date of
final rule.
Care plan.................... Sec. Revised............. Update to C-CDA ....................
170.315(b)(9). companion guide
within 24 months
after publication
date of final rule.
EHI export................... Sec. New................. Update within 36
170.315(b)(10). months of
publication date of
final rule.
Clinical quality measures Sec. Revised............. Effective date of PI Programs.
(CQMs)--report. 170.315(c)(3). final rule (60 days
after publication).
Auditable events and tamper- Sec. Revised............. Update to new ASTM
resistance. 170.315(d)(2). standard within 24
months after
publication date of
final rule.
Audit report(s).............. Sec. Revised............. Update to new ASTM
170.315(d)(3). standard within 24
months after
publication date of
final rule.
Auditing actions on health Sec. Revised............. Update to new ASTM
information. 170.315(d)(10). standard within 24
months after
publication date of
final rule.
Encrypt authentication Sec. New................. Effective date of
credentials. 170.315(d)(12). final rule (60 days
after publication)
(New and updated
certifications
only).
Multi-factor authentication Sec. New................. Effective date of
(MFA). 170.315(d)(13). final rule (60 days
after publication)
(New and updated
certifications
only).
View, Download, and Transmit Sec. Revised............. Update to USCDI/C- PI Measure:
to 3rd Party. 170.315(e)(1). CDA companion guide --Provide Patients
within 24 months Electronic Access
after publication to Their Health
date of final rule. Information.
Secure Messaging............. Sec. Time-limited ONC-ACBs only Operational for
170.315(e)(2). Certification. permitted to issue Medicaid until
certificates for January 1, 2022
this criterion Supports the
until January 1, Coordination of
2022. Care through
Patient Engagement
Objective.
Transmission to public health Sec. Revised............. Update to USCDI/C- PI Measure:
agencies-- electronic case 170.315(f)(5). CDA companion guide --Electronic Case
reporting. within 24 months Reporting.
after publication
date of final rule.
Consolidated CDA creation Sec. Revised............. Update to USCDI/C-
performance. 170.315(g)(6). CDA companion guide
within 24 months
after publication
date of final rule.
Application Access--Data Sec. Time-limited 24 months after PI Measure:
Category Request. 170.315(g)(8). Certification. publication date of --Provide Patients
final rule. Electronic Access
to Their Health
Information.
[[Page 25668]]
Application Access--All Data Sec. Revised............. Update to USCDI/C- PI Measure:
Request. 170.315(g)(9). CDA companion guide --Provide Patients
within 24 months Electronic Access
after publication to Their Health
date of final rule. Information.
Standardized API for patient Sec. New................. Update within 24 Added to the 2015
and population services. 170.315(g)(10). months of Edition Base EHR
publication date of definition.
final rule.
----------------------------------------------------------------------------------------------------------------
Note: The CHPL will be updated to indicate the standards utilized for new or revised certification criteria, as
well as denote criteria removed from the Program.
A. Standards and Implementation Specifications
1. National Technology Transfer and Advancement Act
The National Technology Transfer and Advancement Act (NTTAA) of
1995 (15 U.S.C. 3701 et. seq.) and the Office of Management and Budget
(OMB) Circular A-119 \23\ require the use of, wherever practical,
technical standards that are developed or adopted by voluntary
consensus standards bodies to carry out policy objectives or
activities, with certain exceptions. The NTTAA and OMB Circular A-119
provide exceptions to electing only standards developed or adopted by
voluntary consensus standards bodies, namely when doing so would be
inconsistent with applicable law or otherwise impractical. Agencies
have the discretion to decline the use of existing voluntary consensus
standards if determined that such standards are inconsistent with
applicable law or otherwise impractical, and instead use a government-
unique standard or other standard. In addition to the consideration of
voluntary consensus standards, the OMB Circular A-119 recognizes the
contributions of standardization activities that take place outside of
the voluntary consensus standards process. Therefore, in instances
where use of voluntary consensus standards would be inconsistent with
applicable law or otherwise impracticable, other standards should be
considered that meet the agency's regulatory, procurement or program
needs, deliver favorable technical and economic outcomes, and are
widely utilized in the marketplace.
---------------------------------------------------------------------------
\23\ https://www.whitehouse.gov/sites/whitehouse.gov/files/omb/circulars/A119/revised_circular_a-119_as_of_1_22.pdf.
---------------------------------------------------------------------------
Comments. A couple of commenters stated that they do not support
Federal programs' use of the NTTAA voluntary consensus standards
exceptions, and asked that the involved Federal programs continue to
utilize consensus-based standards developed through work done by
organizations such as HL7[supreg]. They noted that such work
incorporates public health inputs, and stated that it is critical for
there to be sufficient discussion and consideration of all stakeholder
concerns in adopting such critical technologies such as FHIR[supreg].
Response. We thank commenters for their feedback. We clarify that
many of the standards we adopt in this final rule are developed and/or
adopted by voluntary consensus standards bodies, except where we found
that a government unique standard is more appropriate. We are aware of
no voluntary consensus standards that could serve as an alternative for
the following purposes in this final rule.
In this final rule, we use voluntary consensus standards except
for:
The standard adopted in Sec. 170.213, the United States
Core Data for Interoperability (USCDI), Version 1 (v1), is a hybrid of
government unique policy (i.e., determining which data to include in
the USCDI) and voluntary consensus standards (i.e., the vocabulary and
code set standards attributed to USCDI data elements). We have placed
time limitations on the predecessor to this standard, the Common
Clinical Data Set (CCDS) definition, under this rule, and replaced it
with the USCDI in all applicable criteria except for the data export
criterion in Sec. 170.315(b)(6), on which we have also placed a time
limit. We refer readers to the ``Revised and New 2015 Edition
Criteria'' in section IV.B of this preamble.
The standards adopted in Sec. 170.205(h)(3) and (k)(3).
We replaced the current HL7[supreg] QRDA standards with government
unique standards, the CMS Implementation Guide for Quality Reporting
Document Architecture: Category I; Hospital Quality Reporting;
Implementation Guide for 2019, and the CMS Implementation Guide for
Quality Reporting Document Architecture: Category III; Eligible
Clinicians and Eligible Professionals Programs; Implementation Guide
for 2019, that will more effectively support the associated
certification criterion's use case, which is reporting electronic
clinical quality measure (eCQM) data to CMS.
2. Compliance With Adopted Standards and Implementation Specifications
In accordance with Office of the Federal Register regulations
related to ``incorporation by reference,'' 1 CFR part 51, which we
follow when we adopt proposed standards and/or implementation
specifications in a final rule, the entire standard or implementation
specification document is deemed published in the Federal Register when
incorporated by reference therein with the approval of the Director of
the Federal Register. Once published, compliance with the standard and/
or implementation specification includes the entire incorporated
document, unless we specify otherwise. For example, for the HL7[supreg]
FHIR U.S. Core Implementation Guide (IG) STU 3.1.0 adopted in this
final rule (see section VII.B.4), health IT certified to certification
criteria referencing this IG would need to demonstrate compliance with
all mandatory elements and requirements of the IG. If an element of the
IG is optional or permissive in any way, it would remain that way for
testing and certification unless we specified otherwise in regulation.
In such cases, the regulatory text would preempt the permissiveness of
the IG.
3. ``Reasonably Available'' to Interested Parties
The Office of the Federal Register has established requirements for
materials (e.g., standards and implementation specifications) that
agencies propose to incorporate by reference in the Code of Federal
Regulations (79 FR 66267; 1 CFR 51.5(b)). To comply with these
requirements, in section XI (``Incorporation by Reference'') of this
preamble, we provide summaries of, and uniform resource locators (URLs)
to, the standards and implementation specifications we have adopted and
subsequently incorporate by reference in the Code of Federal
Regulations. To note, we also provide relevant information about these
standards and implementation specifications
[[Page 25669]]
throughout the relevant preamble policy discussions and regulation text
sections of the final rule.
B. Revised and New 2015 Edition Criteria
1. The United States Core Data for Interoperability Standard (USCDI)
As we noted in the Proposed Rule, the initial focus of the Program
was to support the Medicare and Medicaid EHR Incentive Programs (76 FR
1294) now referred to as the Promoting Interoperability (PI) Programs.
As such, the 2014 Edition certification criteria mirrored those
functions specified by the CMS PI Programs objectives and measures for
providers demonstrating meaningful use (MU) of certified health IT. In
order to improve efficiency and streamline the common data within our
Program's certification criteria, we created a single definition for
all the required data that could be referenced for all applicable
certification criteria. We created the term ``Common MU Data Set'' to
encompass the common set of MU data types/elements (and associated
vocabulary standards) for which certification would be required across
several certification criteria (77 FR 54170).
The 2015 Edition final rule modified the Program to make it open
and accessible to more types of health IT, and health IT that supports
various care and practice settings beyond those included in the CMS PI
Programs (80 FR 62604). In comparison to the previous editions, the
2015 Edition focused on identifying health IT components necessary to
establish an interoperable nationwide health information
infrastructure, fostering innovation and opening new market
opportunities, and allowing for more health care provider and patient
choices in electronic health information access and exchange. In order
to align with this approach, we made changes in the 2015 Edition final
rule that resulted in updated vocabulary and content standards to
improve and advance interoperability and health information exchange
(80 FR 62604). The 2015 Edition final rule further expanded
accessibility and availability of data exchanged by updating the
definition of Base EHR in the 2015 Edition to include enhanced data
export, transitions of care, and application programming interface
(API) capabilities, all of which previously required that, at a
minimum, the CCDS be available (80 FR 62602 through 62604).
We further noted in the Proposed Rule (84 FR 7440) that the
regulatory approach to using and referencing a ``definition'' to
identify electronic health information, for access, exchange and use,
including associated vocabulary codes, has had its drawbacks. While
ONC's ``CCDS'' definition served its designed purpose (to reduce
repetitive text in each of the certification criteria in which it is
referenced), the term CCDS, and the data set it represents, also began
to be used by outside organizations such as the Argonaut Project \24\
for additional use cases beyond the C-CDA and ONC's Health IT
Certification Program. As these organizations identified the need to
expand the content of the CCDS, the CCDS definition in regulation
became a limitation to developing additional data access, exchange, and
uses outside of ONC's programs. As we move towards value-based care and
the inclusion of Data Classes that go beyond clinical data, and as part
of ONC's continued efforts to evaluate the availability of a minimum
baseline of Data Classes that must be commonly available for
interoperable exchange, we acknowledge the need to change and improve
our regulatory approach to the CCDS. Therefore, in order to advance
interoperability by adopting new data and vocabulary codes sets that
support data exchange, we proposed to remove the ``Common Clinical Data
Set'' in Sec. 170.315(b)(4) and Sec. 170.315(b)(5), and its
references throughout the 2015 Edition and replace it with the ``United
States Core Data for Interoperability'' (USCDI) standard. This first
version of USCDI will be designated ``version 1 (v1).'' The USCDI
standard aims to achieve the goals set forth in the Cures Act by
specifying a common set of data classes and elements that have been
designed to improve data usage and interoperable data exchange.
---------------------------------------------------------------------------
\24\ https://argonautwiki.hl7.org/Main_Page.
---------------------------------------------------------------------------
We proposed to adopt the USCDI v1 as a standard defined in Sec.
170.102. Here, ``Standard'' is defined as a ``technical, functional, or
performance-based rule, condition, requirement, or specification that
stipulates instructions, fields, codes, data, materials,
characteristics, or actions.'' The USCDI standard would be composed of
Data Classes, which may be further delineated into groupings of
specific Data Element(s). For example, ``patient demographics'' is a
Data Class, and within that Data Class there is ``patient name,'' which
is a Data Element. As noted in section IV.B.1.b, for the overall
structure and organization of the USCDI, please consult
www.healthIT.gov/USCDI.
We noted in the Proposed Rule (84 FR 7441) that ONC intended to
establish and follow a predictable, transparent, and collaborative
process to expand the USCDI, including providing stakeholders with the
opportunity to comment on the USCDI's expansion. We indicated that once
the Secretary adopts the first version of the USCDI through rulemaking,
which we proposed in Sec. 170.213 in the Proposed Rule, health IT
developers would be allowed to take advantage of the ``Standards
Version Advancement Process'' (SVAP) flexibility. The SVAP (which we
proposed in Sec. 170.405(b) and which is discussed in section VII.B.5,
below) would permit health IT developers to voluntarily implement and
use a newer version of a Secretary-adopted standard such as the USCDI,
subject to certain conditions including a requirement that the newer
version is approved for use by the National Coordinator, and does not
conflict with requirements under other applicable law. We received a
number of comments regarding these proposals, which are outlined in the
subsections below.
Comments. We received broad support for the adoption of version 1
of the USCDI as a new standard defining critical health care data to
promote interoperability. Some commenters from health plans, while
supportive of patient and provider access to health care data, voiced
concerns about health plans being required to make data available in
the USCDI standard. Other commenters noted that USCDI v1 does not
include data classes and elements that pertain to all health care
settings, including public health, and would therefore not be broadly
applicable to all health care settings.
Response. We thank commenters for their support of the adoption of
USCDI v1 as a standard. We wish to clarify that the adoption of version
1 of the USCDI as a standard for our Program is not specific to a
setting of care, a health care specialty, or a specific category of
health IT user. Nor is the USCDI specific to a particular content
exchange standard (e.g., HL7 C-CDA, HL7 FHIR, HL7 V2, and NCPDP
SCRIPT). Rather, it applies to the certification of health IT and
certified health IT's ability to send and receive the Data Elements
defined by USCDI without requirements regarding functionality, user
interface, or the use of those Data Elements in exchange. While some
users may find few opportunities to exchange these Data Elements, many
will exchange these Data Elements frequently, and we believe that all
health care providers should have certified health IT that can provide
them with a means to appropriately share and access the USCDI data set
when exchanging data with other providers. Accordingly, we
[[Page 25670]]
seek to clarify a point with respect to our proposal regarding the
USCDI and health IT certification. For the purposes of the ONC Health
IT Certification Program, specific certification criteria are the way
the USCDI comes into effect. For example, the USCDI is referenced as
part of the data requirements in the updated ``transitions of care''
certification criterion (Sec. 170.315(b)(1)), which also specifies
that for certification to that criterion, the C-CDA must be used as the
syntax to hold all of the USCDI data.
As we explained, we believe that the adoption of USCDI v1 for all
certified health IT will advance interoperability by ensuring
utilization of common data and vocabulary code sets, and that
standardization will support both electronic exchange and usability of
the data. Furthermore, because ONC will establish and follow a
predictable, transparent, and collaborative process to expand future
versions of USCDI, including providing stakeholders with the
opportunity to comment on draft USCDI's expansion, stakeholders will
have ample opportunities to advance additional Data Classes and Data
Elements relevant to a wide range of health care use cases. After
consideration of these comments and the overall support of commenters,
we have adopted the USCDI v1 as a standard in Sec. 170.213.
We have also extended the compliance timelines with which a health
IT developer needs to update to the USCDI, therefore, we have not
removed the CCDS definition from Sec. 170.102 as proposed but revised
it to remove references to 2014 Edition standards and provided time
limitations for when health IT developers need to update to the USCDI.
a. USCDI 2015 Edition Certification Criteria
We proposed (84 FR 7441) to adopt the USCDI Version 1 (USCDI v1) in
Sec. 170.213.\25\ The USCDI is a standardized set of health Data
Classes and constituent Data Elements that would be required to support
nationwide electronic health information exchange. Once adopted in this
final rule, health IT developers would be required to update their
certified health IT to support the USCDI v1 for all certification
criteria affected by this proposed change. We also proposed conforming
changes in the sections below to update the following formerly CCDS-
dependent 2015 Edition certification criteria to incorporate the USCDI
standard:
---------------------------------------------------------------------------
\25\ We note that USCDI v1 is an updated version and
distinguished from the Draft United States Core Data for
Interoperability (USCDI) previously made available for public review
and comment in the course of its development as a prospective
standard. The data classes and elements in the USCDI v1 were
proposed in Sec. 170.213 and defined in the Proposed Rule, and an
additional USCDI v1 document with technical standards information
was posted electronically concurrent with the publication of the
Proposed Rule in order to provide the public adequate time to fully
review and comment on both the proposed regulation and the USCDI v1
technical information.
---------------------------------------------------------------------------
``transitions of care'' (Sec. 170.315(b)(1));
``view, download, and transmit to 3rd party'' (Sec.
170.315(e)(1));
``transmission to public health agencies--electronic case
reporting'' (Sec. 170.315(f)(5));
``consolidated CDA creation performance'' (Sec.
170.315(g)(6)); and
``application access--all data request'' (Sec.
170.315(g)(9)).
We did not include the ``data export'' criterion (Sec.
170.315(b)(6)) in the proposed list of criteria that would be revised
to include the USCDI standard because we proposed to remove the ``data
export'' criterion (Sec. 170.315(b)(6)) and instead proposed to adopt
a criterion that we referenced as ``EHI export'' in the Proposed Rule
(Sec. 170.315(b)(10)). For similar reasons, we did not include the
``application access--data category request'' criterion (Sec.
170.315(g)(8)) because we proposed to replace it with the API
certification criterion (Sec. 170.315(g)(10)) that derives its data
requirements from the USCDI.
We also proposed, as a Maintenance of Certification requirement
(Sec. 170.405(b)(3)) for the real world testing Condition of
Certification requirement (Sec. 170.405(a)), that health IT developers
with health IT certified to the five above-identified certification
criteria prior to the effective date of this final rule would have to
update such certified health IT to the proposed revised standards (84
FR 7441 and 7596). We further proposed, as a Maintenance of
Certification requirement (Sec. 170.405(b)(3)) for the real world
testing Condition of Certification requirement (Sec. 170.405(a)), that
health IT developers must provide the updated certified health IT to
all their customers with health IT previously certified to the
identified criteria no later than 24 months after the effective date of
this final rule (84 FR 7441 and 84 FR 7596). For the purposes of
meeting this compliance timeline, we noted that we expected health IT
developers to update their certified health IT and notify their ONC-ACB
on the date at which they have reached compliance. We noted that
developers would also need to factor these updates into their next real
world testing plan as discussed in section VII.B.5 of the Proposed
Rule.\26\
---------------------------------------------------------------------------
\26\ The finalized real world testing Condition and Maintenance
of Certification requirements are discussed in section VII.B.5 of
this final rule.
---------------------------------------------------------------------------
Comments. The majority of commenters supported the proposed
adoption of USCDI v1 and incorporation of the USCDI into the revised
and new certification criteria. Some commenters expressed concern that
incorporation of the USCDI into the ``transmission to public health
agencies--electronic case reporting'' certification criteria could have
a negative impact on data received by public health reporting programs.
Some commenters stressed the need for reasonable adoption timelines.
Some suggested a longer adoption and implementation timeline for
incorporation of the USCDI as part of certified health IT.
Response. ONC acknowledges that some entities, such as public
health agencies, may need to consider what the expanded set of data the
USCDI v1 offers may mean to their reporting programs and requirements.
To be clear, the USCDI's existence as a stand-alone standard will not
impact or change public health reporting requirements. However, certain
data now included in the USCDI, such as clinical notes, would now
become more readily available for public health reporting and a State's
public health program's policy may need to be revisited if a State
seeks to make use of the ``new'' data the adoption of the USCDI stands
to make more easily available, and more usable upon receipt. We also
believe that the proposed 24-month timeline for updating certified
health IT to comply with the new USCDI standard in Sec. 170.213 is an
adequate implementation timeline, based on other adoption timelines
with similar technical complexities. We, therefore, have finalized
revisions for the five above-identified formerly CCDS-dependent 2015
Edition certification criteria to incorporate the USCDI standard.
We have finalized a modification to the regulation text for these
criteria based on public comment related to mitigating the risk of
potential confusion caused by updates to existing criteria. As
discussed earlier in this preamble (section IV), we received public
comment requesting that all revised criteria be included in a new
edition of certification criteria. At the start of section IV, we
discuss in response to these comments that we do not believe the
creation of a new edition is appropriate given that the scope of the
updates to the 2015 Edition is tied
[[Page 25671]]
to standards updates required to keep pace with current industry
practices. However, we do plan to distinguish the 2015 Edition
certification criteria from the updated criteria in this final rule by
referring to them as the 2015 Edition Cures Update on the CHPL.
However, as Health IT Modules are updated to the new standards over
time, there is a need to define what is required for certification and
what is required for compliance to prior certification. Therefore, we
have finalized that for criteria being updated from the CCDS to the
USCDI, 24 months after publication date of the final rule shall be
applicable for a transition from the CCDS to the USCDI. We have
finalized that for the period until 24 months after the publication
date of the final rule, the CCDS remains applicable for certified
Health IT Modules until such Health IT Modules are updated to the
USCDI. This means that upon the effective date of the rule, for the
identified criteria the following apply for certification and
compliance:
The USCDI, or
The CCDS for the period up to 24 months after the
publication date of the final rule.
This allows for developers to plan the transition for their
products more effectively and supports certification continuity. We
have finalized a modification to the regulation text to require the
USCDI, or the CCDS for the period lasting until 24 months after the
publication date of the final rule.
We have finalized this modification to the regulation text for the
following criteria:
``transitions of care'' (Sec. 170.315(b)(1));
``view, download, and transmit to 3rd party'' (Sec.
170.315(e)(1));
``transmission to public health agencies--electronic case
reporting'' (Sec. 170.315(f)(5));
``consolidated CDA creation performance'' (Sec.
170.315(g)(6)); and
``application access--all data request'' (Sec.
170.315(g)(9)).
We have finalized in Sec. 170.405(b)(3), as a Maintenance of
Certification requirement under the real world testing Condition of
Certification requirement, that health IT developers with health IT
certified to the five above-identified certification criteria prior to
the effective date of this final rule, would have to update such
certified health IT to the revisions within 24 months of the
publication date of this rule.
As of this final rule's effective date, the ``data export''
criterion in Sec. 170.315(b)(6) is no longer required as a part of the
2015 Edition Base EHR definition. ONC-ACB's will not be permitted to
issue certificates to this certification criteria after 36 months after
the publication date of this final rule. As discussed in the ``EHI
export'' section below, we have retained Sec. 170.315(b)(6) ``as is,''
without updates to the USCDI. Thus, health IT developers with health IT
certified to the prior certification criterion in Sec. 170.315(b)(6)
do not have to update such certified health IT to the revisions listed
above, but are permitted to maintain or seek new Health IT Module
certification to this criterion should they desire this functionality.
b. USCDI Standard--Data Classes Included
As we noted in the Proposed Rule (84 FR 7441), the USCDI Version 1
(USCDI v1) and its constituent Data Elements incorporated
recommendations we had accepted from public comments we had previously
received on our Draft USCDI and Proposed Expansion Process,\27\ which
we published January 5, 2018 as well as initial feedback on that draft
from the Health IT Advisory Committee, both of which occurred prior to
the publication of the Proposed Rule. The standard we proposed to adopt
in Sec. 170.213 also reflected and acknowledged the burden that
rapidly expanding the USCDI v1 beyond the CCDS could cause. As a
result, the USCDI v1 that we proposed was a modest expansion of the
CCDS, which we indicated that most health IT developers already
supported, were already working toward, or should be capable of
updating their health IT to support in a timely manner. Therefore, in
our Proposed Rule, we outlined only the delta between the CCDS and the
USCDI v1. For the overall structure and organization of the USCDI
standard, we urged stakeholders to consult www.healthIT.gov/USCDI.
---------------------------------------------------------------------------
\27\ https://www.healthit.gov/sites/default/files/draft-uscdi.pdf (January 5, 2018).
---------------------------------------------------------------------------
Comments. We received numerous comments proposing new Data Classes,
Data Elements, and other changes within the USCDI beyond those we
included in the Proposed Rule. Comments recommended including new Data
Elements and/or classes within the USCDI v1 related to encounter data,
financial transaction and insurance data, and specialty-specific Data
Elements related to cancer treatment, social determinants of health,
and more. Another commenter identified an error in the Procedures Data
Class citing the wrong code set for dental procedures in the USCDI v1.
Response. We thank the many commenters for their input on the
USCDI. We recognize that the USCDI v1 as proposed represents a modest
change over the current CCDS definition. As we indicated in the
Proposed Rule (84 FR 7441), we view this initial version of the USCDI
standard as a starting point to support improved interoperability. We
are also sensitive to requirements related to the development and
implementation of adopting the USCDI standard. In the interests of
maintaining our proposed implementation timeline of 24 months from the
publication of this final rule, and after consideration of these
comments and the overall support of commenters, we have finalized the
adoption of the Data Classes and elements of the USCDI standard as
proposed, with changes outlined in the subsections below. Additionally,
in order to address the error pointed out to us via comments in the
Procedures Data Class, as was stated in the draft USCDI v1,\28\ we
clarified that the American Dental Association's Code on Dental
Procedures and Nomenclature (CDT) should be used for Dental Procedures
in the USCDI v1, not SNODENT as was erroneously stated in the draft
USCDI v1.
---------------------------------------------------------------------------
\28\ https://www.healthit.gov/sites/default/files/draft-uscdi.pdf.
---------------------------------------------------------------------------
With respect to the USCDI's expansion in future years, ONC will
establish and follow a predictable, transparent, and collaborative
process to expand the USCDI, which will provide stakeholders with the
opportunity to comment on the USCDI's expansion and to advance
additional Data Classes and Data Elements relevant to a wide range of
use cases related to health care. Prior to this final rule, we
published our initial thinking as well as examples of Data Classes and
Data Elements that we believed could be appropriate to propose for
adding to the USCDI.\29\ We have also solicited feedback and
recommendations from the HITAC. As we evaluated public comments and
conducted our own research prior to the issuance of this final rule, we
also wanted to identify for stakeholders another potential source that
could be used to focus efforts around new USCDI Data Classes and Data
Elements. As is noted throughout this rule, the HL7[supreg]
FHIR[supreg] standard represents health information in what are called
``FHIR resources.'' When it comes to logically organizing FHIR
resources that relate to one another and share common properties, FHIR
uses a concept called a ``compartment.'' Through the standards
development process a ``Patient Compartment'' has been
[[Page 25672]]
created, which lists all of the FHIR resources that are associated with
a patient. The Patient Compartment ``includes any resources where the
subject of the resource is the patient, and some other resources that
are directly linked to resources in the patient compartment.'' This
organizing framework provides a potentially rich set of a Data Classes
and Data Elements to consider for inclusion in the USCDI, including
clinical, encounter, specialty, and financial data. As ONC looks to
make its own investments to advance the implementation experience
associated with prospective USCDI Data Classes and Data Elements, we
intend to leverage the Patient Compartment to guide our thinking. In
addition, we will also look to and encourage industry to look at other
organizing frameworks such as the Clinical Quality/Clinical Decision
Support realms and the payer-to-provider community (e.g., DaVinci
Project \30\) to help identify data that would be best to focus on for
USCDI expansion.
---------------------------------------------------------------------------
\29\ https://www.healthit.gov/sites/default/files/draft-uscdi.pdf.
\30\ http://www.hl7.org/about/davinci/index.cfm.
---------------------------------------------------------------------------
i. Updated Versions of Vocabulary Standard Code Sets
We proposed (84 FR 7441) that the USCDI v1 would include the newest
versions of the ``minimum standard'' code sets included in the CCDS
available at publication of this final rule. We requested comment on
that proposal and on whether it could result in any interoperability
concerns. We also noted that criteria such as the 2015 Edition ``family
health history'' criterion (Sec. 170.315(a)(12)), the 2015 Edition
``transmission to immunization registries'' criterion (Sec.
170.315(f)(1)), and the 2015 Edition ``transmission to public health
agencies--syndromic surveillance'' criterion (Sec. 170.315(f)(2))
reference ``minimum standard'' code sets; however, we indicated that we
were considering updating the versions of these standards listed and
incorporated by reference in part 170 subpart B that are referenced by
these criteria from the versions adopted in the 2015 Edition final
rule.
We also noted, for purposes of clarity, that consistent with Sec.
170.555, unless the Secretary prohibits the use of a newer version of
an identified minimum standard code set for certification, health IT
could continue to be certified or upgraded by developers to a newer
version of an identified minimum standard code set than that included
in USCDI v1 or the most recent USCDI version that the National
Coordinator has approved for use in the Program using the SVAP
flexibility.
Comments. There was general support from commenters for updating
``minimum standard'' code sets requirements to the newest versions of
these code sets as part of the update from CCDS to the USCDI. One
commenter recommended adopting the Data Class requirement first,
followed by a delayed requirement of updated versions of the ``minimum
standards'' code sets, in order to allow implementers more time to make
changes to their systems.
Response. We do not believe that adopting the corresponding
``minimum standards'' code sets that are updated in the USCDI v1 would
impose a significant burden on implementers. In consideration of the
overall support from commenters, we have finalized our proposal that
the USCDI v1 include the newest versions of the ``minimum standard''
code sets available at the time of finalization of this final rule. We
have not, however, finalized the proposal for the 2015 Edition ``family
health history'' criterion (Sec. 170.315(a)(12)), the 2015 Edition
``transmission to immunization registries'' criterion (Sec.
170.315(f)(1)), and the 2015 Edition ``transmission to public health
agencies--syndromic surveillance'' criterion (Sec. 170.315(f)(2)) to
reference the newest versions of the ``minimum standard'' code sets for
these criteria, because the flexibility already exists to use newer
versions of code sets included in these criteria. We note that for
these certification criteria, health IT developers may take advantage
of the previously established \31\ flexibility to seek certification to
newer versions of the ``minimum standards'' code with Sec. 170.555.
---------------------------------------------------------------------------
\31\ 77 FR 54163, 54268-69 (September 4, 2012).
---------------------------------------------------------------------------
ii. Address and Phone Number
We proposed (84 FR 7442) new Data Elements in the USCDI v1 for
``address'' and ``phone number.'' We noted that the inclusion of
``address'' (to represent the postal location for the patient) and
``phone number'' (to represent the patient's telephone number) would
improve the comprehensiveness of health information for patient care.
We further noted that the inclusion of these Data Elements was
consistent with the list of patient matching Data Elements already
specified in the 2015 Edition ``transitions of care'' certification
criterion (Sec. 170.315(b)(1)(iii)(G)), which supports the exchange of
patient health information between providers of patient care.
Comments. Commenters unanimously supported the addition of address
and phone numbers to the USCDI v1. The majority of commenters on this
proposal recommended the use of the U.S. Postal Service address format
to improve address data quality. Commenters also recommended additional
elements of address and phone number indicating effective period (e.g.,
current address, former address); use (e.g., mobile phone number,
landline, etc.), and email address.
Response. We thank the commenters for their recommendations and
agree that these additional Data Elements can be useful to provide
better care and assist with patient matching. In consideration of these
comments, we have finalized the addition of the following Data Elements
within the Patient Demographics Data Class:
``current address'';
``previous address'';
``phone number'';
``phone number type''; and
``email address.''
We further clarify that ``phone number'' and ``phone number type''
must be represented using the same standards, ITU-T E.123 (02/2001) and
ITU-T E.164, as already adopted for this data in 45 CFR 170.207(q) and
referenced in the 2015 Edition ``transitions of care'' certification
criterion (Sec. 170.315(b)(1)(iii)(G)).
We appreciate commenters' recommendations to use the U.S. Postal
Service Postal Addressing Standards, which include address formatting
guidance and a variety of products to improve address quality, such as
address element standardization and validation which are published and
available for public use.\32\ The U.S. Postal Service Postal Addressing
Standards include standardized names for common unit identifiers, line
by line acceptance requirements for mail services, and overall address
format guidance that has been specifically designed to support
labelling of mail items for acceptance by the U.S. Postal Service
automated sorting processes. We acknowledge the potential for its use
within health IT to improve patient matching. However, while the U.S.
Postal Service Postal Addressing Standards include a single
representation for certain data elements (such as rendering apartment
as apt, building as bldg, floor as fl, etc.) they also allow variations
for other data elements, such as ``acceptable'' and ``preferred''
spellings and abbreviations for street and city names. This may result
in multiple ``valid'' addresses. To reconcile this variation, the U.S.
Postal Service provides a file listing preferred
[[Page 25673]]
city and State combinations as well as a file of street name and zip
code combinations and the resulting aggregated address would then
require manual reconciliation. We believe the U.S. Postal Service
Postal Addressing Standards may be useful guidance for health IT
developers. However, because of the variation, the required use of
reference files, and the manual reconciliation necessary for
implementation, we have not adopted the U.S. Postal Service Postal
Addressing Standards as a required standard for the address Data
Elements within the USCDI. We encourage the use of standardized
elements to accurately represent patient address including use of
standardized references in the U.S Post Service Postal Addressing
Standards where applicable. In addition, we will continue to work with
standards developing organizations to evaluate potential solutions to
improve patient matching, including considering the potential
adaptability of the U.S. Postal Service formats for health IT use
cases.
---------------------------------------------------------------------------
\32\ U.S. Postal Service: Postal Addressing Standards
(Publication 28) available at https://pe.usps.com/text/pub28/welcome.htm.
---------------------------------------------------------------------------
The U.S. Postal Service also maintains web based tools for address
validation services and provides implementation guidance to integrate
these tools into technical workflows for IT systems in e-commerce and
other industries. We agree that these address validation tools have the
potential to greatly improve address data quality, and we encourage
health IT developers and other relevant health IT users such as health
information networks to explore mechanisms by which such address
validation might support patient matching. While not specifically
designed for patient matching and other health care related
applications, USPS address validation has been piloted in these
settings. To adapt the address validation tool to a health care purpose
requires the services of a third party with licensing of the tool and
the development of a bespoke process to execute the tool. The
aggregated patient address could then be compared against the USPS
address on file and the patient data could be amended where inaccurate,
appended where incomplete, or a linked record of secondary address data
could be created depending on the percent of confidence in the specific
match. This process would then require manual reconciliation. The
results of these pilots indicate significant complexity and burden
associated with implementation of this process. Given these burdens, we
believe it would not be appropriate to require the integration of this
distinct functionality into certified health IT at this time. We again
encourage the further development and use of standardized approaches
for address validation and will continue to monitor and analyze such
efforts for consideration in future rulemaking.
iii. Pediatric Vital Signs
As proposed (84 FR 7442), the USCDI v1 included the pediatric vital
sign data elements, which are specified as optional health information
in the 2015 Edition CCDS definition. The proposed pediatric vital signs
included: head occipital-frontal circumference for children less than 3
years of age, BMI percentile per age and sex for youth 2-20 years of
age, weight for age per length and sex for children less than 3 years
of age, and the reference range/scale or growth curve, as appropriate.
As explained in section VI.A.2 of this final rule, the inclusion of
pediatric vital sign Data Elements in the draft USCDI v1 align with the
provisions of the Cures Act related to health IT to support the health
care of children. Prior to the publication of the Proposed Rule,
stakeholders emphasized the value of pediatric vital sign data elements
to better support the safety and quality of care delivered to children.
We also note in our Proposed Rule and in the 2015 Edition proposed rule
(80 FR 16818 and 16819) that the Centers for Disease Control and
Prevention (CDC) recommends as part of best practices the use of these
pediatric vital signs for settings of care in which pediatric and
adolescent patients are seen. The availability of a reference range/
scale or growth curve would help with proper interpretation of the
measurements for the BMI percentile per age and sex and weight for age
per length and sex.
Further, we noted our belief that the inclusion of this health
information in the USCDI v1 was the appropriate next step after first
specifying them as optional in the CCDS definition as part of the 2015
Edition rulemaking (80 FR 62695), and as a means of supporting patient
access to their EHI in a longitudinal format through certified health
IT (see section 3009(e)(2)(A)(i) of the PHSA as amended by the Cures
Act). We recognized, however, that certain health IT developers and
their customers may not find these capabilities and information useful.
Therefore, we requested comment on the inclusion of pediatric vital
signs in the USCDI v1, including the potential benefits and costs for
all stakeholders stemming from its inclusion in the USCDI v1.
Comments. Commenters generally supported the inclusion of the
pediatric vital signs Data Elements in the USCDI v1. Some commenters
opposed their inclusion or believed the inclusion of these Data
Elements should be optional since pediatric vital signs are not
applicable to all specialties and would add implementation burden and
cost without benefit. One commenter stated that only the measurements
and associated metadata (units of measure, date/time measurement taken,
method of measurement), not the calculated percentiles according to
applicable pediatric growth charts, should be required as part of the
exchange of patient data. One commenter recommended adding the
nutritional status Data Element ``mid-arm circumference.'' Finally,
several commenters suggested or requested clarification on the
pediatric vital signs Data Elements we proposed (84 FR 7442).
Specifically, stakeholders in the pediatric community asked for
clarification of the proposed pediatric vital sign ``weight for age per
length and sex for children less than 3 years of age,'' noting it does
not correspond to any existing pediatric growth charts. Rather, they
noted that there is a growth chart ``weight-for-length'' for children
less than 3 years of age.
Response. We recognize that the adoption of these Data Elements has
the potential to add burden and cost for some health IT products, but
we believe the inclusion of these Data Elements can contribute
significantly to the longitudinal care of patients. Pediatric care is
not isolated to a single specialty or setting of care, and clinicians
providing health care for children--especially those providing care for
children with complex conditions--may practice in a wide range of
settings using a wide range of health IT systems. Many key stakeholders
believe that the ability to capture, calculate, and transmit key
pediatric growth data using health IT is critical to providing care to
these populations as well as communicating with other providers,
parent/guardians, and patients. We also note that adoption of the USCDI
standard and its Data Classes and elements is not specific as to its
usage within a setting of care, a health care specialty, or by a
specific category of health IT user; rather it applies to certified
health IT's ability to send and receive those Data Elements without
requirements regarding functionality, user interface, or the use of
those Data Elements in exchange. While some users may find few
opportunities to exchange these Data Elements, many will exchange these
Data Elements frequently. As we have noted previously, we believe that
the adoption
[[Page 25674]]
of USCDI for all certified health IT will advance interoperability by
ensuring compliance with new data and vocabulary codes sets that
support the data.
We also appreciate the commenter's suggestion for an additional
Data Element. As we have noted, ONC will establish and follow a
predictable, transparent, and collaborative process to expand the
USCDI, which will provide stakeholders with the opportunity to advance
additional Data Classes and Data Elements relevant to a wide range of
use cases related to health care.
Regarding the request to clarify and better define these proposed
pediatric vital signs, we note that these Data Elements, as written and
proposed, were previously included as optional health information in
the 2015 Edition CCDS definition. The discrepancy between the adopted
pediatric vital signs and standardized pediatric growth charts was not
identified previously. Therefore, we wish to clarify that the above-
referenced pediatric vital signs include both the vital measurements
and the percentiles used in the following growth charts currently
recommended by the Centers for Disease Control and Prevention: \33\ for
infants birth to 36 months of age: Weight-for-length; and head
occipital-frontal circumference for age; and for children 2-20 years of
age: Body mass index (BMI) for age.
---------------------------------------------------------------------------
\33\ https://www.cdc.gov/growthcharts/index.htm.
---------------------------------------------------------------------------
In consideration of these comments, we have finalized the following
pediatric Data Elements in the Vital Signs Data Class of the USCDI v1:
Head occipital-frontal circumference percentile (Birth to 36 Months);
weight-for-length percentile (Birth to 36 Months); body mass index
(BMI) percentile (2-20 Years of Age); and the reference range/scale or
growth curve, as appropriate.
iv. Clinical Notes
We proposed (84 FR 7442) to include in the USCDI v1 a new Data
Class entitled ``clinical notes.'' ``Clinical notes'' was included in
the proposed USCDI v1 based on significant feedback from the industry
since the 2015 Edition final rule. We also received similar feedback
during the Trusted Exchange Framework and Common Agreement (TEFCA)
stakeholder sessions and public comment period. As we noted, ``clinical
notes'' have been identified by stakeholders as highly desirable data
for interoperable exchange. The free text portion of the clinical notes
was most often relayed by clinicians as the data they sought, but were
often missing during electronic health information exchange. We
additionally noted that clinical notes can be composed of text
generated from structured (pick-list and/or check the box) fields as
well as unstructured (free text) data. We explained that a clinical
note may include the assessment, diagnosis, plan of care and evaluation
of plan, patient teaching, and other relevant data points.
We recognized that a number of different types of clinical notes
could be useful for stakeholders. We indicated our understanding that
work is being done in the community to focus on a subset of clinical
notes. We considered three options for identifying the different ``note
types'' to adopt in USCDI v1. The first option we considered allowed
for the community to offer any and all recommended notes. The second
option we considered set a minimum standard of eight note types. This
option was derived from the eight note types identified by the Argonaut
Project participants.\34\ The third option we identified looked to the
eleven HL7 Consolidated Clinical Document Architecture (C-CDA) document
types identified in the C-CDA Release 2.1, which also included the note
types being identified by the Argonaut Project participants. We
ultimately proposed the second option because it unites public and
private interests toward the same goal. We indicated that the eight
selected note types were a minimum bar and, in the future, the USCDI
could be updated to include other clinical notes. Specifically, we
proposed to include the following clinical note types for both
inpatient and outpatient (primary care, emergency department, etc.)
settings in USCDI v1 as a minimum standard: (1) Discharge Summary note;
(2) History & Physical; (3) Progress Note; (4) Consultation Note; (5)
Imaging Narrative; (6) Laboratory Report Narrative; (7) Pathology
Report Narrative; and (8) Procedures Note (84 FR 7442). We requested
comment on whether to include additional note types as part of the
USCDI v1.
---------------------------------------------------------------------------
\34\ Link to the Clinical Notes Argonaut Project identified (to
clarify: Seven bullets are listed, however, we split laboratory and
pathology note types into their own note) http://wiki.hl7.org/index.php?title=201805_Clinical_Notes_Track.
---------------------------------------------------------------------------
Comments. Commenters broadly supported adding ``clinical notes'' as
a new Data Class to the USCDI v1, in particular to enable the use of
free text for data exchange. Several commenters requested clarity as to
whether the proposal to adopt this new Data Class would require the
capture and exchange of unstructured, or ``raw'' or ``free'' text,
narrative clinical information or more comprehensive documents such as
those defined by C-CDA. Some commenters recommended adding certain note
types--including continuity of care, operative, and nursing notes--
while others recommended removing some of the proposed note types. In
particular, Laboratory/Pathology Report Narrative note types were
thought to be duplicative of content in the Laboratory Data Class and
element Value/Results. Some commenters recommended Imaging Narrative
not be used, but added to a new Data Class, Diagnostic Tests, which
would combine Laboratory and Radiology tests and results.
Response. We thank commenters for their support and
recommendations. While we recognize that there may be alternative
methods of organizing different clinical note types, we believe there
is value in grouping all clinical notes into a single Data Class within
the USCDI. As we noted above and in the Proposed Rule, we have adopted
the eight note types identified by the Argonaut Project participants
because it unites public and private interests toward the same goal. As
we indicated, the eight selected note types are a minimum bar and, in
the future, the USCDI could be updated to include other clinical note
types. The eight selected note types reflect the most clearly and
consistently recommended set of clinical note type. While a variety of
additional note types were recommended, there was no consensus for
additional note types beyond these eight. In consideration of these
comments, we have finalized the clinical notes as a Data Class in the
USCDI v1, with only the following eight clinical note types for both
inpatient and outpatient (primary care, emergency department, etc.)
settings as a minimum standard as proposed: (1) Discharge Summary Note;
(2) History & Physical; (3) Progress Note; (4) Consultation Note; (5)
Imaging Narrative; (6) Laboratory Report Narrative; (7) Pathology
Report Narrative; and (8) Procedures Note.
We wish to further clarify that we have adopted the new Clinical
Notes Data Class in order to enable capture and exchange of free text
clinical information categorized by the above clinical note types. We
refer commenters to our response in section IV.B.1.d of the final
rule--Clinical Notes C-CDA Implementation Specification--that addresses
the relationship of the clinical notes Data Class to C-CDA
implementation specification.
We also seek to clarify two points. First, that these clinical note
types are content exchange standard agnostic. They should not be
interpreted or associated with the specific C-CDA Document Templates
that may share the
[[Page 25675]]
same name. Secondly, we clarify that these note types are required to
be represented in their plain-text form when included in various
content exchange standards (e.g., C-CDA, FHIR) as may be applicable to
the certification criteria in which the USCDI is referenced.
v. Provenance
We proposed (84 FR 7442) for the USCDI v1 to include a new Data
Class, entitled ``provenance.'' As we indicated, stakeholders \35\ have
identified ``provenance'' as valuable for interoperable exchange.
Stakeholders also referenced the provenance of data as a fundamental
need to improve the trustworthiness and reliability of the data being
exchanged. Provenance describes the metadata, or extra information
about data, that can help answer questions such as who created the data
and when.
---------------------------------------------------------------------------
\35\ https://www.healthit.gov/topic/interoperability/trusted-exchange-framework-and-common-agreement.
---------------------------------------------------------------------------
In the Proposed Rule, we noted that the inclusion of ``provenance''
as a Data Class in the USCDI v1 would also complement the Cures Act
requirement in section 4002(a) to support the exchange of data through
the use of APIs. This approach differs from the exchange of data via
the C-CDA. While C-CDAs are often critiqued due to their relative
``length,'' the C-CDA represents the output of a clinical encounter and
includes relevant context. The same will not always be true in an API
context. APIs facilitate the granular exchange of data and, as noted in
the original 2015 Edition final rule, offer the potential to aggregate
data from multiple sources using a web or mobile application (80 FR
62675). The inclusion of provenance would help retain the relevant
context so the recipient can better understand the origin of the data.
We proposed to further delineate the provenance Data Class into
three Data Elements: ``the author,'' which represents the person(s) who
is responsible for the information; ``the author's time stamp,'' which
indicates the time the information was recorded; and ``the author's
organization,'' which would be the organization the author is
associated with at the time they interacted with the data (84 FR 7442).
We indicated that we identified these three Data Elements as
fundamental for data recipients to have available and noted that they
are commonly captured and currently available through standards. We
requested comment on the inclusion of these three Data Elements and
whether any other provenance Data Elements, such as the identity of the
individual or entity the data was obtained from or sent by (sometimes
discussed in standards working groups as the provenance of the data's
``last hop''), would be essential to include as part of the USCDI v1
standard. We acknowledged that there is currently work to help define
provenance in a standard robust manner, and that we anticipated
adopting the industry consensus once it became available.
Comments. Commenters overwhelmingly supported the addition of
provenance as a new Data Class for USCDI v1. Several commenters stated
that the proposed elements were insufficient for the purpose of audit
logs for use and disclosure of health data, citing the existing
standard specification ASTM E2147.\36\ Other commenters stated that
these proposed elements did not apply to all use cases of exchanged
data and requested clarification regarding applicability, including
whether provenance would have to be created for elements created before
the implementation deadline of USCDI v1. Because this is a new Data
Class, some commenters also requested additional time to adopt and
implement this new requirement. Some commenters stated that there could
be ambiguity in designating ``author'' for certain clinical information
such as patient-reported medications, while in certain other cases,
there could be multiple authors for the same clinical information, such
as clinical notes. Additionally, some commenters suggested that the
``author'' be limited to only a limited set of Data Elements and not to
all the Data Elements. Another commenter specifically addressed several
concerns related to the definition of ``author'' for this purpose.
Commenters specifically stated they understood author to be the person
entering the data into the EHR, but noted that data may also be
historical, captured from a device, started by a patient and completed
by clinical staff, entered by a patient, entered by resident/students
working under a supervising physician, or reported by a patient. The
commenter noted that there are additional documentation scenarios such
as dictation to scribes or other medical staff, which conflate
``responsibility'' for authorship, and that defining author for every
Data Element can be complex. Finally, one health IT developer
recommended a 36-month implementation period to begin only after test
procedures, implementation guides, and test and validation tools are
available and after ONC has consulted at least five CEHRT developers.
---------------------------------------------------------------------------
\36\ https://www.astm.org/Standards/E2147.htm.
---------------------------------------------------------------------------
Response. We acknowledge that these Data Elements may not be able
to fully support the needs of all use cases, but we believe their
adoption will improve the trustworthiness and reliability of data being
exchanged. For this Data Class, it appears that many commenters over-
interpreted our proposal and the effect of having these data in the
USCDI. As we noted earlier, the adoption of the USCDI standard and its
Data Classes and elements is not specific as to its usage within a
setting of care, a health care specialty, or by a specific category of
health IT user. Rather it applies to certified health IT's ability to
send and receive those Data Elements without requirements regarding
functionality, user interface, or the use of those Data Elements in
exchange. Therefore, with respect to our reference to provenance data
in the USCDI, we have no preset notion or explicit upfront requirement
for how this data should be used. We believe that having provenance
data is highly impactful, essential for trustworthy interoperability,
and will generate greater value for stakeholders as they identify new
ways to put this data to use.
Regarding ``author'' as a Data Element within the provenance Data
Class, we agree that significant practical scope challenges may arise.
Our analysis of the concerns raised by commenters identified a risk of
unintended burden and potential risk of error and misattribution
associated with this particular Data Element. In most use cases, the
inclusion of author organization and author time stamp is sufficient to
convey provenance. As a result, we have not finalized the ``author'' as
a required Data Element within the provenance Data Class in USCDI.
However, we understand that for exchanging certain data elements, such
as ``clinical notes,'' it is critical to also send the ``author''
information if available. Our analysis of the various content exchange
standards and specifications (e.g., C-CDA and FHIR) indicates that even
though the ``author'' Data Element is not explicitly required in USCDI,
the health IT specifications in which USCDI Data Elements are
represented also set specific data element requirements for certain
contexts. For example, in the context of clinical notes, these content
exchange standards require health IT systems to be capable of
exchanging ``author'' information when it is available. Further,
``author'' is treated as a ``Must Support'' data element in the FHIR US
Core Implementation Guide STU 3.1.0 and has a ``SHALL'' constraint
(with
[[Page 25676]]
appropriate null flavor value) in the C-CDA 2.1. As we have noted
previously, we believe that the proposed 24-month timeline for updating
certified health IT to comply with the new USCDI standard in Sec.
170.213 is an adequate implementation timeline and will maintain this
requirement as finalized earlier in this section.
Therefore, in consideration of the comments received, we have
finalized the provenance Data Class in the USCDI v1 and the following
two Data Elements:
``author time stamp,'' which indicates the time the
information was recorded; and
``author organization,'' which would be the organization
the author is associated with at the time they interacted with the
data.
We believe these two provenance Data Elements, ``author
organization'' and ``author time stamp,'' within the USCDI v1, which
are also used in the C-CDA and FHIR-based certification criteria we
have adopted that incorporate the USCDI, will serve as a foundation on
which industry stakeholders can subsequently work together to build out
additional provenance data requirements in the USCDI. As noted above,
we have not finalized the proposed Data Element ``the author,'' which
represents the person(s) who was responsible for the information.
vi. Medication Data Request for Comment
In the Proposed Rule, we proposed (84 FR 7443) that the USCDI v1
``Medication'' Data Class include two constituent Data Elements within
it: Medications and Medication Allergies. With respect to the latter,
Medication Allergies, we requested comment on an alternative approach.
This approach would remove the Medication Allergies Data Element from
the Medication Data Class and add it to a new Data Class titled
``Substance Reactions,'' which would include the concept of
``Medication Allergies.'' The new ``Substance Reactions'' Data Class
would include the following Data Elements: ``Substance'' and
``Reaction,'' and include SNOMED CT as an additional applicable
standard for non-medication substances.
Comments. The majority of commenters supported the creation of a
new Data Class ``Substance Reactions'' but requested we preserve the
Medication Allergy element because of patient safety concerns related
to the adoption of an entirely new Data Element. One commenter
supported the change but recommended the new Data Class name be aligned
with the HL7 FHIR resource ``AllergyIntolerance.'' This would also be
consistent with the C-CDA 2.1 ``Allergy and Intolerance'' section.
Response. We thank the commenters for their input. While we
appreciate that there may be some risk associated with the adoption of
a new Data Element, we believe this alternative approach better aligns
with other standards representing substance reactions, including
medication allergies, and this alignment enhances patient safety.
Additionally, we agree with the commenter who suggested renaming this
new Data Class to align with FHIR and C-CDA approaches.
In consideration of comments, we have finalized the creation of a
Data Class in USCDI v1 entitled ``Allergies and Intolerances,'' instead
of ``Substance Reactions'' from the original USCDI v1 proposal. The
Allergies and Intolerances Data Class in USCDI v1 consists of the
following Data Elements: ``Substance--(Medication),'' ``Substance--
(Drug Class),'' and ``Reaction.'' ``Substance--(Medication)'' must be
represented by RxNorm codes and ``Substance--(Drug Class)'' must be
represented by SNOMED CT codes. The addition of the ``Substance--(Drug
Class)'' better represents when an individual may have a reaction to an
entire drug class as opposed to a specific medication. Additionally, we
believe having the Allergy and Intolerances Data Class separated from
the Medication Class will accommodate potential additions of other
substance Data Elements such as food, environmental, and biologic
agents. The Data Element ``Reaction'' is meant to include, but is not
limited to, medication allergies. As the USCDI is updated over time to
include substances other than medications, we can also see the need to
have substance reactions updated as part of this Data Class. To reflect
this change, we have updated the terminology in the regulatory text in
Sec. 170.315 to remove ``medication allergy'' and replace with
``allergy and intolerance.''
c. USCDI Standard--Relationship to Content Exchange Standards and
Implementation Specifications
In recognition of the evolution of standards over time and to
facilitate updates to newer versions of standards, we proposed (84 FR
7443) that the USCDI v1 (Sec. 170.213) would be agnostic as to
``content exchange'' standard. As we noted, the USCDI v1 establishes
``data policy'' and does not directly associate with the content
exchange standards and implementation specifications which, given a
particular context, may require the exchange of the entire USCDI, a
USCDI Data Class, or some or all of the Data Elements within a given
Data Class or classes. We further indicated that, to our knowledge, all
Data Classes in the USCDI v1 can be supported by commonly used
``content exchange'' standards, including HL7 C-CDA Release 2.1 and
FHIR.
We received no comments on this specific proposal and we have
finalized our proposal to make USCDI v1 agnostic as to ``content
exchange standard'' as described.
2. Clinical Notes C-CDA Implementation Specification
In conjunction with our proposal to adopt the USCDI v1, we proposed
to adopt the HL7 CDA[supreg] R2 IG: C-CDA Templates for Clinical Notes
R1 Companion Guide, Release 1 in Sec. 170.205(a)(5) (``C-CDA Companion
Guide''). The C-CDA Companion Guide provides supplemental guidance and
additional technical clarification for specifying data in the C-CDA
Release 2.1.\37\ As we noted in the Proposed Rule (84 FR 7443), the
proposed USCDI v1 included new Data Classes, such as ``clinical
notes,'' which were further supported through the C-CDA Companion
Guide. For example, the C-CDA Companion Guide provides specifications
for clinical notes by indicating that clinical notes should be recorded
in ``note activity'' and requires references to other discrete data,
such as ``encounters.'' The C-CDA Companion Guide also enhances
implementation of the updated 2015 Edition certification criteria that
reference the C-CDA Release 2.1 (Sec. 170.205(a)(4)). As noted by
stakeholders, the C-CDA Release 2.1 includes some optionality and
ambiguity with respect to Data Element components, such as the
locations and value sets. We attempted to address some of this
optionality by clarifying requirements using Certification Companion
Guides (CCGs) \38\ and by specifying in the CCDS definition where
certain data should be placed in the C-CDA Release 2.1 templates (e.g.,
``goals'' in the goals section).\39\ The C-CDA Companion Guide, which
was released in August, 2015, provides similar, but additional C-CDA
implementation structure. For example, race and ethnicity are required
Data Elements in the USCDI and must be included in C-CDA exchanges if
known, or they may be marked with a nullFlavor value ``UNK'' (unknown)
if not known. The
[[Page 25677]]
C-CDA Release 2.1 is unclear on the location and value set, but the C-
CDA Companion Guide clarifies the location and value set. We noted in
the Proposed Rule that the adoption of the C-CDA Companion Guide would
align with our goal to increase the use of consistent implementation of
standards among health IT developers and improve interoperability. We
proposed to adopt this C-CDA Companion Guide to support best practice
implementation of USCDI v1 Data Classes and 2015 Edition certification
criteria that reference C-CDA Release 2.1 (Sec. 170.205(a)(4)). The
criteria include:
---------------------------------------------------------------------------
\37\ http://www.hl7.org/implement/standards/product_brief.cfm?product_id=447.
\38\ https://www.healthit.gov/topic/certification-ehrs/2015-edition-test-method.
\39\ https://www.healthit.gov/sites/default/files/topiclanding/2018-04/2015Ed_CCG_CCDS.pdf.
---------------------------------------------------------------------------
``transitions of care'' (Sec. 170.315(b)(1));
``clinical information reconciliation and incorporation''
(Sec. 170.315(b)(2));
``care plan'' (Sec. 170.315(b)(9));
``view, download, and transmit to 3rd party'' (Sec.
170.315(e)(1));
``consolidated CDA creation performance'' (Sec.
170.315(g)(6)); and
``application access--all data request'' (Sec.
170.315(g)(9)).
We proposed, as a Maintenance of Certification requirement for the
real world testing Condition of Certification requirement, that health
IT developers with health IT certified to the six above-identified
certification criteria prior to the effective date of a subsequent
final rule would have to update such certified health IT to the
proposed revisions (84 FR 7443).\40\ We further proposed as a
Maintenance of Certification requirement for the real world testing
Condition of Certification requirement, that health IT developers would
be required to provide the updated certified health IT to all their
customers with health IT previously certified to the identified
criteria no later than 24 months after the effective date of a final
rule (84 FR 7443). For the purposes of meeting that compliance
timeline, we indicated that we expected health IT developers to update
their certified health IT without new mandatory testing and notify
their ONC-ACB on the date at which they have reached compliance.
Developers would also need to factor these updates into their next real
world testing plan as discussed in section VII.B.5 of the Proposed
Rule.\41\
---------------------------------------------------------------------------
\40\ We proposed to codify this requirement in Sec.
170.405(b)(4) (84 FR 7596).
\41\ The finalized real world testing plan requirements,
codified in Sec. 170.405(b)(2) are discussed in section VII.B.5 of
this final rule.
---------------------------------------------------------------------------
Comments. One commenter supported the use of C-CDA for Clinical
Notes. One commenter sought clarity on testing for Clinical Notes
conformance to C-CDA 2.1, noting that all C-CDA documents are the same
except for the document header. Two commenters recommended review of
the Common Well Concise Consolidated CDA white paper.
Response. We thank the commenters for their suggestions and
support. During the past few months, industry stakeholders updated the
C-CDA Companion Guide to a newer version to best address how clinical
notes should be handled in the C-CDA. In consideration of the update to
the C-CDA Companion Guide and the comments, we have finalized the
adoption of the most up-to-date version, HL7 CDA R2 IG: C-CDA Templates
for Clinical Notes STU Companion Guide, Release 2 in Sec.
170.205(a)(5) (``C-CDA Companion Guide'') and have incorporated by
reference in Sec. 170.299. This includes adoption of the USCDI v1 and
the associated Data Classes.
In order to align ``clinical information reconciliation and
incorporation'' (Sec. 170.315(b)(2)) with the updated Data Classes in
the USCDI v1 as proposed in 84 FR 7441, we have replaced the
``medication allergies'' data element in Sec. 170.315(b)(2)(iii)(D)(2)
criterion to ``Allergies and Intolerances'' Data Class and require
reconciliation of all the data elements in ``Allergies and
Intolerances'' Data Class, which includes Substance (Medication),
Substance (Drug Class), and Reaction Data Elements. We have revised the
regulation text (Sec. 170.315(b)(2)) to align with this change. We
decline to accept the recommendation to adopt the CommonWell
specification as we believe the criterion is best met following the C-
CDA specification published by HL7.
We have additionally finalized the timeline for the update to the
use of the C-CDA companion guide of 24 months after the publication
date of this final rule for the following criteria:
``transitions of care'' (Sec. 170.315(b)(1));
``clinical information reconciliation and incorporation''
(Sec. 170.315(b)(2));
``care plan'' (Sec. 170.315(b)(9));
``view, download, and transmit to 3rd party'' (Sec.
170.315(e)(1));
``consolidated CDA creation performance'' (Sec.
170.315(g)(6)); and
``application access--all data request'' (Sec.
170.315(g)(9)).
3. Unique Device Identifier(s) for a Patient's Implantable Device(s) C-
CDA Implementation Specification
We noted in the Proposed Rule (84 FR 7443) our awareness of a
recently published implementation guide (IG) by HL7 that provides
further guidance on the unique device identifier (UDI) requirements.
The Health Level 7 (HL7) CDA R2 Implementation Guide: C-CDA
Supplemental Templates for Unique Device Identification (UDI) for
Implantable Medical Devices, Release 1-US Realm (UDI IG Release 1),
identifies changes needed to the C-CDA to better facilitate the
exchange of the individual UDI components in the health care system
when devices are implanted in a patient. The UDI components include the
Device Identifier (DI) and the following individual production
identifiers: The lot or batch number, serial number, manufacturing
date, expiration date, and distinct identification code. As this new IG
had been recently published, we requested comment on whether we should
add this UDI IG as a requirement in Sec. 170.299(f)(35) for health IT
to adopt in order to meet the requirements for content exchange using
C-CDA. In addition, we indicated that we did not have a reliable basis
on which to estimate how much it would cost to meet the requirements
outlined in the UDI IG; and, therefore, we requested comment on the
cost and burden of complying with this proposed requirement.
Comments. Commenters unanimously supported adoption of the UDI IG
Release 1 as a new requirement for health IT to meet the requirements
for the USCDI UDI Data Class. One commenter requested additional
guidance regarding the determination of the ``person responsible for
the information'' contained in the ``Device'' entry. None of the
commenters provided a basis of estimate for the cost to meet the
requirements outlined in the UDI IG Release 1.
Response. We thank the commenters for their support. As we noted
earlier, the adoption of the USCDI standard and its Data Classes and
elements is not specific as to its usage within a setting of care, a
health care specialty, or by a specific category of health IT user;
rather it applies to certified health IT's ability to send and receive
those Data Elements without requirements regarding functionality, user
interface, or the use of those Data Elements in exchange. Therefore, we
do not specify who must enter such data.
We note also that the C-CDA Companion Guide referenced in
subsection (d) below of this final rule now includes the content of the
UDI IG Release 1 named in the Proposed Rule. In consideration of
comments, we have finalized the proposed UDI Data Class within the
USCDI v1, and have adopted the UDI Organizer Template defined in the
UDI IG Release 1 and subsequently published as Appendix B of the
HL7[supreg]
[[Page 25678]]
CDA[supreg] R2 IG: C-CDA Templates for Clinical Notes, Release 2.1
Companion Guide, Release 2--US Realm, October 2019, as a new
requirement for Health IT Modules to meet the requirements for C-CDA-
based exchange. We note that the UDI Organizer Template, though
subsequently published in Appendix B of the HL7 CDA R2 IG: C-CDA
Templates for Clinical Notes STU Companion Guide, Release 2, September
2019, remains substantially unchanged from its previous publication in
the UDI IG Release 1 in November 2018 and has been thoroughly reviewed
and subjected to balloting and a public comment process.
4. Electronic Prescribing Criterion
We proposed to adopt a new version of the NCPDP SCRIPT standard in
45 CFR 170.205(b)(1), specifically NCPDP SCRIPT standard version
2017071 (84 FR 7444). Because we proposed to adopt a new standard for
electronic prescribing (e-Rx), we also proposed to adopt a new
certification criterion in Sec. 170.315(b)(11) for the proposed e-Rx
standard to replace the old standard in Sec. 170.315(b)(3). The
proposed new certification criterion reflected our proposed adoption of
NCPDP SCRIPT standard version 2017071 as well as all transactions
adopted for the CMS Medicare Part D E-prescribing Program (84 FR
23832). These proposals were made to realign ONC's Health IT
Certification Program (Program) policies with those of CMS' Part D E-
prescribing rules. ONC and CMS have historically aligned standards
adopted under their programs such as those for e-Rx and medication
history (MH) to ensure that entities regulated under both schemes can
comply with the different programs' requirements. For this reason, we
stated that should our proposal to adopt the new e-Rx criterion (Sec.
170.315(b)(11)) be finalized prior to January 1, 2020, we also proposed
to permit continued certification to the current 2015 Edition
``electronic prescribing'' criterion (Sec. 170.315(b)(3)) that
references NCPDP SCRIPT standard version 10.6 for the period of time in
which that version of the NCPDP SCRIPT standard would continue to be
used in the CMS Medicare Part D E-prescribing Program or the CMS
Promoting Interoperability Programs. Finally, we proposed in 84 FR 7445
that once NCPDP SCRIPT standard version 10.6 is no longer used in those
Programs, we would no longer permit certification to that criterion and
would remove it from the Code of Federal Regulations, and that we would
consider setting an effective date for such actions in a subsequent
final rule based on stakeholder feedback and CMS policies at the time.
In addition to continuing to reference the current transactions
included in Sec. 170.315(b)(3), in keeping with CMS' Modernizing Part
D and Medicare Advantage To Lower Drug Prices and Reduce Out-of-Pocket
Expenses final rule (84 FR 23832), we also proposed in 84 FR 7445 and
in Sec. 170.315(b)(11) to require the support of all of the NCPDP
SCRIPT standard version 2017071 transactions CMS has adopted for the
Part D E-prescribing regulations in 42 CFR 423.160(b)(2)(iv). Given the
January 1, 2020 effective date in CMS rulemaking (83 FR 16440) and the
effective date of this final rule, we have finalized our proposed
update to the new version of the standard for the electronic
prescribing criterion in Sec. 170.315(b)(3) instead of creating a new
criterion as proposed in 84 FR 7427 in Sec. 170.315(b)(11). Unlike
other criteria in this final rule that allow testing to either version
of a required standard until 24 months after the publication date of
this final rule, we will not allow certification testing to version
10.6 of the NCPDP SCRIPT standard, as the implementation date for CMS'
new Part D E-prescribing Program of January 1, 2020 has passed.
However, based on stakeholder feedback, we have finalized a transition
period in 45 CFR 170.405(b)(4)(ii) of 24 months from the date of
publication of this final rule for certification so developers may test
and certify to the updated criterion with all associated transactions.
Comments. The majority of commenters were supportive of our
proposal and recommended moving to the NCPDP SCRIPT standard version
2017071 for the e-Rx certification criterion in alignment with CMS'
adoption of the standard for the Part D E-prescribing Program. However,
a number of commenters expressed concern that while EHRs or other
electronic prescribing systems may become certified, pharmacy
information systems (PIS) lack a similar certification program and
associated standards and technical capability requirements, thus
creating a mismatch between the e-prescribing system requirements for
EHR users and PIS users. Several commenters specifically noted that
PIS, which send or receive these transactions, are not required to
adopt the capability to support these transactions as they are out of
scope for the Program.
Response. First, we note that the comments suggesting that
pharmacies on the sending or receiving end of Part D e-Rx transactions
are not required to utilize NCPDP SCRIPT standard version 2017071
transactions are inaccurate. To the extent that a pharmacy conducts
electronic prescribing with prescribers e-prescribing Part D covered
drugs for Part D eligible individuals, those pharmacies are required to
use the NCPDP SCRIPT version 2017071 standard. While there may not be
2015 Edition certification criteria to which pharmacy information
systems can be certified, the Part D rules require support of the
standard under the Part D E-prescribing Program. Thus, we believe the
mismatch concerns raised by commenters are unfounded. As a general
matter, Part D prescribers need health IT systems capable of conducting
compliant transactions (regardless of ONC certification) and so too do
Part D receiving pharmacies. ONC health IT certification will provide
an added layer of assurance for Part D prescribers that their e-Rx
systems have been tested and certified as being capable of accurately
conducting the adopted NCPDP SCRIPT standard version 2017071
transactions.\42\
---------------------------------------------------------------------------
\42\ https://www.govinfo.gov/content/pkg/FR-2015-10-16/pdf/2015-25597.pdf.
---------------------------------------------------------------------------
In addition, we received several comments related to the readiness
of PIS for specific transactions beyond those defined for Part D. We
include these comments as applicable in the discussion of each
transaction below. We reiterate that PIS are outside the scope of the
ONC Health IT Certification Program, and we acknowledge the challenge
of pharmacy readiness to support all transactions at this time, but if
they conduct e-Rx for part D covered drugs prescribed to Part D
eligible Medicare beneficiaries, they will be required to use the
standard we are adopting for our program by the Medicare Part D e-Rx
Program--so if they do e-prescribing at all, we expect that they will
be able to conduct transactions using the standard adopted here.
Generally, the goal of certification is to ensure that Health IT
Modules voluntarily submitted for the Program are capable of conducting
the transactions as specified. This ensures that providers have the
capability to use the certified product for these transactions where
feasible. For this reason, we have finalized the transactions as
described below for certified Health IT Modules and encourage pharmacy
information system developers to advance their capacity to support a
nationwide network of fully interoperable pharmacy information systems.
Comments. As noted, the majority of commenters were supportive of
the proposal to remove the 2015 Edition
[[Page 25679]]
certification criterion (codified in Sec. 170.315(b)(3)) that
references NCPDP SCRIPT standard version 10.6 and replace it with an
updated e-Rx criterion (proposed to be codified in Sec.
170.315(b)(11)). Commenters requested that ONC work with CMS on a
smooth transition and timeline that would allow adequate time for the
development, testing, and full adoption of these updates. A number of
commenters stated that the NCPDP SCRIPT standard version 2017071 is not
backward compatible with NCPDP SCRIPT standard version 10.6, and
therefore there should be no transition period where both standards are
applicable. Commenters sought clarity on the timing of the change and
expressed concerns that developers and providers may face operational
issues in their adoption of version 2017071 of the NCPDP SCRIPT
standard by January 1, 2020. Commenters recommended that ONC allow
certification timelines that support compliance with Part D while
allowing adequate time to mitigate the risk associated with the
additional requirements for certification to the proposed criterion.
Response. We appreciate the support expressed by commenters as well
as the concern about maintaining alignment between required standards
across HHS. We note that the CMS requirement for Part D e-Rx
transactions includes a compliance date of January 1, 2020, and that
industry feedback notes a consistent and deliberate move toward
readiness for the adoption of the new standard for Part D e-Rx,
including by health IT industry leaders supporting pharmacy
implementation. We believe that this overall industry readiness
supports our adoption of the update to the standard for certification
purposes and to be in alignment with the required standard update for
Part D e-Rx purposes. In response to the request for a smooth
transition and continuity of certification for health care providers,
we have finalized a revision to the existing criterion in Sec.
170.315(b)(3) rather than removing and replacing the criterion. In
order to support the transition to the new standard for Part D, at the
request of stakeholders, ONC issued guidance \43\ in the third quarter
of CY2019 stating, ``. . . developers of 2015 Edition certified Health
IT Modules certified to the e-prescribing criterion adopted at 45 CFR
170.315(b)(3) are permitted to update their products to use the NCPDP
SCRIPT standard version 2017071 to meet CMS' compliance requirements .
. .'' This guidance also noted that ONC would discontinue certification
of new products to the electronic prescribing certification criterion
using version 10.6 of the NCPDP SCRIPT standard as of January 1, 2020.
---------------------------------------------------------------------------
\43\ For Part D covered drugs prescribed for Part D eligible
individuals. ONC Electronic Prescribing Certification Companion
Guide: https://www.healthit.gov/test-method/electronic-prescribing.
---------------------------------------------------------------------------
In consideration of the comments we received, we have finalized our
proposal to update the electronic prescribing (e-Rx) NCPDP SCRIPT
standard used for electronic prescribing in the 2015 Edition to NCPDP
SCRIPT standard version 2017071, which results in a new e-Rx standard
becoming the baseline for certification. As the effective date of this
final rule will occur after January 1, 2020, we have not finalized our
proposal to permit new products to continue to be certified to the
prior standard until the January 1, 2020 date. Instead, we discontinued
certification of new products to the former electronic prescribing
criterion using the NCPDP SCRIPT standard version 10.6 to align with
CMS requirements. We have finalized this update as a modification to
the existing certification criterion rather than as a separate new
certification criterion to allow for a smooth transition, and to allow
for continuity with the certification(s) issued to Health IT Modules
for Sec. 170.315(b)(3) prior to January 1, 2020 that are updated under
the ONC guidance. This approach will also continue to allow for
compliance with the January 1, 2020 timeline for CMS' Medicare Part D
e-Rx and Medication History standards.
As noted by commenters, we understand that there is a lack of
backward compatibility between the two standards. In order to allow for
a reasonable transition period to certification to the full set of
NCPDP SCRIPT transactions and other requirements defined in the updated
e-Rx certification criterion, we have framed our Maintenance of
Certification in section 45 CFR 170.405(b)(5)(ii) with flexibility that
will allow health IT developers up to 24 months from the date of
publication of this final rule to test and certify to the updated
criterion reflective of all NCPDP SCRIPT 2017071 transactions to
demonstrate full conformance with the updated criterion. After January
1, 2020, use of the NCPDP SCRIPT 10.6 standard will be prohibited under
the Part D program, so we do not expect or anticipate health IT systems
certified to Sec. 170.315(b)(3) will conduct Part D transactions using
that standard. We also recognize, however, for the purposes of
maintaining a product certificate with Sec. 170.315(b)(3) in its
scope, that these 24 months from the date of publication from this
final rule enable continued compliance and oversight associated with
other capabilities in Sec. 170.315(b)(3) that are not applicable for
Part D, and for which conformance is still required.
We have finalized this 24-month period for the update for this
criterion under the real world testing provisions in Sec.
170.405(b)(5) as follows:
Electronic Prescribing. A health IT developer with health
IT certified to Sec. 170.315(b)(3) prior to June 30, 2020, must:
[cir] Update their certified health IT to be compliant with the
revised versions of this criterion adopted in Sec. 170.315(b)(3)(ii);
and
[cir] Provide its customers of the previously certified health IT
with certified health IT that meets paragraph (b)(5)(i) of this section
by May 2, 2022.
a. Electronic Prescribing Standard and Certification Criterion
Comments. Commenters expressed concerns about standardization
generally within the context of e-prescribing. Several commenters
expressed concern about using the NCPDP SCRIPT standard version
2017071, the RxNorm standard, as a requirement for e-prescribing, and
other standards such as Fast Healthcare Interoperability Resources
(FHIR). One commenter further stated that only inventory (packaging or
unit dose strength) codes are standardized in RxNorm, and that drug
regimens should be standardized and made computable in RxNorm for
safety reasons. Another commenter noted that RxNorm does not index
brand names exhaustively with a single unique ID for each branded drug,
but that current indexing only allows for generic-level
interoperability and only at unit dose level. One commenter expressed
concern that the criterion as proposed does not appear to support
medication assisted treatment (MAT) for opioid use disorder (OUD) and
other long-acting medications. Another commenter stated a hope that
standards such as the NCPDP SCRIPT version 2017071 standard can ease
data integration into the workflow, lessen burden, and help achieve
greater compliance with policy and legal requirements for querying
State prescription drug monitoring programs (PDMP). Another commenter
supported the adoption of the NCPDP SCRIPT standard version 2017071
because the standard supports the prescribing of compound medications
and the sig (i.e., instructions) field is not limited to 140
characters.
[[Page 25680]]
Some commenters also provided suggestions to improve the NCPDP
SCRIPT 2017071 standard and its availability to the public by the
standards developing organization. Another commenter stated that
today's NCPDP standards are not in an API-ready format, and recommended
CMS and ONC collaborate with NCPDP to explore API FHIR standards
specific to the HL7 Da Vinci Project for a January 2022 effective date
or later. A few commenters stated that because many NCPDP standards are
not openly accessible and require a paid membership to obtain the
technical specifications, our adoption could limit widespread adoption
and a standardized implementation nationwide. Several commenters
suggested that ONC adopt FHIR as a standard for the Program, and for
the e-Rx criterion specifically. We also received several comments that
are out of scope which are not addressed in this rulemaking.
Response. We appreciate the commenters' consideration of the
standards. We note that RxNorm is a standard maintained by the National
Library of Medicine (NLM). ONC adopted RxNorm to represent medication
information as a vocabulary standard in Sec. 170.207(d) (80 FR 62612).
We encourage all developers who have experience with, and feedback
relevant to, RxNorm to contact NLM. As a reminder, RxNorm is considered
a minimum standard code set under the Program, and developers are
permitted to upgrade their products to comply with a newer version of
RxNorm without adversely affecting a product's certification status
pursuant to 45 CFR 170.555(b)(2) as long as no other law prohibits such
action.
In reference to the OUD prevention and treatment-related concerns
that commenters expressed, we note that the NCPDP SCRIPT 2017071
standard does support the exchange of medicines used in medication-
assisted treatment (MAT) for opioid use disorder treatment purposes. An
electronic prescription of controlled substances transaction containing
a MAT drug such as buprenorphine can be sent from a prescriber to a
pharmacy through the specified transactions, and the updated Sec.
170.315(b)(3) criterion also requires the inclusion of a reason for the
prescription using or elements, or
optionally, the technology must be able to receive and transmit the
reason for the prescription using the element. In
addition, the RxHistoryRequest transaction contains a patient consent
indicator that the receiving entity must evaluate for accurate
reporting. We are also aware that many PDMPs across the country accept
reporting of medication history transactions containing buprenorphine,
naltrexone, and other medications that could be used in the treatment
of OUD.
We thank commenters for their input related to improvements that
could be made to the NCPDP SCRIPT version 2017071 standard, however
NCPDP is a member-driven standards developing organization that
requires membership in order to participate in standards developing and
to access standards and implementation guides. We appreciate the
suggestion to provide a direct link to the appropriate NCPDP SCRIPT
standard implementation guide, but we have no authority over the
business processes of standards developing organizations like NCPDP. We
encourage any and all participants with an interest in improving the
standard to engage with NCPDP. Regarding the recommendation for ONC to
collaborate with NCPDP to explore FHIR, we appreciate the suggestion
and support any advancements in technical standards and frameworks that
support interoperability. At this time, NCPDP SCRIPT standard version
2017071 has not been mapped to FHIR, but ONC will continue to monitor
the industry for opportunities to align the ONC Health IT Certification
Program with industry developments.
Comments. Five commenters fully supported all proposed transactions
and requirements detailed in the Proposed Rule. The vast majority of
commenters noted concerns about the proposed criterion specific to the
transactions proposed for adoption in the Sec. 170.315(b)(11) e-Rx
certification criterion; details in support or not in support of
adoption as proposed are further detailed for each type of transaction
below. As a whole, the primary concerns for the transactions and
requirements as proposed include the following: (1) EHRs are required
to comply with the new transactions and requirements, while receiving
pharmacy information systems are not; (2) lack of pharmacy adoption and
readiness, as sufficient adoption should occur prior to making the
transactions required; and (3) implementation of the proposed
transactions and requirements is resource intensive, if not
prohibitive, in order to meet the January 1, 2020 deadline set by CMS.
Several commenters suggested either an extension or that certain
transactions should be made optional.
Response. We appreciate all of the public comments and have
modified the transactions to specify which transactions are finalized
as required for Health IT Modules for purposes of obtaining or
retaining certification to Sec. 170.315(b)(3), which are optional for
Health IT Modules for purposes of obtaining or retaining certification
to Sec. 170.315(b)(3), and any other Sec. 170.315(b)(3) requirements
below. Additional public comment received and related responses are
grouped below based on the comment's relation to the specific
transactions. We note that ``optional'' for the purposes of
certification does not mean, and should not be interpreted as,
``optional'' for Part D E-prescribing Program compliance. To the extent
that prescribers and pharmacies conduct electronic prescribing with
Part D covered drugs prescribed for Part D eligible individuals they
will be required to use the NCPDP SCRIPT 2017071 standard to conduct
those transactions under the Part D E-prescribing Program. Thus, a
transaction designated as ``optional'' for the purposes of
certification means a health IT developer can elect to have that
transaction explicitly tested as part of certification for its product
or can choose not to do so--either will allow its product to be
certified to Sec. 170.315(b)(3). We reiterate that comments regarding
CMS' January 1, 2020 timeline are out of scope as we cannot change CMS'
policy or its timeline.
b. Electronic Prescribing Transactions
In addition to adopting the NCPDP SCRIPT version 2017071 standard
for the transactions that are listed in the current ``electronic
prescribing'' criterion (Sec. 170.315(b)(3)), we also proposed to
adopt and require conformance to all of the NCPDP SCRIPT version
2017071 standard transactions CMS adopted in 42 CFR 423.160(b)(2)(iv).
We proposed this updated 2015 electronic prescribing criterion to
therefore include the following transactions:
i. Create and Respond to New Prescriptions (NewRx, NewRxRequest,
NewRxResponseDenied)
We proposed in 84 FR 7444 to enable a user to perform the related
electronic transactions for NewRx, NewRxRequest and
NewRxResponseDenied. A NewRx transaction is a new prescription from a
prescriber to a pharmacy so that it can be dispensed to a patient. A
NewRxRequest is a request from a pharmacy to a prescriber for a new
prescription for a patient. A NewRxResponseDenied is a denied response
to a previously sent NewRxRequest (if approved by the
[[Page 25681]]
prescriber, a NewRx would be sent instead). A NewRxResponseDenied
response may occur when the NewRxRequest cannot be processed or if
information is unavailable.
Comments. While the NewRx transaction received unanimous support as
a required transaction for adoption in the updated Sec. 170.315(b)(3)
criterion, the vast majority of commenters opposed adopting the
NewRxRequest and NewRxResponseDenied transactions as required
transactions primarily due to a lack of adoption by the PIS involved in
the exchange. Several commenters stated that the NewRxRequest and
NewRxResponseDenied is not yet in broad use. A commenter who supported
adoption of NewRxRequest and NewRxRequestDenied believed that they may
be beneficial for electronic prescribing of controlled substances
(EPCS) and noted that pharmacies have expressed interest in
implementation.
Response. In consideration of public comments, we have adopted
NewRx as a required transaction, and NewRxRequest and
NewRxResponseDenied as optional transactions in the updated Sec.
170.315(b)(3) electronic prescribing criterion. We have finalized these
latter two transactions as optional in response to commenters' concerns
regarding a lack of adoption by the PIS that would be involved in the
exchange. Additionally, we note that pursuant to the certification
criterion, health IT presented for certification must be capable of
including the reason for the prescription as referenced in the updated
Sec. 170.315(b)(3)(ii) or Sec. 170.315(b)(3)(ii)(D) in the NewRx
transaction.
ii. Request and Respond to Change Prescriptions (RxChangeRequest,
RxChangeResponse)
We proposed in 84 FR 7444 to enable a user to perform the related
electronic transactions for RxChangeRequest and RxChangeResponse. An
RxChangeRequest transaction originates from a pharmacy and may be sent
to a prescriber to: Request a change in the original prescription (new
or fillable); validate prescriber credentials; request a review by a
prescriber of the drug requested; or obtain prior authorization from
the payer for the prescription. An RxChangeResponse transaction
originates from a prescriber to respond to: A prescription change
request from a pharmacy; a request for a prior authorization from a
pharmacy; or a prescriber credential validation request from a
pharmacy.
Comments. Most commenters supported the proposed adoption of the
RxChangeRequest and RxChangeResponse transactions. One commenter
recommended against adoption until industry adoption is more widely
spread across retail pharmacies and demonstrates value.
Response. Because the majority of commenters were in support of
adoption of the RxChangeRequest and RxChangeResponse transactions as
proposed, we have included these transactions as required in the
updated Sec. 170.315(b)(3) electronic prescribing criterion.
Additionally, we note that pursuant to the certification criterion,
health IT presented for certification must be capable of including the
reason for the prescription as referenced in the updated Sec.
170.315(b)(3)(ii) or Sec. 170.315(b)(3)(ii)(D) in the RxChangeRequest
and RxChangeResponse transactions.
iii. Request and Respond to Cancel Prescriptions (CancelRx,
CancelRxResponse)
We proposed in 84 FR 7444 to enable a user to perform the related
electronic transactions for CancelRx and CancelRxResponse. A CancelRx
transaction is a request from a prescriber to a pharmacy to not fill a
previously sent prescription. A CancelRx must contain pertinent
information for the pharmacy to be able to find the prescription in
their system (patient, medication (name, strength, dosage, form),
prescriber, and prescription number if available). A CancelRxResponse
is a response from a pharmacy to a prescriber to acknowledge a
CancelRx, and is used to denote if the cancellation is approved or
denied.
Comments. The majority of public comments reflected support for
finalizing CancelRx and CancelRxResponse as required transactions. One
commenter stated that the CancelRx transaction will reduce cost and
improve patient safety, as patients may have remaining refills
available that are subsequently modified based on a physician's new
assessment. Another commenter noted that certified technology currently
supports CancelRx transactions in version 10.6 of the NCPDP SCRIPT
standard and encouraged developers to upgrade their technology to
support CancelRx transactions in NCPDP SCRIPT standard version 2017071,
as these transactions provide great value to end users. One commenter
expressed concern for pharmacy readiness for CancelRx, and felt there
should be sufficient industry adoption in place before it is a
certification requirement.
Response. We thank commenters for their overall support of the
proposed CancelRx and CancelRxResponse transactions. In light of the
commenters' overall support for the proposed CancelRx transactions and
in order to support patient safety and the free flow of communication
between prescribers and pharmacies, we have included these transactions
as required in the revised Sec. 170.315(b)(3) electronic prescribing
criterion. We reiterate that although PIS are outside the scope of the
ONC Health IT Certification Program, we encourage pharmacy information
system developers to advance their capacity to support a nationwide
network of fully interoperable PIS. Additionally, we note that pursuant
to the certification criterion, health IT presented for certification
must be capable of including the reason for the prescription as
referenced in the updated Sec. 170.315(b)(3)(ii) or Sec.
170.315(b)(3)(ii)(D) in the CancelRx transaction.
iv. Request and Respond to Renew Prescriptions (RxRenewalRequest,
RxRenewalResponse)
We proposed in 84 FR 7444 to enable a user to perform the related
electronic transactions for RxRenewalRequest and RxRenewalResponse. An
RxRenewalRequest transaction originates from a pharmacy to request
additional refills beyond those originally prescribed. An
RxRenewalResponse transaction originates from a prescriber to respond
to the request from the pharmacy.
Comments. Commenters supported adoption of the RxRenewalRequest and
RxRenewalResponse transactions as proposed. One commenter stated that
these transactions could be implemented after the CMS deadline of
January 1, 2020 without loss of current functionality. Another
commenter said that these transactions are widely used in the industry
and provide great value to end users.
Response. We appreciate the support for the RxRenewalRequest and
RxRenewalResponse transactions and have included these transactions as
required in the updated Sec. 170.315(b)(3) electronic prescribing
criterion. We reiterate that the entire updated Sec. 170.315(b)(3)
criterion and requirements must be met before certification can be
granted. Additionally, we note that pursuant to the certification
criterion, health IT presented for certification must be capable of
including the reason for the prescription as referenced in the
[[Page 25682]]
updated Sec. 170.315(b)(3)(ii) or Sec. 170.315(b)(3)(ii)(D) in the
RxRenewalRequest and RxRenewalResponse transactions.
v. Receive Fill Status Notifications (RxFill, RxFillIndicatorChange)
We proposed in 84 FR 7444 to enable a user to perform the related
electronic transactions for RxFill and RxFillIndicatorChange. An RxFill
transaction is sent from a pharmacy to a prescriber or long term and
post-acute care (LTPAC) facility indicating the FillStatus (dispensed,
partially dispensed, not dispensed or returned to stock, or transferred
to another pharmacy) of the new, refill, or resupply prescriptions for
a patient. RxFillIndicator informs the pharmacy of the prescriber's
intent for fill status notifications for a specific patient/medication.
An RxFillIndicatorChange is sent by a prescriber to a pharmacy to
indicate that the prescriber is changing the types of RxFill
transactions that were previously requested, and in which the
prescriber may modify the fill status of transactions previously
selected or may cancel future RxFill transactions.
Comments. While the RxFill transaction received unanimous support
as a required transaction, the vast majority of comments opposed
adopting the RxFillIndicatorChange as proposed due to a lack of
industry adoption and broad use by PIS. One commenter stated that there
has not been a significant use case for the RxFillIndicatorChange
transaction to prescribers. A few commenters suggested that ONC wait to
require the RxFillIndicatorChange until this transaction is more widely
adopted by both prescribers and pharmacies and value is realized in the
industry, and suggested either removing RxFillndicatorChange from the
proposed criterion or making this transaction optional. Another
commenter argued that RxFillIndicatorChange should be optional as
development to support this transaction in NCPDP SCRIPT standard
version 2017071 would be resource intensive. Commenters in support of
the adoption of the RxFillIndicatorChange transaction stated it is the
only way to alter the prescriber notification preferences in an
ambulatory or acute setting outside of a fillable message. Commenters
supporting adoption of the RxFillIndicatorChange transaction further
noted that, historically, the lack of prescriber control over
notification messages may have had an impact on hindering adoption. One
commenter suggested that, in lieu of the RxFillIndicatorChange
transaction, EHRs receive all fill notifications and subsequently use
logic to bring the clinician's attention to only important indicators.
Response. We appreciate all of the comments that supported the
RxFill transaction and the RxFillIndicatorChange transaction. After
consideration of comments received on the RxFill and
RxFillIndicatorChange transactions, we have adopted the RxFill
transaction as required and the RxFillIndicatorChange transaction as
optional in the updated Sec. 170.315(b)(3) electronic prescribing
criterion. We encourage further development and innovation to address
the concerns that we heard from commenters, and we will continue to
monitor advancements in standards and technology for future rulemaking.
We reiterate that PIS are outside the scope of the ONC Health IT
Certification Program and encourage pharmacy information system
developers to advance their capacity to support a nationwide network of
fully interoperable PIS. Additionally, we note that pursuant to the
certification criterion, health IT presented for certification must be
capable of including the reason for the prescription as referenced in
the updated Sec. 170.315(b)(3)(ii) or Sec. 170.315(b)(3)(ii)(D) in
the RxFill transaction.
vi. Request and Receive Medication History (RxHistoryRequest,
RxHistoryResponse)
We proposed in 84 FR 7444 to enable a user to perform the related
electronic transactions for RxHistoryRequest and RxHistoryResponse. An
RxHistoryRequest transaction is a request from a prescriber to a
pharmacy for a list of medications that have been prescribed,
dispensed, claimed, or indicated by a patient. An RxHistoryResponse is
a response to an RxHistoryRequest containing a patient's medication
history. It includes the medications that were dispensed or obtained
within a certain timeframe, and optionally includes the prescriber that
prescribed it.
Comments. Commenters supported adoption of the RxHistoryRequest and
RxHistoryResponse transactions as proposed. One commenter also stated
that both transactions could facilitate EHR and other health IT data
integration with PDMP systems, yet noted that in many cases, State law
or policy prohibits data integration between EHRs and PDMPs. Another
commenter stated that these transactions are widely used in the
industry and provide great value to end users.
Response. We appreciate all comments we have received on the use of
the RxHistoryRequest and RxHistoryResponse transactions. We agree with
the commenter that the RxHistoryRequest and RxHistoryResponse
transactions support data integration between health IT systems such as
EHRs and other information technology systems such as PDMPs, and
encourage any efforts made by developers to fully integrate
prescription and other health data into a provider's workflow within
allowable law. We reiterate that ONC does not have control over State
laws that govern PDMPs. We will continue to monitor regulatory and
industry advancements in this area and will take them into
consideration in future rulemaking. We have adopted these transactions
as required in the updated Sec. 170.315(b)(3) electronic prescribing
criterion. Additionally, we note that pursuant to the certification
criterion, health IT presented for certification must be capable of
including the reason for the prescription as referenced in the updated
Sec. 170.315(b)(3)(ii) or Sec. 170.315(b)(3)(ii)(D) in the
RxHistoryResponse transaction.
vii. Ask the Mailbox If There Are Any Transactions (GetMessage)
We proposed in 84 FR 7444 to enable a user to perform the
electronic transaction GetMessage for Ask the Mailbox. This transaction
is used by the prescriber or pharmacy when asking the mailbox if there
are any transactions. It is the basis for the mechanism used by a
prescriber or pharmacy system to receive transactions from each other,
from a payer, or from the Risk Evaluation and Mitigation Strategy
(REMS) Administrator via a switch acting as a mailbox.
Comments. Approximately half of commenters opposed adoption of the
GetMessage transaction and the other half supported adoption in the
updated Sec. 170.315(b)(3) electronic prescribing criterion.
Commenters not in support of the GetMessage transaction asserted that
it is not in use by prescribers and that it is an obsolete method of
message retrieval. Commenters in support of adoption argued that it is
applicable when not transacting with real-time messaging, and should be
adopted as an optional transaction.
Response. We thank commenters for their input. After careful
consideration of all comments received, and in our ongoing efforts to
align with CMS Part D requirements, we have determined to adopt the
GetMessage transaction as optional for the updated Sec. 170.315(b)(3)
electronic prescribing criterion.
[[Page 25683]]
viii. Relay Acceptance of a Transaction Back to the Sender (Status)
We proposed in 84 FR 7444 to enable a user to perform the related
electronic transaction to relay acceptance of a transaction back to the
sender. A Status transaction in response to any applicable transaction
other than GetMessage indicates acceptance and responsibility for a
request. A Status transaction in response to GetMessage indicates that
no mail is waiting for pickup. A Status transaction cannot be held in
an electronic mailbox and may not contain an error.
Comments. Commenters supported adoption of the Status transaction
as proposed. Two commenters noted that since the transaction is an
acknowledgement, it would not contain the reason for the prescription
as referenced in the updated Sec. 170.315(b)(3)(ii) or Sec.
170.315(b)(3)(ii)(D).
Response. We appreciate all comments in support of the Status
transaction and have included this transaction as required in the
updated Sec. 170.315(b)(3) electronic prescribing criterion. As an
acknowledgement, we agree that the NCPDP SCRIPT version 2017071
standard does not support the conveying the reason for the prescription
in the Status transaction, and have modified the requirement to reflect
this.
ix. Respond That There Was a Problem With the Transaction (Error)
We proposed in 84 FR 7444 to enable a user to perform the related
electronic transaction for Error response. This transaction indicates
an error has occurred and that the request was terminated. An Error can
be generated when there is a communication problem or when the
transaction actually had an error. An Error can be held in an
electronic mailbox, as it may be signifying to the originator that a
transaction was unable to be delivered or encountered problems in the
acceptance. The Error must be a different response than a Status, since
the communication between the system and the mailbox must clearly
denote the actions taking place. An Error is a response being delivered
on behalf of a previous transaction, while Status signifies no more
mail.
Comments. Commenters supported adoption of the Error transaction as
proposed. Two commenters noted that since the transaction is an
acknowledgement, it would not contain the reason for the prescription
as referenced in the updated Sec. 170.315(b)(3)(ii) or Sec.
170.315(b)(3)(ii)(D).
Response. We appreciate all comments in support of the Error
transaction and have included this transaction as required in the
updated Sec. 170.315(b)(3) electronic prescribing criterion. As an
acknowledgement, we agree that the NCPDP SCRIPT version 2017071
standard does not support the reason for the prescription in the Error
transaction, and we have modified that requirement to reflect this.
x. Respond That a Transaction Requesting a Return Receipt Has Been
Received (Verify)
We proposed in 84 FR 7445 to enable a user to perform the related
electronic transaction for Verify. This transaction is a response to a
pharmacy or prescriber indicating that a transaction requesting a
return receipt has been received. Verifications result when a ``return
receipt requested'' flag is set in the original request. Upon receiving
a transaction with ReturnReceipt set, it is the responsibility of the
receiver to either generate a Verify in response to the request
(recommended), or generate a Status in response to this request,
followed subsequently by a free-standing Verify transaction. This
transaction notifies the originator that the transaction was received
at the software system. It is not a notification of action taking
place, since time may elapse before the ultimate response to the
transaction may take place.
Comments. Commenters supported adoption of the Verify transaction
as proposed. Two commenters noted that since the transaction is an
acknowledgement, it would not contain the reason for the prescription
as referenced in the updated Sec. 170.315(b)(3)(ii) or Sec.
170.315(b)(3)(ii)(D).
Response. We appreciate all comments in support of the Verify
transaction and have included this transaction as required in the
updated Sec. 170.315(b)(3) electronic prescribing criterion. As an
acknowledgement, we agree that the NCPDP SCRIPT standard version
2017071 does not support the reason for the prescription in the Verify
transaction, and we have modified that requirement to reflect this.
xi. Request to Send an Additional Supply of Medication (Resupply)
We proposed in 84 FR 7445 to enable a user to perform the related
electronic transaction for Resupply. This transaction is a request from
a Long Term and Post-Acute Care (LTPAC) organization to a pharmacy to
send an additional supply of medication for an existing order. An
example use case is when a medication supply for a resident is running
low (e.g., 2-3 doses) and a new supply is needed from the pharmacy. In
such a circumstance, the LTPAC organization sends the Resupply
transaction as a way to notify the pharmacy that an additional supply
for the medication is needed.
Comments. Commenters expressed concern over adopting this
transaction as a required transaction for a few reasons. Some
commenters noted that the Resupply transaction is only applicable to
LTPAC practice settings for management of on-site pharmacy inventory
and for communication between a LTPAC facility and a contracted
pharmacy. Other commenters mentioned that PIS on the sending or
receiving end of the transaction are not required to support this
transaction. Some commenters stated that this transaction is not widely
adopted among prescribers, and that it should not be adopted until this
occurs. Two commenters requested that we either remove the transaction
from the final rule or make the Resupply transaction optional. Other
commenters stated that while this transaction may be beneficial in the
future, it was their opinion that it is premature to require the
Resupply transaction in the electronic prescribing criterion at this
time.
Response. We appreciate all comments related to the Resupply
transaction and have included this transaction as optional in the
updated Sec. 170.315(b)(3) electronic prescribing criterion. We are
aware of several ONC-certified EHRs and other health IT that were
either designed exclusively for, or were expressly designed to support,
LTPAC providers in addition to other institutions, and encourage those
and other developers to undergo certification testing to the Resupply
transaction. Additionally, we note that pursuant to the certification
criterion, health IT presented for certification must be capable of
including the reason for the prescription as referenced in the updated
Sec. 170.315(b)(3)(ii) or Sec. 170.315(b)(3)(ii)(D) in the Resupply
transaction. We reiterate that PIS are outside the scope of the ONC
Health IT Certification Program and encourage pharmacy information
system developers to advance their capacity to support a nationwide
network of fully interoperable PIS.
xii. Communicate Drug Administration Events (DrugAdministration)
We proposed in 84 FR 7445 to enable a user to perform the related
electronic transaction for DrugAdministration.
[[Page 25684]]
This transaction communicates drug administration events from a
prescriber or care facility to the pharmacy or other entity. It is a
notification from a prescriber or care facility to a pharmacy or other
entity that a drug administration event has occurred (e.g., a
medication was suspended or administration was resumed).
Comments. Commenters expressed concern over adopting this
transaction as a required transaction for a few reasons. Some
commenters noted that the DrugAdministration transaction is only
applicable to LTPAC practice settings and is therefore not relevant to
the scope of all certified health IT products, though one commenter
noted that there could be possible value of this transaction in
ambulatory and acute care settings as well. In addition, one commenter
reported LTPAC organizations interested in potentially using e-
prescribing transactions rated DrugAdministration as a low priority
transaction type, meaning there may not be a wide user base interested
in implementing it.
Response. We appreciate comments related to the DrugAdministration
transaction and have included this transaction as optional in the
updated Sec. 170.315(b)(3) electronic prescribing criterion. We are
aware of several ONC-certified EHRs and other health IT that were
either designed exclusively for, or are used in support of, LTPAC
providers, and encourage those and other developers to undergo
certification testing to the DrugAdministration transaction. In light
of the commenters' concerns, we have adopted the DrugAdministration
transaction as optional because the ONC Health IT Certification Program
is agnostic to care settings and programs, yet still supports many
different use cases. This allows the ONC Health IT Certification
Program to support multiple program and setting needs, including but
not limited to the Promoting Interoperability Programs and long term
and post-acute care. Because the transaction will be optional in the
updated (b)(3) criterion, developers whose clients do not support long
term care settings will not be required to demonstrate their capacity
to send this transaction.
xiii. Request and Respond to Transfer One or More Prescriptions Between
Pharmacies (RxTransferRequest, RxTransferResponse, RxTransferConfirm)
We proposed in 84 FR 7445 to enable a user to perform the related
electronic transactions for RxTransferRequest, RxTransferResponse and
RxTransferConfirm. The RxTransferRequest transaction is used when the
pharmacy is asking for a transfer of one or more prescriptions for a
specific patient to the requesting pharmacy. The RxTransferResponse
transaction is the response to the RxTransferRequest which includes the
prescription(s) being transferred or a rejection of the transfer
request. It is sent from the transferring pharmacy to the requesting
pharmacy. The RxTransferConfirm transaction is used by the pharmacy
receiving (originally requesting) the transfer to confirm that the
transfer prescription has been received and the transfer is complete.
Comments. The vast majority of commenters expressed concerns with
the proposal to adopt RxTransferRequest, RxTransferResponse, and
RxTransferConfirm transactions as proposed because they are only used
in pharmacy-to-pharmacy transactions and are not applicable to EHRs.
Further, two commenters noted that PIS are not required to support
these transactions. Conversely, the two commenters that supported these
transactions cited the benefit of allowing pharmacies to transfer
unfilled controlled substance prescriptions, including Schedule 2,
between pharmacies.
Response. We thank commenters for their input. We proposed to
require all of the NCPDP SCRIPT 2017071 standard transactions CMS
adopted in 42 CFR 423.160(b)(2)(iv) to illustrate our continued
dedication to establish and maintain complementary policies to ensure
that the current standard for certification to the electronic
prescribing criterion permits use of the current Part D e-Rx and MH
standards. With consideration of comments, and because it was not the
intent of this certification criterion to include pharmacy specific
transactions for the purposes of certification, we have adopted
RxTransferRequest, RxTransferResponse, and RxTransferConfirm as
optional in the updated Sec. 170.315(b)(3) electronic prescribing
criterion. We reiterate that PIS are outside the scope of the ONC
Health IT Certification Program and encourage pharmacy information
system developers to advance their capacity to support a nationwide
network of fully interoperable PIS.
xiv. Recertify the Continued Administration of a Medication Order
(Recertification)
We proposed in 84 FR 7445 to enable a user to perform the related
electronic transaction for Recertification. This transaction is a
notification from a LTPAC facility, on behalf of a prescriber, to a
pharmacy recertifying the continued administration of a medication
order. An example use is when an existing medication order has been
recertified by the prescriber for continued use.
Comments. Commenters expressed concern over adopting the
Recertification transaction as proposed primarily because it is only
applicable to LTPAC practice settings. One commenter stated that LTPAC
organizations interested in potentially using e-prescribing
transactions rated Recertification as a low priority transaction type,
suggesting that there may not be a wide user base interested in using
it.
Response. We appreciate all comments in support of the
Recertification transaction. In light of commenters concerns, we have
adopted this transaction as optional in the updated Sec. 170.315(b)(3)
electronic prescribing criterion. We are aware of several ONC-certified
EHRs and other health IT that were either designed expressly for or in
support of LTPAC providers, among other institutions, and encourage
those and other developers to undergo certification testing to the
Recertification transaction.
xv. Complete Risk Evaluation and Mitigation Strategy (REMS)
Transactions (REMSInitiationRequest, REMSInitiationResponse,
REMSRequest, and REMSResponse)
We proposed in 84 FR 7445 to enable a user to perform the related
electronic transactions for REMSInitiationRequest,
REMSInitiationResponse, REMSRequest, and REMSResponse. With CMS'
adoption of these transactions in their recently issued final rule
associated with e-Rx for Medicare Part D (42 CFR 423.160(b)(2)(iv)(W)-
(Z)), we believe that it will be beneficial to include these four REMS
transactions as part of this certification criterion:
REMSInitiationRequest, REMSInitiationResponse, REMSRequest, and
REMSResponse.
Furthermore, under the Food and Drug Administration Amendments Act
(FDAAA) of 2007 (Pub. L. 110-85), the Food and Drug Administration
(FDA) requires REMS from a pharmaceutical manufacturer if the FDA
determines that a REMS is necessary to ensure the benefits of a drug
outweigh the risks associated with the drug. In support of our sister
agencies' work, we therefore proposed to include the REMS transactions
as part of this certification criterion.
[[Page 25685]]
Comments. The vast majority of commenters supported adoption of
REMSInitiationRequest, REMSInitiationResponse, REMSRequest, and
REMSResponse as optional, not required, transactions. Those in support
of the transactions as proposed suggested that ONC should develop
strategies to encourage providers to consciously consider and
appropriately act on alerts to reduce the risk that these messages can
easily be clicked through and missed, particularly if that provider is
experiencing alert fatigue. Multiple reasons were provided by
commenters who stated that the proposed REMS transactions should be
adopted as optional in the proposed certification criterion. These
reasons included the state of system readiness and adoption by
manufacturers, REMS administrators, and pharmacy information systems.
Another commenter stated that these REMS transactions are not yet in
widespread use and should be piloted before being required as they
require extensive design and development effort.
Response. Given comments in support of the REMSInitiationRequest,
REMSInitiationResponse, REMSRequest, and REMSResponse transactions, we
have included these transactions as optional in the updated Sec.
170.315(b)(3) electronic prescribing criterion. We encourage
commenters, developers, and other stakeholder to review and provide
feedback on sections related to REMS (https://www.healthit.gov/isa/allows-a-prescriber-communicate-a-rems-administrator) and all other
electronic prescribing use cases on the ONC Interoperability Standards
(ISA) and post suggested edits and updates on these transactions as the
industry advances. We encourage manufacturers, REMS administrators, and
pharmacy information system developers to adopt these and other NCPDP
SCRIPT standard version 2017071 transactions to improve safe
prescribing practices and patient safety, and encourage developers to
test their capacity to send and receive REMS messages by utilizing the
testing tools that are available.
xvi. Electronic Prior Authorization
The Part D E-prescribing prior authorization process in 84 FR 28450
through 28458 requires that providers supply additional clinical
information to verify that the medication can be covered under the
Medicare Part D benefit. The prior authorization process is intended to
promote better clinical decision-making and ensure that patients
receive medically necessary prescription drugs. We are looking for ways
that would streamline the process for exchanging clinical and financial
data amongst prescribers and payers for prior authorization and improve
patients' access to needed medications. Electronic prior authorization
(ePA) automates this process by allowing providers to request and
respond to electronic prior authorization transactions within their
workflow. Using electronic prior authorization (ePA) transactions in
the NCPDP SCRIPT standard version 2017071 provides a standard structure
for exchanging prior authorization (PA) questions and answers between
prescribers and payers, while allowing payers to customize the wording
of the questions. Electronic prior authorization transactions will
additionally support the automation of the collection of data required
for PA consideration, allowing a health IT developer to systemically
pull data from a patient's medical record. The efficiency gains offered
by the ePA transactions in the NCPDP SCRIPT standard version 2017071
are the primary driver behind the development of this new capability.
We believe the adoption of the ePA transactions included in version
2017071 of the NCPDP SCRIPT standard as optional transactions aligns
with CMS' proposals for Part D ePA, and therefore, will not be adopting
NCPDP SCRIPT standard version 2013101 as suggested by the commenter. On
June 17, 2019, CMS issued the Secure Electronic Prior Authorization for
Medicare Part D proposed rule (84 FR 28450), including a proposed new
transaction standard for the Medicare Prescription Drug Benefit
program's (Part D) e-prescribing program. Under this proposal, Part D
plan sponsors would be required to support version 2017071 of the NCPDP
SCRIPT standard for four ePA transactions, and prescribers would be
required to use that standard when performing ePA transactions for Part
D covered drugs they wish to prescribe to Part D eligible individuals.
While not currently adopted as part of the Part D eRx standard, the
NCPDP SCRIPT standard version 2017071 includes eight transactions that
would enable the prescribers to initiate medication ePA requests with
Part D plan sponsors at the time of the patient's visit. The eight
transactions are: PAInitiationRequest, PAInitiationResponse, PARequest,
PAResponse, PAAppealRequest, PAAppealResponse, PACancelRequest, and
PACancelResponse.
Comments. Several commenters recommended the adoption of the ePA
transactions available in the NCPDP SCRIPT standard version 2017071 for
a variety of reasons, including improving efficiencies in the prior
authorization process, improving patient outcomes, reducing point-of-
sale rejections, increasing health IT developer adoption, and improving
the Medicare Part D member experience. Several commenters indicated
that lack of vendor support for the ePA transactions is a major barrier
to physician use of the transactions. One commenter also suggested ONC
adopt the NCPDP SCRIPT standard version 2013101 prior authorization
transactions.
Response. We thank commenters for their feedback. In consideration
of comments, we have adopted the ePA transactions in the NCPDP SCRIPT
standard version 2017071 as optional for the updated Sec.
170.315(b)(3) electronic prescribing criterion. We believe the adoption
of the ePA transactions included in version 2017071 of the NCPDP SCRIPT
standard as optional transactions aligns with CMS' proposals for Part D
ePA. We note that this final rule allows only for the voluntary
certification of Health IT Modules by health IT developers to support
these transactions, and does not require the certification, adoption,
or use of such Health IT Modules by health care providers for this or
any other purpose. We also note that development, testing, and
implementation to support these transactions are important first steps
toward integrating pharmacies in the prior authorization process for
Part D prescriptions, while supporting widespread industry adoption and
reducing burden on providers. We refer readers to the ONC Strategy on
Reducing Regulatory and Administrative Burden Relating to the Use of
Health IT and EHRs,\44\ drafted in partnership with CMS, for further
discussion of potential opportunities to ease related clinician burden
through improved health IT enabled processes.
---------------------------------------------------------------------------
\44\ https://www.healthit.gov/topic/usability-and-provider-burden/strategy-reducing-burden-relating-use-health-it-and-ehrs.
---------------------------------------------------------------------------
xvii. Reason for the Prescription
For each transaction specified, the technology must be able to
receive and transmit the reason for the prescription.
Comments. Commenters supported continued adoption of the reason for
the prescription in specific electronic prescribing transactions. Some
commenters noted that some of the proposed transactions would not
contain the reason for the prescription as referenced in the updated
[[Page 25686]]
Sec. 170.315(b)(3)(ii) or Sec. 170.315(b)(3)(ii)(D).
Response. We thank commenters for their feedback. We reiterate our
decision to require Health IT Modules seeking certification to the
updated electronic prescribing certification criterion to be capable of
including the reason for the prescription as referenced in the updated
Sec. 170.315(b)(3)(ii) or Sec. 170.315(b)(3)(ii)(D) within relevant
electronic prescription transactions to support patient safety and
align with HHS goals to expand safe, high quality health care. Health
IT certified to the updated Sec. 170.315(b)(3) criterion must have the
capacity to enable a user to receive and transmit the reason for the
prescription using the diagnosis elements: or
, or optionally, the technology must be able to receive and
transmit the reason for the prescription using the
element, and be consistent with the International Statistical
Classification of Diseases and Related Health Problems (ICDs) sent in
the diagnosis element(s). The element defines the
indication for use of the medication as meant to be conveyed to the
patient, and is included in the Sig. This requirement would apply to
the following NCPDP SCRIPT standard version 2017071 transactions that
we have adopted in this criterion (see discussion above): NewRx,
RxChangeRequest, RxChangeResponse, CancelRx, RxRenewalRequest,
RxRenewalResponse, RxFill, RxHistoryResponse, Resupply,
RxTransferRequest, RxTranferResponse, REMSInitiationRequest,
REMSInitiationResponse, REMSRequest, REMSResponse, PAInitiationRequest,
PAInitiationResponse, PARequest, PAResponse, PAAppealRequest,
PAAppealResponse, PACancelRequest, and PACancelResponse.
xviii. Oral Liquid Medications
Limit a user's ability to prescribe all oral liquid medications in
only metric standard units of mL (i.e., not cc).
Comments. While not within the scope of the Proposed Rule, one
commenter did not support the continued requirement to prescribe oral
liquids in ``mL'' units. The commenter supported the use of metric
units, but did not agree with the requirement of the ONC Health IT
Certification Program to limit this to only milliliters. The commenter
recommended that the unit of measure used by a prescriber be at their
discretion, as long as it is appropriate for the dosage.
Response. We thank the commenter for the input. Because this
requirement is out of scope for the Proposed Rule in that we did not
propose to change this conformance requirement, we decline to relax or
retire the requirement for oral liquid medications to be prescribed in
mL units. When we first adopted this requirement for the 2015 Edition
Proposed Rule, several commenters were supportive of improving patient
safety through use of the metric standard for dosing, but recommended
that this requirement only apply to oral liquid medications. Incorrect
dosage is a common error with liquid medication, often resulting from
confusion between different dose measurements (e.g., mL and teaspoons).
If these measurements are confused with each other, too much or too
little of the medicine can be given. This requirement is also in
alignment with NCPDP SCRIPT implementation recommendations.
xix. Signatura (Sig) Element
The Signatura (Sig) element is used to support electronic
prescribing for the consistent expression of patient directions for use
by relaying this information between a prescriber and a pharmacist. It
must be legible, unambiguous, and complete to ensure the prescriber's
instructions for use of the medication are understood. For each
transaction, the technology must be able to receive and transmit the
reason for the prescription using the indication elements in the SIG
Segment.
Comments. One commenter requested that the Sig element be required
rather than optional to aid in future medication reconciliation and
clinical reporting. Another commenter noted that the NCPDP SCRIPT
standard version 2017071 allows for an increase in Sig length.
Response. Given the lack of attention paid to and support for
modifying the electronic prescribing criterion for Sig from optional to
required, we have decided to retain Sig as optional in the updated
Sec. 170.315(b)(3) criterion. As discussed in the Reason for
Prescription section, health IT may optionally seek certification to
the updated electronic prescribing criterion by demonstrating their
capacity to receive and transmit the reason for the prescription using
the Sig element.
xx. Real Time Pharmacy Benefit
While development is still currently underway by NCPDP, the Real-
Time Pharmacy Benefit (RTPB) standard is not yet complete. When
complete, the RTPB standard is expected to facilitate the ability for
pharmacy benefit payers/processors to communicate formulary and benefit
information to providers. In the absence of that or another similar
standard, CMS has adopted policies requiring the development and/or
implementation of Real Time Benefit Transaction (RTBT) standards in the
Part D e-Rx Program in the context of recent rulemaking. On May 16,
2019, CMS issued the Modernizing Part D and Medicare Advantage to Lower
Drug Prices and Reduce Out-of-Pocket Expenses final rule, which
includes a requirement under the electronic prescribing standards that
Part D plan sponsors implement one or more electronic real-time benefit
tools that are capable of integrating with at least one prescriber's
electronic prescribing system or electronic health record no later than
January 1, 2021 (84 FR 23832). One commenter recommended that CMS and
ONC coordinate with NCPDP on requirements for real-time benefit
functionality. We are also aware of industry efforts to develop a
consumer-facing real-time pharmacy benefit functionality FHIR[supreg]-
based implementation guide that we anticipate will be balloted in 2020.
ONC will continue to monitor these efforts and consider proposing the
NCPDP RTPB standard or a similar standard to enable real-time benefit
transactions in future rulemaking.
xxi. Other Comments Received Outside the Scope of This Rule
We note that we received several comments specifically addressing
the electronic prescribing of controlled substances and prescription
drug monitoring programs. We note that these specific comments are
outside the scope of the proposals finalized in this rule. However, we
note that we included a discussion of these topics in relation to the
discussion of the RFI on OUD prevention and treatment in the Proposed
Rule in 84 FR 7461.
5. Clinical Quality Measures--Report Criterion
In the 2015 Edition final rule, ONC adopted four clinical quality
measure (CQM) certification criteria, Sec. 170.315(c)(1) CQMs--record
and export, Sec. 170.315(c)(2) CQMs--import and calculate, Sec.
170.315(c)(3) CQMs--report, and Sec. 170.315(c)(4) CQMs--filter (80 FR
62649 through 62655). These four criteria were adopted with the intent
to support providers' quality improvement activities and in
electronically generating CQM reports for reporting with certified
health IT to programs such as the EHR Incentive Programs, Quality
Payment Program, and Comprehensive Primary Care plus initiative. The
``CQMs--report''
[[Page 25687]]
certification criterion (Sec. 170.315(c)(3)) included an optional
certification provision for demonstrating that the health IT can create
Quality Reporting Document Architecture (QRDA) reports in the form and
manner required for submission to CMS programs, which is in accordance
with CMS' QRDA Implementation Guide (IGs).
The CMS QRDA IGs provide technical guidance and specific
requirements for implementing the HL7 QRDA Category I (QRDA I) and
Category III (QRDA III) standards for reporting to CMS quality
reporting programs.\45\ The CMS QRDA IGs include the formal template
definitions and submission criteria for submitting QRDA documents to
the Comprehensive Primary Care Plus (CPC+) and Merit Based Incentive
Payments System (MIPS) Programs. Some of the conformance statements in
the HL7 QRDA standards have been further constrained to meet the
specific requirements from these CMS programs. The CMS QRDA IGs also
only list the templates specifying CMS-specific reporting requirements
from the base HL7 QRDA standards. QRDA I is an individual-patient-level
report. It contains quality data for one patient for one or more
electronic clinical quality measures (eCQMs). QRDA III is an aggregate
quality report. A QRDA III report contains quality data for a set of
patients for one or more eCQMs.
---------------------------------------------------------------------------
\45\ The following resources provide additional information on
the differences between the CMS QRDA and the HL7 QRDA standards:
https://ecqi.healthit.gov/system/files/QRDA_HQR_2019_CMS_IG_final_508.pdf (pg. 38) and https://ecqi.healthit.gov/sites/default/files/2019-07/2020-CMS-QRDA-III-Eligible-Clinicians-and-EP-IG-07182019-508.pdf (pg. 18).
---------------------------------------------------------------------------
Since the 2015 Edition final rule was published, we have gained
additional certification experience and received feedback from the
industry that health IT certified to the ``CQMs--report'' criterion
(Sec. 170.315(c)(3)) are only/primarily being used to submit eCQMs to
CMS for participation in CMS' programs. Therefore, as a means of
reducing burden, we proposed to remove the HL7 CDA[supreg] Release 2
Implementation Guide: QRDA I; Release 1, Draft Standard for Trial Use
(DSTU) Release 3 (US Realm), Volume 1 (Sec. 170.205(h)(2)), as well as
the QRDA Category III, Implementation Guide for CDA[supreg] Release 2
(Sec. 170.205(k)(1)) and the Errata to the HL7 Implementation Guide
for CDA[supreg] Release 2: QRDA Category III, DSTU Release 1 (US
Realm), September 2014 (Sec. 170.205(k)(2)) standard requirements (HL7
QRDA standards) from the current 2015 Edition CQMs--report criterion in
Sec. 170.315(c)(3), and we also proposed to require that health IT
certified to the current 2015 Edition CQMs--report criterion support
the CMS QRDA IGs (84 FR 7446). We stated that this change would
directly reduce burden on health IT developers and indirectly providers
as they would no longer have to develop and support two forms of the
QRDA standard.
We also solicited comment in the Proposed Rule on the future
possibility of FHIR-enabled APIs replacing or complementing QRDA-based
quality reporting. We also noted in the Proposed Rule that the Fast
Health Interoperability Resources (FHIR[supreg]) standard offers the
potential for supporting quality improvement and reporting needs, and
holds the potential of being a more efficient and interoperable
standard to develop, implement, and utilize to conduct quality
reporting through APIs. We believe until the potential benefits of
FHIR[supreg] APIs can be realized for quality reporting, and that
solely requiring the CMS QRDA IGs for the updated 2015 Edition ``CQMs--
report'' criterion will balance the burden on developers, while still
ensuring module users' abilities to meet their quality reporting
obligations to CMS (84 FR 7446).
To support the proposal, we proposed to incorporate by reference in
Sec. 170.299 the latest annual CMS QRDA IGs, specifically the 2019 CMS
QRDA I IG for Hospital Quality Reporting \46\ (Sec. 170.205(h)(3)) and
the 2019 CMS QRDA III IG for Eligible Clinicians and Eligible
Professionals (Sec. 170.205(k)(3)).\47\ We noted in the Proposed Rule
that developers would be able to update certified health IT to newer
versions of the CMS QRDA IGs through the real world testing Maintenance
of Certification provision for standards and implementation
specification updates in Sec. 170.405(b). We also proposed that a
Health IT Module would need to be certified to both standards to ensure
flexibility for Health IT Module users. We solicited comment on whether
to consider an approach that would permit certification to only one of
the standards depending on the care setting for which the Health IT
Module is designed and implemented.
---------------------------------------------------------------------------
\46\ https://ecqi.healthit.gov/system/files/QRDA_HQR_2019_CMS_IG_final_508.pdf.
\47\ https://ecqi.healthit.gov/system/files/2019_CMS_QRDA_III_Eligible_Clinicians_and_EP_IG-508.pdf.
---------------------------------------------------------------------------
Comments. The majority of commenters were supportive of the
proposal to remove the HL7 QRDA standard requirements from the 2015
Edition CQMs--report criterion in Sec. 170.315(c)(3), and to require
that health IT certified to the criterion support the proposed CMS QRDA
IGs. Some commenters observed that the main use cases for the certified
QRDA export functionality (which is specific to CMS eCQMs) are to
support direct data submission to CMS at the conclusion of reporting
periods, to enable use of third party data submission Health IT Modules
to meet CMS reporting requirements, and to support data extraction for
registry reporting for participation in CMS programs such as MIPS.
Commenters noted that while in some cases the extraction of data using
a QRDA may also support other use cases--for example for a registry--
because of the specificity of the criteria to the CMS eCQMs, such a
transaction using the certified functionality is primarily for CMS
reporting. Commenters noted the use of the CMS QRDA IG does not impede
use of the data for other purposes. Finally, commenters noted that ONC
should continue to provide health IT developers the flexibility to
offer a non-certified QRDA functionality that could support eCQMs
beyond those included for CMS programs. One commenter observed that
while some health IT systems also provide tools for internal quality
performance monitoring, those tools often do not rely on the generation
of QRDA exports.
Some commenters reported that the technical support of multiple
versions of QRDA standards is unnecessary. Other commenters recommended
maintaining only the HL7 standard or offering certification to the HL7
standard as an optional alternative to the CMS QRDA IG. One commenter
who recommended maintaining both the HL7 standard and the CMS QRDA IGs
suggested that ONC cite the CMS version(s) of the QRDA IG as a
technical resource in the same manner the C-CDA companion guide is
cited for the transition of care criteria and only require certifying
to the HL7 version. These commenters agreed that developers should not
have to certify to both HL7 QRDA and CMS QRDA IGs, but suggested if a
developer passed certification for the CMS QRDA IGs, they should be
deemed to have achieved certification to the HL7 QRDA standard as well.
Commenters noted that the CMS QRDA apply specifications to the HL7 QRDA
to support CMS eCQM reporting requirements.
Other commenters specifically stated that the HL7 QRDA should
remain as an optional certification criterion, since other
organizations (e.g., certain hospital accreditation organizations such
as The Joint Commission) use the
[[Page 25688]]
HL7 QRDA, and there is need to assure the same style for submission
across programs. They recommended that the HL7 QRDA IG persist as a
continuing option in the Program to enhance alignment with other
standards and C-CDA, and to encourage a base standard alignment across
implementers such as CMS and The Joint Commission. They stated that
citing only to the CMS QRDA IG may lead to misalignment with the base
standards and reduce incentives to update the base standard.
Some commenters expressed concern over the proposed removal of HL7
QRDA standards from the original 2015 Edition CQMs, stating it may
undermine private sector efforts to self-regulate and stated that the
removal of the HL7 QRDA may not achieve the envisioned burden reduction
through the mere elimination of developers' need to certify and
maintain multiple standards. While some commenters suggested that
removing HL7 QRDA from the certification criteria could simplify the
reporting process by recognizing the widespread use of CMS' QRDA IGs,
they noted that the HL7 QRDA is currently the standard for most EHR
systems and questioned how ONC proposed to implement this change given
the prominence of HL7 standards in EHR systems. Several commenters
noted that the disconnect between what the certification testing
required, and how the standard was really being used in the industry
(primarily but not exclusively to meet the CMS QRDA IG) created
unnecessary certification testing burden, and asserted that the
adoption of the CMS proprietary IG was more appropriate than to
maintain HL7 QRDA.
Response. We thank commenters for their support for the proposal
and comments regarding the versions of standards. We understand the
concerns expressed in opposition to this proposal, and we appreciate
specifically the identification of potential risk for the elimination
of the HL7 standard as applicable for other use cases. As noted
previously, since the 2015 Edition final rule was published (October
16, 2015), we have gained received feedback from the industry that
health IT certified to the ``CQMs--report'' criterion (Sec.
170.315(c)(3)) are only or primarily being used to submit eCQMs to CMS
for participation in CMS' programs. In addition, we note that while the
HL7 QRDA may be used for other purposes, the ``CQMs--report'' criterion
(Sec. 170.315(c)(3)) is specific to the CMS eCQMs specified for
participation in CMS reporting programs and no other eCQMs are tested
under that criterion. This specificity applies not only to the current
2015 Edition ``CQMs--report'' criterion, but also to the other 2015
Edition CQM criteria and the prior 2014 Edition CQM criteria. This
specificity is intended to provide assurances through testing and
certification of the accuracy and standardization of CMS program
measures across platforms, while recognizing that it would not be
possible to specifically test to the entire universe of potential eCQMs
in use by health care providers. Because of this dependency, testing
and certification of both the HL7 QRDA for CQMs-report and the CMS QRDA
IG is redundant to support eCQM data reporting.
This has a dual impact on our considerations to finalize our
proposal to require only the CMS QRDA IG. First, for use cases that are
not related to CMS eCQM reporting, the certified functionality would
not specifically support third party non-CMS eCQM reporting
requirements, and so the modification to the functionality does not
change the inability to use the certified version of the functionality
for such purposes. Second, for those use cases involving registries or
other third parties that are implementing or supporting CMS eCQM
reporting, use of the CMS QRDA IG could additionally support such
purposes. In addition, we are not restricting health IT developers from
creating and providing to customers a non-certified functionality that
supports the HL7 QRDA for the extraction of data for eCQMs that are not
CMS eCQMs. We note that this is not a change from the prior policy
allowing such flexibility. The prior certification for the QRDA IG
included testing of CMS eCQMs only and it neither supported nor
restricted any development of a QRDA functionality for non-CMS eCQMs.
We also agree that this approach will support closer alignment
between the testing to the CMS QRDA IG specifications for a certified
health IT module and the technical requirements for CMS program
reporting. As part of the development of the CMS QRDA IGs, CMS strives
to use the annual update process to resolve issues with CQMs based on
updates to clinical guidelines and to advance the requirements as the
standard for reporting eCQM data matures. In this way, aligning the
criterion to the CMS program requirements that it specifically supports
allows for alignment between these efforts as well as allowing for
continued updates through the standards version advancement process. We
also believe our finalized proposal will not impede private sector
initiatives as the CMS IGs support the continued efforts by public/
private collaboration through standards developing organizations (SDOs)
to refine standards.
Therefore, as a means of reducing burden, we have finalized our
proposal to remove the HL7 QRDA standard requirements from the 2015
Edition CQMs--report criterion in Sec. 170.315(c)(3). We maintain our
position that this would directly reduce burden on health IT developers
and indirectly for health care providers as there would no longer be a
requirement to develop and support two forms of the QRDA standard. We
note that this does not preclude developers from continuing to support
the underlying standard, especially where such standard may support
reporting or health information exchange for other quality or public
health purposes. Instead, we are simply not requiring testing and
certification of any such standards, thereby eliminating testing and
certification burden from a criterion that is at this time scoped to
the purpose of reporting for CMS quality programs.
Comments. A few commenters did not support the proposal but instead
recommended that CMS adopt the HL7 QRDA standard and do away with its
own. However, several commenters offered suggestions to CMS on the
development of the CMS QRDA IG and the alignment to the HL7 QRDA
standard. A number of commenters noted the National Technology Transfer
and Advancement Act of 1995 principle that Federal agencies are
generally required to use technical standards that are developed by
voluntary consensus standards bodies rather than a proprietary standard
specific to an HHS program. Commenters also stated if CMS wanted to
retain certain aspects of its standard, it should work with HL7 to get
these vetted, balloted and approved for inclusion within the HL7
standard. Commenters also recommended working with SDOs or other
organizations to sufficiently support CMS QRDA IGs. Some commenters
suggested that consolidation of QRDA standards would be more likely
result in reducing provider burdens than what ONC proposed.
Response. We thank the commenters for their recommendations to
improve the CMS QRDA IGs, or for CMS to work toward including the
aspects of CMS QRDA IGs that they require for their program operations
in SDO-balloted and approved consensus standards. Specific suggestions
for CMS IG development are outside the scope of this rule. ONC had
previously included the HL7 QRDA standards for certification in the
2015 Edition in order to potentially support a broader range of use
cases than
[[Page 25689]]
reporting for CMS programs. However, the specificity of the criterion
to the CMS eCQMs limits the utility of the certified functionality
beyond use with CMS eCQMs and as stated in the Proposed Rule, since the
2015 Edition final rule, ONC and CMS received significant stakeholder
feedback that health IT modules certified to the ``CQMs--report''
criteria at 170.314(c)(3) in the 2014 Edition and 170.315(c)(3) for the
2015 Edition are used only or primarily for reporting to CMS programs.
While we reiterate that these comments are outside the scope of this
rule, we will continue to take this and other feedback into
consideration and will continue to work with CMS, standards developing
organizations, and health IT industry partners to explore the concerns
raised in relation to reducing burden and promoting interoperable
standards for quality reporting.
Comments. Commenters provided mixed feedback on whether the updated
2015 Edition ``CQMs--report'' criterion should require adherence to
both CMS QRDA IGs, specifically the 2019 CMS QRDA I IG for Hospital
Quality Reporting \48\ and the 2019 CMS QRDA III IG for Eligible
Clinicians and Eligible Professionals.\49\ The majority of commenters
recommended that to reduce burden, ONC should consider a certification
approach that permits developers to seek certifications based on the
care setting(s) their health IT modules are intended serve. For
example, commenters suggested that ONC should only require
certification to the 2019 QRDA I IG for Hospital Quality Reporting if a
Health IT Module is designed exclusively for the reporting of hospital
measures, and only require certification to the 2019 QRDA III IG for
Eligible Clinicians and Eligible Professionals when a Health IT Module
is designed exclusively for the reporting of ambulatory measures. In
instances in which both populations are served, the developer would
then seek certification to both standards. Commenters suggested this
approach would avoid the unnecessary burden of certifying to a standard
that the Health IT Module was not intended to serve. Other commenters
stated that the certification requirements should ensure that certified
Health IT Modules can support quality measure reporting by all
potential users, especially given the potential expansion of eligible
participants in certain CMS programs (e.g., should a program expand
from hospital-based only to include ambulatory measures). These
commenters recommended the adoption of a requirement for certified
Health IT Modules to calculate and export both CMS QRDA I patient-level
reports for Hospital Quality Reporting and CMS QRDA III aggregate
summary reports for Eligible Clinicians and Eligible Professionals.
These commenters noted that if a certified Health IT Module can only
send an aggregate report without a patient level report, then this
would greatly diminish the ability to verify the underlying
calculations. However, commenters recommended that ONC clarify that the
transition to CMS QRDA I IG-based reports (patient-level, QRDA I IG for
Hospital Quality Reporting) does not necessarily mean that a hospital
quality measure must be certified by any system (i.e., an ambulatory
Health IT Module can certify to only CMS QRDA III IG requirements).
Commenters also sought clarity that the transition to QRDA III reports
(aggregate-level, IG for Eligible Clinicians and Eligible
Professionals) does not necessarily mean that an ambulatory quality
measure must be certified by any system (i.e., a hospital system can
certify to only hospital measures). Finally, one commenter noted that
certifying ambulatory quality measures for the QRDA I to a hospital IG
is not effective and will interfere with the use case of using QRDA I
to combine data between multiple ambulatory systems such as for group
reporting.
---------------------------------------------------------------------------
\48\ https://ecqi.healthit.gov/system/files/QRDA_HQR_2019_CMS_IG_final_508.pdf.
\49\ https://ecqi.healthit.gov/system/files/2019_CMS_QRDA_III_Eligible_Clinicians_and_EP_IG-508.pdf.
---------------------------------------------------------------------------
Response. We thank commenters for their comments regarding whether
a Health IT Module should be certified to both CMS QRDA IG standards or
whether to consider an approach that permits certification to only one
of the standards depending on the care setting for which the Health IT
Module is designed and implemented. We agree with commenters that our
certification approach should prevent unintended burden by tailoring
the requirements to the type of measures being tested. This would mean
that for the updated certification criterion ``CQMs--report'' in Sec.
170.315(c)(3) a Health IT Module testing only ambulatory measures would
test only with the CMS QRDA III IG for ambulatory measures and a Health
IT Module testing only inpatient measures would test only with the QRDA
I CMS IG for inpatient measures. A Health IT Module supporting both
ambulatory and inpatient measures would be required to test to both the
CMS QRDA I IG and the CMS QRDA III IG. We clarify that testing for the
2015 Edition ``CQM--capture and export'' criterion in Sec.
170.315(c)(1) criteria includes demonstrating the capability to export
a QRDA I report specific to the eCQM being tested--which would support
use case noted by the commenter to combine data across multiple
ambulatory systems. We have not proposed and have not finalized a
change to the 2015 Edition ``CQM--capture and export'' criterion in
Sec. 170.315(c)(1). We further note that health IT developers may
leverage QRDA file formats for a wide range of use cases and that our
inclusion of the CMS QRDA I and QRDA III IGs does not prohibit the use
of the QRDA standard for any other purpose. As noted above, we have
finalized the adoption of the CMS QRDA IGs for the ``CQMs--report''
criterion in Sec. 170.315(c)(3) for which the Health IT Module is
presented for certification.
Comments. The majority of commenters supported the proposal to
adopt the latest CMS QRDA IGs at the time of final rule publication, as
CMS updates their QRDA IGs annually to support the latest eCQM
specifications and only accepts eCQM reporting to the latest version.
However, a few commenters recommended that ONC monitor this part of the
certification process for unintended consequences since CMS' IGs are
updated on a yearly basis. Some commenters noted that given the lack of
alignment with timing, eCQM measures and standards will continue to
lack testing. Other commenters recommended the IGs be updated in
alignment with updates to the certification standards. A few commenters
requested clarification of the effective dates and asked ONC to
evaluate and propose a timeline for the implementation of an alignment
between the programs. In addition, commenters asked for clarification
on whether ONC will propose penalties for providers who may be unable
to meet the timeline if it is insufficient.
Response. We thank commenters for their input and have adopted the
latest CMS QRDA IG versions available at the time of publication of
this final rule. For details on the latest CMS QRDA IGs, we refer
readers to the CMS QRDA I Implementation Guide for Hospital Quality
Reporting and CMS QRDA III Implementation Guide for Eligible Clinicians
and Eligible Professionals available on the eCQI Resource Center
website.\50\ We note that CMS updates
[[Page 25690]]
the CMS eCQMs on an annual basis as well as the CMS QRDA IGs for
reporting to CMS programs. As in prior years going back to the 2014
Edition, HHS will continue to update the Cypress testing tool to
support health IT developer testing to the most recent annual update.
We note that CMS has previously required that EHR technology used for
eCQM reporting be certified to all eCQMs but does not need to be
recertified each time it is updated to a more recent version of the
eCQM electronic specifications, unless the EHR technology is supporting
new eCQMs or functionality (such as the ``CQM--filter'' criterion in
Sec. 170.315(c)(4)) (84 FR 42505). This approach allows for continued
updates to and testing of eCQMs while minimizing the burden on
developers and providers to support those updates in time for each
annual performance period. Finally, we note that ONC has no authority
to set requirements, incentives, or penalties for health care providers
related to the use of health IT, and we direct readers to CMS for
information on health IT requirements in CMS programs.
---------------------------------------------------------------------------
\50\ The Electronic Clinical Quality Improvement (eCQI) Resource
Center. CMS QRDA I Implementation Guide for Hospital Quality
Reporting and CMS QRDA III Implementation Guide for Eligible
Clinicians and Eligible Professionals. Available at: https://ecqi.healthit.gov/qrda.
---------------------------------------------------------------------------
Comments. The majority of commenters agreed with ONC's assessment
in the Proposed Rule that quality reporting is not yet ready to
transition to FHIR and that more testing and validation of FHIR is
needed before requiring a new API-based reporting functionality as a
part of the Program. Some commenters supported the adoption of FHIR
Release 4-enabled APIs as a replacement for QRDA-based reports, but
stated that published documentation aligning HL7 C-CDA, QRDA, and/or
FHIR standards to CMS' ``Quality Data Model,\51\'' which is an
information model that defines relationships between patients and
clinical concepts in a standardized format to enable electronic quality
performance measurement and that would allow for more consistent eCQM
reporting and improved interoperability in clinical quality feedback
between health systems and data registries. Other commenters stated
that FHIR standards will likely strengthen standardized data element
availability and flexibility to improve the types of eCQMs that may be
developed, and suggested that CMS continue to work with the National
Quality Forum, measure stewards, and measure developers to advance both
existing evidence-based measures (e.g., either administrative or hybrid
measures) and evolving outcome measures that utilize population-based
electronic clinical data.
---------------------------------------------------------------------------
\51\ https://ecqi.healthit.gov/qdm.
---------------------------------------------------------------------------
Response. We thank commenters for their support. We believe there
are potential benefits to be gained by exploring both near-term,
program specific implementations of APIs to support current quality
reporting submission mechanisms such as for CMS eCQM reporting as well
as the long-term potential to reimagine quality measurement by
leveraging API technologies. We believe that these technology
approaches could help providers and payers, including CMS, move from
the current approach, in which providers are required to calculate and
submit results on specific quality measures, to one in which payers,
including CMS, could obtain clinical data for quality measurement
directly through an API. This could potentially include the ability to
obtain clinical data for a defined group or sample set of patients to
assess quality across patient populations, as well as to compare
clinical data for patients over time to assess quality impacts through
longitudinal measurement. We believe emerging innovative standards are
now available to support such models, specifically the ability to
respond with clinical data for a defined group or sample set of
patients using the bulk data capabilities in FHIR Release 4. We note
that readiness for such an approach, both for recipients of quality
data and for health IT developers supporting quality improvement
solutions, is not yet mature for adoption of such a criterion in the
Program. However, we are committed to continuing to work with HHS
partners, health care providers, health IT developers and SDOs to
explore the potential for such solutions in the future.
Comments. Several commenters recommended additional changes not
considered in the Proposed Rule. For example, one commenter recommended
ONC require that to be certified in Sec. 170.315(c)(1) ``CQMs--record
and export,'' Sec. 170.315(c)(2), ``CQMs--import and calculate,'' and
Sec. 170.315(c)(3) ``CQMs--report,'' a Health IT Module be certified
in a minimum of 9 eCQMs instead of one eCQM and that the Sec.
170.315(c)(1) criterion should require the ability to export all
patients for a given eCQM. Currently, the ability to export a QRDA I
file can be limited to one patient at a time. Commenters noted that
this limitation defeats the purpose of data interoperability and does
not advance the goals of ONC to increase access to data and the
interoperability of Health IT Modules. And another commenter
recommended that, in addition to the adoption of the CMS IGs under the
Sec. 170.315(c)(3) criterion, that the CMS IGs replace the
corresponding HL7 QRDA IGs as ONC's Program standard under the Sec.
170.315(c)(1) criterion (which currently references QRDA I exclusively)
and Sec. 170.315(c)(2) criterion (which currently references only QRDA
I as standard, but also involves use of QRDA III for purposes of
verifying appropriate calculation of measures from imported QRDAs).
Response. We thank commenters for input and clarifications. While
we appreciate comments suggesting changes to Sec. 170.315(c)(1)
``CQMs--record and export,'' and Sec. 170.315(c)(2) ``CQMs--import and
calculate,'' the recommended changes are outside the scope of our
proposal. Therefore, while we may consider these recommendations for
future Program rulemaking, we have not adopted the suggested changes to
Sec. 170.315(c)(1) ``CQMs--record and export,'' or Sec. 170.315(c)(2)
``CQMs--import and calculate in this final rule.
As noted previously, we have finalized the update to the ``CQMs--
report'' criterion in Sec. 170.315(c)(3) to require that health IT
developers use the CMS QRDA IG appropriate to the measures being
submitted for testing and certification to read as follows: ``Clinical
quality measures--report. Enable a user to electronically create a data
file for transmission of clinical quality measurement data in
accordance with the applicable implementation specifications specified
by the CMS implementation guides for Quality Reporting Document
Architecture (QRDA), category I, for inpatient measures in Sec.
170.205(h)(3) and CMS QRDA, category III, for ambulatory measures in
Sec. 170.205(k)(3).''
6. Electronic Health Information (EHI) Export Criterion
We proposed to adopt a new 2015 Edition certification criterion
referred to as ``EHI Export'' in Sec. 170.315(b)(10). The criterion's
conformance requirements were intended to support two contexts in which
we believed that all EHI produced and electronically managed by a
developer's technology should be made readily available for export as a
capability of certified health IT. First, we proposed in Sec.
170.315(b)(10)(i) at 84 FR 7447 that health IT certified to this
criterion would support single patient EHI export upon a valid request
by a patient or a user on the patient's behalf. Second, we proposed in
Sec. 170.315(b)(10)(ii) at 84 FR 7447 that the proposed criterion
would support the export of all EHI when a health care
[[Page 25691]]
provider chooses to transition or migrate information to another health
IT system. Third, we proposed in Sec. 170.315(b)(10)(iii) that the
export format(s) used to support the exports must be made available via
a publicly accessible hyperlink, including keeping the hyperlink up-to-
date with the current export format.
At the time of the Proposed Rule, we indicated our belief that this
proposed certification criterion provided a useful first step toward
enabling patients to have electronic access to their EHI and equipping
health care providers with better tools to transition patient EHI to
another health IT system. We noted that this criterion would create a
baseline capability for exporting EHI. We requested comments regarding
the proposed single patient EHI export and the proposed database export
functionalities, as well as the proposed scope of data export and other
criterion elements throughout the Proposed Rule section at 84 FR 7447
through 7449.
Comments. Commenters generally supported the intent of the proposed
``EHI export'' criterion to advance the access, exchange, and use of
EHI. Commenters in favor of the criterion and its proposed conformance
requirements stated that it would foster innovative export capabilities
and inform areas where additional standards development could be
needed. We also received a variety of comments asking for adjustments
to proposed requirements. A majority of commenters requested revisions
to the criterion, including calling for a defined set of data elements
for export and specific data transport standards. Many commenters
offered recommended standards or requested that we provide specific
standards to reduce variation. These commenters indicated that no
defined standard could lead to broad interpretation and potential
inadequacies of the data export. Some commenters expressed a medical
record keeping concern that the proposed standards-agnostic approach
for the export functionality could be problematic, stating that the
export could create a dissonance if the EHI renders health record
content in a form or format that is different from what a provider
produces or utilizes as output. Other commenters opposed the adoption
of this proposed criterion. These commenters expressed concern that
later implementation of standards, such as APIs, would make developers
invest time and funding into the proposed requirements only for the
work to be discarded in the future.
Response. We thank commenters for their feedback on the proposed
``EHI export'' criterion at 84 FR 7446 of the Proposed Rule (Sec.
170.315(b)(10)). We have considered commenters' concerns, support, and
recommendations and adopted a revised version of this certification
criterion. This final certification criterion is designed to align with
section 4006(a) of the Cures Act, which requires the Secretary, in
consultation with the National Coordinator, to promote policies that
ensure that a patient's EHI is accessible to that patient and the
patient's designees, in a manner that facilitates communication with
the patient's health care providers and other individuals (84 FR 7447).
In addition, this criterion complements other provisions that support
patients' access to their EHI and health care providers use of EHI,
such as the secure, standard-based API certification criterion
(proposed in 84 FR 7427 and finalized in Sec. 170.315(g)(10)), and
also supports longitudinal data record development. Therefore, we have
finalized the criterion with revisions. Notably, in response to
comments on this criterion and the proposed information blocking
policies, we have adopted a focused definition of EHI in Sec. 170.102
and Sec. 171.102. For context purposes, the EHI definition is focused
on ``electronic protected health information as defined in 45 CFR
160.103 to the extent that it would be included in a designated record
set as defined in 45 CFR 164.501'' with additional caveats not repeated
here for briefness. Put simply, the EHI definition represents the same
ePHI that a patient would have the right to request a copy of pursuant
to the HIPAA Privacy Rule. This is a regulatory concept with which the
industry has nearly 20 years of familiarity. Health IT developers'
customer base includes health care providers who are HIPAA covered
entities, and in many cases developers serve as HIPAA business
associates to their covered-entity customers. Thus, health IT
developers should be accustomed to identifying ePHI so that their
products support appropriately securing it, the fulfillment of patient
access requests, and the identification and reporting on breaches. They
should, therefore, be well prepared to identify what EHI their
product(s) would need to export in order to support a patient's HIPAA
right of access. The finalized criterion requires a certified Health IT
Module to include export capabilities for a single patient (Sec.
170.315(b)(10)(i)) and patient population (Sec. 170.315(b)(10)(ii))
related to EHI. More specifically, the export(s) will need to include
the EHI that can be stored at the time of certification by the product,
of which the Health IT Module is a part. We emphasize that such
``stored'' data applies to all EHI and is agnostic as to whether the
EHI is stored in or by the certified Health IT Module or in or by any
of the other ``non-certified'' capabilities of the health IT product of
which the certified Health IT Module is a part. The scope of EHI
applies across the product as a whole as a means to further promote the
access, exchange, and use of EHI for the use cases required to be
supported by this certification criterion. The finalized scope of data
included in the criterion export is discussed in greater detail under
the ``Scope of Data Export'' (IV.B.6.c) section below.
While the data that must be exported has been more specifically
scoped, the certification criterion does not require a specific
standard format be used for the purposes of representing the exported
EHI. We also modified the certification criterion's documentation
requirements in Sec. 170.315(b)(10)(iii) to be more concise. As
finalized, the documentation required for the export format(s) used to
support (b)(10)(i) and (ii) functionality must be kept up-to-date and
made available via a publicly accessible hyperlink. Additional
information is included under ``Export Format'' below.
We appreciate the comments received regarding the specific data
sets and data transmission standards for this certification criterion.
We reiterate that the finalized certification criterion is specific to
EHI, as defined, that can be stored at the time of certification by the
product, of which the Health IT Module is part, and is not limited to a
predefined data set or to specific data transmission standards.
Developers are required to ensure the health IT products they present
for certification are capable of exporting all of the EHI that can be
stored at the time of certification by the product. We acknowledge that
the amount of EHI exported and format in which such EHI is represented
will differ by developer and products of which certified Health IT
Modules are a part. Each product presented for certification, of which
the Health IT Module is a part, will likely vary in the amount of EHI
it can store. As a result, the amount of EHI that will need to be able
to be exported in order to demonstrate conformance with this
certification criterion will vary widely because of the diversity of
products presented for certification. For example, small software
components only capable of storing a certain scope of EHI (and only
certified to a few certification criteria) will only need to be able to
[[Page 25692]]
export that stored EHI in order to meet this certification criterion.
In contrast, a more comprehensive product with an EHI storage scope
well beyond all of the adopted certification criteria would by its
nature need to demonstrate it could export a lot more EHI. But even in
this latter case, it is important to note that while that scope of EHI
may be comprehensive for that product, it may still not be all of the
health information for which a health care provider is the steward and
that meets the EHI definition within the health IT products deployed
within their organization. In other words, a health IT user may have
other health IT systems with no connection to the Certification Program
that store EHI and such EHI would still be in scope from an information
blocking perspective. We note all of these distinctions to make clear
for and to dissuade readers from jumping to an improper conclusion that
the EHI export criterion in the Certification Program is a substitute
for or equivalent to the EHI definition for the purposes of information
blocking. We direct readers to the information blocking section (VIII)
for additional information. Unless a health care provider (which is an
``actor'' regulated by the information blocking provision) only used a
single health IT product to store EHI that was also certified to this
certification criterion, the EHI definition will always be larger.
Regardless of the amount of EHI each product has within its scope to
export, the purpose of this certification criterion is to make the EHI
already available in such health IT products more easily available for
access, exchange, and use by patients and their providers, which is a
fundamental principle established by the Cures Act.
As technology continues to advance, and as stated in the Proposed
Rule at 84 FR 7447, this criterion may not be needed in the future.
However, the comments suggesting we not adopt this certification
criterion at all because it will be outmoded at some point in the
future did not appear to acknowledge that all technology is eventually
replaced for a variety of reasons. We too look forward to a day where
standards-based APIs are the predominant method for enabling electronic
health information to be accessed, exchanged, and used. We strongly
encourage industry partners to engage in their own consortiums, with
ONC and other Federal agencies, and other stakeholders in the health IT
ecosystem to advance standards development, prototypes, and pilot
testing in order to ultimately build a body of evidence that could
accelerate the adoption and implementation timeline of technology that
could either add more structure to or remove the need for this
certification criterion in the future. However, we do not accept the
promise of this future state as a reason to simply wait, nor do we
believe that the potential of this future justifies delaying the
incremental progress the industry can make. In this case, had we
followed such commenters direction, we would be withholding from
patients and health care providers the certainty that there would be
technical capabilities within a defined time that could be used to
enable the access, exchange, and use of EHI. We note that suggestions
by commenters to structure the certification criterion to only move
information within specific data sets or via specific standards-based
export functionality would delay the ability of patients and users of
health IT to access, exchange, and use the information they need and
would run counter to the underlying principles supporting this
certification criterion--that the electronic health information should
be accessible for access, exchange, and use. For this reason, we have
not included specific data set or export requirements in this
certification criterion as some commenters suggested.
In consideration of comments, the finalized ``EHI export''
criterion in Sec. 170.315(b)(10) is not included in the 2015 Edition
Base EHR definition, which is a modification from what we proposed. We
revised the policy in recognition of comments received, including
comments regarding the structure and scope of the criterion as proposed
and the development burden of the criterion. As finalized here, we
believe that including this certification criterion in the Conditions
and Maintenance of Certification is the best place to include the
requirement associated with the criterion. Thus, we have finalized the
Sec. 170.315(b)(10) certification criterion as a general certification
requirement for the ONC Health IT Certification Program, and have not
included it in the 2015 Edition Base EHR Definition.
In general, we also note that those who use Health IT Module(s)
certified to the ``EHI export'' criterion remain responsible for
safeguarding the security and privacy of individuals' EHI consistent
with applicable laws and regulations related to health information
privacy and security, including the HITECH Act, HIPAA Privacy and
Security Rules, 42 CFR part 2, and State laws. The existence of a
technical capability to make EHI more accessible and useable by Health
IT Module users does not alter or change any of their data protection
responsibilities under applicable laws and regulations.
Comments. Comments received included concerns with the development
and use of the certification criterion. Some commenters expressed
support for the criterion's overall flexibility but cautioned ONC to be
realistic regarding the goals and expectations for the certification
criterion. These commenters also expressed concern that the proposed
certification criterion would result in development for an ambiguous
scope of data export and would divert from work needed to achieve other
interoperability goals. Other commenters stated concerns that
development costs could potentially be passed onto health IT users,
such as health care providers. These commenters also anticipated use
and implementation challenges for users that work with multiple
systems.
Response. We thank commenters for sharing their concerns. In
regards to the use of the capabilities required by this certification
criterion, we interpreted from comments some confusion related to
potential ``users'' of the health IT. As previously defined under the
Program, ``user'' is a health care professional or their office staff;
or a software program or service that would interact directly with the
certified health IT (80 FR 62611, 77 FR 54168).
We also appreciate the comments and concerns regarding the
potential development burden that could result to meet the requirements
of the proposed criterion. In consideration of those expressed
concerns, we have narrowed the scope of data that must be exported.
This more focused scope should measurably reduce the stated ambiguity
by commenters and development burden for health IT developers in
contrast to what was proposed (84 FR 7448). We appreciate the concerns
expressed for the potential user(s) of Health IT Modules, but note that
the certification criterion is designed to advance the electronic
movement of data out of a product while factoring in the current
variability in health IT. As always, we encourage developers to seek
innovative and expedient capabilities that, at minimum, meet the
requirements of the certification criterion, as well as the developing
needs of their health IT users.
Comments. Commenters provided alternative ideas for the criterion
specific to USCDI. Some recommended amending the criterion to require
the specific structure and applicable standards for USCDI elements, or
starting this criterion with a minimum of USCDI data elements. Several
commenters recommended expanding
[[Page 25693]]
the existing 2015 Edition ``data export'' criterion to include USCDI in
lieu of the proposed ``EHI export'' criterion.
Response. We thank commenters for sharing these ideas. We have
finalized the ``EHI export'' criterion as described above. Our intent
under this finalized criterion is to advance export functionality for
single patient and patient population EHI exports, while leaving
flexibility in regard to format and without assigning specific data
sets due to the different scopes of data that health IT may include.
Toward those ends, limiting the scope of this certification criterion
to solely the data represented by the USCDI would make it no different
than other USCDI bounded certification criteria already adopted and
would not advance the policy interests we have expressed. In regards to
comments on the existing 2015 Edition ``data export'' criterion (Sec.
170.315(b)(6)), we refer readers to our discussion of the criterion
below.
Comments. Some comments expressed confusion and asked for guidance
on how this certification criterion would apply to health IT that is no
longer certified. Commenters also asked for guidance on how this
criterion applies to other systems that interact with Health IT Modules
certified to this criterion based on the proposed scope of data for
export.
Response. We thank commenters for requesting clarification. We
first clarify that the export functionality under this certification
criterion applies to Health IT Modules presented for certification
under the Program. More specifically, if a health IT developer presents
for certification a health IT product of which a Health IT Module is a
part and the product electronically stores EHI, certification to Sec.
170.315(b)(10) is required. As noted in our response above, this would
include the EHI that can be stored at the time of certification by the
product, of which the Health IT Module is a part. This includes all EHI
stored by the product's certified and ``non-certified'' capabilities.
For example, if a health IT product includes a component(s) that is
presented for certification and that component stores EHI, then that
EHI must be made available for export, in accordance with Sec.
170.315(b)(10). Importantly, the scope of data required to be exported
in accordance with Sec. 170.315(b)(10) includes only to the EHI that
can be stored at the time of certification by the product. We emphasize
that such ``stored'' data applies to all EHI and is agnostic as to
whether the EHI is stored in or by the certified Health IT Module or in
or by any of the other ``non-certified'' capabilities of the health IT
product of which the certified Health IT Module is a part. The scope of
EHI applies across the product as a whole as a means to further promote
the access, exchange, and use of EHI for the use cases required to be
supported by this certification criterion.
a. Single Patient Export To Support Patient Access
As part of this criterion, we proposed a functionality for single
patient EHI export at 84 FR 7447 which would enable a user of certified
health IT to timely create an export file(s), with the proposed scope
of data export of all of the EHI the health IT product produces and
electronically manages on a single patient. The functionality would
also require a user to be able to execute this capability at any time
the user chooses and without subsequent developer assistance to
operate. In addition, we proposed that health IT certified to this
criterion would be required to enable the ability to limit the users
who could create such export file(s) in at least one of two ways: To a
specific set of identified users, and (2) as a system administrative
function. We also proposed that the export file(s) created must be
electronic and in a computable format and that the export file(s)
format, including its structure and syntax, must be included with the
exported file(s).
Comments. We received many comments in support of the proposal for
single patient export to support patient access under the certification
criterion. The majority of these commenters provided recommended
revisions, including suggested transmission formats and data export
content standards. Some commenters recommended the addition of this
certification criterion to the list of criteria subject to real world
testing.
Response. We thank commenters for their feedback. We have finalized
the single patient export functionality in Sec. 170.315(b)(10)(i) with
some modifications. We finalized a focused data export scope, which
applies to the data expected to be available for export under the
single patient export capability. We defined the scope of data that
needs to be exported to EHI that can be stored at the time of
certification by the product, of which the Health IT Module is a part.
Thus, we have modified the title of Sec. 170.315(b)(10)(i) to ``single
patient electronic health information export'' to reflect the scope of
this data export. We finalized that the capability for a user to
execute a single patient export must be able to be limited at least one
of two ways: To a specific set of identified users, and as a system
administrative function. While we finalized as proposed in Sec.
170.315(b)(10)(i)(D) that the export files must be electronic and in a
computable format, we modified in Sec. 170.315(b)(10)(ii)(E) that the
publicly accessible hyperlink of the export's format must be included
with the exported file(s). This modification clarifies that the user is
able to access the format, and that the developer will keep their
hyperlink up-to-date.
We appreciate commenter's recommendations for specific data
transmission formats and data content standards, and considered the
range of recommendations when developing the finalized scope of data
export required for this criterion. We believe the definition of EHI as
focused in Sec. 171.102, as well as the modifications to the scope of
data export, addresses the data ambiguity concerns received by
commenters. We direct readers to our detailed discussion of the scope
of data export below. As finalized, the certification criterion's
export, for both single and patient population EHI Export, remain
standards-agnostic. We believe that the finalized certification
criterion will serve as an initial step towards increased access,
exchange, and use of electronically available data. We will continue
working alongside industry stakeholders and will revisit export
strategies as standards continue to develop and mature. We appreciate
confirmation that commenters support inclusion of the criterion in
Sec. 170.315(b)(10) alongside the rest of the care coordination
criteria in Sec. 170.315(b), and have finalized that this
certification criterion is part of the real world testing Condition of
Certification requirement.
Comments. Some commenters asked ONC to clarify how health IT
developers may limit the users' ability to access and initiate the
export function in Sec. 170.315(b)(10)(i), and to include examples of
potential permissible and non-permissible behaviors.
Response. We appreciate the comments received. We again clarify
that ``user'' is a health care professional or their office staff; or a
software program or service that would interact directly with the
certified health IT (80 FR 62611, 77 FR 54168). In regards to questions
on permissible behaviors for developers, the ability to limit the
health IT users' access to the single patient EHI export functionality
in Sec. 170.315(b)(10)(i) is intended to be used by and at the
discretion of the organization implementing the technology. We
reiterate that similar to the 2015 edition ``data export'' criterion in
Sec. 170.315(b)(6), this cannot be used by health IT developers as a
way to
[[Page 25694]]
thwart or moot the overarching user-driven aspect of this capability
(80 FR 62646). We do not wish to limit this functionality to specific
permissible or non-permissible behaviors at this time, but reaffirm in
Sec. 170.315(b)(10)(i)(B) that a user must be able to execute the
single patient EHI export capability at any time the user chooses and
without subsequent developer assistance to operate. To be clear, the
user must be able to execute the export without the intervention of the
developer. We also finalize, as proposed, in Sec. 170.315(b)(10)(i)(C)
that this capability must limit the ability of user who create such
export files(s) in at least one of two ways; (1) to a specific set of
identified users, and (2) as a system administrative function.
Comments. The majority of comments received asked for further
clarity on ``timely'' regarding a health IT user's request to create an
export file(s).
Response. We thank commenters for the questions. We specify that
``timely'' means near real-time, while being reasonable and prudent
given the circumstances.
Comments. Commenters also sought clarity on data in electronic
health records that may be shared between patients and possibly
included in the export. These commenters asked if under the proposed
criterion, patients have a right to information about others that may
be contained in their medical record.
Response. We thank commenters for submitting these questions. In
regards to shared patient data concerns, we note that the export
functionality requirements apply to what a product with a Health IT
Module certified to this criterion must be able to do regardless of
whether the developer is operating the export for a health care
provider or a health care provider is maintaining and operating the
technology in their own production environment. Under the HIPAA Privacy
Rule, when a covered health care provider, in the course of treating an
individual, collects or otherwise obtains an individual's family
medical history, this information may become part of the medical record
for that individual and thus be included in the ``designated record
set'' (defined at 45 CFR 164.501)). Thus, if the family medical history
becomes part of the designated record set, the individual/patient may
exercise the right of access (45 CFR 164.524) under the HIPAA Privacy
Rule to this information in the same fashion as any other information
in the medical record. The HIPAA Privacy Rule does not prevent
individuals, themselves, from gathering medical information about their
family members or from deciding to share this information with family
members or others, including their health care providers. Thus,
individuals are free to provide their doctors with a complete family
medical history or communicate with their doctors about conditions that
run in the family. To the degree that, for example, Patient A's medical
record include that their mother had breast cancer, that information
would be accessible to Patient A because it was provided by Patient A
and included as part of their medical record. Under this criterion,
patients would not have a ``right'' to other patient's records,
consistent with existing laws. In general, with respect to patient
access to information, we note that Health IT Module users must ensure
that any disclosures of data conform to all applicable laws and
regulations, including but not limited to alignment between this rule
and the HIPAA Privacy Rule, as discussed in IV.B.6 above. We also refer
readers to the information blocking section at VIII in this preamble,
as well.
Comments. Commenters requested clarity on how ONC will monitor a
developer's compliance with exporting in a timely manner and what
penalties ONC will impose if there is a delay in regards to a Health IT
Module user's request. Commenters requested ONC release sub-regulatory
guidance that describes how users may file complaints and recommended
ONC work with the HHS Office for Civil Rights (OCR) on patient
education.
Response. Any noncompliance by developers with the finalized ``EHI
export'' certification criterion (Sec. 170.315(b)(10)) or the
associated Conditions and Maintenance of Certification requirements
(e.g., Sec. 170.402(a)(4) and (b)(2)) would be subject to review,
corrective action, and enforcement procedures under the Program. We
refer readers to the enforcement (VII) and information blocking (VIII)
sections of this preamble for further information. We do not believe
there is a general need to work with OCR further on this particular
issue or to issue further sub-regulatory guidance. The functionality of
the ``EHI export'' criterion in Sec. 170.315(b)(10) provides a user
(e.g., a health care provider) with the ability to export a file for a
single patient and multiple patients. If a user or other stakeholder
has concerns about ongoing compliance of health IT certified to this
criterion, with the required functionality of the criterion, or the
associated Conditions and Maintenance of Certification requirements,
they may file a complaint with the health IT developer, an ONC-ACB, or
ONC.
Comments. Some commenters requested specific stakeholder exemptions
from this requirement, such as health plans.
Response. We thank commenters for the recommendations. We note that
the ``EHI export'' criterion is applicable only to health IT products
presented by developers for certification under the Program that meet
the criterion and ``Assurances'' Condition of Certification
requirements in Sec. 170.402. In addition, we note that the
information subject to the export requirements is EHI that can be
stored at the time of certification by the product, of which the Health
IT Module is a part.
i. EHI Export for Patient-Initiated Requests
In the Proposed Rule, we reiterated that the ``user'' of the single
patient export functionality would typically be a provider or their
office staff on behalf of the patient (80 FR 62611, 77 FR 54168). We
also recognized that in service to innovative and patient-centric
approaches, a health IT developer could develop a method that allows a
patient to execute the request for data export without needing a
provider to do so on their behalf. Under this scenario, we sought
comments on whether the single patient export functionality should be
made more prescriptive and require that the developers design the
health IT to allow only the patient and their authorized representative
to be the requestor of their EHI (84 FR 7447).
Comments. In the scenario of patient-centric approaches created by
developers, the majority of commenters were in favor of developers
designing the export capability to make the patient and their
authorized representative able to be the direct requestors of their EHI
without needing a provider to execute this capability on their behalf.
We also received recommended terms to further define ``authorized
representative'' under this scenario. Several commenters advised
against specifying or restricting the potential additional user roles
able to initiate a single patient export. Some commenters recommended
additional requirements for developers, including requiring developers
to create this capability to enable the patient or their ``proxy'' to
request their information through and receive information from the
patient's health portal or an application. Commenters asked for the
final rule to include clarification on what the patient and their
authorized representative can access. We did receive some comments that
requested clarification of this potential approach.
[[Page 25695]]
We also received comments expressing confusion with the patient and
authorized representative requests applying across the certification
criterion, as opposed to the proposed and previously defined ``users''
of health IT that will typically perform the request on behalf of a
patient.
Response. We thank commenters for their input and requests for
clarification. In response to the concerns and potential confusion, we
clarify the following. This certification criterion does not require
``direct-to-patient'' functionality in order to demonstrate
conformance. Providing such a capability and demonstrating conformance
to this certification criterion with such a capability would be at the
sole discretion of the health IT developer. In general, just like with
the ``data export'' criterion in Sec. 170.315(b)(6), the capability to
execute this certification criterion can be health care provider/health
care organization initiated (presumably upon that organization
receiving a request by patient for their EHI). In instances where the
functionality certified to this criterion is implemented in a ``direct-
to-patient'' way such that the patient can request and accept EHI
export without assistance from a user, we recognize that further
configuration of the functionality or product in which it is
implemented may be needed in order to account for applicable laws
related to the patient's information access rights and other privacy
and information blocking policies that apply to the configuration and
use of the Health IT Module. While this specific capability within the
certification criterion emphasizes health IT developer assistance must
not be needed to operate the export, we recognize that user assistance
(e.g., a provider) may be necessary to initiate such capability in the
user's product.
b. Patient Population EHI Export for Transitions Between Health IT
Systems
In addition to the single patient export functionality in Sec.
170.315(b)(10)(i), we proposed in Sec. 170.315(b)(10)(ii) that health
IT certified to this criterion would also facilitate the migration of
EHI to another health IT system. We proposed that a health IT developer
or health IT certified to this criterion must, at a user's request,
provide a complete export of all EHI that is produced or electronically
managed (84 FR 7447 through 7448) by means of the developer's certified
health IT.
Comments. We received many comments in support of the functionality
under this criterion for transitions between health IT systems. Many
commenters recommended format and content specifications, such as the
use of bulk FHIR[supreg]-based APIs for export transmission. Some
commenters stressed that ONC should determine and require standards, as
well as clarify the scope of data export specific to this use case.
Some commenters expressed concerns, including gathering patient consent
and the developer burden that may exist with gathering data from
disparate systems under the proposed scope terminology. One commenter
was against the transitions between health IT systems capability,
citing that data structured for one system will not necessarily work in
another.
Response. We thank commenters for their feedback specific to the
functionality of transitions between health IT systems under this
criterion. We finalized this export functionality with modifications.
First, this functionality is now referred to as ``patient population
electronica health information export'' in Sec. 170.315(b)(10)(ii) to
better reflect the policy intent of patient data transitions in
instances of providers switching health IT systems, and to reflect the
finalized scope of data that a product with a certified Health IT
Module must be capable of exporting. Similar to the modifications in
Sec. 170.315(b)(10)(i), we finalized in Sec. 170.315(b)(10)(ii)(A)
that the export files must be electronic and in a computable format and
we modified in Sec. 170.315(b)(10)(ii)(B) that the publicly accessible
hyperlink of the export's format must be included with the exported
file(s). This modification clarifies that the user is able to access
the format, and that the developer will keep their hyperlink up-to-
date.
In response to comments on defining a separate scope of data export
specific to the patient population export functionality, it is our
final policy for this certification criterion to align both the single
patient and patient population export data to EHI, as defined in this
rule, that can be stored at the time of certification by the product,
of which the Health IT Module is a part. This narrower scope also
addressed concerns received regarding development burden expressed
regarding gathering data from disparate systems under the proposed
scope terminology.
In regards to the comments on enforcing format and standards for
data transmission, it is our intent under this certification criterion
that health IT developers have flexibility regarding how the export
outcome is achieved. We again encourage the industry to work together
toward this common goal and to create an industry-wide approach. We do
acknowledge the comments received that data structured for one system
may not necessarily seamlessly align with another, and refer commenters
to the export format requirements of this certification criterion. As
finalized in Sec. 170.315(b)(10)(ii)(A), the export created must be
electronic and in a computable format. In contrast with the single
patient EHI export capability, which must be available to a user
without subsequent developer assistance to operate, the patient
population EHI export capability of this criterion could require action
or support on the part of the health IT developer. We acknowledged in
the Proposed Rule (84 FR 7448) that because of anticipated large volume
of electronic health information that could be exported under this
specific proposed capability, developer action or support could be
needed. Our thinking remains the same post-public comments even with
the narrowed scope of data export. While exporting one patient's data
on an as-needed basis is a capability that should be executable by a
user on their own, orchestrating an entire export of EHI for migration
to another health IT system is an entirely different task and dependent
on a variety of factors such as the organization's overall
infrastructure and deployment footprint. Additionally, developers of
health IT certified to this criterion are required to provide the
assurances in Sec. 170.402, which include providing reasonable
cooperation and assistance to other persons (including customers,
users, and third-party developers) to enable the use of interoperable
products and services. Thus, while developers have flexibility
regarding how they implement the export functionality for transitions
between systems, they are ultimately responsible for ensuring that the
capability is deployed in a way that enables a customer and their
third-party contractors to successfully migrate data. Such cooperation
and assistance could include, for example, assisting a customer's
third-party developer to automate the export of EHI to other systems.
We refer readers to the export format section below for additional
details.
We note that the narrowed scope of data that certified Health IT
Modules must be capable of exporting does not reduce contractual
obligations of health IT developers to continue to support providers if
they do want to change systems, and direct readers to the information
blocking section (VIII) for additional information.
[[Page 25696]]
c. Scope of Data Export
We proposed in 84 FR 7448 and in Sec. 170.315(b)(10) that for both
use cases supported by this criterion, the scope of data that the
certified health IT product must be capable of exporting would
encompass all the EHI that the health IT system produces and
electronically manages for a patient or group of patients. Our
intention was that ``produces and electronically manages'' would
include a health IT product's entire database. In the Proposed Rule,
our use of the term EHI was deliberate. At the time of rulemaking, the
proposed definition of the EHI term in Sec. 171.102 was intended to
support the consistency and breadth of the types of data envisioned by
this proposed criterion. We requested comment on the terminology used
(``produces and electronically manages'') or whether there were
alternatives to the proposed language.
Comments. Some commenters were supportive of our proposed scope of
data export requirements, while a few others offered alternative
specific terminology options. Those commenters suggested terminology
such as all EHI the health IT system ``collects and retains,'' or
``produces or can electronically access, exchange, or use.'' A majority
of commenters, however, stated that the proposed terminology, including
the proposed EHI definition, left broad interpretations of the scope of
data a Health IT Module would have to be capable of exporting under
this criterion. These commenters expressed concerns that the ambiguity
and potentially vast amounts of data would create undue burden on
health IT developers for development and upkeep of export capabilities,
as well as compliance issues with other applicable laws. A majority of
commenters requested and highlighted a need for further specificity
regarding the terminology used to define data exported under this
criterion. Some commenters expressed concerns that a developer
presenting a Health IT Module for certification may not know all
systems a user may later connect to the health IT capabilities. We also
received many comments reflecting varied thoughts on what should or
should not be included in the criterion's data export. Some commenters
strongly opposed any data limits, citing existing regulations such as
the HIPAA Privacy Rule right of access, while others proposed
alternatives to constrain data export requirements, citing development
infeasibility.
Recommendations to constrain the proposed criterion's scope
included alignment with other regulations and data standards, such as
the USCDI. We also received a recommended requirement for health IT
developers to provide a plain language definition of the EHI typically
included in their Health IT Module's export. Some commenters expressed
confusion on how the criterion's proposed scope of data export may
apply to EHI ``produced or electronically managed'' by both the
product's certified and ``non-certified'' capabilities as well as data
from third parties.
Response. We thank commenters for feedback on our proposed terms
and for specific recommendations. The finalized criterion draws the
upper bound of its data scope from the focused definition of EHI as
finalized. The criterion export includes the EHI, as defined, that can
be stored at the time of certification by the product, of which the
Health IT Module is a part. As defined in this rule, EHI means
electronic protected health information as defined in 45 CFR 160.103 to
the extent that it would be included in a designated record set as
defined in 45 CFR 164.501 (other than psychotherapy notes as defined in
45 CFR 164.501 or information compiled in reasonable anticipation of,
or for use in, a civil, criminal, or administrative action or
proceeding), regardless of whether the actor is a covered entity as
defined in 45 CFR 160.103. In response to comments received, this
revised scope of data for export provides a more manageable and less
administratively burdensome certification criterion for health IT
developers for several reasons.
We agree with commenters that our proposed terms of all EHI a
health IT system ``produces and electronically manages'' (84 FR 7448)
raised the potential for broad variance in interpretations and concerns
about the breadth of data intended for export under this criterion and
potential development burden. We also considered the comments noting
that a developer presenting a Health IT Module for certification may
not, at the time of certification, know all systems a user will later
connect to the health IT capabilities. Ultimately, we considered
several approaches to better reflect the policy intent and to alleviate
confusion related to the proposed criterion. In consideration of the
public comments and the policy outcome we sought to address, we revised
the final criterion`s phrasing to describe what information health IT
products with Health IT Module(s) certified to the criterion must be
capable of exporting. The revised scope of data export applies to both
the single patient and patient population export functionalities as
well as the Conditions and Maintenance of Certification requirements
tied to this criterion.
First, we agree with comments received and acknowledge that a
health IT developer is best positioned to know (and would be solely
responsible for only) the EHI that can be stored by the health IT
product at the time the Health IT Module is presented for
certification. In response to comments regarding the applicability of
the scope of export to the product's certified and ``non-certified''
capabilities, as well as data from third parties, we clarify and
reiterate the following from our prior responses. We emphasize that
such ``stored'' data applies to all EHI and is agnostic as to whether
the EHI is stored in or by the certified Health IT Module or in or by
any of the other ``non-certified'' capabilities of the health IT
product of which the certified Health IT Module is a part. To be clear,
conformance ``at the time of certification'' means the combined data
that can be stored by the product, of which the Health IT Module is a
part, at the time the Health IT Module is presented for certification.
As such, for the purposes of this certification criterion, the EHI that
must be exported does not include any data generated from unique post-
certification in response to a particular customer (though such data
could meet the definition of EHI for the purposes of information
blocking). Such modifications could include custom interfaces and other
data storage systems that may be subsequently and uniquely connected to
a certified Health IT Module post-certification. Additionally, to
remain consistent with ``at the time of certification,'' we clarify
that any new EHI stored by the product due to ongoing enhancements
would need to be included within the scope of certification only when a
new version of the product with those new EHI storage capabilities is
presented for certification and listing on the CHPL. In consideration
of comments, we believe that this approach to define storage at the
time the product is presented for certification of a Health IT Module
will make the certification requirements more clear for health IT
developers and more efficient to administer from a Program oversight
perspective.
In addition, the use of ``can be stored by'' refers to the EHI
types stored in and by the health IT product, of which the Health IT
Module is a part. This is meant to be interpreted as the combination of
EHI a heath IT product stores itself and in other data storage
locations. Thus, the cumulative data
[[Page 25697]]
covered by these storage techniques would be in the scope of data
export.
Per our policy intent, by focusing the definition of EHI and
defining the data for export under this criterion, users of certified
Health IT, such as health care providers, will have the ability to
create ``readily producible'' exports of the information of a single
patient upon request by the user, which increases patient access as
reflected in the Cures Act. Lastly, in support of the second
functionality we finalized for patient population export, the EHI
exported (within the Health IT product's scope of data export) would
likely be of significant importance to health care providers for the
purposes of transitioning health IT systems and maintaining continuity
of care for patients, and also helps remove potential barriers to users
switching systems to meet their needs or their patient's needs.
In finalizing this policy, we emphasize that health IT developers
may provide the export of data beyond the scope of EHI and for
functionalities beyond those discussed under this criterion. In such
cases, for additional export purposes, it is advised that health IT
developers and users discuss and agree to appropriate requirements and
functionalities. We again emphasize that health IT product users must
ensure that any disclosures of data conform to all applicable laws,
including the HIPAA Rules and 42 CFR part 2. Stakeholders should review
applicable laws and regulations, including those regarding patients'
right of access to their data, in order to determine the appropriate
means of disclosing patient data. We also refer readers to the
information blocking section at VIII.
i. Image, Imaging Information, and Image Element Export
In the Proposed Rule, we noted at 84 FR 7448 that clinical data
would encompass imaging information, both images and narrative text
about the image. However, we addressed that EHRs may not be the
standard storage location for images. We solicited additional feedback
and comments on the feasibility, practicality, and necessity of
exporting images and/or imaging information. We requested comment on
what image elements, at a minimum, should be shared such as image
quality, type, and narrative text. We did not make any proposals in 84
FR 7448.
Comments. Most commenters were supportive of sharing images and/or
related data elements, expressing that interoperability should include
electronic ordering of imaging studies, which they asserted would
assist health care providers in delivering care. Other commenters
expressed burden concerns with data image export, particularly
challenges around the movement and storage of large amounts of data and
accumulating data from disparate health IT systems. A few commenters
requested specific exclusion of images or videos created as a byproduct
of procedures. As for minimum image data elements to share,
recommendations varied and included Digital Imaging and Communications
in Medicine (DICOMTM) data elements or file type
recommendations. Comments included additional policy recommendations,
such as making Picture Archiving and Communication Systems (PACS)
developers subject to certification rules and requiring EHI export data
to include links for remote authorized access to externally hosted
images.
Response. We thank commenters for their shared insight and
recommendations regarding the export of images, imaging information,
and image elements. Health IT Modules certified to the finalized
criterion must electronically export all of the EHI, as defined, that
can be stored at the time of certification by the product, of which the
Health IT Module is a part. Thus, any images, imaging information, and
image elements that fall within this finalized scope of EHI that can be
stored at the time of certification in or by the product, of which the
Health IT Module is a part will need to be exported under this
certification criterion. We appreciate the recommendations received for
image transfer methods and encourage the stakeholder community to
continue exploring innovative image transfer methods, including for
image transfer that would fall outside of this certification criterion.
We appreciate the policy recommendations, such as including PACS
developers. The ``EHI export'' certification criterion only applies to
developers of health IT seeking or maintaining certification under the
Program. To the extent such providers are developers of health IT under
the Program they would be included. If they are not developers under
the Program, they would not be included.
We also thank commenters for their suggestions to require data
export to include links for remote authorized access to externally
hosted images. We note that the export requirements of this
certification criterion refers to the EHI that can be stored at the
time of certification by the product, of which the Health IT Module is
a part. In the context of imaging, if the only EHI stored in or by the
product to which this certification criterion applies are links to
images/imaging data (and not the images themselves, which may remain in
a PACS) then only such links must be part of what is exported. We
encourage developers to work with their customers to achieve innovative
ways to share all relevant data, including situations outside of the
scope of data export under this criterion where images could be made
more accessible.
ii. Attestation of Information a Health IT Developer Cannot Support for
Export
In the Proposed Rule (84 FR 7448), we also solicited comment on
whether we should require, to support transparency, health IT
developers to attest or publish as part of the export format
documentation the types of EHI they cannot support for export. We did
not have any specific proposals.
Comments. The majority of commenters supported public attestation
regarding the information a Health IT Module is unable to export. Some
commenters requested that we add to the regulatory text to state that
developers attest to information they cannot support for export ``and/
or ingestion.'' Some commenters questioned if it is fair for EHI
developers to delineate what is in their Health IT Module's scope of
data for export under this criterion. Another felt that this
requirement should be extended to health care delivery organizations
and that the attestation should be included within patient portals or
other communications.
Response. We thank commenters for their feedback. We again note the
revised scope of data export under this finalized criterion. Under the
finalized approach, which focuses on the export of the EHI that can be
stored at the time of certification by the product, we have determined
that our final requirements provide sufficient clarity and have not
included any additional requirements such as those on which we sought
comment. Additionally, we believe the recommendation for ingestion
would be impracticable as part of this certification criterion due to
the flexibility we permit for the output format(s). It would not be
possible from a regulatory enforcement perspective to administer a
certification criterion that included within its scope a conformance
requirement for a Health IT Module's capability to import any
proprietary format that may exist without prior knowledge of such
formats.
iii. Export Exclusion Request for Comments
In the Proposed Rule, we proposed metadata categories at 84 FR 7448
for
[[Page 25698]]
exclusion from this criterion. We also requested feedback on what
metadata elements should remain included for export or added to the
list of excluded data. Metadata proposed for exclusion from the
criterion included metadata present in internal databases used for
physically storing the data, metadata that may not be necessary to
interpret the EHI export, and metadata that refers to data that is not
present in the EHI export. Examples of these proposed exclusions are
provided at 84 FR 7448.
Comments. Commenters offered varied recommendations for metadata
elements to remain excluded, or to be included under the scope of data
export for this criterion. We received several comments strongly
supporting the inclusion of audit log metadata. Commenters noted that
the inclusion of audit log metadata had potential legal utility and
could aid in the patient's ability to have all of their data and
knowing who has accessed their data. Commenters also requested
increased clarity on the definition of metadata, audit log, and access
log in regards to this rulemaking, and requested the use of standards
to further clarify policy intentions. We note, however, that other
commenters were against the inclusion of audit log data as part of the
EHI export. Those against inclusion stated that this information was
not necessary to interpret the EHI export, could be burdensome for
development of export capabilities, and potentially contain personally
identifiable information of the health care staff.
Response. We thank commenters for their input on potential metadata
exclusions. As noted above, we have finalized that EHI that can be
stored at the time of certification by the product is the scope of data
that must be included in exports pursuant to Sec. 170.315(b)(10).
Under this revised and specified scope of data export, it is no longer
necessary to list specific metadata exclusions or inclusions. We direct
readers to the discussion of scope of data export (IV.B.6.c) under this
criterion for further details.
d. Export Format
We did not propose a content standard for the export. However, we
did propose to require documentation in Sec. 170.315(b)(10)(iii) that
health IT developers include the export file(s) format, including its
structure and syntax, such as a data dictionary or export support file,
for the exported information to assist the user requesting the
information in processing the EHI (84 FR 7448). This was to prevent
loss of information or its meaning to the extent reasonably practicable
when using the developer's certified Health IT Module(s). We also
proposed in Sec. 170.315(b)(10)(iii) that the developer's export
format must be made available via a publicly accessible hyperlink and
kept up-to date.
Comments. Comments received were in favor of this proposal in Sec.
170.315(b)(10)(iii). Several commenters were supportive of the
flexibility of export format for developers, as long as export
documentation is provided as specified in the Proposed Rule, citing
specifically how this would support the export capability in Sec.
170.315(b)(10)(ii). Some commenters recommended additional
clarification for the publicly accessible hyperlink, specifically to
ensure that information is available without login or other associated
requirements. Commenters also provided export format suggestions.
Response. We thank commenters for their feedback regarding
developers' export format. We have finalized Sec. 170.315(b)(10)(iii)
with modifications to clarify the regulatory text. We finalized that
the export format(s) used to support Sec. 170.315(b)(10)(i) and Sec.
170.315(b)(10)(ii) of this section must be kept up-to-date.
We clarify that the documentation for the export format(s) in Sec.
170.315(b)(10)(iii) consists of information on the structure and syntax
for how the EHI will be exported by the product such as, for example,
C-CDA document(s) or data dictionary for comma separated values (csv)
file(s), and not the actual EHI. The user will use the export format
documentation to process the EHI after it is exported by the product.
We also require that health IT developers keep the export format(s)
used to support Sec. 170.315(b)(10)(i) and Sec. 170.315(b)(10)(ii)
must be ``up-to-date.'' For example, if the health IT developer had
previously specified the C-CDA standard as the export format for
meeting the criterion, but subsequently updated their product to use
the FHIR standard and stopped supporting C-CDA export format then the
documentation for export format would need to be updated so that users
are able to continue to accurately process the EHI exported by the
product. We appreciate suggestions received regarding ensuring that
such information is available without login or other associated
requirements. In response to these comments, our policy intent to
foster transparency, and in alignment with other certification
criterion requirements set forth in this rule, we note our
modifications in Sec. 170.315(b)(10)(i)(E) and Sec.
170.315(b)(10)(ii)(B) that the publicly accessible hyperlink of the
export's format must be included with the exported file(s). We clarify
that the hyperlink must allow any person to directly access the
information without any preconditions or additional steps. We note that
the export format need not be the same format used internally by the
certified health IT and the health IT developer does not need to make
public their proprietary data model. This certification criterion also
does not prescribe how (i.e., media/medium) the exported information is
to be made available to the user, as this may depend on the size and
type of information to be exported. While file formats and related
definitions are not finalized as specific certification requirements,
we encourage developers to continue to foster transparency and best
practices for data sharing, such as machine-readable format, when they
create and update their export format information.
e. Initial Step Towards Real-Time Access
In the Proposed Rule at 84 FR 7449, we offered a clarifying
paragraph to highlight that the criterion in Sec. 170.315(b)(10) was
intended to provide a step in the direction of real-time access goals,
as well as a means to, within the confines of other applicable laws,
encourage mobility of electronic health data while other data transfer
methods were maturing. In that section, we clarified that
``persistent'' or ``continuous'' access to data is not required to
satisfy the proposed ``EHI export'' criterion's requirements, and that
the minimum requirement of developers presenting Health IT Module(s)
for certification to this criterion is for a discrete data export
capability. In this clarification section, we did not have specific
proposals or requests for comments.
Comments. We received recommendations to further specify the use of
``persistent'' and ``continuous'' in context of access to EHI.
Additional commenters recommended specifying Representational state
transfer (REST) or ``RESTful'' transfer, or specifying data transport
methods.
Response. We thank commenters for their input. We first clarify
that this section was added to the Proposed Rule for additional
clarification and to provide prospective context on the proposed
certification criterion. However, we recognize from the comments
received that our reference to ``persistent'' or ``continuous'' access
in the Proposed Rule may have created confusion. We again note that
``persistent'' or ``continuous'' access is not required by health IT
developers
[[Page 25699]]
presenting Health IT Module(s) to satisfy the requirements of this
certification criterion. We have finalized the ``EHI export'' criterion
as described above in response to comments received on proposals we
have made. We appreciate the responses to our future looking points in
the Proposed Rule but have not made further revisions to the final
certification criterion in response.
f. Timeframes
We requested input and comments on the criterion and timeframes at
84 FR 7449. In particular, beyond the proposal to export all the EHI
the health IT system produces and electronically manages, we sought
comment on whether this criterion should include capabilities to permit
health care providers to set timeframes for the EHI export, such as
only the ``past two years'' or ``past month'' of EHI (84 FR 7449).
Comments. A majority of commenters were against the concept of
allowing providers to set timeframes for the export functionality.
Commenters were concerned that creating the capability to limit
timeframes would involve significant technical complexity for health IT
developers. Commenters also expressed concern that allowing providers
the capability to limit timeframes would not align with the HIPAA
Privacy Rule right of access at 45 CFR 164.524 and could potentially
implicate information blocking. Commenters provided alternative
approaches and concepts to implement timeframe capabilities for this
criterion, including use of APIs, granting flexibility to developers,
allowing intervals or dynamic timeframe requirements, and considering
permitted fees. Commenters asked for clarification on how far back the
data request capabilities could go and requested clarification
regarding how this criterion aligns with other API-related criteria
within this rule.
Response. We thank commenters for their feedback. We will not
require the Health IT Module support a specific or user-defined
timeframe range or time limit capability for the purposes of
demonstrating conformance to this certification criterion. We agree
with commenters concerns regarding potential development complexity for
health IT developers if we included such a requirement upfront. What
this means, however, is that for the purposes of testing and
certification, a health IT developer will need to prove that the
product, of which a Health IT Module is part, can perform the
capabilities required by the certification criterion, inclusive of all
EHI that could be exported. In turn, when these capabilities are
deployed in production they will need to be capable of exporting all of
the EHI that can be stored at the time of certification by the product,
of which the Health IT Module is a part. We also agree with the points
received regarding the HIPAA Privacy Rule right of access at 45 CFR
164.524 and emphasize the importance of HIPAA covered entities aligning
with applicable law regarding patient access to health information.
g. 2015 Edition ``Data Export'' Criterion in Sec. 170.315(b)(6)
We proposed to remove the ``data export'' criterion (defined in
Sec. 170.315(b)(6)) from the 2015 Edition Base EHR definition in Sec.
170.102 and to replace ``data export'' with the proposed ``EHI export''
criterion (defined in Sec. 170.315(b)(10)) by amending the third
paragraph of the 2015 Edition Base EHR definition in Sec. 170.102. We
did not propose a transition period for the ``data export'' criterion.
Rather, we proposed to remove the criterion from the 2015 Edition Base
EHR definition upon the effective date of a final rule. We also
proposed to modify the 2015 Edition Base EHR definition to include the
new proposed export criterion (defined in Sec. 170.315(b)(10)), with
an implementation date 24 months from the effective date of the final
rule. We welcomed comments on this approach.
Comments. Some commenters were in favor of immediate removal of
this criterion (Sec. 170.315(b)(6)) from the 2015 Edition Base EHR
definition, stating it would reduce burden. However, the majority of
commenters were against a potential gap in functionality due to the
compliance timeline for the new export criterion (Sec. 170.315(b)(10))
and requested that we keep the ``data export'' criterion until the new
criterion in Sec. 170.315(b)(10) and other standardized data
transmission methods were fully implemented. Some commenters supported
an indefinite retention of the ``data export'' criterion, regardless of
the proposed addition of Sec. 170.315(b)(10). Several commenters also
recommended to expand the current Sec. 170.315(b)(6) criterion through
USCDI as an alternative approach to the proposed ``EHI export''
criterion in Sec. 170.315(b)(10). In addition, some commenters
expressed concern that that the ``data export'' criterion is
inconsistent with CMS Quality Payment Program (QPP) requirements such
as View, Download, and Transmit (VDT) at 83 FR 59814 of the CY 2019
Physician Fee Schedule final rule.
Response. In consideration of public comments in support of the
retention of the ``data export'' certification criterion, we have
maintained the ``data export'' certification criterion in Sec.
170.315(b)(6) as available for certification until 36 months after this
final rule's publication date. To implement this decision, we have
finalized in Sec. 170.550(m) that ONC-ACBs are permitted to issue
certificates to ``data export'' in Sec. 170.315(b)(6) until, but not
after, 36 months after the publication date of this final rule.
However, we note the ``data export'' certification criterion has been
removed from the 2015 Edition Base EHR definition (in Sec. 170.102) as
of the general effective date of this final rule (60 days after its
publication in the Federal Register). During the 36 months immediately
following publication of this final rule, developers will be able to
maintain the certification to Sec. 170.315(b)(6) as a standardized
means of exporting the discrete data specified in the CCDS, but the
criterion will not be updated to the USCDI. Given that certification to
the Sec. 170.315(b)(6) criterion will no longer be available after 36
months, we do not believe an update to the USCDI is the best path.
Rather, Sec. 170.315(b)(6) will remain an unchanged criterion in the
Program for the 36 months immediately following publication of this
final rule in the Federal Register. After that timeframe, the EHI
export criterion in Sec. 170.315(b)(10), including that certification
criterion's scope of data export, will remain an available data export
certification criterion for health IT developers that present for
certification a Health IT Module that is part of a heath IT product
which electronically stores EHI. This approach will support prior
investments in Sec. 170.315(b)(6) by developers and their customers,
and also encourage movement toward the interoperability opportunities
afforded by new criteria.
Regarding commenter concerns that the ``data export'' criterion is
inconsistent with CMS QPP requirements, such as View, Download and
Transmit (VDT), we do not believe that this criterion would be
inconsistent with QPP program requirements. In the CY 2019 Physician
Fee Schedule final rule, CMS removed the VDT measure in Sec.
170.315(e)(1) (83 FR 59814). However, the Promoting Interoperability
performance category of QPP currently includes the measure entitled
Provide Patients Electronic Access to their Health Information (83 FR
59812 through 59813), and CMS has identified technology certified to
the ``View, Download and Transmit to 3rd party'' criterion at 45 CFR
170.315(e)(1) as required to meet this measure (83 FR
[[Page 25700]]
59817). The Data Export criterion in Sec. 170.315(b)(6) is not
required for the Provide Patients Electronic Access to their Health
Information measure included in the Promoting Interoperability
performance category, nor have we proposed to change the ``View,
Download and Transmit to 3rd party'' criterion in Sec. 170.315(e)(1)
required for this measure, thus we do not believe this final policy
will conflict with CMS requirements for QPP.
7. Standardized API for Patient and Population Services Criterion
We proposed to adopt a new API criterion in Sec. 170.315(g)(10) at
84 FR 7449. In response to comments, we are adopting a Standardized API
for Patient and Population Services criterion for Certification in
Sec. 170.315(g)(10) with modifications. The new criterion, will
replace the old ``application access--data category request''
certification criterion (Sec. 170.315(g)(8)). In doing so, we are also
adding the Standardized API for Patient and Population Services
criterion to the updated 2015 Edition Base EHR definition and removing
the application access--data category request criterion (Sec.
170.315(g)(8)). This finalized Standardized API for patient and
population services certification criterion requires the use of the
FHIR Release 4 and several implementation specifications. The new
criterion focuses on supporting two types of API-enabled services: (1)
Services for which a single patient's data is the focus and (2)
services for which multiple patients' data are the focus. Please refer
to the ``Application Programming Interfaces'' section (VII.B.4) in this
preamble for a more detailed discussion of the ``API'' certification
criterion and related Conditions and Maintenance of Certification
requirements.
8. Privacy and Security Transparency Attestations Criteria
In 2015, the HIT Standards Committee (HITSC) recommended the
adoption of two new ``authentication'' certification criteria for the
Program (81 FR 10635). The National Coordinator endorsed the HITSC
recommendations for consideration by the Secretary, and the Secretary
determined that it was appropriate to propose adoption of the two new
certification criteria through rulemaking. To implement the Secretary's
determination, we proposed two new criteria to which health IT would
need to be certified (84 FR 7450). These would require the developer to
attest to whether the Health IT Module for which they are seeking
certification to the criteria encrypts authentication credentials
(Sec. 170.315(d)(12)) and/or supports multi-factor authentication
(Sec. 170.315(d)(13)). We did not propose to require that health IT
have these authentication and encryption-related functions, but instead
proposed that a health IT developer must indicate whether or not their
certified health IT has those capabilities by attesting ``yes'' or
``no.'' We did, however, propose to include the two criteria in the
2015 Edition privacy and security certification framework (Sec.
170.550(h)). For clarity, attesting ``yes'' to either of these criteria
indicates that the Health IT Module can support either Approach 1 or
Approach 2 of the 2015 Edition privacy and security certification
framework for these criteria.
We note that we received many comments on the proposed ``encrypt
authentication credentials'' and ``multi-factor authentication''
criteria, but the majority of comments conflated the two proposals and
provided collective responses. Therefore, we have responded to them in
kind to preserve the integrity of the comments.
a. Encrypt Authentication Credentials
We proposed in 84 FR 7450 to adopt an ``encrypt authentication
credentials'' certification criterion in Sec. 170.315(d)(12) and
include it in the P&S certification framework (Sec. 170.550(h)). We
proposed to make the ``encrypt authentication credentials''
certification criterion applicable to any Health IT Module currently
certified to the 2015 Edition and any Health IT Module presented for
certification that is required to meet the ``authentication, access
control, and authorization'' certification criterion adopted in Sec.
170.315(d)(1) as part of Program requirements.
Encrypting authentication credentials could include password
encryption or cryptographic hashing, which is storing encrypted or
cryptographically hashed passwords, respectively. If a developer
attests that its Health IT Module encrypts authentication credentials,
we proposed in 84 FR 7450 that the attestation would mean that the
Health IT Module is capable of protecting stored authentication
credentials in accordance with standards adopted in Sec.
170.210(a)(2), Annex A: Federal Information Processing Standards (FIPS)
Publication 140-2, ``Approved Security Functions for FIPS PUB 140-2,
Security Requirements for Cryptographic Modules.'' We posited that FIPS
Publication 140-2 is the seminal, comprehensive, and most appropriate
standard. Moreover, in the specified FIPS 140-2 standard, there is an
allowance for various approved encryption methods, and health IT
developers would have the flexibility to implement any of the approved
encryption methods in order to attest ``yes'' to this criterion. We
noted that health IT developers should keep apprised of these standards
as they evolve and are updated to address vulnerabilities identified in
the current standard.
We did not propose that a Health IT Module would be required to be
tested to the ``encrypt authentication credentials'' certification
criterion. Rather, by attesting ``yes,'' the health IT developer is
attesting that if authentication credentials are stored, then the
authentication credentials are protected consistent with the encryption
requirements above. We proposed in 84 FR 7450 that the attestations
``yes'' or ``no'' would be made publicly available on the Certified
Health IT Product List (CHPL). We proposed in 84 FR 7450 that, for
health IT certified prior to the final rule's effective date, the
health IT would need to be certified to the ``encrypt authentication
credentials'' certification criterion within six months after the final
rule's effective date. For health IT certified for the first time after
the final rule's effective date, we proposed that the health IT must
meet the proposed criterion at the time of certification.
We also noted that some Health IT Modules presented for
certification are not designed to store authentication credentials.
Therefore, we specifically requested comment on whether we should
include an explicit provision in this criterion to accommodate such
health IT. We stated that this could be similar to the approach we
utilized for the 2015 Edition ``end-user device encryption'' criterion
(Sec. 170.315(d)(7)(ii)), where we permit the criterion to be met if
the health IT developer indicates that their health IT is designed to
prevent electronic health information from being locally stored on end-
user devices.
b. Multi-Factor Authentication
We proposed in 84 FR 7450 to adopt a ``multi-factor
authentication'' (MFA) criterion in Sec. 170.315(d)(13) and include it
in the P&S certification framework (Sec. 170.550(h)). We proposed to
make the ``multi-factor authentication'' certification criterion
applicable to any Health IT Module currently certified to the 2015
Edition and any Health IT Module presented for certification that is
required to meet the ``authentication, access control, and
authorization'' certification criterion adopted in Sec. 170.315(d)(1)
as part of Program requirements. To provide clarity as to what a
``yes'' attestation for ``multi-factor authentication'' attestation
would
[[Page 25701]]
mean, we provided the following explanation. MFA requires users to
authenticate using multiple means to confirm they are who they claim to
be in order to prove one's identity, under the assumption that it is
unlikely that an unauthorized individual or entity will be able to
succeed when more than one token is required. MFA includes using two or
more of the following: (i) Something people know, such as a password or
a personal identification number (PIN); (ii) something people have,
such as a phone, badge, card, RSA token or access key; and (iii)
something people are, such as fingerprints, retina scan, heartbeat, and
other biometric information. Thus, we proposed in 84 FR 7451 that in
order to be issued a certification, a health IT developer must attest
to whether or not its Health IT Module presented for certification
supports MFA consistent with industry-recognized standards (e.g., NIST
Special Publication 800-63B Digital Authentication Guidelines, ISO
27001).\52\
---------------------------------------------------------------------------
\52\ NIST Special Publication 800-63B: https://pages.nist.gov/800-63-3/sp800-63b/cover.html
---------------------------------------------------------------------------
We proposed in 84 FR 7451 that, for health IT certified prior to
the final rule's effective date, the health IT would need to be
certified to the ``multi-factor authentication'' certification
criterion within six months after the final rule's effective date. For
health IT certified for the first time after the final rule's effective
date, we proposed that the health IT must meet this criterion at the
time of certification. We solicited comment on the method of
attestation and, if the health IT developer does attest to supporting
MFA, whether we should require the health IT developer to explain how
they support MFA. In particular, we asked whether a health IT developer
should be required to identify the MFA technique(s) used/supported by
submitting specific information on how it is implemented, including
identifying the purpose(s)/use(s) to which MFA is applied within their
Health IT Module, and, as applicable, whether the MFA solution complies
with industry standards.
Comments. The vast majority of commenters supported the adoption of
the two proposed privacy and security transparency attestation
certification criteria. A few commenters were opposed to the new
criteria. Several supporters of the proposed criteria recommended that
we make the criteria operative functional requirements (including
testing), rather than yes/no attestations. Some of these commenters
reasoned that MFA should be a requirement for all certified health IT,
given the risks involved with single-factor authentication and how easy
it is today to implement MFA. We also received a number of comments
requesting that we clarify that the MFA proposal does not create a
requirement for health care providers to implement MFA or encryption of
authentication credentials. Similarly, we received several comments
seeking clarification that a ``yes'' attestation would only require
support of MFA, not that MFA would have to be implemented. Along these
same lines, several commenters expressed concerns that the requirements
could interfere with clinical care and urged that the requirements not
contribute to provider burden.
Response. We have adopted both proposed privacy and security
transparency attestation criteria and included both criteria (Sec.
170.315(d)(12) and Sec. 170.315(d)(13)) in the P&S certification
framework (Sec. 170.550(h)), with minor modifications. While some
commenters recommended that MFA should be a requirement for all
certified health IT, we did not propose such a requirement nor could
health IT developers have foreseen such an outcome in this final rule
based on our proposals, particularly considering the clarity provided
with our proposals (84 FR 7450) and the complexities of such a
requirement. For example, as noted by commenters below, MFA may not be
appropriate or applicable in all situations and there is wide variation
in authentication needs and approaches throughout the industry. These
criteria will, however, still provide increased transparency, and if a
developer attests ``yes'' to these criteria regarding a certified
Health IT Module, that Health IT Module will then be subject to ONC-ACB
surveillance for any potential non-conformity with the requirements of
these criteria. Given the strong support expressed in public comments
for these criteria as proposed, we believe this is the appropriate
approach at this time.
While we believe that encrypting authentication credentials and MFA
represent best practices for privacy and security in health care
settings, we emphasize again that these criteria do not require
certified health IT to have these capabilities or for health IT
developers to implement these capabilities for a specific use case or
any use case. Equally important, the criteria place no requirements on
health IT users, such as health care providers, to implement these
capabilities (if present in their Health IT Modules) in their health
care settings. However, we note that information regarding the security
capabilities of certified health IT provided by such transparency can
aid health IT users in making informed decisions on how best to protect
health information and comply with applicable security regulations
(e.g., the HIPAA Security Rule).
Comments. Some commenters who supported the proposed criteria
requested clarification on the scope and intent of the criteria,
including what level of authentication and which types of users and
user roles the criteria apply to, as well as on how to attest for
multiple sign-on paths. A number of commenters noted the wide variation
in authentication needs and approaches throughout the industry, and
they recommended that we permit health IT developers to describe how
they support authentication, rather than simply attest ``yes'' or
``no.'' The commenters stated that such information would provide
helpful clarity regarding what the certified health IT supports.
Additionally, several commenters stated that we should require that
health IT developers explain how they support MFA. A number of
commenters stressed that MFA may not be appropriate or applicable in
all situations, and in particular, several commenters noted that
automated transactions, including some that may occur in the public
health reporting context, cannot support MFA.
Response. In response to requests for modifications and
clarifications, we have modified the ``encrypt authentication
credentials'' criterion to permit a health IT developer that attests
``no'' for its Health IT Module(s) to indicate why the Health IT
Module(s) does not support encrypting stored authentication
credentials. A health IT developer that attests ``no'' to the ``encrypt
authentication credentials'' criterion may explain, for example, that
its Health IT Module is not designed to store authentication
credentials, therefore there is no need for the Health IT Module to
encrypt authentication credentials because it does not store, or have
the capability to store, authentication credentials.
For the ``MFA'' criterion, consistent with our solicitation of
comments and the comments received recommending that health IT
developers explain how they support MFA, we have modified the criterion
to require health IT developers that attest ``yes'' to describe the use
cases supported. For example, a health IT developer could attest
``yes'' to supporting MFA and state that the Health IT Module supports
MFA for remote access by clinical users, thus providing clarity on the
user roles to which MFA applies for that particular Health IT Module.
To be clear, health IT
[[Page 25702]]
developers are not expected to provide specific technical details about
how they support MFA that could pose security risks. Again, the purpose
is to enable health IT developers to give an indication of the types of
uses for which their Health IT Module(s) support MFA. We note that
health IT developers may wish to add new MFA use cases for their
certified health IT over a period of time. In such instances, to
provide the clarity sought in the Proposed Rule as to the MFA
technique(s) used/supported and how MFA is implemented, including
identifying the purpose(s)/use(s) to which MFA is applied within their
Health IT Modules, any new MFA use cases are required to comply with
this criterion's ``yes'' attestation provisions and be part of the
quarterly CHPL reporting by health IT developers and ONC-ACBs under
Sec. 170.523(m).
If a health IT developer attests ``no,'' then it would not be
required to explain why its Health IT Module does not support
authentication, through multiple elements, of the user's identity with
the use of industry-recognized standards. We did not propose to require
an explanation for ``no'' attestation nor did we request comment on
allowing health IT developers to provide an explanation for a ``no''
attestation like we did for ``yes'' attestations (84 FR 7450-7451).
However, in an effort to provide transparency and consistency for these
privacy and security attestation criteria, we will also permit
developers to provide a reason for attesting ``no'' in order to provide
more context. Such a reason may be due to MFA being inapplicable or
inappropriate. In those cases, a developer could state, for example,
that the Health IT Module does not support MFA because it is engaged in
system-to-system public health reporting and MFA is not applicable.
Comments. We received several comments requesting adjustment to the
deadline for compliance to meet these criteria. We also received a
number of comments recommending that we only apply both of the proposed
criteria to new certifications and new Health IT Modules, and not to
Health IT Modules already in widespread use.
Response. Regarding the timeframe for compliance, and in response
to comments recommending that we only apply the criteria to ``new
certifications,'' we have determined that certification to these
criteria as part of the updated 2015 Edition privacy and security
certification framework (Sec. 170.550(h)) will only be necessary for
Health IT Modules that are presented for certification. Thus, a new
Health IT Module seeking certification for the first time to the
criteria specified in the 2015 Edition privacy and security
certification framework (Sec. 170.550(h)), after the effective date of
this final rule, will need to meet these privacy and security
transparency attestation criteria at the time of certification.
Similarly, a previously certified Health IT Module that has undergone
revision, such as removal of certain capabilities, and is presenting
for revised certification to the criteria specified in the 2015 Edition
privacy and security certification framework (Sec. 170.550(h)) after
the effective date of this final rule, will need to meet these privacy
and security transparency attestation criteria at the time of
certification. We believe that this approach will still provide the
intended transparency as health IT will need to be issued new
certifications as Health IT Modules are updated or certified to other
new or revised criteria adopted in this final rule. At the same time,
this approach should reduce burden for health IT developers and allow
them more time to plan and prepare to meet these new transparency
requirements.
9. Security Tags and Consent Management Criteria
In the 2015 Edition final rule, we adopted two ``data segmentation
for privacy'' (DS4P) certification criteria. One criterion, ``DS4P-
send'' (Sec. 170.315(b)(7)), includes capabilities for applying
security tags according to the DS4P standard in Sec. 170.205(o) at the
document-level of a summary care record formatted to the C-CDA 2.1
standard in Sec. 170.205(a)(4). The other criterion, ``DS4P-receive''
(Sec. 170.315(b)(8)), includes capabilities for receiving a summary
care record formatted to the C-CDA 2.1 standard in Sec. 170.205(a)(4)
with document-level security tags according to the DS4P standard in
Sec. 170.205(o). As noted in the 2015 Edition final rule (80 FR
62646), certification to these criteria is not required to meet the
CEHRT definition for PI Programs.
Security tagging enables computer systems to recognize the
existence of sensitive elements in data and properly protect the
privacy and security of the data by ensuring that only the appropriate
individuals and entities can access it. Security tagging capabilities
do not compromise the availability or comprehensiveness of health
information available for treatment or research purposes; rather, they
enable appropriate access controls in accordance with existing
policies, governance, and applicable laws. The DS4P standard describes
a method for applying security tags to HL7 CDA documents to ensure that
privacy policies established at a record's source can be understood and
enforced by the recipient of the record.
The utility of the DS4P standard is not limited to data subject to
the Federal regulations governing the Confidentiality of Substance Use
Disorder Patient Records, 42 CFR part 2 (80 FR 62647). DS4P may be
implemented to support other data exchange use cases in which
compliance with State or Federal legal frameworks require special
protections for sensitive health information. Security tagging
capabilities are an initial step towards enabling an interoperable
health care system to use technical standards to permit appropriate
access, use, or disclosure of sensitive health information in
accordance with applicable policies and patient preferences. We
understand and acknowledge additional challenges related the prevalence
of unstructured data, sensitive images, and potential issues around use
of sensitive health information by clinical decision support systems.
The adoption of document level data tagging for structured documents
would not solve these issues, but could help move technology in the
direction where these issues could be addressed (80 FR 16841).
Adoption of the 2015 Edition final rule DS4P criteria was
consistent with earlier HIT Policy Committee (HITPC) recommendations
for the use of security tagging to enable the electronic implementation
and management of disclosure policies that originate from the patient,
the law, or an organization, in an interoperable manner, so that
electronic sensitive health information may be appropriately
shared.\53\ The HITPC recommendations consisted of a glide path for the
exchange of 42 CFR part 2-protected data starting with the inclusion of
Level 1 (document level tagging) send and receive functionality. The
HITPC also recommended advancing the exchange of 42 CFR part 2-
protected data, by outlining additional capabilities in sharing,
viewing and incorporating privacy restricted data at a more granular
level, as well as
[[Page 25703]]
managing computable patient consent for the use of restricted data.\54\
---------------------------------------------------------------------------
\53\ See HIT Policy Committee (HITPC) Recommendation Letter to
ONC, July 2 014, http://www.healthit.gov/facas/sites/faca/files/PSTT_DS4P_Transmittal%20Letter_2014-07-03.pdf; see also HITPC's
Privacy and Security Tiger Team Public Meeting, Transcript, May 12,
2014, http://www.healthit.gov/facas/sites/faca/files/PSTT_Transcript_Final_2014-05-12.pdf.; Public Meeting, Transcript,
May 27, 2014, http://www.healthit.gov/facas/sites/faca/files/PSTT_Transcript_Final_2014-05-27.pdf.
\54\ For more details on the two glide paths for part 2-
protected data, see http://www.healthit.gov/facas/sites/faca/files/PSTT_DS4P_Transmittal%20Letter_2014-07-03.pdf.
---------------------------------------------------------------------------
Since the 2015 Edition final rule, the health care industry has
engaged in additional field testing and implementation of the DS4P
standard. As of the beginning of the fourth quarter of the 2019
calendar year, 34 Health IT Modules were certified to one or both of
the current 2015 Edition DS4P certification criteria (Health IT Modules
with multiple certified versions were counted once). Stakeholders have
shared with ONC--through public forums, listening sessions, and
correspondence--that document-level security tagging does not provide
enough flexibility to address more complex privacy and security use
cases. Stakeholders noted that certain provider types, such as
pediatrics and behavioral health, often rely on burdensome manual
workflows to appropriately segment and share sensitive health
information according to State and local laws. Additionally,
stakeholders expressed interest in ONC adopting health IT standards
that work with DS4P to support electronic consent for the exchange of
security tagged data over an API.
Therefore, in consideration of stakeholder feedback and HITPC
recommendations to adopt DS4P certification criteria on a glide path,
we proposed (84 FR 7452) to remove the 2015 Edition DS4P-send (Sec.
170.315(b)(7)) and DS4P-receive (Sec. 170.315(b)(8)) certification
criteria. We proposed that the effective date of removal of these
criteria would be the effective date of the final rule. We proposed to
replace the removed DS4P criteria with two new 2015 Edition DS4P
certification criteria in Sec. 170.315(b)(12) and Sec. 170.315(b)(13)
that would support security tagging according to the DS4P standard at
the document, section, and entry levels of C-CDA 2.1 formatted
documents. Our primary purpose for proposing to remove and replace the
criteria, in lieu of proposing to revise them, was to provide clarity
to stakeholders about the additional functionality enabled by health IT
certified to the new criteria. We also proposed a new 2015 Edition
certification criteria for sharing patient consent information over an
API using the Substance Abuse and Mental Health Services
Administration's (SAMHSA) Consent2Share (C2S) IG a FHIR-based exchange
standard, in Sec. 170.315(g)(11). We noted resources released by ONC
and OCR, such as the HHS Security Risk Assessment Tool \55\ and the
Guide to Privacy and Security of Electronic Health Information,\56\ as
well as the Office for Civil Rights' security risk analysis guidance
\57\ that entities may employ to make risk-based decisions regarding
their implementation of the proposed DS4P criteria. We also noted the
availability of the Electronic Consent Management Landscape Assessment,
Challenges, and Technology report.\58\ The report includes suggestions
for overcoming barriers associated with implementing electronic consent
management, which may be considered for further research and
discussion.
---------------------------------------------------------------------------
\55\ HHS Security Risk Assessment Tool: http://www.healthit.gov/providers-professionals/security-risk-assessment.
\56\ ONC Guide to Privacy and Security of Electronic Health
Information: http://www.healthit.gov/sites/default/files/ pdf/
privacy/privacy-and-security-guide.pdf.
\57\ HHS Office for Civil Rights: https://www.hhs.gov/hipaa/for-professionals/security/guidance/index.html; and https://www.hhs.gov/hipaa/for-professionals/security/guidance/guidance-risk-analysis/index.html?language=es.
\58\ https://www.healthit.gov/sites/default/files/privacy-security/ecm_finalreport_forrelease62415.pdf.
---------------------------------------------------------------------------
We note that we received many comments on the proposed DS4P
criteria and the proposed consent management for the API criterion but
the majority of comments conflated the two proposals and provided a
collective response. We tried to separate where possible, but in some
instances, we kept them combined in order to preserve the integrity of
the comments.
a. Implementation With the Consolidated CDA Release 2.1
In place of the removed 2015 Edition DS4P criteria, we proposed (84
FR 7452) to adopt new DS4P-send (Sec. 170.315(b)(12)) and DS4P-receive
(Sec. 170.315(b)(13)) criteria that would remain based on the CDA 2.1
and the HL7 DS4P standard. These criteria would include capabilities
for applying security tags according to the DS4P standard at the
document, section, and entry level. We believe this offers more
valuable functionality to providers and patients, especially given the
complexities of the landscape of privacy laws for multiple care and
specialty settings. We stated in the Proposed Rule that we believe
health IT certified to these criteria would support multiple practice
settings and use cases.
Comments. We received many comments both in support and against
this proposal. In certain instances, commenters were supportive of our
aims but felt there were too many barriers and challenges near term,
including but not limited to the perceived cost involved with
successful segmentation in practice and indicated we should delay our
finalization of the proposal. Others felt immediate adoption of our
proposal in the final rule was critical for patient care and the secure
exchange of sensitive health information. Many commenters in favor of
our proposal provided examples of use cases which it could support,
such as helping to combat the opioid crisis by facilitating the secure
exchange of sensitive health information across health care settings
and including substance use disorder (SUD) information covered by 42
CFR part 2. We also received support of our proposal for the protection
of women's health--the commenter explained that segmenting at the
element level would protect individuals who have experienced intimate
partner violence, sexual assault, and other sensitive experiences.
Stakeholders shared with us that focusing certification on segmentation
to only the document level does not permit providers the flexibility to
address more granular segmentation needs. We received many comments on
this proposal in the context of the following topics: provider and
developer burden; readiness of the standard and C-CDA exchange;
information blocking and EHI; future multidisciplinary activities (such
as workgroups) and creating a vision for segmentation using health IT;
safety; privacy policy conformity; suggested use cases; cost; and
requests for specific clarifications. We describe these comments
further below.
Response. We thank commenters for their input. To address the
comments concerned about the cost and timing, at the current time,
these criteria are voluntary and not required under the definition of
CEHRT or to participate in any HHS program. For more information on the
costs for the adoption of these criteria, please see the Regulatory
Impact Analysis in section XIII. For the reasons noted above, in this
final rule, we have finalized our proposal to support a more granular
approach to privacy tagging data consent management for health
information exchange supported by the C-CDA exchange standard. We do
this not by removing and replacing the 2015 Edition DS4P criteria with
new Sec. 170.315(b)(12) and Sec. 170.315(b)(13), but by revising the
2015 Edition DS4P criteria, DS4P criteria DS4P-send (Sec.
170.315(b)(7)) and DS4P-receive (Sec. 170.315(b)(8)), to include the
full scope of the HL7 DS4P standard for
[[Page 25704]]
security tagging at the document, section and entry level with
modifications as described below.
Comments. We received many comments regarding the perceived burden
of segmentation on providers and developers including comments focused
on workflow challenges. One commenter indicated a lack of system and
explained that tagging is burdensome for implementers because it does
not describe how to determine what information is sensitive and should
be tagged. Another indicated that DS4P creates a permanent added burden
of extensive and costly manual data curation to redact each page to
meet overlapping Federal and State regulations. Commenters indicated
end users would be required to flag each individual data element, a
process that is time consuming and error prone. They further explained
that granular level privacy tagging has the risk of adding additional
data entry burden to provider workflows if users must tag each item
individually.
Response. We appreciate the thoughtful comments submitted on the
proposed criteria. Notably, with respect to the comments we received
that expressed concern about the DS4P standard due to the burden, our
analysis of the comments indicates that the concerns the commenters
express are more closely related to the complexity of the privacy law
landscape than to the specific functionality and standard in our
proposal. As noted above, at the current time, these criteria are
voluntary and not required under the definition of CEHRT or to
participate in any HHS program. The DS4P standard is a tool and
voluntary certification to these criteria is an initial step towards
enabling an interoperable health care system to use technical standards
to compute and persist security tags to permit access, use, or
disclosure of sensitive health information. The criteria do not specify
that a manual workflow is required to implement security tagging, and
we understand from examples of DS4P use in practice that solutions may
include the use of value sets to automate the tagging process. We
reiterate that these criteria are intended to apply standards to the
transmission of documents so that such security tags may be
interoperable. Though the updated criteria would support a more
granular approach to tagging the sensitive information, we recognize
that this will not solve the whole problem of how to manage data
segmentation for privacy and consent management. The recipient will
still receive and can view the information that is tagged--the
recipient will need to determine what they are going to do with that
information. Policies and procedures for what to do with the
information once it is received are outside the scope of these criteria
and this final rule. However, we emphasize that health care providers
already have processes and workflows to address their existing
compliance obligations for State and Federal privacy laws, which could
be made more efficient and cost effective through the use of health IT,
rather than relying on case-by-case manual redaction and subsequent
workarounds to transmit redacted documents. We believe this tool may be
one part of innovative solutions to support health IT enabled privacy
segmentation in care coordination workflows to significantly reduce the
burden of these manual processes currently in practice.
Comments. Several commenters indicated that enhanced segmentation
may unintentionally impact clinical care when providers are presented
with an incomplete picture of patient data. Commenters stated there
could be patient care risks involved with not sharing elements as users
of downstream systems may not realize that a single element is filtered
and act improperly, such as by prescribing a contraindicated medication
due to missing information.
Response. DS4P is a technical standard for C-CDA that helps health
care providers comply with existing, applicable laws. As such, health
care providers should already have processes and workflows in place to
address their existing compliance obligations. The DS4P standard does
not itself create incomplete records. Under existing law, patients
already have the right to prevent re-disclosure of certain types of
data by withholding consent to its disclosure or to place restrictions
on its re-disclosure. DS4P allows providers to electronically tag
(mark) data as sensitive and express re-disclosure restrictions and
other obligations in an electronic form. DS4P does not determine
whether a segmentation obligation exists legally or what that legal
obligation means to the recipient. Instead, DS4P allows for tagging and
exchange of health information that has already been determined to be
sensitive and in need of special protections under existing law.
Comments. We received comments in support of our proposal
indicating that, without data segmentation, other mandatory criteria,
such as the proposed ``EHI export'' criterion, would be difficult to
implement without risking disclosure of sensitive data or information
blocking. One commenter indicated that without this technical standard,
it would be difficult for stakeholders to know whether appropriate
consent has been obtained prior to releasing health information.
Further, the commenter indicated concern that without such
capabilities, hospitals and health systems could be accused of
information blocking because they cannot verify that a patient has
given consent for their EHI to be shared. They further commented that
if ONC does not finalize this criterion, then we should provide an
appropriate exception in the information blocking provisions so that an
entity is not accused of information blocking because they do not know
if another organization has obtained consent from patients. One
commenter stated ONC should propose a new information blocking
exception that specifically clarifies that a health IT developer's
choice to not certify to an optional standard cannot be a practice that
implicates information blocking.
Response. We thank commenters for their support of the DS4P
standard. While we understand commenters' concerns, we first reiterate
the DS4P capability enables sensitive health information to be
exchanged electronically with security tags in a standardized format.
It does not enable the full segmentation of a patient's record within
an EHR, which may be necessary when responding to a request for EHI.
Second, we have revised the Infeasibility Exception in the information
blocking section of this final rule to provide that an actor is not
required to fulfill a request for access, exchange, or use of EHI if
the actor cannot unambiguously segment the requested EHI from other
EHI: (1) Because of a patient's preference or because the EHI cannot be
made available by law; or (2) because the EHI is withheld in accordance
with the Harm Exception in Sec. 171.201 (Sec. 171.204(a)(2)). For
instance, an actor will be covered under this condition if the actor
could not fulfill a request to access, exchange, or use EHI because the
requested EHI could not be unambiguously segmented from patient records
created by federally assisted programs (i.e., Part 2 Programs) for the
treatment of substance use disorder (and covered by 42 CFR part 2) or
from records that the patient has expressed a preference not to
disclose. We refer readers to the Infeasibility Exception discussion in
section VIII.D.1.d of this final rule.
Comments. Many commenters noted a low level of adoption for these
standards and concerns related to readiness expressing that the
standard
[[Page 25705]]
utility is limited by lack of widespread developer implementation.
Several commenters encouraged ONC to defer adoption of the DS4P
criteria with a few commenters recommending that the optional 2015
Edition criterion should be maintained with document level tagging only
until practical implementations at scale have been demonstrated at this
level. One commenter suggested that organic adoption by end-user
providers will help spark innovation in this emerging standard while
expressing concern that C-CDA level data tagging for privacy is largely
untested in real world scenarios. Others encouraged ONC to provide
additional guidance on the adoption of the DS4P standards and
certification criteria and forgo the inclusion of this requirement
until additional real world testing is available. They also indicated
ONC should first conduct use test cases to demonstrate how this
functionality will be effectively used across a variety of
environments.
Response. We appreciate the comments on the proposed criteria. In
reference to the DS4P standard's maturity, we note that it is
considered a ``normative'' standard from the HL7 perspective--a status
which indicates the content has been enhanced and refined through trial
use. While we recognize that to date the standard has not been widely
adopted, the SAMHSA C2S application uses the standard to segment Part 2
information. Likewise, the U.S. Department of Veterans Affairs (VA) and
private companies across the country have used the DS4P standard to
support behavioral health and pediatric care models. In addition, as of
the fourth quarter of 2019, 34 individual Health IT Modules obtained
certification to one of or both of the prior 2015 Edition certification
criteria. Our intent for adopting the updates to these criteria is that
in the absence of adoption of consensus driven standards there is
increased risk that single-use-case, proprietary solutions will be
developed, which may increase fragmentation, provider burden, and cost
while limiting interoperability. Further, the purpose of adopting these
criteria is to encourage the use of interoperable standards, in this
case to use technical standards to compute and persist security tags
upon exchange of a summary of care document in an interoperable manner.
In addition, the certification criteria using the DS4P standard are
voluntary and therefore our intent is, as commenters noted, to support
organic adoption of technology certified to the criteria by providers
seeking to implement health IT solutions to replace burdensome manual
privacy workflows.
Comments. Several commenters called for the need to increase
conformity among Federal and State privacy provisions to achieve
successful implementation of granular tagging. They noted the
significant policy component involved with the successful
implementation of the DS4P standard in practice, and in certain
instances specifically noted support for HIPAA Privacy Rule and 42 CFR
part 2 harmonization. Several commenters identified specific areas for
technical development of IT supporting data segmentation for privacy
based on Federal and State privacy provisions. One commenter indicated
that ONC could map which clinical codes are associated with certain
health conditions that receive special privacy protections in addition
to the HIPAA Rules. Other commenters noted that mapping of privacy
policy to technical specifications is not a sufficient or adequate
approach given policy complexities. One commenter indicated a future
approach should focus on development of criteria that support a data
provenance driven method of sensitive data management as applicable
under privacy laws.
Response. As we have stated, the DS4P standard enables sensitive
health information to be exchanged electronically with security tags in
a standardized format and we encourage health IT developers to include
DS4P functionality and pursue certification of their health IT to these
criteria in order to help support their users' compliance with relevant
State and Federal privacy laws that protect sensitive health
information. We recognize that the current privacy law landscape is
complex. In light of the complexities of the privacy law landscape, we
believe that supporting a standard that allows for increased
granularity in security tagging of sensitive health information would
better allow for the interoperable exchange of this information to
support a wide range of privacy related use cases.
Comments. Many commenters offered an approach for next steps to
advance the standard. To advance adoption and implementation of the
standard, several commenters suggested that ONC work closely with
clinicians, privacy subject matter experts and interoperability experts
(notably the HL7 Privacy and Security workgroups) to develop a clear
vision for implementing enhanced data segmentation. Many commenters
specifically called for ONC to sponsor or lead a multidisciplinary
workgroup of stakeholders to develop recommendations for industry
adoption and implementation. One commenter in support of our proposal
suggested such workgroup focus on including whether additional
standards are needed, as well as data visualization of non-disclosed
data and its utilization in clinical decision support algorithms.
Several commenters cited existing work to help support potential new
multidisciplinary efforts indicating that one SDO has already
undertaken early work toward evolving DS4P implementation guidance via
the HL7 V2 to FHIR mapping project sponsored by the HL7 Orders Work
Group. One commenter, called for an ONC led public-private
collaborative effort to reduce data entry burden. One commenter
recommended that ONC stand up a multi-stakeholder workgroup to identify
and define policy needs and functional requirements to address patient
privacy and provider needs.
Response. We thank commenters for their recommendations. ONC
believes that data segmentation is an integral capability for
exchanging sensitive health data. ONC first studied policy
considerations regarding data segmentation in electronic health
information exchange in 2010 and informed ONC's launch of the DS4P
Standards and Interoperability Framework (S&I Framework) Initiative in
2011.\59\ The initiative focused on the development of a DS4P technical
specification that would allow highly sensitive health information to
flow more freely to authorized users while improving the ability of
users of health IT to meet their obligations under State and Federal
privacy rules. Recommendations from the initiative called for the use
of metadata security tags to demonstrate privacy and security
obligations associated with patient health information. It also advised
that patients and providers be able to share portions, or segments, of
records in order to maintain patient privacy. Pilot projects conducted
under the DS4P S&I Framework Initiative demonstrated ways to enable the
sharing of information that is protected by Federal and State laws,
including the substance use disorder treatment confidentiality
regulations, 42 CFR part 2. ONC's prior Federal Advisory Committee, the
HITPC, also focused on the health IT certification needed to enable
exchange of behavioral health data.\60\ Additionally, ONC led a project
on
[[Page 25706]]
patient choice where the exchange of sensitive data was addressed.\61\
ONC also led a project on the Behavioral Health Data Exchange (BHDE)
Consortium. The purpose of the project was to facilitate and address
barriers to the intra and interstate exchange of behavioral health
data.\62\ Currently, ONC's Leading Edge Acceleration Projects (LEAP) in
Health Information Technology (IT) program seeks to address well-
documented and fast emerging challenges inhibiting the development,
use, and/or advancement of well-designed, interoperable health IT. In
2019, one of the two LEAP awards issued by ONC focused on the
standardization and implementation of the Fast Healthcare
Interoperability Resources (FHIR[supreg]) Consent resource. Under this
project, a FHIR[supreg] Consent Implementation Guide (IG) and package
of open-source prototypes and content to assist partners in using the
FHIR[supreg] Consent Resource will become available.\63\
---------------------------------------------------------------------------
\59\ https://archive.healthit.gov/providers-professionals/ds4p-initiative.
\60\ https://www.healthit.gov/topic/Federal-advisory-committees/health-it-policy-committee-recommendations-national-coordinator.
\61\ https://www.healthit.gov/topic/patient-consent-electronic-health-information-exchange.
\62\ https://www.healthit.gov/topic/health-it-health-care-settings/behavioral-health-data-exchange-primary-care-and-behavioral.
\63\ https://www.healthit.gov/topic/leading-edge-acceleration-projects-leap-health-information-technology-health-it.
---------------------------------------------------------------------------
Also, ONC actively participates in HL7 International (HL7[supreg])
Workgroups and standards-development activities related to data
segmentation and consent management. It is critical for sensitive
health information to be included in health information exchange and we
are exploring opportunities for additional collaboration in the future.
Comments. One commenter recommended a companion guide be developed
to assist implementers with the standard. Another indicated ONC should
provide guidance to facilitate adoption of the DS4P standards and
certification criteria including dissemination of best practices to
help ensure that providers can most effectively implement the standards
and associated workflows. Another referred to a Query-Based Document
Exchange IG which has further guidance on the ability to assert access
policies and DS4P implementation considerations.
Response. The HL7 Version 3 Implementation Guide: Data Segmentation
for Privacy (DS4P), Release 1, Part 1: CDA R2 and Privacy Metadata
Reusable Content Profile, May 16, 2014 standard \64\ Sec.
170.205(o)(1) (HL7 DS4P standard) describes the technical means to
apply security tags to a health record and data may be tagged at the
document-level, the section-level, or individual data element-level.
The HL7 DS4P standard also provides a means to express obligations and
disclosure restrictions that may exist for the data. We appreciate
commenters input on additional guidance beyond these certification
requirements that may prove useful for developers. However, we
reiterate that in this rule we address only that guidance that is
required for those developers to voluntarily submit a Health IT Module
for certification to our criteria. Additional guidance on best
practices would be outside the scope of this rulemaking. However, as
noted above, we are committed to continuing to work with stakeholders,
including health IT developers and those involved in implementing
privacy policy in the health care industry, to work toward
interoperable solutions for privacy and consent management.
---------------------------------------------------------------------------
\64\ https://www.hl7.org/implement/standards/product_brief.cfm?product_id=354.
---------------------------------------------------------------------------
Comments. We received several comments seeking clarification on our
proposal to remove the current 2015 Edition ``DS4P-send'' (Sec.
170.315(b)(7)) and ``DS4P-receive'' (Sec. 170.315(b)(8)) certification
criteria and to replace these two criteria with three new 2015 Edition
DS4P certification criteria (two for C-CDA and one for a FHIR-based
API). As examples, one commenter sought clarification on whether our
proposal was for DS4P send and receive to become mandatory for the
revised 2015 Edition certification, or if they will remain voluntary
criteria. One commenter sought clarification on whether the data
protections apply to FHIR transmissions. Another indicated that they
believe the DS4P implementation guide only focuses on data segmentation
for C-CDA documents and not for HL7 FHIR and sought ONC clarification
regarding whether or not we intend to apply data segmentation labeling
to the HL7 FHIR resources in support of the USCDI as well. Another
commenter recommended that we require FHIR Release 4 version but
commented that a consistent approach of USCDI across HL7 CDA, C-CDA and
HL7 FHIR is not attainable at this time. One commenter stated a similar
need for clarification indicating that the standard for DS4P should be
HL7 standards for CDA Version 2 and FHIR security tagging and not be
the SAMHSA C2S stating that ONC should clarify this misunderstanding.
Another commenter sought clarification by ONC to indicate that the IG
is for CCDS and not FHIR, and also indicated confusion regarding STU4.
One commenter noted that the DS4P criteria are only effective for C-
CDA-based data exchange and recommended ONC add FHIR-based standard for
tagging of sensitive data. Several commenters expressed concern over
what they described as misalignment of this proposal with other ONC
policies explaining that neither USCDI nor ARCH, nor HL7 FHIR US Core
includes the FHIR Composition resource, which would be at the
equivalent level of granularity as a C-CDA document.
Response. We thank commenters for their input and we appreciate the
need for clarity requested by commenters. In the Proposed Rule (84 FR
7452), we proposed both to adopt an update to the HL7 DS4P standard for
the existing 2015 Edition certification criteria to support security
tagging of a C-CDA upon send and receive by removing DS4P-send (Sec.
170.315(b)(7)) and DS4P-receive (Sec. 170.315(b)(8)) and replacing
them with DS4P-send (Sec. 170.315(b)(12)) and DS4P-receive (Sec.
170.315(b)(13)) and to also adopt a new criterion to support API
exchange via consent management solutions using the FHIR standard. In
other words, these were two separate proposals, the first to support
security tags in summary of care documents and another to support
consent management for specific use cases that leverage a FHIR-based
API. As of this final rule, these criteria remain voluntary and not
required under the definition of CEHRT or to participate in any HHS
program. We proposed these several criteria in a single section of the
Proposed Rule because of the relationship between them as two potential
health IT tools that could be part of overarching solutions to manage
privacy and consent in health information exchange. However, as stated
earlier, we note that neither of these tools addresses the entirety of
the scope of data segmentation for privacy. To address the comment on
the DS4P implementation guide, we confirm that the HL7 DS4P standard in
Sec. 170.205(o)(1) describes the technical means to apply security
tags to a health record and data may be tagged at the document-level,
the section-level, or individual data element-level in the C-CDA and
not for FHIR. Currently, we do not intend to apply data segmentation
labeling to the HL7 FHIR resources in support of the USCDI because all
FHIR resources already include the capability to apply security tags to
the resource as metadata. We appreciate the recommendation to require
FHIR Release 4 for consent management but as discussed below, we have
decided not to finalize the proposal for consent management for APIs in
this final rule. For further
[[Page 25707]]
discussion of our FHIR-based consent management proposal, we direct
readers to subsection b below.
For the updates to the existing DS4P criteria, to support greater
clarity requested by public comment, rather than removing the existing
2015 Edition criteria and replacing them with new criteria as proposed,
we instead finalized a simple update to the existing criteria to note
the use of the full HL7 DS4P standard for tagging or applying security
tags at the document, section, and entry level.
We further note that these updated criteria remain voluntary, and
that we have finalized modifications in Sec. 170.315(b)(7)(ii) and
Sec. 170.315(b)(8)(i)(B) to our proposed effective date for this
change to allow for a longer glide path for health IT developers to
update Health IT Modules to the full standard to better support
clinical and administrative workflows. While certification to the
updated standards will be available after the effective date of this
final rule upon successful testing, we have finalized that document-
level tagging remains applicable for up to 24 months after the
publication date of this final rule. For certification and compliance
of Health IT Modules certified after 24 months after the publication
date of this final rule, only the full scope of the HL7 DS4P standard
is applicable. We have finalized this 24 month period for the update
for these criteria under the real world testing provisions in Sec.
170.405(b)(6) as follows:
Security tags. A health IT developer with health IT
certified to Sec. 170.315 (b)(7) and/or Sec. 170.315 (b)(8) prior to
June 30, 2020, must:
[cir] Update their certified health IT to be compliant with the
revised versions of the criteria adopted in Sec. 170.315(b)(7) and/or
the revised versions of the criteria adopted in Sec. 170.315(b)(8);
and
[cir] Provide its customers of the previously certified health IT
with certified health IT that meets paragraph (b)(6)(i) of this section
by May 2, 2022,
In addition, we have finalized these updated criteria with
modifications to the criteria names to better describe the function the
criteria support in interoperable health IT systems. The modifications
to the criteria are as follows:
Prior criterion: ``DS4P-send'' (Sec. 170.315(b)(7))
includes capabilities for creating a summary care record formatted to
the C-CDA standard and document-level tagging as restricted (and
subject to restrictions on re-disclosure) according to the DS4P
standard.
Revised criterion: ``Security tags--Summary of Care
(send)'' (Sec. 170.315(b)(7)) includes capabilities for creating a
summary of care record formatted to the C-CDA standard and that is
tagged as restricted and subject to restrictions on re-disclosure
according to the DS4P standard at the document, section, and entry
(data element) level, or at the document-level for the period until May
2, 2022.
Prior criterion: ``DS4P-receive'' (Sec. 170.315(b)(8))
includes capabilities for receiving a summary care record formatted to
the C-CDA standard and document-level tagged as restricted (and subject
to restrictions on re-disclosure) according to the DS4P standard.
Revised criterion: ``Security tags--Summary of Care
(receive)'' (Sec. 170.315(b)(8)) includes capabilities for receiving a
summary of care record formatted to the C-CDA standard and that is
tagged as restricted and subject to restrictions on re-disclosure
according to the DS4P standard at the document, section, and entry
(data element) level, or at the document-level for the period until May
2, 2022. We have finalized our proposal to include in the voluntary
``Security tags--Summary of Care (receive)'' (Sec. 170.315(b)(8))
criterion as a requirement that the Health IT Module has the capability
to preserve privacy markings to ensure fidelity to the tagging based on
consent and with respect to sharing and re-disclosure restrictions as
proposed.
b. Implementation With the Fast Healthcare Interoperability Resources
(FHIR[supreg]) Standard
In collaboration with ONC, SAMHSA developed the C2Sapplication to
address the specific privacy protections for patients with substance
use disorders whose treatment records are covered by the Federal
confidentiality regulation, 42 CFR part 2. C2S is an open source
application for data segmentation and consent management. It is
designed to integrate with existing FHIR systems. SAMHSA created a FHIR
implementation guide (the Consent2Share Consent Profile Design,
hereafter referred to as ``Consent Implementation Guide'') that
describes how the Consent2Share application and associated access
control solution (C2S platform) uses the FHIR Consent resource to
represent and persist patient consent for treatment, research, or
disclosure.\65\ The implementation guide provides instructions for
using the FHIR Consent resource to capture a record of a health care
consumer's privacy preferences.
---------------------------------------------------------------------------
\65\ The draft FHIR IG titled ``Consent2Share FHIR Profile
Design.docx'' can be accessed through the Community- Based Care and
Privacy (CBCP) HL7 workgroup, within the Package Name titled
``BHITS_FHIR_Consent_IG,'' at https://gforge.hl7.org/gf/project/cbcc/frs/.
---------------------------------------------------------------------------
In section VII.B.4 of this final rule, we discuss policies related
to the implementation of a standardized API to support the exchange of
health information between providers and patients and among members of
a care team. In the Proposed Rule, we anticipated that the proposed
2015 Edition ``standardized API for patient and population services''
certification criterion (Sec. 170.315(g)(10)) would result in a
proliferation of APIs that will enable a more flexible and less
burdensome approach to exchanging EHI. We stated our belief that the
health care industry could leverage this API infrastructure to share
segmented data in a secure and scalable manner. Therefore, we proposed
to adopt a 2015 Edition certification criterion ``consent management
for APIs'' in Sec. 170.315(g)(11) to support data segmentation and
consent management through an API in accordance with the Consent
Implementation Guide.
Comments. Overall, the majority of commenters were supportive of
the concept of consent management for APIs but many had concerns with
the proposed criteria, specifically the adoption of the Consent
Implementation Guide or the C2S platform as part of a certification
criterion. Many commenters raised concerns that the Consent
Implementation Guide has not been balloted as an HL7 standard and noted
that C2S does not support a consenter's signature or specification to
protect information content data requirements. A couple of commenters
stated that the Consent Implementation Guide is a new emerging standard
in pilot with feedback requested. Commenters also raised concern that
the IG has not gone through an SDO process. Another commenter raised
concern that SAMHSA no longer supports the C2S platform and the Consent
Implementation Guide and it now lacks a steward. A couple of commenters
suggested ONC defer the consent management criteria at least until an
API FHIR standard version is finalized and the Consent Implementation
Guide is revised to conform that to that version. One commenter
supported the adoption of FHIR v3-based Consent resource, but urged ONC
to also consider pediatric and geriatric use cases in its adoption.
Other commenters stated that their understanding was that tagging will
be
[[Page 25708]]
a feature of FHIR Release 4, but were unclear how the proposal to move
to FHIR Release 2 would work. One commenter questioned how if there are
no standards-based approaches for identifying what in the record is
sensitive, how one could feasibly implement privacy-tagging and consent
management via FHIR at the Resource level and that tagging at a more
granular level is too cumbersome and unrealistic. A number of
commenters stated that the standards were premature and if adopted
could have unintended negative effects. Commenters were not supportive
of having two versions of FHIR but instead recommended the use of FHIR
Release 4. Commenters recommended ONC focus on driving real-world
implementation experience before adopting the standards.
On the other hand, a few commenters supported our proposal, and
stated that the C2S platform and the Consent Implementation Guide is
mature and already supports granular level security tagging and data
segmentation and supports several API standards listed in the Proposed
Rule. One commenter expressed support broadly for the C2S platform
indicating that, though it was originally designed to satisfy 42 CFR
part 2 consent for the substance use disorder data, it supports the
other sensitive categories such as HIV and mental health. Several
commenters stated that the criteria should be required in the Base EHR
definition.
Many providers called for patient education and for ONC to work
with SAMHSA, OCR, and CMS. It was also suggested that ONC coordinate
with SAMHSA to establish a public-private project to advance the C2S
platform and the Consent Implementation Guide using an analogous
process to that of the Da Vinci Project with transparency and with no
membership fees. Finally, several commenters raised issues that are out
of scope for this rule including concerns specifically with the HIPAA
Rules or 42 CFR part 2 which are under the authority of OCR and SAMHSA
respectively.
Response. We appreciate the comments received and the insights into
real world implementing challenges of consent management. We agree that
there is continued work to be done to ballot and field test the C2S
platform and the Consent Implementation Guide and also agree with
commenters that identified this resource as having significant
potential to support consent management for specific use cases such as
42 CFR part 2, behavioral health, and pediatric care. We also note that
we had included a series of questions in our Proposed Rule related to
the alignment of FHIR releases and we appreciate comments received
related to these questions. We direct readers to section VII.B.4.c for
further discussion of our adoption in this rule the FHIR Release 4
standard. We note that the Consent Implementation Guide is designed in
FHIR Release 3 and that there is significant work to be done in
standards development before the IG would be feasible with FHIR Release
4. At this time, FHIR Release 4 version of FHIR consent resource is not
normative and can change from version to version and therefore further
development, review, balloting, and testing would be required for a
FHIR Release 4 based IG to be a viable consensus standard for adoption
in the Program. In consideration of comments, and the scope of the
additional work required for readiness of an IG that could be adopted
in our regulations, we have not finalized the proposed ``consent
management for APIs'' certification criterion in Sec. 170.315(g)(11).
We maintain, as stated above, that the C2S platform and the Consent
Implementation Guide may still serve as a template for implementation
of consent management workflows leveraging APIs and that it may be a
part of health IT solutions to facilitate health information exchange
of sensitive information. We will continue to monitor the development
of the Consent Implementation Guide and other FHIR resources to support
consent management and may consider including in a future rulemaking.
10. Auditable Events and Tamper-Resistance, Audit Reports, and Auditing
Actions on Health Information
Since adopting the Auditable events and tamper-resistance (Sec.
170.315(d)(2)), Audit Reports (Sec. 170.315(d)(3)), and Auditing
Actions on health information (Sec. 170.315(d)(10)) criteria in the
2015 Edition, there has been an update to ASTM E2147--1 standard and
has been replaced by a newer version. Given the older version has been
deprecated and based on comments received, we have updated these
criteria with the most up to date standard, ASTM E1247--18 in Sec.
170.210(h). We have also updated the requirements to align with the new
numbering sequence of the updated standard. In order to meet the
minimum requirements for capturing and auditing electronic health
information, we have specified, in Sec. 170.210(e)(1)(i), that the
data elements in sections 7.1.1 through 7.1.3 and 7.1.6, through 7.1.9
in ASTM E1247--18 are required. We believe that the updated standard
reinforces what we have previously required and maintained with
previous certification requirements and note that there is no
substantial change to the standard.
We further note that health IT developers must update Health IT
Modules to these updated standards referenced in these criteria within
24 months after the publication date of this final rule. We have added
as a Maintenance of Certification requirement for the real world
testing Condition of Certification requirement, that health IT
developers are required to provide the updated certified health IT to
all their customers with health IT previously certified to the
identified criteria no later than 24 months after the publication date
of the final rule. Developers would also need to factor these updates
into their next real world testing plan as discussed in section VII.B.5
of this final rule and in Sec. 170.405(b)(7).
C. Unchanged 2015 Edition Criteria--Promoting Interoperability Programs
Reference Alignment
In the FY 2019 IPPS/LTCH PPS proposed rule (83 FR 20516), CMS
proposed scoring and measurement policies to move beyond the three
stages of meaningful use to a new phase of EHR measurement with an
increased focus on interoperability and improving patient access to
health information. To reflect this focus, CMS changed the name of the
Medicare and Medicaid EHR Incentive Programs, to the Medicare and
Medicaid Promoting Interoperability (PI) Programs. To align with the
renaming of the EHR Incentive Programs, we proposed to remove
references to the EHR Incentive Programs and replace them with
``Promoting Interoperability Programs'' in the updated 2015 Edition
``automated numerator recording'' criterion in Sec. 170.315(g)(1) and
the ``automated measure calculation'' criterion in Sec. 170.315(g)(2).
Comments. We did not receive any comments on this proposal to
remove references to the EHR Incentive Programs and replace them with
``Promoting Interoperability Programs'' in the updated 2015 Edition
``automated numerator recording'' criterion in Sec. 170.315(g)(1) and
the ``automated measure calculation'' criterion in Sec. 170.315(g)(2).
Response. We have removed references to the EHR Incentive Programs
and replaced them with ``Promoting Interoperability Programs'' in the
2015 Edition ``automated numerator recording'' criterion in Sec.
170.315(g)(1) and the ``automated measure calculation'' criterion in
Sec. 170.315(g)(2).
[[Page 25709]]
V. Modifications to the ONC Health IT Certification Program
A. Corrections
1. Auditable Events and Tamper Resistance
We proposed to revise Sec. 170.550(h)(3) to require the End-User
Device Encryption criterion in Sec. 170.315(d)(7) as appropriate, and
exempt Health IT Modules from having to meet Sec. 170.315(d)(7) when
the certificate scope does not require Sec. 170.315(d)(7)
certification (see Sec. 170.315(d)(2)(i)(C)) (84 FR 7454). As noted in
the Proposed Rule (84 FR 7454), paragraph 170.315(d)(2)(i)(C) was not
applicable to the privacy and security testing and certification of a
Health IT Module required by Sec. 170.550(h)(3)(iii), (v), (vii), and
(viii), but we intended for it to also be exempted from the
aforementioned paragraphs. We, therefore, proposed to revise Sec.
170.550(h)(3)(iii), (v), (vii), and (viii) by removing references to
paragraph 170.315(d)(2)(i)(C).
Comments. One commenter expressed support of the proposals under
section V (``Modifications of the ONC Health IT Certification
Program'') of the Proposed Rule as a whole. However, we received no
comments specific to this proposal.
Response. We have finalized the revision as proposed. Certification
can proceed for the audit log process without the Health IT Module
demonstrating that it can record an encryption status in accordance
with Sec. 170.315(d)(2)(i)(C). Paragraph Sec. 170.315(d)(2)(i)(C) is
not applicable for the privacy and security testing and certification
of a Health IT Module required by Sec. 170.550(h)(3)(iii), (v), (vii),
and (viii). We had previously identified this error in guidance,\66\
and have now codified the correction to Sec. 170.550(h)(3)(iii), (v),
(vii), and (viii) in regulation.
---------------------------------------------------------------------------
\66\ https://www.healthit.gov/test-method/auditable-events-and-tamper-resistance.
---------------------------------------------------------------------------
2. Amendments
We proposed to revise Sec. 170.550(h) to remove the ``amendments''
criterion's application to certain non-applicable clinical criteria
including: ``Drug-drug, drug-allergy interaction checks for
computerized provider order entry (CPOE)'' in Sec. 170.315(a)(4);
``clinical decision support (CDS)'' in Sec. 170.315(a)(9); ``drug-
formulary and preferred drug list checks'' in Sec. 170.315(a)(10); and
``patient-specific education resources'' in Sec. 170.315(a)(13) (84 FR
7454). The ``amendments'' certification criterion Sec. 170.315(d)(4)
is not necessarily indicated for health IT capabilities that may not
have any patient data for which a request for an amendment would be
relevant.
Comments. One commenter expressed support of the proposals under
section V (``Modifications of the ONC Health IT Certification
Program'') of the Proposed Rule as a whole. However, we received no
comments specific to this proposal.
Response. We have finalized the proposal with modifications. Health
IT Modules presented for certification to these criteria do not have to
demonstrate the capabilities required by the revised 2015 Edition
``amendments'' certification criterion (Sec. 170.315(d)(4)), unless
the Health IT Module is presented for certification to another
criterion that requires certification to the 2015 Edition
``amendments'' criterion under the privacy and security (P&S)
certification framework. We note that, because we have not finalized
our proposal to remove the ``drug-formulary and preferred drug list
checks'' criterion in Sec. 170.315(a)(10) and the ``patient- specific
education'' criterion in Sec. 170.315(a)(13), but to only permit ONC-
ACBs to issue certificates for these criteria until January 1, 2022, we
have not removed references to these criteria from the exemption in
Sec. 170.550(h) at this time. This clarification has already been
incorporated into sub-regulatory guidance,\67\ and is now codified in
regulation.
---------------------------------------------------------------------------
\67\ https://www.healthit.gov/test-method/drug-drug-drug-allergy-interaction-checks-cpoe; https://www.healthit.gov/test-method/clinical-decision-support-cds; https://www.healthit.gov/test-method/drug-formulary-and-preferred-drug-list-checks; and https://www.healthit.gov/test-method/patient-specific-education-resources.
---------------------------------------------------------------------------
3. View, Download, and Transmit to 3rd Party
We proposed to remove Sec. 170.315(e)(1)(ii)(B), which includes a
cross-reference to Sec. 170.315(d)(2) indicating that a Health IT
Module may demonstrate compliance with active history log requirements
if it is also certified to Sec. 170.315(d)(2) (84 FR 7454).
Comments. One commenter expressed support of the proposals under
section V (``Modifications of the ONC Health IT Certification
Program'') of the Proposed Rule as a whole. However, we received no
comments specific to this proposal.
Response. We thank commenters for their support and have finalized
the proposal to remove Sec. 170.315(e)(1)(ii)(B), which includes a
cross-reference to Sec. 170.315(d)(2). As noted in the Proposed Rule
(84 FR 7454), this cross-reference indicates that a Health IT Module
may demonstrate compliance with activity history log requirements if it
is also certified to the 2015 Edition ``auditable events and tamper-
resistance'' certification criterion (Sec. 170.315(d)(2)). However, we
no longer require testing of activity history log when certifying for
Sec. 170.315(d)(2). Therefore, this cross-reference is no longer
applicable to meet certification requirements for the updated 2015
Edition ``view, download, and transmit to 3rd party'' certification
criterion (Sec. 170.315(e)(1)) activity history log requirements.
Consequently, we have finalized our proposal to remove Sec.
170.315(e)(1)(ii)(B).
4. Integrating Revised and New Certification Criteria Into the 2015
Edition Privacy and Security Certification Framework
We proposed to require the new certification criteria (Sec.
170.315(d)(12) and (d)(13)) to apply to all Sec. 170.315 certification
criteria (84 FR 7454). Therefore, given these and the other
modifications discussed above, we proposed to revise the P&S
Certification Framework as shown in Table 1 of the Proposed Rule (84 FR
7455), noting that the P&S Certification Framework when finalized could
differ depending on finalization of proposals in section III.B.4 of the
Proposed Rule (84 FR 7436 and 7437) to remove certain 2015 Edition
certification criteria.
Comments. One commenter expressed support of the proposals under
section V (``Modifications of the ONC Health IT Certification
Program'') of the Proposed Rule as a whole. However, we received no
comments specific to this proposal.
Response. We thank the commenter for their input regarding our
proposals under section V (``Modifications of the ONC Health IT
Certification Program'') of the Proposed Rule. We have adopted the
revisions as proposed with modifications. As noted in section IV.B.8.a,
we have also adopted both proposed privacy and security transparency
attestation criteria (Sec. 170.315(d)(12) and (d)(13)) with minor
modifications. We have applied Sec. 170.315(d)(12) and (d)(13) to all
certification criteria across the P&S Certification Framework. Table 2
shows the final updated P&S Certification Framework, which includes all
changes including the removal of certain 2015 Edition certification
criteria as finalized in section III.B.4 of this final rule. We updated
the P&S Certification Framework to reflect other changes made
throughout this final rule. The privacy and security certification
criteria applicable to a Health IT Module presented for certification
is based on the other capabilities included in the Health IT Module and
for which certification is sought (80 FR 62705). In this final rule, we
have determined that
[[Page 25710]]
Sec. 170.315(b)(10) and, consistent with the rationale provided in the
2015 Edition final rule, (g)(1) through (6) are exempt from the P&S
Certification Framework due to the capabilities included in these
criteria, which do not implicate privacy and security concerns (80 FR
62707). We have revised Sec. 170.550(h) of this final rule to reflect
these clarifications. We also corrected Table 2 to accurately reflect
the regulatory text at Sec. 170.315(a)(3), (a)(14), and (a)(15).
Sections 170.315(a)(3), (a)(14), and (a)(15), though included in the
regulatory text, were erroneously deleted in the Proposed 2015 Edition
Privacy and Security Certification Framework table and we corrected it
in Table 2.
Table 2--2015 Edition Privacy and Security Certification Framework
----------------------------------------------------------------------------------------------------------------
It will need to be certified to approach 1 or approach 2 for each of the
If the Health IT Module includes P&S certification criteria listed in the ``approach 1'' column
capabilities for certification listed -------------------------------------------------------------------------
under: Approach 1 Approach 2
----------------------------------------------------------------------------------------------------------------
Sec. 170.315(a)(1) through (3), (5), Sec. 170.315(d)(1) For each applicable P&S
(12), (14), and (15). (authentication, access control, certification criterion not
and authorization), (d)(2) certified using Approach 1, the
(auditable events and tamper health IT developer submits system
resistance), (d)(3) (audit documentation that is sufficiently
reports), (d)(4) (amendments), detailed to enable integration
(d)(5) (automatic log-off), (d)(6) such that the Health IT Module has
(emergency access), (d)(7) (end- implemented service interfaces for
user device encryption) (d)(12) each applicable P&S certification
(encrypt authentication criterion that enable the Health
credentials) (d)(13) (multi-factor IT Module to access external
authentication). services necessary to meet the
requirements of the P&S
certification criterion.
Sec. 170.315(a)(4), (9), (10), and Sec. 170.315(d)(1) through
(13). (d)(3), (d)(5) through (d)(7),
(d)(12), and (d)(13).
Sec. 170.315(b)(1) through (3) and Sec. 170.315(d)(1) through
(6) through (9). (d)(3), (d)(5) through (d)(8)
(integrity), (d)(12), and (d)(13).
Sec. 170.315(c)..................... Sec. 170.315(d)(1) through (d)(3)
and (d)(5), (d)(12), and (d)(13) *.
Sec. 170.315(e)(1).................. Sec. 170.315(d)(1) through
(d)(3), (d)(5), (d)(7), (d)(9)
(trusted connection), (d)(12), and
(d)(13).
Sec. 170.315(e)(2) and (3).......... Sec. 170.315(d)(1) through
(d)(3), (d)(5), (d)(9), (d)(12),
and (d)(13) *.
Sec. 170.315(f)..................... Sec. 170.315(d)(1) through
(d)(3), (d)(7), (d)(12), and
(d)(13).
Sec. 170.315(g)(7) through (g)(10).. Sec. 170.315(d)(1) and (d)(9);
(d)(2) or (d)(10) (auditing
actions on health information),
(d)(12), and (d)(13).
Sec. 170.315(h)..................... Sec. 170.315(d)(1) through
(d)(3), (d)(12), and (d)(13) *.
----------------------------------------------------------------------------------------------------------------
An ONC-ACB must ensure that a Health IT Module presented for certification to any of the certification criteria
that fall into each regulatory text ``first level paragraph'' category of Sec. 170.315 (e.g., Sec.
170.315(a)) identified in Table 2 is certified to either Approach 1 (technically demonstrate) or Approach 2
(system documentation).
In order to be issued a certification, a Health IT Module would only need to be tested once to each applicable
privacy and security criterion identified as part of Approach 1 or Approach 2 so long as the health IT
developer attests that such privacy and security capabilities apply to the full scope of capabilities included
in the requested certification, except for the certification of a Health IT Module to Sec. 170.315(e)(1)
``view, download, and transmit to 3rd party.'' For this criterion, a Health IT Module must be separately
tested to Sec. 170.315(d)(9) because of the specific capabilities for secure electronic transmission
included in the criterion.
* Sec. 170.315(d)(2)(i)(C) is not required if the scope of the Health IT Module does not include end-user
device encryption features.
B. Principles of Proper Conduct for ONC-ACBs
1. Records Retention
We proposed to revise the records retention requirement in Sec.
170.523(g) to include the ``life of the edition'' as well as three
years after the retirement of an edition related to the certification
of Complete EHRs and Health IT Modules (84 FR 7456). We also proposed
to clarify that HHS has the ability to access certification records for
the ``life of the edition,'' which begins with the codification of an
edition of certification criteria in the Code of Federal Regulations
through a minimum of three years from the effective date of the final
rule that removes the applicable edition from the Code of Federal
Regulations (CFR), not solely during the three-year period after
removal from the CFR (84 FR 7456).
Comments. Several commenters expressed support for ONC's proposal
to revise the records retention requirement. Another commenter
requested that ONC provide a separate posting or notice that lists the
dates specific to when the ``life of the edition'' starts and dates
specific to when the ``life of the edition'' and the minimum period of
three years from the effective date that removes the applicable edition
end.
Response. We thank commenters for their input and have finalized
this revision as proposed. Because the ``life of the edition'' begins
with the codification of an edition of certification criteria in the
CFR and ends on the effective date of the final rule that removes the
applicable edition from the CFR, the start and end dates for the ``life
of the edition'' are published in the Federal Register in the
rulemaking actions that finalize them. The period of three years beyond
the ``life of the edition'' begins on the effective date of the final
rule that removes the applicable edition from the CFR, thus the three-
year period after removal from the CFR continues through three full
calendar years following that date. For example, if the effective date
of a hypothetical final rule removing an edition from the CFR were July
1, 2025, then the three year period following the end of the life of
this hypothetical edition would be June 30, 2028. We anticipate
continuing to work with ONC-ACBs to provide guidance and information
resources as necessary or appropriate to promote successful adherence
to all Principles of Proper
[[Page 25711]]
Conduct (PoPC) applicable to their participation in the Program.
2. Conformance Methods for Certification Criteria
The PoPC in Sec. 170.523(h) specified that ONC-ACBs may only
certify health IT that has been tested by ONC-ATLs using tools and test
procedures approved by the National Coordinator. We proposed to revise
the PoPC in Sec. 170.523(h) in three ways (84 FR 7456).
First, we proposed to revise this PoPC to additionally permit ONC-
ACBs to certify Health IT Modules that the ONC-ACB has evaluated for
conformance with certification criteria without first passing through
an ONC-ATL. However, we proposed that such methods to determine
conformity must first be approved by the National Coordinator.
Second, we proposed to revise the PoPC to clarify that
certifications can only be issued to Health IT Modules and not Complete
EHRs. We proposed to remove the 2014 Edition from the CFR (see section
III.B.2 of this preamble) and Complete EHR certifications are no longer
available for certification to the 2015 Edition (80 FR 62608; 79 FR
54443). We also proposed to remove the provision that permits the use
of test results from National Voluntary Laboratory Accreditation
Program (NVLAP)-accredited testing laboratories under the Program
because the regulatory transition period from NVLAP-accredited testing
laboratories to ONC-ATLs has expired (81 FR 72447).
Third, we proposed to remove the provision that permits the
certification of health IT previously certified to an edition if the
certification criterion or criteria to which the Health IT Module(s)
was previously certified have not been revised and no new certification
criteria are applicable because the circumstances that this provision
seeks to address are no longer feasible with certification to the 2015
Edition.
Comments. One commenter sought clarification on whether the
proposal to remove references to Sec. 170.545, which includes the
ability to maintain Complete EHR certification, would impact Sec.
170.550(k), which requires ONC-ACBs to accept requests for a newer
version of a previously certified Health IT Module(s) to inherit the
certified status of the previously certified Health IT Module(s)
without requiring the newer version to be recertified. The commenter
strongly urged ONC to allow ONC-ACBs to grant inherited certification
status to updated versions of certified technology. Another commenter
expressed support for ONC's proposal to revise the PoPC to clarify that
certifications can only be issued to Health IT Modules and not Complete
EHRs. The commenter also expressed support for ONC's proposal to remove
the provision that permits the certification of health IT previously
certified to an edition if the certification criterion or criteria to
which the Health IT Module(s) was previously certified have not been
revised and no new certification criteria are applicable because the
circumstances that this provision seeks to address are no longer
feasible with certification to the 2015 Edition.
Response. We have finalized the proposal to revise the PoPC in
Sec. 170.523(h). As noted in the Proposed Rule, the ability to
maintain Complete EHR certification is only permitted with health IT
certified to the 2014 Edition certification criteria (84 FR 7435).
Because this concept was not continued in the 2015 Edition (84 FR
7456), we proposed revisions to clarify that Complete EHR
certifications are no longer available. We note that ONC-ACBs have
discretion, and processes in place, to evaluate updates made to
certified health IT and assess the need for additional testing. These
ONC-ACB processes allow for efficient certification of upgraded version
releases of previously certified health IT while ensuring its continued
conformity with certification criteria and standards to which the prior
version release of the same Module(s) had been certified. We have
finalized this proposal.
Comments. Multiple commenters expressed support for the use of
conformance methods approved by the National Coordinator. One commenter
noted that the opportunity would enable alternative testing methods and
less costly testing. Another commenter noted that this proposal would
reduce burden for EHR developers and for ONC-ATLs by leveraging
certification programs and alternative test methods and specifically
requested that ONC consider a specific proprietary certification
related to e-prescribing functionalities for potential approval. While
expressing appreciation for the flexibility offered by the proposed
revision, one commenter expressed concern about certifications based on
other ONC-approved conformance methods that are not specifically
designed to test against the ONC criteria and stressed the importance
of assessing conformance to technical standards before being deployed
to end users. Another commenter questioned whether the ONC-ACB would be
permitted to do all evaluation directly, thus eliminating the need for
ONC-ATLs entirely. Two commenters sought clarity from ONC as to what
metrics the National Coordinator will use to approve a conformance
method. These commenters also sought clarification on ONC's plan to
reduce the risk of developers seeking certification through fraudulent
means. The commenters cited the example of two developers who are
currently operating under corporate integrity agreements with the HHS
Office of the Inspector General due to court cases brought against them
in relation to conduct including, but not limited to, the process of
seeking certification.
Response. We thank commenters for their feedback. We have finalized
the proposal to revise the PoPC in Sec. 170.523(h) to permit a
certification decision to be based on an evaluation conducted by the
ONC-ACB for Health IT Modules' compliance with certification criteria
by use of conformity methods approved by the National Coordinator.
We note that all certification criteria will continue to have some
method of holding developers responsible for demonstrating conformity
whether through ONC-ATL testing, developer self-declaration, or some
other method assessed and approved by the National Coordinator. As
noted in the Proposed Rule (84 FR 7456), ONC acknowledges that there is
a broad spectrum of types of evidence of conformance, from laboratory
testing with an ONC-ATL to developer self-declaration. Some of these
types of evidence may be more appropriate than others in specific
circumstances. Historically, it has been proven that, in some
circumstances, the requirement for ONC-ATL testing has presented more
administrative burden on health IT developers than benefits for
assessing conformity. For example, under Sec. 170.315(a)(5)
demographics certification criteria require only documentation or a
visual inspection, and do not require testing by an ONC-ATL. We note
that industry advancements have presented opportunities for improved
efficiency for demonstrating conformity and this flexibility will allow
the Program to advance as the state of the art for demonstrating
conformance evolves. This flexibility addresses the current Program
construct limitation of ONC-ACB certification only being permissible
for health IT that has been tested by an ONC-ATL with ONC-approved test
procedures. In some instances, such as developer self-declaration,
there is no testing required and thus bypassing the ONC-ATL testing
step reduces burden and enables a more streamlined and
[[Page 25712]]
efficient process. By adopting this flexibility, we may approve
conformance methods that rely solely on ONC-ACB evaluation, and not
ONC-ATL testing, when appropriate.
We will follow the same process used for alternative test methods
(76 FR 1280) for the submission of non-governmental developed
conformance methods to the National Coordinator for approval. A person
or entity may submit a conformance method to the National Coordinator
to be considered for approval for use under the Program. The submission
should identify the developer of the conformance method; specify the
certification criterion or criteria that is/are addressed by the
conformance method; and explain how the conformance method would
evaluate a Health IT Module's or, if applicable, other type of health
IT's, compliance with the applicable certification criterion or
criteria. The submission should also provide information describing the
process used to develop the conformance method, including any
opportunity for the public to comment on the conformance method and the
degree to which public comments were considered. In determining whether
to approve a conformance method for purposes of the Program, the
National Coordinator will consider whether it is clearly traceable to a
certification criterion or criteria adopted by the Secretary; whether
it is sufficiently comprehensive (i.e., assesses all required
capabilities) for the assessment of Health IT Modules', or other type
of health IT's, conformance to the certification criterion or criteria
adopted by the Secretary; whether an appropriate public comment process
was used during the development of the conformance method; and any
other relevant factors. When the National Coordinator has approved a
conformance method for purposes of the Program, we will publish a
notice of availability in the Federal Register and identify the
approved conformance method on the ONC website.
3. ONC-ACBs To Accept Test Results From Any ONC-ATL in Good Standing
We proposed to add the PoPC for ONC-ACBs in Sec. 170.523(r) in
order to address business relationships between ONC-ACBs and ONC-ATLs
(84 FR 7456). To encourage market competition, we proposed to require
ONC-ACBs to accept test results from any ONC-ATL that is in good
standing under the Program and is compliant with its ISO/IEC 17025
accreditation requirements. However, if an ONC-ACB has concerns about
accepting test results from a certain ONC-ATL, the ONC-ACB would have
an opportunity to explain the potential issues to ONC and NVLAP, and on
a case-by-case basis, ONC could consider the facts and make the final
determination.
Comments. Multiple commenters expressed support for the proposed
requirement that ONC-ACBs must accept test results from any ONC-ATL in
good standing. One commenter expressed an opinion that this proposal
has value in ensuring the credibility of the Program. Another commenter
agreed that this proposal would encourage market competition and
provide more options to developers. One commenter recommended that ONC-
ATLs should also be required to provide their results to any ONC-ACB to
which the developer has chosen to present its health IT for
certification, stating that this consistency across ONC-ACBs and ONC-
ATLs would ensure market competition.
Response. We thank commenters for their input. We have finalized
the PoPC for ONC-ACBs in Sec. 170.523(r) as proposed. While an ONC-ATL
attempting to inappropriately restrict developers' choice of ONC-ACBs
to those favored by the ONC-ATL would not support appropriate
competition, we do not believe it would be practical to mandate direct
transmission of ONC-ATL results to any ONC-ACB designated by the
developer, in part because developers often do not initiate engagement
with an ONC-ACB until after they have received and had a chance to
review their ONC-ATL results. To date, we are not aware of substantial
evidence that the standard practice of NVLAP-accredited testing
laboratories providing test results to the client who engaged them to
test their Health IT Modules is not serving as a sufficient safeguard
against anti-competitive behavior on the part of ONC-ATLs in relation
to their client developers' selection of ONC-ACBs.
4. Mandatory Disclosures and Certifications
We proposed to revise the PoPC in Sec. 170.523(k) to remove Sec.
170.523(k)(1)(ii)(B) because certifications can only be issued to
Health IT Modules and not Complete EHRs (84 FR 7456). We also proposed
to revise Sec. 170.523(k)(1)(iii)(A) to broaden the section beyond the
Promoting Interoperability (PI) Programs. We proposed to revise the
section to include a detailed description of all known material
information concerning additional types of costs or fees that a user
may be required to pay to implement or use the Health IT Module's
capabilities, whether to meet provisions of HHS programs requiring the
use of certified health IT or to achieve any other use within the scope
of the health IT's certification.
We also proposed to remove the provision in Sec. 170.523(k)(3)
that requires a certification issued to a pre-coordinated, integrated
bundle of Health IT Modules to be treated the same as a certification
issued to a Complete EHR for the purposes of Sec. 170.523(k)(1),
except that the certification must also indicate each Health IT Module
that is included in the bundle (84 FR 7457).
We proposed to revise Sec. 170.523(k)(4) to clarify that a
certification issued to a Health IT Module based solely on the
applicable certification criteria adopted by the ONC Health IT
Certification Program must be separate and distinct from any other
certification(s) based on other criteria or requirements (84 FR 7457).
We also proposed changes related to transparency attestations and
disclosures of limitations in section III.B.5 of the Proposed Rule
preamble (84 FR 7437 and 7438). Additionally, we proposed other new
PoPC for ONC-ACBs as discussed in sections VII.B.5 (84 FR 7501) and
VII.D (84 FR 7506 and 7507) of the Proposed Rule preamble.
Comments. Multiple commenters expressed support for ONC's proposal
to include a detailed description of all known material information
concerning additional types of costs or fees that a user may be
required to pay to implement or use the Health IT Module's
capabilities--whether to meet provisions of HHS programs requiring the
use of certified health IT or to achieve any other use within the scope
of the health IT's certification. One commenter endorsed the
transparency that this proposal would provide, noting that it would
help providers budget for their health IT, but also expressed concern
that requiring developers to disclose how much they charge for a
particular functionality may be impractical due to variations across
contracts and over time, or potentially have unintended consequences on
market pricing. Multiple commenters expressed support for our proposal
to remove subsection Sec. 170.523(k)(1)(ii)(B). One commenter
expressed support for ONC's proposed revisions to Sec. 170.523(k)(4).
Another commenter was supportive of the proposal to remove the
provision in Sec. 170.523(k)(3).
Response. We thank commenters for their support. We have finalized
the proposals, in their entirety, as proposed. To clarify, the
finalized revision in Sec. 170.523(k) requires disclosure of a
detailed description of all known material information concerning
[[Page 25713]]
additional types of costs or fees a user may be required to incur or
pay to implement or use the Health IT Module's capabilities to achieve
any use within the scope of the health IT's certification. We emphasize
that (unless required elsewhere in CFR part 170) the requirement is for
a description of the types of costs or fees, not predicted amounts of
these costs or fees across the full array of probable implementation
circumstances or over time. Among other considerations, we note that
costs required to achieve some particular uses within the scope of some
certifications may be for third-party services outside the control of
the developer required to disclose the detailed description.
C. Principles of Proper Conduct for ONC-ATLs--Records Retention
We proposed to revise the records retention requirement in Sec.
170.524(f) to include the ``life of the edition'' as well as 3 years
after the retirement of an edition related to the testing of Health IT
Module(s) to an edition of certification criteria (84 FR 7457). The
circumstances are the same as in section V.B.1 of the Proposed Rule
preamble, as summarized above. Therefore, we proposed the same
revisions for ONC-ATLs as we did for ONC-ACBs. We did not receive any
comments specific to this proposed revision to the PoPC for ONC-ATLs.
In light of the absence of comments, we have finalized the revisions as
proposed.
VI. Health IT for the Care Continuum
Health IT should help promote and support patient care when and
where it is needed. This means health IT should help support patient
populations, specialized care, transitions of care, and practice
settings across the care continuum. In the Proposed Rule, we provided a
history of the many actions we have taken since the inception of the
ONC Health IT Certification Program through the Proposed Rule (84 FR
7457). As stated in the Proposed Rule, section 4001(b)(i) of the Cures
Act instructs the National Coordinator to encourage, keep, or
recognize, through existing authorities, the voluntary certification of
health IT under the Program for use in medical specialties and sites of
service for which no such technology is available or where more
technological advancement or integration is needed. This provision of
the Cures Act closely aligns with our ongoing collaborative efforts
with both Federal partners and stakeholders within the health care and
health IT community to encourage and support the advancement of health
IT for a wide range of clinical settings. These initiatives have
included projects related to clinical priorities beyond those
specifically included in the EHR Incentive Programs (now called the
Promoting Interoperability Programs) including efforts in public
health, behavioral health, and long-term and post-acute care. We noted
in the Proposed Rule that these initiatives often include the
development of non-regulatory informational resources to support the
specific implementation goal and align with the technical
specifications already available in the Program for certification. To
advance these efforts, we also explained in the Proposed Rule that we
generally consider a range of factors including: Stakeholder input and
identification of clinical needs and clinical priorities, the evolution
and adoption of health IT across the care continuum, the costs and
benefits associated with any policy or implementation strategy related
to care settings and sites of service, and potential regulatory burden
and compliance timelines. Our goal was then and is now to support the
advancement of interoperable health IT and to promote health IT
functionality in care and practice settings across the care continuum
(see 80 FR 62604). As stated in the Proposed Rule (84 FR 7458),
generally, our approach can be summarized in three parts:
First, we analyze existing certification criteria to
identify how such criteria may be applicable for medical specialties
and sites of service.
Second, we focus on the real-time evaluation of existing
and emerging standards to determine applicability to medical
specialties and sites of service as well as to the broader care
continuum, including the evaluation of such standards for inclusion in
the ONC Interoperability Standards Advisory (ISA).\68\
---------------------------------------------------------------------------
\68\ https://www.healthit.gov/isa/.
---------------------------------------------------------------------------
Third, we may work in collaboration with stakeholders to
support the development of informational resources for medical
specialties and sites of service for which we identify a need to
advance the effective implementation of certified health IT.
We continue to believe this approach is economical, flexible, and
responsive for both health care providers and the health IT industry.
It is also in alignment with the provisions of section 4001(a) in the
Cures Act related to burden reduction and promoting interoperability.
We are committed to continuing to work with stakeholders to promote the
adoption of health IT to support medical specialties and sites of
service and to help ensure that providers have the tools they need
(such as access to essential health information across care settings)
to support patients at the point of care.
A. Health IT for Pediatric Setting
Section 4001(b)(iii) of the Cures Act--``Health information
technology for pediatrics'' requires:
First, that the Secretary, in consultation with relevant
stakeholders, shall make recommendations for the voluntary
certification of health IT for use by pediatric health providers to
support the health care of children, and
Second, that the Secretary shall adopt certification
criteria to support the voluntary certification of health IT for use by
pediatric health providers to support the health care of children.
In the Proposed Rule (84 FR 7458), we described our approach to
stakeholder engagement, the analysis used to develop the
recommendations, the specific 2015 Edition certification criteria that
support each recommendation, and the voluntary certification of health
IT for use by pediatric health providers to support the health care of
children.
Comments. We received several comments requesting further
clarification on whether the pediatric health IT recommendations will
be adopted as an independent certification program and/or certification
criteria designated specifically for pediatric care. One commenter
recommended that pediatric provisions should be formalized over time
within what they refer to as the current pediatric program and not as a
separate program, and that this future aligns with the 2015 Children's
EHR Format. One commenter also sought clarification as whether ONC
intends for other government agencies/programs such as CHIP, to develop
conditions of participation or financial incentives around the adoption
of certification criteria identified in this rulemaking. We also
received several comments stating that since current EHRs have
pediatric capabilities, there is no need to specify requirements in
regulation, and that there is no value in having EHRs certified as
``pediatric-friendly,'' only increased costs. We also received several
comments stating that our approach reflects an attempt to retrofit the
needs of pediatric patients by using adult requirements.
Response. We thank commenters for their feedback. The comments we
received suggests a need for greater clarity on our approach. We
therefore reiterate that we did not propose to adopt care- or practice-
specific certification tracks, or additional
[[Page 25714]]
voluntary program(s), in parallel to the existing voluntary ONC Health
IT Certification Program. In the Proposed Rule, we reiterated our
statements from the 2015 Edition final rule, which explained that we
did not intend to develop and issue separate regulatory certification
``paths'' or ``tracks'' for particular care or practice settings (e.g.,
a ``long-term and post-acute care (LTPAC) certification'') because it
would be difficult to independently construct such ``paths'' or
``tracks'' in a manner that would align with other relevant programs
and specific stakeholder needs. We further stated that stakeholders had
indicated that separate certification pathways could have unintended
consequences related to increasing burden on health care providers and
health IT developers. We also stated that we would welcome the
opportunity to work with HHS agencies, other agencies, and provider
associations in identifying the appropriate functionality and
certification criteria in the Program to support their stakeholders (80
FR 62704). In response to the comments regarding our approach to
implement section 4001(b) of the Cures Act, we clarify that the 2015
Edition certification criteria identified for the voluntary
certification of health IT for use by pediatric health providers are
agnostic to the age of the patient (with the exception of the pediatric
vital signs in the USCDI). Therefore, we believe our approach to
fulfilling the Cures Act requirement for pediatric health care
providers and settings, which involves identifying existing, new, or
revised 2015 Edition criteria--as applicable to an identified clinical
or interoperability priority--is appropriate across patient
populations. We also note that our authority is limited to implementing
the described requirements of the Cures Act related to pediatric
settings. We cannot speak for the actions of other Federal agencies,
but would note once again that we have taken a limited regulatory
approach to implementing the pediatric provisions of the Cures Act.
Comments. We received multiple comments requesting clarification on
the intended use and functionality of the Certified Health IT Products
List (CHPL) for pediatric certification, such as guidance on navigating
the CHPL to identify relevant products based on pediatric care
settings.
Response. We thank stakeholders for their comments on the CHPL. We
do not intend to have a separate tag functionality on the CHPL that
identifies a product specifically for pediatric care. We did not
propose, and do not intend, for there to be a separate certification
pathway or a new ONC certification designation called pediatric
certification. However, we recognize that beyond certification and
testing there are certain implementation needs that are important for
pediatric care and services. We agree with the overwhelming prior
feedback from stakeholders stating that they should not have to
purchase separate products that contain universally applicable
functionality, such as the ``API functionality'' certification
criteria. We are exploring options for non-regulatory informational
resources on effective implementation of health IT for use by pediatric
health providers to expand the availability of health IT products
supporting the care of children.
Comments. We received comments regarding how the approach for
voluntary certification of health IT for use by pediatric health
providers might be applicable to other medical specialties and use
cases. One commenter noted that the pediatric experience is scalable
and should be extended to other disciplines. Another commenter sought
clarification if this model could be used for broad applicability to
multiple medical specialties such as pathologists.
Response. We thank these commenters for identifying the
applicability of our approach to pediatrics to other medical
specialties. We confirm that our approach for advancing health IT can
be used for other use cases and medical specialties, and welcome the
opportunity to engage with stakeholders representing a wide range of
medical specialties or sites of service to provide insight into this
process and to inform stakeholder-led efforts to improve clinically-
relevant health IT implementation across specialties and settings of
care.
1. Background and Stakeholder Convening
Over the past ten years, a number of initiatives have focused on
the availability and use of effective health IT tools and resources for
pediatric care. These have included a number of public-private
partnerships including efforts between HHS, State agencies, and health
systems for innovative projects that range from care coordination
enterprise solutions to immunization information systems and to point
of care solutions for specialty needs. In order to learn from and build
upon these efforts, ONC has engaged with stakeholders in both the
public and private sector including other Federal, State and local
government partners, health care providers engaged in the care of
children, standards developing organizations, charitable foundations
engaged in children's health care research, and health IT developers
supporting pediatric care settings. For example, significant work has
been done by the Agency for Healthcare Research and Quality (AHRQ),
CMS, the Health Resources and Services Administration (HRSA), and
organizations around the Children's EHR Format (Children's Format),
which is critical to any discussion of the pediatric health IT
landscape.\69\
---------------------------------------------------------------------------
\69\ Agency for Health Care Information and Technology. Health
Information Technology. http://healthit.ahrq.gov/health-it-tools-and-resources/childrens-electronic-health-record-ehr-format.
Accessed September, 2017.
---------------------------------------------------------------------------
The Children's Format was authorized by the 2009 Children's Health
Insurance Program Reauthorization Act (CHIPRA) \70\ and developed by
AHRQ in close collaboration with CMS. It was developed to bridge the
gap between the functionality present in most EHRs currently available
and the functionality that could optimally support the care of
children. Specifically, the Children's Format provides information to
EHR system developers and others about critical functionality and other
requirements that are helpful to include in an EHR system to address
health care needs specific to the care of children. The final version
of the Children's Format, released in 2015, consists of 47 high
priority functional requirements in 19 topic areas that focus on
improvements that would better support the safety and quality of care
delivered to children. The Children's Format was intended as a starting
point for developers, users, and purchasers for informing an approach
for pediatric voluntary certification. We refer to the Voluntary
Edition proposed rule for a description of our prior discussion around
the Children's Format (79 FR 10930).
---------------------------------------------------------------------------
\70\ Pub. L. 111-3, section 401 https://healthit.ahrq.gov/sites/default/files/docs/citation/children-ehr-format-enhancement-final-recommendation-report-abridged.pdf.
---------------------------------------------------------------------------
In the summer of 2017, the American Academy of Pediatrics (AAP)
reviewed the 2015 Children's Format using a robust analytical process
and engagement with their members. The result was a prioritized list of
eight clinical priorities to support pediatric health care (``Priority
List''). In October 2017, we held a technical discussion with
stakeholders titled ``Health IT for Pediatrics'' with the specific
purpose of obtaining input from an array of stakeholders in an effort
to draw correlations between the pediatric providers' clinical
priorities identified in the Priority List with the detailed
[[Page 25715]]
technical requirements outlined in the Children's Format and the
capabilities and standards that could be included in certified health
IT. Through this collaborative approach, the meeting participants
identified a set of priority needs for health IT to support pediatric
care based upon those identified by the Priority List and the primary
correlation to the Children's Format.
2. Recommendations for the Voluntary Certification of Health IT for Use
in Pediatric Care
To support the first part of section 4001(b) of the Cures Act, we
considered the historical efforts on the Children's Format, the input
from stakeholders, and our own technical analysis and review of health
IT capabilities and standards to develop a set of recommendations for
voluntary certification of health information technology for use by
pediatric health providers to support the health care of children.
These include eight recommendations related to the Priority List:
Recommendation 1: Use biometric-specific norms for growth
curves and support growth charts for children
Recommendation 2: Compute weight-based drug dosage
Recommendation 3: Ability to document all guardians and
caregivers
Recommendation 4: Segmented access to information
Recommendation 5: Synchronize immunization histories with
registries
Recommendation 6: Age- and weight- specific single-dose
range checking
Recommendation 7: Transferrable access authority
Recommendation 8: Associate maternal health information
and demographics with newborn
We also developed two additional recommendations beyond the
Priority List, which relate to other items within the Children's Format
that are considered important to pediatric stakeholders. These
additional recommendations, which may be supported by certified health
IT, are as follows:
Recommendation 9: Track incomplete preventative care
opportunities
Recommendation 10: Flag special health care needs
In order to implement the second part of section 4001(b) of the
Cures Act for the adoption of certification criteria to support the
voluntary certification of health IT for use by pediatric health care
providers, we identified both the 2015 Edition certification criteria
and the new or revised certification criteria proposed in the Proposed
Rule that support the 10 recommendations for the voluntary
certification of health IT for use by pediatric health providers to
support the health care of children. In the Proposed Rule (84 FR 7459),
we directed readers to the appendix of the Proposed Rule for a set of
technical worksheets, which include a crosswalk of the various criteria
specifically associated with each recommendation. These worksheets
outlined the following information:
The alignment of each recommendation to the primary
Children's Format \71\ item identified by stakeholders
---------------------------------------------------------------------------
\71\ http://healthit.ahrq.gov/health-it-tools-and-resources/childrens-electronic-health-record-ehr-format.
---------------------------------------------------------------------------
The alignment of each recommendation to the 2015 Edition
certification criteria and the new or revised criteria described in the
Proposed Rule
Supplemental items from the Children's Format for each
recommendation and the related 2015 Edition certification criteria
We also sought comment on the following:
1. Relevant gaps, barriers, safety concerns, and resources
(including available best practices, activities, and tools) that may
impact or support feasibility of the recommendation in practice.
2. Effective use of health IT itself in support of each
recommendation as it relates to provider training, establishing
workflows, and other related safety and usability considerations.
3. If any of the 10 recommendations should not be included in ONC's
final recommendations for voluntary certification of health IT for use
by pediatric health providers to support the health care of children.
4. Any certification criteria from the Program that is identified
for the 10 recommendations that should not be included to support the
specific recommendation.
Comments. We received many comments asking for detailed guidance
and/or implementation specifications post final rulemaking, with one
commenter noting that the majority of recommendations require
additional capabilities beyond the scope of any aligned existing or
proposed certification criteria. We also received many comments
providing implementation recommendations specific to the 10 ONC
recommendations for the voluntary certification of health IT for use by
pediatric health providers such as adding in developmental activity
milestones, including what versions of growth charts should be
supported, and including listings to clearly identify medical home
providers. Several commenters also referenced concerns regarding the
feasibility of implementing the content included as part of the
pediatric health IT technical worksheet crosswalk analysis included in
the Proposed Rule appendix for Recommendation 5 ``Synchronize
immunization histories with registries.'' In this regard, several
commenters noted that FHIR is not currently consistent with CDC/AIRA
standards or practices for immunization data submission or query/
response, and that public health is not currently funded to provide
this capability from IIS.
Response. We thank commenters for their useful input regarding the
technical worksheets in the appendix we included for the Proposed Rule.
As we stated in the Proposed Rule, these comments, and the detailed
insights received through stakeholder outreach, will inform the future
development of a non-binding informational guide or informational
resource to provide useful information for health IT developers and
pediatric care providers seeking to successfully implement these health
IT solutions in a clinical setting. To facilitate adoption of the ten
recommendations, we are developing a Pediatric Health IT Developer
Informational Resource and a Pediatric Health IT Provider Informational
Resource to be available for respective use in 2020. As such, we
appreciate the comments we received specific to implementation
recommendations and will take them into account in the support of the
creation of non-regulatory informational resources for health IT
developers and other stakeholders. We plan to continue working with
stakeholders as we further develop and consider technical and
implementation recommendations we have received through solicited
public comments, the Health Information Technology Advisory Committee
(HITAC), and other engagements. We also direct readers to our
``pediatrics health IT'' web page (www.healthIT.gov/pediatrics) for
information on future work pertaining to health IT for pediatric care.
Comments. We received several comments suggesting the use of
pediatric-focused clinicians and settings to test EHR systems as part
of these provisions, specifically recommending that we should require
EHR developers to use pediatric-focused scenarios and mock pediatric
patients when testing functionality, as well as requiring the
[[Page 25716]]
inclusion of pediatric clinicians as part of end-user testing.
Response. We thank commenters for their input. We agree that it
would be beneficial for health IT developers to include pediatric-
focused testing of their health IT especially with regards to ensuring
patient safety. We note that we have established requirements for real
world testing that requires health IT developers to real world test
their health IT for the types of setting(s) in which it is intended for
use (we refer readers to section VII.B.5 for more information on real
world testing Condition and Maintenance of Certification requirements).
a. 2015 Edition Certification Criteria
In order to implement the second part of section 4001(b) of the
Cures Act to adopt certification criteria to support the voluntary
certification of health IT for use by pediatric health providers to
support the health care of children, we identified the following
already adopted 2015 Edition certification criteria in the Proposed
Rule that support the recommendations. The already adopted 2015 Edition
criteria are as follows:
``API functionality'' criteria (Sec. 170.315(g)(7)-
(g)(9)) which address many of the challenges currently faced by
patients and by caregivers such as parents or guardians accessing
child's health information, including the ``multiple portal'' problem,
by potentially allowing individuals to aggregate health information
from multiple sources in a web or mobile application of their choice.
``Care plan'' criterion (Sec. 170.315(b)(9)) which
supports pediatric care by facilitating the documentation of electronic
health information in a structured format to improve care coordination
(80 FR 62648 and 62649).
``Clinical decision support'' (CDS) criterion (Sec.
170.315(a)(9)) which supports pediatric care by enabling interventions
based on the capture of biometric data.
``Common Clinical Data Set'' (Sec. 170.315(b)(4) and
Sec. 170.315(b)(5)) which includes optional pediatric vital sign data
elements including as optional the reference range/growth curve for
three pediatric vital signs--BMI percent per LOINC identifiers for age
per sex, weight per length/sex, and head occipital-frontal
circumference for children less than three years of age.
``Data segmentation for privacy'' send criterion and
receive criterion (Sec. 170.315(b)(7) and Sec. 170.315(b)(8)) which
provides the ability to: Create a summary record that is tagged at the
document level as restricted and subject to re-disclosure; receive a
summary record that is document-level tagged as restricted; separate
the document-level tagged document from other documents received; and
view the restricted document without having to incorporate any of the
data from the document.
``Demographics'' criterion (Sec. 170.315(a)(5)) which
supports pediatric care through the capture of values and value sets
relevant for the pediatric health care setting as well as allowing for
improved patient matching which is a key challenge for pediatric care.
``Electronic Prescribing'' criterion (Sec. 170.315(b)(3))
which includes an optional Structured and Codified Sig Format, which
has the capability to exchange weight-based dosing calculations within
the NCPDP SCRIPT 10.6 standard and limits the ability to prescribe all
oral, liquid medications in only metric standard units of mL (i.e., not
cc) important for enabling safe prescribing practices for children.
``Family health history'' criterion (Sec. 170.315(a)(12))
which supports pediatric care because it leverages concepts or
expressions for familial conditions, which are especially clinically
relevant when caring for children.
``Patient health information capture'' criterion (Sec.
170.315(e)(3)) which supports providers' ability to accept health
information from a patient or authorized representative. This criterion
could support pediatric care through documentation of decision-making
authority of a patient representative.
``Social, psychological, and behavioral data'' criterion
(Sec. 170.315(a)(15)) which supports integration of behavioral health
data into a child's record across the care continuum by enabling a user
to record, change, and access a patient's social, psychological, and
behavioral data based using SNOMED CT[supreg] and LOINC[supreg] codes.
``Transitions of care'' criterion (Sec. 170.315(b)(1))
which supports structured transition of care summaries and referral
summaries that help ensure the coordination and continuity of health
care as children transfer between different clinicians at different
health care organizations or different levels of care within the same
health care organization.
``Transmission to immunization registries'' criterion
(Sec. 170.315(f)(1)) which supports the safe and effective provision
of child health care through immunizations and registry linkages. This
criterion also provides the ability to request, access, and display the
evaluated immunization history and forecast from an immunization
registry for a patient. Immunization forecasting recommendations allow
for providers to access the most complete and up-to-date information on
a patient's immunization history to inform discussions about what
vaccines a patient may need based on nationally recommended
immunization recommendations (80 FR 62662 through 62664).
``View, download, and transmit to 3rd party'' (VDT)
criterion (Sec. 170.315(e)(1)) which supports transferrable access
authority for the pediatric health care setting and provides the
ability for patients (and their authorized representatives) \72\ to
view, download, and transmit their health information to a 3rd party.
---------------------------------------------------------------------------
\72\ The VDT criterion includes a ``patient-authorized
representative'' concept that aligns with the use of the term under
the EHR Incentive Program. A ``patient-authorized representative''
is defined as any individual to whom the patient has granted access
to their health information (see also 77 FR 13720). However, consent
is not needed for minors, for whom existing local, state, or Federal
law grants their parents or guardians access (see also 77 FR 13720).
---------------------------------------------------------------------------
We noted in the Proposed Rule (84 FR 7460) that some of these
criteria may be updated based on proposals contained in the Proposed
Rule (see further discussion below on new or revised certification
criteria); and stated that we continue to believe that prior to any
such updates, technology that is currently available and certified to
these 2015 Edition criteria can make a significant impact in supporting
providers engaged in the health care of children. We invited readers to
use the technical worksheets in the appendix of the Proposed Rule to
inform their public comment on the recommendations, the inclusion of
specific items from the Children's Format, and the identified 2015
Edition certification criteria as they relate specifically to use cases
for pediatric care and sites of service.
b. New or Revised Certification Criteria
In order to implement the second part of section 4001(b)(iii) of
the Cures Act to adopt certification criteria to support the voluntary
certification of health information technology for use by pediatric
health providers to support the health care of children, we also
identified new or revised 2015 Edition certification criteria (and
standards) in the Proposed Rule (84 FR 7460) that support the
recommendations. These proposed criteria and standards include:
New API criterion (Sec. 170.315(g)(10)) which would serve
to implement the Cures Act requirement to permit health information to
be accessed, exchanged,
[[Page 25717]]
and used from APIs without special effort.
New ``DS4P'' criteria (two for C-CDA ((Sec.
170.315(b)(12)) and (Sec. 170.315(b)(13)) and one for FHIR (Sec.
170.315(g)(11))) that would support a more granular approach to privacy
tagging data for health information exchange supported by either the C-
CDA or FHIR-based exchange standards.
New electronic prescribing certification criterion (Sec.
170.315(b)(11)), which would support improved patient safety and
prescription accuracy, workflow efficiencies, and increased
configurability of systems including functionality that could support
pediatric medication management.
USCDI (Sec. 170.213) and USCDI-based criteria which
enables the inclusion of pediatric vital sign data elements, including
the reference range/scale or growth curve for BMI percentile per age
and sex, weight for age per length and sex, and head occipital-frontal
circumference. Each of the new or revised certification criteria and
standards are further described in other sections of this final rule,
including all final actions related to the criteria (some of which are
described below in the response to comments).
Comments. A majority of comments received supported our
recommendations for the voluntary certification of health IT for use by
pediatric health providers to support the health care of children along
with the alignment with the Children's Format and 2015 Edition
certification criteria. Several commenters suggested that the 10
recommendations should only be the first step and encouraged future
development of additional recommendations using the Children's Format.
Commenters were also pleased with the 10 recommendations selected by
ONC from the Children's Format stating that they represent a strong,
positive step forward for improving EHRs used in the care of children.
Many commenters stated that they support the continued alignment with
the 2015 Edition recommendations.
Response. We thank commenters for their support and feedback. As
such, we have maintained the 10 recommendations for the voluntary
certification of health IT for use by pediatric health providers to
support the health care of children. We have finalized in this final
rule the majority of the aligned proposed new 2015 Edition
certification criteria that support the voluntary certification of
health IT for use by pediatric health providers, with the exception of
the proposed criterion for ``consent management'' in Sec.
170.315(g)(11) since we did not finalize our proposal for the criterion
in this final rule. The functionality of the proposed new ``DS4P''
criteria have been incorporated into the already adopted 2015 Edition
DS4P criteria DS4P-send (Sec. 170.315(b)(7)) and DS4P-receive (Sec.
170.315(b)(8)) now referred to as ``Security tags--Summary of Care-
send'' and ``Security tags--Summary of Care--receive,'' respectively.
The functionality of the proposed new e-Rx criterion was also
incorporated in the already adopted e-Rx criterion (Sec.
170.315(b)(3)). Last, we have removed the ``Common Clinical Data Set''
(Sec. 170.315(b)(4) and Sec. 170.315(b)(5)) from the 2015 Edition in
this final rule.
We note that we are aware that the NCPDP SCRIPT Standard Version
2017071 Implementation Guide contains a number of requirements intended
to improve accurate dosing and pediatric patient safety. One such
requirement is the inclusion of the most recent patient height and
weight in the Observation Segment on all new and renewal prescriptions
sent from the prescriber to the pharmacy, along with the date
associated with these measures, for all patients 18 years old and
younger. We are also aware of the challenges that such a requirement
may pose on specific providers and under certain circumstances where
height and/or weight is not required or applicable for dosing of the
product. We believe additional work must be done on refining this
requirement, and will continue to monitor standards and industry
advancements before proposing such a requirement. At this time, we
recommend vital signs to be included in all electronic prescriptions
for all patient populations when available and where applicable.
The 10 recommendations and the aligned 2015 Edition certification
criteria support the health IT needs of pediatric care providers. We
believe further support can be provided through non-regulatory
informational resources. These resources can help inform technical and
implementation specifications for health IT developers and products for
use by pediatric health providers to support the health care of
children. We also agree with commenters that the 10 recommendations are
a first step and welcome input and collaboration from the health IT
industry and health care providers to continue efforts to develop and
build a health IT infrastructure supporting pediatric care and other
specialty care and sites of service across the continuum.
B. Health IT and Opioid Use Disorder Prevention and Treatment--Request
for Information
We identified a need to explore ways to advance health IT across
the care continuum to support efforts to fight the opioid epidemic. For
that purpose, in the Proposed Rule, we included a request for
information (RFI) related to health IT and opioid use disorder
prevention and treatment (84 FR 7461 through 7465). We received over
100 comments in responses to this RFI, which included recommendations
from the HITAC. We appreciate the feedback and recommendations provided
by commenters and the HITAC taskforce, respectively. We plan to share
this feedback with appropriate Department partners.
VII. Conditions and Maintenance of Certification Requirements for
Health IT Developers
Section 4002 of the Cures Act modifies section 3001(c)(5) of the
Public Health Service Act (PHSA) to require the Secretary of HHS,
through notice and comment rulemaking, to establish Conditions and
Maintenance of Certification requirements for the Program.
Specifically, health IT developers or entities must adhere to certain
Conditions and Maintenance of Certification requirements concerning
information blocking; appropriate exchange, access, and use of
electronic health information; communications regarding health IT;
application programming interfaces (APIs); real world testing;
attestations regarding certain Conditions and Maintenance of
Certification requirements; and submission of reporting criteria under
the EHR Reporting Program under section 3009A(b) of the PHSA.
A. Implementation
To implement section 4002 of the Cures Act, we proposed an approach
whereby the Conditions and Maintenance of Certification requirements
express initial certification requirements for health IT developers and
their certified Health IT Module(s) as well as ongoing maintenance
requirements that must be met by both health IT developers and their
certified Health IT Module(s) under the ONC Health IT Certification
Program (Program). If these requirements are not met, the health IT
developer may no longer be able to participate in the Program and/or
its certified health IT may have its certification terminated. We
proposed to implement each Condition of Certification requirement with
further specificity as it applies to
[[Page 25718]]
the Program. We also proposed to establish Maintenance of Certification
requirements for certain Conditions of Certification requirements as
standalone requirements. As we stated in the Proposed Rule, this
approach would establish clear baseline technical and behavior
Conditions of Certification requirements with evidence that the
Conditions of Certification requirements are continually being met
through the Maintenance of Certification requirements.
Comments. We received comments expressing general support for the
concept of requiring Conditions and Maintenance of Certification
requirements. Commenters stated that these requirements are a step
forward toward promoting transparency, improving usability, and
achieving interoperability of health IT. We also received comments
asserting that the Conditions and Maintenance of Certification
requirements should only apply to developers of certified health IT.
Response. We thank commenters for their support. We provide further
details on each of the Conditions and Maintenance of Certification
requirements within their respective subsections in this section of the
final rule. However, to clarify our approach to the Conditions and
Maintenance of Certification requirements in response to comments, the
Conditions and Maintenance of Certification requirements, except for
the ``information blocking'' and ``assurances'' Conditions and
Maintenance of Certification requirements, apply only to actions and
behaviors of health IT developers related to their certified health IT
as well as to the certified health IT itself. For the ``information
blocking'' and ``assurances'' Conditions and Maintenance of
Certification requirements, consistent with the Cures Act provisions
and our implementation of section 3022(a) (information blocking) of the
PHSA, a health IT developer is also responsible to ensure that all of
its health IT and related actions and behaviors do not constitute
information blocking or inhibit the appropriate access, exchange, and
use of electronic health information (EHI). We refer readers to section
VIII of this preamble for further discussion of the information
blocking regulations.
B. Provisions
1. Information Blocking
The Cures Act requires that a health IT developer, as a Condition
and Maintenance of Certification requirement under the Program, not
take any action that constitutes ``information blocking'' as defined in
section 3022(a) of the PHSA (see 3001(c)(5)(D)(i) of the PHSA). We
proposed to establish this Information Blocking Condition of
Certification in Sec. 170.401. We proposed that the Condition of
Certification would prohibit any health IT developer who has at least
one health IT product certified under the Program from taking any
action that constitutes information blocking as defined by section
3022(a) of the PHSA and proposed in Sec. 171.103. We clarified in the
Proposed Rule that this proposed ``information blocking'' Condition of
Certification and its requirements would be substantive requirements of
the Program and would rely on the definition of ``information
blocking'' established by section 3022(a) of the PHSA and proposed in
Sec. 171.103 (84 FR 7465).
We received no comments specifically about the Information Blocking
Condition of Certification and have adopted the Condition of
Certification as proposed. We received many comments regarding the
information blocking provision, and have responded to those comments in
the information blocking discussion in section VIII of this preamble.
We also refer readers to section VII.D of this final rule for
additional discussion of ONC's enforcement of this and other Conditions
and Maintenance of Certification requirements.
2. Assurances
The Cures Act requires that a health IT developer, as a Condition
and Maintenance of Certification requirement under the Program, provide
assurances to the Secretary, unless for legitimate purposes specified
by the Secretary, that it will not take any action that constitutes
information blocking as defined in section 3022(a) of the PHSA, or any
other action that may inhibit the appropriate exchange, access, and use
of electronic health information (EHI). We proposed to implement this
Condition of Certification and accompanying Maintenance of
Certification requirements in Sec. 170.402. As a Condition of
Certification requirement, a health IT developer must comply with the
Condition of Certification as recited here and in the Cures Act. We
discussed in section VIII of the Proposed Rule the proposed reasonable
and necessary activities specified by the Secretary, which constitute
the exceptions to the information blocking definition.
We also proposed to establish more specific Conditions and
Maintenance of Certification requirements for a health IT developer to
provide assurances that it does not take any action that may inhibit
the appropriate exchange, access, and use of EHI. These proposed
requirements serve to provide further clarity under the Program as to
how health IT developers can provide such broad assurances with more
specific actions.
Comments. Most commenters agreed with the central premise of our
proposal to adopt the ``assurances'' Condition and Maintenance of
Certification requirement, requiring that a health IT developer provide
certain assurances to the Secretary, including that, unless done for
one of the ``legitimate purposes'' specified by the Secretary, it will
not take any actions that constitutes information blocking as defined
in section 3022(a) of the PHSA, or any other action that may inhibit
the appropriate exchange, access, and use of electronic health
information (EHI). Commenters stated that they support ONC's efforts to
eliminate barriers that result in information blocking. One commenter
stated that it is not clear what constitutes ``satisfactory to the
Secretary'' as interpretations may change from Secretary to Secretary,
and suggested removing the term ``Secretary.''
Response. We thank commenters for their support. We have finalized
our proposal to adopt the ``assurances'' Condition and Maintenance of
Certification requirement subject to the clarifications and revisions
discussed below. In response to the comment recommending we remove the
term ``Secretary'' as Secretaries may change over time, it will not be
removed as it is in the authorizing Cures Act statutory language. For
clarification, future Secretaries may establish changes to the
implementation of the Cures Act ``assurances'' Condition and
Maintenance of Certification requirements through notice and comment
rulemaking, as has been done with this rulemaking.
a. Full Compliance and Unrestricted Implementation of Certification
Criteria Capabilities
We proposed, as a Condition of Certification requirement, that a
health IT developer must ensure that its health IT certified under the
Program conforms to the full scope of the certification criteria to
which its health IT is certified. This has always been an expectation
of ONC and users of certified health IT and, importantly, a requirement
of the Program. As stated in the Proposed Rule, we believe that by
incorporating this expectation as an explicit Condition of
Certification requirement under the Program, there
[[Page 25719]]
would be assurances, and documentation via the ``Attestations''
Condition and Maintenance of Certification requirements proposed in
Sec. 170.406, that all health IT developers fully understand their
responsibilities under the Program, including not to take any action
with their certified health IT that may inhibit the appropriate
exchange, access, and use of EHI. To this point, certification criteria
are designed and issued so that certified health IT can support
interoperability and the appropriate exchange, access, and use of EHI.
We also proposed that, as a complementary Condition of
Certification requirement, health IT developers of certified health IT
must provide an assurance that they have made certified capabilities
available in ways that enable them to be implemented and used in
production environments for their intended purposes. More specifically,
developers would be prohibited from taking any action that could
interfere with a user's ability to access or use certified capabilities
for any purpose within the scope of the technology's certification.
Such actions may inhibit the appropriate access, exchange, or use of
EHI and are therefore contrary to this proposed Condition of
Certification requirement. While such actions are already prohibited
under the Program (80 FR 62711), making these existing requirements
that prohibit developers from taking any action that could interfere
with a user's ability to access or use certified capabilities for any
purpose within the scope of the technology's certification explicit in
this Condition of Certification requirement will ensure that health IT
developers are required to attest to them pursuant to the Attestations
Condition of Certification requirement in Sec. 170.406, which will in
turn provide additional assurances to the Secretary that developers of
certified health IT support and do not inhibit appropriate access,
exchange, or use of EHI.
As discussed at 84 FR 7466 in our Proposed Rule, actions that would
violate this Condition of Certification requirement include failing to
fully deploy or enable certified capabilities; imposing limitations
(including restrictions) on the use of certified capabilities once
deployed; or requiring subsequent developer assistance to enable the
use of certified capabilities, contrary to the intended uses and
outcomes of those capabilities). The Condition of Certification
requirement would also be violated were a developer to refuse to
provide documentation, support, or other assistance reasonably
necessary to enable the use of certified capabilities for their
intended purposes. More generally, any action that would be likely to
substantially impair the ability of one or more users (or prospective
users) to implement or use certified capabilities for any purpose
within the scope of applicable certification criteria would be
prohibited by this Condition of Certification requirement. Such actions
may include imposing limitations or additional types of costs,
especially if these were not disclosed when a customer purchased or
licensed the certified health IT.
Comments. We received a comment recommending additional language to
allow health IT developers to be able to provide an explanation of how
their software conforms to the certification criteria requirements and
how they enable the appropriate exchange, access, and use of EHI.
Response. We thank the commenter for their input, but do not accept
the recommendation. Health IT must comply with certification criteria
as specified in regulation. We also refer readers to the
``Attestations'' Condition of Certification requirement in this section
of the preamble for more information regarding how we proposed to
provide flexibilities, including a method for health IT developers to
indicate their compliance, noncompliance, or the inapplicability of
each Condition and Maintenance of Certification requirement as it
applies to all of their health IT certified under the Program, as well
as the flexibility to specify noncompliance per certified Health IT
Module, if necessary. As such, we have finalized the Full Compliance
and Unrestricted Implementation of Certification Criteria Capabilities
Condition of Certification requirement as proposed that a health IT
developer must ensure that its health IT certified under the Program
conforms to the full scope of the certification criteria to which its
health IT is certified, and that health IT developers would be
prohibited from taking any action that could interfere with a user's
ability to access or use certified capabilities for any purpose within
the scope of the technology's certification. We note that because
compliance with the information blocking section of this final rule
(Part 171) is not required until six months after the publication date
of the final rule, Sec. 170.402(a)(1) also has a six-month delayed
compliance date.
Comments. A couple of commenters requested clarification on whether
requiring subsequent developer assistance to enable the use of certain
certified capabilities would be considered noncompliance with the
Condition of Certification requirement, such as managed services,
hosting, connecting with exchange networks, or outsourced arrangements
under agreement.
Response. We clarify that the purpose of this Condition of
Certification requirement is to make certified capabilities available
in ways that enable them to be implemented and used in production
environments for their intended purposes. As stated above, the
Condition of Certification requirement would be violated were a
developer to refuse to provide documentation, support, or other
assistance reasonably necessary to enable the use of certified
capabilities for their intended purposes (see 84 FR 7466). We do not
believe that actions by health IT developers to provide their customers
with education, implementation, and connection assistance to integrate
certified capabilities for their customers would typically constitute
actions that interfere with a customer's ability to use certified
capabilities for their intended purposes, but in the absence of
specific facts, we cannot say that whether there are scenarios that
would result in the assistance interfering with a user's ability to
access or use certified capabilities for any purpose within the scope
of the health IT's certification. As such, education and other
assistance may be offered, but care should be taken to do so in a
manner that minds the Condition of Certification requirement standards.
Comments. We received a comment asking that health IT developers be
required to provide honest communication and expert advice as required
by a user.
Response. We appreciate the commenter's suggestion regarding honest
communication and expert advice. However, such a requirement would not
be consistent with this Condition of Certification requirement, which
focuses on assurances that Health IT developers did not take actions
that may inhibit the appropriate exchange, access, and use of
electronic health information (EHI). We also believe it would be
difficult to enforce such a requirement in terms of determining what
constitutes an ``honest'' communication and ``expert advice.''
b. Certification to the ``Electronic Health Information Export''
Criterion
We proposed that a health IT developer that produces and
electronically manages EHI must certify their health IT to the 2015
Edition ``EHI export'' criterion in Sec. 170.315(b)(10). As
[[Page 25720]]
a Maintenance of Certification requirement, we proposed that a health
IT developer that produces and electronically manages EHI must provide
all of its customers of certified health IT Modules with health IT
certified to the functionality included in Sec. 170.315(b)(10) within
24 months of a subsequent final rule's effective date or within 12
months of certification for a health IT developer that never previously
certified health IT to the 2015 Edition, whichever is longer.
Consistent with these proposals, we also proposed to amend Sec.
170.550 to require that ONC-ACBs certify health IT to the proposed 2015
Edition ``EHI export'' certification criterion when the health IT
developer of the health IT Module presented for certification produces
and electronically manages EHI. As discussed in section IV.C.1 of the
Proposed Rule, the availability of the capabilities in the ``EHI
export'' certification criterion promote access, exchange, and use of
health information to facilitate electronic access to single patient
and patient population health information in cases such as a patient
requesting their information, or a health care provider switching
health IT systems. As such, health IT developers with health IT
products that have health IT Modules certified to the finalized ``EHI
export'' certification requirement must make this functionality
available to customers and provide assurances that the developer is not
taking actions that constitute information blocking or any other action
that may inhibit the appropriate exchange, access, and use of health
information. We discussed the EHI export functionality in section
IV.B.4 of the Proposed Rule.
Comments. A couple of commenters expressed their support for the
Condition of Certification requirement, noting that certifying health
IT to Sec. 170.315(b)(10) would provide greater EHI access to end
users. Several commenters requested extending the implementation
timeframe to 36 months stating that more time is needed for analysis,
product development, and testing, with an additional 12 months for
client adoption, testing, and training. A couple of commenters
supported the 24-month timeframe, but stated that they did not support
ONC dictating the adoption schedule for providers, and that the
proposal does not consider the efforts required from providers to plan
and execute effective implementation and adoption. One commenter stated
that 24 months is not aggressive enough and that the rule should
prioritize certain aspects of patient-directed exchange and make these
available in 12 months or less. Another commenter suggested that we
narrow the type of health IT developer that must certify health IT to
Sec. 170.315(b)(10), noting that some Health IT Modules may manage
data produced by other Health IT Modules, or received and incorporated
from other sources. We did not receive any comments specific to our
proposal to amend Sec. 170.550 to require that ONC-ACBs certify health
IT to the proposed 2015 Edition ``EHI export'' criterion when the
health IT developer of the health IT Module presented for certification
produces and electronically manages EHI.
Response. We thank the commenters for their support. In response to
comments regarding scope of data export under this criterion, we have
modified the proposed ``EHI export'' certification criterion and scope
of data export. In doing so, we have also revised our Condition of
Certification requirement, which we have finalized in Sec.
170.402(a)(4), that a health IT developer of a certified Health IT
Module that is part of a health IT product which electronically stores
EHI must certify to the certification criterion in Sec.
170.315(b)(10). Additionally, we clarify that in attesting to Sec.
170.406, a health IT developer must attest accurately in accordance
with Sec. 170.402(a)(4) and (b)(2) if the health IT developer
certified a Health IT Module(s) that is part of a health IT product
which can store EHI. The finalized criterion focuses on the Health IT
Module's ability to export EHI for the health IT product's single and
patient population, which encompasses the EHI that can be stored at the
time of certification by the product, of which the Health IT Module is
a part. To note, we do not require developers to disclose proprietary
information about their products. Also, as clarified above and in Sec.
170.315(b)(10)(iii), we do not require any specific standards for the
export format(s) used to support the export functionality.
In regards to when health IT developers must provide all of their
users of certified health IT with health IT certified to the
functionality included in Sec. 170.315(b)(10), we have removed the
proposed language ``within 12 months of certification for a health IT
developer that never previously certified health IT to the 2015
Edition, whichever is longer.'' Our intention was to provide equity
between existing and new health IT developers. However, we have
concluded that new health IT developers will not be at a disadvantage
to meet the same timeline considering all health IT developers will be
aware of requirements necessary for certification when this final rule
is published. We also acknowledge the concerns expressed regarding the
24-month timeframe and have extended the compliance timeline to within
36 months of the final rule's publication date, as finalized in Sec.
170.402(b)(2)(i). With the narrowed scope of data export for the
criterion, we believe health IT developers should be able to provide
all of their customers of Health IT Modules certified to Sec.
170.315(b)(10) with the export functionality included in Sec.
170.315(b)(10) within 36 months. We have also finalized in Sec.
170.402(b)(2)(ii) that on and after 36 months from the publication of
this final rule, health IT developers that must comply with the
requirements of Sec. 170.402(a)(4) must provide all of their customers
of certified health IT with health IT certified to Sec.
170.315(b)(10). From this milestone forward, a health IT developer's
participation in the Certification Program obligates them to provide
the technical capabilities expressed in Sec. 170.315(b)(10) when they
provide such certified health IT to their customers. We will monitor
ongoing compliance with this Condition and Maintenance of Certification
through a variety of means including, but not limited to, developer
attestations pursuant to Sec. 170.406, health IT developers real world
testing plans, response to user complaints, and ONC-ACB surveillance
activities.
Consistent with the above revisions and in alignment with our
proposal to amend Sec. 170.550, we have also amended Sec.
170.550(g)(5) regarding Health IT Module dependent criteria for
consistency with the requirements of Sec. 170.402(a)(4) and (b)(2)
when a Health IT Module presented for certification is part of a health
IT product which can store electronic health information. In addition,
we have amended Sec. 170.550(m)(2) to only allow ONC-ACBs to issue
certifications to Sec. 170.315(b)(6) until 36 months after the
publication date of this final rule. Thus, ONC-ACBs may issue
certificates for either Sec. 170.315(b)(6) or (b)(10) up until 36
months after the publication date of this final rule, but on and after
36 months they may only issue certificates for Health IT Modules in
accordance with Sec. 170.315(b)(10). We note that ONC-ACBs are
required by their ISO/IEC 17065 accreditation to have processes in
place to meet the expectations and minimum requirements of the Program.
Thus, ONC-ACBs are expected to have processes in place in order to
effectively monitor these timeline requirements on and after 36 months
after the
[[Page 25721]]
publication of this rule, and to additionally ensure that the health IT
developer attests accurately to Sec. 170.402(a)(4) and (b)(2). Should
a developer fail to comply, the ONC-ACB will follow its processes to
institute corrective action and report to ONC in accordance with
Program reporting requirements in 45 CFR 170.523(f)(1)(xxii). In the
event the developer does not follow through with the corrective action
plan established and approved with the ONC-ACB, the ONC-ACB must alert
ONC of the health IT developer's failure to comply with the Conditions
and Maintenance of Certification requirements.
Comments. A commenter requested ONC add functionality to the CHPL
(or in another format) that provides a list of the start and end dates
of each previously certified Health IT Module.
Response. We appreciate this suggestion and note that the CHPL
already lists certification dates for certified Health IT Modules,
including the dates the Health IT Module was last modified,
decertified, or made inactive.
c. Records and Information Retention
We proposed that, as a Maintenance of Certification requirement in
Sec. 170.402(b)(1), a health IT developer must, for a period of 10
years beginning from the date of certification, retain all records and
information necessary to demonstrate initial and ongoing compliance
with the requirements of the Program. In other words, records and
information should be retained starting from the date a developer first
certifies health IT under the Program and applies separately to each
unique Health IT Module (or Complete EHR, as applicable) certified
under the Program. This retention of records is necessary to verify
health IT developer compliance with Program requirements, including
certification criteria and Conditions and Maintenance of Certification
requirements. As stated in the Proposed Rule, 10 years is an
appropriate period of time given that many users of certified health IT
participate in various CMS programs, as well as other programs, that
require similar periods of records retention.
In an effort to reduce administrative burden, we also proposed,
that in situations where applicable certification criteria are removed
from the Code of Federal Regulations before the 10 years have expired,
records must only be kept for 3 years from the date of removal for
those certification criteria and related Program provisions unless that
timeframe would exceed the overall 10-year retention period. This ``3-
year from the date of removal'' records retention period also aligns
with the records retention requirements for ONC-ACBs and ONC-ATLs under
the Program.
We encouraged comment on these proposals and whether the proposed
requirements can provide adequate assurances that certified health IT
developers are demonstrating initial and ongoing compliance with the
requirements of the Program; and thereby ensuring that certified health
IT can support interoperability, and appropriate exchange, access, and
use of EHI.
Comments. Some commenters requested clarification on what records
and information are expected to be maintained and how this is different
from the records ONC-ACBs and ONC-ATLs retain. A couple commenters
requested clarification on when the records and information retention
requirement would take effect. One commenter requested clarification
regarding the role of health IT developers that no longer maintain a
certified Health IT Module or have their certification suspended. One
commenter recommended setting a retention period for record keeping in
the event that a health IT developer removes a Health IT Module from
market to ensure that potentially short lived Health IT Modules would
inadvertently not have their documentation maintained.
Response. We have adopted our proposal in Sec. 170.402(b)(1)
without revisions. We continue to believe that 10 years is an
appropriate period of time given that many users of certified health IT
participate in various CMS programs, as well as other programs, that
require similar periods of records retention. We also finalized that in
situations where applicable certification criteria are removed from the
Code of Federal Regulations, records must only be kept for 3 years from
the date of removal for those certification criteria and related
Program provisions unless that timeframe would exceed the overall 10-
year retention period. We clarify that health IT developers are best
situated to determine what records and information in their possession
would demonstrate their compliance with all of the relevant Program
requirements. We note that it is our understanding that health IT
developers are already retaining the majority of their records and
information for the purposes of ONC-ACB surveillance and ONC direct
review under the Program. We also refer readers to section VII.D of
this final rule preamble for additional discussion of records necessary
for the enforcement of the Conditions and Maintenance of Certification
requirements. In regard to the requested clarification for the role of
health IT developers that no longer maintain a certified Health IT
Module or have their certification suspended, a health IT developer who
does not have any certified Health IT Modules within the Program would
no longer have any obligation to retain records and information for the
purposes of the Program. However, we note that it may be in the health
IT developer's best interest to retain their records and information.
For example, records may be useful for health IT developers in any
potential investigation or enforcement action taken outside of the ONC
Health IT Certification Program such as by the HHS Office of the
Inspector General (e.g., information blocking) or the U.S. Department
of Justice (e.g., False Claims Act).
d. Trusted Exchange Framework and the Common Agreement--Request for
Information
In the Proposed Rule, we included a Request for Information (RFI)
as to whether certain health IT developers should be required to
participate in the Trusted Exchange Framework and Common Agreement
(TEFCA) as a means of providing assurances to their customers and ONC
that they are not taking actions that constitute information blocking
or any other action that may inhibit the appropriate exchange, access,
and use of EHI. We received 40 comments on this RFI. We appreciate the
input provided by commenters and may consider them to inform a future
rulemaking.
3. Communications
The Cures Act requires that a health IT developer, as a Condition
and Maintenance of Certification requirement under the Program, does
not prohibit or restrict communication regarding the following
subjects:
The usability of the health information technology;
The interoperability of the health information technology;
The security of the health information technology;
Relevant information regarding users' experiences when
using the health information technology;
The business practices of developers of health information
technology related to exchanging electronic health information; and
The manner in which a user of the health information
technology has used such technology.
The Cures Act established the broad communications protections
delineated above (referred to hereafter as ``protected
communications'') and we proposed in 84 FR 7467 to implement
[[Page 25722]]
this general prohibition against developers imposing prohibitions and
restrictions on protected communications in Sec. 170.403.
We also recognized that there are circumstances where it is both
legitimate and reasonable for developers to limit the sharing of
information about their health IT. As such, we proposed to allow
developers to impose prohibitions or restrictions on protected
communications in certain narrowly defined circumstances. In order for
a prohibition or restriction on a protected communication to be
permitted, we proposed in 84 FR 7467 that it must pass a two-part test.
First, the communication that is being prohibited or restricted must
not fall within a class of communications (hereafter referred to as
``communications with unqualified protection'') that is considered to
always be legitimate or reasonable--such as communications required by
law, made to a government agency, or made to a defined category of
safety organizations. Second, to be permitted, a developer's
prohibition or restriction on communications must also fall within a
category of communications (hereafter referred to as ``permitted
prohibitions and restrictions'') for which it is both legitimate and
reasonable for a developer to limit the sharing of information about
its health IT. This would be because of the nature of the relationship
between the developer and the communicator or because of the nature of
the information that is, or could be, the subject of the communication.
We proposed that a developer's restriction or prohibition that does not
satisfy this two-part test would contravene the Communications
Condition of Certification requirement. We note that this two-part test
strikes a reasonable balance between the need to promote open
communication about health IT and related business practices, and the
need to protect the legitimate interests of health IT developers and
other entities.
Comments. The majority of public comments we received supported the
proposed Communications Condition of Certification requirements, with
many commenters expressing strong support. Commenters stated that the
proposed requirements would enable better communication that would
improve health IT and patient care. Some commenters who supported the
proposed requirements sought clarification or had specific concerns,
including regarding the proposed deadlines for contract modification.
These matters are discussed in more detail below. Additionally, a
handful of public comments strongly opposed the proposed requirements,
primarily based on concerns regarding intellectual property (IP).
Response. We appreciate the overall strong support for the
Communications Condition of Certification requirements as proposed and
have finalized with modifications in Sec. 170.403. We also recognize
the need to provide clarification regarding some aspects of the
requirements, including regarding the protections available for IP that
are included in the Communications Condition and Maintenance of
Certification requirements.
We emphasize that, under section 3001(c)(5) of the PHSA,
participation in the ONC Health IT Certification Program (Program) is
voluntary. In other words, ONC cannot compel health IT developers to
participate in the Program nor can ONC impose consequences (e.g.,
enforcement actions or penalties) on health IT developers who choose
not to participate in the Program. The requirements of the Program are
much like requirements for any other voluntary contract or agreement an
entity would enter into with the Federal Government. Through the
Conditions and Maintenance of Certification requirements, we have
essentially offered developers terms for participation in the Program
that we believe are appropriate based on: Our statutory instruction and
interpretation of the Cures Act; the utility and necessity of using
intellectual property, including screenshots, to communicate issues
with usability, user experience, interoperability, security, or the way
the technology is used (and relatedly, the real and substantial threat
to public health and safety resulting from prohibitions and/or
restrictions on the communication of screenshots); and the measured
approach we have taken throughout the Communications Condition and
Maintenance of Certification requirements (which is discussed in detail
in this section). Because the Program is voluntary, developers have the
option to agree to the terms we have offered or to choose not to
participate in the Program. As such, we believe our policies concerning
intellectual property, including the use of screenshots, are consistent
with other laws and regulations that govern terms for voluntary
contracts and agreements with the Federal Government. Further, we
believe that the final provisions of this Condition of Certification
include appropriate consideration of health IT developers' intellectual
property rights.
We further discuss the various aspects of the Communications
Condition of Certification requirements, as well as the changes we have
made to our proposals, in more detail below.
a. Background and Purpose
The Communications Condition of Certification requirements address
industry practices of certified health IT developers that can severely
limit the ability and willingness of health IT customers, users,
researchers, and other stakeholders to openly discuss and share their
experiences and other relevant information about health IT performance,
including about the ability of health IT to exchange health information
electronically. These practices result in a lack of transparency that
can contribute to and exacerbate patient safety risks, system security
vulnerabilities, and health IT performance issues.
We explained in the Proposed Rule that the challenges presented by
health IT developer actions that prohibit or restrict communications
have been examined for some time. The problem was identified in a 2012
report by the Institute of Medicine of the National Academies (IOM)
entitled ``Health IT and Patient Safety: Building Safer Systems for
Better Care'' \73\ (IOM Report). The IOM Report stated that health care
providers, researchers, consumer groups, and other health IT users lack
information regarding the functionality of health IT.\74\ The IOM
Report observed, relatedly, that many developers restrict the
information that users can communicate about developers' health IT
through nondisclosure clauses, confidentiality clauses, IP protections,
hold-harmless clauses, and other boilerplate contract language.\75\ The
report stressed the need for health IT developers to enable the free
exchange of information regarding the experience of using their health
IT, including the sharing of screenshots relating to patient
safety.\76\
---------------------------------------------------------------------------
\73\ IOM (Institute of Medicine), Health IT and Patient Safety:
Building Safer Systems for Better Care (2012). Available at http://www.nationalacademies.org/hmd/Reports/2011/Health-IT-and-Patient-Safety-Building-Safer- Systems-for-Better-Care.aspx.
\74\ Id. at 37.
\75\ Id. at 36, 128.
\76\ Id.
---------------------------------------------------------------------------
Concerns have also been raised by researchers studying health
IT,\77\ who emphasize that confidentiality and IP provisions in
contracts often place broad and unclear limits on authorized uses of
information related to health IT,
[[Page 25723]]
which in turn seriously impact the ability of researchers to conduct
and publish their research.\78\
---------------------------------------------------------------------------
\77\ See Hardeep Singh, David C. Classen, and Dean F. Sittig,
Creating an Oversight Infrastructure for Electronic Health Record-
Related Patient Safety Hazards, 7(4) Journal of Patient Safety 169
(2011). Available at https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3677059/.
\78\ Kathy Kenyon, Overcoming Contractual Barriers to EHR
Research, Health Affairs Blog (October 14, 2015). Available at
http://healthaffairs.org/blog/2015/10/14/overcoming-contractual-barriers-to-ehr-research/.
---------------------------------------------------------------------------
The issue of health IT developers prohibiting or restricting
communications about health IT has been the subject of a series of
hearings by the Senate Committee on Health, Education, Labor and
Pensions (HELP Committee), starting in the spring of 2015. Senators on
the HELP Committee expressed serious concern regarding the reported
efforts of health IT developers to restrict, by contract and other
means, communications regarding user experience, including information
relevant to safety and interoperability.\79\
---------------------------------------------------------------------------
\79\ Senate HELP Committee Hearing at 13 and 27 (July 23, 2015),
available at https://www.help.senate.gov/hearings/achieving-the-promise-of-health-information-technology-information-blocking-and-potential-solutions.
---------------------------------------------------------------------------
Developer actions that prohibit or restrict communications about
health IT have also been the subject of investigative reporting.\80\ A
September 2015 report examined eleven contracts between health systems
and major health IT developers and found that, with one exception, all
of the contracts protected large amounts of information from being
disclosed, including information related to safety and performance
issues.\81\
---------------------------------------------------------------------------
\80\ D. Tahir, POLITICO Investigation: EHR gag clauses exist--
and, critics say, threaten safety, Politico, August 27, 2015.
\81\ Id.
---------------------------------------------------------------------------
b. Condition of Certification Requirements
i. Protected Communications and Communicators
We proposed in 84 FR 7468 that the protection afforded to
communicators under the requirements of the Communications Condition of
Certification in Sec. 170.403(a) would apply irrespective of the form
or medium in which the communication is made. We proposed in 84 FR 7468
that developers must not prohibit or restrict communications whether
written, oral, electronic, or by any other method if they are
protected, unless such prohibition or restriction is otherwise
permitted by the requirements of this Condition of Certification.
Similarly, we proposed that these Condition of Certification
requirements do not impose any limit on the identity of the
communicators that are able to benefit from the protection afforded,
except that employees and contractors of a health IT developer may be
treated differently when making communications that are not afforded
unqualified protection under Sec. 170.403(a)(2)(i). For example, we
proposed that this Condition of Certification's requirements are not
limited to communications by health IT customers (e.g., providers) who
have contracts with health IT developers.
Comments. Many commenters addressed the scope of protected
communications in their comments. Several commenters suggested that the
proposed scope of protected communications was too broad. Other
commenters stated that the scope should be clarified. One commenter
suggested that the scope of private communications that can be shared
should be limited and that ONC should require mutual consent for such
communications to be made public.
Response. We appreciate these comments. The Cures Act identifies a
list of subject areas about which health IT developers cannot prohibit
or restrict communications to meet the conditions for certification.
The terms we proposed for the protected subject areas are taken from
the language in section 4002 of the Cures Act and include:
The usability of the health information technology;
The interoperability of the health information technology;
The security of the health information technology;
Relevant information regarding users' experiences when
using the health information technology;
The business practices of developers of health information
technology related to exchanging electronic health information; and
The manner in which a user of the health information
technology has used such technology.
We continue to interpret the above statutory terms broadly, but
within the limiting framework we proposed, which includes a distinction
between communications entitled to unqualified protections and those
communications not entitled to such protection. We have, however,
finalized some provisions with further limiting and clarifying language
as well as provided examples to improve understanding of the
provisions.
We decline to create a consent requirement as part of the
requirements of this Condition of Certification because such a
requirement could unnecessarily encumber vital communications protected
by the Cures Act. As highlighted above, the Communications Condition of
Certification requirements are intended to enable unencumbered
communication about usability, interoperability, and other critical
issues with health IT, and a consent requirement would chill the
ability of users of health IT to engage in that communication as well
as be contrary to section 4002 of the Cures Act.
Comments. One commenter stated that the Communications Condition of
Certification requirements should apply only to certified health IT,
recommending that ONC clarify that the use of ``the health IT'' refers
only to the developer's health IT that is certified under the ONC
Health IT Certification Program. The commenter stated that the use of
``the health IT'' in the Cures Act can only be reasonably interpreted
as referring to the health IT for which a developer is seeking
certification, not all of the developer's health IT. Another commenter
stated that other health IT, such as billing systems, should be out of
scope of this requirement and noted that to do otherwise would create a
regulatory imbalance between developers of such health IT who also
offer certified health IT and those who do not.
Response. We appreciate these comments regarding restricting the
applicability of the Communications Condition of Certification
requirements to certified health IT. We clarify that, as with all of
the Conditions of Certification requirements, the Communications
Condition of Certification requirements apply to developers of health
IT certified under the Program and to the conduct of such developers
with respect to health IT certified under the Program. By way of
example, if a developer had health IT certified under the Program and
also had health IT that was not certified under the Program, then only
those communications about the certified health IT would be covered by
the Communications Condition of Certification requirements.
Comments. We received one comment requesting more specificity on
the definition of communicators covered by the Communications Condition
of Certification requirements. The commenter expressed concern that the
broad scope could impact the ability to maintain confidentiality in
traditional business-to-business relationships.
Response. We appreciate this comment and understand the concern
noted by the commenter. As stated in the Proposed Rule and finalized in
Sec. 170.403, the Communications Condition and Maintenance of
Certification requirements generally do not impose any limit on the
identity of communicators that are able to benefit from the protection
afforded. We also note that there are limited exceptions
[[Page 25724]]
where communications by certain communicators can be restricted.
Specifically, as finalized in Sec. 170.403(a)(2)(ii)(A), health IT
developers can place limited restrictions on communications by
employees and contractors. We believe this will enable traditional
business-to-business relationships to continue without undue
disruption, including allowing implementation of non-disclosure
agreements or other contracts as necessary to maintain confidentiality.
ii. Protected Subject Areas
Comments. We received several comments requesting that we clarify
how the Communications Condition of Certification requirements would
apply to communications regarding public health reporting, including
communications made by public health authorities.
Response. We emphasize that the Cures Act identified a list of
subject areas about which we were required to forbid developers from
prohibiting or restricting communications. Though public health
reporting was not specifically covered by the Cures Act or our proposed
regulations, it may be that certain public health communications will
fall within the categories established by the statute. We also note
that one of the ``communications with unqualified protection''
discussed later in this section is for communicating information about
adverse events, hazards, and other unsafe conditions to government
agencies, health care accreditation organizations, and patient safety
organizations. Depending on the specific communication in question, a
communication about public health reporting or a communication made to
public health authorities could be a communication that could not be
restricted in any way. We also emphasize that, subject to limited
circumstances already discussed above, we do not impose any limit on
the identity of the communicators that are able to benefit from
protections afforded under the Communications Condition of
Certification requirements. Communicators are broadly defined and could
include public health agencies and authorities.
Comments. Several commenters had concerns regarding how a developer
may address communications that contain false claims or libelous
statements. Commenters discussed the need to enable health IT
developers to--for example--refute false claims, deal with anonymous
claims, and restrict certain communications (such as false statements
or communications protected by attorney-client privilege). Some of
these comments emphasized that false communications such as libel
should not be protected, nor should communications sent by someone who
obtained them illegally, such as a hacker. Some of the commenters
recommended adding a category of communications that would never be
protected under the proposed framework, and such communications would
not receive unqualified protection or necessitate permitted
restrictions. This would allow a developer to--for example--prohibit or
restrict communications that are false or deceptive, would violate a
law or court order, or would result in a breach of contract.
Response. We appreciate the concerns expressed by commenters
regarding statements that may be false or misleading. However,
developers already have legal means and remedies available to them to
address such statements, and this rule does not change that. For
example, each State has libel laws that address libelous or defamatory
statements and provide remedies in situations where the specific facts
in a damaging statement can be proven to be untrue. We believe that
such statements are best addressed through those laws and that it is
neither prudent nor practical for ONC to use the Program and the
Communications Condition of Certification requirements to attempt to
assess such statements and make determinations as to their veracity.
Further, we note that the Communications Condition of Certification
requirements only provide that such protected communications cannot be
restricted or prohibited. It is up to the health IT developer whether
and how they choose to respond to the protected communication once
made. Therefore, we clarify that it is not a violation of the
Communications Condition of Certification requirements for developers
to respond to false or unlawful comments under applicable law, as they
do now, and to pursue litigation or any other available legal remedy in
response to any protected communications that are covered by the
Communications Condition of Certification. For example, it would not be
a violation of the Communications Condition of Certification for a
health IT developer who restricts the communication of screenshots as
permitted under Sec. 170.403(a)(2)(ii)(D) to pursue litigation for
Copyright infringement or violation of contract if a ``protected
communication'' disclosed more screenshots than the developer's
restriction allowed.
Comments. Several commenters requested that ``safety'' be added as
a protected category or that ONC should include in the final rule a
specific ban that prohibits any restrictions on communications about
health IT-related patient safety. Additionally, several commenters
noted that ONC should include specific reporting methods or standards
in the final rule to improve safety reporting or add examples to help
encourage reporting of safety and security issues. Several commenters
also requested that ONC develop protocols for reporting safety issues,
and one commenter recommended ONC develop a patient safety reporting
system.
Response. In implementing the Cures Act requirement that a health
IT developer, as a Condition of Certification requirement under the
Program, not restrict communications about health IT, we adhered to the
list of protected subject areas identified by Congress in the Cures
Act. Those subject areas include communications about ``usability,''
``relevant information regarding users' experiences when using the
health information technology,'' and the ``manner in which a user of
the health information technology has used such technology.'' We
clarify that patient safety issues related to an interaction with the
health IT could be covered in one or more of those categories.
Additionally, we agree with commenters that safety-related
communications should receive specific protections, and we emphasize
that the communication of safety concerns is also addressed as a
protected communication receiving ``unqualified protection.'' In the
section of this final rule on ``Communications with Unqualified
Protection,'' and in Sec. 170.403(a)(2)(i)(B), we state that
communicating information about adverse events, hazards, and other
unsafe conditions to government agencies, health care accreditation
organizations, and patient safety organizations is a communication
about which a developer would be prohibited from imposing any
prohibition or restriction.
(A) Usability of Health Information Technology
The term ``usability'' is not defined in the Cures Act, nor in any
other relevant statutory provisions. We proposed in 84 FR 7469 that the
``usability'' of health IT be construed broadly to include both an
overall judgment on the ``usability'' of a particular certified health
IT product by the user, as well as any factor that contributes or may
contribute to usability. We proposed that the factors of usability that
could be the subject of
[[Page 25725]]
protected communications include, but are not limited to, the
following: The user interface (e.g., what a user sees on the screen,
such as layout, controls, graphics and navigational elements); ease of
use (e.g., how many clicks); how the technology supports users'
workflows; the organization of information; cognitive burden; cognitive
support; error tolerance; clinical decision support; alerts; error
handling; customizability; use of templates; mandatory data elements;
the use of text fields; and customer support.
Comments. One commenter stated that ``usability'' is too broadly
defined and should relate more specifically to judgments on the ease of
use of the health IT, rather than factors related to usability.
Response. We do not believe that ``usability'' is inaccurately
defined nor too broadly defined. To define usability in the Proposed
Rule, we referenced the NIST standard \82\ as well as principles
recognized by the Healthcare Information and Management Systems Society
(HIMSS). We also emphasized that there are a multitude of factors that
contribute to any judgment about ``usability,'' including factors
contributing to the effectiveness, efficiency, and performance of the
health IT. We have finalized the scope of the protected subject area
``usability of its health IT'' in Sec. 170.403(a)(1)(i) as proposed,
providing that the ``usability'' of health IT be construed broadly to
include both an overall judgment on the ``usability'' of a particular
certified health IT product, as well as any of the many factors that
could contribute to usability as described in the Proposed Rule. We
also note that communications about the usability of health IT may
include communications about features that are part of the certified
health IT as well as communications about what is not in the certified
health IT (e.g., the absence of alerts or features that a user believes
would aid in usability or are related to the other subject areas
identified by the Cures Act).
---------------------------------------------------------------------------
\82\ See https://www.nist.gov/programs-projects/health-it-usability.
---------------------------------------------------------------------------
(B) Interoperability of Health Information Technology
The Cures Act, as codified in section 3000(9) of the PHSA, provides
a definition of ``interoperability'' that describes a type of health IT
that demonstrates the necessary capabilities to be interoperable. For
the purposes of the Communications Condition of Certification
requirements, we proposed that protected communications regarding the
``interoperability of health IT'' would include communications about
whether certified health IT and associated developer business practices
meet the interoperability definition described in section 3000(9) of
the PHSA, including communications about aspects of the technology or
developer that fall short of the expectations found in that definition.
We stated that this would include communications about the
interoperability capabilities of health IT and the practices of a
health IT developer that may inhibit the access, exchange, or use of
EHI, including information blocking. As previously noted, Congress did
not define the terms used in the Communications Conditions of
Certification requirements in section 4002(a) of the Cures Act and
codified in section 3001(c)(5)(D)(iii) of the PHSA. We believe that
``interoperability'' was appropriately defined in the Proposed Rule by
using the interoperability definition that is located elsewhere in
section 4003(a)(2) of the Cures Act and codified in section 3000(9) of
the PHSA.
We did not receive comments about this aspect of the Proposed Rule,
and we have finalized the scope of the protected subject area
``interoperability of its health IT'' in Sec. 170.403(a)(1)(ii) as
proposed above.
(C) Security of Health IT
The security of health IT is addressed by the HIPAA Security
Rule,\83\ which establishes national standards to protect individuals'
electronic protected health information (ePHI) that is created,
received, maintained, or transmitted by a covered entity or business
associate (as defined at 45 CFR 160.103). Covered entities and business
associates must ensure the confidentiality, integrity, and availability
of all ePHI; protect against any reasonably anticipated threats or
hazards to the security or integrity of such information; and protect
against any reasonably anticipated uses or disclosures of such
information that are not permitted or required under the HIPAA Privacy
Rule.\84\ The HIPAA Security Rule requires health IT developers, to the
extent that they are business associates of covered entities, to
implement appropriate administrative, physical, and technical
safeguards to ensure the confidentiality, integrity, and availability
of ePHI.\85\ We proposed in 84 FR 7469 that the matters that fall
within the topic of health IT security should be broadly construed to
include any safeguards, whether or not required by the HIPAA Security
Rule, that may be implemented (or not implemented) by a developer to
ensure the confidentiality, integrity, and availability of EHI
(information that includes ePHI), together with the certified health
IT's performance regarding security.
---------------------------------------------------------------------------
\83\ 45 CFR part 160 and subparts A and C of part 164.
\84\ 45 CFR part 160 and subparts A and C of part 164.
\85\ Id.
---------------------------------------------------------------------------
Comments. One commenter noted that it is important that developers
are able to remove posts on a website or forum that could compromise
the security of health IT and recommended that ONC explicitly allow
developers to do so in the final rule.
Response. We recognize the importance of protecting the security of
EHI and health IT. We also recognize that our engagement with
stakeholders, as well as the language in section 4002 of the Cures Act,
emphasize the strong public interest in allowing unencumbered
communications regarding the protected subject areas and communications
with unqualified protection, which are discussed in more detail below
and in Sec. 170.403(a)(2)(i). We emphasize that developers may respond
to communications as allowed under applicable law and may pursue any
appropriate legal remedy. Taking these factors into consideration, we
decline at this time to explicitly allow developers to restrict
communications regarding security as suggested by the commenter.
Comments. One commenter requested that ONC consider narrowing the
permitted communication of security elements in Sec.
170.403(a)(1)(iii) that might be used to compromise a particular
certified health IT's security, for example restricting the sharing of
authentication credentials issued to a customer or user to access a
system containing sensitive information such as PHI.
Response. We do not believe it is necessary in this final rule to
narrow or restrict the information that can be communicated where
security elements are included in the communication. As stated above,
we believe there is a strong public interest in allowing unencumbered
communications regarding the protected subject areas and communications
with unqualified protection. Further, assurances that access
credentials and PHI communicated under these circumstances will not be
shared inappropriately are addressed in the HIPAA Security Rule and
relevant State laws, and this rule does not change those protections.
Comments. One comment recommended that the Communications Condition
of Certification requirements should protect communication
[[Page 25726]]
regarding the overall security posture that the health IT developer
takes or makes the user take, including communications regarding a
system with known and longstanding issues or bugs.
Response. We appreciate this comment and clarify that
communications related to the overall security posture taken by a
health IT developer would be within the subject area of ``security of
its health IT,'' and thus would be protected communications covered by
the Communications Condition of Certification requirements. We have
finalized the scope of the protected subject area ``security of its
health IT'' in Sec. 170.403(a)(1)(iii) as proposed.
(D) User Experiences
The phrases ``relevant information regarding users' experiences
when using the health IT'' and ``user experience'' are not defined in
the Cures Act nor any other relevant statutory provisions. We proposed
in 84 FR 7470 to afford the term ``user experience'' its ordinary
meaning. To qualify as a ``user experience,'' we proposed that the
experience would have to have been one that is had by a user of health
IT. However, beyond this, we did not propose to qualify the types of
experiences that would receive protection under the Communications
Condition of Certification requirements based on the ``user
experience'' subject area. To illustrate the breadth of potential user
experiences that would be protected by the proposed Communications
Condition of Certification requirements, we proposed that
communications about ``relevant information regarding users'
experiences when using the health IT'' would encompass, for example,
communications and information about a person or organization's
experience acquiring, implementing, using, or otherwise interacting
with the health IT. We also proposed that this would include
experiences associated with the use of the health IT in the delivery of
health care, together with administrative functions performed using the
health IT. We proposed that user experiences would also include the
experiences associated with configuring and using the technology
throughout implementation, training, and in practice. Further, we
proposed that user experiences would include patients' and consumers'
user experiences with consumer apps, patient portals, and other
consumer-facing technologies of the health IT developer. We clarified
that a ``relevant user experience'' would include any aspect of the
health IT user experience that could positively or negatively impact
the effectiveness or performance of the health IT.
Comments. One commenter stated that the most relevant aspect of a
user's experience of a health IT system is whether that experience
resulted in patient safety events and requested that ONC specify
patient safety events that arise from the use, misuse, or failure of
health IT systems as ``user experiences'' that cannot be covered by gag
orders.
Response. As previously noted in our response to patient safety
comments above, we reiterate that a user experience resulting in a
patient safety event would be covered under the Communications
Condition of Certification requirements and that a communication about
such an experience would be protected, subject to other applicable
laws. Further, communications about ``adverse events, hazards, and
other unsafe conditions to government agencies, health care
accreditation organizations, and patient safety organizations'' receive
unqualified protection as described in Sec. 170.403(a)(2)(i). We noted
in the Proposed Rule that the Patient Safety and Quality Improvement
Act of 2005 (PSQIA) provides for privilege and confidentiality
protections for information that meets the definition of patient safety
work product (PSWP). This means that PSWP may only be disclosed as
permitted by the PSQIA and its implementing regulations. We clarified
that to the extent activities are conducted in accordance with the
PSQIA, its implementing regulation, and section 4005(c) of the Cures
Act, no such activities shall be construed as constituting restrictions
or prohibitions that contravene this Condition of Certification.
We believe that ``user experience'' was appropriately defined in
the Proposed Rule and have finalized the scope of the protected subject
area ``relevant information regarding users' experiences when using its
health IT'' in Sec. 170.403(a)(1)(iv) as proposed, with the
clarification provided above regarding patient safety events and to
clarify that any communications regarding consumer-facing technologies
would need to be about certified consumer-facing technologies per our
earlier clarification about the scope of this Condition of
Certification being limited to certified health IT.
(E) Manner in Which a User Has Used Health IT
We proposed in 84 FR 7470 that protected communications regarding
the ``manner in which a user has used health IT'' would encompass any
information related to how the health IT has been used. We also
proposed that the terms used to describe the protected subject areas
should be construed broadly. We noted in the Proposed Rule that this
subject area largely overlaps with the matters covered under the ``user
experience'' subject area but may include additional perspectives or
details beyond those experienced by a user of health IT. We proposed
that the types of information that would fall within this subject area
include but are not limited to:
Information about a work-around implemented to overcome an
issue in the health IT;
customizations built on top of core health IT
functionality;
the specific conditions under which a user used the health
IT, such as information about constraints imposed on health IT
functionality due to implementation decisions; and
information about the ways in which health IT could not be
used or did not function as was represented by the developer.
We did not receive comments on this specific aspect of the Proposed
Rule, and we believe the Proposed Rule appropriately outlined what
would fall within the subject matter of the manner in which a user has
used health IT. We have finalized the scope of the protected subject
area ``manner in which a user of the health IT has used such
technology'' in Sec. 170.403(a)(1)(vi) as proposed, with the
clarification that ``used'' refers to any uses of the certified health
IT by the user and is not limited to uses that involve direct patient
care.
(F) Business Practices Related to Exchange
We proposed in 84 FR 7470 that the subject matter of ``business
practices of developers of health IT related to exchanging electronic
health information'' should be broadly construed to include developer
policies and practices that facilitate the exchange of EHI and
developer policies and practices that impact the ability of health IT
to exchange health information. We further proposed that the exchange
of EHI would encompass the appropriate and timely sharing of EHI.
We proposed that protected communications would include, but would
not be limited to:
The costs charged by a developer for products or services
that support the exchange of EHI (e.g., interface costs, API licensing
fees and royalties, maintenance and subscription fees, transaction or
usage-based costs for exchanging information);
[[Page 25727]]
the timeframes and terms on which developers would or
would not enable connections and facilitate exchange with other
technologies, individuals, or entities, including other health IT
developers, exchanges, and networks;
the developer's approach to participation in health
information exchanges and/or networks;
the developer's licensing practices and terms as it
relates to making available APIs and other aspects of its technology
that enable the development and deployment of interoperable products
and services; and
the developer's approach to creating interfaces with
third-party products or services, including whether connections are
treated as ``one off'' customizations, or whether similar types of
connections can be implemented at a reduced cost.
Importantly, we further proposed in 84 FR 7470 that information
regarding ``business practices of developers of health IT related to
exchanging electronic health information'' would include information
about switching costs imposed by a developer, as we are aware that the
cost of switching health IT is a significant factor impacting health
care providers adopting the most exchange-friendly health IT available.
Comments. One commenter stated that our proposed ``business
practices'' is too broadly defined and should relate exclusively to
interoperability elements of certified health IT, rather than to
products and services that support exchange.
Response. As discussed in the Proposed Rule, we believe the term
``business practices of developers of health IT related to exchanging
electronic health information'' should be broadly construed consistent
with our interpretation of the Cures Act language regarding the
Communications Condition of Certification requirements, but limited to
those business practices that relate to the certified health IT as
clarified previously in this Condition and Maintenance of Certification
section. A wide variety of business practices could impact the exchange
of EHI, including developer business strategies, pricing, and even
fraudulent behavior. As such, we have finalized in Sec.
170.403(a)(1)(v) our proposal that such business practices include
developer policies and practices that impact or facilitate the exchange
of EHI. They could also include costs charged by a developer not only
specifically for interoperability elements of the certified health IT,
but also for any products or services that support the exchange of EHI
through the certified health IT. We reiterate that business practices
related to exchange could include timeframes and terms on which
developers facilitate exchange; the developer's approach to
participating in health information exchanges and/or networks; the
developer's licensing practices and terms as related to APIs and other
interoperable services; and the developer's approach to creating
interfaces with third-party services. As proposed in 84 FR 7473, this
Communications Condition of Certification requirement will also apply
to any communication concerning a Program requirement (e.g., a
Condition or Maintenance of Certification requirement) related to the
exchange of EHI or the information blocking provision.
Comments. Several commenters had concerns regarding communications
about prices and costs, with some commenters asserting that such
communications should be protected and some others asserting that
developers should be able to restrict communications about prices and
costs, including switching costs. Additionally, one commenter had
concerns about protecting communications regarding timeframes and terms
as well as workarounds and customizations. One commenter also
recommended that ONC seek guidance from the Antitrust Division of the
FTC regarding economic impacts of regulating health IT developer terms,
prices, and timeframes.
Response. We continue to interpret costs, information regarding
timeframes and terms, and information about health IT workarounds and
customizations as protected communications under the ``Business
Practices Related to Exchange'' provision of this condition. We believe
that this type of information is frequently relied upon and necessary
in order to optimize health IT for the exchange of EHI. We emphasize
that the costs charged by a developer for certified health IT or
related services that support the exchange of EHI are significant
factors that can impact the adoption of interoperable certified health
IT and should be protected communications. For example, pricing could
include prohibitive costs that prevent or discourage customers from
using certified health IT to interact with competing technologies.
Likewise, information regarding timeframes and terms is the type of
information considered and relied upon in the adoption of interoperable
certified health IT and is a protected communication. We have also
finalized in Sec. 170.403(a)(1)(vi) that information about certified
health IT workarounds and customizations relates to important aspects
of how a user has used certified health IT, including how the certified
health IT can be used to achieve greater interoperability, and is a
protected communication.
In response to the comments recommending that we seek guidance from
the FTC, we note that we are not regulating health IT developer terms,
prices, and timeframes under this Communications Condition of
Certification requirements, and therefore do not need to seek further
guidance. Rather, the Communications Condition of Certification
requirements would protect communications about health IT developer
costs, terms, and timeframes as described above and ensure that such
information could be shared. We have finalized the scope of the
protected subject area ``business practices of developers of health IT
related to exchanging electronic health information'' in Sec.
170.403(a)(1)(v) as proposed.
iii. Meaning of ``Prohibit or Restrict''
The terms ``prohibit'' and ``restrict'' are not defined in the
Cures Act, nor in any other relevant statutory provisions. We discussed
in the Proposed Rule that communications can be prohibited or
restricted through contractual terms or agreements (e.g., non-
disclosure agreements or non-disparagement clauses) as well as through
conduct, including punitive or retaliatory business practices that are
designed to create powerful disincentives to engaging in communications
about developers or their health IT. Therefore, we proposed in 84 FR
7470 that the Communications Condition of Certification requirements
would not be limited to only formal prohibitions or restrictions (such
as by means of contracts or agreements) and would encompass any conduct
by a developer that would be likely to restrict a communication or
class of communications protected by the Communications Condition of
Certification requirements. We explained that the conduct in question
must have some nexus to the making of a protected communication or an
attempted or contemplated protected communication.
(A) Prohibitions or Restrictions Arising by Way of Contract
We explained in the Proposed Rule that the principal way that
health IT developers can control the disclosure of information about
their health IT is through contractual prohibitions or restrictions. We
noted that there are different ways that contractual prohibitions or
restrictions arise. In some instances, a contractual prohibition or
restriction will be
[[Page 25728]]
expressed, and the precise nature and scope of the prohibition or
restriction will be explicit in the contract or agreement. However, we
also noted that a contract may also impose prohibitions or restrictions
in less precise terms. We stated that a contract does not need to
expressly prohibit or restrict a protected communication in order to
have the effect of prohibiting or restricting that protected
communication. The use of broad or vague language that obfuscates the
types of communications that can and cannot be made may be treated as a
prohibition or restriction if it has the effect of restricting
legitimate communications about health IT.
We stated that restrictions and prohibitions found in contracts
used by developers to sell or license their health IT can apply to
customers directly and can require that the customer ``flow-down''
obligations to the customer's employees, contractors, and other
individuals or entities that use or work with the developer's health
IT. We proposed that such contract provisions would not comply with the
Communications Condition of Certification requirements and would be
treated as prohibiting or restricting protected communications. We
noted that prohibitions or restrictions on communications can also be
found in separate nondisclosure agreements (NDAs) that developers
require their customers--and in some instances the users of the health
IT or third-party contractors--to enter into in order to receive or
access the health IT. We proposed that such agreements are covered by
the Communications Condition of Certification requirements.
We did not receive comments on this specific aspect of the Proposed
Rule and have finalized our interpretation proposed in FR 7471
regarding prohibitions or restrictions arising by way of contract as
stated above.
(B) Prohibitions or Restrictions That Arise by Way of Conduct
We proposed in 84 FR 7471 that conduct that has the effect of
prohibiting or restricting a protected communication would be subject
to the Communications Condition of Certification requirements. We
emphasized that the conduct in question must have some nexus to the
making of a protected communication or an attempted or contemplated
protected communication. As such, developer conduct that was alleged to
be intimidating, or health IT performance that was perceived to be
substandard, would not, in and of itself, implicate the Communications
Condition of Certification requirements unless there was some nexus
between the conduct or performance issue and the making of (or
attempting or threatening to make) a protected communication.
We did not receive comments on this specific aspect of the Proposed
Rule and have finalized our interpretation proposed in 84 FR 7471
regarding prohibitions or restrictions arising by way of conduct as
stated above.
iv. Communications With Unqualified Protection
We proposed in 84 FR 7472 a narrow class of communications--
consisting of five specific types of communications--that would receive
unqualified protection from developer prohibitions or restrictions.
With respect to communications with unqualified protection, a developer
would be prohibited from imposing any prohibition or restriction. We
proposed that this narrow class of communications warrants unqualified
protection because of the strength of the public policy interest being
advanced by the class of the communication and/or the sensitivity with
which the identified recipient treats, and implements safeguards to
protect the confidentiality and security of, the information received.
We stated that a developer that imposes a prohibition or restriction on
a communication with unqualified protection would fail the first part
of the two-part test for allowable prohibitions or restrictions, and as
such would contravene the Communications Condition of Certification
requirements.
Comments. One commenter recommended adding language specifying the
types of entities that can receive communications with unqualified
protection, noting that such specificity would help ensure that these
communications go to the appropriate entities so that they can be
addressed quickly. The commenter recommended that provisions around
reporting to government entities should be limited to United States
government entities.
Response. We do not believe it is necessary to further specify the
types of entities that can receive communications with unqualified
protection. We intend for this protection to cover a wide variety of
organizations, and further specifying the types of entities that can
receive such communications, such as limiting communication to only
United States government entities, would unnecessarily limit the scope
of this protection and could be counter to the public policy interest
to advance the ability of these communications to occur unencumbered.
We have finalized in Sec. 170.403(a)(2)(i) our proposal to prohibit
developers from imposing any prohibition or restriction on
communications that fall into a narrow class of communications--
consisting of the five specific types of communications described
below--that would receive unqualified protection.
(A) Disclosures Required by Law
We proposed in 84 FR 7472 that where a communication relates to
subject areas enumerated in proposed Sec. 170.403(a)(1) and there are
Federal, State, or local laws that would require the disclosure of
information related to health IT, developers must not prohibit or
restrict in any way protected communications made in compliance with
those laws. We noted that we expect most health IT contracts would
allow for, or not prohibit or restrict, any communication or disclosure
that is required by law, such as responding to a court or Congressional
subpoena, or a valid warrant presented by law enforcement. We further
proposed that if required by law, a potential communicator should not
have to delay any protected communication under the Communications
Condition of Certification requirements.
We did not receive comments on this aspect of the Proposed Rule and
have finalized in Sec. 170.403(a)(2)(i)(A) our approach regarding
disclosures required by law as proposed.
(B) Communicating Information About Adverse Events, Hazards, and Other
Unsafe Conditions to Government Agencies, Health Care Accreditation
Organizations, and Patient Safety Organizations
We proposed in 84 FR 7472 that there is an overwhelming interest in
ensuring that all communications about health IT that are necessary to
identify patient safety risks, and to make health IT safer, not be
encumbered by prohibitions or restrictions imposed by health IT
developers that may affect the extent or timeliness of communications.
In addition to the public policy interest in promoting uninhibited
communications about health IT safety, we proposed that the recognized
communication channels for adverse events, hazards, and unsafe
conditions provide protections that help ensure that any disclosures
made are appropriately handled and kept confidential and secure. We
proposed that the class of recipients to which the information can be
communicated under this specific category of communications given
unqualified protection should provide health IT developers with comfort
that there is little risk of such communications prejudicing the
developer's IP rights.
[[Page 25729]]
We sought comment on whether the unqualified protection afforded to
communications made to a patient safety organization about adverse
events, hazards, and other unsafe conditions should be limited.
Specifically, we sought comment on whether the unqualified protection
should be limited by the nature of the patient safety organization to
which a communication can be made, or the nature of the communication
that can made.
Comments. Several commenters stated that ONC should not place any
limits on the unqualified protection afforded to communications made to
patient safety organizations about adverse events, hazards, and other
unsafe conditions.
Response. We have finalized in Sec. 170.403(a)(2)(i)(B) as
proposed regarding the unqualified protection afforded to
communications about adverse events, hazards, and other unsafe
conditions that are made to government agencies, health care
accreditation organizations, and patient safety organizations.
Additionally, we placed no limits or qualifiers on such communications,
including those communications made to patient safety organizations.
(C) Communicating Information About Cybersecurity Threats and Incidents
to Government Agencies
We proposed in 84 FR 7472 that if health IT developers were to
impose prohibitions or restrictions on the ability of any person or
entity to communicate information about cybersecurity threats and
incidents to government agencies, such conduct would not comply with
the Communications Condition of Certification requirements.
We sought comment on whether it would be reasonable to permit
health IT developers to impose limited restrictions on communications
about security issues to safeguard the confidentiality, integrity, and
security of EHI. In the Proposed Rule, we asked if, for example, health
IT developers should be permitted to require that health IT users
notify the developer about the existence of a security vulnerability
prior to, or simultaneously with, any communication about the issue to
a government agency.
Comments. Some commenters stated that users should never be
required to notify the developer when reporting cybersecurity issues,
as this would impose a burden on the user and a potential barrier to
reporting. Other commenters recommended that developers should be
allowed to require users to notify them simultaneously or prior to
reporting such incidents, with one comment noting that this would
enable developers to better address and respond to security threats
prior to the knowledge of a threat becoming widespread. Some commenters
recommended that ONC make it a violation for developers to not share
cybersecurity vulnerabilities with providers, and that ONC work with
DHS to mitigate issues around sharing such vulnerabilities. One
commenter recommended changing the wording regarding communicating
cybersecurity and security risks to include known vulnerabilities and
health IT defects.
Response. We strongly encourage users of health IT to notify
developers as soon as possible when reporting security incidents and
issues. However, it would not be appropriate to require this practice,
which would impose an obligation on users of health IT that is outside
the scope of this rule. It would also be outside the scope of this
condition to implement additional requirements for developers regarding
the sharing of cybersecurity vulnerabilities with health care
providers. To be clear, we expect developers with Health IT Modules
certified under the Program to share information about cybersecurity
vulnerabilities with health care providers and other affected users as
soon as feasible, so that these affected users can take appropriate
steps to mitigate the impact of these vulnerabilities on the security
of EHI and other PII in the users' systems. Thus, we have finalized the
Communications Condition of Certification requirements in Sec.
170.403(a)(2)(i)(C) as proposed. Developers must not place restrictions
on communications receiving unqualified protections. We also clarify
that known vulnerabilities and health IT defects would likely be
considered types of ``adverse events, hazards, and other unsafe
conditions'' that would receive ``unqualified protection,'' and thus a
developer would not be able to restrict a health IT user from
communicating about such issues in communications receiving unqualified
protections under the Communications Condition of Certification
requirements (see Sec. 170.403(a)(2)(i) as finalized). However, we
note that in communications not receiving unqualified protection under
the Communications Condition of Certification requirements, a security
vulnerability that is not already public knowledge would be considered
a non-user-facing aspect of health IT, about which developers are
permitted to restrict communications (see Sec. 170.403(a)(2)(ii)(B) as
finalized). Last, we note that we will continue to work with our
Federal partners to mitigate and address cybersecurity threats and
incidents.
(D) Communicating Information About Information Blocking and Other
Unlawful Practices to a Government Agency
We proposed in 84 FR 7473 that the public benefit associated with
the communication of information to government agencies on information
blocking, or any other unlawful practice, outweighs any concerns
developers might have about the disclosure of information about their
health IT. We noted that reporting information blocking, as well as
other unlawful practices, to a government agency would not cause an
undue threat to a health IT developer's IP.
Comments. We received several comments regarding the lack of
whistleblower protections in the Proposed Rule for individuals who
report information blocking or other issues regarding certified health
IT. These comments discussed the need to provide for whistleblower type
protections for individuals who highlight information blocking
practices, as well as to identify them to the appropriate authorities
so that the individual is not subject to retaliatory action by the
actor identified by the whistleblower.
Response. We appreciate these comments and agree that it is
extremely important for individuals to be able to report information
blocking and violations of other Conditions of Certification without
fear of retaliation. We note that the Communications Condition of
Certification requirements provide protections against retaliation and
intimidation by developers with respect to protected communications. We
discussed in the Proposed Rule that the Communications Condition of
Certification requirements cover communications that are prohibited or
restricted through contractual terms or agreements (e.g., non-
disclosure agreements, non-disparagement clauses) between the health IT
developer, or offeror of health IT, and the communicator, as well as
through conduct, including punitive or retaliatory business practices
that are designed to create powerful disincentives to engaging in
communications about developers or their health IT. We clarify,
however, that merely filing a lawsuit against the communicator
regarding the making of
[[Page 25730]]
a communication would not be considered intimidating conduct in
violation of this Condition. Any such determination would necessarily
be fact-specific, and the health IT developer's lawsuit would have to
be designed to intimidate a communicator in order to prevent or
discourage that communicator from making a protected communication,
rather than be designed to pursue a legitimate legal interest. We
believe that the proposed broad interpretation of ``prohibit'' and
``restrict'' is appropriate given the intention of the Cures Act, which
placed no limitations on the protection of communications about the
protected subject areas. We finalized this interpretation of
``prohibit'' and ``restrict'' proposed in 84 FR 7470 and believe that
the interpretation would provide significant protections for
whistleblowers from retaliatory actions. Thus, retaliatory actions by a
developer against a whistleblower would be in violation of this
provision. We also emphasize that conduct by a developer that may be
perceived as intimidating or punitive would not implicate the
Communications Condition of Certification requirements unless that
conduct was specifically designed to influence the making of a
protected communication. In other words, punitive actions must have a
nexus to the making of a protected communication, such as retaliation
for reporting of information blocking, in order to violate the
Communications Condition of Certification requirements in Sec.
170.403(a)(1). Last, we refer readers to the discussion of
``complaints'' under the information blocking section of this final
rule, which details the confidentiality provided to information
blocking complaints and complainants.
We have finalized the Communications Condition of Certification
requirements in Sec. 170.403(a)(2)(i)(D) as proposed.
(E) Communicating Information About a Health IT Developer's Failure To
Comply With a Condition of Certification or Other Program Requirement
We proposed in 84 FR 7473 that the benefits to the public and to
users of health IT of communicating information about a health IT
developer's failure to comply with a Condition of Certification
requirement or other Program requirement (45 CFR part 170) justify
prohibiting developers of health IT from placing any restrictions on
such protected communications. We explained that information regarding
the failure of certified health IT to meet any Condition of
Certification requirement or other Program requirement is vital to the
effective performance and integrity of the Program. Moreover, the
failure of a certified health IT to meet such requirements could impact
the performance of the certified health IT with respect to usability,
safety, and interoperability. We stated that it is important to enable
unencumbered reporting of such information and that such reporting is
essential to the transparency that section 4002 of the Cures Act seeks
to ensure. While the current procedures for reporting issues with
certified health IT encourage providers to contact developers in the
first instance to address certification issues, we noted that users of
health IT should not hesitate to contact ONC-Authorized Certification
Bodies (ONC-ACBs), or ONC itself, if the developer does not provide an
appropriate response, or the matter is of a nature that should be
immediately reported to an ONC-ACB or to ONC.
We did not receive any comments on this aspect of the Proposed
Rule. In consideration of the above, we have finalized this provision
in Sec. 170.403(a)(2)(i)(E) as proposed.
v. Permitted Prohibitions and Restrictions
We proposed in 84 FR 7473 that, except for communications with
unqualified protection (Sec. 170.403(a)(2)(i)), health IT developers
would be permitted to impose certain narrow prohibitions and
restrictions on communications. Specifically, we proposed that, with
the exception of communications with unqualified protection, developers
would be permitted to prohibit or restrict the following
communications, subject to certain conditions:
Communications of their own employees;
Disclosure of non-user-facing aspects of the software;
Certain communications that would infringe the developer's
or another person's IP rights;
Publication of screenshots in narrow circumstances; and
Communications of information that a person or entity
knows only because of their participation in developer-led health IT
development and testing.
The proposed Communications Condition of Certification requirements
delineated the circumstances under which these types of prohibitions
and restrictions would be permitted, including certain associated
conditions that developers would be required to meet. We emphasized
that any prohibition or restriction not expressly permitted would
violate the Communications Condition of Certification requirements.
Additionally, we proposed that it would be the developer's burden to
demonstrate to the satisfaction of ONC that the developer met all
associated requirements. Further, as an additional safeguard, we
proposed that where a developer sought to avail itself of one of the
permitted types of prohibitions or restrictions, the developer must
ensure that potential communicators are clearly and explicitly notified
about the information and material that can be communicated, and that
which cannot. We proposed this would mean that the language of health
IT contracts must be precise and specific. We stressed that contractual
provisions or public statements that support a permitted prohibition or
restriction on communication should be specific about the rights and
obligations of the potential communicator. We explained that contract
terms that are vague and cannot be readily understood by a reasonable
health IT customer would not benefit from the qualifications to this
Condition of Certification requirement as outlined in the Proposed Rule
and below.
(A) Developer Employees and Contractors
We recognized in the Proposed Rule in 84 FR 7473 that health IT
developer employees, together with the entities and individuals who are
contracted by health IT developers to deliver products and/or services
(such as consultants), may be exposed to highly sensitive, proprietary,
and valuable information in the course of performing their duties. We
also stated that we recognize that an employer should have the ability
to determine how and when the organization communicates information to
the public, and that employees owe confidentiality obligations to their
employers. We noted that this would similarly apply to contractors of a
developer. We proposed in 84 FR 7473 that on this basis, developers
would be permitted to impose prohibitions or restrictions on the
communications of employees and contractors to the extent that those
communications fall outside of the class of communications with
unqualified protection as discussed above.
Comments. One commenter stated that this provision should be
clarified and expanded to cover other third parties with whom the
health IT developer shares its confidential information, including
subcontractors, agents, auditors, suppliers, partners, co-sellers, and
re-sellers, as well as
[[Page 25731]]
potential relationships for which a contract has not yet been signed in
case information is shared during a pre-contract evaluation stage.
Response. We reiterate that ``developer employees and contractors''
include health IT developer employees, together with the entities and
individuals who are contracted by health IT developers to deliver
health IT and/or services who may be exposed to highly sensitive,
proprietary, and valuable information in the course of performing their
duties. This functional description of employees and contractors could
include subcontractors, agents, auditors, suppliers, partners, co-
sellers, and re-sellers, depending on the specific relationship and
circumstances. We have finalized the proposed approach to describing
employees and contractors in Sec. 170.403(a)(2)(ii)(A). We note that
we did not expand this description to include ``potential
relationships'' because such an addition would make the description
overly broad, and it is unlikely that individuals who are not yet under
contract would be exposed to highly sensitive, proprietary, and
valuable information.
Comments. We received one comment that self-developers should not
be permitted to place restrictions on the communications of their
employees who are using their certified health IT.
Response. We agree that self-developers should not be allowed to
restrict the communications of users of their certified health IT who
are also employees or contractors. We have revised Sec.
170.403(a)(2)(ii)(A) to clarify that the limited prohibitions
developers may place on their employees or contractors under the
Communications Condition of Certification requirements cannot be placed
on users of a self-developer's certified health IT who are also
employees or contractors of the self-developer. For example, a large
health system with a self-developed EHR cannot restrict a health care
provider, who is employed by that health system and using that EHR to
provide services, from communicating about the EHR as a user based on
the fact that the health care provider is also an employee of the
health system. We note that the concept of ``self-developed'' refers to
a Complete EHR or Health IT Module designed, created, or modified by an
entity that assumed the total costs for testing and certification and
that will be the primary user of the health IT (76 FR 1300).
(B) Non-User-Facing Aspects of Health IT
We proposed in 84 FR 7474 that the Communications Condition of
Certification requirements would permit health IT developers to impose
prohibitions and restrictions on communications to the extent necessary
to ensure that communications do not disclose ``non-user-facing aspects
of health IT.'' We noted that, like all permitted prohibitions, such
prohibitions and restrictions could only be put in place by developers
if there is not an unqualified protection that applies. We proposed in
84 FR 7474 that a ``non-user-facing aspect of health IT,'' for the
purpose of this Condition of Certification, was an aspect of health IT
that is not a ``user-facing aspect of health IT.'' We stated that
``user-facing aspects of health IT'' would include the design concepts
and functionality that is readily ascertainable from the health IT's
user interface and screen display. We stated that they did not include
those parts of the health IT that are not exposed to persons running,
using, or observing the operation of the health IT and that are not
readily ascertainable from the health IT's user interface and screen
display, all of which would be considered ``non-user-facing'' concepts.
We proposed in 84 FR 7474 that ``non-user-facing aspects of health IT''
would include source and object code, software documentation, design
specifications, flowcharts, and file and data formats. We welcomed
comments on whether these and other aspects of health IT should or
should not be treated as user-facing.
In the Proposed Rule, we noted that the terminology of ``non-user-
facing aspects of health IT'' is not intended to afford only health IT
users with specific protections against developer prohibitions or
restrictions on communications and is agnostic as to the identity of
the communicator.
Comments. Some commenters expressed concern regarding the broad
scope of ``user-facing'' and, by extension, the scope of ``non-user-
facing.'' One commenter asked for clarification regarding the
definition of ``software documentation'' with regards to non-user-
facing aspects of health IT and suggested that it applies to
documentation that is for back-end components, not documents for
normal-end use. Additionally, a couple of comments stated that
administrative functions should not be considered user-facing,
including one comment that the relevant users for the purpose of the
Communications Condition of Certification requirements are ``end''
users, thus the non-user-facing provision should apply only to ``non-
end-user-facing'' aspects of health IT. Some commenters emphasized that
administrative portions of health IT contain more insight into health
IT systems and that administrative functions affect a limited number of
users and are not the types of communications or subject matters
contemplated by the Cures Act. One commenter stated that algorithms
should be considered non-user-facing. Another commenter stated that ONC
should clarify the status of diagrams and flowcharts.
Response. We do not see a necessary or appreciable distinction
between ``users'' and ``end users,'' as we have focused on the aspects
of the health IT that are and are not subject to protected
communications under this Condition of Certification. We also believe
that there could be unintended consequences with the term ``end user,''
such as limiting certain users not specified under the ``permitted
prohibitions and restrictions'' (e.g., developer employees and
contractors) from making protected communications. Therefore, we
believe ``non-user-facing'' best reflects the scope of the
communications about health IT we seek to capture with these terms.
We reiterate that ``non-user-facing aspects of health IT'' comprise
those aspects of the health IT that are not readily apparent to someone
interacting with the health IT as a user of the health IT, including
source and object code, certain software documentation, design
specifications, flowcharts, and file and data formats. We clarify that
``non-user-facing aspects of health IT'' would also include underlying
software that is utilized by the health IT in the background and not
directly by a user of the health IT. For example, the programming
instructions for proprietary APIs would be considered non-user-facing
because they are not readily apparent to the individual users of the
health IT. In addition, underlying database software that connects to
health IT and is used to store data would be considered a non-user-
facing aspect of health IT because it serves data to the health IT, not
directly to a user.
We further clarify that algorithms would be considered ``non-user-
facing aspects of health IT'' as they are not readily apparent to
persons using health IT for the purpose for which it was purchased or
obtained. Thus, communications regarding algorithms (e.g., mathematical
methods and logic) could be restricted or prohibited, while
communications regarding the output of the algorithm and how it is
displayed in
[[Page 25732]]
a health IT system could not be restricted as ``non-user-facing aspects
of health IT.'' Similarly, we also clarify that certain ``software
documentation'' that would be considered to be a non-user-facing aspect
of health IT would include documentation for back-end components, again
because it is not readily apparent to persons using health IT.
Whether or not a communication would be considered a ``non-user-
facing aspects of health IT'' would be based on whether the
communication involved aspects of health IT that would be evident to
anyone running, using, or observing the operation of the health IT for
the purpose for which it was purchased or obtained. With respect to
administrative functions, where the communication at issue relates to
aspects of the health IT that are not observable by users of the health
IT, it would be considered ``non-user-facing'' for the purpose of this
Condition of Certification requirement. For example, a communication
regarding an input process delay experienced by an administrator of
health IT that was caused by the underlying database software could be
restricted if the communication discussed the underlying database
software, which would be considered a non-user-facing aspect of the
health IT. However, if the communication discussed the user screens and
the delay experienced by the administrator, which would be considered
user-facing aspects of health IT, it could not be restricted.
Similarly, as long as diagrams or flowcharts do not include aspects of
the health IT that are observable by users of the health IT, as
described above, they would be considered communications about non-
user-facing aspects of health IT.
We have finalized in Sec. 170.403(a)(2)(ii)(B) our proposed
approach to the scope of ``non-user-facing aspects of health IT'' with
the clarification provided above regarding scope.
(C) Intellectual Property
We proposed in 84 FR 7474 that the Communications Condition of
Certification requirements are not intended to operate as a de facto
license for health IT users and others to act in a way that might
infringe the legitimate IP rights of health IT developers or other
persons. Indeed, we proposed in 84 FR 7474 that health IT developers
are permitted to prohibit or restrict certain communications that would
infringe their IP rights so long as the communication in question is
not a communication with unqualified protection. We proposed in 84 FR
7474 that any prohibition or restriction imposed by a developer must be
no broader than legally permissible and reasonably necessary to protect
the developer's legitimate IP interests. We also proposed in 84 FR 7474
that health IT developers are not permitted to prohibit or restrict, or
purport to prohibit or restrict, communications that would be a ``fair
use'' of any copyright work comprised in the developer's health IT.\86\
``Fair use'' is a legal doctrine that allows for the unlicensed use of
copyright material in certain circumstances, which could include
circumstances involving criticism, commentary, news reporting, and
research.\87\
---------------------------------------------------------------------------
\86\ See 17 U.S.C. 107 (setting forth the four factors required
to evaluate a question of fair use under the statutory framework).
\87\ See https://www.copyright.gov/fair-use/more-info.html for
more information on fair use.
---------------------------------------------------------------------------
Comments. One commenter stated that fair use should not override
other IP protections and stressed that relying on fair use could lead
to uncertainty because it is determined on a case-by-case basis.
Another commenter stated that because the fair use doctrine can be
difficult to implement and can lead to uncertain results, ONC should
expand the list of communications that would be explicitly protected as
fair use to include news reporting, criticism, parody, and
communications for educational purposes.
Response. We disagree with commenters and believe that relying on
the ``fair use'' doctrine for determining when a screenshot or other
communication cannot be restricted should be allowed under the
Communications Condition of Certification requirements. This doctrine
presents a framework of analysis that is well-developed in case law and
thus can be interpreted and applied consistently, even when materials
are not formally copyrighted. Accordingly, we are retaining the concept
of ``fair use'' in the final provision in Sec. 170.403(a)(2)(ii)(C).
Developers and ONC will apply a fair use test to copyrighted materials
and, by analogy, to materials that could be copyrighted, to determine
whether developers may prohibit a communication that would infringe on
IP rights.
The Communication Condition of Certification requirements relate
only to protected communications, thus developers can place
restrictions on communications about subject matters outside of the
protected communications categories without implicating the
Communications Condition of Certification requirements. Also, as
discussed earlier regarding developer employees and contractors in
Sec. 170.403(a)(2)(ii)(A), developers may restrict communications by
their employees, contractors, and consultants without implicating the
Communications Condition of Certification requirements, provided they
do not restrict communications with unqualified protections. Further,
as described earlier regarding non-user-facing aspects of certified
health IT in Sec. 170.403(a)(2)(ii)(B), developers may restrict
communications that disclose non-user-facing aspects of the developer's
certified health IT, provided they do not restrict communications with
unqualified protections. We clarified in that section that screenshots
or videos depicting source code would be considered communications of
non-user-facing aspects of health IT and could be restricted under the
Communications Condition of Certification requirements as long as they
did not receive unqualified protection. We also clarify that this
Condition does not prohibit health IT developers from enforcing their
IP rights and that a lawsuit filed by a health IT developer in response
to a protected communication regarding infringement of IP rights would
not automatically be considered intimidation or retaliation in
violation of this Condition.
As discussed later in the pre-market testing and development
section in Sec. 170.403(a)(2)(ii)(E), developers can place
restrictions on communications related to pre-market health IT
development and testing activities, which could include IP protections,
provided they do not restrict communications with unqualified
protections. Combined, these avenues allow for protecting IP in ways
that would not implicate the Communications Condition of Certification
requirements, thereby allowing developers to take a number of actions
to protect and safeguard IP in their certified health IT.
Comments. Several commenters requested clarity regarding how the
proposed protections for IP would work. One commenter stated that the
rule must allow developers to protect legitimate IP interests and asked
for clarity on how ONC would determine whether a developer's
restriction on the communication of a screenshot was an allowable
protection of trade secrets or an impermissible restriction of
protected communications. Several other commenters, who generally
supported the Communications Condition of Certification requirements,
requested clarification regarding how a
[[Page 25733]]
prohibition on communications that is designed to protect IP can be
applied. Some commenters requested examples of the types of
communications that can be restricted on the basis of IP and
clarification of the standard ONC will use to determine what
prohibitions are permissible.
Response. We have finalized an approach in Sec.
170.403(a)(2)(ii)(C) that allows developers to prohibit or restrict
communications that involve the use or disclosure of intellectual
property existing in the developer's health IT (including third-party
intellectual property), provided that any prohibition or restriction
imposed by a developer must be no broader than necessary to protect the
developer's legitimate intellectual property interests and consistent
with all other requirements under the ``permitted prohibitions and
restrictions'' (Sec. 170.403(a)(2)(ii)) of this section. As discussed
above, a restriction or prohibition would be deemed broader than
necessary and inconsistent with the ``permitted prohibitions and
restrictions'' (Sec. 170.403(a)(2)(ii)) if it would restrict or
preclude a public display of a portion of a work subject to copyright
protection (without regard to whether the copyright is registered) that
would reasonably constitute a ``fair use'' of that work.
Examples of the types of communications that could be restricted
under the Communications Condition of Certification requirements might
include a blog post describing a customization of a developer's health
IT that includes the source code of the developer's health IT or a
written review of an analytical feature of the developer's health IT
that reveals the algorithms used. However, as mentioned above, the
restriction must be no broader than necessary to protect the
developer's legitimate IP interests, thus only the infringing portions
of the communications could be restricted.
Comments. One commenter recommended that a health IT developer must
demonstrate that a communication was specifically designed to copy or
steal a developer's IP in order for the developer to be allowed to
prohibit the communication as an infringement on their IP rights.
Response. We appreciate this comment, but decline to require that a
developer demonstrate that a communication was designed to copy or
steal IP in order for the developer to restrict the communication as
one that would infringe on IP rights. We believe that the revised
approach discussed above provides appropriate balance between
protecting IP rights and enabling protected communications and do not
believe that an ``intent'' element would be necessary. We have
finalized the proposals regarding IP in Sec. 170.403(a)(2)(ii)(C), as
amended above.
(D) Faithful Reproductions of Health IT Screenshots
We proposed in 84 FR 7475 that health IT developers generally would
not be permitted to prohibit or restrict communications that disclose
screenshots of the developer's health IT. We proposed that the
reproduction of screenshots in connection with the making of a
communication protected by this Condition of Certification would
ordinarily represent a ``fair use'' of any copyright subsisting in the
screen display, and developers should not impose prohibitions or
restrictions that would limit that fair use. Notwithstanding this, we
proposed that health IT developers would be allowed to place certain
restrictions of the disclosure of screenshots as specified in proposed
Sec. 170.403(a)(2)(ii)(D).
With respect to the limited allowable restrictions on screenshots,
we proposed in 84 FR 7475 that developers would be permitted to prevent
communicators from altering screenshots, other than to annotate the
screenshot or to resize it for the purpose of publication. We also
proposed that health IT developers could impose restrictions on the
disclosure of a screenshot on the basis that it would infringe third-
party IP rights (on their behalf or as required by license). However,
to take advantage of this exception, we proposed in 84 FR 7475 that the
developer would need to first put all potential communicators on
sufficient written notice of those parts of the screen display that
contain IP and cannot be communicated, and would still need to allow
communicators to communicate redacted versions of screenshots that do
not reproduce those parts. Finally, we proposed in 84 FR 7475 that it
would be reasonable for developers to impose restrictions on the
communication of screenshots that contain PHI, provided that developers
permit the communication of screenshots that have been redacted to
conceal PHI, or where the relevant individual's consent or
authorization had been obtained.
We welcomed comments on whether an appropriate balance had been
struck between protecting legitimate IP rights of developers and
ensuring that health IT customers, users, researchers, and other
stakeholders who use and work with health IT can openly discuss and
share their experiences and other relevant information about the
performance of health IT.
Comments. A large number of commenters, particularly health care
providers, supported our proposals regarding the communication of
screenshots, with several stressing how helpful screenshots are when
communicating usability and safety issues with health IT. One commenter
noted that communication of screenshots can help different health care
systems understand whether a proposed implementation of an EHR has
introduced safety-related challenges at other locations, or help
identify solutions to common problems, such as usability challenges.
One other commenter stated that there is nothing novel displayed in
health IT screenshots that would need to be protected.
Response. We appreciate the many positive comments on our proposals
regarding screenshots.
Comments. Commenters stated that the scope of protected
communications as proposed should exclude disclosure of the health IT
itself, such as through screenshots. The commenter stressed that the
Cures Act required that health IT developers not restrict
communications about the certified health IT with respect to specific
topic areas, while the Proposed Rule expands that restriction to
include communication of the health IT itself. One commenter noted that
the Cures Act does not mention screenshots and they should not be
included in the Communications Condition of Certification requirements.
Response. The Cures Act amended title XXX of the PHSA to establish
this condition of certification, which applies to ``health information
technology.'' Title XXX of the PHSA was previously added by the HITECH
Act, which included the definition of ``health information
technology.'' Section 3000(5) of the PHSA defines health information
technology to mean hardware, software, integrated technologies or
related licenses, IP, upgrades, or packaged solutions sold as services
that are designed for or support the use by health care entities or
patients for the electronic creation, maintenance, access, or exchange
of health information. We emphasize both that this definition includes
IP associated with the health information technology and that it
applies to this condition of certification as this condition references
communications regarding health information technology. We have also
adopted this definition in Sec. 170.102.
We disagree with the commenters' interpretation of the statutory
provision. The statutory provision focuses on ``communications''
regarding
[[Page 25734]]
enumerated aspects of the health IT. Communications are not defined nor
limited in the Cures Act, and we proposed to broadly define them.
Verbal, written, and visual, as well other types of communications, are
all covered under the Cures Act. A screenshot is a copy/picture of the
user interface of the health IT, or a ``visual communication'' that is
protected under this condition of certification. We have specifically
defined ``communication'' for this section in Sec. 170.403(c) to mean
any communication, irrespective of the form or medium. The term
includes visual communications, such as screenshots and video.
As we emphasized in the Proposed Rule in 84 FR 7475, the sharing of
screenshots (with accompanying annotation and/or explanatory prose) is
often a critical form of communication of issues with health IT related
to--for example--usability, user experience, interoperability,
security, or the way the technology is used. We believe screenshots are
uniquely helpful as a form of visual communication that can non-
verbally illustrate the ``user's experiences when using the health
information technology'' and the ``manner in which a user of the health
information technology has used such technology'' as they relate
intrinsically to both subject areas and capture those user experiences
immediately and directly. Further, enabling screenshot sharing can
allow for clearer, more immediate, and more precise communication on
these pertinent issues, potentially helping a health system avoid
costly, or even deadly, complications when implementing health IT. It
is also our understanding that screenshots are often the only recourse
a user in a network enterprise system has for capturing, documenting,
and explaining their concerns. We clarify, however, that the sharing of
a screenshot alone would not be considered a protected communication as
it would need to be accompanied by an explanation of the issues or
aspects of the health IT that the screenshot is meant to communicate or
illustrate.
Considering the value of communicating significant issues regarding
health IT through screenshots, we have finalized our proposal to
include screenshots as a protected communications under the Cures Act.
However, as discussed in responses to other comments below, we have
revised our final policy in multiple ways.
Comments. One commenter recommended that screenshots should be
defined broadly to include video and other media that can be helpful in
demonstrating challenges with EHRs.
Response. We agree with the recommendation that protections
afforded to screenshots should extend to video. We clarify that, like
screenshots, video is considered a form of visual communication. A
video of a computer screen while a software program is in operation
would capture the user experience of interacting with that program and
essentially would show a number of screenshots from that program in
rapid succession. We emphasize that video, similarly to individual
screenshots, is a critical form of communication of issues with the
health IT, including issues related to usability, user experience,
interoperability, security, or the way the technology is used.
As with screenshots, video is particularly useful in communicating
a user's experience with health IT and the manner in which the user has
used health IT. This is especially the case when issues of a temporal
nature are involved. For example, video would be essential for
illustrating a latency issue experienced during drug ordering that
could not be communicated through screenshots or other forms of
communication. Video also could be critical to demonstrating an issue
with a clinical decision support alert that is designed to
appropriately and timely notify the provider of a patient matter but
fails to do so.
Comments. Several commenters expressed concern regarding how a
developer's IP may be impacted by the proposed Communications Condition
of Certification requirements. Several commenters stated that the
Proposed Rule goes beyond protecting communications for the purposes of
patient safety and system improvement and would enable or require
inappropriate sharing and disclosure of IP, potentially creating
security risks, increased IP theft, and harming innovation and the
marketplace for health IT. Several commenters stated that trade
secrets, patent protections, and protections for confidential and
proprietary information were not addressed or considered appropriately
in the Proposed Rule, and that as a result it would be possible for bad
actors to create pirated health IT based on the disclosure of
screenshots and similar communications. Commenters stated that
developers of health IT have successfully used licensing and
nondisclosure agreements that apply to user-facing aspects of the
technology to maintain the trade secret status of their health IT and
that the Proposed Rule would impact their ability to do so and remain
competitive in the market.
Response. We appreciate the comments regarding how a developer's IP
may be impacted by the Communications Condition of Certification
requirements. As discussed earlier in this section, participation in
the Program is voluntary; and developers have the option to agree to
the terms we have offered or to choose not to participate in the
Program. However, we recognize the need to properly balance the
protection of a developer's IP with the need to advance visual
communications (e.g., screenshot and video communications) under the
Communications Condition and Maintenance of Certification requirements,
which we believe is critical to addressing--among other things--the
usability, interoperability, and security of health IT. As discussed
throughout this section and in section (C) above, we believe that we
have properly considered and addressed health IT developers' IP rights
in this final rule in Sec. 170.403(a)(2)(ii)(C) by amending the
proposed regulation as described above.
We emphasize that the communication of screenshots is essential to
protect public health and safety and that our final policies take a
measured approach to responding to and addressing a real and
substantial threat to public health and safety. The communication of
screenshots enables providers, researchers, and others to identify
safety concerns, share their experiences with the health IT, learn from
the problems, and then repair dangers that could otherwise cause
serious harm to patients. Our position is informed both by years of
experience regulating health IT and overwhelming research and academia,
which is discussed below.
For instance, a study published in 2018 was performed to better
characterize accessibility to EHRs among informatics professionals in
various roles, settings, and organizations across the United States and
internationally.\88\ To quantify the limitations on EHR access and
publication rights, the researchers conducted a survey of informatics
professionals from a broad spectrum of roles including practicing
clinicians, researchers, administrators, and members of industry. The
results were analyzed and levels of EHR access were stratified by role,
organizational affiliation, geographic region, EHR type, and
restrictions with regard to
[[Page 25735]]
publishing results of usability testing, including screenshots. Among
faculty members and researchers, 72 percent could access the EHR for
usability and/or research purposes, but, of those, fewer than 1 in 3
could freely publish screenshots with results of usability testing and
half could not publish such data at all. Across users from all roles,
only 21 percent reported the ability to publish screenshots freely
without restrictions.\89\
---------------------------------------------------------------------------
\88\ Khairat, S, et al. 2018 Assessing the Status Quo of EHR
Accessibility, Usability, and Knowledge Dissemination. eGEMs
(Generating Evidence & Methods to improve patient outcomes), pp. 1-
11, https://doi.org/10.5334/egems.228.
\89\ Id. at 1.
---------------------------------------------------------------------------
The study explained that the patient safety implications of EHR
publication censorship and restricted EHR access are multiple. First,
limiting institutions from sharing usability research findings can
prevent the correction of known problems. Second, without public
dissemination, poor design practices will propagate to future
iterations of existing vendor systems. Finally, research efforts are
directed away from real-world usability problems at a time when EHR
systems have become widely deployed and when an urgency exists to
accelerate usability testing. The study referenced the 2011 Institute
of Medicine report (as discussed in the Proposed Rule and in additional
detail below), which identified contractual restrictions as a barrier
to knowledge regarding patient safety risks related to health IT.\90\
---------------------------------------------------------------------------
\90\ Id. at 2.
---------------------------------------------------------------------------
The study emphasized that the result of this level of censorship is
that a vast majority of scientists researching EHR usability are either
prevented from publishing screenshots altogether or must first obtain
vendor permission, thus impeding the free dialogue necessary in
communities of investigation.\91\ The study argued that: (1) Lack of
EHR access makes many critical EHR usability research activities
impossible to conduct, and (2) publication censorship, especially
regarding screenshots, means that even those usability studies which
can be conducted may not have the impact they otherwise would. As a
consequence, innovation can be stifled. As such, one of the
recommendations made by the researchers was that there should be a
mandate that screenshots and images from EHR systems be freely
publishable without restrictions from copyright or trade secret
constraints.\92\
---------------------------------------------------------------------------
\91\ Id. at 7.
\92\ Id. at 8.
---------------------------------------------------------------------------
In the report by the Institute of Medicine that was noted above,
entitled Health IT and Patient Safety: Building Safer Systems for
Better Care,\93\ the Committee on Patient Safety and Health Information
Technology (Committee) explained that a significant impediment to
gathering safety data is contractual barriers (e.g., nondisclosure,
confidentiality clauses) that can prevent users from sharing
information about health IT-related adverse events. They further
explained that such barriers limit users' abilities to share knowledge
of risk-prone user interfaces, for instance through screenshots and
descriptions of potentially unsafe processes. In addition, some vendors
include language in their sales contracts and escape responsibility for
errors or defects in their software (i.e., ``hold-harmless clauses'').
The Committee concluded that these types of contractual restrictions
limit transparency, which significantly contributes to the gaps in
knowledge of health IT-related patient safety risks. Further, these
barriers to generating evidence pose unacceptable risks to safety.\94\
Based on these findings, the committee recommended that the Secretary
of HHS should ensure insofar as possible that health IT vendors support
the free exchange of information about health IT experiences and issues
and not prohibit sharing of such information, including details (e.g.,
screenshots) relating to patient safety.\95\
---------------------------------------------------------------------------
\93\ Institute of Medicine 2012. Health IT and Patient Safety:
Building Safer Systems for Better Care. Washington, DC: The National
Academies Press, https://doi.org/10.17226/13269.
\94\ Id. at 3.
\95\ Id. at 7.
---------------------------------------------------------------------------
Recently, the U.S. Food and Drug Administration (FDA) funded
Brigham and Women's Hospital Center for Patient Safety Research and
Practice to conduct an exploration of computerized prescriber order
entry (CPOE)-related potential for errors in prescribing, particularly
as these relate to drug name displays, and ordering and workflow design
issues. The project investigated ways to better identify, understand,
and prevent electronic ordering errors in the future.\96\ However, the
researchers noted that one large vendor would not grant permissions to
share requested screenshots necessary for the study. This refusal ran
counter to both the FDA's task order initial precondition as well as
multiple high-level panels' health IT safety recommendations. The FDA
emphasized that it is hard to justify from a safety viewpoint why such
permission was withheld, despite the vendors' proprietary concerns. FDA
explained that identifying, preventing, and learning from errors and
improving prescribing safety should be a priority and should take
precedence over commercial considerations (and to the extent
correctable problems can be identified, likely would result in an
improved commercial CPOE product). In cases where the FDA sought to
illustrate problems in the system, they drew generic screenshots to
illustrate the issue in question.\97\
---------------------------------------------------------------------------
\96\ U.S. Food & Drug Admin., UCM477419, Computerized Prescriber
Order Entry Medication Safety: Uncovering and Learning from Issues
and Errors, https://www.fda.gov/downloads/Drugs/DrugSafety/MedicationErrors/UCM477419.pdf.
\97\ Id. at 44.
---------------------------------------------------------------------------
Among their recommendations, the FDA recommended that vendors be
required to share screenshots and error reports. The FDA emphasized
that vendors should be required to permit the sharing of screenshots
and information with the FDA and other institutions regarding other
CPOE system issues of concern or that pose risk for errors. They
stressed that the practice of prohibiting such sharing via copyright
must be eliminated. Further, the FDA recommended that vendors should be
required to disclose errors reported to them or errors identified in
their products, analogous to the requirement that drug manufacturers
report significant adverse drug effects.\98\
---------------------------------------------------------------------------
\98\ Id. at 52.
---------------------------------------------------------------------------
One of the co-authors of the FDA study recently wrote a law review
article that discussed the significance of screenshots.\99\ The author
noted that the results of the FDA study were remarkable and remarkably
distressing, as they identified and took screenshots of over fifty
different dangers in the health IT. He expressed frustration that it
took up to two years of additional discussions with the vendors to get
permission to share the screenshots publicly, and that even after these
extended discussions, one vendor--``with more than a lion's share of
the market''--prevented the study from displaying the screenshots, some
of which were clearly dangerous or deadly. He explained that they had
worked around that limitation by substituting the one vendor's screens
with parallel screens taken from Harvard's homegrown, but by then
superannuated, EHR. The author emphasized that those images and
screenshots illustrated over fifty EHR risks caused by dangerous and
confusing EHR interfaces. The author also emphasized that the study
could have been even more helpful in identifying these risks if the FDA
had been able to present the findings when first available, rather than
haggle for a year or two, and if the study was able
[[Page 25736]]
to include all of the full images from each system they studied.\100\
---------------------------------------------------------------------------
\99\ Ross Koppel, Uses of the Legal System That Attenuate
Patient Safety, 68 DePaul L. Rev. (2019) Available at: https://via.library.depaul.edu/law-review/vol68/iss2/6.
\100\ Id. at 280-81.
---------------------------------------------------------------------------
Comments. A commenter recommended that ONC draw a distinction
around purpose of use in relation to the fair use of screenshots and
require that the discloser of a screenshot be responsible for ensuring
the appropriateness of that purpose.
Response. As discussed under section (C) above we have retained the
concept of ``fair use'' as it applies to all health IT developer
intellectual property covered under ``permitted prohibitions and
restrictions'' (Sec. 170.403(a)(2)(ii)). As discussed throughout this
section, we have placed certain restrictions on the sharing of
screenshots responsive to the commenter.
Comments. One commenter urged ONC to revise the proposed approach
to screenshots by adopting a process that would allow developers to
review and approve screenshots for publication for specific purposes,
such as communications about safety and usability.
Response. A pre-approval process could create potential or
perceived barriers to communications and thus could discourage or delay
the making of protected communications that are vital to patient safety
or other important issues regarding certified health IT. For example, a
user might be less willing to go through the process, the time the
process takes could undermine the conveyance of the communications, and
the objections raised during the process may not be valid or amenable
to all parties.
Comments. Several commenters had concerns regarding the volume of
screenshots that could be shared under our proposal and potential harms
that could occur. One commenter emphasized that sharing of screenshots
could disclose information about how health IT works, including
algorithms and workflows, and enable creation of duplicate software and
theft of valuable IP. One commenter suggested that if a user of health
IT published hundreds of screenshots of the health IT, a bad actor
could theoretically deduce trade secrets based on the screenshots.
Several additional commenters were also concerned that the Proposed
Rule could allow communication of an unlimited number of screenshots of
certified health IT, and one commenter suggested revising the proposed
approach to include limiting sharing of screenshots to a reasonable
number, such as seven.
Response. We appreciate those comments expressing concerns
regarding the volume of screenshots that could be shared and the
potential negative consequences of allowing screenshots to be shared.
In the Proposed Rule in 84 FR 7475, we proposed to allow developers to
place limited restrictions on the sharing of screenshots. We stressed
in the Proposed Rule that our goal with our proposals concerning
screenshots was to enable communications that will address matters such
as patient safety, system security vulnerabilities, health IT
performance, and usability. Our intent was not to prevent developers
from restricting the communication of screenshots for purposes outside
the scope of the protected communications detailed in the Cures Act.
Additionally, we believe that modern software design best practices
uncouple screen design from underlying algorithms, and that limited use
of screenshots for safety would not allow reverse engineering of large
parts of the underlying code. However, we further emphasize that it was
never our intention that screenshots (or other visual communications
such as video) depicting source or object codes would be protected
communications (see the non-user-facing aspects provision of this
Condition of Certification), so long as such communications are not
communications with unqualified protection.
We reviewed comments that suggested establishing a set numerical
limit for the sharing of screenshots. However, we have not finalized a
requirement in Sec. 170.403(a)(2)(ii)(D) with a fixed numerical limit
because there is no non-arbitrary way to determine what the ``right''
or ``appropriate'' number is in a one-size-fits-all way. That is
because the number of screenshots or amount of video that would be
needed to communicate about the health IT could vary, from one
situation to the next, based on the specific issue and circumstances.
For instance, an issue with health IT functionality regarding a
particular process that involves the user viewing and making selections
on several different screens may necessitate images of all of the
screens involved in order to communicate the issue. However, an issue
regarding how one value is being displayed in a particular context
(e.g., a medication name being truncated) may only necessitate one
screenshot in order to communicate the issue. Thus, we believe the best
approach is to adopt a qualitative standard that is designed to be
sufficiently flexible for the wide range of health IT issues that may
arise and the varying visual communications that need to be
communicated to demonstrate or display the issue.
We have finalized provisions in Sec. 170.403(a)(2)(ii)(D)(2) and
(3) that allow health IT developers to require persons who communicate
screenshots to limit the sharing of screenshots to only the relevant
number of screenshots and amount of video that are needed to
communicate about the health IT regarding one or more of the six
subject areas identified in the Cures Act and detailed in Sec.
170.403(a)(1). Allowing developers to limit the sharing of screenshots
to only the relevant number needed to communicate about the health IT--
regarding one or more of those six subject areas--places a limitation
on the number of screenshots allowed to be shared under the
Communications Condition of Certification requirements and requires
that the screenshots are related to, and thus necessary in
illustrating, the protected communication being made. In practice, this
would mean that if a particular safety issue in the health IT could be
communicated using three screenshots, the communicator should not share
additional screenshots that are irrelevant or only potentially relevant
to communicate the safety issue with the health IT. If the
communication included additional screenshots that were not necessary
to visually communicate about the particular safety issue with the
health IT that falls within the usability category, the health IT
developer would have grounds to seek redress.
As with screenshots, we wish to be sensitive to concerns regarding
protecting IP in health IT and allow developers to appropriately limit
video communication in order to protect against harms that could occur
due to unlimited sharing. Similar to screenshots, the amount of video
that may be necessary to make a protected communication about health IT
could vary, depending on the nature of the issue or aspect of the
health IT being addressed. For example, a video meant to communicate a
delay in order entry would need to be long enough to communicate the
significance of the delay, but would not need to include video of the
log-in process or other unrelated functionality of the health IT. We
have finalized a provision in Sec. 170.403(a)(2)(ii)(D)(3) that allows
health IT developers to place certain limitations on the communication
of video. Under this provision, a health IT developer may require
persons who communicate video to limit the sharing of video to: (1) The
relevant amount of video needed to communicate about the health IT
regarding one or more of the
[[Page 25737]]
subject areas identified in the Cures Act and detailed in Sec.
170.403(a)(1); and (2) only videos that address temporal matters that
the user reasonably believes cannot be communicated through screenshots
or other forms of communications.
In sum, any disclosure must be limited to the relevant number of
screenshots or amount of video that is necessary to convey the matter
that falls within one of the six subject areas, with video only being
used to convey temporal matters that cannot be communicated through
screenshots or other forms of communication. We believe these
additional limitations on the communication of screenshots and video
will further bolster protections for developer IP, while still allowing
necessary and effective communication about health IT issues within the
six subject areas.
Comments. Several commenters stated that there should be a way to
protect against doctored screenshots.
Response. As proposed, communicators of screenshots must not alter
the screenshots (or video), except to annotate the screenshots or
resize the screenshots (Sec. 170.403(a)(2)(ii)(D)(1)). These
restrictions similarly apply to video as well (Sec.
170.403(a)(2)(ii)(D)(1)). We further note that, despite a lack of
comments, on further reflection, we have elected to not finalize
proposed limitations to allow developers to impose restrictions on the
communication of screenshots that contain PHI. We have made this
determination because we believe that most of the individuals or
entities communicating the screenshots would be bound by other laws,
including the HIPAA Rules and State privacy laws, which would be
applicable to the PHI at issue. Therefore, we do not believe it is
necessary to provide for developers policing the release of such data
in the form of screenshots in this Condition of Certification.
Comments. A number of commenters discussed the infeasibility of the
proposed requirements regarding restricting communication of
screenshots, and in particular, the requirement that health IT
developers put all potential communicators on sufficient written notice
of each aspect of its screen display that contains third-party content
that cannot be communicated because it would infringe IP rights. Some
commenters stated that the proposed language should be amended to
require a list of third-party content that might appear in a screen or
that the developer sublicenses, or to require a notice on the
developer's website. Other commenters stated that the proposal should
be removed. One commenter recommended ONC consider not making
developers accountable for actions by health IT users regarding the
disclosure of screenshots with third-party information. One commenter
requested additional guidance from ONC for dealing with third-party,
non-health IT content in health IT.
Response. Where a health IT developer is prohibited by this rule
from restricting the communication of a screenshot and allows a
screenshot containing third-party content to be communicated, the
health IT developer is acting as required by this final rule and
enabling important communication regarding critical health IT issues to
occur. Thus, we believe developers acting in accordance with this final
rule should not be responsible for third-party content in screenshots
that are communicated as required by the Communications Condition of
Certification requirements. As such, in Sec. 170.403(a)(2)(ii)(D) we
have removed from the requirements related to third-party IP rights
proposed in 84 FR 7475.
(E) Testing and Development
We discussed in the Proposed Rule in 84 FR 7475 that some health IT
developers expose aspects of their health IT to health care providers
and others for the purpose of testing and development prior to a
product's ``general availability'' release. We stated that such
disclosures may relate to beta releases that are shared with certain
customers for testing prior to the software being made generally
available to the market, or may be made as part of a joint-venture or
cooperative development process. In these circumstances, we proposed in
84 FR 7475 that a health IT developer would be justified in keeping
information about its health IT confidential. We explained that this
permitted prohibition or restriction would allow developers to seek
appropriate IP protection and discuss novel, ``unreleased'' product
features with their customer base, which has significant public policy
benefits for research and innovation in the health IT industry.
We proposed in 84 FR 7475 that this permitted restriction would be
limited and would not apply to communications that are subject to
unqualified protection as specified in proposed Sec. 170.403(a)(2)(i).
We proposed that this permitted restriction would also not apply to
communications about the released version of the health IT once the
health IT has been released.
We requested comment on whether we should limit the time this
protection would apply for testing purposes. We also requested comment
on whether we should set specific parameters for covered testing.
Comments. A couple of commenters stated that there should be no
limit on how long testing and development could last for the purpose of
the restrictions that developers would be allowed to place on
communications regarding products in development. These commenters
stressed that any limit would be arbitrary and that until certified
health IT is in live commercial use, health IT developers should be
permitted to restrict communications about it.
Response. We agree with the commenters and did not propose to add a
time limit on testing and development phases for the purpose of this
Condition of Certification requirement.
Comments. A couple of commenters requested clarification that
providers testing products in real-world environments would not be
considered ``contractors'' of developers for the purpose of the
Communications Condition of Certification requirements because such
treatment could result in developers being allowed to place additional
communication restrictions on employees and contractors under the
Communication Condition of Certification requirements. One comment also
stated that restrictions on communications by employees and contractors
should not extend to their communications regarding product features
and functionality that the employees and contractors were not involved
in developing or testing.
Response. The applicability of this allowable restriction to
providers testing products would be determined by the particular facts
at issue and whether or not the provider was an actual contractor,
employee, or consultant for the developer. We also clarify that this
final rule does not limit the restrictions a developer may place on an
employee, contractor, or consultant with regard to protected
communications, except to the extent that the communication is one with
unqualified protection, in which case no such restrictions would be
allowed.
Comments. One commenter recommended that a health IT user must have
used health IT in a real-world context before a communication by the
user about the health IT can be protected.
Response. We have finalized our proposal in Sec.
170.403(a)(2)(ii)(E) that a health IT developer would be justified in
keeping information about its health
[[Page 25738]]
IT confidential prior to a product's ``general availability'' release.
We note that a health IT developer would also be justified in keeping
information about a product update confidential because the update is
not yet generally available. We do not place any limits on who the
communicator has to be in order to be covered by the Communications
Condition of Certification requirements, particularly since the
protections in the Communications Condition of Certification
requirements extend beyond users of certified health IT to cover
researchers and other stakeholders who may experience certified health
IT in a variety of settings and scenarios. As such, we have decided not
to limit the communication protection to only those communications that
are made by users of certified health IT in the real-world context.
c. Maintenance of Certification Requirements
We proposed in 84 FR 7476 that to maintain compliance with the
Communications Condition of Certification requirements, a health IT
developer must not establish or enforce any contract or agreement
provision that contravenes the Communications Condition of
Certification requirements. We also proposed in 84 FR 7476 that a
health IT developer must notify all entities or individuals with which
it has a contract/agreement related to certified health IT that any
communication or contract/agreement provision that contravenes the
Communications Condition of Certification requirements will not be
enforced by the health IT developer. We proposed in 84 FR 7476 that
such notification must occur within six months of the effective date of
the final rule. Further, we proposed in 84 FR 7476 that this notice
would need to be provided annually up to and until the health IT
developer amends the contract or agreement to remove or make void any
contractual provision that contravenes the Communications Condition of
Certification requirements. We further proposed as a Maintenance of
Certification requirement in proposed Sec. 170.403(b)(2) that health
IT developers must amend their contracts/agreements to remove or make
void any provisions that contravene the Communications Condition of
Certification requirements within a reasonable period of time, but not
later than two years from the effective date of a final rule.
In the event that a health IT developer cannot, despite all
reasonable efforts, locate an entity or individual that previously
entered into an agreement with the developer that prohibits or
restricts communications protected by the Communications Condition of
Certification requirements, we proposed in 84 FR 7476 that the
developer would not be in contravention of the Communications Condition
of Certification requirements so long as it takes no step to enforce
the prohibition or restriction. We did not propose that health IT
developers be required to furnish to ONC or their ONC-ACB copies of
notices made to customers, or copies of contracts or agreements
revised, in satisfaction of this Maintenance of Certification
requirement, although we noted that those communications could be
requested by ONC or an ONC-ACB in the usual course of business or to
demonstrate compliance.
Comments. A number of commenters expressed concerns regarding the
proposed deadlines for complying with the requirements. Several
commenters stated that the requirement to notify customers and others
with whom the developer has contracts or agreements within six months
was too long and recommended that the deadline be shortened. Regarding
the deadline for amending contracts/agreements that contravene the
Communications Condition of Certification requirements, most commenters
stated that the deadline was too short, with several requesting that it
be extended to five years. Some other commenters recommended that
modification of any contracts/agreements to comply with the
Communications Condition of Certification requirements should occur
whenever such contracts/agreements are renewed, or at the earliest
available time, without the need for a specific deadline. A couple of
commenters recommended that a health IT developer not be held
responsible for amending contracts within two years of the effective
date of the final rule if it has made reasonable efforts to do so.
Several comments recommended that ONC should allow alternative means of
completing this requirement, such as posting relevant language on the
developer's website. One commenter stated that it would be helpful to
have a ``standard exception clause'' that developers could use in their
contracts and agreements.
Response. We appreciate the comments we received on this provision.
We clarify in Sec. 170.403(b)(2)(i) that a developer may not include
provisions that contravene the Communications Condition of
Certification requirements in any new contract as of the effective date
of the final rule. In consideration of comments, we have decided to
modify the timeframe requirement proposed in 84 FR 7476 for amending
contracts/agreements to be in compliance with this condition. While we
considered extending the deadline to five years to allow developers to
have additional time for compliance, we determined that a more flexible
solution is appropriate. As such, we have modified the requirement in
Sec. 170.405(b)(2)(ii) to state that any contracts/agreements in place
as of the effective date of the final rule and containing language in
contravention of the Communications Condition of Certification
requirements must be revised to remove or void the contractual
provision that contravenes the Communications Condition of
Certification requirements whenever the contract is next modified for
any reason. We clarify that where a contract automatically renews, the
developer would still be prohibited under the Program from enforcing
any agreement or contract provisions that contravene the Communications
Condition of Certification requirements in Sec. 170.403(a) and the
developer would also be responsible for sending an annual notice as
described above until such provisions have been modified. To note, we
decline to absolve a developer of the requirement to modify the
contract solely because the developer has made a reasonable effort to
do so.
We finalized the notification requirements proposed in 84 FR 7476.
A health IT developer must notify all entities and individuals with
which it has a contract/agreement related to certified health IT that
any communication or contract/agreement provision that contravenes the
Communications Condition of Certification requirements will not be
enforced by the health IT developer. However, we no longer require that
such notification must occur within six months of the effective date of
the final rule and annually thereafter until contravening provisions
are amended. Instead, notification must only occur annually, beginning
in calendar year 2020, and continue until all contravening provisions
are amended. Given the timing of the publication of the final rule,
health IT developers could have potentially been required to provide
both initial notification and an annual notification in the same
calendar year. We believe the removal of the six months notification
deadline and retention of an annual requirement only, beginning with
notification in calendar year 2020, will simplify compliance for health
IT developers while still providing adequate notice and ensuring that
initial notification is provided in a reasonable amount of time.
Therefore
[[Page 25739]]
we have finalized the deadline for the notice requirement in Sec.
170.403(b)(1) to be annually, beginning in calendar year 2020.
Comments. Several commenters requested clarification that once the
final rule goes into effect, contravening provisions in developer
contracts prohibiting communications cannot be enforced. One of these
commenters stated that developers would often include language in their
contracts prohibiting communication on the part of end users and
entities, thus preventing communication about issues with EHRs. Several
commenters requested that ONC explicitly state that any permitted
communication made following the effective date of the final rule be
inadmissible as a violation of a contract/agreement regardless of
whether the customer has been notified. One commenter requested that
ONC clarify that, with respect to protecting communications regarding
developer business practices, where the disclosure of certain
information is prohibited by contract, the developer would not be
liable for its inability to communicate such information.
Response. We emphasize that as of the effective date of the final
rule, contravening provisions in contracts or agreements cannot be
enforced without the risk of losing certification for the developer's
health IT or a certification ban for the developer under the Program,
regardless of whether the customer was notified as required by the
Communications Condition of Certification requirements. We clarify that
provisions of contracts requiring that the health IT customer ``flow-
down'' obligations onto the customer's employees, contractors, and
other users of the health IT that would restrict protected
communications would be in contravention of this Condition of
Certification. Such provisions could not be enforced after the
effective date of the final rule without risking loss of certification
as noted above for the developer under the Program.
We appreciate commenters' concern regarding disclosing information
that may be otherwise prohibited by contract. However, we clarify that
the purpose of the Communications Condition of Certification
requirements is to prevent developers from improperly restricting
protected communications, including communications about a developer's
practices and policies related to facilitating the exchange of health
information. As discussed earlier in this section, costs, timeframes,
licensing practices and terms, as well as the developer's approach to
working with third-party services, could all be considered protected
communications to the extent they relate to facilitating the exchange
of health information. Thus, we reiterate that where a contract entered
into by the developer would restrict a communication protected by the
Communications Condition of Certification requirements, the developer
may not enforce such a contract and may not restrict a protected
communication in violation of the Communications Condition of
Certification requirements after the effective date of the final rule
without risking loss of certification. It is also important to note
that not all contractual provisions related to communications would
create a risk of de-certification. As noted above, the Communications
Condition of Certification requirements in Sec. 170.403(a)(2)(ii) do
allow for developers to place restrictions on certain communications as
discussed above. Therefore, contractual provisions that appropriately
address those allowances would not create a risk of de-certification
under the Program.
Comments. One commenter suggested that ``renew'' should be added to
the maintenance requirement to not establish or enforce any contract or
agreement that contravenes the Communications Condition of
Certification requirements in Sec. 170.403(a).
Response. We appreciate this comment and amended the proposed
regulatory text in Sec. 170.403(b)(2)(i) to include ``renew.'' We
clarify that where a contract auto-renews, the developer would still be
prohibited under the Program from enforcing any agreement or contract
provisions that contravene the Communications Condition of
Certification requirements without risking loss of certification and
would also be responsible for sending an annual notice as described
above until such provisions have been modified.
Comments. A couple of commenters expressed concern about developer
efforts to re-negotiate other terms of a contract that are unrelated to
protected communications as part of the contract modification process.
Response. We stress that the contract modifications required as
part of the Communications Condition of Certification requirements are
strictly limited to removing any provisions of the relevant contract/
agreement that would restrict protected communications in contravention
of the Communications Condition of Certification requirements and are
not required to be done until the contract/agreement is modified for
other purposes.
4. Application Programming Interfaces
The API Condition of Certification requirement in Section 4002 of
the Cures Act requires health IT developers to publish APIs that allow
``health information from such technology to be accessed, exchanged,
and used without special effort through the use of APIs or successor
technology or standards, as provided for under applicable law.'' The
requirement also states that a developer must, through an API,
``provide access to all data elements of a patient's electronic health
record to the extent permissible under applicable privacy laws.''
Additionally, the API Condition of Certification requirement of the
Cures Act includes several key phrases and requirements for health IT
developers that go beyond the technical functionality of the Health IT
Modules they present for certification. In this section of the
preamble, we outline the proposals we have adopted to implement the API
Condition of Certification requirement of the Cures Act to provide
compliance clarity for health IT developers.
We have adopted new standards, new implementation specifications, a
new certification criterion, Condition and Maintenance of Certification
requirements, and modified the Base EHR definition. Health IT
developers should consider these final requirements in the context of
information blocking provisions described in section VIII of this
preamble.
a. Statutory Interpretation and API Policy Principles
Section 4002 of the Cures Act requires health IT developers
certified to the Program to publish APIs that allow ``health
information from such technology to be accessed, exchanged, and used
without special effort through the use of APIs or successor technology
or standards, as provided for under applicable law.'' To implement the
Cures Act API requirements, we proposed a new 2015 Edition Cures Update
``API'' certification criterion at 84 FR 7476 that included
requirements for an API to have ``read'' capabilities that support two
types of services: (1) Services for which a single patient's data is
the focus; and (2) services for which multiple patients' data are the
focus.
We conveyed in the Proposed Rule our belief that ``without special
effort'' requires APIs and the health care ecosystem in which they are
deployed to be standardized, transparent, and pro-
[[Page 25740]]
competitive. Therefore, we noted that any Health IT Module certified to
the new 2015 Edition Cures Update API criterion and a health IT
developer's business practices would have to have these attributes.
b. API Standards and Implementation Specifications
i. Base Standard
We proposed in Sec. 170.215(a)(1) at 84 FR 7477 to adopt
HL7[supreg] FHIR[supreg] Draft Standard for Trial Use (DSTU) 2 for
reference in the criterion proposed in Sec. 170.315(g)(10).
Additionally, we requested comment in 84 FR 7478 and 7479 on four
options to determine the best version of HL7 FHIR to reference for use
in Sec. 170.315(g)(10): Option 1: FHIR DSTU 2, Option 2: FHIR DSTU 2
and FHIR Release 3, Option 3: FHIR DSTU 2 and FHIR Release 4, and
Option 4: FHIR Release 4 only. We requested commenters review the
proposed certification criterion in Sec. 170.315(g)(10) and the
accompanying Condition of Certification requirements attributed to the
API certification criteria. Notably, we stated in the Proposed Rule at
84 FR 7479 that if we adopted another FHIR Release in a final rule as
an alternative to FHIR Release 2 for the proposed API criterion in
Sec. 170.315(g)(10), then we would also adopt the applicable
implementation specifications associated with the FHIR Release.
Comments. We received overwhelming support for Option 4: Adopt
solely FHIR Release 4 in the final rule for reference in Sec.
170.315(g)(10). We received support for the adoption of FHIR Release 4
across a broad array of stakeholders, including health IT developers,
medical trade associations, software application developers, and
payers. Commenters noted that FHIR Release 4 is the first FHIR release
with normative FHIR resources and support for enhanced capabilities.
Most commenters emphasized that Option 4 will allow the industry to
unify and focus on a single baseline standard, rather than
accommodating multiple releases proposed in Options 2 and 3. A minority
of commenters suggested alternative or multiple versions, noting this
would allow for flexibility, but the vast majority of commenters
supported the adoption of FHIR Release 4 only.
Response. We appreciate the feedback and agree with commenters that
adoption of a single standard is the best option to align industry and
enable widespread interoperability. We have adopted the latest version
of the standard at the time of this final rule publication (FHIR
Release 4.0.1) in Sec. 170.215(a)(1) and finalized its use in Sec.
170.315(g)(10).
ii. United States Core Data for Interoperability
We proposed in Sec. 170.215(a)(2) at 84 FR 7479 to adopt the API
Resource Collection in Health (ARCH) Version 1 implementation
specification, which listed a set of base HL7[supreg] FHIR[supreg]
resources that Health IT Modules certified to the proposed criterion in
Sec. 170.315(g)(10) would need to support.
Comments. Most commenters were opposed to the adoption of the ARCH
in the final rule. Commenters argued for the use of American National
Standards Institute accredited standards, and suggested ONC work with
standards developing organizations for standards development and
maintenance.
Several commenters noted that the ARCH has not gone through a
formal balloting process, did not support ONC's proposal to rely upon
the National Technology Transfer and Advancement Act's exception to
adopt the ARCH in the final rule, and encouraged the use of technical
standards developed or adopted by voluntary consensus standards bodies.
Several commenters noted that requiring the ARCH in addition to the
other adopted standards could create confusion. Commenters further
emphasized the importance of maintaining ongoing consistency between
the ARCH and the other adopted standards, and noted this would be
challenging to achieve.
Additional comments against the ARCH expressed concern with the
proposed updates through the Standards Version Advancement Process, and
with ONC over-regulating API functionality. Commenters also noted that
ONC could encourage API access to specific data elements without
creating a new implementation specification.
Some commenters in favor of the ARCH implementation specification
asked for data element revisions. Commenters also asked for clarity
that EHRs will not need to provide the full set of data to modular
applications, and asked for specificity on how much of this data would
need to be mapped by the API Technology Supplier. Additionally,
commenters asked for guidance on lab results, including application
creation implementation guides that would ensure accuracy and
compliance when incorporating lab data.
Response. In response to commenters, we did not adopt the ARCH as
an implementation specification in the final rule. Upon consideration
of public comments and in an effort to consistently approach how we
reference the United States Core Data for Interoperability (USCDI) with
various content standards (e.g., C-CDA), we determined that having an
implementation specification to map USCDI to HL7 FHIR could create more
restrictions than we intended. We appreciate the concerns raised by
stakeholders, and as we evaluated the ARCH in context of our other
proposals, we determined that we could achieve our desired policy
outcome to link the USCDI Data Elements to FHIR Resources without the
ARCH. We refer commenters to the sections that follow for further
clarity regarding the implementation of Data Elements included in the
USCDI implementation specification (IV.B.1).
iii. US Core IG and Bulk IG
We proposed in 84 FR 7480 in Sec. 170.215(a)(3) to adopt the
Argonaut Data Query Implementation Guide version 1 (Argonaut IG)
implementation specification, which specifies constraints for 13 of the
HL7[supreg] FHIR[supreg] resources proposed in Sec. 170.215(a)(2).
Additionally, we proposed in Sec. 170.215(a)(4) to adopt the Argonaut
Data Query Implementation Guide Server implementation specification.
Comments. Several commenters advocated for the adoption of the FHIR
US Core Implementation Guide STU 3 Release 3.0.0 implementation
specification instead of the Argonaut Implementation Guides. Commenters
noted that the US Core Implementation Guide was built from the Argonaut
Implementation Guides and has been balloted by the standards community.
Response. We thank commenters for their feedback. We note that in
the Proposed Rule at 84 FR 7479 we stated that if we were to adopt
another FHIR Release in the final rule as an alternative to FHIR
Release 2, then we would also adopt the applicable implementation
specifications and FHIR profiles associated with the FHIR Release.
Considering this and commenters' recommendations, we have adopted the
HL7 FHIR US Core Implementation Guide STU 3.1.0 (US Core IG)
implementation specification in Sec. 170.215(a)(2). We note that we
adopted the latest version of the US Core IG at the time of the final
rule publication. The US Core IG defines the minimum conformance
requirements for accessing patient data using FHIR Release 4 (adopted
in Sec. 170.215(a)(1)), including profiled resources, operations, and
search parameters for the Data Elements required in the USCDI
implementation specification (adopted in Sec. 170.213).
[[Page 25741]]
We note that in the Proposed Rule at 84 FR 7479 we proposed to
require that the ``Patient.address'' and ``Patient.telecom'' elements
of the ``Patient'' resource must be supported. We note these
requirements have since been subsumed by the US Core IG, given that
``Patient.address'' and ``Patient.telecom'' elements are both flagged
``must support'' for the ``Patient'' profile in the US Core IG. We also
proposed to require that the ``Device.udi'' element follow the human
readable representation of the unique device identifier found in the
recommendation, guidance, and conformance requirements section of the
``HL7 Version 3 Cross Paradigm Implementation Guide: Medical Devices
and Unique Device Identification Pattern, Release 1.'' These
requirements have also been subsumed by the US Core IG. Additional
information can be found in the ``Device'' profile of the US Core IG
adopted in Sec. 170.215(a)(2).
We note that in the Proposed Rule we proposed in 84 FR 7480 that
the clinical note text included in the ``DocumentReference'' resource
would need to be represented in its ``raw'' text form, and further
proposed in 84 FR 7480 that it would be unacceptable for the note text
to be converted to another file or format (e.g., .docx, PDF) when it is
provided as part of an API response. We clarify that the clinical note
text included in any of the notes described in the ``Clinical Notes
Guidance'' section of the US Core IG adopted in Sec. 170.215(a)(2)
must be represented in a ``plain text'' form, and would be unacceptable
for the note text to be converted to another file or format (e.g.,
.docx, PDF) when it is provided as part of an API response.
We note that in the Proposed Rule we proposed in 84 FR 7480 to
require that the ``Provenance.recorded'' and ``Provenance.agent.actor''
elements of the ``Provenance'' resource must be supported. We note
these requirements have been subsumed by the US Core IG, given that
``Provenance.recorded'' and ``Provenance.agent.who'' elements are both
flagged ``must support'' for the ``Provenance'' profile in the US Core
IG.
As addressed under the header ``Standardized API for Patient and
Population Services'' in the section V.B.4.c, we have finalized the
adoption of the HL7 FHIR Bulk Data Access (Flat FHIR) (v1.0.0: STU 1)
implementation specification (Bulk IG), including mandatory support for
the ``group-export'' ``OperationDefinition'' in Sec. 170.215(a)(4).
iv. HL7 SMART IG and Backend Services Authorization
We proposed in 84 FR 7481 in Sec. 170.215(a)(5) to adopt the
HL7[supreg] SMART Application Launch Framework Implementation Guide
Release 1.0.0 implementation specification, a profile of the OAuth 2.0
specification.
Comments. Most commenters expressed support for the HL7 SMART
Application Launch Framework Implementation Guide Release 1.0.0 (SMART
IG) implementation specification. Multiple commenters suggested that in
addition to requiring support for ``refresh tokens,'' ``Standalone
Launch,'' and ``EHR Launch'' capabilities from the SMART IG, ONC also
require support for ``sso-openid-connect,'' ``launch-standalone,''
``launch-ehr,'' ``client-public,'' ``client-confidentialsymmetric,''
``context-ehr-patient,'' ``context-standalone-patient,'' ``permission-
patient,'' ``permission-user,'' and ``permission-offline''
capabilities.
Response. We thank stakeholders for their comments. The ten
optional capabilities commenters suggested are included in the ``SMART
on FHIR Core Capabilities'' section of the SMART IG. The ``SMART on
FHIR Core Capabilities'' suggested by commenters include ``sso-openid-
connect,'' which allows for support of the OpenID Connect profile in
the SMART IG; ``client-public'' and ``client-confidential-symmetric,''
which allow for client authentication; ``context-ehr-patient'' and
``context-standalone-patient,'' which provide context to apps at launch
time; and ``permission-patient,'' ``permission-user,'' and
``permission-offline,'' which allow support for patient-level scopes,
user-level scopes, and refresh tokens, respectively. Other ``SMART on
FHIR Core Capabilities'' that were not suggested by commenters include
``context-banner'' and ``context-style,'' which provide basic context
to apps at launch time, and ''context-ehr-encounter'' and ``context-
standalone-encounter,'' which provide encounter-level granularity to
apps at launch time. Given the importance of these ``SMART on FHIR Core
Capabilities,'' and in consideration of public comments and our own
research, we have adopted the SMART IG, including mandatory support for
the ``SMART on FHIR Core Capabilities'' in Sec. 170.215(a)(3). We
explicitly require mandatory support of the ``SMART on FHIR Core
Capabilities'' in Sec. 170.215(a)(3) because these capabilities are
indicated as optional in the implementation specification. We further
clarify these ``SMART on FHIR Core Capabilities'' are in scope for
Program testing and certification. Additionally, we clarify that by
requiring the ``permission-patient'' ``SMART on FHIR Core Capability''
in Sec. 170.215(a)(3), Health IT Modules presented for testing and
certification must include the ability for patients to authorize an
application to receive their EHI based on FHIR resource-level scopes.
Specifically, this means patients would need to have the ability to
authorize access to their EHI at the individual FHIR resource level,
from one specific FHIR resource (e.g., ``Immunization'') up to all FHIR
resources necessary to implement the standard adopted in Sec. 170.213
and implementation specification adopted in Sec. 170.215(a)(2). This
capability will give patients increased control over how much EHI they
authorize applications of their choice to receive. For example, if a
patient downloaded a medication management application, they would be
able to use these authorization scopes to limit the EHI accessible by
the application to only information contained in FHIR
``MedicationRequest'' and ``Medication'' profile.
Comments. Some commenters noted concerns for privacy and security
of APIs. Specifically, one commenter explained the threat of cross-site
request forgery (CSRF), and suggested we take action to mitigate that
risk, including by requiring the use of both OAuth 2.0 and OpenID
Connect Core 1.0.
Response. We appreciate the concerns expressed by commenters
regarding the privacy and security of APIs. The OAuth 2.0 standard
defined at Request For Comment (RFC) 6749 \101\ describes that ``[The
OAuth 2.0 authorization] framework was designed with the clear
expectation that future work will define prescriptive profiles and
extensions necessary to achieve full web-scale interoperability.'' The
SMART IG serves as a ``prescriptive profile'' as described in RFC 6749.
Thus, consistent with commenters' recommendations, we have adopted a
profile of the OAuth 2.0 standard (SMART IG) in Sec. 170.215(a)(3).
Additionally, we have adopted OpenID Connect Core 1.0 incorporating
errata set 1 in Sec. 170.215(b), and require conformance with the
relevant parts of this standard as part of testing and certification.
CSRF is a well-documented security threat in OAuth 2.0, which can be
prevented with adequate security practices. We encourage implementers
to adhere to industry best practices to mitigate CSRF and other known
security threats. Relatedly, we note that the HL7 community has
developed an
[[Page 25742]]
``Implementer's Safety Check List,'' \102\ a guide of security best
practices for implementing FHIR-based APIs. We encourage stakeholders
to consult this guide during development and implementation of Sec.
170.315(g)(10)-certified Health IT Modules to minimize security risks.
---------------------------------------------------------------------------
\101\ https://tools.ietf.org/html/rfc6749.
\102\ https://www.hl7.org/FHIR/safety.html.
---------------------------------------------------------------------------
For backend services authorization, as addressed under the header
``Standardized API for Patient and Population Services'' in the section
V.B.4.c, we have finalized the adoption of the HL7 FHIR Bulk Data
Access (Flat FHIR) (v1.0.0: STU 1) implementation specification (Bulk
IG), which includes the ``Backend Services Authorization Guide'' in
Sec. 170.215(a)(4).
v. OpenID Connect
We proposed in 84 FR 7480 through 7481 in Sec. 170.215(b) to adopt
OpenID Connect Core 1.0 including errata set 1.
Comments. We received few comments regarding the adoption of OpenID
Connect Core 1.0 including errata set 1, however, commenters generally
supported the adoption of this standard.
Response. We thank commenters for their feedback. Given their
support, we have finalized the adoption of OpenID Connect Core 1.0
including errata set 1 as proposed in Sec. 170.215(b). We clarify that
only the relevant parts of the OpenID Connect Core 1.0 including errata
set 1 adopted in Sec. 170.215(b) that are also included in the
implementation specification adopted in Sec. 170.215(a)(3) will be in-
scope for testing and certification.
c. Standardized API for Patient and Population Services
We proposed in 84 FR 7481 to adopt a new certification criterion,
Sec. 170.315(g)(10), to replace Sec. 170.315(g)(8), and we proposed
in 84 FR 7495 to update the 2015 Edition Base EHR definition, as
referenced in Sec. 170.102. The proposed certification criterion would
require Health IT Modules to support API-enabled ``read'' services for
single and multiple patients. ``Read'' services include those that
allow authenticated and authorized third-party applications to view EHI
through a secure API. These services specifically exclude ``write''
capabilities, where authenticated and authorized third-party
applications would be able to create or modify EHI through a secure
API.
Comments. Commenters supported the proposed adoption of a new
certification criterion, Sec. 170.315(g)(10), to replace Sec.
170.315(g)(8).
Response. We appreciate the support from commenters. As a result,
we have adopted a new certification criterion in Sec. 170.315(g)(10),
to replace Sec. 170.315(g)(8) and made several revisions to address
public comment as discussed further below. Although the certification
criteria finalized at Sec. 170.315(g)(10) will replace Sec.
170.315(g)(8), we note that Sec. 170.315(g)(8) is not removed from
regulation. We maintain Sec. 170.315(g)(8) and have finalized in Sec.
170.550(m) that ONC-ACBs can issue certificates for Sec. 170.315(g)(8)
during the transition period to Sec. 170.315(g)(10) for 24 months
after the publication date of the final rule.
Comments. Commenters suggested dividing the Sec. 170.315(g)(10)
criterion into two separate criteria for single and multiple patients.
Response. We appreciate the feedback. We decline to split the
certification criterion into two criteria. In consideration of comments
and for clarity, we have improved the organization of the final
certification requirements for API-enabled ``read'' services for single
and multiple patients by separating the criterion into distinct
sections in the regulation text.
Comments. Several commenters supported referencing a standard for
API-enabled ``read'' services for multiple patients, including the
HL7[supreg] FHIR[supreg] Bulk Data Access Implementation Guide Release
1.0.0. Commenters felt that omitting a standard in the criterion would
undermine interoperability for API-enabled ``read'' services for
multiple patients.
Response. We thank commenters for their feedback. To enable
consistent health IT implementation of API-enabled ``read'' services
for multiple patients, we have finalized the adoption of the Bulk IG,
including mandatory support for the ``group-export''
``OperationDefinition'' in Sec. 170.215(a)(4). As part of the Program,
we require Health IT Modules presented for testing and certification to
conform to the Bulk IG implementation specification finalized in Sec.
170.215(a)(4). The adoption of an implementation specification for API-
enabled ``read'' services for multiple patients in Sec. 170.215(a)(4)
is responsive to stakeholder concerns and further supports our intent
to prevent ``special effort'' for the use of APIs as mandated in
section 4002 of the Cures Act. Furthermore, based on our analysis, we
believe the ``group-export'' ``OperationDefinition,'' as defined in the
Bulk IG implementation specification is essential to fulfill the use
cases envisioned for API-enabled ``read'' services for multiple
patients. The ``group-export'' ``OperationDefinition'' will allow
application developers interacting with Sec. 170.315(g)(10)-certified
Health IT Modules to export the complete set of FHIR resources as
constrained by the US Core IG adopted in Sec. 170.215(a)(2) and USCDI
adopted in Sec. 170.213 for a pre-defined cohort of patients. We
appreciate commenters' recommendations, and agree that coalescing
around a common implementation specification will advance
interoperability of API-enabled ``read'' services for multiple
patients. We provide further discussion of the supported search
operations, data response, and authentication and authorization
requirements for API-enabled ``read'' services for multiple patients in
the sections below.
Comments. Commenters requested clarification that API-enabled
``read'' services for multiple patients are not intended for patient
end users and that health IT developers and health care providers are
therefore not expected to supply a patient-facing mechanism for these
requests.
Response. We appreciate the feedback from commenters. API-enabled
``read'' services for multiple patients are not intended for patient
end users because API-enabled ``read'' services for multiple patients
allow for the disclosure of multiple patients' records, and individual
patients only have the right to access their own records or records of
patients to whom they are the personal representative (45 CFR
164.502(f)(1)). Health IT Modules are not required to support patient-
facing API-enabled ``read'' services for multiple patients for the
purposes of this certification criterion.
Comments. One commenter suggested we modify the language that
defines the purpose of this section to provide more clarity,
specifically the term ``services.'' The commenter also requested we
include the scope of cohorts we intended to address in ``population
services.''
Response. We appreciate the feedback from commenters. The term
``services'' includes all Sec. 170.315(g)(10)-related technical
capabilities included in a Health IT Module presented for testing and
certification. The API-enabled ``read'' services for single patients is
intended to support EHI requests and responses for individual patient
records and the API-enabled ``read'' services for multiple patients is
intended to support EHI requests and responses for multiple patients'
records. The scope of patient cohorts for ``population services'' can
include various groups defined at the
[[Page 25743]]
discretion of the user of the API-enabled ``read'' services for
multiple patients, including, for example, a group of patients that
meet certain disease criteria or fall under a certain insurance plan.
We have adopted the Bulk IG in Sec. 170.215(a)(4) to support this
function as discussed further below. The technical capabilities
expected of API-related Health IT Modules presented for testing and
certification are included in Sec. 170.315(g)(10).
Comments. Commenters requested clarification for information
blocking policies and health care provider obligations for API-enabled
``read'' services for multiple patients.
Response. We appreciate the request for clarification from
commenters. We clarify that the criteria finalized in Sec.
170.315(g)(10) includes the technical capabilities that must be met by
API-related Health IT Modules presented for testing and certification.
The information blocking policies in this rule do not compel health
care providers to implement Health IT Modules certified to requirements
in 170.315(g)(10). We note that other programs, like CMS value-based
programs, may require the use of this technology. We refer commenters
to the information blocking section (VIII) for additional
clarification.
Comments. Commenters asked us to clarify the relationship between
the API-enabled ``read'' services for single and multiple patients in
Sec. 170.315(g)(10) and the ``EHI export'' criterion in Sec.
170.315(b)(10).
Response. We thank commenters for this request. The API criterion
in Sec. 170.315(g)(10) is separate from the ``EHI export'' criterion
in Sec. 170.315(b)(10). While both criteria aim to advance health IT
in alignment with the Cures Act's goal of ``complete access, exchange,
and use of all electronically accessible health information'' for both
single and multiple patients, the criteria specifications and Condition
and Maintenance of Certification requirements are distinct.
The ``EHI export'' criterion focuses on a Health IT Module's
ability to electronically export EHI, as defined in Sec. 171.102, that
can be stored at the time of certification by the product, of which the
Health IT Module is a part. In contrast, the finalized API criterion in
Sec. 170.315(g)(10) focuses on ``read'' services for single and
multiple patients for the USCDI (adopted in Sec. 170.213) Data
Elements and US Core IG (adopted in Sec. 170.215(a)(2)) FHIR profiles.
Additionally, the ``EHI export'' criterion finalized in Sec.
170.315(b)(10) does not mandate conformance to standards or
implementation specifications, whereas the criterion finalized in Sec.
170.315(g)(10) requires conformance to several standards and
implementation specifications, as described further below. We refer to
the finalized ``EHI export'' criterion in Sec. 170.315(b)(10) for
additional information.
Comments. Several commenters supported requiring Health IT Modules
to support API-enabled ``write'' services for single patients, either
in this rule or in a future rulemaking. One commenter suggested
including a subset of data classes for ``write'' services for single
patients, including ``patient goals,'' ``patient-generated health
data'' (including patient-reported outcomes, patient generated device
data, and questionnaires), and ``care plans.'' Another commenter
suggested adding a list of required operations (``read'' and ``write'')
to USCDI elements, limited to ``read'' for this rulemaking.
Response. We appreciate the feedback from commenters. While we
support the interest in API-enabled ``write'' services, we have not
adopted such requirements. We do not believe API-enabled ``write''
services have reached a level of a maturity to warrant the addition of
regulatory conformance requirements within the Program. We encourage
industry to consider all the implications and implementation
requirements for API-enabled ``write'' services, and perform additional
API-enabled ``write'' pilot implementations to demonstrate the
readiness for API-enabled ``write'' services in the testing and
certification of Health IT Modules. Additionally, we encourage industry
to expand existing profiles like the US Core IG to support ``write''
services.
Comments. Commenters recommended including a requirement for event
logging for ``read'' services for single and multiple patients.
Response. We appreciate the recommendation from commenters. The
2015 Edition Privacy and Security Certification Framework requires that
if a Health IT Module includes capabilities for certification under
Sec. 170.315(g)(10) it needs to be certified to several privacy and
security certification criteria including auditable events in Sec.
170.315(d)(2) or auditing actions on health information in Sec.
170.315(d)(10).
Comments. Commenters noted that references to APIs focus
exclusively on RESTful query and ignore ``push'' elements of the FHIR
API, such as ``POST,'' ``PUT,'' and FHIR messaging.
Response. We appreciate the feedback from commenters. While we
support the interest in the ``push'' operations of the FHIR standard,
including ``POST,'' ``PUT,'' and FHIR messaging, we have not adopted
such requirements for the Program. We encourage industry stakeholders
to further consider all the requirements and implications for the
``push'' operations of the FHIR standard, develop use cases, perform
additional API-enabled ``push'' pilot implementations, create or expand
implementation profiles to support ``push'' services, and demonstrate
the utility of the ``push'' operations of the FHIR standard for future
potential inclusion in the Program.
i. Data Response
We proposed in 84 FR 7482 in Sec. 170.315(g)(10)(i) that Health IT
Modules presented for testing and certification must be capable of
responding to requests for data on single and multiple patients in
accordance with proposed standards and implementation specifications
adopted in Sec. 170.215(a)(1) (HL7[supreg] FHIR[supreg] DSTU 2
(v1.0.2-7202)), specified in the proposed Sec. 170.215(a)(2) (API
Resource Collection in Health (ARCH) Version 1), and consistent with
the proposed specifications in Sec. 170.215(a)(3) (Argonaut Data Query
Implementation Guide Version 1.0.0). We clarified that all data
elements indicated as ``mandatory'' and ``must support'' by the
proposed standards and implementation specifications must be supported
and would be in scope for testing.
Comments. Commenters expressed concern with fully enforcing
``mandatory'' and ``must'' support requirements of the referenced
specifications and implementation guides, explaining that developers
may be required to support requirements that are not applicable to the
stated intended use of the Health IT Module(s).
Response. We appreciate the concerns expressed by commenters. We
clarify that the standards and implementation specifications adopted
and required for this certification criterion were created by standards
developing organizations to support a wide range of health care use
cases.
We have finalized in Sec. 170.315(g)(10)(i)(A) that Health IT
Modules presented for testing and certification must be capable of
responding to requests for a single patient's data according to the
standard adopted in Sec. 170.215(a)(1) and implementation
specification adopted in Sec. 170.215(a)(2), including the mandatory
capabilities described in ``US Core Server CapabilityStatement,'' for
each of the Data Elements included in the standard adopted in Sec.
170.213. This requirement will enable Health IT Modules to support US
Core IG
[[Page 25744]]
operations for each of the Data Elements included in the USCDI.
Additionally, we have finalized in Sec. 170.315(g)(10)(i)(B) that
Health IT Modules presented for testing and certification must be
capable of responding to requests for data on multiple patients as a
group according to the standard adopted in Sec. 170.215(a)(1) and
implementation specifications adopted in Sec. 170.215(a)(2) and Sec.
170.215(a)(4), for each of the Data Elements included in the standard
adopted in Sec. 170.213. Finally, we clarify that the use of the
``SMART Backend Services: Authorization Guide'' section of the
implementation specification adopted in Sec. 170.215(a)(4) is required
for API ``read'' services for multiple patients as finalized in Sec.
170.315(g)(10)(i)(B) and described above.
For requests for data on multiple patients, we note that the
implementation specification adopted in Sec. 170.215(a)(4) has
optional parameters which can be used to filter results to a period of
time, or one or several specified FHIR resources. While these
parameters are not required for testing and certification, we encourage
health IT developers to adopt these parameters and other
``OperationDefinitions'' to enhance the utility of requests for data on
multiple patients.
ii. Search Support
We proposed in 84 FR 7482 in Sec. 170.315(g)(10)(ii) that Health
IT Modules presented for testing and certification must be capable of
responding to all of the ``supported searches'' specified in the
proposed implementation specification in Sec. 170.215(a)(4) (Argonaut
Data Query Implementation Guide Server). We reiterated that Health IT
Modules presented for testing and certification and as implemented must
support all search capabilities for single and multiple patients in
accordance with the proposed implementation specification in Sec.
170.215(a)(4). We also requested comments on the minimum ``search''
parameters that would need to be supported for the
''DocumentReference'' and ``Provenance'' HL7[supreg] FHIR[supreg]
resources.
Comments. Most commenters supported this proposal. One commenter
recommended only requiring the ``target'' query parameter for the
``Provenance'' FHIR resource, and ``patient'' and ``date'' query
parameters for the ``DocumentReference'' FHIR resource. One commenter
suggested deferring this certification requirement until a standard is
published by HL7.
Response. We appreciate the feedback from commenters. Since we have
not finalized the adoption of the ARCH as proposed in Sec.
170.215(a)(2), and instead rely on the search parameters specified in
the US Core IG finalized in Sec. 170.215(a)(2) and Bulk IG finalized
in Sec. 170.215(a)(4), the comments related to the specific
``Provenance'' and ``DocumentReference'' FHIR resources are no longer
applicable. We have finalized in Sec. 170.315(g)(10)(ii)(A) that
Health IT Modules presented for testing and certification must support
all search capabilities for single patients according to the
implementation specification adopted in Sec. 170.215(a)(2), including
support for all mandatory capabilities included in the ``US Core Server
CapabilityStatement.'' Additionally, we have finalized in Sec.
170.315(g)(10)(ii)(B) that Health IT Modules presented for testing and
certification must respond to search requests for multiple patients'
data consistent with the search criteria included in the implementation
specification adopted in Sec. 170.215(a)(4). We clarify that the scope
of data available in the data responses defined in Sec.
170.315(g)(10)(i) must be supported for single and multiple patient
searches via the supported search operations finalized in Sec.
170.315(g)(10)(ii). Additionally, we clarify for the requirements
finalized in Sec. 170.315(g)(10)(i) and (ii) that all data elements
indicated as ``mandatory,'' ``must support,'' by the standards and
implementation specifications must be supported and are in scope for
testing.
iii. Application Registration
We proposed in 84 FR 7483 in Sec. 170.315(g)(10)(iii) that Health
IT Modules presented for testing and certification must be capable of
enabling apps to register with an ``authorization server.'' As
proposed, this would have required an API Technology Supplier to
demonstrate its registration process, but would not have required
conformance to a standard. We requested comment at 84 FR 7483 on
whether to require the OAuth 2.0 Dynamic Client Registration Protocol
(RFC 7591) \103\ standard as the sole method to support registration
for the proposed certification criterion in Sec. 170.315(g)(10), and
requested comment on whether we should require its support as part of
the final rule's certification criterion. Additionally, we requested
comment at 84 FR 7483 on whether to include application registration in
the testing and certification of apps executed within an API Data
Provider's clinical environment.
---------------------------------------------------------------------------
\103\ https://tools.ietf.org/html/rfc7591.
---------------------------------------------------------------------------
Comments. Commenters generally supported that Health IT Modules
presented for testing and certification must enable apps to register
with an authorization server. Some commenters supported excluding
application registration from the testing and certification of apps
executed within an API Data Provider's clinical environment.
Response. We appreciate the feedback from commenters. Given the
overwhelming support, we have finalized in Sec. 170.315(g)(10)(iii)
that Health IT Modules presented for testing and certification must
enable apps to register with an authorization server. We clarify that
Health IT Modules presented for testing and certification must support
application registration regardless of the scope of patient search
utilized by the application (e.g., single or multiple). This
certification criterion requires a health IT developer, as finalized in
the Condition of Certification requirements section below, to
demonstrate its registration process, but does not require conformance
to a standard. Additionally, we expect that apps executed within an
implementer's clinical environment will be registered with an
authorization server, but we do not require a health IT developer to
demonstrate its registration process for these ``provider-facing''
apps. We reiterate that we believe implementers of Sec.
170.315(g)(10)-certified Health IT Modules should have the discretion
to innovate and execute various methods for application registration
within a clinical environment.
Comments. Commenters provided a mix of support and opposition for
requiring the OAuth 2.0 Dynamic Client Registration Protocol (RFC 7591)
standard as the sole method of application registration. Some
commenters felt that the Program should require dynamic client
registration in the context of patient-access scenarios only, and
others felt the standard is not ready for mandated adoption in the
Program. Commenters opposed to requiring the OAuth 2.0 Dynamic Client
Registration Protocol (RFC 7591) felt that not specifying a standard
would allow flexibility for different innovative registration
approaches to be used and developed. Other commenters suggested there
should be an option for data holders to support dynamic client
application registration if the data holder prefers that approach,
including support for dynamic application registration via trusted
networks.
[[Page 25745]]
Response. We appreciate the feedback from commenters. We have not
adopted a requirement for Health IT Modules presented for testing and
certification to support the OAuth 2.0 Dynamic Client Registration
Protocol (RFC 7591) standard. We agree with commenters and believe that
requiring registration without a mandated standard will allow
registration models to develop further. We encourage health IT
developers to coalesce around the development and implementation of a
common standard for application registration with an API's
authorization server.
Comments. Commenters suggested permitting implementers of Sec.
170.315(g)(10)-certified Health IT Modules to undertake a review of
third-party applications prior to permitting them to connect to the
implementers' deployed APIs.
Response. We appreciate the suggestion from commenters. The
requirement that health IT developers must enable an application to
register with the Sec. 170.315(g)(10)-certified Health IT Module's
authorization server only applies for the purposes of demonstrating
technical conformance to the finalized certification criterion and
Condition and Maintenance of Certification requirements. The practices
by all parties (including implementers of Health IT Modules) other than
developers of certified Health IT Modules are not in scope for this
certification criterion nor the associated Condition and Maintenance of
Certification requirements. All other practices associated with third-
party application review or ``vetting'' by implementers must not
violate the information blocking provision described in section VIII of
this preamble and applicable laws and regulations. In general, an
implementer of Sec. 170.315(g)(10)-certified Health IT Modules (e.g.,
health care providers) would be allowed to review third-party
applications the implementer intends to use for its own business use
(e.g., a third-party decision-support application used by the health
care provider in the course of furnishing care) prior to permitting the
third-party applications to connect to the implementer's deployed APIs
within its enterprise and clinical users' workflow. However,
implementers of Sec. 170.315(g)(10)-certified Health IT Modules (e.g.,
health care providers) are not permitted to review or ``vet'' third-
party applications intended for patient access and use (see section
VII.C.6 of this preamble). We clarify that the third-party application
registration process that a health IT developer must meet under this
criterion is not a form of review or ``vetting'' for purposes of this
criterion.
Comments. Commenters requested clarity on whether the ``EHR
Launch'' scenario was out of scope for testing during registration with
an authorization server.
Response. Commenters referred to the ``EHR Launch'' scenario, which
is the ``launch-ehr'' ``SMART on FHIR Core Capability'' included in the
implementation specification adopted in Sec. 170.215(a)(3). Health IT
Modules presented for testing and certification must enable all apps
that utilize the SMART IG ``launch-standalone'' ``SMART on FHIR Core
Capability'' to register with an authorization server. We reiterate
that the application registration requirement finalized in Sec.
170.315(g)(10)(iii) does not require conformance to a standard or
implementation specification. We envision that apps using only the
SMART IG ``launch-ehr'' ``SMART on FHIR Core Capability'' will be
tightly integrated with Sec. 170.315(g)(10)-certified Health IT
Modules deployed by implementers, and will be able to accommodate
registration processes that best suit the needs of those implementers.
Additionally, while we do not require conformance to a standard or
implementation specification for application registration, we clarify
that Health IT Modules presented for testing and certification are
required to support application registration functions to enable
authentication and authorization as finalized in Sec.
170.315(g)(10)(v).
iv. Secure Connection
We proposed in 84 FR 7483 in Sec. 170.315(g)(10)(iv) that Health
IT Modules presented for testing and certification must be capable of
establishing a secure and trusted connection with an application
requesting patient data in accordance with the proposed Sec.
170.215(a)(5) (HL7 SMART Application Launch Framework Implementation
Guide Release 1.0.0), including mandatory support for ``Standalone
Launch'' and ``EHR Launch'' modes.
Comments. Commenters asked for clarification around where
``Standalone Launch'' and ``EHR Launch'' capabilities are required,
suggesting that ``Standalone Launch'' support be used exclusively for
patient access and ``EHR Launch'' support be used exclusively for
provider/clinician access. They also noted that testing and
certification of ``Standalone Launch'' would not be a valid use case
and should be excluded from the certification criterion.
Response. We appreciate the feedback from commenters. The SMART IG
``Standalone Launch'' and ``EHR Launch'' modes can be used by both
provider- and patient-facing applications. We refer to the adopted
implementation specification in Sec. 170.215(a)(3) for clarification
of certification requirements for the SMART IG. We have finalized in
Sec. 170.315(g)(10)(iv)(A) that Health IT Modules presented for
testing and certification must demonstrate the ability to establish a
secure and trusted connection with an application requesting data for a
single patient in accordance with the implementation specifications
adopted in Sec. 170.215(a)(2) and (a)(3). We amended this text from
the Proposed Rule by adding the US Core IG implementation specification
adopted in Sec. 170.215(a)(2) because the US Core IG specifically
requires Transport Layer Security 1.2 (RFC 5246) \104\ or higher for
all transmissions not taking place over a secure network connection.
Pursuant to this adopted implementation specification, we will test
Health IT Modules for support for all ``SMART on FHIR Core
Capabilities'' including both ``launch-ehr'' and ``launch-standalone.''
---------------------------------------------------------------------------
\104\ https://tools.ietf.org/html/rfc5246.
---------------------------------------------------------------------------
Additionally, we have finalized in Sec. 170.315(g)(10)(iv)(B) that
Health IT Modules presented for testing and certification must
demonstrate the ability to establish a secure and trusted connection
with an application requesting data for multiple patients in accordance
with the implementation specification adopted in Sec. 170.215(a)(4).
The implementation specification adopted in Sec. 170.215(a)(4) has
several sections, but for testing and certification to this criterion,
we specifically require conformance to, but not limited to, the ``SMART
Backend Services: Authorization Guide.''
v. Authentication and Authorization
We proposed in 84 FR 7483 in Sec. 170.315(g)(10)(v) that Health IT
Modules presented for testing and certification must demonstrate the
ability to perform user authentication, user authorization, and issue a
refresh token valid for a period of at least 3 months during its
initial connection with an application to access data for a single
patient in accordance with the proposed standard in Sec. 170.215(b)
(OpenID Connect Core 1.0 incorporating errata set 1) and the proposed
implementation specification in Sec. 170.215(a)(5) (HL7[supreg] SMART
Application Launch Framework Implementation Guide Release 1.0.0).
[[Page 25746]]
Additionally, we proposed in Sec. 170.315(g)(10)(vi) that Health IT
Modules presented for testing and certification must demonstrate the
ability of an application to access data for a single patient and
multiple patients during subsequent connections of applications capable
of storing a client secret, in accordance with the proposed
implementation specification in Sec. 170.215(a)(5) (HL7 SMART
Application Launch Framework Implementation Guide Release 1.0.0),
without requiring the user to re-authorize and re-authenticate when a
valid refresh token is supplied. Additionally, we proposed in 84 FR
7483 that Health IT Modules presented for testing and certification
must demonstrate it can issue a new refresh token to an application,
valid for a period of at least 3 months.
Comments. A majority of commenters supported that Health IT Modules
presented for testing and certification must demonstrate the ability to
perform user authentication, user authorization, and issue a refresh
token valid for a period of at least 3 months. Some commenters noted
that the OAuth 2.0 implementation guide does not recommend servers
provide refresh tokens to public/non-confidential applications.
Response. We thank commenters for their feedback. Given the general
support and in response to these comments, we have consolidated the
proposed requirements in Sec. 170.315(g)(10)(v) and Sec.
170.315(g)(10)(vi) as a revised set of requirements finalized in Sec.
170.315(g)(10)(v). Specifically, we have finalized requirements for
authentication and authorization for patient and user scopes in Sec.
170.315(g)(10)(v)(A) and requirements for authentication and
authorization for system scopes in Sec. 170.315(g)(10)(v)(B). We have
focused the revised requirements around authentication and
authorization scopes to remove any confusion associated with
requirements for single and multiple patients. We have finalized
authentication and authorization requirements for first time
connections for patient and user scopes in Sec.
170.315(g)(10)(v)(A)(1). This include the requirement finalized in
Sec. 170.315(g)(10)(v)(A)(1)(i) that Health IT Modules presented for
testing and certification must demonstrate that authentication and
authorization occurs during the process of granting access to patient
data in accordance with the implementation specification adopted in
Sec. 170.215(a)(3) and standard adopted in Sec. 170.215(b). It also
includes the requirement finalized in Sec. 170.315(g)(10)(v)(A)(1)(ii)
that an application capable of storing a client secret must be issued a
refresh token valid for a period of no less than three months.
Additionally, we have finalized authentication and authorization
requirements for subsequent connections for patient and user scopes in
Sec. 170.315(g)(10)(v)(A)(2). This includes the requirements finalized
in Sec. 170.315(g)(10)(v)(A)(2)(i) that Health IT Modules presented
for testing and certification must demonstrate that access is granted
to patient data in accordance with the implementation specification
adopted in Sec. 170.215(a)(3) without requiring re-authorization and
re-authentication when a valid refresh token is supplied by the
application. It also includes the requirements finalized in Sec.
170.315(g)(10)(v)(A)(2)(ii) that an application capable of storing a
client secret must be issued a new refresh token valid for a new period
of no less than three months.
Additionally, we have finalized requirements for authentication and
authorization for system scopes in Sec. 170.315(g)(10)(v)(B), which
require that Health IT Modules presented for testing and certification
must demonstrate that authentication and authorization occurs during
the process of granting an application access to patient data in
accordance with the ``SMART Backend Services: Authorization Guide''
section of the implementation specification adopted in Sec.
170.215(a)(4) and the application must be issued a valid access token.
We note that for system scopes, applications will likely be authorized
via a prior authorization negotiation and agreement between
applications and Health IT Modules.
For clarity, we use the term ``an application capable of storing a
client secret'' to refer to ``confidential clients.'' In the definition
at RFC 6749, ``confidential'' clients are ``clients capable of
maintaining the confidentiality of their credentials (e.g., client
implemented on a secure server with restricted access to the client
credentials), or capable of secure client authentication using other
means.'' RFC 6749 also defines ``public'' clients as ``clients
incapable of maintaining the confidentiality of their credentials
(e.g., clients executing on the device used by the resource owner, such
as an installed native application or a web browser-based application),
and incapable of secure client authentication via any other means.'' We
clarify that the term ``an application capable of storing a client
secret'' specifically excludes ``public'' clients.
Additionally, we clarify that Health IT Modules will be explicitly
tested for US Core IG operations using authentication and authorization
tokens acquired via the process described in the implementation
specification adopted in Sec. 170.215(a)(3), and Health IT Modules
will be explicitly tested for Bulk IG operations using authentication
and authorization tokens acquired via the process described in the
implementation specification adopted in Sec. 170.215(a)(4).
Comments. One commenter recommended that ONC introduce a Condition
of Certification requirement to ensure that implementers of Sec.
170.315(g)(10)-certified Health IT Modules can obtain automated system-
level access to all API calls from the API servers offered by the
Certified Health IT Developers (e.g., via the SMART Backend Services
authorization guide), with ``system/*.*'' scopes.
Response. We decline to accept the recommendation to require
``system/*.*'' scopes as a certification requirement in Sec.
170.315(g)(10). Insofar as the commenter requested that Health IT
Modules make available automated system-level scopes for the purposes
of an ``all information export,'' we have finalized a similar
requirement in Sec. 170.315(b)(10), and refer the commenter to that
section for additional detail. Additionally, we have finalized in Sec.
170.315(g)(10)(v)(B) that Health IT Modules must perform authentication
and authorization during the process of granting an application access
to patient data using system scopes in accordance with the ``SMART
Backend Services: Authorization Guide'' section of the implementation
specification adopted in Sec. 170.215(a)(4). We recognize that the
capabilities supported by ``SMART Backend Services: Authorization
Guide'' could be used for many other use cases that are currently not
required by the criterion. We clarify that implementers of Health IT
Modules are not prohibited from configuring Health IT Modules to
support the backend ``system'' scope described in the ``SMART Backend
Services: Authorization Guide'' section of the Bulk IG adopted in Sec.
170.215(a)(4) for API-enabled ``read'' services defined in the US Core
IG. Indeed, we strongly encourage health IT developers to support these
use cases as they develop in order to make full use of the certified
functions of Health IT Modules and advance the state of the industry.
Comments. Commenters suggested specifying that refresh tokens apply
exclusively to patient access scenarios, noting that there are too many
security risks to allow persistent tokens for provider-facing
applications.
[[Page 25747]]
Additionally, commenters suggested permitting Health IT Modules to
support the revocation of refresh tokens in appropriate scenarios to
address legitimate security concerns.
Response. We appreciate the feedback from commenters. We do not
agree that there are too many security risks to allow refresh tokens to
be used for provider-facing applications. Refresh tokens are commonly
used in health care and other industries to provide seamless
integration of systems with other applications while reducing the need
for the burdensome process of re-authentication and re-authorization.
We expect implementers of Sec. 170.315(g)(10)-certified Health IT
Modules to have the capability of revoking refresh tokens where
appropriate. Additionally, we clarify that implementers of Sec.
170.315(g)(10)-certified Health IT Modules are not prohibited from
changing the length of refresh tokens for users of the API including
patients and providers to align with their institutional policies.
However, implementers of Sec. 170.315(g)(10)-certified Health IT
Modules should be mindful of information blocking provisions applicable
to them and that requiring patients to re-authenticate and re-authorize
at a high frequency could inhibit patient access and implicate
information blocking.
Comments. Commenters suggested amending the time from three months
to 12 months. One commenter agreed that the patient token should be
valid for three months, but suggested the provider token be limited to
24 hours. One commenter suggested requiring re-authentication every
time information is sought via APIs.
Response. We appreciate the feedback from commenters. We believe a
refresh token valid for a period of three months is sufficient to
balance persistent access and security concerns. Moreover, for
subsequent connections of applications capable of storing a client
secret, Health IT Modules are required to issue a new refresh token
valid for a new period of no shorter than three months per the API
certification criterion requirement finalized in Sec.
170.315(g)(10)(v)(A)(2)(ii). Given this requirement, we anticipate that
the user's application will renew its refresh token (valid for a new
period of three months) every time the user actively engages with the
application. We believe this justifies a refresh token length for a
moderate period of no shorter than three months rather than a long
period of 12 months suggested by commenters. Additionally, as stated
above, implementers of Sec. 170.315(g)(10)-certified Health IT Modules
are not prohibited from changing the length of refresh tokens for users
of the API, including patients and providers, to align with their
institutional policies. Further, implementers of Sec. 170.315(g)(10)-
certified Health IT Modules are not prohibited from implementing their
Sec. 170.315(g)(10)-certified Health IT Modules in accordance with
their organizational security policies and posture, including by
instituting policies for re-authentication and re-authorization (e.g.,
providers and/or patients could always be required to re-authenticate
and re-authorize after a set number of refresh tokens have been
issued). We also note that we have finalized a requirement in Sec.
170.315(g)(10)(vi) that a Health IT Module's authorization server must
be able to revoke an authorized application's access at a patient's
direction. This required capability will enable patients to
definitively revoke an application's authorization to receive their EHI
until reauthorized, if ever, by the patient.
Comments. Commenters suggested creating a more robust assessment
process for identity management, including adding additional criteria
for identity proofing, authentication, and authorization, and ensuring
software developers do not act in a way that could inhibit patient
control of their data.
Response. We appreciate the feedback and suggestions. Although we
agree that identity proofing is an important practice, we did not
include requirements for identity proofing in the Proposed Rule, and
have not finalized requirements for identity proofing in response to
this comment. We note that the certification criterion finalized in
Sec. 170.315(g)(10) only applies to health IT developers. Given the
scope of the Program, we believe that mandating identity proofing,
which are generally business practices performed by organizations and
other entities, is not something appropriate to require of health IT
developers. We note that per the requirements of the 2015 Edition
Privacy and Security Certification Framework, health IT developers with
Health IT Modules certified to Sec. 170.315(g)(7) through (g)(10) are
required to certify to Sec. 170.315(d)(1), which includes requirements
for authentication, access control, and authorization. Additionally,
authentication and authorization for use of Sec. 170.315(g)(10)-
certified Health IT Modules are included in the requirements finalized
in Sec. 170.315(g)(10)(v). We appreciate the sentiment expressed by
commenters, and have created thorough and rigorous requirements to
ensure adequate privacy and security capabilities are present in Sec.
170.315(g)(10)-certified Health IT Modules. Regarding the request for
certification requirements to ensure that software developers do not
act in a way that could inhibit patient control of their data, we refer
to the requirement finalized in Sec. 170.315(g)(10)(A), which requires
that patients have the ability to grant applications authorization to
access their EHI using granular FHIR Resources of their choice to
comply with the adopted implementation specification in Sec.
170.215(a)(3), and requirement in Sec. 170.315(g)(10)(vi), which
requires that a Health IT Module's authorization server must be able to
revoke an authorized application's access at a patient's direction.
Comments. Several commenters suggested that patients be able to
specify refresh token length, if desired, and revoke a third-party
application's access at any time. Commenters suggested that clear
information be provided to patients whether authorized access is one-
time or ongoing.
Response. We appreciate the feedback from commenters. Refresh
tokens are an OAuth 2.0 concept, and are largely opaque to the end
user. However, we clarify that patients are not prohibited from
changing the length of refresh tokens to the degree this option is
available to them. Additionally, pursuant to these comments, and to
ensure patients have the ability to revoke an application's access to
their EHI at any time, we have finalized an additional certification
requirement in Sec. 170.315(g)(10)(vi) which requires that a Health IT
Module's authorization server must be able to revoke an authorized
application's access at a patient's direction. We have finalized this
as a functional requirement to allow health IT developers the ability
to implement it in a way that best suits their existing infrastructure
and allows for innovative models for authorization revocation to
develop. Additionally, per the requirement finalized in Sec.
170.315(g)(10)(v)(A), Health IT Modules must perform authorization
conformant with the implementation specification adopted in Sec.
170.215(a)(3), including all ``SMART on FHIR Core Capabilities.'' The
``permission-offline'' ``SMART on FHIR Core Capability'' includes
support for the ``offline_access'' scope. Importantly, the
implementation specification adopted in Sec. 170.215(a)(3) requires
that patients have the ability to explicitly enable the
``offline_access'' scope during authorization. If the
``offline_access'' scope is not enabled by patients, patients will be
required to re-
[[Page 25748]]
authenticate and re-authorize an application's access to their EHI
after the application's access token expires.
Comments. Commenters suggested providing the ability for
implementers of Sec. 170.315(g)(10)-certified Health IT Modules to
perform token introspection using services enabled by health IT
developers to ensure that additional resource servers can work with the
same access tokens and authorization policies as the resource servers
provided by API Technology Suppliers.
Response. We appreciate the feedback from commenters. Based on
feedback, we have finalized in Sec. 170.315(g)(10)(vii) that Health IT
Modules presented for testing and certification must demonstrate the
ability to receive and validate a token issued by its authorization
server, but we did not specify a standard for this requirement. Token
introspection will allow implementers of Sec. 170.315(g)(10)-certified
Health IT Modules to use API authorization servers and authorization
tokens with various resource servers. This functionality has the
potential to reduce complexity for implementers of Sec.
170.315(g)(10)-certified Health IT Modules authorizing access to
several resource servers and reduces the overall effort and subsequent
use of Sec. 170.315(g)(10)-certified Health IT Modules consistent with
the goals of section 4002 of the Cures Act to enable the use of APIs
without ``special effort.'' Although we do not specify a standard for
token introspection, we encourage industry to coalesce around using a
common standard, like OAuth 2.0 Token Introspection (RFC 7662).\105\
---------------------------------------------------------------------------
\105\ https://tools.ietf.org/html/rfc7662.
---------------------------------------------------------------------------
Comments. One commenter expressed concerns with the privacy and
security of APIs, and nefarious actors posing as legitimate health
facilities.
Response. Regarding the privacy and security of APIs, the
Standardized API for Patient and Population Services certification
criterion finalized in Sec. 170.315(g)(10) requires Health IT Modules
presented for testing and certification to implement the implementation
specification adopted in Sec. 170.215(a)(3), which is based on the
OAuth 2.0 security standard that is widely used in industry. The
implementation of OpenID Connect paired with OAuth 2.0 allows health
care providers to securely deploy and manage APIs consistent with their
organizational practices. Health care providers retain control over how
their workforce and patients authenticate when interacting with the
API. For example, a patient may be required to use the same credentials
(e.g., username and password) they created and use to access their EHI
through a patient portal as they do when authorizing an application to
access their data. Since patients complete the authentication process
directly with their health care provider, no application will have
access to their credentials. There is little protection software can
provide to protect against nefarious actors posing as legitimate health
facilities, however, we believe that implementing the security controls
and safeguards described above, along with the privacy and security
requirements required under the 2015 Edition Privacy and Security
Certification Framework, will help to protect Health IT Modules against
nefarious actors. Additionally, the protections required for ePHI in
Health IT Modules offered by health IT developers acting as business
associates of health care providers remain unchanged.
vi. Technical Documentation
We proposed in 84 FR 7484 in Sec. 170.315(g)(10)(vii) that an API
Technology Supplier needed to provide complete documentation via a
publicly accessible hyperlink, without additional access requirements,
for all aspects of its Sec. 170.315(g)(10)-certified API, especially
for any unique technical requirements and configurations, including API
syntax, function names, required and optional parameters supported and
their data types, return variables and their types/structures,
exceptions and exception handling methods and their returns, the
software components and configurations necessary for an application to
successfully interact with the API and process its response(s), and all
applicable technical requirements and attributes necessary for an
application to be registered with an authorization server.
Additionally, we proposed in 84 FR 7484 to remove the ``terms of use''
documentation provisions in the API certification criteria adopted in
Sec. 170.315(g)(7) through (g)(9) in order to reflect the Condition of
Certification requirements and not be duplicative of the terms and
conditions transparency Condition of Certification requirements
proposed in 84 FR 7485.
Comments. Commenters generally supported the requirements for this
criterion as proposed. Some commenters suggested technical
documentation should be limited to descriptions of how the API differs
from the utilized standards and implementation specifications, like
HL7[supreg] FHIR[supreg] and the SMART IG.
Response. We appreciate the feedback from commenters. We did not
make substantive changes to the requirements proposed in Sec.
170.315(g)(10)(vii). We have finalized these requirements Sec.
170.315(g)(10)(viii). We recognize that our formal adoption of the HL7
FHIR standard and the associated implementation specifications
referenced in Sec. 170.315(g)(10) would be consistent across all
Health IT Modules presented for certification. As a result, there may
be minimal additional documentation needed for these capabilities
beyond what is already documented in adopted standards and
implementation specifications. We expect health IT developers to
disclose any additional data their Sec. 170.315(g)(10)-certified
Health IT Module supports in the context of the adopted standards and
implementation specifications. The content of technical documentation
required to meet this certification criteria are described in
requirements finalized in Sec. 170.315(g)(10)(viii)(A). We expect
these and any additional documentation relevant to the use of a health
IT developer's Sec. 170.315(g)(10)-certified Health IT Module to be
made available via a publicly accessible hyperlink without
preconditions or additional steps to meet the requirement as finalized
in Sec. 170.315(g)(10)(viii)(B).
d. API Condition of Certification Requirements
i. Key Terms
We proposed in 84 FR 7477 to adopt new definitions for ``API
Technology Supplier,'' ``API Data Provider,'' and ``API User'' in Sec.
170.102 to describe the stakeholders relevant to our proposals.
Comments. The majority of commenters recommended updating
definitions and providing examples for the key terms, including API
User. Most commenters recommended dividing ``API User'' into two
categories: ``First-Order Users,'' to include patients, health care
providers, and payers that use apps/services that connect to API
technology, and ``Third-Party Users,'' to include third-party software
developers, and developers of software applications used by API Data
Providers.
Response. We thank commenters for their feedback. We note that in
this section we use the terms proposed in Sec. 170.102 that we
finalized in Sec. 170.404(c) with added quotation marks for emphasis
and clarity. We considered separating the term ``API User'' into
distinct terms for developers of software applications and other users,
such as patients and health care providers. However, we determined that
this distinction was unnecessary from a regulatory perspective.
Narrowing our
[[Page 25749]]
definitions to distinct subgroups could exclude unforeseen stakeholders
that emerge in a future API ecosystem. The term ``API User'' was
intended to describe stakeholders that interact with the certified API
technology either directly (e.g., to develop third-party apps/services)
or indirectly (e.g., as a user of a third-party app/service).
Based on suggestions to revise the proposed key terms, we have
renamed the term ``API Data Provider'' to ``API Information Source''
finalized in Sec. 170.404(c) to make clear which party is the source
and responsible for the EHI (as in ``the source of the information is
the health care provider''), and ``API Technology Supplier'' to
``Certified API Developer'' finalized in Sec. 170.404(c) to more
clearly refer to health IT developers with Health IT Modules certified
to any of the API criteria under the Program. Rather than keeping ``API
technology'' an undefined term, we renamed it to ``certified API
technology'' and finalized a definition in Sec. 170.404(c).
Additionally, we amended the definition of ``API User'' for clarity in
Sec. 170.404(c) to ``API User means a person or entity that creates or
uses software applications that interact with the `certified API
technology' developed by a `Certified API Developer' and deployed by an
`API Information Source.''' Additionally, we did not include the non-
exhaustive list of examples of ``API User'' in the definition finalized
in Sec. 170.404(c). Instead, we rely on preamble to provide guidance
for examples of ``API Users'' rather than appearing to limit the
regulatory definition to these examples. We interpret that ``API
Users'' can include, but are not limited to, software developers,
patients, health care providers, and payers. We simplified the
definition of ``API Information Source'' in Sec. 170.404(c) to ``API
Information Source means an organization that deploys `certified API
technology' created by a `Certified API Developer.''' We revised the
definition of ``Certified API Developer'' in Sec. 170.404(c) to
``Certified API Developer means a health IT developer that creates the
`certified API technology' that is certified to any of the
certification criteria adopted in Sec. 170.315(g)(7) through (10).''
We added the definition of ``certified API technology'' in Sec.
170.404(c) as ``certified API technology means the capabilities of
Health IT Modules that are certified to any of the API-focused
certification criteria adopted in Sec. 170.315(g)(7) through (10).''
For ease of reference and to clarify that these terms only apply to the
Condition and Maintenance of Certification requirements, we have
finalized these revised definitions in Sec. 170.404(c). In this and
other sections of the rule, we use the original proposed terms in the
proposal and comment summaries, and the finalized terms in our
responses.
Comments. Some commenters suggested ONC allow flexibility for
instances where stakeholders may meet the definition of more than one
key term, and others recommended restricting stakeholders from meeting
the definition of more than one key term. Commenters expressed concern
with the complexity of key terms in the Proposed Rule, and confusion
with the interaction of these terms with other criteria within the
rule.
Response. We thank commenters for expressing their concern about
stakeholders being able to serve more than one role under the
definitions proposed in Sec. 170.102 that we have finalized in Sec.
170.404(c). We do not believe it is practical to restrict persons or
entities to just one definition. We anticipate situations where a
person or entity can serve more than one role. For example, a large
health care system could purchase and deploy ``certified API
technology'' as an ``API Information Source'' and have ``API Users'' on
staff that create or use software applications that interact with the
``certified API technology.'' Additionally, a health IT developer could
serve as a ``Certified API Developer'' that creates ``certified API
technology'' for testing and certification and as an ``API User'' when
it creates software applications that connect to ``certified API
technology.'' We clarify that a stakeholder will meet a role defined in
Sec. 170.404(c) based on the context in which they are acting. For
example, only health IT developers (when acting in the context of a
``Certified API Developer'') are required to comply with these API
Condition and Maintenance of Certification requirements.
Comments. Commenters expressed concern that ONC exceeded its
regulatory authority by implicating physicians in the definition of
``API Data Providers.''
Response. We remind commenters that these definitions were created
to describe relationships between key API stakeholders and to help
describe the Condition and Maintenance of Certification requirements.
We clarify that health care providers are not covered by the Condition
and Maintenance of Certification requirements to which the definitions
apply in Sec. 170.404(c) unless they are serving the role of a
``Certified API Developer.
ii. Scope and Compliance
We proposed in 84 FR 7485 that the Condition and Maintenance of
Certification requirements proposed in Sec. 170.404 apply to API
Technology Suppliers with Health IT Modules certified to any API-
focused certification criteria adopted in the proposed Sec.
170.315(g)(7) through (11).
Comments. Commenters agreed that the proposed applicability for the
Condition of Certification requirements proposed in Sec. 170.404
should be limited to health IT developers certified to any API-focused
criteria adopted in the proposed Sec. 170.315(g)(7) through (11). One
commenter requested clarification whether non-certified internally
developed laboratory systems would be subject to this requirement.
Response. We thank stakeholders for their comments. We have
generally finalized the scope and compliance for the Condition and
Maintenance of Certification requirements as proposed in Sec. 170.404
with one modification. Given that we have not adopted the certification
criterion proposed for adoption in Sec. 170.315(g)(11), the scope of
the Condition and Maintenance of Certification requirements apply only
to health IT developers with Health IT Modules certified to any of the
API-focused criteria finalized in Sec. 170.315(g)(7) through (10). The
Condition and Maintenance of Certification requirements finalized in
Sec. 170.404 do not apply to health IT developers not seeking
certification, nor do they apply to health IT developers certified to
solely non-API-focused criteria. Additionally, we clarify that the
Condition and Maintenance of Certification requirements only apply to
practices of Certified API Developers with respect to the capabilities
included in Sec. 170.315(g)(7) through (10). In other words, the
Condition and Maintenance of Certification requirements would not apply
to practices of Certified API Developers with respect to non-certified
capabilities or practices associated with, for example, the
immunization reporting certification criterion in Sec. 170.315(f)(1),
because that criterion is not one of the API-focused criteria finalized
in Sec. 170.315(g)(7) through (10). However, health IT developers
should understand that other requirements in this final rule,
especially those related to information blocking, could still apply to
its business practices associated with non-API-focused certification
criteria.
iii. General
We proposed in 84 FR 7485 in Sec. 170.404(a)(1) to adopt the Cures
Act's
[[Page 25750]]
API Condition of Certification requirement stating that an API
Technology Supplier must, through an API, ``provide access to all data
elements of a patient's electronic health record to the extent
permissible under applicable privacy laws.'' We then subsequently
proposed in 84 FR 7485 to interpret ``all data of a patient's
electronic health record'' for the purposes of the scope of this API
Condition of Certification requirement to include the proposed ARCH
standard, its associated implementation specifications, and the policy
expressed around the data elements that must be supported by Sec.
170.315(g)(10)-certified APIs.
Comments. Commenters supported our adoption of the Cures Act's API
Condition of Certification requirement. For the purposes of the scope
of data covered under this API Condition of Certification requirement,
most commenters recommended defining ``all data elements'' as the Data
Elements referenced by the USCDI and the FHIR resources in the FHIR US
Core Implementation Guide STU 3 (US Core IG) for FHIR Release 4. We
received comments recommending additional data elements to be included
that we discuss in our comment summary for the ARCH in the ``API
Standards, Implementation Specifications, and Certification Criterion''
section of this final rule.
Response. We appreciate stakeholder feedback. The Sec.
170.315(g)(10) certification criterion requirement and associated
standards and implementation specifications will enable secure,
standards-based API access to a specific set of information. We have
finalized that a Certified API Developer must publish APIs, and must
allow EHI from such technology to be accessed, exchanged, and used
without special effort through the use of APIs or successor technology
or standards, as provided for under applicable law, including providing
access to all data elements of a patient's electronic health record to
the extent permissible under applicable privacy laws, in Sec.
170.404(a)(1). Additionally, for the purposes of meeting this portion
of the Cures Act's API Condition of Certification requirement, we
clarify the data required and that must be supported to demonstrate
conformance to the final Sec. 170.315(g)(10) certification criterion
(including all of its associated standards and implementation
specifications) constitutes ``all data elements of a patient's
electronic health record to the extent permissible under applicable
privacy laws.'' Regarding the recommendation by commenters that the
scope of ``all data elements'' include the Data Elements of the
standard adopted in Sec. 170.213 and FHIR resources referenced by the
implementation specification adopted in Sec. 170.215(a)(2), we note
that both the standard and implementation specification are included in
the interpretation of ``all data elements of a patient's electronic
health record to the extent permissible under applicable privacy laws''
above. We note that this specific interpretation does not extend beyond
the API Condition and Maintenance of Certification requirements
finalized in Sec. 170.404 and cannot be inferred to reduce the scope
or applicability of other Cures Act Conditions of Certification or the
information blocking policies, which include a larger scope of data.
iv. Transparency Conditions
We proposed in 85 FR 7485 and 7486 in Sec. 170.404(a)(2)(i) to
require API Technology Suppliers make available complete business and
technical documentation via a publicly accessible hyperlink, including
all terms and conditions for use of its API technology. Additionally,
we proposed that API Technology Suppliers must make clear to the public
the timing information applicable to their disclosures in order to
prevent discrepancies between an API Technology Supplier's public
documentation and its direct communication to customers. Additionally,
we requested comment at 84 FR 7486 on whether the expectation for API
Technology Suppliers to make necessary changes to transparency
documentation should be finalized in regulation text, or whether this
would be standard practice as part of making this documentation
available.
Comments. We received overall support from commenters for the need
to make complete business and technical documentation available via a
publicly accessible hyperlink. We did not receive public comment on
whether we should formally include public disclosure requirements for
regular updates to business and technical documentation in regulatory
text.
Response. We thank commenters for their support to make complete
business and technical documentation available via a publicly
accessible hyperlink. We have finalized in Sec. 170.404(a)(2)(i) that
a Certified API Developer must publish complete business and technical
documentation, including the documentation described in Sec.
170.404(a)(2)(ii), via a publicly accessible hyperlink that allows any
person to directly access the information without any preconditions or
additional steps. We made small adjustments to Sec. 170.404(a)(2)(i)
to reflect the changes in API definitions finalized in Sec.
170.404(c).
Given that we did not receive public comment on whether we should
formally include public disclosure requirements for regular updates to
business and technical documentation in regulatory text, so we have
finalized in 170.404(a)(4)(iii)(B) that a Certified API Developer must
provide notice and a reasonable opportunity for API Information Sources
and API Users to update their applications to preserve compatibility
with certified API technology and to comply with applicable terms and
conditions. We note that notice could include a public notice made
available on a website, but also encourage Certified API Developers to
contact API Information Source customers and registered API Users
(application developers) directly prior to updating business and
technical documentation.
(A) Terms and Conditions
We proposed in 84 FR 7485 in Sec. 170.404(a)(2)(ii)(A) that API
Technology Suppliers must publish all terms and conditions for its API
technology, including any restrictions, limitations, obligations,
registration process requirements, or other similar requirements that
would be needed to: Develop software applications to interact with the
API technology; distribute, deploy, and enable the use of software
applications in production environments that use the API technology;
use software applications, including to access, exchange, and use EHI
by means of the API technology; use any EHI obtained by means of the
API technology; and register software applications. Additionally, we
proposed in Sec. 170.404(a)(2)(ii)(B) that any and all fees charged by
an API Technology Supplier for the use of its API technology must be
described in detailed, plain language, including the persons or classes
of persons to whom the fee applies; the circumstances in which the fee
applies; and the amount of the fee, which for variable fees must
include the specific variable(s) and methodology(ies) that will be used
to calculate the fee.
Comments. We received support from stakeholders regarding the
transparency of ``all terms and conditions'' associated with the use of
API technology.
Response. We thank commenters for their support. We believe this
terms and conditions transparency requirement would ensure that API
Information Sources and API Users do not experience ``special effort''
in the form
[[Page 25751]]
of unnecessary costs or delays in obtaining the terms and conditions
for certified API technology. Furthermore, we believe full transparency
is necessary to ensure that API Users have a thorough understanding in
advance of any terms or conditions that might apply to them once they
have committed to developing software that interacts with certified API
technology. We have finalized in Sec. 170.404(a)(2)(ii)(A) that
Certified API Developers must publish all terms and conditions for its
certified API technology, including any fees, restrictions,
limitations, obligations, registration process requirements or other
similar requirements as enumerated in Sec. 170.404(a)(2)(ii)(A)(1)
through (6). We made small adjustments to Sec. 170.404(a)(2)(ii)(A) to
reflect the changes in API definitions finalized in Sec. 170.404(c).
Additionally, we moved ``App developer verification'' from its proposed
location in Sec. 170.404(a)(2)(ii)(C) and finalized it in Sec.
170.404(b)(1) to improve organization. We added the phrase ``Used to
verify the authenticity of API Users'' to the regulation text finalized
in Sec. 170.404(a)(2)(ii)(A)(5) for consistency with our proposed
policy. We also moved the phrase ``Register software applications''
from its proposed location in Sec. 170.404(a)(2)(ii)(A)(5) to the
finalized location in Sec. 170.404(a)(2)(ii)(A)(6) and revised the
phrase for consistency. Additionally, we made small changes to the
regulation text finalized in Sec. 170.404(a)(2)(ii)(A)(1) through
Sec. 170.404(a)(2)(ii)(A)(6) for clarity.
Comments. We received both support and disagreement for the
requirement to publish transparency documentation on API fees. Some
commenters felt transparency documentation of API fees should be
limited to value-added services, because those are the only permitted
fees applicable to API Users, and the other permitted fees applicable
to API Data Providers (usage-based fees and fees to recover costs for
development, deployment, and upgrades) would be included in contractual
documentation with their customers.
Response. We recognize that some commenters had concern with making
documentation on permitted fees publicly available. We believe that
transparent documentation of all permitted fees is necessary to
maintain a competitive marketplace and ensure that fees are reasonably
related to the development, deployment, upgrade, and use of certified
API technology. Fee transparency will also enable API Information
Sources and API Users to shop for certified API technology and related
services that meet their needs. We have finalized in Sec.
170.404(a)(2)(ii)(B) that any and all fees charged by a Certified API
Developer for the use of its certified API technology must be described
in detailed, plain language, including all material information
described in Sec. 170.404(a)(2)(ii)(B)(1) through (3). Additionally,
we made small adjustments to Sec. 170.404(a)(2)(ii)(B) to reflect the
changes in API definitions finalized in Sec. 170.404(c).
Comments. Multiple stakeholders expressed the need to include
consumer protections in the terms and conditions documentation with an
explanation about how EHI will be used.
Response. This provision of the Condition of Certification
requirements does not prohibit additional content or limit the type of
content a Certified API Developer may include in its terms and
conditions. A Certified API Developer would be permitted to include
consumer protections in their terms and conditions documentation.
Additionally, we clarify these API Conditions of Certification
requirements only apply to Certified API Developers. As such, API
Information Sources and API Users are not required by the API Condition
of Certification requirements to publish any terms and conditions,
including those that apply to consumer protections.
v. Fees Conditions
(A) General Fees Prohibition
We proposed in Sec. 170.404(a)(3)(i)(A) that API Technology
Suppliers would be prohibited from imposing fees associated with API
technology as a Condition of Certification requirement. In establishing
this general prohibition, ONC was mindful of the need for API
Technology Suppliers to recover their costs and to earn a reasonable
return on their investments in providing API technology that has been
certified under the Program. Accordingly, we identified categories of
``permitted fees'' in 84 FR 7487 that API Technology Suppliers would be
permitted to charge and still be compliant with the Condition of
Certification and Program requirements. These include the proposed
Sec. 170.404(a)(3)(ii) (permitted fee for developing, deploying, and
upgrading API technology), proposed Sec. 170.404(a)(3)(iii) (permitted
fee to recover costs of supporting API usage for purposes other than
patient access), and proposed Sec. 170.404(a)(3)(iv) (permitted fee
for value-added services). We also proposed in 84 FR 7487 that API
Technology Suppliers would not be permitted to impose fees on any
person in connection with an API Technology Supplier's work to support
the use of API technology to facilitate a patient's ability to access,
exchange, or use their EHI. We also clarified that while the proposed
permitted fees set the boundaries for the fees API Technology Suppliers
would be permitted to charge and to whom those permitted fees could be
charged, the proposed regulations did not specify who could pay the API
Technology Supplier's permitted fee. Rather, we proposed general
conditions that an API Technology Supplier's permitted fees must
satisfy in Sec. 170.404(a)(3)(i)(B)(1) through (4), and requested
comment in 84 FR 7488 on these conditions and whether they sufficiently
restrict fees from being used to prevent access, exchange, and use of
EHI through APIs without special effort. We include detailed
discussions of permitted fees and related conditions below.
Comments. Some commenters supported the clear prohibition on API
fees outside those fees permitted in Sec. 170.404(a)(3)(ii) through
(iv), expressing that the language in the rule would prevent confusion
regarding allowable and restricted fees. Some commenters noted that
prohibiting fees would enable patients to exercise their HIPAA right of
access without experiencing cost barriers, and remove cost barriers to
hospitals and health care facilities using APIs for interoperability.
Commenters noted that the proposals addressed many of the access and
pricing practices that API Technology Suppliers engaged in to limit
data exchange and gain a competitive advantage. Commenters noted that
API Technology Supplier pricing practices often create barriers to
entry and competition for apps that health care providers seek to use.
Some commenters supported the proposal that prohibits API Technology
Suppliers from charging fees to API Users.
Response. We thank stakeholders for their support of and feedback
on our proposal. We have finalized in Sec. 170.404(a)(3)(i)(A) that
all fees related to certified API technology not otherwise permitted by
Sec. 170.404(a)(3) are prohibited from being imposed by a Certified
API Developer. Additionally, we have modified and reorganized these
Condition of Certification requirements for clarity. We have renamed
the title for the section from the Proposed Rule to ``Fees conditions''
because the requirements include both permitted and prohibited fees. We
have updated the terminology used in this section to reflect changes
made to the terminology used throughout the API Condition of
[[Page 25752]]
Certification requirements and finalized in Sec. 170.404(c). We
finalized a requirement in Sec. 170.404(a)(3)(i)(A) that permitted
fees in paragraphs Sec. 170.404(a)(3)(ii) and Sec. 170.404(a)(3)(iv)
may include fees that result in a reasonable profit margin in
accordance with the information blocking Costs Exception provision
finalized in Sec. 170.302. We clarify that any fee that is not covered
by those exceptions would be suspect under the information blocking
provision, and would equally not be permitted by this API Condition of
Certification requirement.
This general prohibition on fees as finalized in Sec.
170.404(a)(3)(i)(A) is meant to ensure that Certified API Developers do
not engage in pricing practices that create barriers to entry and
competition for apps and API-based services that health care providers
seek to use. Such activities are inconsistent with the goal of enabling
API-based access, exchange, and use of EHI by patients and other
stakeholders without special effort. As finalized, this general
prohibition allows for three categories of permitted fees (Sec.
170.404(a)(3)(ii) through (iv)) to allow Certified API Developers to
recover their costs and to earn a reasonable return on their
investments in providing certified API technology while being compliant
with the Condition of Certification and Program requirements.
Comments. Some commenters were critical of our proposals,
expressing concerns that the proposed policies may stifle relationships
between API Technology Suppliers and application developers. Others
expressed concern that the proposed fee structure would place undue
burden on API Data Providers, and that ONC should instead consider
regulations that allow fee sharing across stakeholders. Some commenters
stated that ONC should remove all prohibitions, and allow for market
pricing and revenue sharing.
Several commenters, many of whom were providers and provider
organizations, requested additional clarity and guidance regarding the
API fees that can be charged under the Condition of Certification
requirements. Some commenters requested clarification regarding whether
an API Data Provider can transfer costs to API Users. Other commenters
requested clarification regarding when it is (and is not) appropriate
for an API User to be charged a fee in connection with use of API
technology. A few commenters requested that ONC provide a chart that
lists all actors, all types of costs, and who can charge whom.
Response. We appreciate this feedback from commenters. These
``general conditions,'' as finalized in Sec. 170.404(a)(3)(i) and
discussed above, will facilitate API-based access, exchange, and use of
EHI by patients and other stakeholders without special effort. We
disagree with commenters that the permitted fee policies will stifle
relationships between Certified API Developers and API Users.
Cumulatively, these final policies create guardrails to protect against
anti-competitive practices and reinforce the independence that we
believe API Information Sources should have to establish relationships
with API Users. Furthermore, we believe these fee policies are
necessary in light of the potential for Certified API Developers to use
their market position and control over certified API technology to
engage in discriminatory practices that create special effort and
barriers to the use of certified API technology. We continue to receive
evidence that some Certified API Developers are engaging in practices
that create special effort for the use of certified API technology.
These practices include fees that create barriers to entry or
competition as well as rent-seeking and other opportunistic behaviors.
For example, we have received feedback that some Certified API
Developers are conditioning access to technical documentation on
revenue sharing or royalty agreements that bear no plausible relation
to the costs incurred by the Certified API Developer to provide or
enable the use of certified API technology. We are also aware of
discriminatory pricing policies that have the purpose or effect of
excluding competitors from the use of APIs and other interoperability
elements despite the fact that the API Information Source would like to
partner with and use these competitive, best-of-breed services. These
practices from Certified API Developers close off the market to
innovative applications and services that could empower patients and
enable providers to deliver greater value and choice to health care
consumers and other service providers.
We note that Certified API Developers and API Users have the
ability to collaborate and form relationships, so long as these
relationships do not conflict with any of the provisions of this final
rule or other applicable Federal and State laws and regulations.
Further, we clarify that while the permitted fees set the boundaries
for the fees Certified API Developers are permitted to charge and to
whom those permitted fees can be charged, they do not prohibit who may
pay the Certified API Developer's permitted fee. In other words, these
conditions limit the party from which a Certified API Developer may
require payment, but they do not speak to who may pay the fee. For
example, a permitted practice under these conditions could include a
relationship or agreement where an API User or other party offered to
pay the fee owed by the API Information Source to a Certified API
Developer. This is an acceptable practice because the fee is first
agreed upon between the Certified API Developer and API Information
Source and subsequently paid by the API Information Source directly or
by a third party on behalf of the API Information Source. We note that
fees charged for ``value-added services'' can arise between an API
Information Source and Certified API Developer or API User. As a
general matter, we note that stakeholders should be mindful of other
Federal and State laws and regulations that could prohibit or limit
certain types of relationships involving remuneration.
We provide additional clarity and guidance regarding the API fees
that can be charged under the Condition of Certification requirements
in the sections that follow. Additionally, we appreciate commenters'
requests for clarification, including a chart of actors and costs. We
will take this comment into consideration as we develop educational
materials to help explain the permitted fees conditions finalized in
Sec. 170.404(a)(3).
Comments. Commenters suggested that one way to clarify the limits
on API fees would be to require API Technology Suppliers provide fee
information to ONC and for ONC to make this information publicly
available, including information on individual pricing transactions.
Response. We appreciate the recommendation from commenters to
require Certified API Developers to provide fee information to ONC. We
view fee transparency as a responsibility that a Certified API
Developer can fulfill without having to send a listing of its API fees
to ONC. We have finalized the provision in Sec. 170.404(a)(2)(ii) that
a Certified API Developer must publish all terms and conditions for its
certified API technology, including any fees. Specifically, we have
finalized in Sec. 170.404(a)(2)(ii)(B) that any and all fees charged
by a Certified API Developer for the use of its certified API
technology must be described in detailed plain language, including the
persons or classes of persons to whom the fee applies; the
circumstances in which the fee applies; and the amount of the fee,
which for variable fees must include the specific variable(s) and
[[Page 25753]]
methodology(ies) that will be used to calculate the fee.
(B) Certified API Developer Permitted Fees Conditions
We proposed general conditions in Sec. 170.404(a)(3)(i)(B)(1)
through (4) that an API Technology Supplier's permitted fees must
satisfy in order for such fees to be expressly permitted.
Comments. We received support for the general conditions for
permitted fees from commenters. Some commenters expressed appreciation
for the guardrails and transparency of the permitted fees. Under the
first condition, commenters sought clarity on the nature and extent of
some of the permissible fees an API Technology Supplier can charge and
how to model such fees, specifically regarding the ``objective and
verifiable'' criteria. Another commenter supported the second condition
that fees must be reasonably related to API Technology Supplier's costs
of supplying and, if applicable, supporting the API technology to the
API Data Provider, especially in situations where physicians may also
develop APIs or support apps.
However, some commenters expressed concern with the third condition
to reasonably allocate fees across all customers of the API. Commenters
explained that fees could not be reasonably allocated across all
customers of the API, because the number of customers will change over
time. We received no comments on the fourth condition that API
Technology Suppliers must ensure that fees are not based on whether the
requestor or other person is a competitor who will be using the API
technology in a way that facilitates competition. In addition to the
general permitted fees proposed, some commenters recommended clear fee
exemption for any health information provided or reported by a practice
for the purpose of meeting reporting requirements.
Response. We appreciate feedback from commenters. We have finalized
these general conditions for permitted fees in Sec.
170.404(a)(3)(i)(B) with some modifications as described further below.
We have finalized that for all permitted fees, a Certified API
Developer must: (1) Ensure that such fees are based on objective and
verifiable criteria that are uniformly applied to all similarly
situated API Information Sources and API Users; (2) Ensure that such
fees imposed on API Information Sources are reasonably related to the
Certified API Developer's costs of supplying certified API technology
to, and if applicable, support certified API technology for, API
Information Sources; (3) Ensure that such fees for supplying, and if
applicable, supporting certified API technology are reasonably
allocated among all similarly situated API Information Sources; and (4)
Ensure that such fees are not based on whether API Information Sources
or API Users are competitors, potential competitors, or will be using
the certified API technology in a way that facilitates competition with
the Certified API Developer. We have revised the term ``substantially
similar'' to ``similarly situated'' in Sec. 170.404(a)(3)(i)(B)(1) for
clarity and to align with changes made in Sec. 171.302. Additionally,
in response to comments and to align with changes made in Sec. 171.302
and Sec. 170.404(a)(3)(i)(B)(1), we have revised the term
``substantially similar'' to ``similarly situated'' in Sec.
170.404(a)(3)(i)(B)(3). We emphasize that this provision is meant to
prevent one customer or a specific group of customers to whom the
certified API technology is supplied or for whom it is supported from
bearing an unreasonably high cost compared to other customers, which
could lead to ``special effort'' for accessing and using APIs. We
believe the final policy achieves the same goal as proposed and
provides clearer guidelines for the regulated community to follow.
Additionally, we have revised the phrase ``classes of persons and
requests'' to ``API Information Sources and API Users'' in Sec.
170.404(a)(3)(i)(B)(1) to clearly express the actors being charged fees
by Certified API Developers. Additionally, we have revised the sentence
structure and grammar in Sec. 170.404(a)(3)(i)(B)(2) through (4) for
simplification.
In response to comments requesting clarity on the nature and extent
of permissible fees a Certified API Developer can charge and how a
Certified API Developer should model such fees, specifically regarding
the ``objective and verifiable'' requirement finalized in Sec.
170.404(a)(3)(i)(B)(1), we emphasize that there will be significant
variability in the fee models and specific fees charged by each
Certified API Developer. Our goal with the requirement that fees be
``objective and verifiable'' is to require Certified API Developers to
apply fee criteria that, among other things, will lead the Certified
API Developer to come to the same conclusion with respect to the
permitted fee's amount each time it administers a fee to an API
Information Source or API User. Accordingly, the fee cannot be based on
the Certified API Developer's subjective judgment or discretion.
Comments. A few commenters suggested that ONC allow API Data
Providers the ability to recoup the costs for upgrading technology.
Response. This comment appears to misunderstand the scope and
applicability of ONC's authority with respect to these Condition of
Certification requirements. We clarify that these Condition of
Certification requirements apply only to Certified API Developers. We
note that similar to any IT investment, API Information Sources (as
``health care providers'') would generally be expected to recover these
costs through fees administered while delivering health care services.
Additionally, if an API Information Source were to recoup such costs
they would need to do so consistent with the information blocking
exceptions and other applicable laws and regulations.
Comments. Some commenters requested that ONC conduct evaluations
after the implementation of the rule and use the results to drive
future policy. Some commenters recommended a study to evaluate the
real-world cost of APIs used by health systems in areas such as
clinical decision support, payments, machine learning, and precision
medicine. Commenters also suggested ONC conduct a study on whether
these regulations improve patient access to their EHI.
Response. We appreciate the evaluation recommendations. We will
consider these suggestions as we implement and administer the Program.
(C) Certified API Developer Prohibited Fees
We proposed in 84 FR 7595 in Sec. 170.404(a)(3)(iii)(B) that
permitted fees would not include costs associated with intangible
assets (including depreciation or loss of value), except the actual
development or acquisition costs of such assets. Additionally, we
proposed in Sec. 170.404(a)(3)(iii)(C) that permitted fees would not
include opportunity costs, except for the reasonable forward-looking
cost of capital.
Comments. We did not receive any comments specific to the proposal
for costs associated with intangible assets other than actual
development or acquisition costs of such assets.
Response. We moved the proposed Sec. 170.404(a)(3)(iii)(B) and (C)
to the general conditions for permitted fees finalized in Sec.
170.404(a)(3)(i)(C)(1) and (2), respectively, because they are general
conditions on permitted fees rather than conditions for ``Recovering
API usage costs.'' We did not make
[[Page 25754]]
other changes to the proposed regulation text in these two sections
other than updating terms to the finalized definitions in Sec.
170.404(c).
Additionally, in the discussion of the Fees Exception in this final
rule (VIII.D.2.b), we discussed that one commenter expressed concern
that the overlap between the Fees Exception and the Licensing Exception
creates the potential for actors to recover the same costs twice. The
commenter explained that licensing of IP is intended to recoup the
costs of development of that IP, so where the IP is an interoperability
element, the costs reasonably incurred for its development should be
incorporated into the royalty rate. The commenter recommended that we
be clearer that, in these circumstances, only a single recovery is
permitted. In order to address this comment and align the API permitted
fees with related provisions finalized in the Fees Exception (Sec.
170.302(a)(2)(vi)) and Licensing Exception (Sec. 170.303(b)(2)(iv)),
we have added and finalized Sec. 170.404(a)(3)(i)(C)(3), which states
that the permitted fees in this section cannot include any costs that
that led to the creation of IP if the actor charged a royalty for that
IP pursuant to Sec. 170.303 and that royalty included the development
costs for the creation of the IP. We refer readers to the ``Basis for
Fees Condition'' sub-section within section VIII.D.2.b for a more
detailed discussion of the rationale for this addition.
(i) General Examples of Prohibited Fees
As discussed in the Proposed Rule in 84 FR 7481 and finalized in
Sec. 170.404(a)(3)(i)(A), any API-related fee imposed by a Certified
API Developer that is not expressly permitted is prohibited. In the
Proposed Rule, we provided the following non-exhaustive examples of
fees for services that Certified API Developers would be prohibited
from charging, and reiterate them here in the final rule for clarity:
(1) Any fee for access to the documentation that a Certified API
Developer is required to publish or make available under this Condition
of Certification requirement.
(2) Any fee for access to other types of documentation or
information that a software developer may reasonably require to make
effective use of certified API technology for any legally permissible
purpose.
(3) Any fee in connection with any services that would be essential
to a developer or other person's ability to develop and commercially
distribute production-ready applications that use certified API
technology. These services could include, for example, access to ``test
environments'' and other resources that an application developer would
need to efficiently design and develop apps. The services could also
include access to distribution channels if they are necessary to deploy
production-ready software and to production resources, such as the
information needed to connect to certified API technology (e.g.,
service base URLs) or the ability to dynamically register with an
authorization server.
Comments. At least one commenter expressed concern about the open-
ended nature of the examples of prohibited fees we provided in the
Proposed Rule. In particular, that any fee in connection with any
services that would be essential to a developer or other person's
ability to develop and commercially distribute production-ready
applications that use API technology would be prohibited. They stated
that if the example were not more clearly defined and scoped, it could
be used by API Users to create requirements for API Technology
Suppliers beyond what would normally be considered necessary to
successfully deploy apps in production. They requested ONC more clearly
define ``essential services'' in final rulemaking or withdraw the
reference.
Response. We appreciate the feedback from commenters. We disagree
with commenters that the examples are too broad. We believe that in
some cases they need to be general because of the diverse and varied
practices that could be used by Certified API Developers to create
special effort to use certified API technology. While we understand
that the generality of the example regarding ``essential services'' may
at first appear difficult for Certified API Developers to follow and,
per the commenter, could be creatively used by an API User to request
more support than necessary, we offer the following as additional
guidance: A Certified API Developer is best positioned to know what an
API User, for example, needs to have access to and do programmatically
in order for the API User's application to be developed and
commercially distributed as production-ready for use with certified API
technology. From a Certified API Developer's perspective, if that
requires any number of mandatory steps (e.g., passing tests in sandbox/
test environment, conducting a demo, submitting documentation or
paperwork) in order for the application to be production-ready for use
with certified API technology, then fees associated with those
mandatory steps are prohibited. Conversely, fees for requirements
beyond what a Certified API Developer considers necessary to
successfully deploy applications in production are considered
supplemental to the development, testing, and deployment of software
applications that interact with certified API technology, and are
permitted fees for value added services as finalized in Sec.
170.404(a)(3)(iv).
(D) Record-Keeping Requirements
We proposed in Sec. 170.404(a)(3)(v) that API Technology Suppliers
must keep for inspection detailed records of all API technology fees
charged, all costs incurred to provide API technology to API Data
Providers, methodologies used to calculate such fees, and the specific
costs to which such fees are attributed. We requested comment in 84 FR
7492 on whether these requirements provide adequate traceability and
accountability for costs permitted under this API Condition of
Certification and whether to require more detailed accounting records
or prescribe specific accounting standards.
Comments. A majority of commenters expressed concerns with the
level of granularity proposed for record keeping in Sec.
170.404(a)(3)(v). These commenters stated that the required
recordkeeping would exceed documentation performed for any other
purpose. Some commenters stated that the requirement for health IT
developers to track who pays fees and how fees enter the system will
cause significant administrative burden, especially on smaller vendors
or vendors with business models that require less operational overhead.
Additionally, they stated that the requirement for clients to maintain
and potentially publicly disclose records of fees for inspection would
place a burden on IT providers, and could potentially allow bigger
companies to engage in practices such as predatory pricing. Commenters
suggested ONC have a more scaled-back method, and simply allow patients
the ability to access their EHI without charge. These commenters
recommended focusing on a good conduct approach rather than
prescriptive requirements.
Response. We thank commenters for their feedback and perspective.
We moved Sec. 170.404(a)(3)(v) to 170.404(a)(3)(i)(D) for better
organization because this provision applies to the permitted fee
Condition of Certification requirements finalized in Sec.
170.404(a)(3)(ii) through (iii). We have finalized in Sec.
170.404(a)(3)(i)(D) that Certified API Developers must keep detailed
records for inspection of all fees charged, all costs incurred to
provide certified API technology to API Information Sources,
methodologies
[[Page 25755]]
used to calculate such fees, and the specific costs to which fees are
attributed. Considering the feedback on perceived burden, we believe
transparency and documentation of API fees is necessary to mitigate
unfair pricing practices that may stifle innovation or otherwise create
barriers to the goals of enabling API-based access, exchange, and use
of EHI without special effort. Further, we believe that the accounting
practices already used by health IT developers will largely support the
health IT developer to meet this requirement. Examples of these
practices by health IT developers include the methods used to track
their own investments, determine how to bill and issue invoices to
their customers, document receipt of payment, and to maintain overall
accurate financial records of business transactions. We find it
difficult to believe, as some commenters appeared to indicate, that
health IT developers are not already keeping such financial records and
that this requirement would create substantial new documentation burden
for Certified API Developers. The record-keeping requirements finalized
in 170.404(a)(3)(i)(D) foster transparency and promote accountability
in the Program. In response to the comments received, we have not added
additional requirements for accounting records or standards.
(E) Permitted Fee for Development, Deployment, and Upgrades
We proposed in Sec. 170.404(a)(3)(ii) to permit an API Technology
Supplier to charge API Data Providers reasonable fees for developing,
deploying, and upgrading Health IT Modules certified to Sec.
170.315(g)(7) through (g)(11).
Comments. Many commenters applauded the permitted fee related to
development, deployment, and upgrading API technology. The majority
supported the proposal that fees would not be permitted if they
interfere with an API User's ability to efficiently and effectively
develop and deploy production-ready software. A few commenters
expressed concern that our proposals regarding development, deployment,
and upgrade fees were not restrictive enough. Commenters noted that API
Technology Suppliers will use the allowable fees, such as for program
upgrades, as a barrier to providing interoperability between systems or
other applications and a means to eliminate competitive threats. Some
of these commenters recommended that ONC explicitly prohibit API
Technology Suppliers from charging any fees for implementing APIs and
for facilitating the interoperable exchange of EHI and that this
blanket prohibition apply to all new and updated API technology. A few
commenters noted that it is possible that API Technology Suppliers will
bundle or upcharge service fees to recoup API technology development
costs and API Technology Suppliers should not be allowed to charge
costs for development or impose surcharges for product feature
development. They noted that product feature development should be
considered a cost of doing business and can be amortized as a one-time
capital expense across the vendor's entire customer base without the
need for recovering costs from API Users. They emphasized that API
access and use prices need to be transparent as the intent of Congress
was to have APIs be made easily available and at no or low cost, not to
be a source of revenue for profit. Other commenters noted that the
development of the APIs themselves should be regarded as part of the
license fee and the API Technology Suppliers should not be permitted to
charge an additional license fee to either the API Data Provider or API
User for what is an inherent part of the software. Another commenter
requested that consideration be applied toward potential additional
hidden integration fees.
Response. We appreciate the support, concerns, and recommendations
from commenters. We finalized this proposal in Sec. 170.404(a)(3)(ii)
as proposed with updated terms based on the revised finalized
definitions in Sec. 170.404(c). We refer to the discussions below and
84 FR 7488 for additional details on what Certified API Developer fees
for ``developing,'' ``deploying,'' and ``upgrading'' certified API
technology comprise. We also note that the nature of the costs charged
under this category of permitted fees depends on the scope of the work
to be undertaken by a Certified API Developer (i.e., how much or how
little labor an API Information Source requires of the Certified API
Developer to deploy and upgrade the certified API technology).
We sincerely thank commenters for the various recommendations to
prohibit or restrict fees regarding certified API technology. In order
to reconcile the recommendations specific to Sec. 170.404(a)(3)(ii)
and other conditions in this final rule, we have aligned related
conditions to address concerns and mitigate potential fee practices
that could limit API-based access, exchange, and use of EHI by patients
and other stakeholders without special effort. As finalized, we believe
the fees permitted in Sec. 170.404(a)(3)(ii) and Sec.
170.404(a)(3)(i)(B), transparency requirements in Sec. 170.404(a)(2),
and openness and pro-competitive conditions in Sec. 170.404(a)(4) will
ensure that fees permitted for upgrade costs will not be used as a
barrier to providing interoperability between systems or other
applications, or as a means to eliminate competitive threats.
Additionally, the transparency requirements regarding the publication
of fees finalized in Sec. 170.404(a)(2)(ii)(B) will help prevent
hidden integration fees cited by commenters.
We thank commenters for recommending and noting that development of
the APIs themselves should be regarded as part of a license fee and
that Certified API Developers should not be permitted to charge an
additional license fee for what is an inherent part of the software. In
response to this recommendation, we have added a provision in Sec.
170.404(a)(3)(i)(C)(3) that states that permitted fees in Sec.
170.404(a)(3)(ii) through (iv) may not include any costs that led to
the creation of IP, if the actor charged a royalty for that IP pursuant
to the information blocking Licensing Exception (Sec. 171.303). This
provision aligns with similar provisions included in the information
blocking section and will ensure that Certified API Developers cannot
earn a double recovery in instances described by the commenter.
We will continue to work with stakeholders to advance policies that
promote interoperability and deter practices that may stifle innovation
or present barriers to the access, exchange, and use of EHI through
APIs. Subject to the general conditions in Sec. 170.404(a)(3)(i), our
final policies support the ability of Certified API Developers to
recover the full range of reasonable costs associated with developing,
deploying, and upgrading API technology over time. It is important that
Certified API Developers be able to recover these costs and earn a
reasonable return on their investments so that they have adequate
incentives to make continued investments in these technologies. In
particular, we anticipate Certified API Developers will need to
continually expand the data elements and upgrade the capabilities
associated with certified APIs as the USCDI and HL7[supreg]
FHIR[supreg] standard and associated implementation specifications
mature. We refer readers to the information blocking section of this
preamble (VIII) for additional information on activities that may
constitute information blocking and for discussion about how the fees
provisions in this Condition of Certification and within the
information blocking section support innovation.
[[Page 25756]]
Comments. Some developers expressed concern regarding balancing and
distributing costs with regard to the permitted fee for developing,
deploying, and upgrading technology. The commenters noted ONC proposed
that the cost for development be distributed among those who will use
it, which they felt was problematic in many ways, but most
fundamentally because it suggests a serious misconception about how
software development is funded, priced, and sold. The commenters
emphasized that requiring development costs to be divided among clients
purchasing the API necessitates new and complex business processes and
creates unsolvable scenarios that could easily create business
conflicts between API Technology Suppliers and their clients. At least
one commenter suggested that ONC should consider balancing the costs
associated with API development and deployment across both API Data
Providers and certain API Users to ensure that third-party software
application developers also bear some of the financial burden, since
they stand to generate revenue from the use of their apps. Commenters
asked ONC clarify why it believes it is inappropriate to pass
development, deployment, and upgrade costs on to API Users. Other
commenters noted that the costs for updating information systems and
Health IT Modules to the new standards and requirements should not be
passed on to physicians and patients.
Response. We appreciate the feedback from commenters. We proposed
and finalized this permitted fee for development, deployment, and
upgrade costs because we believe that these costs should be negotiated
solely between the Certified API Developer that supplies the
capabilities and the API Information Source that implements them in
their production environment. In our view, it is inappropriate for
Certified API Developers to go around the API Information Source to
directly impose financial cost burdens on API Users for the benefit of
working with or connecting to the API Information Source. Based on our
experience, the practice of a Certified API Developer going around its
customer (the API Information Source) to also charge API Users erodes
an API Information Source's choice and the independence of their
relationship with API Users. As such, that kind of business practice
would be something that we would consider creating special effort on
the part of the API Users if they had to continue to face additional
fees just for permission to work with or connect to an API Information
Source's certified API technology.
While the development, deployment, and upgrade permitted fee is
limited between the Certified API Developer and API Information Source
as a way to recoup a Certified API Developer's costs to supply
certified API technology to a particular API Information Source, we
again reiterate that the value added services permitted fee providers
Certified API Developers a wide range of options to make additional
revenue related to their certified API technology.
Should API Users stand to generate revenue from the use of their
apps, any fee an API Information Source may impose would not be in
scope for this Condition of Certification but would be likely be
covered by information blocking. Accordingly, we emphasize that such
stakeholders should take care to ensure they are compliant with other
Federal and State laws and regulations that may prohibit or limit
certain types of relationships involving remuneration.
In response to comments suggesting that costs for updating
information systems and Health IT Modules to the new standards and
requirements would be passed on to physicians and patients, we
disagree. We emphasize that most of the information contained in a
patient's electronic record has been documented during the practice of
medicine or has otherwise been captured in the course of providing
health care services to patients. In our view, patients have
effectively paid for this information, either directly or through their
employers, health plans, and other entities that negotiate and purchase
health care items and services on their behalf, and should be able to
access the information via certified API technology without fees.
Comments. Some developers suggested that API Technology Suppliers
should be able to charge fees for access to a test environment and
requested clarification as to whether an API Technology Supplier can
charge for the use of sandboxes by API Users.
Response. We appreciate the feedback from commenters. As detailed
in the ``General Examples of Prohibited Fees'' section of the preamble
text and included in the general prohibition finalized in Sec.
170.404(a)(3)(i)(A), Certified API Developers are prohibited from
charging fees in connection with any services essential to a developer
or other person's ability to develop and commercially distribute
production-ready applications for use with certified API technology. In
general, if a test environment or sandbox is required to be used by a
Certified API Developer and is essential for an application to be
developed in order to be considered production-ready by the Certified
API Developer for use with its certified API technology, then fees
associated with that kind of test environment would be prohibited as
they would impose special effort. However, we note that this
prohibition is not globally applicable. If instead, the purpose of the
testing environment was to provide specific testing above-and-beyond
production-readiness for use with certified API technology, then fees
could be charged for such testing as part of the value-added services
permitted fee.
Comments. A few commenters requested guidance on how ONC expects
API Technology Suppliers to account for the costs incurred to develop,
deploy, and upgrade the API technology, which is part of, and not
necessarily separable from, the broader EHR product. Several commenters
opposed the prohibition against charging for work to upgrade the
broader EHR product, expressing that this is essential work needed to
modernize their solutions as broader technologies evolve. One commenter
noted that the Proposed Rule does not set specific guidelines on what
constitutes an upgrade or how much the fee could be, and it is the
commenter's experience that EHR systems often charge fees for such
services as integrating with a clinical data registry or using outside
or non-preferred software.
Response. We thank stakeholders for their comments. While we
understand that there is overlap between features of the certified API
technology and the ``broader EHR product,'' we refer specifically to
development, deployment, and upgrades made to ``certified API
technology'' as defined in Sec. 170.404(c). Namely, development,
deployment, and upgrades made to the capabilities of certified Health
IT Modules that fulfill the API-focused certification criteria adopted
at Sec. 170.315(g)(7) through (10). In response to commenters
concerned that EHR developers often charge fees for services such as
integrating with a clinical data registry or using outside or non-
preferred software, we note that, as described in Sec.
170.404(a)(3)(i)(A), Certified API Developers are prohibited from
imposing fees associated with certified API technology unless included
as a permitted fee in Sec. 170.404(a)(3)(ii) through (iv). We do not
include specific price information for permitted fees to develop,
deploy, or upgrade API technology, because these costs are subject to
change over time with new technology and varying development,
deployment, and upgrade
[[Page 25757]]
efforts. Instead, we allow Certified API Developers to recover their
costs (including costs that result in a reasonable profit margin for
permitted fees in Sec. 170.404(a)(3)(ii) and Sec. 170.404(a)(3)(iv))
in providing certified API technology while being compliant with the
Condition and Maintenance of Certification and Program requirements. We
include descriptions of fees for developing, deploying, and upgrading
API technology in the sections that follow, in which we offer
additional clarity, as discussed in the Proposed Rule at 84 FR 7488, on
the fees for developing, deploying, and updating API technology.
(i) Fees for Developing Certified API Technology
Fees for ``developing'' certified API technology comprise the
Certified API Developer's costs of designing, developing, and testing
certified API technology. In keeping with our discussion at 84 FR 7488,
fees for developing certified API technology must not include the
Certified API Developer's costs of updating the non-API related
capabilities of the Certified API Developer's existing Health IT
Modules, including its databases, as part of its development of the
certified API technology. As we further discussed in 84 FR 7488 in our
Proposed Rule, these costs are connected to past business decisions
made by the Certified API Developer and typically arise due to Health
IT Modules being designed or implemented in nonstandard ways that
unnecessarily increase the complexity, difficulty or burden of
accessing, exchanging, or using EHI. The recovery of costs associated
with updating a Certified API Developer's non-API related Health IT
Modules capabilities would be inconsistent with the Cures Act
requirement that API technology be deployed ``without special effort.''
(ii) Fees for Deploying Certified API Technology
Certified API Developer's fees for ``deploying'' certified API
technology comprise the Certified API Developer's costs of
operationalizing certified API technology in a production environment.
Such fees include, but are not limited to, standing up hosting
infrastructure, software installation and configuration, and the
creation and maintenance of API Information Source administrative
functions. We discussed in our Proposed Rule that a Certified API
Developer's fees for ``deploying'' certified API technology does not
include the costs associated with managing the traffic of API calls
that are used to access the certified API technology, which a Certified
API Developer can only recover under the permitted fee for usage
support costs (Sec. 170.404(a)(3)(iii)). We emphasize that for the
purpose of this Condition of Certification, we consider that certified
API technology is ``deployed'' by the customer--the API Information
Source--that purchased or licensed it.
(iii) Fees for Upgrading Certified API Technology
The Certified API Developer's fees for ``upgrading'' certified API
technology comprise the Certified API Developer's costs of supplying an
API Information Source with an updated version of certified API
technology. Such costs would include the costs required to bring
certified API technology into conformity with new requirements of the
Program, upgrades to implement general software updates (not otherwise
covered by development fees or under warranty), or developing and
releasing newer versions of the certified API technology at the request
of an API Information Source. The nature of the costs that can be
charged under this category of permitted fees depends on the scope of
the work undertaken by a Certified API Developer (i.e., how much or how
little labor an API Information Source requires of the Certified API
Developer to upgrade the certified API technology being supplied from
one version or set of functions to the next).
(F) Permitted Fee to Recover Costs of Supporting API Usage
We proposed in 84 FR 7489 in Sec. 170.404(a)(3)(iii) to permit an
API Technology Supplier to charge API usage-based fees to API Data
Providers to recover the API Technology Supplier's reasonable
incremental costs for purposes other than facilitating the access,
exchange, or use of EHI by patients or their applications,
technologies, or services. We considered ``usage-based'' fees to be the
fees imposed by an API Technology Supplier to recover the costs that
would typically be incurred supporting API interactions at increasing
volumes and scale within established service levels. Additionally, in
84 FR 7489 under Sec. 170.404(a)(3)(iii), we proposed that any usage-
based fees associated with API technology be limited to the recovery of
the API Technology Supplier's ``incremental costs.'' Additionally, we
proposed in Sec. 170.404(a)(3)(iii)(A) that the permitted fee would
not include any costs incurred by the API Technology Supplier to
support uses of the API technology that facilitate a patient's ability
to access, exchange, or use their EHI. Finally, we proposed in Sec.
170.404(a)(3)(iii)(B)-(C) restrictions for permitted fees that were
moved to the general permitted fees section finalized in Sec.
170.404(a)(3)(i)(C).
Comments. Commenters generally supported our proposal to permit an
API Technology Suppliers to charge usage-based fees to API Data
Providers to the extent that the API technology is used for purposes
other than facilitating the access, exchange, or use of EHI by patients
or their applications, technologies, or services.
Response. We appreciate support from commenters and have finalized
this proposal in Sec. 170.404(a)(3)(iii) with some modification. We
amended the title of the regulation text for clarity in Sec.
170.404(a)(3)(iii) to ``Permitted fee--Recovering API usage costs.''
Additionally, we amended the regulation text to focus on usage-based
fees and Certified API Developer's reasonable incremental costs. We did
not finalize the specific prohibition on permitted fees proposed in
Sec. 170.404(a)(3)(iii)(A) that the ``permitted fee does not include
costs incurred by the API Technology Supplier to support uses of the
API technology that facilitate a patient's ability to access, exchange,
or use electronic health information.'' We did not finalize this aspect
of the provision because upon further consideration of this cost and
the fee prohibition included in information blocking related to patient
access, we determined that these fees remain necessary in order to
allow Certified API Developers to recover incremental costs reasonably
incurred during the process of hosting certified API technology on
behalf of the API Information Source. We reiterate that a Certified API
Developer's ``incremental costs'' comprise the Certified API
Developer's costs that are directly attributable to supporting API
interactions at increasing volumes and scale within established service
levels. A Certified API Developer should ``price'' its costs of
supporting access to the certified API technology by reference to the
additional costs that the Certified API Developer would incur in
supporting certain volumes of API use. For comments and responses
related to the proposed provisions in Sec. 170.404(a)(3)(iii)(B) and
(C), we refer readers to the header ``Certified API Developer
Prohibited Fees.''
Comments. We received a few comments focused on volume thresholds
and incremental costs. A few commenters supported a reasonable cap for
API call fees. Several recommended changing the parameters around API
usage-based fees to focus on volume
[[Page 25758]]
thresholds being included in any contractual language related to these
fees, to ensure that any incremental costs attributable to supporting
API interactions at increasing volumes and scale are addressed
appropriately. Commenters noted that if an API Technology Supplier is
receiving fees to develop, deploy, and upgrade API technology, it is
unlikely that they would also need to charge for usage of the APIs, as
long as their usage remains under a pre-determined volume threshold. A
few commenters noted that the volume of requests that will be pinging
APIs may compromise the performance of data retrieval and effective
user experience. In order to protect against denial of service attacks
whether intentional or inadvertent, they stated ONC should consider an
additional throttling or rate-limiting layer or capability onto the API
in order for the API to accept and digest the data being entered or
extracted. A few commenters noted that our proposal could create
loopholes that would enable certain organizations to charge highly
burdensome, excessive fees to clinical registries to access their data.
A few commenters expressed concern that this proposal is not
restrictive enough. Some commenters requested that ONC provide more
definitive guidance, including a range of prices based on examples from
the current marketplace, to ensure providers are not charged
unreasonable fees by API Technology Suppliers and can reasonably charge
API Users for the cost of accessing their API technology.
Response. We appreciate the feedback from commenters. This
Condition of Certification requirement offers the flexibility necessary
to accommodate reasonable pricing methodologies and will allow
Certified API Developers to explore innovative approaches to recovering
the costs associated with supporting the use of certified API
technology with a permitted fee. As described in the Proposed Rule (84
FR 7489), ``usage-based'' fees are fees imposed by a Certified API
Developer to recover costs typically incurred for supporting API
interactions at increasing volumes and scale within established service
levels. That is, ``usage-based'' fees recover costs incurred by a
Certified API Developer due to the actual use of the certified API
technology once it has been deployed (e.g., costs to support a higher
volume of traffic, data, or number of apps via the certified API
technology). Certified API Developers can adopt a range of pricing
methodologies when charging for the support of API usage. We appreciate
commenters' request to establish a reasonable cap for API usage-based
fees, but the focus of our policy is to identify usage fees as a type
of permitted fee and not to dictate a singular fee model, which we
believe could limit Certified API Developers ability to create
innovative fee models that serve to benefit themselves and API
Information Sources. We decline to include a price cap for API usage-
based fees or a range of prices for API fees based on examples from the
current marketplace because we anticipate the cost of technology will
change over time and so too will the way in which usage costs are
calculated. Additionally, while we understand and expect that Certified
API Developers and API Information Sources will deploy particular
security methods to mitigate the risk of denial of service attacks and
other impacts on API availability, these types of technology layers are
separate from the focus of our policy on permitted API usage fees.
Comments. Several commenters requested that ONC further clarify
that API Technology Suppliers should not attempt to charge different
fees for different API transactions as they frequently do today.
Response. We appreciate this information and feedback from
commenters. We clarify that Certified API Developers are permitted to
charge ``usage-based'' fees to recover the costs that would typically
be incurred supporting API transactions at increasing volumes and scale
within established service levels. To clarify, usage-based fees recover
costs incurred by a Certified API Developer related to the actual use
of certified API technology once it has been deployed (e.g., costs to
support a higher volume of traffic, data, or number of apps via the API
Technology). We acknowledge that Certified API Developers could adopt a
range of pricing methodologies when charging for the support of API
usage, including potentially charging higher prices for some API
transactions that incur relatively higher costs than others. However,
in combination with this flexibility, Certified API Developers will
still need to be mindful of not violating any overarching information
blocking policies. We refer readers to a discussion in the Proposed
Rule in 84 FR 7489 for additional discussions on usage-based fees.
Comments. Some commenters emphasized that it is unreasonable to
presume that API User-driven data overages should be the responsibility
of the API Data Provider. While other commenters expressed concern that
our proposal will leave providers, who are mandated to use certified
EHRs that include API technology and provide patients with access to
data via those APIs, responsible for a variety of unwarranted costs
with little recourse to recover those costs.
Response. While we understand the perspective from which these
concerns arise, especially regarding unpredictable overuse of certified
API technology, an API Information Source has financial responsibility
for its overall technology infrastructure. This accountability is no
different for certified API technology than it is for non-certified
APIs and other interfaces that may also create costs for the API
Information Source (i.e., health care provider). Given that API Users
can also include an API Information Source's own employees/internal
tools and 3rd party partners' tools, an API Information Source is best
positioned and generally accountable for its financial commitments.
Again, as noted above, we do not limit who may pay for the charges an
API Information Source incurs. An API Information Source should have
full knowledge and ability to assess what employees, internal
applications, and 3rd party services it has granted access to use and
interact with its certified API technology. With respect to potential
overages as a result of patient access, as we have stated before, we
believe patients have effectively paid for this information, either
directly or through their employers, health plans, and other entities
that negotiate and purchase health care items and services on their
behalf, and believe they should not be charged.
Additionally, as stated in the Proposed Rule (84 FR 7489) and
finalized here, usage fees for certified API technology will only apply
when the Certified API Developer acts on behalf of the API Information
Source to deploy its certified API technology. In scenarios where the
API Information Source, such as a large hospital system, assumes full
responsibility for the technical infrastructure necessary to deploy and
host the certified API technology it has acquired, the volume and scale
of its usage would be the API Information Source's sole responsibility,
and a Certified API Developer would not be permitted to charge usage-
based fees. Instead, the Certified API Developer would be limited to
charge fees under the ``development, deployment, upgrade'' permitted
fee in Sec. 170.404(a)(3)(ii). Additionally, the costs recovered under
``usage-based'' fees can only reflect ``post-deployment'' costs. As
such, ``usage-based'' fees cannot include any costs necessary to
prepare and ``get the certified API technology up, running, and ready
for use,'' which are costs that must be
[[Page 25759]]
recovered as part of the deployment services delivered by the Certified
API Developer if permitted under Sec. 170.404(a)(3)(ii).
Comments. Several commenters supported ONC's efforts to bolster
patient access, noting that the capacity to offer a patient's access to
all elements of their electronic medical record, through an API,
without cost, is well-supported in the Proposed Rule. One commenter
noted that the proposed provisions regarding fees supports uses of the
API technology that facilitate a patient's ability to access, exchange,
or use their EHI. The commenters noted that the clear language in the
Proposed Rule will prevent any potential confusion or friction in the
future.
A few commenters expressed concern that application developers will
attempt to leverage the patient access fee limitations by claiming to
be patient facing. One commenter suggested that the proposed fee
limitations regarding patient access applied only with respect to fees
API Technology Providers impose on API Data Providers, should also
apply to fees charged to consumer-facing application developers who in
the past have been charged high fees by CEHRT developers. One commenter
recommended making it clear that provider organizations and health IT
developers cannot charge patients, or the apps that they use, for using
patient-facing APIs. At least one commenter requested that ONC clarify
that permitted usage-based fees do not apply to patients or patient
designees.
Response. We thank commenters for their support for restricting
API-related fees. As noted above, we have reconfigured the permitted
fee for usage costs in response to public comments and our assessment
of the intersection of API permitted fees policies and information
blocking policies. We have finalized an approach that permits Certified
API Developers to recover incremental usage costs reasonably incurred
during the process of hosting certified API technology on behalf of an
API Information Source, which could include fees to the API Information
Source for providing and supporting patient access. However, the
Certified API Developers and API Information Sources cannot recover
these costs from patients or the developers of applications that
facilitate access to and receipt of patients' EHI. Patients have
already effectively paid for their EHI, either directly or through
their employers, health plans, and other entities that negotiate and
purchase health care items and services on their behalf. We refer
readers to the Fees Exception in the information blocking section of
this final rule in VII.D.2.b, which applies to health IT developers and
a broader set of actors than these Condition and Maintenance of
Certification requirements, for a discussion of the restrictions on
charging patients for access to their EHI.
Comments. Several commenters requested that ONC provide further
guidance on the types of costs that a developer could charge to permit
API Data Suppliers to offer population-level queries to API Users. They
requested ONC clarify that such usages fees must relate to the costs
associated with actual hardware (e.g., server space) needed to support
the increased volume of queries for non-patients and not the cost of
implementing the population-level query functionality itself.
Response. We clarify that API usage fees related to API ``read''
services for multiple patients would be calculated using a similar
methodology to calculate API usage fees related to API ``read''
services for single patients. These ``usage-based'' fees are fees
imposed by a Certified API Developer to recover the costs typically
incurred to support API interactions for API ``read'' services for
multiple patients once these services have been deployed. This could
include, but not be limited to, costs to support a higher volume of
traffic, data, or number of apps via the certified API technology
(which could include higher costs for hardware, including server
space). We appreciate the recommendation from commenters; however, we
have not prescribed the centralization of all of this content.
Comments. Some commenters suggested that API Technology Suppliers
publish their fees on the same website as their API documentation so
there is full transparency and an API Data Supplier and API User can
easily understand costs before embarking upon development.
Response. We appreciate the recommendation and support from
commenters. As finalized under Sec. 170.404(a)(2)(ii)(B), a Certified
API Developer must publish all terms and conditions for its certified
API technology, including any fees. Any and all fees charged by a
Certified API Developer for the use of its certified API technology
must be described in detailed, plain language, including the persons or
classes of persons to whom the fee applies; the circumstances in which
the fee applies; and the amount of the fee, which for variable fees
must include the specific variable(s) and methodology(ies) that will be
used to calculate the fee.
Comments. Some commenters stated that usage-based fees may not be
appropriate. They stated that, in the case of TEFCA, HIEs and providers
must be responsive to inbound requests to broadcast data and should not
be charged a fee for responding to such requests. They explained that
such an arrangement could be used maliciously between market
participants seeking to increase the operational expenses of their
competitors.
Response. We appreciate this comment, but we continue to believe
that that usage-based fees should be permitted subject to the
conditions described in Sec. 170.404(a)(3)(iii). We have addressed
commenter's concern regarding potential anticompetitive behavior
through the final provisions in Sec. 170.404(a)(3)(i)(B).
Specifically, in Sec. 170.404(a)(3)(i)(B)(1), a Certified API
Developer must ensure that fees are based on objective and verifiable
criteria that are uniformly applied for all similarly situated classes
of persons and requests. In addition, under Sec.
170.404(a)(3)(i)(B)(4), a Certified API Developer must ensure that fees
are not based in any part on whether the requestor or other person is a
competitor, potential competitor, or will be using the certified API
technology in a way that facilitates competition with the Certified API
Developer.
Comments. Several commenters expressed concern about incremental
costs that can be recovered by actors supporting the use of APIs for
purposes other than patient access. They requested ONC clarify that
recovery of incremental costs for these other purposes should not be
allowed, because they believed the incremental costs do not add any
efficiency to the health care system, do not benefit patients, and do
not serve any other procompetitive purpose.
Response. We appreciate these comments, but continue to believe
that ``incremental costs'' should be allowed. A Certified API
Developer's ``incremental costs'' comprise the Certified API
Developer's costs that are directly attributable to supporting API
interactions at increasing volumes and scale within established service
levels. We believe a Certified API Developer should ``price'' its costs
of supporting access to the certified API technology by reference to
the additional costs that the Certified API Developer would incur in
supporting certain volumes of API use. In practice, we expect that this
means that a Certified API Developer will offer a certain number of
``free'' API calls based on the fact that, up to a certain threshold,
the Certified API Developer will not incur any material costs in
supporting certified API technology in addition to the costs recovered
for
[[Page 25760]]
deployment services. However, after this threshold is exceeded, we
expect that the Certified API Developer will impose usage-based costs
commensurate to the additional costs that the Certified API Developer
must incur to support certified API technology use at increasing
volumes and scale.
We expect that Certified API Developers will charge fees that are
correlated to the incremental rising of costs required to meet
increased demand. For example, if, at a certain volume of API calls,
the Certified API Developer needed to deploy additional server
capacity, the associated incremental cost of bringing an additional
server online could be passed on to the API Information Source because
the certified API technology deployed on behalf of the API Information
Source was the subject of the higher usage. In this example, up until
the point that the threshold is reached, the additional server capacity
is not required, so the Certified API Developer would not be permitted
to recover the costs associated with it. Moreover, the additional
server capacity would support ongoing demand up to a certain additional
volume, so the Certified API Developer would not be permitted to
recover the costs of further additional server capacity until the
existing capacity was exhausted.
(G) Permitted Fee for Value-Added Services
We proposed in 84 FR 7490 and 7491 in Sec. 170.404(a)(3)(iv) to
permit an API Technology Supplier to charge fees to API Users for
value-added services supplied in connection with software that can
interact with the API technology. We also clarified in 84 FR 7491 that
a fee will only be permitted if it relates to a service that an API
User, such as a software developer, can elect to purchase, but is not
required to purchase in order to develop and deploy production-ready
apps for API technology.
Comments. Several commenters supported our proposal to permit an
API Technology Supplier to charge fees to API Users for value-added
services supplied in connection with software that can interact with
certified API technology. Some commenters requested certain
clarifications regarding our proposal. One commenter requested that we
clarify within the discussion of value-added services, that references
to ``app stores'' and ``listing processes'' for software applications
that register to connect with the API technology are solely intended as
examples to illustrate when a fee would or would not qualify as a
``value-added service,'' and are not meant to convey a requirement or
expectation that API Technology Suppliers provide an app store with
application listing free of charge. A few commenters requested that ONC
clarify that EHR developers can charge value-add fees without
triggering the information blocking provision. A couple other
commenters requested additional examples of what constitutes a ``value-
added'' service for which an API Technology Supplier can charge fees to
an API User.
Response. We thank commenters for the feedback. We have finalized
Sec. 170.404(a)(3)(iv) as proposed, with the exception of updating
terms based on the definitions finalized in Sec. 170.404(c). Our final
policy permits Certified API Developers to charge fees, including a
reasonable profit margin, to API Users for value-added services related
to certified API technology, so long as such services are not necessary
to efficiently and effectively develop and deploy production-ready
software that interacts with certified API technology. We clarify that
the value-added services need to be provided in connection with and
supplemental to the development, testing, and deployment of production-
ready software applications that interact with certified API
technology. A fee is permitted if it relates to a service that a
software developer can elect to purchase from a Certified API
Developer, but is not required to purchase in order to develop and
deploy production-ready apps for certified API technology.
In response to comments for clarity, we note that examples used to
illustrate when a fee would or would not qualify as a ``value-added
service,'' such as app store listing, are demonstrative, but not
required unless otherwise noted in the regulation text. Under this
condition, we permit fees for services associated with the listing and
promotion of apps beyond basic application placement so long as the
Certified API Developer ensures that basic access and listing in the
app store is provided free of charge (if an application developer
depended on such listing to efficiently and effectively develop and
deploy production-ready apps for use with certified API technology).
Fees charged for additional/specialized technical support or promotion
of the API User's application beyond basic access and listing services
would be examples of permitted value-added services. We caution health
IT developers not to over-interpret the scope of this Condition of
Certification, which is focused on certified API technology. To the
degree that a health IT developer administers an ``app store'' and
offers value-added services associated with certified API technology,
the Condition of Certification covers its practices related to
certified API technology only. Conversely, this Condition of
Certification would not apply to any practices that do not involve
certified API technology. However, health IT developers would need to
be mindful of any applicable information blocking rules that may apply
to their app store practices given applicable facts and circumstances.
Regarding the request for specific value-added fees that would not
constitute information blocking, we refer readers to the information
blocking section (VIII) of this preamble.
(H) Request for Comment on Sec. 170.404(a)(3)
We requested comment at 84 FR 7491 on any additional specific
``permitted fees'' not addressed in our Proposed Rule (84 FR 7491) that
commenters felt API Technology Suppliers should be able to recover in
order to assure a reasonable return on investment. Furthermore, we
requested comment on whether it would be prudent to adopt specific, or
more granular, cost methodologies for the calculation of the permitted
fees. We encouraged commenters to consider, in particular, whether the
approach we described would be administrable and appropriately balance
the need to ensure that stakeholders do not encounter unnecessary costs
and other special effort with the need to provide adequate assurance to
API Technology Suppliers, investors, and innovators that they will earn
a reasonable return on their investments in API technology. We welcomed
comments on whether the approach adequately balances these concerns and
achieves our stated policy goals. We also welcomed comments on
potential revisions or alternative approaches. We encouraged detailed
comments that included, where possible, economic justifications for
suggested revisions or alternative approaches.
Comments. Commenters suggested we alter our approach to APIs so
that it is tiered fee structure. They suggested that ONC could
establish categories where the technology requirements designate the
fees: (1) A ``no fee'' category would limit API Technology Suppliers
from charging API Data Providers or API Users any fees for exchanging
data in compliance with Federal requirements; (2) an ``at cost''
category would allow API Technology Suppliers to charge API Data
Providers or API Users the cost of interfacing APIs with a non-API
Technology Supplier's commercial technology; and (3) a ``cost plus
reasonable profit'' category would allow
[[Page 25761]]
API Technology Suppliers to charge API Data Providers or API Users a
reasonable profit when conducting legitimate custom API development or
creating custom apps.
Response. We appreciate the recommendation from commenters, but we
have not adopted a tiered fee structure in the final rule because it
would require unnecessary specificity and prescribe a particular method
that could have unintended effects of limiting the market's evolution
over time. We believe the current structure for prohibited and
permitted fees allows for the adequate cost recovery and reasonable
profit by Certified API Developers while also establishing the
guardrails around which API access can be enabled without special
effort.
Comments. Many commenters expressed concerns related to the effect
our proposals regarding API fees would have on innovation and business.
Several commenters noted that the structure of permitted fees could
have unintended consequences that will ultimately work to impede
innovation, increase administrative burden, and focus on cost recovery
rather than creation of novel ways to improve data access.
Several developers stated that the proposed fee structure
specifically works to sever business relationships between API
Technology Providers and API Users for anything other than ``value
added services'' and effectively eliminates the ability for API Users
to work directly with API Technology Suppliers to innovate and
accelerate API development, and to achieve truly integrated and
supported products throughout the product lifecycle. They suggested
that a better model would be one that gives API Data Providers rights
to leverage APIs ``without special effort,'' while supporting the
ability for API Technology Suppliers and API Users to voluntarily
engage in direct business relationships under mutually agreeable terms
that are fair and equitable. Some developers stated that the market
should determine permitted fees. They stated that in order to maintain
a vigorously competitive market, API Technology Suppliers must be
adequately compensated for their work to create and deploy non-standard
APIs and support expanding standards. They explained that without this
compensation, there will be far fewer entrants into the certified
health IT space and current participants will depart.
A couple of developers recommended that ONC allow revenue-sharing
models for certain components of certified APIs. The commenters
suggested that ONC should view revenue sharing arrangements as a type
of market-based compensation that will ultimately benefit innovation
and competition. Conversely, one commenter stated that it is essential
that API Technology Suppliers be expressly prohibited from conditioning
access to API technology on charging revenue-sharing or royalty
agreements to API Data Providers or API Users outside of actual usage
costs incurred. The commenter noted this rent-seeking behavior is anti-
competitive in nature and can have a significant impact on squelching
any new market entrants and allow existing health IT actors to prevent
all the positive outcomes that could arise from the ONC's proposed
rules. Some developers stated that the prohibition against health IT
developers charging for work to update their code structure is
unreasonable, emphasizing that this is important work that is necessary
for companies to be able to modernize their solutions as broader
technologies evolve.
Response. We appreciate these comments, but disagree with
commenters regarding the potential negative effect of the final
permitted fee structure on innovation. We also note that the value-
added services permitted fee does permit a direct relationship between
Certified API Developers and API Users. What is generally prohibited
and what we noted presented ``special effort'' in the Proposed Rule
were Certified API Developer practices that required an API Information
Source to seek permission to use its own certified API technology from
the Certified API Developer.
We reiterate that complying with the requirements of this permitted
fee and the information blocking exception will generally not prevent
an actor from making a reasonable profit in connection with the access,
exchange, or use of EHI. To be responsive to comments, we have added a
provision in Sec. 171.404(a)(3)(i)(A) to clarify this point. This
final provision states that certain permitted API fees (Sec.
170.404(a)(3)(ii) and Sec. 170.404(a)(3)(iv)) may include fees that
result in a reasonable profit margin in accordance with the Costs
Exception (Sec. 171.302). We believe that the allowance of reasonable
profits is necessary to incentivize innovation and allow innovators to
earn returns on the investments they have made to develop, maintain,
and update innovations that ultimately improve health care delivery and
benefit patients. Our finalized approach to API fees strikes the
appropriate balance of addressing the rent-seeking and exclusionary
pricing practices noted by the commenters while enabling and supporting
innovation.
We also emphasize that a majority of the EHI has been generated and
recorded in the course of furnishing health care services paid with
public dollars through Federal programs, including Medicare and
Medicaid, or directly subsidized through the tax preferences for
employer-based insurance. Yet, this EHI is not readily available where
and when it is needed. We believe the overwhelming benefits of
publishing certified APIs that allow EHI from such technology to be
accessed, exchanged, and used without special effort far outweigh the
potential burden on Certified API Developers and API Information
Sources.
Comments. A few commenters requested that ONC clarify whether API
Data Suppliers would be allowed to recoup costs from API Users in light
of the information blocking provisions. A few commenters expressed
confusion that fees are addressed under the API Condition and
Maintenance of Certification and information blocking. The commenters
suggested that ONC address fees in one consolidated section.
Response. We appreciate this comment and refer readers to the
information blocking section of this rule. We do not believe that a
discussion of fees should be consolidated in one section for a couple
of reasons. First, the information blocking provision has a much
broader reach than the Condition and Maintenance of Certification
requirements and regulates conduct of health IT developers of certified
Health IT Modules, health care providers, health information networks,
and health information exchanges. The Condition and Maintenance of
Certification requirements only relate to conduct by health IT
developers of certified Health IT Modules. Second, the API Condition of
Certification covers a much narrower scope of potential fees, as the
fees in this section are specific to certified API technology only
while fees in the information blocking section generally relate to the
access, exchange, or use of EHI regardless of the particular technology
used.
We emphasize that we have finalized a provision in Sec. 171.302(c)
that if the actor is a health IT developer subject to the Condition of
Certification requirements in Sec. 170.402(a)(4) (Assurances), Sec.
170.404 (API), or both, the actor must comply with all requirements of
such conditions for all practices and at all relevant times. Under this
provision, health IT developers of certified Health IT
[[Page 25762]]
Modules subject to the API Condition of Certification requirements may
not charge certain types of fees and are subject to more specific cost
accountability provisions than apply generally under the Costs
Exception. We explain in the Costs Exception that a failure of
developers to comply with these additional requirements would impose
impediments to consumer and other stakeholder access to EHI without
special effort and would be suspect under the information blocking
provision.
vi. Openness and Pro-Competitive Conditions
We proposed in 84 FR 7595 in Sec. 170.404(a)(4) that an API
Technology Supplier must grant API Data Providers the sole authority
and autonomy to permit API Users to interact with the API technology
deployed by the API Data Provider in a non-discriminatory manner;
provide all reasonably necessary support and other services to enable
the effective development, deployment, and use of API technology by API
Data Providers and its API Users to access, exchange, and use EHI in
production environments; not impose collateral terms or agreements that
could interfere with the use of API technology; and provide reasonable
notice prior to making changes to its API technology or terms and
conditions.
Comments. The majority of commenters supported the proposed
openness and pro-competitive conditions. Several commenters requested
clarification about API Data Providers' rights and responsibilities
when providing access to an application of a patient's choice.
Specifically, they sought clarification on whether they can vet, deny,
or limit access by applications that are using the API technology
inappropriately. Another commenter proposed that app developers be
required to obtain a business associate agreement (BAA) with providers
prior to the application developer gaining access to a patient's EHI on
behalf of a patient.
Response. We appreciate the feedback from commenters. Based on the
support from commenters, we have finalized that a Certified API
Developer must grant API Information Sources the independent ability to
permit API Users to interact with the certified API technology deployed
by the API Information Source in Sec. 170.404(a)(4).
Under the HIPAA Privacy Rule, a business associate relationship
exists if an entity creates, receives, maintains, or transmits ePHI on
behalf of a covered entity (directly or through another business
associate) to carry out the covered functions of the covered entity.
HIPAA does not require a covered entity (e.g., API Information Source)
or its business associate (e.g., API Technology Supplier) to enter into
a business associate agreement with an app developer that does not
create, receive, maintain, or transmit ePHI on behalf of or for the
benefit of the covered entity (whether directly or through another
business associate). However, if the app was developed to create,
receive, maintain, or transmit ePHI on behalf of the covered entity
(API Information Source), or was provided by or on behalf of the
covered entity (directly or through its API Technology Supplier, acting
as the covered entity's business associate), then a business associate
agreement would be required.\106\ In such cases, API Information
Sources have the ability to conduct whatever ``vetting'' they deem
necessary of entities (e.g., app developers) that would be their
business associates under the HIPAA Rules before granting access and
use of EHI to the entities. In this regard, covered entities must
conduct necessary vetting in order to comply with the HIPAA Security
Rule.
---------------------------------------------------------------------------
\106\ https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/access-right-health-apps-apis/index.html.
---------------------------------------------------------------------------
For third-party applications chosen by individuals to facilitate
their access to their EHI held by actors, there would not be a need for
a BAA as discussed above. There would also generally not be a need for
``vetting'' on security grounds and such vetting actions otherwise
would be an interference. Please see our discussion of ``vetting'' in
the ``Interference Versus Education When an Individual Chooses
Technology to Facilitate Access'' discussion in the Information
Blocking section of the preamble (Section VIII). We also refer readers
to our discussion of ``vetting'' versus verifying an app developer's
authenticity under the API Condition of Certification later in this
section of the preamble.
Comments. Several commenters requested clarification about the
types of business relationships permitted between API Technology
Suppliers and API Users and requested examples of permitted activities
and responsibilities under each role. These comments expressed concern
about prohibiting API Technology Suppliers from being able to form
direct relationships with API Users for the purpose of joint
development and commercialization of their products. Other commenters
requested clarifications about relationships that existed prior to the
involvement of an API Data Provider.
Response. We appreciate the feedback from commenters. Based on the
general support, we have finalized in Sec. 170.404(a)(4)(i)(A) that a
Certified API Developer must provide certified API technology to API
Information Sources on terms that are no less favorable than it
provides to itself and its own customers, suppliers, partners, and
other persons with whom it has a business relationship. Additionally,
we have finalized in Sec. 170.404(a)(4)(i)(B) that the terms on which
a Certified API Developer provides certified API technology must be
based on objective and verifiable criteria that are uniformly applied
to all substantially similar or similarly situated classes of persons
and requests. Furthermore, we have finalized in Sec.
170.404(a)(4)(i)(C) that a Certified API Developer must not offer
different terms or services on the basis of: Competition or potential
for competition and revenue or other value the other party receiving
the services may receive from using the certified API technology. We
note that we slightly modified the finalized requirements in Sec.
170.404(a)(4)(i) based on the revised definitions finalized in Sec.
170.404(c). We clarify that this rule does not prohibit Certified API
Developers from forming business relationships with API Users. To the
degree that a Certified API Developer seeks to charge an API User for
particular services associated with its certified API technology, it
would need to do so pursuant to the ``value-added services'' permitted
fee.
Comments. Commenters requested clarification about how ``the sole
authority and autonomy to unilaterally permit connections to their
health IT through certified API technology'' applies to application
registration. Specifically, they asked whether API Users are required
to register once with the API Technology Supplier, or several times
with each instance of API technology deployed by API Data Providers.
Response. We appreciate the feedback from commenters. We refer
commenters to Sec. 170.315(g)(10)(iii) for the application
registration requirements for Health IT Modules presented for
certification. In general, we do not prescribe the registration
paradigm that Certified API Developers create for themselves and their
customers. Thus, in different scenarios, an API User may only be
required to register once with an Certified API Developer, or several
times with each instance of a Sec. 170.315(g)(10)-certified Health IT
Module deployed by an API Information Source. When it comes to apps
that focus on the ``launch-ehr'' ``SMART on FHIR Core Capability'' from
the
[[Page 25763]]
implementation specification adopted in 170.215(a)(3), such an approach
will be tightly integrated with the Health IT Modules deployed by API
Information Sources. Because of the tight integration between API
Information Sources and Health IT Modules, registration for these apps
could more often fall to the API Information Source. When it comes to
apps that enable patient access, registration could be handled
centrally by Certified API Developers or in a distributed manner with
each API Information Source, especially in cases where API Information
Sources take full responsibility for administering their Sec.
170.315(g)(10)-certified Health IT Modules.
Regarding ``the sole authority and autonomy to unilaterally permit
connections to their health IT through certified API technology,'' we
have finalized in 170.404(a)(4)(ii)(A) that Certified API Developer
must have and, upon request, must grant to API Information Sources and
API Users all rights that may be reasonably necessary to (1) access and
use certified API technology in a production environment; (2) develop
products and services that are designed to interact with the Certified
API Developer's API technology; and (3) market, offer, and distribute
products and services associated with the Certified API Developer's
certified API technology.
Additionally, we have finalized in Sec. 170.404(a)(4)(ii)(B) that
a Certified API Developer must not condition any of the rights
described in Sec. 170.404(a)(4)(ii)(A) on: (1) Receiving a fee,
including but not limited to a license fee, royalty, or revenue-sharing
arrangement; (2) agreeing to not compete; (3) agreeing to deal
exclusively with the Certified API Developer; (4) Obtaining additional
services that are not related to the certified API technology; (5)
sharing intellectual property with the Certified API Developer; (6)
meeting any Certified API Developer-specific testing or certification
requirements; and (7) providing the Certified API Developer or
technology with reciprocal access to application data. We slightly
modified the conditions from the Proposed Rule for what we finalized in
Sec. 170.404(a)(4)(ii)(B) for clarity, and amended terms to the
revised definitions finalized in Sec. 170.404(c). Additionally, we
clarify that while Certified API Developers are not permitted to
condition the rights described in Sec. 170.404(a)(4)(ii)(A) on
receiving a fee, Certified API Developers are permitted to charge fees
compliant with the permitted fees described in Sec. 170.404(a)(3). We
also clarify that ``meeting any Certified API Developer-specific
testing or certification requirements'' would include preconditions
like registering and testing in a testing environment prior to moving
to production, and meeting Certified API Developer-created
certification requirements.
Comments. Commenters expressed concern about software applications
maintaining compatibility when upgrading API technology, and
highlighted the importance of adopting backwards-compatible standards.
Response. We appreciate the feedback from commenters. We share the
concern expressed by commenters. We specifically consider features of
standards like backwards compatibility when proposing and finalizing
testing and certification requirements for the Program. As mentioned
above, we have finalized the standard adopted in Sec. 170.215(a)(1) as
the base standard for the certification criterion adopted in Sec.
170.315(g)(10) Standardized API for Patient and Population Services. We
note that the standard adopted in Sec. 170.215(a)(1) includes many
FHIR resources that need to retain their compatibility over time, which
will help as upgrades to newer standards occur. Additionally, we have
finalized in Sec. 170.404(a)(4)(iii) the service and support
obligations required by a Certified API Developer, including the
requirements that a Certified API Developer must provide all support
and other services reasonably necessary to enable the effective
development, deployment, and use of certified API technology by API
Information Sources and API Users in production environments. These
include requirements for changes and updates to API technology
finalized in Sec. 170.404(a)(4)(iii)(A), where Certified API
Developers must make reasonable efforts to maintain the compatibility
of its certified API technology and to otherwise avoid disrupting the
use of certified API technology in production environments, and
requirements for changes to terms and conditions finalized in Sec.
170.404(a)(4)(iii)(B), where Certified API Developers must provide
notice and reasonable opportunity for its API Information Source
customers and registered API Users to update their applications to
preserve compatibility with API technology and to comply with
applicable terms and conditions.
e. API Maintenance of Certification Requirements
i. Authenticity Verification
We proposed in 84 FR 7486 in Sec. 170.404(a)(2)(ii)(C) to permit
API Technology Suppliers to verify the authenticity of application
developers, limited to a duration of no greater than five business days
of receipt of a request to register an application developer's software
with the API technology. We noted the authenticity verification process
would need to be objective, apply to the application developer and not
their software, and be the same for all application developers. We
sought comment in 84 FR 7486 on factors that would enable registration
with minimal barriers, including options and associated trade-offs.
Additionally, we sought comment at 84 FR 7486 on other timing
considerations for application developer authenticity verification.
Comments. Commenters asked for a longer timeframe to complete the
authenticity verification process of application developers. Some
commenters asked to extend the authenticity verification timeframe to
ten business days. Commenters suggested adding ``and any receipt of any
additional requested information needed in order to verify the
developer's authenticity'' to ``within five business days of receipt of
an application developer's request to register their software
application with the API technology provider's authorization server.''
Commenters suggested various methods for verifying the authenticity
of application developers and applications, including by proposing
required registration information, or required attestation to model
privacy guidelines or industry best practices. Other commenters
suggested various approaches for verifying application developers and
applications, including by working with industry to establish a
verification body, privacy and security trust or certification
framework, and other more detailed recommendations. Several commenters
suggested requiring application developers to attest to providing a
model privacy notice to patients. Commenters suggested mandating terms
and conditions and consent requirements as part of the registration
process.
Response. We appreciate feedback from commenters. To improve the
organization of these Condition and Maintenance of Certification
requirements, we moved the requirements proposed in Sec.
170.404(a)(2)(ii)(C) to the finalized Sec. 170.404(b)(1)(i) under the
combined Sec. 170.404(b)(1), ``Authenticity verification and
registration for production use.'' We accept commenters' requests to
establish a longer time period for this permitted, but not required,
process to verify the authenticity of application developers
[[Page 25764]]
who seek to register their software application for use with the
Certified API Developer's certified API technology. We have adopted ten
business days as the timeframe by which this process would need to be
completed and as a result find it unnecessary to add the text
contemplating a back and forth between the Certified API Developer and
API User. We recommend that Certified API Developers who elect to
institute a verification process implement a process that is as
automated as possible to ensure they remain in compliance with our
final policy. Given that we combined authenticity verification and
registration for production use in one requirement finalized in Sec.
170.404(b)(1), we reduced the scope of these requirements to Certified
API Developers with a Health IT Module certified to the certification
criterion adopted in Sec. 170.315(g)(10) to remain consistent with the
scope of applicability of registration for production use from the
Proposed Rule.
We also note that authenticity verifications would likely occur
more frequently for patient-facing applications that are not sponsored
by API Information Sources. We anticipate that an API Information
Source (e.g., a health care organization) that is a HIPAA covered
entity would vet and enter into a HIPAA business associate agreement
with a provider-facing application developer prior to using the
application within their internal technical enterprise. In comparison,
a patient-facing application is likely to connect to an API Information
Source's resource server using a public service base URL of a Sec.
170.315(g)(10)-certified Health IT Module in service to the patient's
HIPAA Privacy Rule right of access (45 CFR 164.524) or based on a
patient's HIPAA authorization (45 CFR 164.508) without first
establishing a relationship with the API Information Source. For
patient-facing applications, and to the comments suggesting we require
various modes of attestation to privacy guidelines in such contexts, we
refer commenters to the information blocking provisions in section VIII
for a discussion of permitted behaviors regarding privacy attestations.
Comments. Commenters suggested including a warning by the API Data
Provider that the application developer selected by the patient or
patient-designee is untrusted.
Response. We thank commenters for their feedback. An API
Information Source would not be prohibited from showing a warning to
patients as part of the patient authorization for an application to
receive their EHI from an API Information Source. This could include a
warning that an application attempting to access data on behalf of a
patient is untrusted. We refer commenters to the information blocking
provisions in section VIII for additional information about providing
warnings to patients.
ii. Registration for Production Use
We proposed in 84 FR 7494 in Sec. 170.404(b)(1) to require API
Technology Suppliers to register and enable all applications for
production use within one business day of completing its verification
of an application developer's authenticity.
Comments. Commenters generally supported the proposed registration
requirements. Most commenters suggested extending the registration
timeframe to five business days.
Response. We appreciate the feedback from commenters. We have
reorganized this section of the regulation text for readability by
combining ``Authenticity verification'' with ``Registration for
production use'' under the heading ``Authenticity verification and
registration for production use'' in Sec. 170.404(b)(1). We accepted
the recommendation from commenters to extend the registration timeline
and have finalized in Sec. 170.404(b)(2)(ii) a requirement for
Certified API Developers with Health IT Modules certified to the
certification criterion finalized in Sec. 170.315(g)(10) to register
and enable all applications for production use within five business
days of completing its verification of an application developer's
authenticity pursuant to requirements finalized in Sec.
170.404(b)(1)(i).
iii. Service Base URL Publication
We proposed in 84 FR 7595 in Sec. 170.404(b)(2) to require an API
Technology Supplier to support the publication of service base URLs for
all of its customers, and make such information publicly available, in
a computable format, at no charge.
Comments. A majority of commenters supported the proposal requiring
API Technology Suppliers to publish service base URLs for all of its
customers. Several commenters recommended the creation of a single,
publicly available repository to maintain all client endpoints. Some
stakeholders recommended ONC require additional facility information be
published with the service base URL. Commenters who disagreed with this
proposal stated that health IT developers cannot publish client
information without their consent, and that API Data Providers should
have the sole authority to publish their endpoints.
Response. We thank commenters on their feedback on our proposal
requiring a Certified API Developer to publish service base URLs for
all of its customers. The public availability and easy accessibility of
this information is a central necessity to assuring the use of
certified API technology without special effort, particularly for
patient-facing applications. We agree with the points made by
commenters on the need for a single or multiple publicly available
repositories that maintain provider service base URLs. We encourage
industry to coalesce around the development of a public resource from
which all stakeholders could benefit. We believe this would help scale
and enhance the ease with which service base URLs could be obtained and
used. While we support the concept of repositories for service base
URLs, we do not believe that creating a requirement under the Program
is the appropriate mechanism to foster industry support around this
concept at this time.
We acknowledge that stakeholders expressed concern about Certified
API Developers publishing client service base URLs and revised our
approach to focus on service base URLs necessary to support patient
access. We anticipate that many services related to certified API
technology will be developed and made available and do not believe it
is appropriate to burden Certified API Developers with publishing all
service base URLs for these services for all of their customers. We
considered several options, including requiring Certified API
Developers to publish service base URLs for only those API Information
Source customers for whom they manage/host an authorization server
centrally. However, we determined that alternative options would not
meet our policy interests and would lead to unnecessarily complex and
burdensome approaches and would not achieve the Cures Act's goals of
enabling EHI to be accessed, exchanged, and used without special
effort. Additionally, we considered requiring that all Certified API
Developers with certified API technology, that is, health IT developers
with a Health IT Module certified to Sec. 170.315(g)(7) through (10),
meet this requirement. However, we determined that it would be more
beneficial to allow health IT developers to focus energy and resources
on upgrading their technology to the certification criterion finalized
in Sec. 170.315(g)(10). Therefore, we have finalized in Sec.
170.404(b)(2) that a Certified API Developer must publish service base
URLs for all Health IT
[[Page 25765]]
Modules certified to Sec. 170.315(g)(10) that can be used by patients
to access their EHI. We further require that a Certified API Developer
must publicly publish service base URLs for all customers in a machine-
readable format at no charge regardless of whether the Health IT
Modules certified to Sec. 170.315(g)(10) are centrally managed by the
Certified API Developer or locally deployed by an API Information
Source. We note our focus for this criterion on ``service base URLs for
Health IT Modules certified to Sec. 170.315(g)(10) that can be used by
patients to access their EHI.'' We believe that Certified API
Developers will have adequate relationships with API Information
Sources in the process of providing Health IT Modules certified to
Sec. 170.315(g)(10) and will be able to collect and publish all
service base URLs that support patient access on behalf of their
customers. Furthermore, we note that API Information Sources would be
obligated to share such service base URLs with Certified API Developers
to avoid violating the Technical Interference Information Blocking
provisions as discussed further in section VIII. Certified API
Developers must make available appropriately scoped service base URLs
that can be used by patients to access their EHI for Health IT Modules
certified to Sec. 170.315(g)(10).
iv. Providing (g)(10)-Certified APIs to API Data Providers
We proposed in 84 FR 7494 in Sec. 170.404(b)(3) that an API
Technology Supplier with Health IT Modules previously certified to
Sec. 170.315(g)(8) must provide all API Data Providers Health IT
Modules certified to Sec. 170.315(g)(10) within 24 months of this
final rule's effective date.
Comments. The majority of comments received urged ONC to extend the
timeline beyond the 24 months proposed. Many commenters requested
separate timelines for developers and providers. Several commenters
recommended 36 months. Some commenters offered alternatives ideas for
timelines, including a stepwise approach, or ONC only determining
technical timelines, and allowing CMS to cover provider timelines. Only
a few commenters encouraged faster adoption.
Response. We appreciate commenters' feedback on our proposal. Given
the reduced scope of the overall updates required by this final rule,
our belief that the industry is well-prepared to meet this
certification criterion's requirements once the final rule is
published, and the Cure's Act expectation that secure, standards-based
APIs would be made available in a timely manner, we have retained a 24
month compliance timeline, which will start from the publication date
of the final rule. At that point, it will be approximately five years
since the Cures Act's passage and we believe its implementation should
not be delayed any further. We also remind stakeholders that this is
within 24 months of this rule's publication compliance date for
supplying all API Information Sources with Health IT Modules certified
to Sec. 170.315(g)(10) enables Certified API Developers (based on
their client base and IT architecture) to determine the most
appropriate timeline for development, testing, certification, and
product release cycles. Thus, we have finalized in Sec. 170.404(b)(3)
that a Certified API Developer with certified API technology previously
certified to the certification criterion at Sec. 170.315(g)(8) must
provide all API Information Sources with such certified API technology
deployed with certified API technology certified to the certification
criterion in Sec. 170.315(g)(10) within 24 months of the publication
date of the final rule.
v. Compliance for Existing Certified API Technology
We proposed in 84 FR 7486 that API Technology Suppliers with Health
IT Modules certified to Sec. 170.315(g)(7), (8), or (9) must revise
their existing API documentation within six months from the final
rule's effective date.
Comments. Some commenters supported the requirement to revise
existing API documentation within six months of the final rule's
effective date. Others requested more time to allow documentation and
all other websites to come into alignment before enforcement of this
Condition of Certification requirement. One commenter requested
clarification on which documentation requires revision within the six-
month timeframe.
Response. In order to align the API Condition of Certification
requirements policies, we have broadened the scope of the provision
finalized in Sec. 170.404(b)(4) to apply to all API Condition of
Certification requirements finalized in Sec. 170.404(a), including
Sec. 170.404(a)(1) through (4). Given the change of scope, we renamed
this section to ``Compliance for existing certified API technology.''
We considered commenters' request for more time, but given the already
delayed effective date of Part 170 we believed the proposed time of six
months sufficient to enable Certified API Developers to become
compliant with the Condition of Certification requirements finalized in
Sec. 170.404(a). This additional time provides Certified API
Developers with Health IT Modules already certified to Sec.
170.315(g)(7), (8), or (9) a total of eight months from the final
rule's publication to update their policies and documentation to comply
with the requirements finalized in Sec. 170.404(a). We did not allow a
longer time period than six months in Sec. 170.404(b)(4) due to the
fact that we have finalized our proposal in Sec. 170.404(b)(3) to
require Certified API Developers with Health IT Modules previously
certified to the certification criterion in 170.315(g)(8) to provide
Sec. 170.315(g)(10)-certified APIs to API Information Sources within
24 months of final rule's publication date. These policies finalized in
Sec. 170.404(b)(4) provide API Information Sources with Health IT
Modules certified to Sec. 170.315(g)(8) with 18 months of updated
documentation before the new requirements finalized in Sec.
170.404(b)(3) become effective. Setting a more delayed compliance date
than the one finalized in Sec. 170.404(b)(4) would have unreasonably
delayed and ultimately diminished the benefits of the Program
requirements we have finalized in this rule. In summary, we finalized
in Sec. 170.404(b)(4) that Certified API Developers with Health IT
Modules certified to Sec. 170.315(g)(7), (8), or (9) must comply with
Sec. 170.404(a) no later than six months after this final rule is
published in the Federal Register, including by revising their existing
business and technical API documentation and making such documentation
available via a publicly accessible hyperlink that allows any person to
directly access the information without any preconditions or additional
steps.
5. Real World Testing
The Cures Act requires, as Condition and Maintenance of
Certification requirements under the Program, that health IT developers
successfully test the real world use of the technology for
interoperability \107\ in the type of setting in which such technology
would be marketed. As discussed in the Proposed Rule (84 FR 7495), the
objective of real world testing is to verify the extent to which
certified health IT deployed in production contexts continues to
demonstrate conformance to the full scope of applicable certification
criteria and functions with the intended use cases as part of the
overall maintenance
[[Page 25766]]
of a health IT's certification. Real world testing should assess that
the certified health IT is meeting the intended use case(s) of the
certification criteria to which it is certified within the workflows,
system architectures, and type(s) of care setting(s) for which it is
marketed (advertised, promoted, or sold).
---------------------------------------------------------------------------
\107\ Defined in statute in section 3000 of the Public Health
Service Act (as modified by section 4003 of the Cures Act) and
defined in regulation at 45 CFR 170.102.
---------------------------------------------------------------------------
For the purpose of this Condition of Certification requirement, in
Sec. 170.405(a), we proposed (84 FR 7495) that successful real world
testing means:
The certified health IT continues to be compliant to the
full scope of the certification criteria to which it is certified,
including the required technical standards and vocabulary codes sets;
The certified health IT is exchanging electronic health
information in the care and practice settings for which it is intended
for use; and
Electronic health information is received by and used in
the certified health IT.
To fully implement the real world testing Condition of
Certification requirement, we proposed Maintenance of Certification
requirements that would require health IT developers to submit publicly
available prospective annual real world testing plans and retrospective
annual real world testing results for the certification criteria
focused on interoperability to which each of its Health IT Modules is
certified (84 FR 7496).
Comments. Comments on the whole support the establishment of a
robust process of real world testing. Several commenters expressed
concerns regarding the quality and usability of health IT.
Specifically, commenters indicated that issues related to health IT
usability may be contributing to clinician burn-out or impacting
patient safety, noting that they therefore strongly support the
inclusion of robust real world testing requirements.
Response. We appreciate all comments, and have finalized real world
testing Condition and Maintenance of Certification requirements in
Sec. 170.405(a) and (b) as proposed, with minor adjustments to due
dates and clarifications of several points in response to specific
comments as discussed below.
Comments. Commenters indicated that additional clarification of the
real world testing requirements would make these Condition and
Maintenance of Certification requirements less burdensome to implement.
These commenters specifically sought additional guidance around the
expectations for an appropriate testing plan and method of execution.
One commenter recommended that ONC provide more guidance around what
care settings must be covered by test plans, and establish a minimum
number of settings and test sites that are applicable for certified
Health IT Modules.
Response. In response to comments requesting additional guidance
around expectations and acceptable methods for real world testing, we
provide below additional discussion, explanation, and illustrative
examples. At this time, we have decided not to establish a minimum
number of settings or minimum percentage or fraction of production
instances of the developer's applicable certified Health IT Modules
that must be included in the developer's annual real world testing
activities. While health IT developers are not required to test their
certified health IT in each and every setting in which it is intended
for use, we would expect a developer's real world testing plan to
address each type of clinical setting for which their health IT is
marketed. Developers must address in their real world testing plans
their choice of care and/or practice settings to test and provide a
justification for their chosen approach. We also remind developers that
although we are not requiring testing in every setting for which the
certified health IT is marketed, we encourage real world testing in as
many specific settings as feasible within each type of setting for
which the certified health IT is marketed.
Comments. Some commenters expressed a view that there has been too
much focus on the export capabilities of systems and not enough
attention paid to providers being able to ingest data received in
standardized formats--such as the Continuity of Care Document (CCD)
standard--from other providers, including other providers who use the
same developer's Health IT Modules certified to produce exports in
conformance with the standards.
Response. The interoperability focused criteria listed in Sec.
170.405(a) include required capabilities for receiving and
incorporating data in accordance with referenced standards and
implementation specifications adopted by the Secretary in part 170
subpart B. We believe this appropriately aligns requirements for real
world testing of Health IT Modules' ability to ingest data with the
capabilities their certifications address.
Comments. A commenter recommended that, for real world testing of
Health IT Modules certified to the API criterion, the final rule
require health IT developers to provide a testing environment (or
``developer sandbox'') and require the use of a testing platform and
test scripts that validate the ability of the API to meet the
underlying requirements for the version of FHIR[supreg] to which Health
IT Module(s) are certified, any applicable FHIR[supreg] profiles, and
implementation guides.
Response. As discussed in the Proposed Rule (84 FR 7496), we
believe health IT developers are in the best position to design and
facilitate implementation of real world testing approaches that balance
the burdens of this statutory requirement with its intended assurances
that certified health IT as deployed in the types of clinical settings
for which it is marketed (advertised, promoted, or sold) continues to
meet the Program requirements, including but not limited to
interoperability performance, applicable under the certification it
holds. While we recognize that testing environments can be useful for a
variety of purposes, and would not generally discourage developers from
offering test platforms specific to their products or participating in
the development and use of open-source testing platforms, the purpose
of real world testing is to demonstrate that Health IT Modules continue
to perform in conformance to their certification when and as they are
deployed in production environments supporting the types of clinical
settings for which the Health IT Modules are marketed. Thus, real
patient data and real production environments will in most cases best
meet that need and should be first considered when developing real
world testing plans. Mandating creation or use of testing environments
for real world testing would compete for developers' time and effort
with the focus on innovative ways to best serve the purpose of the real
world testing Conditions and Maintenance of Certification requirements
at the least burden on their customers and end users. We have therefore
not required health IT developers to provide a testing environment (or
``developer sandbox'') nor have we required the use of a testing
platform or test scripts in order to satisfy real world testing
Condition and Maintenance of Certification requirements.
Comments. Several commenters requested that ONC be mindful of the
burdens this testing could place on health care providers in terms of
time and cost and take all necessary steps to minimize such burdens.
Commenters specifically stated real world testing would require
significant work by providers for whom, in the commenters' stated view,
there is no incentive to
[[Page 25767]]
participate in real world testing. Some commenters specifically
recommended that HHS incentivize providers to participate, stating that
without providers' participation, this proposal would become an
untenable requirement. One commenter requested HHS clarify whether a
developer would be permitted to compensate its customers for the time
the customer spends supporting the developer's real world testing
activities.
Response. We thank commenters for their feedback noting the
potential for health IT developers' real world testing activities to
impose burden on providers. We do appreciate the importance of
recognizing that providers engage directly and actively in various
types of activities supporting advancement of health IT. The fact that
many of these activities could be included in robust real world testing
regimes suggests that we should provide developers with extensive
flexibility to develop innovative real world testing plans. We have
therefore built into our real world testing policy flexibility that
offers the developer a substantial opportunity to design real world
testing approaches that minimize burden and fully optimize value of the
real world testing activities and results to current and prospective
customers. We do not believe that HHS incentives to providers
participating in real world testing would be the most effective means
of alleviating burdens on health care providers specifically
attributable to developers' real world testing activities. Rather, the
flexibility of our policy allows for, and encourages, developers to
approach real world testing in an innovative mode so that they can
maximize efficiency and minimize burden of real world testing for both
the developer and its customers. A wide range of practical strategies
are available for developers to potentially consider in creating such
optimized solutions for real world testing of their specific health IT
with their particular customer base. Examples of this range of
practical strategies include, but are not necessarily limited to:
Avoiding some activities that satisfy only the real world testing
Maintenance of Certification requirements by including in its overall
real world testing plans the testing typically associated with
confirming functionality of new installations and upgrades of their
software; and innovating methods of measuring products' performance in
real time use through system metadata and/or feedback from health
information networks and other exchange partners of their customers.
In response to the recommendation that developers be allowed to
compensate their customers for participating in the developer's real
world testing activities, we note that nothing in our proposed or
finalized policy under part 170 would prohibit that. In the event a
developer concludes that its real world testing approach imposes on its
customers directly participating in real world testing activities a
burden that the developer would like to offset for those customers, we
would not discourage the developer from considering whether there may
be opportunities within the bounds of other applicable laws or
regulations for developers of certified health IT to offer customers
some types of burden-offsetting compensation or other incentive for
real world testing participation. Analysis, interpretation, or changes
to such other law or regulation is outside the scope of this particular
rulemaking action. Moreover, outside the rulemaking process, developers
should be aware that ONC is not in a position to provide general
guidance on Federal laws specific to compensation arrangements or
advice specific to any particular circumstances or contemplated conduct
related to developers compensating providers for participating in
developers' real world testing activities. However, if developers or
providers may be contemplating a potential compensation arrangement
related to offsetting providers' cost or burden of engagement in
developers' real world testing, we offer as a point of information that
one publicly stated purpose of the HHS Office of the Inspector General
advisory opinion process is to provide meaningful advice about of the
applicability of the anti-kickback statute or other OIG sanction
statutes in specific factual situations.\108\
---------------------------------------------------------------------------
\108\ For more information about HHS Office of the Inspector
General advisory opinions and advisory opinion process, please
visit: https://oig.hhs.gov/compliance/advisory-opinions/index.asp.
---------------------------------------------------------------------------
Comments. One commenter expressed concern that developers with
small customer bases will have smaller pools of participants willing to
undergo a lengthy process which will require significant resources and
suggested developers submit results from a more limited scope of
testing only every three years.
Response. We reiterate that the policy we have finalized includes
substantial flexibility for developers to assess how to meet the real
world testing Condition and Maintenance of Certification requirements
in a way that appropriately minimizes burden on the current users of
their certified health IT.
Comments. A commenter expressed concern that health care providers
might be unwilling to use health IT that had not yet been certified,
and that this could make real world testing of Health IT Modules prior
to certification impractical.
Response. In our Proposed Rule (84 FR 7429), we proposed in Sec.
170.405(a) to limit the applicability of this Condition of
Certification to health IT developers with Health IT Modules that are
certified to one or more 2015 Edition certification criteria focused on
interoperability and data exchange. We also proposed that the real
world testing Condition of Certification would be met through meeting
the real world testing Maintenance of Certification requirements in
Sec. 170.405(b). We have finalized this proposal as proposed. Thus,
the real world testing Condition and Maintenance of Certification
requirements do not mandate testing real world use of a Health IT
Module in actual production environments before it is certified.
a. Unit of Analysis at Which Testing Requirements Apply
Comments. One commenter requested confirmation if real world
testing is required per CHPL listing, per product, or per company.
Response. The real world testing Condition and Maintenance of
Certification requirements apply to each developer that has at least
one Health IT Module certified to at least one of the interoperability
and exchange focused criteria listed in Sec. 170.405(a), because
Condition and Maintenance of Certification requirements apply to the
developer of certified health IT. However, each developer of certified
health IT to which the real world testing Condition and Maintenance of
Certification requirements apply must conduct real world testing for
each criterion within the scope of real world testing (Sec.
170.405(a)) to which each developer presents for certification a Health
IT Module that is part of a health IT product to be listed on the CHPL
are certified. A health IT developer with multiple products that are
listed on the CHPL and that include one or more Health IT Module(s)
certified to one or more of the criteria listed in Sec. 170.405(a)
need only submit one real world testing plan, and one real world
testing results report, for any given annual cycle of real world
testing, but the real world testing plan and results report must
address each of the developer's products that is listed on the CHPL.
Health IT developers with multiple health IT products that may include
the same Health IT Module(s) certified to one or
[[Page 25768]]
more of the criteria listed in 170.405(a) have discretion to design
their real world testing plans in a way that efficiently tests a
combination of products that include Health IT Modules certified
criteria listed in Sec. 170.405(a) so long as testing plans and
results are traceable to specific certified Health IT Modules and each
criterion to which the Health IT Module(s) are certified, and address
the types of settings for which the products are marketed. Because the
purpose of real world testing is to test health IT products as they are
deployed in production, developers of health IT products deployed
through the cloud who offer their products for multiple types of
clinical settings will be required to test the same capability for
those different types of settings even if it uses a single instance of
the deployed capability to serve all of those types of settings.
b. Applicability of Real World Testing Condition and Maintenance of
Certification Requirements
We proposed (84 FR 7495) to limit the applicability of the real
world testing Condition of Certification requirement to health IT
developers with Health IT Modules certified to one or more of the
certification criteria focused on interoperability and data exchange or
availability listed in (then-proposed) Sec. 170.405(a):
The care coordination criteria in Sec. 170.315(b);
The clinical quality measures (CQMs) criteria in Sec.
170.315(c)(1) through (c)(3);
The ``view, download, and transmit to 3rd party''
criterion in Sec. 170.315(e)(1);
The public health criteria in Sec. 170.315(f);
The application programming interface criteria in Sec.
170.315(g)(7) through (g)(10); and
The transport methods and other protocols criteria in
Sec. 170.315(h).
We solicited comment on whether to also include the ``patient
health information capture'' certification criteria in Sec.
170.315(e)(3), including the value of real world testing these
functionalities compared to the benefit for interoperability and
exchange (84 FR 7496). We also solicited comment on whether any other
2015 Edition certification criteria should be included or removed from
the applicability list (to be codified at 170.405(a)) for this
Condition of Certification requirement.
Comments. The vast majority of commenters addressing this proposal
were in support of the specific criteria proposed to be within the
scope of real world testing and expressed agreement that required
testing should be limited to Health IT Modules certified to one or more
of the certification criteria listed in Sec. 170.405(a) as proposed.
Response. We appreciate all feedback received. The list of criteria
to which real world testing Condition and Maintenance of Certification
requirements apply is finalized in Sec. 170.405(a) as proposed.
Comments. We received one comment supporting and two comments
opposing the addition of patient health information capture criterion
in Sec. 170.315(e)(3) to the scope of real world testing. One
commenter specifically recommended against including the patient health
information capture criterion in Sec. 170.315(e)(3) in real world
testing because of the significant variability in how health IT
certified to this criterion is implemented. They stated that this
variability in the real world could make cross-implementation
comparisons difficult, and stated that testing for this criterion could
present a particular challenge based on difficulty they anticipated
would be encountered in securing needed engagement from patients as
well as the exchange partners who would presumably receive the data as
a result of the patient using the ``transmit'' functionality.
Commenters opposed to addition of this criterion to the real world
testing Condition and Maintenance of Certification requirements also
stated this addition would add cost to the developer which would then
flow down to end users and be burdensome to clinician practices.
Response. On balance, the comments received do not support
expansion of the scope of real world testing requirements to include
the patient health information capture criterion in Sec. 170.315(e)(3)
at this time. In developing the proposed list of criteria to which real
world testing Condition and Maintenance of Certification requirements
would apply, we concluded an initial focus on those particular criteria
would strike an appropriate balance between the magnitude of the
challenge represented by the new real world testing requirements and
the potential benefits of their broader application. The concerns
raised by the commenters recommending against adding the patient health
information capture criterion in Sec. 170.315(e)(3) to the scope of
real world testing requirements at this time, combined with other
comments more generally recommending against a broader scope at this
time, tend to support the conclusion that the scope we proposed strikes
an appropriately practical balance until we and the industry have
benefit of experience and innovation in real world testing. Thus, the
finalized list of criteria to which real world testing requirements
apply (Sec. 170.405(a)) does not include the patient health
information capture criterion in Sec. 170.315(e)(3).
Comments. A few commenters suggested expanding the scope of real
world testing requirements to include the proposed ``EHI export''
criterion in Sec. 170.315(b)(10).
Response. We appreciate the confirmation that commenters supported
inclusion of the ``EHI export'' criterion in Sec. 170.315(b)(10)
alongside the rest of the care coordination criteria in Sec.
170.315(b). We have finalized the criteria listed in Sec. 170.405(a)
including, as proposed, all criteria within Sec. 170.315(b).
Comments. One commenter expressed an opinion that the initial scope
of criteria is more expansive than the commenter would suggest for an
introductory set, and asked that fewer criteria be required for the
initial rollout of real world testing, delaying application of the
requirement to more interoperability focused criteria until experience
has been amassed with real world testing for a narrower selection of
criteria than we had proposed.
Response. Noting that the majority of comments received were
supportive of the scope as proposed, we also balance suggestions such
as that offered by this commenter against the Program's needs and the
purpose of the real world testing Condition and Maintenance of
Certification requirements. We do not believe it would be in the best
interest of the Program or the health care providers and patients who
rely on certified health IT to meet their needs for interoperable
health IT to narrow the applicability of the real world testing
Condition and Maintenance of Certification requirements further than we
proposed. We have, therefore, finalized the criteria listed in Sec.
170.405(a) as proposed.
Comments. Some commenters advocated expanding the scope of the real
world testing requirement to include select functionally-based
``clinical'' criteria within Sec. 170.315(a) that are included in the
base EHR definition.
Response. As explained in the Proposed Rule (84 FR 7495), we did
not propose to include in the scope of real world testing functionally-
based criteria, administrative criteria, or other criteria that do not
focus on interoperability and exchange or availability of data. The
``clinical'' certification criteria in Sec. 170.315(a) were noted in
the Proposed Rule as an
[[Page 25769]]
example of criteria not proposed because they require only that the
health IT enable the provider to record, change, and access specific
types of data within the Health IT Module being certified (or within a
product that includes the Health IT Module being certified to the
particular criteria). However, real world testing of health IT's
ability to exchange the types of data these clinical criteria reference
is addressed through the inclusion of the USCDI in the
interoperability-focused criteria listed in Sec. 170.405(a) as
proposed, which is finalized as proposed. In order to successfully
exchange interoperable EHI, the health IT must be able to access it,
and in order to incorporate a type of data, the health IT must be able
to record it.
Comments. The majority of comments received specifically
referencing the proposed inclusion of public health criteria in the
real world testing requirement in Sec. 170.405(a) support the
importance and inclusion of the public health criteria in the scope of
real world testing requirements. One commenter questioned the inclusion
of the public health criteria in Sec. 170.315(f), stating the
commenter's perception that extensive variation between registries
would make this a challenging functionality to demonstrate.
Response. Variations in system configurations across different
public health agencies' infrastructures may suggest different real
world testing strategies may be most appropriate, or most relevant to
customers, compared to what might be the case for some other criteria
within the scope of real world testing. However, as noted below about
testing tools, we are aware of a wide variety of resources and
opportunities to test real world interoperability performance of Health
IT Modules certified to the public health criteria in Sec. 170.315(f).
Because interoperability performance in actual production environments
is an important feature of health IT certified to the public health
criteria in Sec. 170.315(f), and noting the support for its inclusion
expressed by most commenters, and we have determined that the most
appropriate course is to finalize the inclusion of the public health
criteria inSec. 170.315(f) in the scope of real world testing in Sec.
170.405(a).
Comments. One commenter expressed concern that some of the criteria
proposed for inclusion in Sec. 170.405(a) be re-examined because they
do not include all three of the characteristics our Proposed Rule
described as being demonstrated through real world testing. Examples
offered included that some criteria proposed for inclusion in Sec.
170.405(a) require exporting but do not require receipt and use of
electronic health information by the certified health IT.
Response. We appreciate commenters' bringing to our attention that
additional discussion about the requirements would be helpful to the
community. For the criteria proposed and finalized in the real world
testing scope in Sec. 170.405(a), such real world testing needs to
address the interoperability characteristics and all other
functionalities and capabilities applicable based on the specific
criteria to which the Health IT Module is certified. For example, even
if a Health IT Module is not certified to any criterion that
specifically requires it to demonstrate, in order to be certified, that
the Health IT Module has the capability to incorporate and use data
received directly from sources outside the production environment in
which it is deployed, that Health IT Module will still need to
demonstrate conformance to the full scope of each criterion to which it
is certified. This includes, though it is not limited to, the technical
standards and vocabulary codes sets included in each criterion to which
it certified.
c. Testing Plans, Methods, and Results Reporting
We proposed (84 FR 7496) that a health IT developers must submit an
annual real world testing plan to its ONC-ACB via a publicly accessible
hyperlink no later than December 15, of each calendar year for each of
its certified Health IT Modules that include certification criteria
specified for this Condition of Certification. We proposed (84 FR 7497)
that a health IT developer must submit an annual real world testing
plan to its ONC-ACB via a publicly accessible hyperlink no later than
January 31, of each calendar year for the preceding calendar year's
real world testing.
We proposed that the real world testing plan, which will be
required to be available to ONC and the public via the CHPL no later
than December 15 of each year once this final rule is effective, will
need to address the health IT developer's real world testing that will
be conducted the upcoming calendar year and must include, for each of
the certification criteria in scope for real world testing in Sec.
170.405(a) and each Health IT Module certified to one or more of these
criteria (84 FR 7496):
The testing method(s)/methodology(ies) that will be used
to demonstrate real world interoperability, including a mandatory focus
on scenario- and use case-focused testing;
The care and practice setting(s) that will be tested for
real world interoperability, including conformance to the full scope of
the certification criteria requirements, and an explanation for the
health IT developer's choice of care setting(s) to test; \109\
---------------------------------------------------------------------------
\109\ We do not specifically define or limit the care settings
and leave it to the health IT developer to determine. As an example,
health IT developers can consider categories, including but not
limited to, those used in the EHR Incentive Programs (https://www.cms.gov/Regulations-and-Guidance/Legislation/EHRIncentivePrograms/Downloads/UserGuide_QNetHospitalObjectivesCQMs.pdf); long-term and post-acute
care; pediatrics; behavioral health; and small, rural, and
underserved settings.
---------------------------------------------------------------------------
The timeline and plans for voluntary updates to standards
and implementation specifications that ONC has approved (further
discussed below);
A schedule of key real world testing milestones;
A description of the expected outcomes of real world
testing;
At least one measurement/metric associated with the real
world testing for each certification in scope; and
A justification for the health IT developer's real world
testing approach.
We sought comment (84 FR 7497) on whether we should specify a
minimum ``core'' set of metrics/measurements and examples of suggested
metrics/measurements as well as on the timing of required real world
testing results reporting. We also invited comment on the annual
frequency and timing of required real world testing results reporting.
Comments. Most comments received supported the proposed requirement
for Health IT Modules to undergo real world testing. In addition,
commenters indicated that real world testing should occur on a regular
basis to ensure various types of changes in the Health IT Modules or
production environments have not affected functionality required by the
certification. Several commenters recommended development of more
specific minimum requirements for test plans and measurement of
results. They further recommended that ONC provide additional guidance
about what will constitute a minimally acceptable testing plan with
explicit content depicting the minimum requirements for each component
of the testing plan.
Response. We thank commenters for their feedback. As discussed in
the Proposed Rule and above, we believe health IT developers are in the
best position to design and facilitate implementation of real world
testing approaches that balance the burdens of this statutory
requirement with its intended assurances that certified health
[[Page 25770]]
IT meets Program requirements, including interoperability performance,
applicable under the certification it holds. We have therefore
finalized requirements in Sec. 170.405(b)(1) designed to avoid the
risk of a ``one size fits all'' set of testing tools (discussed at 84
FR 7496) that might not fully address the concerns raised or provide
the assurances of interoperability performance sought across the
various types of care settings. By establishing in Sec.
170.405(b)(1)(iii) the topics and considerations every developer must
address in its required real world testing plan but not specifying how
they must address these required aspects we have provided health IT
developers with a requirement that at the same time provides them with
the flexibility to develop and implement successful real world testing
plans that will best balance burden and value for the customers of each
of their products. The ONC-ACBs will be responsible for assessing real
world testing plans and results reports for completeness in comparison
to what Sec. 171.405(b)(1) requires the plan and results reports to
include or address, but will otherwise not be formally evaluating the
testing approach for quality as a testing approach. We note for clarity
that while ONC-ACB's will not be judging a developer's real world
testing approaches as planned or as executed, the contents of a
developer's publicly available real world testing results could be used
by an ONC-ACB as part of its ongoing surveillance of certified health
IT. Additionally, we have finalized our proposed requirement in Sec.
170.405(a) and (b) that requires developers subject to the real world
testing Condition and Maintenance of Certification requirements (see
Sec. 170.405(b)(2)(i)) who discover in the course of their real world
testing any non-conformities with the standards, functionalities, or
other requirements of any certification criterion under the Program, to
address these non-conformities in order for their Health IT Modules to
remain certified. This requirement will apply in the same manner to
Health IT Modules certified under the SVAP flexibility in Sec.
170.405(b)(8) or (9) as to Health IT Modules not certified under the
SVAP flexibility. Thus, developers who discover non-conformity to any
Program requirement(s) will be required to report those non-
conformities to their ONC-ACB(s). In order to provide a clear threshold
for determining whether a developer has acted on this requirement in a
timely manner, we have finalized the requirement to report non-
conformities within 30 days of discovering them (see Sec.
170.405(b)(2)(i)). We believe 30 days is an appropriate timeframe to
allow developers the opportunity to gather all facts and report to
their ONC-ACBs the details and nature of the non-conformity.
Furthermore, we believe more than the 30 days would extend beyond the
timeframe by which a non-conformity should be investigated by an ONC-
ACB and corrective action implemented, if necessary.
We are aware that by choosing not to specify particular methods,
tools, or checklists of activities that must be included in real world
testing, and providing instead extensive flexibility for developers to
select tools and design overall methodologies based on their knowledge
of their products and customers, we are asking developers to apply
innovation and problem solving skills to their real world testing. We
believe that the alternative of developing a catalog of detailed
specifications and checklists, as some commenters suggested, would be
undesirably complex, less supportive of ongoing innovation in the
market, and not ultimately less burdensome for developers or their
customers. As we have noted in the context of prior Program rulemaking
actions, we often make additional information resources and non-binding
guidance regarding real world testing available through familiar
communications channels, such as the HealthIT.gov website.
Comments. Several commenters expressed concerns about the burden of
real world testing in specific reference to ONC-ACB processes for in-
the-field surveillance of certified products' continued conformance to
applicable certification criteria. Some comments raised concerns about
the burden that could be placed on developers' customers should
developers choose to rely heavily on the procedures used by ONC-ACBs
for randomized or reactive in-the-field surveillance. Some comments
indicated concern that ONC would expect, encourage, or view more
favorably real world testing approaches that rely heavily or
exclusively on use of ONC-ACB in-the-field surveillance protocols.
Response. In the Proposed Rule, we stated that ``developers may
consider working with an ONC-ACB and have the ONC-ACB oversee the
execution of the health IT developer's real world testing plans, which
could include in-the-field surveillance per Sec. 170.556, as an
acceptable approach to meet the requirements of the real world testing
Condition of Certification'' requirement (84 FR 7497). Having
considered all comments received, we have decided not to finalize the
flexibility for developers to use ONC-ACBs' in-the-field surveillance
as part of the developer's real world testing plan. We do not believe
that use or replication of methods or protocols used by ONC-ACBs for
in-the-field surveillance of certified Health IT Modules would be the
most effective or the least burdensome approach available to health IT
developers and are concerned accepting real world testing approaches
that rely on ONC-ACB in-the-field surveillance could slow rather than
accelerate development of more innovative approaches to real world
testing. We are also concerned that inclusion of ONC-ACB execution of
in-the-field surveillance within a developer's real world testing
approach could lead to confusion as to whether the organization that is
an ONC-ACB was applying in-the-field surveillance protocols in its
capacity as an ONC-ACB as part of its oversight responsibilities on
behalf of ONC or in its private capacity on behalf of the health IT
developer. We believe it is important, to protect HIPAA covered health
care providers and other HIPAA covered entities and their business
associates from inadvertently violating requirements related to
disclosure of health information, to maintain a clear distinction of
when an organization that is an ONC-ACB is acting in the ONC-ACB
capacity and when it is acting in its private capacity. We note and
emphasize this because, in the event a developer may choose to engage
services in support of developing or implementing the developer's real
world testing plans from an organization or entity that also happens to
be an ONC-ACB, all activities undertaken by the organization or entity
to develop, execute, or support the development or execution of the
developer's real world testing plan would be activities outside the
ONC-ACB role. In such circumstances, the organization that is an ONC-
ACB would be acting in a separate, private capacity. Note that an
organization providing such private services that involve ePHI would
likely be characterized under the HIPAA Rules as a business associate
to the health care provider and subject to the HIPAA Rules. The
oversight authorities attached to its ONC-ACB role would not apply to
the organization's requests to gain access to health care provider
facilities or to EHI for purposes of providing these separate support
services to health IT developers for conduct of the developers' real
world testing.
[[Page 25771]]
Comments. Several commenters sought confirmation that a test server
could be used for real world testing instead of a production
environment, given the permissible use of synthetic data.
Response. After considering the totality of comments received, we
have decided to finalize that a test server could be used for real
world testing and provide the flexibility included in the Proposed Rule
that allows for real world testing to occur in a production setting
using real patient data in accordance with applicable laws as well as
in an environment that mirrors a specific production environment used
in a type of clinical setting for which the health IT is marketed. We
have also decided to finalize the flexibility for the developer to use
synthetic patient data in lieu of or in addition to real patient data
in real or simulated/test scenarios executed in environments that
mirror production environments where the health IT is deployed.
However, we emphasize that the purpose of real world testing is to
demonstrate that the Health IT Module(s) work as expected in real-life
clinical settings. We note, as a point of potential interest for such
consideration, that real world testing plans that meet the Program
requirement might include observation or measurement of the health IT's
interoperability performance while actual scenarios and use cases are
executed by end users on real patient data in actual operational
contexts. If a developer chooses to use synthetic data, non-production
(mirrored) environments, or a combination of real and synthetic data or
production and mirrored environments, to complete any portion of their
annual real world testing requirements, the developer must include in
their real world testing plan and results submissions a specific
explanation justifying how the synthetic data, mirrored environment, or
both are appropriate and adequate to meet the real world testing
requirement(s) for which they will be or were used.
Comments. Several commenters sought confirmation that a product
serving multiple care settings could complete a single test relevant to
all settings and ask ONC to provide a list of eligible care settings
for reference.
Response. The finalized real world testing Condition and
Maintenance of Certification requirements include testing each
criterion listed in Sec. 170.405(a) to which any Health IT Module(s)
within the product are certified, and testing in each type of setting
to which it is marketed. To satisfy these Condition and Maintenance of
Certification requirements as finalized, a single testing plan,
protocol, or approach must address all the types of settings to which
the product, with all its included Health IT Module(s), is marketed and
do so with traceability to each Health IT Module of its real world
performance in each type of setting for which it is marketed. We
believe it is possible to construct a real world use scenario or use
case that tests more than one type of setting applicable to the Health
IT Module, and confirm that a developer is not required to develop
unnecessarily or artificially separate scenarios or use cases across
multiple types of settings to which a given developer markets its
applicable Health IT Module(s). With respect to the types of settings
required to be addressed by a given developer's plan, we do not believe
that additional specification is necessary because we believe each
developer is well situated to know for what types of settings the
developer (or its authorized resellers) has marketed, is marketing, or
intends to market its Health IT Modules. For purposes of this Condition
and Maintenance of Certification requirement as finalized, there is no
exclusion for settings or health care provider types based on their
inclusion or lack of inclusion in, or eligibility or ineligibility for,
and particular Federal health care program or initiative. Therefore,
the types of settings eligible to be addressed in a developer's real
world testing plan for a given year include all those to which
product(s) including one or more Health IT Modules certified to one or
more of the criteria listed at Sec. 170.405(a) as of August 31 of the
year in which that specific annual real world testing plan is due have
been or are marketed when the real world testing plan is submitted,
and/or the types of settings for which the developer anticipates
marketing such product(s) in time to include them in a specific year's
real world testing activities.
Comments. Several commenters requested ONC ensure that real world
testing requirements do not create infrastructure for testing of public
health transactions without public health involvement. Several
commenters noted that public health organizations and many public
health agencies already offer resources and processes used in
onboarding processes for public health reporting connections and
suggested these resources and processes could be used more broadly to
test health IT's real world performance on public health
interoperability criteria rather than requiring creation of new or
different tools.
Response. We would tend to agree that relying for specific use
cases on testing infrastructures developed without appropriate
involvement of key participants in the use case would not be an optimal
approach. Also, we reiterate that we encourage developers to consider a
variety of options and approaches before finalizing their annual real
world testing plans. We would encourage developers to consider the real
world testing potential of resources, tooling, and infrastructure
already offered by public health organizations and agencies before
embarking on efforts to develop additional tooling. We also note that,
for the interoperability-focused public health criteria, alternatives
that would avoid both overuse of simulation environments and asking
public health agencies to engage in work unique to developers' real
world testing plans might include structured observation and
measurement of interoperability performance in actual public health
data reporting/exchange as well as the testing ordinarily conducted for
onboarding/confirming connectivity of newly deployed/upgraded
implementations to public health data exchange infrastructures.
Comments. A number of commenters expressed support of requiring the
use of metrics/measurements for real world testing. One commenter
stated that ONC should not allow just one measurement to suffice for
real world testing of interoperability of a Health IT Module. Several
commenters recommended ONC include a description of ``measurement,''
provide clarity on the role of measurement, and provide a ``sample'' or
suggested set of metrics/measurements to help foster alignment of
reporting around meaningful common metrics/measurements across
developers. Some commenters recommended ONC identify a core set of
metrics/measures that developers would be required to include, or from
which developers would be required to select specific metrics/measures
to include, in their real world testing plans. Other commenters
advocated against developers being required to submit testing results
for a minimum ``core'' set of general metrics, providing the rationale
that not all metrics will be available to all systems uniformly and
suggesting that many metrics are retained in the provider's locally
integrated production systems and unavailable to the developer of any
given Module(s) without considerable effort to retrieve the data. One
commenter recommended requiring that each developer's real world test
plan include measures addressing all of the domains of the NQF report:
[[Page 25772]]
Measurement Framework to Assess Nationwide Progress Related to
Interoperable Health Information Exchange to Support the National
Quality Strategy.\110\
---------------------------------------------------------------------------
\110\ https://www.qualityforum.org/Projects/i-m/Interoperability_2016-2017/Key_Informant_Summary_Report.aspx (last
accessed 12/17/2019).
---------------------------------------------------------------------------
Response. The comments on real world testing did not show clear,
widespread support for any specific subset of available metrics as a
``core'' set or catalog that a significant portion of the affected
communities (health IT developers, health care providers, and public
health agencies) would generally agree should be consistently used
across all developers' real world testing plans. Thus, we have
finalized the real world testing plan requirements (see Sec.
170.405(b)(1)(iii) and real world testing results reporting
requirements (see Sec. 170.405(b)(2)(ii)) without identifying a
minimum set of measures that must be used or a catalog of suggested
measures from which a developer would be expected to choose in
constructing its real world testing plans. We reiterate that each
developer must choose a measurement approach, including at least one
measurement/metric per applicable criterion, for use in each year's
real world testing and explain the selection and relevance of its
selected measures/metrics within its justification for its real world
testing approach in that year's plan and results report.
Comments. Comments were received on the frequency and timing of
real world testing. One commenter stated the policy should not require
annual testing if the capability certified for a given criterion
remains unchanged year to year, offering the example that if a Health
IT Module is certified for both Sec. 170.315(b)(1) and (b)(2) and the
developer is planning to release material updates to the capabilities
specific to Sec. 170.315(b)(1), but not make any material changes
specific to the Module's certification to Sec. 170.315(b)(2), this
commenter would prefer that the Health IT Module would need to submit a
testing plan and subsequent results addressing only the Sec.
170.315(b)(1) criterion for the year the change is made. Another
commenter expressed skepticism regarding the value of annual real world
testing requirements, expressing a preference for an approach that
developers would, after an initial cycle of post-certification real
world testing of a Health IT Module, be required to re-test only when
updating to National Coordinator-approved newer versions of adopted
standards included in applicable criteria or when making major
functional updates to the certified Health IT Module. One commenter who
was overall not supportive of the real world testing requirement stated
that developers would need a two-year cycle instead of a one-year cycle
in order to adequately demonstrate compliance with full functionality
testing. One commenter specifically expressed support for the annual
frequency and timing of required real world testing results reporting.
Response. We thank the commenters for their feedback regarding the
frequency and timing of real world testing. We have finalized the
requirement for annual testing in Sec. 170.405(b)(1). Ongoing annual
testing is needed to ensure that Health IT Module(s) continue to
perform as intended in the types of settings where patients and health
care providers continue to rely on it to meet their interoperability
needs.
Comments. Several commenters expressed support of the proposed real
world testing plan requirements and requested we strengthen this
provision to require that developers test their products within each
clinical specialty to which the technology would be marketed. One
commenter requested that we define with more particularity what is
expected of developers during the testing to account for the differing
conditions under which Health IT Modules are deployed, and how for
example, the system works particular conditions like server
degradation. Several other commenters suggested we provide a
standardized template for use in developing test plans. Commenters
described a template would include all required testing elements and
promote greater consistency in the way the test plans are written by
the various developers.
Response. For reasons stated in the Proposed Rule (84 FR 7496) and
above, we do not believe a centrally developed or standardized approach
for real world testing plans is the most appropriate solution at this
time. By centrally mandating or endorsing a single template in the
interest of consistently formatted documentation, we are concerned that
we might inadvertently discourage innovation in both testing approaches
and their communication to the customer community. What the plan must
include or address for each applicable criterion to which the
developer's Health IT Module(s) are certified is outlined in Sec.
170.405(b)(1)(iii), as finalized by this rule. We believe the plan
requirements finalized in the plan requirements in Sec. 170.405(b) are
specific enough to ensure the plans can be completed by developers and
effectively reviewed for completeness by ONC-ACBs, and that both the
substance and clarity or efficacy of presentation can both be examined
and considered by any interested parties--from health care providers to
informatics and interoperability researchers. Because individual
circumstances and needs may vary even within the same type of setting
or clinician specialty, it would be not be possible at this time to
define a real world testing regime that eliminated all of the
variability developers may have in implementing their real world
testing plans.
Comments. One commenter sought clarification on the total minimum
number of metrics required for a developer's real world testing plan to
be considered complete and in compliance with the requirement.
Response. A developer's real world testing plan must include at
least one metric for each applicable certification criteria. To ensure
that we are providing clear guidance, we offer the following
illustrative example: A developer with one Health IT Module that is
certified to five criteria would need to include in its real world
testing plan at least one specific measurement/metric associated with
the real world testing for each of those five criteria. Depending on
the specific criteria and the developer's real world testing approach,
this could call for up to five different measurements/metrics, or could
be addressed with fewer different measurements/metrics but a specific
measurement/metric would need to be identified/attributed within the
plan to each of the applicable certification criteria.
Comments. A few commenters stated concerns regarding our mandatory
focus on scenario- and use case-focused testing. One commenter
expressed a view that this would be expensive and time consuming,
stating that this expense limits scenario- and use case-focused testing
in the number of settings that can realistically be tested in any given
year. One commenter noted that as more settings are tested, fewer
scenarios can be run per setting. Two commenters sought more
information on the mandatory scenario- and use case-focused testing
that will be required, recommending that Health Information Service
Providers (HISPs) be able to attest to the relevant use cases and
provide the proper evidence of testing associated to those scenarios.
Response. In light of comments received, we can see how our use of
terms that are also used in the context of ONC-ATL laboratory or ONC-
ACB surveillance testing, and our reference in one instance to in-the-
field
[[Page 25773]]
surveillance, could have led to an inference that our use of these
terms implied we would expect to see the same or similar testing
protocols used in real world testing. However, we did not propose that
real world testing would require developers to set up and execute
artificial scenarios or activities solely for purposes of testing. In
fact, we do not encourage use of the laboratory testing or ONC-ACB in-
the-field surveillance protocols to conduct real world testing, as
those particular test methods, tools, and surveillance protocols were
not designed and should not be relied upon for real world testing. The
testing methods/methodologies need to address realistic scenarios, use
cases, and workflows associated with interoperability, and we do expect
developers to consider such factors as the size of the organization
that production systems support, the type of organization and setting,
the number of patient records and users, system components and
integrations, and the volume and types of data exchange in planning for
real world testing.
Comments. One commenter expressed agreement that the developer is
best situated to determine the most effective real world testing plan
for their products. One commenter requested developers be allowed to
work together with their customers to define what real world tests are.
Response. The requirements we proposed and finalized provide
developers the opportunity to identify, potentially in partnership with
their customers, the real-life scenarios, use cases, and work flows
applicable to the customer's day-to-day use of the Health IT Module(s)
to meet their interoperability needs in their production environments.
d. Submission Dates
We proposed that a health IT developer must submit an annual real
world testing plan to its ONC-ACB via a publicly accessible hyperlink
for availability to ONC and the public no later than December 15, of
each calendar year, and that the plan must address all of its Health IT
Modules certified to the 2015 Edition certification criteria listed in
proposed in Sec. 170.405(a) and (84 FR 7496). We proposed requiring
that prior to submission to the ONC-ACB, the plan will need to be
approved by a health IT developer authorized representative capable of
binding the health IT developer for execution of the plan and include
the representative's contact information. We proposed that the plan due
in any given year will need to include all health IT certified to the
2015 Edition through August 31 of that year (in other words, the August
31 that immediately preceded the December 15 due date).
We further proposed that a health IT developer would submit annual
real world testing results to their ONC-ACBs via a publicly accessible
hyperlink no later than January 31 of each calendar year for the real
world testing conducted in the preceding calendar year (84 FR 7497). We
proposed that real world testing results for each certification
criterion listed in Sec. 170.405(a) would be required to address the
elements required in the previous year's testing plan, describe the
outcomes of real world testing with any challenges encountered, and
provide at least one measurement or metric associated with the real
world testing.
Comments. Some commenters expressed concerns that the annual real
world testing plan due date falls in December, noting that in addition
to multiple holidays widely celebrated in the U.S., December can be a
busy time for many health IT developers due to various year-end
requirements and necessary preparations to support customers' quality
measurement data submissions for CMS programs.
Response. We understand the commenters' concern that the proposed
real world testing plan publication due date falls in the preparatory
run-up to year-end deadlines, including for many developers completing
preparations to support their customers' successful clinical quality
measurement data submission during CMS program windows that typically
open on the first Federal business day in January. In consideration of
comments received, we have made edits to the phrasing of the CFR text
in Sec. 170.405(b) to convey with more precise clarity that under the
policy we have finalized, the developer is required to submit its real
world testing plans so that the ONC-ACB can conduct its completeness
review and publish the plan hyperlink on CHPL no later than December 15
of each year. This allows for the ONC-ACB and developer to identify and
agree on the date by which the developer will actually submit its plan
to the ONC-ACB, which could be well in advance of December. One
practical implication of the single-deadline feature of the policy as
proposed is that in order for the plans to be submitted to ONC and made
publicly available by the single deadline, the ONC-ACB's requirement to
review plans for completeness per Program requirements will in many
cases mean that the ONC-ACB will need the developer to submit the plan
to the ONC-ACB in advance of the single deadline. We have finalized the
December 15 due date for real world testing plan publication on CHPL as
proposed. We have also made clarifying edits to the finalized
regulation text (see Sec. 170.405(b)(1)) in comparison to the proposed
text to more explicitly recognize the practical implication that the
developers' and ONC-ACBs' responsibility for a single publication date
for the plans means that the plan must be submitted by the developer to
the ONC-ACB on a date agreed between them that allows for publication
by the deadline. We encourage developers and ONC-ACBs to consider
allowing at least one calendar month so that the December 15 due date
for ONC-ACBs' publication of real world testing plans will be
consistently met. We also note that nothing in Sec. 170.405 as
finalized precludes a developer and ONC-ACB from agreeing on the
developer submitting its annual real world testing plan to the ONC-ACB
more than one month prior to December 15. We have finalized the single
plan publication deadline as proposed.
We did not receive comments specific to August 31 as the annual
date when a Health IT Module must be certified by in order to be
required to be included in the real world testing plan due that year.
We have finalized this aspect of our policy as proposed in Sec.
170.405(b)(1)(ii). Thus, developers can submit their real world testing
plans as early as September 1 and on a rolling basis thereafter for
products in scope for the following year, which also addresses
commenter concerns.
We did not receive comments specific to this point, but have
removed from Sec. 170.405(b) as finalized the language that would have
specifically required the initial submission of the plan to the ONC-ACB
by the developer must be by a publicly accessible hyperlink. While this
remains an option, and could be the most efficient one for developers
and ONC-ACBs in many instances, we believe this is an unnecessarily
limiting specification of the manner of interaction between developers
and ONC-ACBs in these instances. The URL or hyperlink in CHPL will not
be published on CHPL until the ONC-ACB takes action to publish it, and
the ONC-ACB is required to review the plan and ensure it is complete
before publishing the plan link on CHPL.
Comments. We received some comments that appeared to construe our
intent to be that real world testing for all Health IT Modules
certified as of August 31 of a given year would need to be planned,
conducted, and reported within five months of that date. Comments that
appeared to be based on this interpretation also expressed
[[Page 25774]]
concern that this would be too much to accomplish on such an annual
schedule.
Response. We proposed that each developer's annual real world
testing plan required to be published by December 15 of a given year
would need to address all of the developer's Health IT Modules
certified to criteria listed in Sec. 170.405(a) as of August 31 of
that year (84 FR 7496). We also proposed that this annual real world
testing plan would pertain to real world testing activities to be
conducted in the year following the December 15 plan publication due
date. In light of comments received, we can see how we might have been
more precise in how we stated that the annual results report would be
due early in the year following the year in which the testing it
reported was conducted. The full cycle of real world testing for a
given year was never specifically proposed to be contained within a
single year, considering that the plan is due in the year prior and the
results report was proposed to be due in the year following the one in
which a given annual round of real world testing activity occurs.
Comments. Comments raised concerns that the January 31 publication
deadline might not leave enough time for developers who do not or
cannot complete their annual testing activities until late in the
testing year to submit their results reports, and ONC-ACBs complete
their required reviews, prior to the publication deadline. One
commenter raised a specific concern that the proposed January 31 due
date for real world testing results falls in the submission window for
several CMS programs for which developers' customers need to submit
their clinical quality measurement data for the preceding year. One
commenter recommended leveraging the existing quarterly update
attestation process and asking developers to conduct real world testing
on those items identified as major changes.
Response. As with the plan due date, the practical implication of
this proposal is that each developer will need to submit their results
reports to their ONC-ACB sufficiently in advance of the due date for
publication for the ONC-ACB to be able to complete its pre-publication
responsibilities for all of the results reports and still publish no
later than that due date. In theory, this means that in some cases
developers could complete their real world testing relatively early in
a given testing year and submit their results report for that year
before the CMS submission window for that year's measurement data even
opens for the developer's customers. However, considering the comments
received, we do recognize it is possible developers may for various
reasons not be able to complete their annual real world testing
activities until fairly late in any given testing (calendar) year. We
also recognize that the data submission window for CMS programs can be
a busy time for developers, and would not wish to disadvantage newer or
smaller developers who may not have separate resources available to
finalize a report of real world testing not concluded until late in the
testing year while simultaneously supporting customers' data
submissions. In light of these comments, we have decided to finalize a
deadline for publication on the CHPL of the publicly accessible
hyperlink to developers' report of real world testing conducted in the
prior year at March 15 of each year (see Sec. 170.405(b)(2)(ii)). This
finalized date gives an additional six weeks for finalization and
submission by developers compared to the date originally proposed. It
also implements a single deadline, to which the developers and ONC-ACBs
are mutually accountable, in parallel to the annual real world testing
plan submission requirement in Sec. 170.405(b)(1). We believe this
strikes an appropriate balance between timely availability of annual
real world testing results and recognition that some developers may
need to devote a substantial amount of focus to the CMS quality
measures data submission windows at the beginning of each year.
Although we have opted not to mandate developers submit their results
reports to their ONC-ACBs by a date providing a minimum required lead
time for ONC-ACBs' required review of the report, we would suggest that
ONC-ACBs and developers consider the potential merits of allowing at
least one calendar month between the developer's initial submission of
their real world testing results report to the ONC-ACB and the March 15
publication deadline.
e. Real World Testing Pilot Year
We acknowledged in the Proposed Rule that a subsequent final rule
for that may not provide sufficient time for health IT developers to
develop and submit plans for a full year of real world testing in 2020
(84 FR 7497). Therefore, we indicated in the Proposed Rule that we
expected to provide an appropriate period of time for developers to
submit their plans, and potentially treat 2020 as a ``pilot'' year for
real world testing. We expected that the pilot testing of real world
testing would match up to the fullest extent practicable with our
proposed real world testing requirements (e.g., same criteria but for a
shorter duration and without the same consequences for noncompliance).
We welcomed comments on this potential approach.
Comments. The majority of comments specifically addressing this
point were in support of 2020 being treated as a pilot year. One
commenter agreed that deferring the implementation or constructing a
pilot year for the Program would be appropriate and stated their belief
that 2020 may be too early even to conduct a pilot.
Response. We thank commenters for their thoughts on potential
piloting of real world testing and the timing of initiating real world
testing requirements. In consideration of the timing of the final rule,
we have decided not to finalize 2020 as a pilot year since developers
will now have the majority of calendar year 2020 to develop a
prospective plan for real world testing that would begin in 2021.
However, we recognize that this first ``performance'' year of real
world testing in 2021 presents unique challenges with respect to the
development of initial plans, and we fully intend to approach both the
submission of initial plans and submission of retrospective testing
results for those plans (i.e., 2021 real world testing results) as
learning experiences for developers that can be used to inform future
iterations of real world test plans. As noted in the proposed rule (84
FR 7497), the due date for the first annual real world testing plan
would be finalized based in part on the timing of the final rule.
Because this final rule is publishing well in advance of the December
15 annual due date for publication of developers' plans of real world
testing activities to be conducted in the following year, we have
concluded it is reasonable to require the first annual real world
testing plan be published via a publicly accessible hyperlink on the
CHPL no later than December 15, 2020. This initial real world testing
plan must address any and all of the developer's Health IT Modules that
hold a current, valid certificate under the Program as of August 31,
2020. The real world testing plan due to be published in December 2020,
will need to address the real world testing activities that will occur
during calendar year 2021. The report of results for this initial
(2021) annual real world test cycle will be due to be published on the
CHPL no later than March 15, 2022.
f. Health IT Modules Certified But Not Yet Deployed
We proposed (84 FR 7497) that even if a health IT developer does
not have customers or has not deployed their
[[Page 25775]]
certified Health IT Module(s) at the time the real world testing plan
is due, the health IT developer would still need to submit a plan that
prospectively addresses its plans for real world testing that would
occur in the coming year for those Health IT Modules that had been
certified on or before August 31 of the calendar year in which the plan
is due (the calendar year immediately preceding the calendar year
during which testing addressed by any given annual real world testing
plan will take place). If a health IT developer has not yet deployed
their certified Health IT Module to any real world users when the
annual real world testing results are due for that module, we proposed
that the developer would need to report as such to meet the proposed
Maintenance of Certification requirement.
Comments. We received no comments on this proposal.
Response. We have finalized this proposal. Any Health IT Module
certified to at least one criterion within the scope of real world
testing as of August 31 of a given year must be addressed by its
developer's real world testing plan for the subsequent year that must
be published via publicly accessible hyperlink on the CHPL by the
December 15 due date (see Sec. 170.405(a)). This requirement applies
regardless of whether that Health IT Module is in actual real world use
prior to December 15 (or the earlier date by which the developer and
ONC-ACB agree the developer will submit its annual real world testing
plan to the ONC-ACB to ensure the developer and ONC-ACB meet single,
December 15, deadline for the plan to have been reviewed for
completeness and published on CHPL). To ensure precise clarity about
the effect of the August 31 reference date for purposes of real world
testing requirements, we reiterate that if a developer has at least one
Health IT Module certified to at least any one criterion within the
real world testing scope of applicability as of August 31 of a given
year, the real world testing Condition and Maintenance of Certification
requirements apply to that developer and the developer must submit an
annual real world testing plan for that year, addressing each of their
Health IT Module(s) certified to any (one or more) criteria listed in
Sec. 170.405(a) and that plan must meet the requirements in Sec.
170.405(b)(1)(iii) for each module and criterion. Only developers who
have no Health IT Module(s) certified to any criterion within the real
world testing scope of applicability as of August 31 of a given year
need not submit a real world testing plan that year and would not be
required to perform real world testing in the subsequent year.
g. Standards Version Advancement Process (SVAP)
As discussed in the Proposed Rule (84 FR 7497), as newer versions
\111\ become available for adopted standards and implementation
specifications included in the certification criteria subject to the
real world testing Condition and Maintenance of Certification
requirements, we believe that a health IT developer's ability to
conduct ongoing maintenance on its certified Health IT Module(s) to
incorporate these newer versions of Secretary-adopted standards and
implementation specifications (``standards'') is essential to support
interoperability in the real world. Updated versions of standards
reflect insights gained from real-world implementation and use. They
also reflect industry stakeholders' interests to improve the capacity,
capability, and clarity of such standards to meet new, innovative
business needs, which earlier standards versions cannot support.
Therefore, as part of the real world testing Condition of
Certification, we proposed a Maintenance of Certification flexibility
that we refer to as the Standards Version Advancement Process
(SVAP).\112\ This flexibility would permit health IT developers to
voluntarily use in their certified Health IT Modules newer versions of
adopted standards so long as certain conditions are met. As we stated
in the Proposed Rule, these conditions are not limited to but notably
include successful real world testing of the Health IT Module using the
new version(s) subsequent to the inclusion of these newer standards and
implementation specification versions in the Health IT Module's
certification. We proposed to establish the SVAP not only to meet the
Cures Act's goals for interoperability, but also in response to the
continuous stakeholder feedback that ONC has received through prior
rulemakings and engagements, which requested that ONC establish a
predictable and timely approach within the Program to keep pace with
the industry's standards development efforts.
---------------------------------------------------------------------------
\111\ We note that standards developing organizations and
consensus standards bodies use various nomenclature, such as
``versions'' or ``releases,'' to identify updates to standards and
implementation specifications.
\112\ Regulation text implementing the real world testing
Condition and Maintenance of Certification requirement was proposed
in Sec. 170.405, including but not limited to SVAP-specific
provisions proposed in Sec. 170.405(b)(5). The SVAP-specific
provisions have now been finalized in Sec. 170.405(b)(8) and (9)
(see section VII.B.5.g of this final rule).
---------------------------------------------------------------------------
The SVAP we proposed, with corresponding proposed revisions for
Sec. Sec. 170.500 and 170.555, introduces two types of administrative
flexibility for health IT developers participating in the Program (84
FR 7498). First, for those health IT developers with existing certified
Health IT Module(s), such Health IT Modules could be upgraded to a new
version of an adopted standard within the scope of the certification
and have support for that updated version of the standard reflected on
the Health IT Module's certificate so long as: Such version was
approved by the National Coordinator for use in the Program; and the
developer satisfied all requirements of the SVAP including
demonstration of conformance through an acceptable means (84 FR 7498
through 7500). For purposes of the SVAP as applied to updates to Health
IT Modules with certificates to criteria listed in Sec. 170.405(a)
that include prior version(s) \113\ of the standards, acceptable means
of demonstrating conformance include but are not necessarily limited to
self-declaration of conformance, as proposed in 84 FR 7499 and
finalized in this final rule. Second, for those health IT developers
presenting health IT for certification to a criterion listed in Sec.
170.405(a), a National Coordinator-approved newer version of a standard
included in one of these criteria could be used in lieu of or in
addition to the version of that standard incorporated by reference in
Sec. 170.299 (84 FR 7498). However, for purposes of the SVAP as
applied to health IT that is presented for certification to any
criterion listed in Sec. 170.405(a), developer self-declaration is an
acceptable means of demonstrating conformance only where there is not
yet another conformance method available that can be validly used for
that version of that standard (84 FR 7499 through 7500). The regulation
text codifying requirements for health IT developers to avail
themselves of each of the proposed types of administrative flexibility
was proposed (84 FR 7595 through 7596) in Sec. 170.405(b)(5).
Corresponding revisions to Sec. 170.550 and Sec. 170.555 were
proposed in 84 FR 7598.
---------------------------------------------------------------------------
\113\ Prior versions for this purpose could include those
incorporated by reference in Sec. 170.299, National Coordinator
approved newer versions, or a mix of such versions for any or all of
the standards adopted by the Secretary in subpart B of part 170 that
are included in a given criterion.
---------------------------------------------------------------------------
We proposed that the SVAP would be available only for National
Coordinator-approved newer versions of standards and implementation
specifications (``standards'') that have already been
[[Page 25776]]
adopted into the Program by the Secretary through rulemaking in
accordance with applicable law including the Administrative Procedures
Act (5 U.S.C. 553) and sections 3001 and 3004 of the Public Health
Service Act (PHSA) (42 U.S.C. 300jj-1 and 42 U.S.C. 300jj-11) (84 FR
7498). We have finalized this aspect of the standards version
advancement flexibility as proposed. Under current law and the
finalized SVAP flexibility, a standard must be initially adopted by the
Secretary through rulemaking before the National Coordinator can
approve the use of newer updated versions of that standard in the
Program.
We also proposed that a health IT developer would be able to choose
which of the updated standards versions approved by the National
Coordinator for use in certification to include in its updated
certified Health IT Module and would be able to do so on an itemized
basis (84 FR 7499).
We stated in the Proposed Rule that we welcomed comments on any and
all aspects of our proposed SVAP as an option available to developers
through maintenance requirements as part of the real world testing
Condition and Maintenance of Certification requirements (84 FR 7500).
We also invited comments on our proposal to allow in conjunction with
this maintenance flexibility the opportunity for developers to elect to
present health IT for initial testing and certification either to more
advanced versions or to the prior adopted versions of the standards
included in regulatory text as of the date the Health IT Modules are
presented for certification.
Comments. Comments were strongly supportive of the SVAP. Several
commenters recommended the description of this process include
recognition of the fact that developers and systems might need to
maintain operational support for previously adopted versions of
standards to avoid potential adverse effects on data access, exchange,
and use.
Response. We have finalized the SVAP in Sec. 170.405(b)(8) and (9)
to provide the flexibility for which stakeholders' comments expressed
support. This flexibility includes the option for a Health IT Module to
be certified to the standards versions incorporated by reference in
Sec. 170.299 and/or one or more National Coordinator-approved updated
versions of standards included in the criteria listed in Sec.
170.405(a). Thus, once the National Coordinator has approved for use in
the Program more advanced version(s) of any standard(s) applicable to
any of the criteria listed in Sec. 170.405(a), a health IT developer
will have flexibility to choose on an itemized basis which of the
National Coordinator-approved updated standards versions they wish to
have included in their Health IT Module certification(s). Using the
SVAP flexibility does not require a developer cease supporting prior
version releases of standards referenced by applicable certification
criteria.
Comments. Several commenters expressed concerns about the effect of
an uneven pace of advanced version implementation across health IT
developers and products within and outside the Program. Several of
these commenters recommended that, as developers voluntarily seek to
support newer versions of standards and specifications through the
SVAP, they also be required to maintain support for the adopted version
of the standard listed in the Code of Federal Regulations (45 CFR part
170, subpart B) for the applicable criteria until HHS conducts
rulemaking that would require all certified health IT upgrade to the
newer version of the standard and sunset older versions of the standard
from the Program on a mandatory, coordinated timeline.
Response. We do recognize the importance of ensuring that updated
versions of standards are approved and available for use in the Program
only when such use is consistent with the Program's purposes. We do not
anticipate that the National Coordinator would approve a newer version
of a standard for use in the Program where that is inconsistent with
the Program's purposes, notably including the maintenance and
advancement of interoperability. Moreover, we believe there is
substantial value in allowing for the market to, in effect, sunset
obsolete standards versions at its own pace unless a hard cutover (or
other highly coordinated nationwide timeline for abandoning older
versions) would be necessary to sustain functional interoperability.
The SVAP flexibility simply allows for a developer to choose to work
with their ONC-ACB to obtain certification, or to modify the scope of
the of Health IT Module's certification, to reflect that the Health IT
Module as certified includes: The version of each adopted standard that
is incorporated by reference in Sec. 170.299; or a specific National
Coordinator-approved updated version of each applicable standard; or a
National Coordinator-approved updated version for each of one or more
applicable standard(s); or multiple version(s) of any one or more
adopted standard(s). Previously, developers were free to upgrade
certified Health IT Modules to support newer versions of adopted
standards, but only in addition to the version(s) of those standards
incorporated by reference in Sec. 170.299. In our experience, newer
versions render prior versions obsolete on a more rapid pace for some
standards than for others and more rapidly than the versions
incorporated by reference in regulations could be updated. Prior
feedback had indicated that being required to maintain support for the
version of a standard that is incorporated by reference in Sec.
170.299 solely for the purpose of maintaining regulatory compliance
under the Program represented a burden without commensurate value in
cases where customers' operational interoperability needs could be met
only by use of newer version(s) of particular adopted standards than
the versions listed in the regulations. The SVAP is designed to
eliminate that burden and simultaneously provide, through inclusion of
support for advanced standards versions within a Health IT Module's
certification, enhanced assurance to users that Health IT Modules
supporting National Coordinator-approved newer versions of standards
under the SVAP flexibility continue to meet all of the requirements of
the criteria to which the Health IT Module is certified.
Comments. A number of commenters requested clarification on how the
proposed Standards Version Advancement Process would align with
expansion of the USCDI, or whether the USCDI will be versioned through
the SVAP. Some commenters expressed an opinion that the USCDI expansion
process should not be executed or allowed via the SVAP and instead
require rulemaking.
Response. As discussed in section IV.B.1, we have adopted the USCDI
as a standard in Sec. 170.213 and incorporated USCDI v1 by reference
in Sec. 170.299(n)(5). For purposes of the SVAP, the USCDI will be
treated like any other standard. This means that health IT when
presented for certification to any one or more criteria referencing
Sec. 170.213 will be required to support USCDI v1 or a later version,
with SVAP providing flexibility for developers to choose whether to
support later versions of USCDI that the National Coordinator may
approve for use in the Program in lieu of or in complement to USCDI v1.
Developers and will not be required to support newer versions of the
USCDI standard instead of USCDI v1 until such time as Sec. 170.213 and
Sec. 170.299 are updated. However, developers may voluntary choose to
use the SVAP flexibility to voluntarily upgrade certified Health IT
[[Page 25777]]
Modules, or to seek certification of their health IT, to newer version
release(s) of the USCDI if such release(s) have been approved by the
National Coordinator for use under the Program. As with any other
standard relevant to the SVAP flexibility, we would anticipate that the
National Coordinator would not approve for voluntary use under the
Program an updated version of any standard that would render Health IT
Module(s) using it incapable of exchanging EHI with other technology
certified under the Program to other version(s) of the standard. We
also note that, although HHS is the steward of the USCDI standard, we
have not at this time foreclosed the possibility that we could publish
a newer update of the USCDI that the National Coordinator would not
immediately approve for developers' voluntary use under the Program via
the SVAP flexibility. We recognize a potential that expanding the USCDI
to include additional data classes in future versions could lead to
Health IT Modules certified to these more advanced versions of USCDI
being able to access, use, and exchange more data classes than Health
IT Modules certified only to earlier versions of the USCDI. However,
the technology certified to National Coordinator-approved newer
versions of the USCDI would be capable of exchanging the data classes
included in prior version(s) of the standard. Thus, the flexibility
maintains interoperability while allowing those who need additional
data classes to be fully supported by certified health IT in their
access, exchange, and use of these additional data classes and not
forcing other users of certified health IT (who do not yet need to
access, exchange, or use such additional data classes) to update their
health IT. We therefore believe that allowing for expansion of data for
which certified Health IT Modules can support interoperability at a
pace driven by the market's progress in standards development and
demand for interoperability is an important benefit of the SVAP
flexibility.
Comments. One commenter stated the SVAP would be more effective for
electronic prescribing if it could be used to allow voluntary adoption
of a new version of the NCPDP SCRIPT standard by prescribers,
pharmacies, and Part D prescription drug plans without CMS rulemaking.
Response. CMS is solely responsible for Medicare Part D program
regulations and other policies, including its required e-prescribing
standards and standards versions. In the future, the SVAP flexibility
could enable developers to have the certifications of their Health IT
Modules to e-prescribing criteria updated to reflect conformance of the
Health IT Modules to newer versions of adopted standards that might be
required by CMS Part D program or other HHS regulatory requirements
before we could update the version(s) of e-prescribing standards
incorporated by reference in Sec. 170.299. This approach would avoid
the need for CMS or ONC to go through joint rulemaking in order
maintain programmatic alignment.
h. Updating Already Certified Health IT Leveraging SVAP Flexibility
We proposed that in instances where a health IT developer has
certified a Health IT Module, including but not limited to instances
where its customers are already using the certified Health IT Module,
if the developer intends to update pursuant to the SVAP election, the
developer will be required to provide advance notice to all affected
customers and its ONC-ACB: (a) Expressing its intent to update the
software to newer versions of the standard approved by the National
Coordinator through the SVAP; (b) the developer's expectations for how
the update will affect interoperability of the affected Health IT
Module as it is used in the real world; and (c) whether the developer
intends to continue to support the certificate for the existing Health
IT Module version for some period of time and how long, or if the
existing version of the Health IT Module certified to prior version(s)
of applicable standards will be deprecated (e.g., that the developer
will stop supporting the earlier version of the module and request to
have the certificate withdrawn) (84 FR 7498). The notice would be
required to be provided sufficiently in advance of the developer
establishing its planned timeframe for implementation of the upgrade to
the more advanced standard(s) version(s) in order to offer customers
reasonable opportunity to ask questions and plan for the update. We
requested public comment on the minimum time prior to an anticipated
implementation of an updated standard or implementation specification
version update that should be considered reasonable for purposes of
allowing customers, especially health care providers using the Health
IT Module in their health care delivery operations, to adequately plan
for potential implications of the update for their operations and their
exchange relationships. We also requested comments on specific
certification criteria, standards, characteristics of the certified
Health IT Module or its implementation (such as locally hosted by the
customer using it versus software-as-a-service type of implementation),
or specific types or characteristics of customers that could affect the
minimum advance notice that should be considered reasonable across
variations in these factors (84 FR 7499).
Comments. Only a few commenters offered thoughts specifically on
the minimum time prior to an anticipated implementation of an updated
standard or implementation specification version update that should be
considered reasonable. Several of these commenters noted that different
market segments and provider types vary in their willingness or ability
to upgrade to new software versions. One comment submission indicated
two months would be a reasonable minimum time prior to implementation
of an updated standard for their customers to be notified. Another
commenter observed that the minimum timeframe prior to an anticipated
implementation of an updated standard is two to four years.
Response. The comments received comport with our prior
understanding that the minimum advance notice needed to offer customers
reasonable opportunity to ask questions and plan for the update or
modification of Health IT Modules the customers are using or have
purchased and scheduled for deployment varies across different
circumstances. We have, therefore, decided to finalize the advance
notice requirement as proposed. The regulation text for this
requirement is finalized in Sec. 170.405(b)(8)(i). Thus, a developer
choosing to take advantage of the SVAP flexibility must provide notice
to its customers sufficiently in advance of the developer's anticipated
timeframe for implementation of the update to the newer version(s) of
applicable standard(s) to offer customers reasonable opportunity to ask
questions and plan for the update. We note for clarity that we intend
to apply a reasonableness standard to evaluating adequacy of advance
notice timeframes for particular version updates in their specific
factual contexts, prioritizing the perspective of a reasonable person
in the situation of the developer's customers because this requirement
is intended to protect the interests of those customers. We would
anticipate that proactive engagement between the developers and their
customers would result in mutually agreeable timeframes and obviate the
need for us to assess reasonableness in at least the vast majority, and
ideally the totality, of instances where developers choose to use the
SVAP flexibility.
[[Page 25778]]
i. Health IT Modules Presented for Certification Leveraging SVAP
Flexibility
In instances where a health IT developer presents health IT for
certification to a criterion listed in Sec. 170.405(a) to which the
health IT is not already certified, we proposed that the health IT
developer would be permitted to use National Coordinator-approved newer
versions of any or all of the standards included in the criterion,
instead of or in combination with the versions of these standards
incorporated by reference in Sec. 170.299. In such circumstances, a
health IT developer would be able to choose which National Coordinator-
approved standard version(s) it seeks to include in a new or updated
certified Health IT Module and would be able to do so on an itemized
basis. To enable this flexibility for developers seeking certification,
we proposed to amend ONC-ACB Principles of Proper Conduct (PoPC) to
require ONC-ACBs offer certification to National Coordinator-approved
newer versions of standards and provide the ability for ONC-ACBs to
accept a developer self-declaration of conformity as to the use,
implementation, and conformance to a newer version of a standard
(including but not limited to implementation specifications) as
sufficient demonstration of conformance in circumstances where the
National Coordinator has approved a version update of a standard for
use in certification but no testing tool is yet available to test to
the newer version (84 FR 7501).
Comments. Commenters supported the proposal to allow for both
updates to existing certifications of Health IT Modules and newly
sought certifications to applicable criteria to follow a process of
self-declaration where approved test tools are not yet available to
support conformance validation of the pertinent National Coordinator-
approved newer version of a standard. A few commenters requested we
clarify how developers can demonstrate conformance when a newer version
of a standard is available for use under this process but does not yet
have testing tools available under the Program.
Response. We proposed (84 FR 7456) and have finalized modifications
in Sec. 170.523(h) to permit ONC-ACBs to certify Health IT Modules
that the ONC-ACB has evaluated for conformance with certification
criteria without first passing through an ONC-ATL. As finalized, Sec.
170.523(h)(2) provides that an ONC-ACB may certify a Health IT Module
that has been evaluated by it for compliance with a conformance method
approved by the National Coordinator. This provides flexibility for the
National Coordinator to approve a conformance method other than ONC-ATL
testing, for evaluating conformance where the National Coordinator has
approved a version update of a standard for use in certification but an
associated testing tool is not yet updated to test to the newer
version. We have also made edits to the text in Sec. 170.405(b) as
finalized in comparison to the text included in the Proposed Rule to
make more immediately clear which specific requirements apply when
developers choose to take advantage of the SVAP flexibility for
updating Health IT Modules already certified to a criterion listed in
Sec. 170.405(a) and which specific requirements apply when developers
choose to leverage the flexibility when presenting Health IT Modules
for certification to a criterion listed in Sec. 170.405(a).
Comments. Commenters recommended HHS give health IT developers'
flexibility to choose which standards to advance through this process
and not obligate them to update to all possible standards at once.
Response. In the Proposed Rule, we noted (84 FR 7497) that a health
IT developer would be able to choose which National Coordinator-
approved standard version(s) it seeks to include in a new or updated
certified Health IT Module and would be able to do so on an itemized
basis. Under the finalized SVAP flexibility in Sec. 170.405(b)(9),
health IT developers are permitted to choose to use National
Coordinator-approved version(s) or the version incorporated by
reference in Sec. 170.299 or both for any standard(s) included in
applicable criteria it seeks to use in its certified Health IT
Module(s) on an itemized, standard-by-standard basis at the developer's
discretion.
In the Proposed Rule, the regulation text for all SVAP requirements
was proposed to be codified in Sec. 170.405(b)(5). The SVAP
requirements, as finalized, are codified in Sec. 170.405(b)(8) and
(9). We decided to codify the finalized SVAP requirements in separate
paragraphs because it complements other wording changes to the
finalized regulation text that we made to make more immediately clear
on the face of the regulation which specific requirements (Sec.
170.405(b)(8)) apply when developers choose to take advantage of the
SVAP flexibility for updating Health IT Modules already certified to a
criterion listed in Sec. 170.405(a) and which specific requirements
(Sec. 170.405(b)(9)) apply when developers choose to leverage the
flexibility when presenting Health IT Modules for certification to a
criterion listed in Sec. 170.405(a).
j. Requirements Associated With All Health IT Modules Certified
Leveraging SVAP
As outlined in the Proposed Rule (84 FR 7499), in all cases,
regardless of whether a health IT developer is updating an existing
certified Health IT Module or presenting a new Health IT Module for
certification to new versions of adopted standards approved by the
National Coordinator through the Standards Version Advancement Process,
we proposed that any developer choosing to take advantage of the
proposed flexibility would need to:
Ensure its mandatory disclosures in Sec. 170.523(k)(1)
appropriately reflect its use of any National Coordinator-approved
newer versions of adopted standards; and
Address and adhere to all Program requirements--including
but not limited to Conditions of Certification and Maintenance of
Certification requirements--that are applicable to its certified Health
IT Modules regardless of whether those Health IT Modules were certified
to the adopted standards found in 45 CFR part 170 or National
Coordinator-approved newer version(s) of the adopted standard(s).
For example, as we proposed, a developer would need to ensure that
its real world testing plan and actual real world testing include the
National Coordinator-approved newer versions of standards to which it
is claiming conformance, beginning with the plan for and real world
testing conducted in the year immediately following the first year the
developer's applicable Health IT Module(s) were, as of August 31,
certified to the National Coordinator-approved newer versions of
standards.
Under the policies outlined in the Proposed Rule, developers would
be held accountable for maintaining all applicable certified Health IT
Modules in conformance with any National Coordinator-approved newer
versions of standards and implementation specifications that they
voluntarily elect to use in their certified health IT under the real
world testing Condition and Maintenance of Certification requirements
proposed in Sec. 170.405, the attestations Condition and Maintenance
of Certification requirements proposed in Sec. 170.406, and through
ONC-ACB surveillance applying to certificates that include National
Coordinator-approved updated versions as it does to those that do not.
We also included discussion indicating our intent that developers would
be accountable for correcting
[[Page 25779]]
non-conformities with certification criteria that were discovered in
real world testing of a Health IT Module certified using National
Coordinator-approved newer versions. Under the proposed policies,
prompt corrective action would be required by a developer discovering
such non-conformity through real world testing, in similar manner as a
developer would be accountable for correcting non-conformities
discovered through real world testing of Health IT Modules certified
using only the versions of Secretary-adopted standards that are
incorporated by reference in Sec. 170.299, or through other Program
means.
Comments. We did not receive specific comments on these general
requirements and details of the relationship between the proposed SVAP
and other proposed Program enhancements or existing accountability
mechanisms.
Response. We have finalized these details of our SVAP policies as
proposed.
We stated in the Proposed Rule that we anticipate providing ONC-
ACBs (and/or health IT developers) with a means to attribute
information on Health IT Modules' support for National Coordinator-
approved updated versions of standards to the listings on the CHPL for
the Health IT Modules the ONC-ACB has certified, and proposed to
require in the PoPC for ONC-ACBs that they are ultimately responsible
for this information being made publicly available on the CHPL (84 FR
7501). We requested public comment on any additional information about
updated standards versions that may be beneficial to have listed with
certified Health IT Modules on the CHPL.
Comments. One commenter recommended ONC provide a method on the ONC
CHPL for documenting the dot version/release associated with the new
standard version implementation and clarify the ONC-ACBs reporting
timeline for these types of standard version updates.
Response. We thank the commenter for the feedback, which will help
to inform our internal deliberations about future operational planning.
k. Advanced Version Approval for SVAP
The Proposed Rule (84 FR 7500) included discussion of how, after a
standard has been adopted through notice and comment rulemaking, ONC
anticipated undertaking an open and transparent process to timely
ascertain whether a more recent version of any standard or
implementation specification that the Secretary as adopted in part 170
should be approved for developers' voluntary use under the Program. We
requested commenters' input on our anticipated approach to standards
and implementation specification advanced version approval as outlined
in the Proposed Rule.
Comments. Some commenters expressed concerns that appeared to
suggest an understanding that the SVAP would be used to adopt new
standards into the Program.
Response. As stated in the Proposed Rule, the SVAP flexibility can
only be used for newer (sometimes known as ``updated'') versions of
standards and implementation specifications that the Secretary has
already adopted through notice-and-comment rulemaking.\114\
---------------------------------------------------------------------------
\114\ As also noted in the Proposed Rule, this policy considers
the substance of a standard and not whether its name or version
naming and identification track remains unchanged over time, as
standards developing organizations and processes may apply different
naming or identification methods from one version to another of the
same standards or implementation specifications. For more
information on version naming and identification tracks for
standards and implementation specifications, please see the Proposed
Rule (84 FR 7500).
---------------------------------------------------------------------------
Comments. One commenter urged that in order to be considered for
approval for voluntary use under the Program the full details of a
version of a standard should be required to be publicly available
online by the start of opportunity for public review and discussion of
the list of versions under consideration.
Response. We appreciate the feedback. Although specifics of
operational processes are outside the scope of this rule, we wish to
reassure all stakeholders that we do appreciate the value of ensuring
public dialogue around such matters as consideration of standards
versions for potential voluntary use in the program is appropriately
supported by availability of relevant information. As we operationalize
support for finalized policies including the SVAP, we plan to provide
ample public outreach and communications through channels familiar to
affected stakeholders--including but not limited to ONC's HealthIT.gov
website.
Comments. Several commenters suggested various potential features
or processes that could be used in ascertaining whether a more recent
version of any standard or implementation specification that the
Secretary as adopted in part 170 should be approved by the National
Coordinator for developers' voluntary use under the Program. We also
received several comments regarding potential uses of information from
the standards review and approval processes or the SVAP flexibility
itself to inform assessments of various aspects of the health IT
ecosystem such as the maturity and uptake of specific standards
versions.
Response. Although addressing their substance is outside the scope
of this final rule, we appreciate these responses to our call for
comments. This information will help to inform our deliberations about
future program policies and operations.
l. Real World Testing Principles of Proper Conduct for ONC-ACBs
We proposed to include a new PoPC for ONC-ACBs in Sec. 170.523(p)
that would require ONC-ACBs to review and confirm that applicable
health IT developers submit real world testing plans and results in
accordance with our proposals (84 FR 7501). The proposed requirement
was that the ONC-ACBs review the plans for completeness. Once
completeness is confirmed, we proposed that ONC-ACBs would provide the
plans to ONC and make them publicly available by December 15 of each
year (see Sec. 170.523(p)(1) and (3) in 84 FR 7598). We proposed that
for the reasons discussed above in context of developer requirements,
we have finalized (in Sec. 170.405(b)(1)) December 15 of each year as
the due date for the annual real world testing plans. We proposed in
Sec. 170.523(p)(2) that the ONC-ACB would ``review and confirm that
applicable health IT developers submit real world testing results in
accordance with Sec. 70.405(b)(2).'' And in Sec. 170.523(p)(3) we
proposed that the ONC-ACBs would be required to submit real world
testing results by April 1 of each year to ONC for public availability
(84 FR 7598).
Comments. The only comments received relevant to these PoPC
proposals were about due dates, and were summarized above in context of
the Sec. 170.405 requirements applicable to developers (see section
VII.B.5.d Submission Dates, in this final rule).
Response. We thank commenters again for their feedback on this
proposal and have finalized the PoPC (170.523(p)(1)-(3)) as proposed,
with the exception of having adjusted in Sec. 170.523(p)(3) the annual
due date for publication of developers' real world testing results
reports on CHPL from the proposed April 1 to the finalized March 15
date.
Because we proposed to allow health IT developers to implement
National Coordinator-approved newer versions of adopted standards and
implementation specifications in certified Health IT
[[Page 25780]]
Modules, we proposed two requirements to ensure the public has
knowledge and ONC-ACBs can maintain appropriate oversight and
surveillance of the version of a standard that certified health IT
meets. First, we proposed to revise the PoPCs in Sec. 170.523(m) to
add subparagraph (4) requiring ONC-ACBs to aggregate, no less than
quarterly, all updates successfully made to use newer versions of
adopted standards in certified health IT per the requirements for
developers choosing to take advantage of the SVAP flexibility. This
would ensure that ONC is aware of the version of a standard that
certified health IT meets for the purposes of Program administration.
Second, we proposed, that a developer that chooses to avail itself of
the SVAP flexibility must address its use of newer versions of adopted
standards in its real world testing plans and results.
We sought comment on the proposed additions to the PoPC for ONC-
ACBs. More specifically, we sought comment on whether ONC-ACBs should
be required to perform an evaluation beyond a completeness check for
the real world testing plans and results and the value versus the
burden of such an endeavor.
Comments. We did not receive any comments on this proposal.
Response. The substance of the requirement is finalized as
proposed, though, we have made clarifying edits to the way in which the
PoPC amendments are organized and phrased. The requirement proposed in
Sec. 170.523(m)(4) (84 FR 7599) has been re-designated in Sec.
170.523(m)(5). In the finalized Sec. 170.523(m)(5), we have revised
the citation to the SVAP requirements because they were proposed in
Sec. 170.405(b)(5) but are finalized in Sec. 170.405(b)(8) and (9).
The wording of requirement finalized in Sec. 170.523(m)(5) was
modified in comparison to that proposed in 84 FR 7599 to make clear
that ONC-ACBs are required to report on all certifications of Health IT
Modules to National Coordinator-approved newer versions of Secretary-
adopted standards, both those updated to include newer versions of
adopted standards and those of Health IT Modules first presented for
certification using newer versions of adopted standards. Another
modification to the finalized regulation text in Sec. 170.523(m)(5) in
comparison with that proposed clarifies that ONC-ACBs are permitted to
obtain the quarterly record of successful use in certified Health IT
Modules of newer versions of adopted standards from the ONC-ACB's
records of certification activity. We believe this clarification is
important to ensure the regulation text finalized in Sec.
170.523(m)(5) cannot be misconstrued as precluding use of such records
as the data source for this requirement.
In complement to the above requirements to ensure transparency for
the public and end users, we proposed in Sec. 170.523(t) a new PoPC
for ONC-ACBs requiring them to ensure that developers seeking to take
advantage of the SVAP flexibility in Sec. 170.405(b) comply with the
applicable requirements, and that the ONC-ACB both retain records of
the timing and content of developers' required \115\ notices and ensure
each notice is timely and publicly accessible, and easily located via
the CHPL through attribution of the notice to the certified Health IT
Modules to which it applies.\116\
---------------------------------------------------------------------------
\115\ The advance notice requirement that was proposed in Sec.
170.405(b)(5)(i) and that is now finalized in Sec. 170.405(b)(8)(i)
remains specific to developers leveraging SVAP flexibility to update
Health IT Modules with existing certifications.
\116\ We note for clarity that whether a copy of the content is
hosted on CHPL, made available via a publicly accessible hyperlink
provided by the developer, or another mechanism or method that may
emerge as a more advanced and efficient technical approach to
achieving this same goal is an operational detail and does not need
to be defined in rulemaking.
---------------------------------------------------------------------------
We note that in the proposed regulation text in Sec. 170.523(t) as
published in 84 FR 7598, there was an editorial error. The editorial
error was in title in Sec. 170.523(t) as published in 84 FR 7598,
which read ``Standards Voluntary Advancement Process'' instead of
``Standards Version Advancement Process,'' although the proposed
introductory text correctly referenced ``Standards Version Advancement
Process.''
Comments. We did not receive public comment on the proposed
paragraph (t) or its addition to Sec. 170.523.
Response. We have finalized Sec. 170.523(t) with a revised title
more consistent with the finalized titles of paragraphs (8) and (9) in
Sec. 170.405(b), and a revised citation to Sec. 170.405. The citation
to Sec. 170.405 was revised because the SVAP requirements 170.523(t)
references were proposed in Sec. 170.405(b)(5) but have been finalized
in Sec. 170.405(b)(8) and (9). The substance of the PoPC requirement
in Sec. 170.523(t) is finalized as proposed.
m. Health IT Module Certification & Certification to Newer Versions of
Certain Standards
We proposed to add in Sec. 170.550, Health IT Module
certification, a new paragraph (e), which would require that ONC-ACBs
must provide an option for certification of Health IT Modules to any
one or more of the criteria referenced in Sec. 170.405(a) based on
newer versions of standards included in the criteria which have been
approved by the National Coordinator for use in certification through
the Standards Version Advancement Process (84 FR 7598).
Comments. We received no public comments on this proposed addition
to Sec. 170.550 to accommodate the SVAP flexibility.
Response. We have finalized the substance of Sec. 170.550(e) as
proposed. We have modified the regulatory text finalized in Sec.
170.550(e) in comparison with that proposed in 84 FR 7598 by adding a
header. The finalized paragraph reads: ``Standards Updates. ONC-ACBs
must provide an option for certification of Health IT Modules to any
one or more of the criteria referenced in Sec. 170.405(a) based on
newer versions of standards included in the criteria which have been
approved by the National Coordinator for use in certification.''
We proposed to revise Sec. 170.555(b)(1) to accommodate the SVAP
flexibility. The revised text in Sec. 170.555(b)(1) as proposed (84 FR
7598) read: ONC-ACBs are not required to certify Complete EHRs and/or
Health IT Module(s) according to newer versions of standards adopted
and named in subpart B of this part, unless: (i) The National
Coordinator identifies a newer version through the Standards Version
Advancement Process and a health IT developer voluntarily elects to
seek certification of its health IT in accordance with Sec.
170.405(b)(5); or (ii) The new version is incorporated by reference in
Sec. 170.299.
Comments. We did not receive public comments on revising paragraph
(b)(1) of Sec. 170.555 to accommodate the SVAP flexibility.
Response. We have finalized the substance of this revision as
proposed. However, we have struck ``Complete EHRs and/or'' from the
text finalized in Sec. 170.555(b)(1) consistent with our finalizing
the removal from 45 CFR part 170 of references to ``Complete EHRs'' in
conjunction with the removal of the 2014 Edition (as discussed in
section III.B.2 of this final rule). We have clarified the text in
Sec. 170.555(b)(1) as finalized to use the word ``approves'' in place
of ``identifies,'' consistent with our phrasing and terminology
throughout the preamble of this final rule and finalized regulation
text implementing the SVAP flexibility. We have replaced ``under the
Standards Version Advancement Process'' with ``for use in
certification'' because we
[[Page 25781]]
believe this wording prevents potential confusion about whether the
term ``Standards Version Advancement Process'' refers to the
administrative flexibility established in Sec. 170.405(b)(8) and (9)
or to the National Coordinator's approach to approving versions for use
in the Program. We have also revised the citation to Sec. 170.405(b)
in the finalized text in Sec. 170.555 because the SVAP provisions
proposed in Sec. 170.405(b)(5) have been finalized in Sec.
170.405(b)(8) and (9).
6. Attestations
The Cures Act requires that a health IT developer, as a Condition
and Maintenance of Certification requirement under the Program, provide
to the Secretary an attestation to all of the Conditions of
Certification requirements specified in PHSA Sec. 3001(c)(5)(D),
except for the ``EHR reporting criteria submission'' Condition of
Certification requirement in Sec. 3001(c)(5)(D)(vii). We proposed to
implement the Cures Act by requiring health IT developers to attest, as
applicable, to compliance with the Conditions and Maintenance of
Certification requirements proposed in Sec. Sec. 170.401 through
170.405.
We proposed that, as a Maintenance of Certification requirement for
the ``attestations'' Condition of Certification requirement under Sec.
170.406(b), health IT developers would need to submit their
attestations every 6 months (i.e., semiannually). We proposed to
provide a 14-day attestation period twice a year. For health IT
developers presenting Health IT Modules for certification for the first
time under the Program, we proposed that they would be required to
submit an attestation at the time of certification and also comply with
the semiannual attestation periods. As stated in the Proposed Rule, we
would publicize and prompt developers to complete their attestation
during the required attestation periods. We also proposed to provide a
method for health IT developers to indicate their compliance,
noncompliance with, or the inapplicability of each Condition and
Maintenance of Certification requirement as it applies to all of their
health IT certified under the Program for each attestation period.
Last, we proposed to provide health IT developers the flexibility to
specify noncompliance per certified Health IT Module, if necessary. We
noted, however, that any noncompliance with the proposed Conditions and
Maintenance of Certification requirements, including the
``attestations'' Conditions and Maintenance of Certification
requirements, would be subject to ONC direct review, corrective action,
and enforcement procedures under the Program.
We welcomed comments on the proposed attestations Condition and
Maintenance of Certification requirements, including the appropriate
frequency and timing of attestations. We also welcomed comments on the
proposed responsibilities for ONC-ACBs related to the attestations of
Condition and Maintenance of Certification requirements.
Comments. We received many comments supporting the ``attestations''
Condition and Maintenance of Certification requirements. Commenters
generally agreed that health IT developers should attest that they are
complying with all the required Conditions and Maintenance of
Certification requirements. A few commenters were concerned that the
Condition of Certification requirements set up unreasonable
expectations that health IT developers attest to statements that are
subject to interpretation and are ambiguous, and that developers should
be able to articulate how their software and businesses meet the
expectations.
We also received comments suggesting ways to reduce burden for
health IT developers. Some commenters suggested less frequent
attestation periods ranging from once a year to every two years as a
means for reducing burden on health IT developers. Another commenter
suggested that we send reminders to health IT developers when an
attestation(s) needs renewal. One commenter recommended that we include
a specific deadline at the middle and end of each year for attestations
in lieu of the proposed predefined 14-day attestation window. Another
commenter recommended that attestations should only be sent
electronically as any other process of reporting (e.g., written letter)
would be onerous on all parties.
Response. We thank commenters for their support and have adopted in
Sec. 170.406 the ``attestations'' Conditions and Maintenance of
Certification requirement with revisions discussed below. These
revisions should both provide clarity for compliance and reduce burden.
Health IT developers will be attesting to the Conditions of
Certification that are statutory requirements under section 4002 of the
Cures Act. This final rule also addresses concerns of ambiguity and
interpretation by revising the Conditions and Maintenance of
Certification requirements and the information blocking provision,
which is a Condition of Certification in Sec. 170.401. We have also
revised Sec. 170.406 to provide further clarity on the applicability
of each of the Conditions and Maintenance of Certification requirements
to health IT developers for the purposes of attestation. For example,
all health IT developers under the Program would attest to the
``information blocking'' Condition of Certification requirement (Sec.
170.401), while only health IT developers that have health IT certified
to the ``API'' certification criteria (Sec. 170.315(g)(7)-(10)) would
be required to attest to the ``API'' Condition of Certification and
Maintenance requirements (Sec. 170.404). We have also revised the
``attestations'' Conditions and Maintenance of Certification
requirements in Sec. 170.406 to clearly reflect that all attestations
must be approved and submitted by an officer, employee, or other
representative the health IT developer has authorized to make a binding
attestation(s) on behalf of the health IT developer. This provides
regulatory clarity for health IT developers as to their responsibility
under the attestation provisions (Sec. 170.406).
A requirement of attestation every 6 months properly balances the
need to support enforcement actions with the attestation burden placed
on developers. In this regard, allegations of inappropriate actions and
non-compliance by health IT developers with Program requirements and
the information blocking provision can be more readily cross-referenced
against their attestations for enforcement purposes comparative to a
one-year or two-year attestation period. Based on the efficient methods
we are establishing for attestation as described below, we believe that
we have implemented this statutory requirement for health IT developers
in ways that will reduce the compliance burden for them. We also refer
readers to section VII.D of this preamble for discussion of ONC direct
review, corrective action, and enforcement procedures for the
Conditions and Maintenance of Certification requirements under the
Program.
We recognize comments expressing concerns on the potential burden
placed on health IT developers to attest semiannually. The process we
plan to implement for providing attestations should minimize burden on
health IT developers. To further minimize potential burden on health IT
developers, we have revised the proposed 14-day attestation window to
extend the window to 30 days. In other words, health IT developers will
be able to submit their attestations within a
[[Page 25782]]
designated 30-day window twice a year for purposes of compliance. To
note, in accordance with Sec. 170.406(b), the first attestation window
will begin April 1, 2021. This attestation period will cover the time
period from the effective date of the final rule through March 31,
2021. This irregular time period is due to the publication of the final
rule. Subsequently, a regular 6-month period will commence with the
attestation window for the 6-month period opening on October 1, 2021
(attesting for the period of April 1 through September 30). We have
also revised the Conditions and Maintenance of Certification
requirements to reflect that all health IT developers under the Program
would adhere to a similar semiannual attestation schedule, rather than
new health IT developers also attesting at the time of certification.
We believe this is more practical, less burdensome for health IT
developers and ONC-ACBs, and creates less confusion as to what actions
and statements a health IT developer is attesting to (i.e., for past
actions under the Program).
As stated in the Proposed Rule, we plan to implement several other
means to minimize burden. First, we plan to publicize and prompt
developers to complete their attestation during the required
attestation periods. Second, as proposed in the Proposed Rule, we will
provide a method for health IT developers to indicate their compliance,
noncompliance, or the inapplicability of each Condition and Maintenance
of Certification requirement as it applies to all or each of their
Health IT Modules certified under the Program for each attestation
period. Third, to clarify our proposal and respond to the comment
recommending electronic submission, we note ONC-ACBs have discretion to
specify the format and may choose to require electronic submission. In
addition, to support electronic submission, we will provide a web-based
form and method for health IT developers to submit attestations in an
efficient manner for ONC-ACBs' review.
ONC-ACB Responsibilities
We proposed that attestations would be submitted to ONC-ACBs and
reviewed in accordance with Sec. 170.523(q) as a means for ONC-ACBs to
monitor health IT developers for compliance with Program requirements.
ONC-ACBs would be required to share the attestations with ONC. ONC
would then make the attestations publicly available through the CHPL.
The other responsibility we proposed in Sec. 170.550(l) was that
before issuing a certification, an ONC-ACB would need to ensure that
the health IT developer of the Health IT Module has met its
responsibilities related to the Conditions and Maintenance of
Certification requirements as solely evidenced by its attestation. For
example, if a health IT developer with an active certification under
the Program provided noncompliant designations in their attestation but
was already participating in a corrective action plan (CAP) under ONC
direct review to resolve the noncompliance, certification would be able
to proceed while the issue is being resolved.
Comments. One commenter requested clarification on the specific
responsibilities of ONC-ACBs when collecting and submitting
attestations to ONC, including instances of an attestation indicating
non-conformity and the lack of a submission of an attestation by a
health IT developer.
Response. We thank commenters for their input and have finalized as
proposed. We refer readers to section VII.D for further discussion of
ONC direct review, corrective action, and enforcement procedures for
the Conditions and Maintenance of Certification requirements under the
Program, including the roles of ONC-ACBs in enforcement of the
Conditions and Maintenance of Certification requirements.
7. EHR Reporting Criteria Submission
As stated in the Proposed Rule, the Cures Act specifies that health
IT developers shall be required, as a Condition and Maintenance of
Certification requirement under the Program, to submit certain
information to satisfy the reporting criteria on certified health IT in
accordance with the EHR Reporting Program requirements established
under section 3009A of the PHSA, as added by section 4002 of the Cures
Act. We have not yet established an EHR Reporting Program. Once ONC
establishes such an EHR Reporting Program, we will undertake future
rulemaking to propose and implement the associated Condition and
Maintenance of Certification requirement(s) for health IT developers.
C. Compliance
The Maintenance of Certification requirements discussed above do
not necessarily define all the outcomes necessary to meet the
Conditions of Certification. Rather, they provide preliminary or
baseline evidence toward measuring whether a Condition of Certification
requirement is being met. Thus, ONC could determine that a Condition of
Certification requirement is not being met through reasons other than
the Maintenance of Certification requirements. For example, meeting the
Maintenance of Certification requirement that requires a health IT
developer to not establish or enforce any contract or agreement that
contravenes the Communications Condition of Certification requirement
does not excuse a health IT developer from meeting all the requirements
specified in the Communications Condition of Certification requirement.
This is analogous to clarifications ONC has previously provided about
certification criteria requirements whereby testing prior to
certification sometimes only tests a subset of the full criterion's
intended functions and scope. However, for compliance and surveillance
purposes, we have stated that ONC and its ONC-ACBs will examine whether
the certified health IT meets the full scope of the certification
criterion rather than the subset of functions it was tested against (80
FR 62709 and 62710).
Comments. We did not receive any comments specific to compliance
with Maintenance of Certification requirements as related to meeting
Conditions of Certification requirements.
Response. We continue to maintain our position that Maintenance of
Certification requirements do not define all of the outcomes necessary
to meet the Conditions of Certification requirements. Thus, while
complying with Maintenance of Certification requirements will provide
evidence toward measuring whether a Condition of Certification
requirement is being met, reasons beyond the Maintenance of
Certification requirements could result in ONC determining that a
Condition of Certification requirement has not been met.
D. Enforcement
The Cures Act affirms ONC's role in using certification to improve
health IT's capabilities for the access, use, and exchange of EHI. The
Cures Act provides this affirmation through expanded certification
authority for ONC to establish Conditions and Maintenance of
Certification requirements for health IT developers that go beyond the
certified health IT itself. The new Conditions and Maintenance of
Certification requirements in section 4002 of the Cures Act focus on
the actions and business practices of health IT developers (e.g.,
information blocking and appropriate access, use, and exchange of
electronic health information) as well as technical interoperability of
health IT (e.g., APIs and real world testing). Furthermore
[[Page 25783]]
and equally important, section 4002 of the Cures Act provides that the
Secretary of HHS may encourage compliance with the Conditions and
Maintenance of Certification requirements and take action to discourage
noncompliance. Given these considerations, we proposed a general
enforcement framework outlining a corrective action process for ONC to
review potential or known instances where a Condition or Maintenance of
Certification requirement has not been or is not being met by a health
IT developer under the Program, including the requirement for a health
IT developer to attest to meeting the Conditions and Maintenance of
Certification requirements.
1. ONC Direct Review of the Conditions and Maintenance of Certification
Requirements
Historically we utilized the processes previously established for
ONC direct review of certified health IT in the ONC Health IT
Certification Program: Enhanced Oversight and Accountability Act (EOA)
final rule (81 FR 72404), and as codified in Sec. Sec. 170.580 and
170.581, to address non-conformities with Program requirements. For
multiple reasons, we proposed in 84 FR 7503 to utilize substantially
the same processes for the enforcement of the Conditions and
Maintenance of Certification requirements. First, these processes were
designed to address non-conformities with Program requirements.
Conditions and Maintenance of Certification requirements have been
adopted as Program requirements and, as such, any noncompliance with
the Conditions and Maintenance of Certification requirements
constitutes a Program non-conformity. Second, health IT developers are
familiar with the ONC direct review provisions as they were established
by the EOA final rule in October 2016. Third, Sec. Sec. 170.580 and
170.581 have provided thorough and transparent processes for working
with health IT developers through notice and corrective action to
remedy Program non-conformities. Last, the direct review framework has
provided equitable opportunities for health IT developers to respond to
ONC actions and appeal certain ONC determinations.
As further discussed below, we have finalized our proposed approach
to utilize the processes previously established and codified in
Sec. Sec. 170.580 and 170.581 for ONC direct review of certified
health IT for the enforcement of the Conditions and Maintenance of
Certification requirements, along with our proposed revisions to these
processes in order to properly incorporate enforcement of these
requirements. We note that the Information Blocking Condition of
Certification (Sec. 170.401) and the related Assurances Condition of
Certification requirement (Sec. 170.402(a)(1)) have a delayed
enforcement date of 6 months after date of publication of the final
rule.
2. Review and Enforcement Only by ONC
We proposed in 84 FR 7503 to retain use of the term ``direct
review'' as previously adopted in the EOA final rule to continue to
distinguish actions ONC takes to directly review certified health IT or
health IT developers' actions from actions taken by an ONC-ACB to
review certified health IT under surveillance. We proposed, however,
that ONC would be the sole party responsible for enforcing compliance
with the Conditions and Maintenance of Certification requirements.
Comments. We received comments requesting clarification that ONC-
ACBs are not responsible for enforcement of the Conditions and
Maintenance of Certification requirements.
Response. We have finalized this review and enforcement approach in
Sec. Sec. 170.580(a)(1) and 170.580(a)(2)(iii) as proposed above. We
clarify that ONC-ACBs are not responsible for enforcement of the
Conditions and Maintenance of Certification requirements. Under
finalized Sec. 170.523(s), and as further discussed later in this
section, ONC-ACBs must report any information that could inform whether
ONC should exercise direct review of noncompliance with the Conditions
and Maintenance of Certification requirements to ONC. ONC-ACBs also
address non-conformities with technical and other Program requirements
through surveillance and by working with health IT developers through
corrective action plans.
3. Review Processes
As discussed above, we proposed to utilize the processes previously
established and codified in Sec. Sec. 170.580 and 170.581 for ONC's
direct review and enforcement of the Conditions and Maintenance of
Certification requirements, along with certain proposed revisions and
additions to these processes to properly incorporate enforcement of
these requirements and effectuate congressional intent conveyed through
the Cures Act.
a. Initiating Review and Health IT Developer Notice
We proposed in 84 FR 7503 to fully incorporate the review of
compliance with the Conditions and Maintenance of Certification
requirements into the provisions of Sec. 170.580(a) and (b). We
proposed in Sec. 170.580(a)(2)(iii) that if ONC has a reasonable
belief that a health IT developer has not complied with a Condition or
Maintenance of Certification requirement, then it may initiate direct
review. Similarly, we proposed in Sec. 170.580(b)(1) and (2) that ONC
may issue the health IT developer a notice of potential non-conformity
or notice of non-conformity and provide the health IT developer an
opportunity to respond with an explanation and written documentation,
including any information ONC requests.
Comments. We received one comment that ONC should communicate with
a representative sample of users of a health IT product when enforcing
the Conditions and Maintenance of Certification requirements.
Response. We appreciate this comment. We are committed to
consistent and thorough enforcement of the Conditions and Maintenance
of Certification requirements and review of complaints of
noncompliance. Our goal is to work with developers to remedy any
noncompliance in a timely manner. During the course of our review of a
potential noncompliance, we may communicate with users of the health
IT, as appropriate. We have finalized this approach regarding
initiation of review and health IT developer notice in Sec. Sec.
170.580(a)(2)(iii) and 170.580(b) as proposed.
i. Complaint Resolution
In the Proposed Rule, we noted and recommended in 84 FR 7503 that
customers and end users first work with their health IT developers to
resolve any issues of potential noncompliance with the Conditions and
Maintenance of Certification requirements. We proposed that if the
issue cannot be resolved, the end user should contact the ONC-ACB for
assessment. However, as discussed above and in section VII.D.5 below,
the ONC-ACB purview for certified health IT generally applies to
certified capabilities and limited requirements of developer business
practices. We proposed that if neither of these pathways resolves the
issue, end users may want to provide feedback to ONC via the Health IT
Feedback Form.
Comments. We received one comment recommending that we require
complaints regarding developer compliance with Conditions and
[[Page 25784]]
Maintenance of Certification requirements go directly to ONC rather
than to an ONC-ACB. Another commenter requested that we provide
guidance regarding how to report issues related to developer
compliance.
Response. We have finalized in Sec. 170.580 our proposed approach
regarding complaint resolution as described above, which is guided by
prior Program experience.
Comments. One commenter recommended that we adopt a self-disclosure
mechanism for health IT developers to report any non-conformity with
the Program and enable such self-disclosure to offer health IT
developers regulatory protection.
Response. We appreciate the comment and strongly encourage self-
disclosure by developers, which health IT developers currently do under
the Program. We note that currently there are methods by which health
IT developers may communicate with ONC-ACBs and/or ONC, and it is our
longstanding policy to work with health IT developers to correct non-
conformities. While we believe this approach works well, consistent
with Executive Order 13892, we are considering whether it would be
appropriate to adopt additional procedures that further encourage self-
reporting of non-conformities and voluntary information sharing, as
well as procedures to provide pre-enforcement rulings to health IT
developers who make inquiries regarding their compliance with
regulatory requirements.
ii. Method of Correspondence With Health IT Developers
Section 170.505 states that correspondence and communication with
ONC or the National Coordinator shall be conducted by email, unless
otherwise necessary or specified. We noted in the Proposed Rule in 84
FR 7503 that in the EOA final rule we signaled our intent to send
notices of potential non-conformity, non-conformity, suspension,
proposed termination, and termination via certified mail (81 FR 72429).
However, we proposed to follow Sec. 170.505 for correspondence
regarding direct review of noncompliance with the Conditions and
Maintenance of Certification requirements.
As discussed in the Proposed Rule, the type and extent of review by
ONC could vary significantly based on the complexity and severity of
each fact pattern. For instance, ONC may be able to address certain
noncompliance with the Conditions and Maintenance of Certification
requirements quickly and with minimal effort (e.g., failure to make
public a documentation hyperlink), while other situations may be more
complex and require additional time and effort (e.g., violation of API
fee prohibitions). Considering this wide range of potential
noncompliance with the Conditions and Maintenance of Certification
requirements, we proposed that ONC retain discretion to decide, on a
case-by-case basis, when to go beyond the provisions of Sec. 170.505
to use means other than email in providing notices and correspondence
for noncompliance with the Conditions and Maintenance of Certification
requirements.
We solicited comment on the nature and types of noncompliance with
the Conditions and Maintenance of Certification requirements that ONC
should consider in determining the method of correspondence. We also
solicited comment on whether the type of notice should determine the
method of correspondence. More specifically, we solicited comment on
whether certain types of notices under direct review should be
considered more critical than others, thus requiring a specific method
of correspondence.
Comments. We received several comments regarding the proposed
method of correspondence with health IT developers. Some commenters
stressed that time-sensitive notifications should not be sent via
email, with one commenter noting that ONC should use certified mail,
with a copy to a designated notice recipient, for notices of potential
noncompliance and noncompliance with the Conditions and Maintenance of
Certification requirements. Other commenters suggested that ONC should
use both email and certified mail for notices regarding initiation of
direct review, potential non-conformity, non-conformity, suspension,
proposed termination, and termination. One commenter recommended ONC
acknowledge receipt of communications received.
Response. We appreciate commenters' support of our proposals, as
well as the constructive suggestions. We have finalized our proposal to
use the provisions in Sec. 170.505 for correspondence regarding
noncompliance with the Conditions and Maintenance of Certification
requirements, with minor revisions. While we agree with commenters that
there may be situations when sending notice only via email would not be
adequate, such situations would be contingent on the circumstances as
described in the Proposed Rule. Therefore, we have revised the
regulation text of Sec. 170.505 to specify some of those
considerations. These considerations include, but are not limited to,
whether: The party requests use of correspondence beyond email; the
party has responded via email to our communications; we have sufficient
information from the party to ensure appropriate delivery of such
notice; and, importantly, the alleged violation of a Condition or
Maintenance of Certification requirement or other Program requirement
within ONC's purview under Sec. 170.580 indicates a serious violation
of the Program with potential consequences of suspension, certification
termination, or a certification ban.
We did not propose any requirements regarding acknowledgment of
receipt, and we have finalized our proposed approach to utilize the
processes previously established and codified in Sec. Sec. 170.580 and
170.581 for ONC direct review of certified health IT for the
enforcement of the Conditions and Maintenance of Certification
requirements, which include response requirements already codified in
Sec. Sec. 170.580 and 170.581.
Comments. One commenter requested clarification on ONC's timeframe
for responding to health IT developers during direct review. Another
commenter requested clarity on investigation timelines generally.
Response. We have finalized our proposed approach to utilize the
processes previously established and currently codified in Sec. Sec.
170.580 and 170.581 for ONC's direct review and enforcement of the
Conditions and Maintenance of Certification requirements, which include
specific response timeframes throughout the direct review process. We
refer commenters to Sec. Sec. 170.580 and 170.581 for the timeframes
applicable to the various steps in the direct review process. We also
clarify that proposed termination and suspension are excluded from
ONC's direct review process for the Conditions and Maintenance of
Certification requirements, so any timeframes related to proposed
termination and suspension do not apply.
b. Relationship With ONC-ACBs and ONC-ATLs
Section 170.580(a)(3) outlines ONC direct review in relation to the
roles of ONC-ACBs and ONC-ATLs, which we proposed to revise to
incorporate the Conditions and Maintenance of Certification
requirements. In the Proposed Rule in 84 FR 7507, we provided
situational examples in section VII.D.5 ``Effect on Existing Program
Requirements and Processes''
[[Page 25785]]
regarding ONC direct review and the role of an ONC-ACB. As finalized in
the EOA final rule and per Sec. 170.580(a)(3)(v), we stressed that ONC
may refer the applicable part of its review of certified health IT to
the relevant ONC-ACB(s) if ONC determines this would serve the
effective administration or oversight of the Program (81 FR 72427 and
72428).
We did not receive comments on this specific aspect of the proposed
rule and have finalized the relationship with ONC-ACBs and ONC-ATLs in
Sec. 170.580(a)(3) as proposed.
c. Records Access
We proposed in 84 FR 7504 to revise Sec. 170.580(b)(3) to ensure
that ONC, or third parties acting on its behalf, have access to the
information necessary to enforce the Conditions and Maintenance of
Certification requirements. As specified in Sec.
170.580(b)(1)(ii)(A)(2), (b)(2)(ii)(A)(2) and (b)(3), in response to a
notice of potential non-conformity or notice of non-conformity, ONC
must be granted access to, and have the ability to share within HHS,
with other Federal agencies, and with appropriate entities, all of a
health IT developers' records and technology related to the
development, testing, certification, implementation, maintenance, and
use of its certified health IT, and any complaint records related to
the certified health IT. ``Complaint records'' include, but are not
limited to issue logs and help desk tickets (81 FR 72431). We proposed
in 84 FR 7504 to supplement these requirements with a requirement that
a health IT developer make available to ONC, and third parties acting
on its behalf, records related to marketing and distribution,
communications, contracts, and any other information relevant to
compliance with any of the Conditions and Maintenance of Certification
requirements or other Program requirements. If ONC determined that a
health IT developer was not cooperative with the fact-finding process,
we proposed ONC would have the ability to issue a certification ban
and/or terminate a certificate (see Sec. 170.581 discussed below and
Sec. 170.580(f)(1)(iii)(A)(1)).
We proposed in 84 FR 7504 that ONC would implement appropriate
safeguards to ensure, to the extent permissible with Federal law, that
any proprietary business information or trade secrets ONC may encounter
by accessing the health IT developer's records, other information, or
technology, would be kept confidential by ONC or any third parties
working on behalf of ONC.
Comments. We received one comment recommending that ONC detail the
procedural and technical safeguards in place to protect information
submitted to ONC by a developer as part of direct review of compliance
with a Conditions or Maintenance of Certification requirement.
Response. As we stated above, in the Proposed Rule, and in the EOA
final rule (81 FR 72429), we will implement appropriate safeguards to
ensure, to the extent permissible with Federal law, that any
proprietary business information or trade secrets ONC may encounter by
accessing the health IT developer's records, other information, or
technology, will be kept confidential by ONC or any third parties
working on behalf of ONC. We have finalized in Sec. 170.580(b)(3) our
approach regarding records access as proposed. Additionally, we have
finalized our recommendation, stated in 84 FR 7504 in the Proposed Rule
and the EOA final rule, that health IT developers clearly mark, as
described in HHS Freedom of Information Act regulations at 45 CFR
5.65(c), any information they regard as trade secret or confidential
prior to disclosing the information to ONC (81 FR 72431).
d. Corrective Action
We proposed in 84 FR 7504 that if ONC determines that a health IT
developer is noncompliant with a Condition or Maintenance of
Certification requirement (i.e., a non-conformity), ONC would work with
the health IT developer to establish a corrective action plan (CAP) to
remedy the issue through the processes specified in Sec.
170.580(b)(2)(ii)(A)(4) and (c). We noted that a health IT developer
may be in noncompliance with more than one Condition or Maintenance of
Certification requirement. In such cases, we proposed that ONC would
follow the proposed compliance enforcement process for each Condition
or Maintenance of Certification requirement accordingly, but may also
require the health IT developer to address all violations in one CAP
for efficiency of process. We also proposed, as we currently do with
CAPs for certified health IT, to list health IT developers under a CAP
on ONC's website.
We did not receive any comments on this aspect of the Proposed
Rule, and in Sec. 170.580(c) we have finalized our proposals regarding
corrective action as proposed (84 FR 7504).
e. Certification Ban and Termination
We proposed in 84 FR 7504 that if a health IT developer under ONC
direct review for noncompliance with a Condition or Maintenance of
Certification requirement failed to work with ONC or was otherwise
noncompliant with the requirements of the CAP and/or CAP process, ONC
could issue a certification ban for the health IT developer (and its
subsidiaries and successors). A certification ban, as it currently does
for other matters under Sec. 170.581, would prohibit future health IT
by the health IT developer from being certified.
We proposed in 84 FR 7504 that ONC would also consider termination
of the certificate(s) of the affected Health IT Module(s) should the
health IT developer fail to work with ONC or is otherwise noncompliant
with the requirements of the CAP and/or CAP process. We proposed that
ONC may consider termination if there is a nexus between the
developer's actions or business practices in relation to the Conditions
and Maintenance of Certification requirements and the functionality of
the affected certified Health IT Module(s). For example, as discussed
in the Proposed Rule, ONC may determine that a health IT developer is
violating a Condition of Certification requirement due to a clause in
its contracts that prevents its users from sharing or discussing
technological impediments to information exchange. In this example, the
health IT developer's conduct would violate the Communications
Condition of Certification requirement that we have finalized in Sec.
170.403. If the same conduct were also found to impair the
functionality of the certified Health IT Module (such as by preventing
the proper use of certified capabilities for the exchange of EHI), ONC
may determine that a nexus exists between the developer's business
practices and the functionality of the certified Health IT Module, and
may consider termination of the certificate(s) of that particular
Health IT Module under the proposed approach.
We proposed this approach, which allows ONC to initiate a
certification ban and/or certificate termination under certain
circumstances, to ensure that health IT developers are acting in
accordance with the Conditions and Maintenance of Certification
requirements. However, we stressed that our first and foremost priority
is to work with health IT developers to remedy any noncompliance with
Conditions and Maintenance of Certification requirements through a
corrective action process before taking further action. This emphasizes
ONC's desire to promote and support health IT developer compliance with
the
[[Page 25786]]
Conditions and Maintenance of Certification requirements, and ensure
that certified health IT is compliant with Program requirements, in
order to foster an environment where EHI is exchanged in an
interoperable way.
We proposed in 84 FR 7505 that in considering whether termination
of a Health IT Module's certificate(s) and/or a certification ban is
appropriate, ONC would consider factors including, but not limited to:
Whether the health IT developer has previously been found in
noncompliance with the Conditions and Maintenance of Certification or
other Program requirements; the severity and pervasiveness of the
noncompliance, including the effect of the noncompliance on widespread
interoperability and health information exchange; the extent to which
the health IT developer cooperates with ONC to review the
noncompliance; the extent of potential negative impact on providers who
may seek to use the certified health IT to participate in CMS programs;
and whether termination and/or a certification ban is necessary to
ensure the integrity of the certification process.
In the Proposed Rule, we noted in 84 FR 7505 that, as found in
Sec. 170.580(f)(2), ONC would provide notice of the termination to the
health IT developer, including providing an explanation for,
information supporting, and consequences of, the termination, as well
as instructions for appealing the termination. We proposed to add
substantially similar notice provisions to Sec. 170.581 for
certification bans issued under ONC direct review for noncompliance
with the Conditions and Maintenance of Certification requirements.
These provisions would also include instructions for requesting
reinstatement. In this regard, in 84 FR 7505 we proposed to apply the
current reinstatement procedures under Sec. 170.581 to certification
bans resulting from noncompliance with the Conditions and Maintenance
of Certification requirements, but with an additional requirement that
the health IT developer has resolved the noncompliance with the
Condition or Maintenance of Certification requirement. In sum, we
proposed that a health IT developer could seek ONC's approval to re-
enter the Program and have the certification ban lifted if it
demonstrates that it has resolved the noncompliance with the Condition
or Maintenance of Certification requirement, and ONC is satisfied that
all affected customers have been provided appropriate remediation. We
sought comment on whether ONC should impose a minimum time period for a
certification ban, such as when a health IT developer is noncompliant
with a Condition or Maintenance of Certification requirement more than
once (e.g., a minimum six months for two instances, a minimum of one
year for three instances). We also sought comment on whether additional
factors should be considered for a certification ban and/or termination
of a health IT developer's certified health IT.
Comments. We received several comments regarding a minimum ban
length for repeat offenders. A couple of the commenters recommended ONC
establish a minimum ban and agreed with ONC's examples listed above.
Other commenters stated that a minimum ban would not be appropriate,
with one commenter stating that a minimum ban could have unintended
consequences and another commenter stating that it would be better if
the length of the ban was determined situationally.
Response. We have finalized the provisions regarding termination
and certification ban in Sec. Sec. 170.580 and 170.581 as proposed. We
have not established a minimum ban length for repeat offenders, as a
reinstatement process has been established in Sec. 170.581(d) that
affords ONC the discretion to determine whether a developer has
demonstrated appropriate remediation to all customers affected by the
certificate termination, certificate withdrawal, or noncompliance with
a Condition or Maintenance of Certification requirement. Section
170.581(d)(4) allows ONC to grant reinstatement into the Program if ONC
is satisfied with a health IT developer's demonstration of appropriate
remediation, and ONC may consider any and all factors, including past
bans, that may affect ONC's decision to grant reinstatement into the
Program.
Comments. We received several comments expressing concern for how
physicians using products whose developer has been banned would be
impacted with respect to payment programs.
Response. We appreciate these comments and clarify that the health
IT products of a health IT developer under a certification ban (not
certificate termination) would still be considered certified. This
means that those products would still be available for use by providers
participating in programs requiring the use of certified health IT.
However, while under a ban, a health IT developer could not make
updates to the certification of those products. This means that access
to new certified functionalities within a health IT developer's
products would be limited. If the certification status of a product may
impact health care providers that are users of that product for HHS
program participation, ONC would continue to support HHS and other
Federal and State partners, such as CMS, to help identify and make
available appropriate remedies for users of terminated certified health
IT. This would include supporting policies to mitigate negative impacts
on providers, such as the availability of hardship exceptions for the
Promoting Interoperability (PI) Programs for hospitals as mandated by
section 4002(b)(1)(A) and (b)(2) of the 21st Century Cures Act and
finalized by CMS in the FY 2018 Inpatient Prospective Payment System
final rule (80 FR 38488 through 38490).
Comments. We received one comment that ONC should add a fine as
part of the enforcement of the Conditions and Maintenance of
Certification requirements.
Response. We appreciate this comment, but ONC does not have the
authority to add a monetary fine as part of the enforcement of the
Conditions and Maintenance of Certification requirements. We note,
however, that health IT developers are subject to civil monetary
penalties (CMPs) if they engage in information blocking, and that a
health IT developer must not take any action that constitutes
information blocking as a Condition of Certification requirement (Sec.
170.401).
Comments. One commenter recommended that certification bans apply
not only to health IT developers who are noncompliant, but also to the
individual management representatives involved, and that account
migration review plans be required as an aspect of enforcement in order
to address issues around creation of new legal entities in response to
a certification ban.
Response. We appreciate these comments and note that certification
bans affect health IT developers participating in the Program, their
subsidiaries, and their successors (81 FR 72443). We do not have the
authority to regulate or enforce against individual management
representatives, though we believe the certification ban's reach is an
appropriate and sufficient incentive for health IT developers to
resolve any noncompliance and meet all required conditions. As stated
previously, we are utilizing processes previously established for ONC
direct review of certified health IT for the enforcement of the
Conditions and Maintenance of Certification requirements, which we
believe are familiar to health IT developers and provide a transparent
process for working with health IT
[[Page 25787]]
developers to remedy instances of noncompliance.
Comments. One commenter expressed concern that there is no process
for measuring the severity of a finding of noncompliance, and ONC's
proposed enforcement approach would allow for banning of all of a
health IT developer's certified health IT based on a finding of
noncompliance. The commenter requested that the final rule specify
circumstances that could lead to this serious result.
Response. We appreciate the comment and clarify that, as proposed,
if a health IT developer under ONC direct review for noncompliance with
a Condition of Certification requirement failed to work with ONC to
correct the noncompliance, or was noncompliant with the requirements of
the CAP, ONC could issue a certification ban. However, we stress that
our priority is to first work with health IT developers to correct any
noncompliance with the Conditions and Maintenance of Certification
requirements through corrective action. As stated in the Proposed Rule
in 84 FR 7505, factors we would consider prior to issuing a
certification ban, or termination of a Health IT Module's certificate,
include whether the health IT developer has previously been found in
noncompliance with the Conditions and Maintenance of Certification
requirements or other Program requirements; the severity and
pervasiveness of the noncompliance; cooperation on the part of the
health IT developer during ONC review; potential negative impact on
providers participating in CMS programs; and whether termination and/or
a certification ban is necessary to ensure the integrity of the
certification process.
We clarify that while under a CAP or surveillance by ONC or an ONC-
ACB, in the event a health IT developer's approach to remedy a non-
conformity and/or to meet Program requirements is to withdraw their
current certificate(s) for replacement with a new certificate issued by
the ONC-ACB to reflect a new scope, they will not be subject to a
certification ban. We note that any open non-conformities will be
transferred to the newly issued certificate(s) and must still be
resolved by the health IT developer. Similarly, when an ONC-ACB issues
a new certificate to reflect 2015 Edition changes, and must withdraw a
health IT developer's current certificate to do so, the health IT
developer will not be subject to a certification ban if the developer
is currently under a CAP or has health IT with open non-conformities.
Comments. One commenter stated that in instances of information
blocking, the termination of a Health IT Module's certificate or
issuance of a certification ban should not occur until the health IT
developer has had the opportunity to respond to the charge of
information blocking and appeal the finding.
Response. As stated previously, we have finalized in Sec. Sec.
170.580 and 170.581 our proposed approach to utilize the processes
previously established for ONC direct review of certified health IT for
the enforcement of the Conditions and Maintenance of Certification
requirements. These processes are open and transparent, and they
provide an opportunity for health IT developers to remedy instances of
noncompliance through corrective action. We again stress that it is our
priority to first work with health IT developers to correct any
noncompliance with the Conditions and Maintenance of Certification
requirements through corrective action. We believe these processes
provide ample opportunity for a health IT developer to respond to and
address information blocking prior to issuance of a certification ban
or termination of a Health IT Module's certificate.
Comments. We received one comment stating that the final rule
should provide for an emergency remedy when the blocking of information
places an individual at risk of immediate harm.
Response. Our current process for direct review enables ONC to
respond appropriately in the case of certified health IT that may be
causing or contributing to conditions that present a serious risk to
public health or safety (Sec. Sec. 170.580(a)(2)(i) and
170.580(d)(1)). We also refer readers to the information blocking
section in this final rule (section VIII of preamble and Part 171) for
a detailed discussion regarding the information blocking provision and
the exceptions to the information blocking definition, including those
designed to prevent harm to patients and others.
f. Appeal
We proposed in 84 FR 7505 that a health IT developer would have an
opportunity to appeal an ONC determination to issue a certification ban
and/or certificate termination resulting from noncompliance with a
Condition or Maintenance of Certification requirement. We proposed to
follow the processes specified in Sec. 170.580(g). As such, we
proposed to revise Sec. 170.580(g) to incorporate ONC direct review of
compliance with the Conditions and Maintenance of Certification
requirements.
Comments. We received a number of comments generally supporting our
proposal to utilize the Appeals processes in our enforcement of
compliance with the Condition or Maintenance of Certification
requirements.
Response. We appreciate the comments expressing support for our
proposal and have finalized our proposal and proposed revisions to
Sec. 170.580(g) to incorporate ONC direct review of compliance with
the Conditions and Maintenance of Certification requirements.
g. Suspension
We proposed in 84 FR 7506 to not apply the suspension processes
under Sec. 170.580 to our review of compliance with the Conditions and
Maintenance of Certification requirements. Section 170.580 includes a
process for suspending the certification of a Health IT Module at any
time if ONC has a reasonable belief that the certified health IT may
present a serious risk to public health and safety. While this will
remain the case for certified health IT under ONC direct review (i.e.,
suspension of certification is always available under ONC direct review
when the certified health IT presents a serious risk to public health
and safety), we do not believe such circumstances would apply to
noncompliance with the Conditions or Maintenance of Certification
requirements. Further, we believe the more streamlined processes
proposed for addressing noncompliance with Conditions and Maintenance
of Certification requirements alleviates the need to proceed through a
suspension process.
Comments. We received a number of comments generally supporting our
proposal not to include Suspension in our enforcement of compliance
with the Condition or Maintenance of Certification requirements.
Response. We appreciate the comments expressing support for our
proposal and have finalized our proposal as proposed.
h. Proposed Termination
We proposed in 84 FR 7506 to not include an intermediate step
between a developer failing to take appropriate and timely corrective
action and termination of a certified Health IT Module's certificate
called ``proposed termination'' (see Sec. 170.580(e) and 81 FR
72437)). Rather, as discussed above, ONC may proceed directly to
issuing a certification ban or notice of termination if it determines a
certification ban and/or certificate termination are appropriate per
the considerations
[[Page 25788]]
discussed above. The Conditions and Maintenance of Certification
requirements focus on developer business practices and actions for
which, as previously discussed, noncompliance is likely to undermine
the integrity of the Program and impede widespread interoperability and
information exchange. As such, we stated that it is appropriate and
consistent with the Cures Act to proceed immediately to a certification
ban and/or termination of the affected Health IT Module's
certificate(s) if a developer does not take appropriate and timely
corrective action. A certification ban and/or termination serves as an
appropriate disincentive for noncompliance with the Conditions and
Maintenance of Certification requirements.
Comments. We received a number of comments generally supporting our
proposal not to include Proposed Termination in our enforcement of
compliance with the Condition or Maintenance of Certification
requirements.
Response. We appreciate the comments expressing support for our
proposal and have finalized our proposal as proposed.
4. Public Listing of Certification Ban and Termination
We proposed in 84 FR 7506 to publicly list on ONC's website health
IT developers and certified Health IT Modules that are subject to a
certification ban and/or have been terminated, respectively, for
noncompliance with a Condition or Maintenance of Certification
requirement or for reasons already specified in Sec. 170.581. We take
this same approach for health IT with terminated certifications (see 81
FR 72438). Public listing serves to discourage noncompliance with
Conditions and Maintenance of Certification and other Program
requirements, while encouraging cooperation with ONC and ONC-ACBs and
remediation of non-conformities. It also serves to provide notice to
all ONC-ATLs, ONC-ACBs, public and private programs requiring the use
of certified health IT, and consumers of certified health IT of the
status of certified health IT and health IT developers operating under
the Program. We sought comment on this proposal, including input on the
appropriate period of time to list health IT developers and affected
certified Health IT Modules on healthit.gov.
Comments. We received several recommendations that we should enable
indefinite posting of certification bans and certificate terminations,
including a comment recommending that the public listing show the start
and end date of bans that were lifted. We also received one comment
recommending that ONC differentiate reinstated developers on the public
listing. We also received one comment that there should be an option
for a ban to be lifted once the developer comes into compliance.
Response. Responsive to comments and in order to support
transparency, we have decided not to set a time limit for listings on
the Certified Health IT Product List (CHPL) and to also provide the
start and end dates of bans that were lifted. We clarify that the CHPL
provides transparency regarding certified health IT listings, including
historical non-conformities assessed through surveillance, even after
the non-conformity is resolved. This approach to historical
transparency is applied to certification bans as well. We also clarify
that a certification ban can be lifted as long as the developer has
resolved the noncompliance and met all required conditions. We refer
readers to Sec. 170.581 for details about the certification ban and
reinstatement processes.
5. Effect on Existing Program Requirements and Processes
The Cures Act introduced new Conditions and Maintenance of
Certification requirements that encompass technical and functional
requirements of health IT and new actions and business practice
requirements for health IT developers, which we proposed to adopt in
subpart D of Part 170. The pre-Cures Act structure and requirements of
the Program provide processes to enforce compliance with technical and
functional requirements of certified health IT, and to a more limited
extent, requirements for the business practices of health IT developers
(see, e.g., 45 CFR 170.523(k)(1)) under subparts C (Certification
Criteria for Health Information Technology) and E (ONC Health IT
Certification Program) of Part 170. ONC-ACBs are required to perform
surveillance on certified Health IT Modules and may investigate
reported allegations of non-conformities with Program requirements
under subparts A, B, C, and E, with the ultimate goal of working with
the health IT developer to correct the non-conformity. Under certain
circumstances, such as unsafe conditions or impediments to ONC-ACB
oversight, ONC may directly review certified health IT to determine
whether it conforms to the requirements of the Program (see Sec.
170.580 and the EOA final rule at 81 FR 72404). These avenues for
investigating non-conformities with certified Health IT Modules will
continue to exist under the Program and generally focus on
functionality and performance of certified health IT, or on more
limited requirements of business practices of health IT developers
found in subparts A, B, C and E of Part 170, respectively. Thus, there
may be instances where one or more Condition or Maintenance of
Certification requirement is not being or has not been met that also
relate to certified Health IT Module non-conformities under subparts A,
B, C and E. We proposed that under these situations, ONC could in
parallel implement both sets of processes--existing processes to
investigate Health IT Module non-conformities and the proposed process
to enforce compliance with the Conditions and Maintenance of
Certification requirements. We stressed, however, that under the
proposed enforcement approach, only ONC would have the ability to
determine whether a Condition or Maintenance of Certification
requirement per subpart D has been or is being met.
We proposed to delineate the scope of an ONC-ACB's requirements to
perform surveillance on certified Health IT Modules as related only to
the requirements of subparts A, B, C and E of Part 170. Given our
proposed approach that would authorize solely ONC to determine whether
a Conditions or Maintenance of Certification requirement per subpart D
has been or is being met, we proposed in 84 FR 7506 to add a new PoPC
for ONC-ACBs in Sec. 170.523(s) that would require ONC-ACBs to report
to ONC, no later than a week after becoming aware, any information that
could inform whether ONC should exercise direct review for
noncompliance with a Condition or Maintenance of Certification
requirement or any matter within the scope of ONC direct review. We did
not receive specific comments on this section of the Proposed Rule and
have finalized this approach regarding delineation of the review
activities of ONC and ONC-ACBs in Sec. Sec. 170.580 and 170.581 as
proposed.
6. Coordination With the Office of the Inspector General
We clarified in the Proposed Rule in 84 FR 7507 that the
enforcement approach would apply only to ONC's administration of the
Conditions and Maintenance of Certification requirements and other
requirements under the Program, but it would not apply to other
agencies or offices that have independent authority to investigate and
take enforcement action
[[Page 25789]]
against a health IT developer of certified health IT. Notably, section
3022(b)(1)(A)(ii) of the PHSA, as added by the Cures Act, authorizes
the OIG to investigate claims that a health IT developer of certified
health IT has engaged in information blocking, which is defined by
section 3022(a)(1) of the PHSA as subject to reasonable and necessary
activities identified by the Secretary as exceptions to the definition
as proposed in part 171 (see section VIII.D of this final rule).
Additionally, section 3022(b)(1)(A)(i) authorizes OIG to investigate
claims that a health IT developer of certified health IT has submitted
a false attestation under the Condition of Certification requirement
which is described at section 3001(c)(5)(D)(vi) of the Cures Act. We
emphasized that ONC's and OIG's respective authorities under the Cures
Act (and in general) are independent and that either or both offices
may exercise those authorities at any time.
We noted, however, that ONC and OIG may coordinate their respective
information blocking activities, as appropriate, such as by sharing
information about claims or suggestions of possible information
blocking or false attestations (including violations of Conditions and
Maintenance of Certification requirements that may indicate that a
developer has falsely attested to meeting a Condition or Maintenance of
Certification requirement). Therefore, we proposed in 84 FR 7507 that
we may coordinate our review of a claim of information blocking with
OIG or defer to OIG to lead a review of a claim of information
blocking. In addition, we proposed that we may rely on OIG's findings
to form the basis of a direct review action.
Comments. The majority of comments received supported the general
enforcement approach proposed by ONC. We did receive one comment
recommending that we use a process similar to OCR's enforcement of the
HIPAA Rules and centralize enforcement of patient and provider rights
with respect to privacy and access to EHI. Additionally, we received
several comments seeking clarification regarding ONC's coordination
with OIG and one expressing concern about the potential for a developer
to be under review by both OIG and ONC for the same conduct.
Response. We welcome the many comments in support of our proposed
enforcement approach. We also appreciate the comment regarding using
processes similar to OCR and centralizing enforcement of privacy and
access rights. We agree that it is crucial that we develop clear
processes for reporting and investigating claims of potential
information blocking. To that end, ONC and OIG are actively
coordinating on establishing referral policies and procedures to ensure
the timely and appropriate flow of information related to information
blocking complaints. We also note that the information blocking section
of this final rule (part 171) has a delayed compliance date of 6 months
after date of publication of the final rule.
OIG and ONC are also coordinating timing of the effective date of
this final rule and the start of information blocking enforcement and
enforcement of the Conditions of Certification related to information
blocking (Sec. 170.401, Sec. 170.404(a)(1), and Sec. 170.406(a)(1)).
We are providing the following information on timing for actors
regulated by the information blocking provision. Enforcement of
information blocking civil monetary penalties (CMP) in section
3022(b)(2)(A) of the PHSA will not begin until established by future
notice and comment rulemaking by OIG. As a result, actors would not be
subject to penalties until CMP rules are final. At a minimum, the
timeframe for enforcement would not begin sooner than the compliance
date of the information blocking provision and will depend on when the
CMP rules are final. Discretion will be exercised such that conduct
that occurs before that time will not be subject to the information
blocking CMPs. Individuals and entities are subject to the information
blocking regulations and must comply with this rule as of the
compliance date of this provision.
The Cures Act directs the National Coordinator to implement a
standardized process for the public to submit reports on claims of
health information blocking. ONC intends to implement and evolve this
complaint process by building on existing mechanisms, including the
current ONC complaint process. We requested comment in the Proposed
Rule on ways to adapt our current complaint process for claims of
information blocking and refer readers to section VIII.F of this final
rule for a more detailed discussion of the complaint process for claims
of information blocking. OIG also has the ability to receive and review
complaints directly from the public. This ensures that there is no
``wrong door'' by which a complainant can submit information. OIG will
provide training to allow their investigators to identify information
blocking allegations as part of their other fraud and abuse
investigations. Additionally, as part of their continued efforts to
implement the information blocking authorities, OIG will establish
policies and procedures for reviewing and triaging complaints. We will
continue to work with OIG to establish coordinated and aligned
procedures and reviews of information blocking complaints as envisioned
by the Cures Act. We also emphasize that in order to promote effective
enforcement, the information blocking provision of the Cures Act
empowers OIG to investigate claims of information blocking and provides
referral processes to facilitate coordination with other relevant
agencies, including ONC, OCR, and the Federal Trade Commission (FTC).
Future notice and comment rulemaking by OIG will provide more
additional detail regarding information blocking enforcement.
We clarify that there could be situations when a health IT
developer of certified health IT's practices could be reviewed by both
ONC and OIG because ONC and OIG have separate and distinct enforcement
authority regarding claims of information blocking. We explained in the
Proposed Rule that ONC has statutory authority to enforce the
Information Blocking Condition and Maintenance of Certification
requirements (Sec. 170.401) and that ONC would enforce the Conditions
of Certification requirements through the direct review process. OIG
has investigatory authority for the information blocking provision (42
U.S.C. 300jj-52(b)), which may lead to the issuance of (CMPs) for
information blocking conducted by health IT developers of certified
health IT, health information networks, and health information
exchanges. OIG may also investigate health care providers for
information blocking, which could result in health care providers being
subject to appropriate disincentives. In addition, OIG may investigate
false attestations by health IT developers participating in the
Program. Since ONC's and OIG's respective authorities with regard to
information blocking under the Cures Act (and in general) are
independent, it is necessary that either or both offices may exercise
those authorities at any time.
However, we emphasize, as we explained above in the Proposed Rule,
that we anticipate that ONC and OIG will coordinate their respective
information blocking activities, as appropriate, such as by sharing
information about claims or suggestions of possible information
blocking or false attestations (including violations of Conditions and
Maintenance of Certification requirements that may indicate that a
developer has falsely attested to meeting a Condition or Maintenance of
Certification
[[Page 25790]]
requirement). Therefore, we have finalized in Sec. 170.580(a)(4) the
proposed approach that will allow us to coordinate our review of a
claim of information blocking with the OIG, or defer to OIG to lead a
review of a claim of information blocking. In addition, the finalized
approach will allow ONC to rely on OIG findings to form the basis of a
direct review action.
7. Applicability of Conditions and Maintenance of Certification
Requirements for Self-Developers
The HHS regulation that established the Program, ``Establishment of
the Permanent Certification Program for Health Information Technology''
(76 FR 1261), addresses self-developers and describes the concept of
``self-developed'' as referring to a Complete EHR or EHR Health IT
Module designed, created, or modified by an entity that assumed the
total costs for testing and certification and that will be the primary
user of the health IT (76 FR 1300 and 1301). While we proposed in 84 FR
7508 in the ``Enforcement'' section of the Proposed Rule that all
general Conditions and Maintenance of Certification requirements apply
to such developers, we also sought comment on which aspects of the
Conditions and Maintenance of Certification requirements may not be
applicable to self-developers.
Comments. We received one comment that self-developers should not
be permitted to rely on the exception available under the
``Communications'' Condition of Certification requirement that allows
developers to place limited restrictions on the communications of their
employees who are using their products.
Response. We agree with the comment that self-developers should not
be allowed to restrict the communications of users of their product who
are also employees. We have revised the language of the
``Communications'' Condition of Certification requirement in Sec.
170.403(a)(2)(ii)(A)(2) to clarify that the limited prohibitions
developers may place on employees under the Condition of Certification
requirement cannot be placed on users of the developers' products who
also happen to be employees or contractors of the developer. Overall,
we intend to hold self-developers to all Conditions and Maintenance of
Certification requirements of health IT developers, as applicable based
on the health IT certified.
VIII. Information Blocking
A. Statutory Basis
Section 4004 of the Cures Act added section 3022 of the Public
Health Service Act (PHSA) (42 U.S.C. 300jj-52, ``the information
blocking provision''). Section 3022(a)(1) of the PHSA defines practices
that constitute information blocking when engaged in by a health care
provider, or a health information technology developer, exchange, or
network. Section 3022(a)(3) authorizes the Secretary to identify,
through notice and comment rulemaking, reasonable and necessary
activities that do not constitute information blocking for purposes of
the definition set forth in section 3022(a)(1). We proposed in the
Proposed Rule to establish exceptions to the information blocking
definition, each of which would define certain activities that would
not constitute information blocking for purposes of section 3022(a)(1)
of the PHSA because they are reasonable and necessary to further the
ultimate policy goals of the information blocking provision. We also
proposed to interpret or define certain statutory terms and concepts
that are ambiguous, incomplete, or provide the Secretary with
discretion, and that we believe are necessary to carry out the
Secretary's rulemaking responsibilities under section 3022(a)(3) (84 FR
7522).
B. Legislative Background and Policy Considerations
In the Proposed Rule, we outlined the purpose of the information
blocking provision and related policy and practical considerations that
we considered in identifying the reasonable and necessary activities
that we proposed as exceptions to the information blocking definition
(84 FR 7508).
1. Purpose of the Information Blocking Provision
We explained in the Proposed Rule that the information blocking
provision was enacted in response to concerns that some individuals and
entities are engaging in practices that unreasonably limit the
availability and use of electronic health information (EHI) for
authorized and permitted purposes. These practices undermine public and
private sector investments in the nation's health IT infrastructure,
and frustrate efforts to use modern technologies to improve health care
quality and efficiency, accelerate research and innovation, and provide
greater value and choice to health care consumers (84 FR 7508).
We emphasized that the nature and extent of information blocking
has come into sharp focus in recent years. In 2015, at the request of
Congress, we submitted a Report on Health Information Blocking \117\
(``Information Blocking Congressional Report''), in which we commented
on the then-current state of technology and of health IT and health
care markets. Notably, we observed that prevailing market conditions
create incentives for some individuals and entities to exercise control
over EHI in ways that limit its availability and use (84 FR 7508).
---------------------------------------------------------------------------
\117\ ONC, Report to Congress on Health Information Blocking
(Apr. 2015), https://www.healthit.gov/sites/default/files/reports/info_blocking_040915.pdf [hereinafter ``Information Blocking
Congressional Report''].
---------------------------------------------------------------------------
We noted that we have continued to receive complaints and reports
of information blocking from patients, clinicians, health care
executives, payers, app developers and other technology companies,
registries and health information exchanges, professional and trade
associations, and many other stakeholders. We noted that ONC has
listened to and reviewed these complaints and reports, consulted with
stakeholders, and solicited input from our Federal partners in order to
inform our proposed information blocking policies. Stakeholders
described discriminatory pricing policies that have the obvious purpose
and effect of excluding competitors from the use of interoperability
elements. Many industry stakeholders who shared their perspectives with
us in listening sessions, including several health IT developers of
certified health IT, condemned these practices and urged us to swiftly
address them. We highlighted that our engagement with stakeholders
confirmed that, despite significant public and private sector efforts
to improve interoperability and data accessibility, adverse incentives
remain and continue to undermine progress toward a more connected
health system (84 FR 7508).
Based on these economic realities and our first-hand experience
working with the health IT industry and stakeholders, in the
Information Blocking Congressional Report, we concluded that
information blocking is a serious problem, and recommended that
Congress prohibit information blocking and provide penalties and
enforcement mechanisms to deter these harmful practices (84 FR 7508).
We noted in the Proposed Rule that recent empirical and economic
research further underscores the intractability of this problem and its
harmful effects. In a national survey of health information
organizations, half of respondents reported that EHR developers
routinely
[[Page 25791]]
engage in information blocking, and a quarter of respondents reported
that hospitals and health systems routinely do so. The survey reported
that perceived motivations for such conduct included, for EHR vendors,
maximizing short-term revenue and competing for new clients, and for
hospitals and health systems, strengthening their competitive position
relative to other hospitals and health systems.\118\ We noted that
other research suggests that these practices weaken competition among
health care providers by limiting patient mobility, encouraging
consolidation, and creating barriers to entry for developers of new and
innovative applications (also referred to as ``apps'') and technologies
that enable more effective uses of clinical data to improve population
health and the patient experience \119\ (84 FR 7508).
---------------------------------------------------------------------------
\118\ See, e.g., Julia Adler-Milstein and Eric Pfeifer,
Information Blocking: Is It Occurring And What Policy Strategies Can
Address It?, 95 Milbank Quarterly 117, 124-25 (Mar. 2017), available
at http://onlinelibrary.wiley.com/doi/10.1111/1468-0009.12247/full.
\119\ See, e.g., Martin Gaynor, Farzad Mostashari, and Paul B.
Ginsburg, Making Health Care Markets Work: Competition Policy for
Health Care, 16-17 (Apr. 2017), available at https://www.brookings.edu/research/making-health-care-markets-work-competition-policy-for-health-care/; Diego A. Martinez et al., A
Strategic Gaming Model For Health Information Exchange Markets,
Health Care Mgmt. Science (Sept. 2016). (``[S]ome healthcare
provider entities may be interfering with HIE across disparate and
unaffiliated providers to gain market advantage.'') Niam Yaraghi, A
Sustainable Business Model for Health Information Exchange
Platforms: The Solution to Interoperability in Healthcare IT (2015),
available at http://www.brookings.edu/research/papers/2015/01/30-sustainable-business-model-health-information- exchange-yaraghi;
Thomas C. Tsai & Ashish K. Jha, Hospital Consolidation, Competition,
and Quality: Is Bigger Necessarily Better?, 312 J. AM. MED. ASSOC.
29, 29 (2014).
---------------------------------------------------------------------------
We explained in the Proposed Rule that the information blocking
provision provides a comprehensive response to these concerns. The
information blocking provision defines and creates possible penalties
and disincentives for information blocking in broad terms, while
working to deter the entire spectrum of practices that unnecessarily
impede the flow of EHI or its use to improve health and the delivery of
care. The information blocking provision applies to the conduct of
health care providers and health IT developers, exchanges, and
networks, and seeks to deter information blocking through civil
monetary penalties and disincentives for violations. Additionally,
developers of health IT certified under the Program are prohibited from
information blocking under 3001(c)(5)(D)(i) of the PHSA (84 FR 7509).
The information blocking provision authorizes the HHS Office of
Inspector General (OIG) to investigate claims of information blocking
and provides for referral processes to facilitate coordination among
Federal agencies, including ONC, the HHS Office for Civil Rights (OCR),
and the Federal Trade Commission (FTC). The information blocking
provision also provides for a process for the public to submit reports
on claims of information blocking as well as confidentiality
protections to encourage and facilitate the reporting of information
blocking. Enforcement of the information blocking provision is
buttressed by section 3001(c)(5)(D)(i) and (vi) of the PHSA, which
requires the Secretary to establish as a Condition and Maintenance of
Certification requirement under the Program that health IT developers
do not take any action that constitutes information blocking and
require such developers to attest that they have not engaged in such
conduct (84 FR 7509).
2. Policy Considerations and Approach to Information Blocking
We explained in the Proposed Rule that the information blocking
provision encompasses a broad range of potential practices in order to
ensure that individuals and entities that engage in information
blocking are held accountable. However, we explained that it is
possible that some activities that are innocuous, or even beneficial,
could technically implicate the information blocking provision. Given
the possibility of these activities, section 3022(a)(3) of the PHSA
requires the Secretary, through rulemaking, to identify reasonable and
necessary activities that do not constitute information blocking. We
refer to such reasonable and necessary activities identified by the
Secretary as ``exceptions'' to the information blocking provision. The
information blocking provision also excludes from the definition of
information blocking those practices that are required by law (section
3022(a)(1) of the PHSA) and clarifies certain other practices that
would either not be considered information blocking or penalized
(sections 3022(a)(6) and (7) of the PHSA) (84 FR 7509).
In considering potential exceptions to the information blocking
provision, we strove to balance a number of policy and practical
considerations. To minimize compliance and other burdens for
stakeholders, we explained that we were seeking to promote clear,
predictable, and administrable policies. In addition, we emphasized our
intention to implement the information blocking provision in a way that
would be sensitive to legitimate practical challenges that may prevent
access to, exchange, or use of EHI in certain situations. We also
explained our goal to accommodate practices that, while they may
inhibit access, exchange, or use of EHI, are reasonable and necessary
to advance other compelling policy interests, such as preventing harm
to patients and others, promoting the privacy and security of EHI, and
promoting competition and consumer welfare (84 FR 7509).
At the same time, we explained that we sought to provide a
comprehensive response to the information blocking problem. Information
blocking can occur through a variety of business, technical, and
organizational practices that can be difficult to detect and that are
constantly changing as technology and industry conditions evolve. The
statute responds to these challenges by defining information blocking
broadly and in a manner that allows for careful consideration of
relevant facts and circumstances in individual cases.
Accordingly, we proposed in the Proposed Rule to establish certain
defined exceptions to the information blocking provision as a way to
identify reasonable and necessary activities that do not constitute
information blocking as required by section 3022(a)(3) of the PHSA. We
proposed that these exceptions would be subject to strict conditions
and would apply three overarching policy criteria. First, each
exception would be limited to certain activities that are both
reasonable and necessary. These reasonable and necessary activities
include: Promoting public confidence in the health IT infrastructure by
supporting the privacy and security of EHI and protecting patient
safety; and promoting competition and innovation in health IT and its
use to provide health care services to consumers. Second, we noted that
each exception addresses a significant risk that regulated individuals
and entities will not engage in these reasonable and necessary
activities because of uncertainty regarding the breadth or
applicability of the information blocking provision. Third, we
explained that each exception is intended to be tailored, through
appropriate conditions, so that it is limited to the reasonable and
necessary activities that it is designed to protect and does not extend
protection to other activities or practices that could raise
information blocking concerns (84 FR 7509).
3. General Comments Regarding Information Blocking Exceptions
Comments. Numerous commenters expressed support for the proposed
[[Page 25792]]
information blocking exceptions overall. Some commenters stated that
information blocking is a widespread problem and perhaps the greatest
barrier to interoperability, and supported our approach to addressing
information blocking.
While most commenters supported our policy goals regarding
information blocking, others questioned whether our policies would have
detrimental consequences to the industry given the breadth of the
definitions, ambiguity of the expectations, and narrowness of the
proposed exceptions. Another commenter stated that the proposed
information blocking exceptions are too vague and that an alternative
approach is necessary to reduce confusion. The commenter stated that we
should align the information blocking requirements with the certified
capabilities of health IT developers, and that information blocking
should be evaluated through the lens of access, exchange, and use of
the USCDI. One commenter suggested that our information blocking
policies be more patient-focused as offered by the Individual Health
RecordTM (IHR) Model.\120\ A few commenters requested
clarification on how each of the exceptions would be arbitrated, and
requested that we provide additional examples of actions that may fall
within each exception.
---------------------------------------------------------------------------
\120\ The IHR is a digital tool that provides an all-in-one
record of an individual's health, enabling a person and their care
team to help improve collaboration and care.
---------------------------------------------------------------------------
Response. We appreciate the support expressed by many commenters.
This final rule maintains the general direction of the Proposed Rule
regarding information blocking but focuses the scope of certain terms,
while also addressing the reasonable and necessary activities that
would qualify for an exception under the information blocking
provision. As an example, we have focused the scope of the EHI and
Health Information Network (HIN) definitions and have included a new
exception in this final rule, the Content and Manner Exception (Sec.
171.301). We appreciate the comment regarding the IHR Model, but have
determined that the best approach to support interoperability and the
access, exchange, and use of EHI is through the policies finalized in
this final rule, which are patient-focused. For instance, the Fees
Exception (Sec. 171.302), which allows certain fees to be charged,
does not apply to a fee based in any part on the electronic access (as
such term is defined in Sec. 171.302(d)) of an individual's EHI by the
individual, their personal representative, or another person or entity
designated by the individual. We emphasize that an actor's practice of
charging an individual, their personal representative, or another
person or entity designated by the individual for electronic access to
the individual's EHI would be inherently suspect under an information
blocking review.
We continue to receive complaints and reports alleging information
blocking from a wide range of stakeholders. ONC has listened to and
reviewed these complaints and reports, consulted with stakeholders,
solicited input from our Federal partners, and reviewed public comments
received in response to the Proposed Rule in order to inform our
information blocking policies. We look forward to ongoing collaboration
with public and private sector partners as we implement the information
blocking provision of this final rule. To note, we have provided
clarifications and additional examples throughout this final rule.
Comments. Numerous commenters expressed concern over the proposed
effective date of the information blocking policies. Commenters stated
that imposing stringent new mandates with an overly aggressive
implementation timeframe could be counterproductive by increasing
administrative and financial burdens on physician practices,
threatening the security of health information, and potentially
compromising patient safety. Several provider organizations requested
an enforcement ``grace period'' after the new information blocking
requirements take effect to allow providers sufficient time to
understand the requirements and implement new procedures to be
compliant before any disincentives would be applied. Specifically,
commenters recommended that OIG not take any enforcement action for a
period of 18 months or two years after the effective date of the final
rule. Several commenters recommended a period of enforcement discretion
of no less than five years during which OIG would require corrective
action plans instead of imposing penalties for information blocking.
One commenter also recommended that we ``grandfather'' any economic
arrangements that exist two years from date of the final rule.
We did not receive any comments on the proposed Sec. 171.101,
Applicability, which stated that this part applies to health care
providers, health IT developers of certified health IT, health
information exchanges, and health information networks, as those terms
are defined in Sec. 171.102.
Response. We thank commenters for their input. Taking these
comments into consideration, we have delayed the compliance date of the
information blocking section of this rule (45 CFR part 171). The
compliance date for the information blocking section of this final rule
will be six months after the publication date of this final rule in the
Federal Register. This six-month delayed compliance date was
established to provide actors with time to thoroughly read and
understand the final rule and educate their workforce in order to apply
the exceptions in an appropriate manner. We also note that the
finalized definition of information blocking (Sec. 171.103)) and the
new Content and Manner Exception (Sec. 171.301(a)) reduce the scope of
the EHI definition for the first 18 months after the compliance date of
the information blocking section of this final rule to the EHI
identified by the data elements represented in the USCDI. Therefore, in
addition to the information blocking section's compliance date being
six months after publication, actors will have an additional 18 months
to gain experience applying the exceptions with just the EHI identified
by the data elements represented in the USCDI as compared to the full
scope of EHI, which would apply thereafter.
During this combined period of 24 months, we strongly encourage
actors to apply the exceptions to all EHI as if the scope were not
limited to EHI identified by the data elements represented in the
USCDI. However, given the initial scope of EHI identified in the
information blocking definition in Sec. 171.103 and the Content and
Manner Exception in Sec. 171.103, if an actor did not, in the first 24
months from this final rule's publication date, enable access,
exchange, or use of data outside the USCDI, or did not appropriately
apply an exception to data outside the USCDI, such practice or error
would not be considered information blocking because that data would
not be considered ``EHI'' during that time period.
We have also delayed the compliance date of the Information
Blocking Condition of Certification requirement in Sec. 170.401 and
the Assurances Condition of Certification requirement in Sec.
170.402(a)(1). We also note that under 45 CFR part 171, we have focused
the scope of the EHI definition and have revised the seven proposed
exceptions in a manner that is clear, actionable, and likely to reduce
perceived burden.
OIG and ONC are coordinating timing of the compliance date of the
information blocking section of this
[[Page 25793]]
final rule (45 CFR part 171) and the start of information blocking
enforcement. We are providing the following information on timing for
actors. Enforcement of information blocking civil monetary penalties
(CMP) in section 3022(b)(2)(A) of the PHSA will not begin until
established by future notice and comment rulemaking by OIG. As a
result, actors would not be subject to penalties until CMP rules are
final. At a minimum, the timeframe for enforcement would not begin
sooner than the compliance date of the information blocking section of
this final rule (45 CFR part 171) and will depend on when the CMP rules
are final. Discretion will be exercised such that conduct that occurs
before that time will not be subject to information blocking CMP.
We have finalized Sec. 171.101 with an additional paragraph to
codify the compliance date for the information blocking section of this
final rule (45 CFR part 171). Section 171.101(b) states that health
care providers, health IT developers of certified health IT, health
information exchanges, and health information networks must comply with
this part on and after November 2, 2020.
Comments. Several commenters requested that we develop training and
educational materials on the information blocking provision. Commenters
specifically stated that we should work with other agencies (including
CMS, OIG, FTC and OCR) to develop and widely disseminate comprehensive
informational materials, such as sub-regulatory guidance and frequently
asked questions about what constitutes information blocking. Some
commenters recommended we work with OIG to ensure that enforcement
focuses on education rather than penalties against non-malicious
information blockers. A few commenters suggested that we offer an
opportunity for stakeholders to seek advisory opinions from OIG to
clarify what constitutes information blocking, or that we create a
formal advisory committee on information blocking. Other commenters
requested that heath care providers be provided an opportunity to cure
an alleged violation and an opportunity to appeal the alleged
violation.
Response. We thank commenters for their feedback, including their
suggestions for establishing a formal advisory committee. While we do
not plan to establish an advisory committee, we plan to engage in
multiple efforts to educate stakeholders. We intend to provide
educational resources such as infographics, fact sheets, webinars, and
other forms of educational materials and outreach based on needs
identified. We emphasize that the final rule details our information
blocking policies, and these educational materials are intended to
educate stakeholders on our final policies established in the final
rule. We are also actively coordinating with OIG and have provided OIG
with comments we received on the Proposed Rule related to information
blocking investigations and enforcement. Future notice and comment
rulemaking by OIG will provide additional detail regarding information
blocking enforcement.
C. Relevant Statutory Terms and Provisions
In the Proposed Rule, we included regulation text to codify the
definition of information blocking in Sec. 171.103. We discussed how
we proposed to interpret certain aspects of the information blocking
provision that we believe are ambiguous, incomplete, or that provided
the Secretary with discretion. We proposed to define or interpret
certain terms or concepts that are present in the statute and, in a few
instances, to establish new regulatory terms or definitions that we
believe are necessary to implement the directive in section 3022(a)(3)
of the PHSA to identify reasonable and necessary activities that do not
constitute information blocking. We explained that our goal in
interpreting the statute and defining relevant terms is to provide
greater clarity concerning the types of practices that could implicate
the information blocking provision and, relatedly, to more effectively
communicate the applicability and scope of the exceptions (84 FR 7509).
Comments. We did not receive any comments on the codification of
the proposed definition of information blocking in Sec. 171.103.
As discussed in more detail in section VIII.C.3, we received many
comments expressing concerns regarding the breadth of the proposed EHI
definition and requesting flexibility in the implementation of the
information blocking provision. Many commenters stated that it would be
difficult for actors to provide the full scope of EHI as it was
proposed to be defined, particularly as soon as the final rule was
published. Some commenters opined that we were trying to do too much
too fast. Commenters requested that we provide flexibility for actors
to adjust to the scope of the EHI definition, as well as the
exceptions. Commenters asserted that such an approach would permit them
to adapt their processes, technologies, and systems to enable the
access, exchange, and use of EHI as required by the Cures Act and this
final rule. Some commenters suggested that EHI under the information
blocking provision should be limited to ePHI as defined in 45 CFR
160.103, while others requested that ONC consider constraining the EHI
covered by the information blocking provision to only the data included
in the USCDI.
Response. We have finalized the proposed definition of information
blocking in Sec. 171.103 with the addition of paragraph (b). This new
paragraph states that until May 2, 2022--which is 18 months after the
6-month delayed compliance date for part 171 (a total of 24 months
after the publication date of this final rule)--EHI for purposes of
part 171 is limited to the EHI identified by the data elements
represented in the United States Core Data for Interoperability (USCDI)
standard adopted in Sec. 170.213. This addition aligns with the
content condition within the Content and Manner Exception, which states
that for up to May 2, 2022, an actor must respond to a request to
access, exchange, or use EHI with, at a minimum, the EHI identified by
the data elements represented in the USCDI standard adopted in Sec.
170.213 (see Sec. 171.301(a)(1)).
This incremental expansion of the access, exchange, and use of EHI
in both the information blocking definition (Sec. 171.103) and Content
and Manner Exception (Sec. 171.301) responds to commenters' concerns
regarding the breadth of health information actors are required to
share and the concern about the pace at which we are implementing the
information blocking provision. By using USCDI as the baseline of EHI
for 18 months after the compliance date of the information blocking
section of this final rule (45 CFR part 171),\121\ we have created a
transparent, predictable starting point for sharing the types of EHI
that is understood by the regulated community and more readily
available for access, exchange, and use. In addition, health IT that
has been certified to the 2015 Edition ``CCDS'' certification criteria
will be able to immediately and readily produce almost all of the data
elements identified in the USCDI. Furthermore, most, if not all, of
such health IT already supports recording USCDI data elements and most
HIEs/HINs are routinely exchanging such data elements. Further those
developers maintaining certification over the 18-month period from the
compliance date of the information blocking section of this
[[Page 25794]]
final rule (45 CFR part 171) will be in the process of updating their
certified health IT to produce all of the data elements specified in
the USCDI, including being certified to the new standardized
application programming interface (API) criterion (Sec.
170.315(g)(10)) and API Condition of Certification (Sec. 170.404).
---------------------------------------------------------------------------
\121\ The compliance date for the information blocking section
of this final rule (45 CFR part 171) is six months after the
publication date of the final rule.
---------------------------------------------------------------------------
We believe the 18-month delay will provide actors with adequate
time to prepare for the sharing of all EHI and sunset any non-compliant
technology, while providing a clear deadline for when all EHI must be
available for access, exchange, and use. During this time period,
actors can gain awareness, experience, and comfort with the information
blocking provision and exceptions without being required to apply the
information blocking exceptions to all EHI as it is defined in Sec.
171.102 (see section VIII.C.3). We expect actors to use this 18-month
delay from the compliance date of the information blocking section of
this final rule (45 CFR part 171) (in addition to the 6-month period
from the publication date of this final rule to the information
blocking compliance date) to practice applying the exceptions to real-
life situations and to update their processes, technologies, and
systems to adapt to the new information blocking requirements. We
believe actors will benefit from learning how to respond to requests
for all EHI and applying the exceptions during the 18-month delay.
Further, this approach will ensure that the application of the
information blocking provision is equitable across actors during the
18-month time period. For instance, if we had required actors to
respond to a request to access, exchange, or use EHI during this 18-
month time period with all EHI that the actor is able to provide, then
actors who are able to provide more EHI would carry a heavier burden
than actors who were only able to provide the data elements specified
in the USCDI. Nonetheless, and as discussed above, we encourage actors
to respond to requests for access, exchange, or use of EHI with as much
EHI as possible in order to promote interoperability and to practice
applying the exceptions.
We have included language regarding this incremental expansion of
the access, exchange, and use of EHI in both the information blocking
definition (Sec. 171.103) and Content and Manner Exception (Sec.
171.301) in order to ensure that the 18-month delay is uniformly
applied in the broad circumstances when requestors request access,
exchange, or use of EHI as well as in situations when an actor seeks to
satisfy the Content and Manner Exception by fulfilling a request to
access, exchange, or use EHI in an alternative manner than the manner
requested. This approach will ensure that the requisite content to be
included in an actor's response to a request to access, exchange, or
use EHI during the 18-month period is clear and consistent throughout
our information blocking policies.
1. ``Required by Law''
With regard to the statute's exclusion of practices that are
``required by law'' from the definition of information blocking, we
emphasized in the Proposed Rule that ``required by law'' refers
specifically to interferences with access, exchange, or use of EHI that
are explicitly required by State or Federal law. By carving out
practices that are ``required by law,'' the statute acknowledged that
there are laws that advance important policy interests and objectives
by restricting access, exchange, and use of EHI, and that practices
that follow such laws should not be considered information blocking (84
FR 7509).
We noted in the Proposed Rule that for the purpose of developing an
exception for reasonable and necessary privacy-protective practices, we
distinguished between interferences that are ``required by law'' and
those engaged in pursuant to a privacy law, but which are not
``required by law.'' (The former does not fall within the definition of
information blocking, but the latter may implicate the information
blocking provision and an exception may be necessary (84 FR 7510)).
Comments. We received comments requesting additional clarity
regarding the meaning and scope of ``required by law'' within the
information blocking provision.
Response. We thank commenters for the feedback. We clarify that our
references to Federal and State law include statutes, regulations,
court orders, and binding administrative decisions or settlements, such
as (at the Federal level) those from the FTC or the Equal Employment
Opportunity Commission (EEOC). We further note that ``required by law''
would include tribal laws, as applicable. For a detailed discussion of
the application of ``required by law'' in the context of the Privacy
Exception, please see section VIII.D.1.b.
2. Health Care Providers, Health IT Developers, Exchanges, and Networks
We explained in the Proposed Rule that section 3022(a)(1) of the
PHSA, in defining information blocking, refers to four classes of
individuals and entities that may engage in information blocking and
which include: Health care providers, health IT developers, networks,
and exchanges. We proposed in the Proposed Rule to adopt definitions of
these terms to provide clarity regarding the types of individuals and
entities to whom the information blocking provision applies (84 FR
7510). We noted that, for convenience and to avoid repetition in the
preamble, we typically refer to these individuals and entities covered
by the information blocking provision as ``actors'' unless it is
relevant or useful to refer to the specific type of individual or
entity. That is, when the term ``actor'' appears in the preamble, it
means a health care provider, health IT developer, health information
exchange, or health information network. We proposed to codify this
definition of ``actor'' in Sec. 171.102.
Comments. We did not receive any comments on this general approach
to use the term ``actors'' throughout the rule for clarity or the
proposed definition of ``actor'' in Sec. 171.102. We note that we did
receive comments about the definitions of the four categories of
actors, which are discussed below.
Response. We have finalized this approach and the definition of
``actor'' in Sec. 171.102 as proposed.
a. Health Care Providers
We identified in the Proposed Rule that the term ``health care
provider'' is defined in section 3000(3) of the PHSA (84 FR 7510). We
proposed to adopt this definition for purposes of section 3022 of the
PHSA (that is, for purposes of information blocking) when defining
``health care provider'' in Sec. 171.102. We noted that the PHSA
definition is different from the definition of ``health care provider''
under the HIPAA Rules. We further stated that we were considering
adjusting the information blocking definition of ``health care
provider'' to cover all individuals and entities covered by the HIPAA
Rules ``health care provider'' definition in 45 CFR 160.103. We sought
comment on whether such an approach would be justified, and encouraged
commenters to specify reasons why doing so might be necessary to ensure
that the information blocking provision applies to all health care
providers that might engage in information blocking.
Comments. A significant number of commenters were in favor of using
the definition of health care provider used in the HIPAA Rules.
However, other commenters asserted that doing so would exceed the scope
intended by the Cures Act. Some commenters requested exclusions or a
``phased-in'' approach
[[Page 25795]]
for the requirements for State agencies, institutions, public health
departments, ambulatory surgical centers, and other small providers due
to their limited resources or limited access to health IT. Other
commenters suggested limiting the application of the information
blocking provisions only to those health care providers using certified
health IT though some commenters also opposed such a limitation. Some
commenters suggested including additional categories such as medical
device manufacturers and community-based organizations that address
social determinants of health (e.g., access to food, housing, and
transportation).
Response. We have retained in this final rule the definition of
``health care provider'' as set forth in section 3000(3) of the PHSA as
proposed. The definitions listed in section 3000 of the PHSA apply
``[i]n this title,'' which refers to Title XXX of the PHSA. Section
3022 of the PHSA is included in Title XXX. We note that the last clause
of the health care provider definition in section 3000(3) of the PHSA
gives the Secretary discretion to expand the definition to any other
category determined to be appropriate by the Secretary. We will
consider whether the definition should be expanded in the future if the
scope of health care providers subject to the information blocking
provision does not appear to be broad enough in practice to ensure that
the information blocking provision applies to all health care providers
that might engage in information blocking.
With respect to the requested exclusions or a ``phased-in''
approach for certain types of entities, we do not believe that this is
necessary due to the addition of paragraph (b) within the information
blocking definition in Sec. 171.103 and the new Content and Manner
Exception in Sec. 171.310. Section 171.103(b) states that until May 2,
2022--which is 18 months after the compliance date of the information
blocking section of this final rule (part 171)--EHI for purposes of
part 171 is limited to the EHI identified by the data elements
represented in the United States Core Data for Interoperability (USCDI)
standard adopted in Sec. 170.213 (see the discussion in section
VIII.C). Similarly, the Content and Manner Exception allows actors to
make available a limited set of EHI (the USCDI) during the first 18
months after the six-month delayed compliance date for part 171 (a
total of 24 months after publication of this final rule). This
approach, as well as the Infeasibility Exception, will address concerns
about certain actors having limited resources or limited access to
health IT.
The health care provider definition and resources we have made
available provide clarity and examples of the types of individuals and
entities covered by the definition. To this point, medical device
manufacturers and community-based organizations, as described by
commenters, generally would not meet the health care provider
definition unless they are also a type of individual or entity
identified in the definition.
b. Health IT Developers of Certified Health IT
Section 3022(a)(1)(B) of the PHSA defines information blocking, in
part, by reference to the conduct of health information technology
developers. In the Proposed Rule (84 FR 7510), we explained that,
because title XXX of the PHSA does not define ``health information
technology developer,'' we interpreted section 3022(a)(1)(B) in light
of the specific authority provided to OIG in section 3022(b)(1)(A) and
(b)(2). We noted that section 3022(b)(2) discusses developers,
networks, and exchanges by referencing any individual or entity
described in section 3022(b)(1)(A) or (C). Section 3022(b)(1)(A)
states, in relevant part, that OIG may investigate any claim that a
health information technology developer of certified health information
technology or other entity offering certified health information
technology engaged in information blocking.
We believe it is reasonable to interpret these sections together to
mean that the information blocking provision extends to individuals or
entities that develop or offer certified health IT. That the individual
or entity must develop or offer certified health IT, we explained, is
further supported by section 3022(a)(7) of the PHSA--which refers to
developers' responsibilities to meet the requirements of
certification--and section 4002 of the Cures Act--which identifies
information blocking as a Condition of Certification. Consistent with
this, we proposed a definition of ``health IT developer of certified
health IT'' in Sec. 171.102 (84 FR 7601) and an interpretation of the
use of ``health information technology developer'' in section 3022 of
the PHSA that would apply to part 171 only, and would not apply (84 FR
7511) to the implementation of any other section of the PHSA \122\ or
the Cures Act, such as section 4005(c)(1) of the Cures Act.
---------------------------------------------------------------------------
\122\ Because part 171 is referenced by part 170 subpart D, the
definition and interpretation are relevant to developers'
obligations to meet Condition and Maintenance of Certification
Requirements.
---------------------------------------------------------------------------
Limiting the Definition of Health IT Developer to Developers of
Certified Health IT
Comments. A number of commenters suggested broadening the
definition of ``health IT developers'' to include all developers of
health IT, whether or not any of their products include Health IT
Module(s) certified under ONC's Health IT Certification Program.
Several of these commenters expressed concern that developers of only
non-certified health IT would, under our proposed definition, be able
to continue to block patients from accessing or directing their EHI to
third parties of their choice. A majority of these commenters expressed
concerns that an information blocking prohibition limited to developers
who participate in the ONC Health IT Certification Program (also
referred to as ``the Program'') will result in an uneven playing field
for developers who participate in the Program in comparison to those
who do not participate in the Program. Some commenters suggested that
this could motivate developers to avoid or withdraw from the Program.
Response. We believe that ``health information technology
developer'' as used in PHSA section 3022(a)(1)(B) should be interpreted
in light of the specific authority provided to OIG in section
3022(b)(1)(A) and (b)(2). Section (b)(1)(A) states, in relevant part,
that OIG may investigate any claim that a health information technology
developer of certified health information technology or other entity
offering certified health information technology engaged in information
blocking. We recognize that health IT developers that are not
developers of certified health IT could engage in conduct meeting the
definition of information blocking in section 3022(a) of the PHSA.
However, the statute places health IT developers of certified health IT
on different footing than other developers of health IT with respect to
information blocking enforcement. A broader definition of ``health IT
developer'' in Sec. 171.102 would not change the scope or effect of
section 3022(b)(1)(A) and (b)(2) of the PHSA.
We acknowledge that the information blocking provision may change
some health IT developers' assessments of whether participation in the
voluntary ONC Health IT Certification Program is the right decision for
their health IT products and customers. However, we believe the value
certification offers to the health IT developers' customers, such as
health care providers, is substantially enhanced by both the
information blocking provision and the
[[Page 25796]]
enhancements to certification called for in PHSA section 3001(c)(5)(D).
We believe the benefit that certification offers health IT developers'
customers will continue to weigh in favor of the developers obtaining
and maintaining certification of their products. For example, the
Promoting Interoperability Programs (formerly known as the Medicare and
Medicaid EHR Incentive Programs) continue to require use of Certified
EHR Technology (CERHT), which makes certification important for
developers seeking to market certain types of health IT (notably
including, but not limited to, that within the ``Base EHR'' definition
in Sec. 170.102) to eligible clinicians, eligible hospitals, and
critical access hospitals (CAHs).
Comments. Several commenters recommended alternative approaches to
interpreting the Cures Act, to justify broadening the definition of
``health IT developer'' in 45 CFR 171.102 to include all developers of
any products within the definition of ``health information technology''
in section 3000 of the PHSA. These commenters offered a variety of
rationales, including consideration of information that would have been
available to Congress at the time the Cures Act was enacted, as the
basis for inferring that Congress did not intend to limit the scope of
the information blocking provision to developers that participate in
the voluntary ONC Health IT Certification Program. Some commenters
stated the phrasing of the Cures Act's information blocking provision
appeared to exclude health IT developers that do not participate in our
Program and recommended that we address what some comments described as
a potential enforcement gap by broadening the regulatory definition of
``health IT developer'' in 45 CFR 171.102, although they did not
identify a specific statutory basis for closing what their comments
described as a gap or drafting issue in the statute. One commenter
asked that we work with Congress to expand the definition of health IT
developer beyond those with at least one product that is or that
includes at least one Health IT Module certified under the Program.
Response. As explained in the Proposed Rule and in the immediately
preceding response to comments, we believe that ``health information
technology developer'' as used in PHSA section 3022(a)(1)(B) should be
interpreted in light of the specific authority provided to OIG in
section 3022(b)(1)(A) and (b)(2). Our interpretation is that the
individual or entity must develop or offer certified health IT to be
considered a health IT developer covered by the information blocking
provision, which is further supported by PHSA sections 3022(a)(7) and
3001(c)(5)(D). Section 3022(a)(7) refers to developers'
responsibilities to meet the requirements of certification, and section
3001(c)(5)(D) identifies as a Condition of Certification that a health
IT developer not engage in information blocking. Moreover, PHSA Sec.
3022 does not specifically address all of the types of individuals and
entities (such as health plans and claims data clearinghouses) that
could or currently do engage in practices that might otherwise meet the
definition of information blocking in PHSA Sec. 3022(a).
Applicability of Information Blocking Provision to Non-Certified Health
IT Products of a Developer of Certified Health IT
Comments. On the whole, the majority of comments supported defining
``health IT developer'' in a manner that includes all health IT
products developed or offered by developers who have at least one
Health IT Module certified under the Program. However, multiple
comments, predominantly from the perspective of developers of certified
health IT, recommended that we limit the definition of ``health IT
developers of certified health IT'' in Sec. 171.102 so that it would
encompass only the developers' conduct specific to their certified
health IT products. Commenters advocating this more limited definition
stated that these developers' non-certified health IT products would be
competing against similar products of developers who are not subject to
the information blocking provision.
Response. The Cures Act does not prescribe that only practices
involving certified health IT may implicate PHSA section 3022(a). If
Congress had intended to limit the application of section 3022 of the
PHSA to practices involving certified health IT, we believe PHSA
section 3022 would have included language that tied enforcement of that
section to the operation or performance of health IT products that
include one or more Health IT Module(s) certified under the Program.
Instead, PHSA section 3022(b)(1)(A) provides that the HHS Inspector
General may investigate under PHSA section 3022 any claim that ``a
health information technology developer of certified health information
technology or other entity offering certified health information
technology--submitted a false attestation under section
3001(c)(5)(D)(vii); or engaged in information blocking.'' Similarly,
neither subparagraph (B) of PHSA section 3022(b)(1), specific to claims
that a health care provider engaged in information blocking, nor
subparagraph (C), specific to claims that health information exchanges
(HIEs) or health information networks (HINs) engaged in information
blocking, includes language limiting the Inspector General to
investigating claims tied to these actors' use of certified health IT.
Moreover, our observation is that the customers of health IT
developers of certified health IT seldom, if ever, rely solely on
Health IT Modules certified under the Program to meet their needs to
access, exchange, and use EHI. A developer's health IT product suite
that a hospital, clinician office practice, or other health care
provider uses (and colloquially references) as its ``EHR system'' will
typically include a wide variety of functions, services, components,
and combinations thereof. Even where such a health IT product suite
meets the definition of ``Certified EHR Technology'' for purposes of
participation in the Promoting Interoperability Programs, there is no
guarantee that every part of the overall product suite will meet the
requirements of at least one certification criterion adopted by the
Secretary. In fact, typically only a subset of the functions, services,
components, and combinations thereof within the overall product suite
will meet the requirements of at least one certification criterion
adopted by the Secretary and be Health IT Modules certified under the
Program.
If we were to interpret the information blocking provision as
applying only to the certified Health IT Modules within a developer's
product suite(s), we are concerned the developers' customers might too
easily presume, based on the developer's participation in the ONC
Health IT Certification Program, that the developer will not engage in
information blocking with respect to any of the EHI that the customer
uses of the developer's product suite(s) to access, exchange, or use.
Moreover, limiting our definition of ``health IT developer of certified
health IT'' for purposes of part 171 to only the subset of an
individual or entity's products that are, or that specifically include,
Health IT Modules certified under our Program could encourage
developers to split various functions, services, or combinations
thereof into multiple products so that they could more easily or
broadly avoid accountability for engaging in practices otherwise
meeting the definition of information blocking in Sec. 171.103 with
respect to various pieces of their product suite(s) rather than
[[Page 25797]]
composing products in response to customers' needs and preferences.
We do not believe this outcome would be in the best interest of
patients, health care providers, or other customers of health IT
developers of certified health IT. Thus, while acknowledging that our
definition of ``health IT developer of certified health IT'' in
specific may, like the information blocking provision in general,
change some health IT developers' assessments of whether participation
in the voluntary ONC Health IT Certification Program is the right
decision for their health IT products and customers, we believe the
definition we have finalized offers necessary assurance to purchasers
and users that a health IT developer that has chosen to participate in
the Program can be held accountable under part 170 subpart D and under
part 171 should that developer also engage in any conduct meeting the
definition of information blocking in Sec. 171.103.
Duration of Health IT Developer of Certified Health IT Status
We proposed that ``health IT developer of certified health IT''
would mean an individual or entity that develops or offers health
information technology (as that term is defined in 42 U.S.C. 300jj(5))
and which had, at the time it engaged in a practice that is the subject
of an information blocking claim, health information technology (one or
more) certified under the ONC Health IT Certification Program. We
proposed (84 FR 7511) that the term ``information blocking claim''
within this definition should be read broadly to encompass any
statement of information blocking or potential information blocking. We
also noted in the Proposed Rule that ``claims'' of information blocking
within this definition would not be limited, in any way, to a specific
form, format, or submission approach or process.
We stated in the Proposed Rule that we were also considering
additional approaches to help ensure developers and offerors of
certified health IT remain subject to the information blocking
provision for an appropriate period of time after leaving the Program.
While encouraging commenters to identify alternative approaches for
identifying when a developer or offeror should, and when they should no
longer, be subject to the information blocking provision, we requested
comment on whether one of two specific approaches would best achieve
our policy goal of ensuring that health IT developers of certified
health IT will face consequences under the information blocking
provision if they engage in information blocking in connection with EHI
that was stored or controlled by the developer or offeror while they
were participating in the Program. One such approach would have defined
``health IT developer of certified health IT'' as including developers
and offerors of certified health IT that continue to store EHI that was
previously stored in health IT certified in the Program. The other
would have continued to define a developer or offeror of health IT as a
``health IT developer of certified health IT'' for purposes of part 171
for an appropriate period of time, such as one year, after the
developer or offeror left the Program (no longer had any Health IT
Modules certified under part 170).
Comments. We received several comments in support of defining
``health IT developer of certified health IT'' in a way that would
include developers and offerors who have left the Program so long as
they continue to store or control EHI that had been stored in or by
their health IT products while the products were, or included one or
more, Health IT Module(s) certified in the Program. We also received
several comments recommending developers of certified health IT remain
subject to the information blocking provision for a period of time
after leaving the Program. A couple of commenters recommended a hybrid
approach that would include individuals and entities in the definition
of ``health IT developer of certified health IT'' while they continue
to store EHI that had been stored in certified health IT or for a
reasonable period of time after they ceased participating in the
Program, whichever is longer.
One reason commenters stated in support of extending the definition
of ``health IT developer of certified health IT'' beyond the time a
developer ceased participating in the program was that in commenters'
view this could help former customers access the EHI that the customers
need to provide the best care for patients and that they had contracted
with a developer to manage while the developer had certified health IT.
Some commenters stated that the need for customers to ensure their
contracts with Program-participating developers include provisions for
retrieval of the EHI upon termination or conclusion of the contract
would be eliminated if the period of time during which the ``health IT
developer of certified health IT'' definition applied extended beyond
the date a developer leaves the Program. Other comments recommended
against developers remaining subject to the information blocking
provision after leaving the Program, citing concerns such as burden.
Response. We thank commenters for their feedback. We have finalized
in Sec. 171.102 that a ``health IT developer of certified health IT''
for purposes of part 171 means an individual or entity, other than a
health care provider that self-develops health IT for its own use, that
develops or offers health information technology (as that term is
defined in 42 U.S.C. 300jj(5)) and which has, at the time it engages in
a practice that is the subject of an information blocking claim, one or
more Health IT Modules certified under a program for the voluntary
certification of health information technology that is kept or
recognized by the National Coordinator pursuant to 42 U.S.C. 300jj-
11(c)(5) (ONC Health IT Certification Program). This definition will
ensure conduct a developer or offeror engages in while it has any
health IT product certified under the Program will be within the
definition of ``health IT developer of certified health IT'' for
purposes of part 171.
We have not extended the definition of ``health IT developer of
certified health IT'' beyond the date on which a developer or offeror
no longer has any health IT certified under the Program. It may be that
extending duration of ``health IT developer of certified health IT''
status beyond the date on which a developer or offeror stops
participating in the Program could help motivate such a developer or
offeror to better support transfers of EHI in their custody if their
customers choose to switch products because of the developer's
withdrawal from the Program. However, we believe that ensuring
continuity of access to patients' EHI is an essential consideration in
the process of selecting and contracting for health IT. All transitions
between different health IT products will require transfer of EHI
between those products. Planning for this transfer is, as a practical
matter, integral to a successful transition between products that
ensures continuity of access to EHI essential to safe, well-coordinated
patient care. We are not persuaded that any of the alternative
approaches to duration of ``health IT developers of certified health
IT'' status could eliminate the need for health care providers and
other customers of ``health IT developers of certified health IT'' to
ensure their health IT planning and contracting provides for
appropriate transfer(s) of data at the conclusion or termination of any
particular contract.
We also note that in the market for certified Health IT Modules
today, many of the customers of health IT developers
[[Page 25798]]
or offerors are HIPAA-covered entities (such as health care providers)
or HIPAA business associates (BAs) (such as health information
exchanges or clinical data registries) with whom covered entities
contract for particular services. In such cases, the HIPAA Rules
generally require that a HIPAA covered entity (or BA) enter into a
business associate agreement (BAA) that requires that the BA (or
subcontractor BA) return or destroy the PHI after the termination of
its service as a BA (or subcontractor BA). Because a contract for
health IT products or services, and any associated BAA, could extend
beyond a developer or offeror's departure from the ONC Health IT
Certification Program, we believe such contracts and agreements provide
an appropriate mechanism for customers to guard against a health IT
developer or offeror who has left the Program refusing to relinquish
EHI. We note further that limiting the definition of ``health IT
developer of certified health IT'' to the time period during which the
individual or entity has at least one Health IT Module certified under
the Program would not require claims of information blocking to come to
our attention during that same period. We have finalized the definition
as proposed, with modification to its wording that is discussed below.
Comments. A commenter suggested that the definition of
``information blocking claim'' should not include any ``potential
information blocking,'' but instead should be evaluated with facts and
evidence necessary to support a verifiable claim.
Response. We did not propose to define in regulation ``information
blocking claim.'' We did note in the preamble to the Proposed Rule that
for purposes of the definition of ``health IT developer of certified
health IT'' proposed in Sec. 171.102, claims of information blocking
would not be limited, in any way, to a specific form, format, or
submission process (84 FR 7511). In the definition of ``health IT
developer of certified health IT'' finalized in Sec. 171.102, we have
retained reference to the time at which the individual or entity that
develops or offers certified health IT engages in a practice that is
the subject of an information blocking claim so that it is immediately
clear on the face of the regulation text that the claim need not be
brought while the developer still has certified health IT. If a health
IT developer of certified health IT engages in a practice that is
within the definition of information blocking in Sec. 171.103 while
they remain in the Program, that health IT developer cannot avoid
applicability of the information blocking provision to those practices
by simply leaving the Program before any claim(s) about the practice
may come to light. Our reference to claims of information blocking in
the finalized definition of ``health IT developer of certified health
IT'' is not intended to imply that any actor whose conduct is the
subject of a claim of information blocking that is received by HHS
necessarily will be found to have engaged in conduct meeting the
definition of information blocking in Sec. 171.103 or that is
otherwise contrary to requirements of the ONC Health IT Certification
Program (such as the Condition and Maintenance of Certification
requirements established in subpart D of part 170).\123\ If subject to
an investigation, each practice that implicates the information
blocking provision and does not meet an exception would be analyzed on
a case-by-case basis to evaluate, for example, whether it rises to the
level of an interference, and whether the actor acted with the
requisite intent.
---------------------------------------------------------------------------
\123\ Section 3022(b) of the PHSA authorizes the HHS Office of
the Inspector General to investigate claims of information blocking.
Simultaneously, ONC has responsibility for assessing developers'
compliance with requirements of the ONC Health IT Certification
Program. Coordination between ONC and OIG in our respective roles is
discussed in section VII.D.3 of this preamble.
---------------------------------------------------------------------------
Developers and Offerors of Certified Health IT
We stated in the proposed rule that within the definition of
``health IT developer of certified health IT'' for purposes of part
171, we interpret an ``individual or entity that develops the certified
health IT'' as the individual or entity that is legally responsible for
the certification status of the health IT, which would be the
individual or entity that entered into a binding agreement that
resulted in the certification status of the health IT under the Program
or, if such rights are transferred, the individual or entity that holds
the rights to the certified health IT (84 FR 7511). We also stated that
an ``individual or entity that offers certified health IT'' would
include an individual or entity that under any arrangement makes
certified health IT available for purchase or license. We requested
comment on both of these interpretations, and whether there are
particular types of arrangements under which certified health IT is
``offered'' in which the offeror should not be considered a ``health IT
developer of certified health IT'' for the purposes of the information
blocking provision.
Comments. Several comments questioned the inclusion of offerors of
certified health IT who do not themselves develop the health IT in the
definition of ``health IT developer of certified health IT.'' Some
commenters recommended the exclusion of offerors who do not modify or
configure the health IT in question. Some commenters advocated treating
entities that include other developers' certified health IT in the
health IT products or services they offer, but do not themselves
develop certified health IT, as being outside the definition of
``health IT developer of certified health IT.'' Commenters stated that
these offerors do not themselves develop the certified health IT and
thus do not control its design. Commenters also stated that the
products offered by some of these offerors (such as clinical data
registries which may be certified to clinical quality measurement and
measure reporting criteria) are not primary sources of patients' EHI,
and that offerors of health IT that is not a primary source of EHI
should be excluded from the definition of health IT developer of
certified health IT. One commenter specifically recommended excluding
from the definition individuals and entities that offer under their own
brand, but do not modify or configure, certified health IT developed by
others. These commenters suggested that this is desirable in order to
hold developers accountable for information blocking conduct in the
course of development.
Response. Including both developers and other offerors in the
definition of ``health IT developer of certified health IT'' is
consistent with the policy goal of holding all entities who could, as a
developer or offeror, engage in information blocking accountable for
their practices that are within the definition of information blocking
in Sec. 171.103. PHSA section 3022(b)(1)(A) expressly references both
``a health information technology developer of certified health
information technology'' and ``other entity offering certified health
information technology'' in the context of authority to investigate
claims of information blocking. As stated in the Proposed Rule (84 FR
7510), we interpret PHSA section 3022(a)(1)(B) in light of the specific
authority provided to OIG in PHSA section 3022(b)(1)(A) and (b)(2).
We interpret these sections together as the basis for applicability
of the information blocking provision to individuals or entities that
develop or offer certified health IT. We refer commenters concerned
about holding offerors that do not develop, modify, or configure health
IT accountable for the conduct of others to PHSA section 3022(a)(6),
which states that the term ``information blocking,'' with respect to
[[Page 25799]]
an individual or entity, shall not include an act or practice other
than an act or practice committed by such individual or entity. Where
the individual or entity that develops health IT is different from the
individual or entity that offers certified health IT, each such
individual or entity would have the potential to engage in various
practices within the definition of information blocking in PHSA section
3022(a) and 45 CFR 171.103, and we believe each should be accountable
for their own conduct. Actors who are not primary generators of EHI or
who may hold only a few data classes or elements for any given patient
(as would be the case for examples specifically cited by commenters),
could nevertheless engage in conduct that constitutes information
blocking as defined in Sec. 171.103 with respect to that EHI they do
hold or control. We therefore see no reason to exclude them from the
definition of health IT developer of certified health IT. To do so
would not be consistent with the policy goal of addressing the problem
of information blocking.
Comments. Several commenters recommended that public health
agencies that develop and/or offer health IT products and services,
such as those related to syndromic surveillance and immunization
registries, be excluded from the definition of health IT developer in
Sec. 171.102.
Response. We believe the vast majority of public health agencies
would remain outside of our definition of ``health IT developer of
certified health IT'' finalized in Sec. 171.102. The ``public health''
certification criteria within the ONC Health IT Certification Program
are applicable to the health IT that health care providers would use to
exchange information with public health information infrastructure.
These criteria are not applicable to the public health information
reporting or exchange infrastructure itself.
Treatment of ``Self-Developers'' of Certified Health IT
We stated in the proposed rule (84 FR 7511) that a ``self-
developer'' of certified health IT, as the term has been used in the
ONC Health IT Certification Program (Program) and described in section
VII.D.7 of the Proposed Rule (84 FR 7507), section VII.D.7 of this
preamble, and previous rulemaking,\124\ would be treated as a health
care provider for the purposes of information blocking because our
description of a self-developer for Program purposes \125\ would mean
that they would not be supplying or offering their certified health IT
to other entities (84 FR 7511 and 7512). We stated in the Proposed Rule
that self-developers would still be subject to the proposed Conditions
and Maintenance of Certification requirements because they have health
IT certified under the Program (see also section VII.D.7 of the
Proposed Rule (84 FR 7507) and section VII.D.7 of this preamble). We
requested comments on our treatment of ``self-developers'' for
information blocking purposes and whether there are other factors we
should consider.
---------------------------------------------------------------------------
\124\ The final rule establishing ONC's Permanent Certification
Program, ``Establishment of the Permanent Certification for Health
Information'' (76 FR 1261), addresses self-developers.
\125\ The language in the final rule establishing ONC's
Permanent Certification Program describes the concept of ``self-
developed'' as referring to a complete EHR or EHR Module designed,
created, or modified by an entity that assumed the total costs for
testing and certification and that will be the primary user of the
health IT (76 FR 1300).
---------------------------------------------------------------------------
Comments. A number of comments expressed support of treating
``self-developer'' health care providers who do not supply or offer
their certified health IT to other entities as health care providers
for purposes of information blocking.
Response. We appreciate commenters' input. The definition of
``health IT developer of certified health IT'' that we have finalized
in Sec. 171.102 expressly excludes health care providers who self-
develop health IT for their own use. However, we remind health care
providers who may be considering or are embarking on self-development
of certified Health IT Modules that ``self-developers'' are subject to
certain Condition and Maintenance of Certification requirements
finalized in subpart D of part 170. These requirements include, though
they are not limited to, providing assurances and attestations that
they will not, have not, and do not engage in conduct constituting
information blocking.
For purposes of the definition of ``health IT developer of
certified health IT,'' we interpret ``a health care provider that self-
develops health IT for its own use'' to mean that the health care
provider is responsible for the certification status of the Health IT
Module(s) and is the primary user of the Health IT Module(s). Moreover,
we interpret ``a health care provider that self-develops health IT for
its own use'' to mean that the health care provider does not offer the
health IT to other entities on a commercial basis or otherwise. This
interpretation rests on our established concept of ``self-developed''
certified Health IT Modules. In this context, it is important to note
that some use of a self-developer's health IT may be made accessible to
individuals or entities other than the self-developer and its employees
without that availability being interpreted as offering or supplying
the health IT to other entities in a manner inconsistent with the
concept of ``self-developer.'' For example, if a hospital were to self-
develop an EHR system, we would not consider inclusion in that system
of certain functionalities or features--such as APIs or patient
portals--to be offering or supplying the hospital's self-developed
health IT to other entities. We would also not interpret as offering or
supplying the self-developed health IT to other entities the issuance
of login credentials allowing licensed health care professionals who
are in independent practice to use the hospital's EHR to furnish and
document care to patients in the hospital. Keeping in the hospital's
EHR a comprehensive record of a patient's care during an admission is a
practice we view as reasonable and it typically requires that all the
professionals who furnish care to patients in the hospital be able to
use the hospital's EHR system. It is also customary practice amongst
hospitals that purchase commercially marketed health IT, as well as
those that self-develop their health IT, to enable health care
professionals in independent practice who furnish care in the hospital
to use the EHR in connection to furnishing and documenting that care.
Clinician portals made available to facilitate independent licensed
health care professionals furnishing and/or documenting care to
patients in the hospital would also not be interpreted as negating the
hospital's ``self-developer'' status. However, if a health care
provider responsible for the certification status of any Health IT
Module(s) were to offer or supply those Health IT Module(s), separately
or integrated into a larger product or software suite, to other
entities for those entities' use in their own independent operations,
that would be inconsistent with the concept of the health care provider
self-developing health IT for its own use.
In deciding to exclude health care providers who self-develop
health IT for their own use from the definition of ``health IT
developer of certified health IT'' finalized in Sec. 171.102, we rely
substantially on our Program experience that self-developed certified
health IT currently represents a small, and diminishing, share of the
Health IT Modules certified under our Program. We also note that we may
consider amending this definition in future
[[Page 25800]]
rulemaking in response to changing market conditions. For example, the
market might evolve in ways that would increase risk of abuse of this
exclusion of health care providers who self-develop certified health IT
from the application of the Sec. 171.103 definition of ``information
blocking'' to their conduct as a developer of health IT. In such
circumstances, we might contemplate appropriate revisions to the
definition of ``health IT developer of certified health IT'' for
purposes of part 171.
Summary of Finalized Policy: Definition of Health IT Developer of
Certified Health IT
In Sec. 171.102, we have finalized that ``health IT developer of
certified health IT'' means an individual or entity, other than a
health care provider that self-develops health IT for its own use, that
develops or offers health information technology (as that term is
defined in 42 U.S.C. 300jj(5)) and which has, at the time it engages in
a practice that is the subject of an information blocking claim, one or
more Health IT Modules certified under a program for the voluntary
certification of health information technology that is kept or
recognized by the National Coordinator pursuant to 42 U.S.C. 300jj-
11(c)(5) (ONC Health IT Certification Program). This is substantially
the definition we proposed (84 FR 7601), but with minor modifications
to its text.
We have added to this finalized definition ``other than a health
care provider that self-develops health IT for its own use,'' so that
this feature of the proposed definition which we stated in the Proposed
Rule's preamble (84 FR 7511) is immediately clear on the face of the
regulation text itself. We also replaced the proposed phrasing ``health
information technology (one or more) certified'' (84 FR 7601) with
``one or more Health IT Modules certified'' because it is more
consistent with our Program terminology. We also replaced ``under the
ONC Health IT Certification Program'' from the proposed phrasing with
the finalized ``under a program for the voluntary certification of
health information technology that is kept or recognized by the
National Coordinator pursuant to 42 U.S.C. 300jj-11(c)(5) (ONC Health
IT Certification Program).'' Currently, we keep a single Program that
we refer to as the ONC Health IT Certification Program. For purposes of
precision, we decided to refer to the statutory basis for the Program,
and indicate parenthetically the manner in which we currently reference
it.
We interpret ``individual or entity that develops'' certified
health IT as the individual or entity that is legally responsible for
the certification status of the health IT, which would be the
individual or entity that entered into a binding agreement that
resulted in the certification status of the health IT under the Program
or, if such rights are transferred, the individual or entity that holds
the rights to the certified health IT. As we clarified in the final
rule ``ONC Health IT Certification Program: Enhanced Oversight and
Accountability'' (81 FR 72404), the consequences under 45 CFR part 170
for a developer's having had one or more of its products' certification
terminated apply to developers, their subsidiaries, and their
successors (81 FR 72443).
For purposes of part 171 and the information blocking provision, we
interpret an entity that has health IT to include not only the entity
that entered into a binding agreement that resulted in the
certification status of the health IT under the Program, but also its
subsidiaries, and its successors. The facts and circumstances of a
particular case may determine which individual(s) or entity (or
entities) are culpable and whether enforcement against particular
individual(s), the developer entity, a successor in rights to the
health IT, the developer or successor's subsidiary, or a parent entity
will be pursued. Similarly, use of the word ``individual'' in this
context does not limit responsibility for practices of an entity that
develops or offers health IT to the particular natural person(s) who
may have signed binding agreement(s) that resulted in the certification
status of the health IT under the Program. Depending on the nature of
the organization, the person who signs the binding agreement that
results in the certification status may be different from the person
who determines the fees, the person who implements the health IT, and
the person who sets the overall business strategy for the company. The
facts and circumstances of each case may determine who the culpable
individual or individual(s) are and whether enforcement against the
entity or against specific individual(s) will be pursued.
As stated in the Proposed Rule, for purposes of this definition, a
developer or offeror of a single certified health IT product that has
had its certification suspended will still be considered to have
certified health IT (84 FR 7511).
c. Health Information Networks and Health Information Exchanges
The terms ``network'' and ``exchange'' are not defined in the
information blocking provision or in any other relevant statutory
provisions. We proposed to define these terms in a way that does not
assume the application or use of certain technologies and is flexible
enough to apply to the full range and diversity of exchanges and
networks that exist today and that may arise in the future.
We stated that in considering the most appropriate way to define
these terms, we examined how they are used throughout the Cures Act and
the HITECH Act. Additionally, we considered dictionary and industry
definitions of ``network'' and ``exchange.'' While the terms have
varied usage and meaning in different industry contexts, we noted that
certain concepts are common and were incorporated into the proposed
definitions.
Health Information Network
We proposed a functional definition of ``health information
network'' (HIN) that focused on the role of these actors in the health
information ecosystem. We stated that the defining attribute of a HIN
is that it enables, facilitates, or controls the movement of
information between or among different individuals or entities that are
unaffiliated. Therefore, we proposed that two parties are affiliated if
one has the power to control the other, or if both parties are under
the common control or ownership of a common owner. We noted that a
significant implication of the definition is that a health care
provider or other entity that enables, facilitates, or controls the
movement of EHI within its own organization, or between or among its
affiliated entities, is not a HIN in connection with that movement of
information for the purposes of the HIN definition.
We proposed that an actor could be considered a HIN if it performs
any one or any combination of the following activities. First, the
actor would be a HIN if it were to determine, oversee, administer,
control, or substantially influence policies or agreements that define
the business, operational, technical, or other conditions or
requirements that enable or facilitate the access, exchange, or use of
EHI between or among two or more unaffiliated individuals or entities.
Second, an actor would be a HIN if it were to provide, manage, control,
or substantially influence any technology or service that enables or
facilitates the access, exchange, or use of EHI between or among two or
more unaffiliated individuals or entities.
We noted that, typically, a HIN will influence the sharing of EHI
between many unaffiliated individuals or entities. However, we did not
propose to establish any minimum number of
[[Page 25801]]
parties or ``nodes'' beyond the requirement that there be some actual
or contemplated access, exchange, or use of information between or
among at least two unaffiliated individuals or entities that is
enabled, facilitated, or controlled by the HIN. We stated that any
further limitation would be artificial and would not capture the full
range of entities that should be considered networks under the
information blocking provision. We clarified that any individual or
entity that enables, facilitates, or controls the access, exchange, or
use of EHI between or among only itself and another unaffiliated
individual or entity would not be considered a HIN in connection with
the movement of that EHI (although that movement of EHI may still be
regulated under the information blocking provision on the basis that
the individual or entity is a health care provider or health IT
developer of certified health IT). To be a HIN, we emphasized that the
individual or entity would need to be enabling, facilitating, or
controlling the access, exchange, or use of EHI between or among two or
more other individuals or entities that were not affiliated with it.
We provided multiple examples to illustrate how the proposed
definition would operate. An entity is established within a state for
the purpose of improving the movement of EHI between the health care
providers operating in that state. The entity identifies standards
relating to security and offers terms and conditions to be entered into
by health care providers wishing to participate in the network. The
entity offering (and then overseeing and administering) the terms and
conditions for participation in the network would be considered a HIN
for the purpose of the information blocking provision. We noted that
there is no need for a separate entity to be created in order for that
entity to be considered a HIN. To illustrate, we stated that a health
system that ``administers'' business and operational agreements for
facilitating the exchange of EHI that are adhered to by unaffiliated
family practices and specialist clinicians in order to streamline
referrals between those practices and specialists would likely be
considered a HIN.
We noted that the proposed definition would also encompass an
individual or entity that does not directly enable, facilitate, or
control the movement of information, but nonetheless exercises control
or substantial influence over the policies, technology, or services of
a network. In particular, we stated that there may be an individual or
entity that relies on another entity--such as an entity specifically
created for the purpose of managing a network--for policies and
technology, but nevertheless dictates the movement of EHI over that
network. As an example, a large health care provider could decide to
lead an effort to establish a network that facilitates the movement of
EHI between a group of smaller health care providers (as well as the
large health care provider) and through the technology of health IT
developers. To achieve this outcome, the large health care provider,
together with some of the participants, could create a new entity that
administers the network's policies and technology.
In this scenario, we noted that the large health care provider
would come within the functional definition of a HIN and could be held
accountable for the conduct of the network if the large health care
provider used its control or substantial influence over the new
entity--either in a legal sense, such as via its control over the
governance or management of the entity, or in a less formal sense, such
as if the large health care provider prescribed a policy to be
adopted--to interfere with the access, exchange, or use of EHI. We
clarified that the large health care provider in this example would be
treated as a health care provider when utilizing the network to move
EHI via the network's policies, technology, or services, but would be
considered a HIN in connection with the practices of the network over
which the large health care provider exercises control or substantial
influence.
We sought comment on the proposed definition of a HIN. In
particular, we requested comment on whether the proposed definition was
broad enough (or too broad) to cover the full range of individuals and
entities that could be considered HINs within the meaning of the
information blocking provision. Additionally, we specifically requested
comment on whether the proposed definition would effectuate our policy
goal of defining this term in a way that does not assume particular
technologies or arrangements and was flexible enough to accommodate
changes in these and other conditions.
We note that we summarize and respond to the comments received on
the HIN definition below with the comments received on the health
information exchange definition (HIE) due to the overlap in the
comments received and our responses.
Health Information Exchange
We proposed to define a ``health information exchange'' (HIE) as an
individual or entity that enables access, exchange, or use of EHI
primarily between or among a particular class of individuals or
entities or for a limited set of purposes. We noted that our research
and experience in working with exchanges drove the proposed definition
of this term. We stated that HIEs would include, but were not limited
to, regional health information organizations (RHIOs), State health
information exchanges (State HIEs), and other types of organizations,
entities, or arrangements that enable EHI to be accessed, exchanged, or
used between or among particular types of parties or for particular
purposes. As an example, we noted an HIE might facilitate or enable the
access, exchange, or use of EHI exclusively within a regional area
(such as a RHIO), or for a limited scope of participants and purposes
(such as a clinical data registry or an exchange established by a
hospital-physician organization to facilitate Admission, Discharge, and
Transfer (ADT) alerting). We further noted that HIEs may be established
under Federal or State laws or regulations but may also be established
for specific health care or business purposes or use cases. We also
mentioned that if an HIE facilitates the access, exchange, or use of
EHI for more than a narrowly defined set of purposes, then it may be
both an HIE and a HIN.
We sought comment on the proposed HIE definition and encouraged
commenters to consider whether the proposed definition was broad enough
(or too broad) to cover the full range of individuals and entities that
could be considered exchanges within the meaning of the information
blocking provision, and whether the proposed definition was
sufficiently flexible to accommodate changing technological and other
conditions.
Comments on the HIN and HIE Definitions
As mentioned above, we received substantially similar comments on
both proposed definitions. Based on those comments and our approach to
the final definition for these terms, we have combined our comment
summary and response for the proposed definitions.
Comments. Many commenters suggested that the definitions of HIN and
HIE should be combined because confusion could arise in trying to
distinguish between the two terms. Commenters asserted that these
definitions are used to describe entities that perform the same or
similar functions. Some commenters expressed support for the broad
functional definitions of HIE and HIN, while others expressed concern
that many organizations could be unintentionally
[[Page 25802]]
covered by the proposed definitions due to the broad scope of the
definitions as proposed.
Many commenters suggested excluding certain individuals and
entities from the HIE and/or HIN definitions, while other commenters
noted such an approach could significantly limit the application of the
information blocking provision. Proposed exclusions offered by
commenters included, but were not limited to: Health plans, payers,
health care providers, business associates, accountable care
organizations, health care clearinghouses, public health agencies,
research organizations, clinical data registries, certified health
information technology providers, software developers, mobile app
providers, cloud storage vendors, internet service providers, and
patient or consumer focused social media.
Some commenters suggested limiting the types of activities and/or
the purposes for those activities that might be necessary to be
considered a HIN or HIE.
Commenters also raised concerns with particular language in the
proposed HIN definition, noting that the term ``substantially
influences'' was vague and that we should remove ``individual'' from
the definitions as commenters could not foresee an individual acting as
a HIN or HIE.
Response. The definitions of HIN and HIE in the Proposed Rule
achieved a key goal which was to solicit feedback from a wide array of
stakeholders that might be considered HINs or HIEs under the proposed
definition, including on whether the definitions were too broad or not
broad enough. We have adopted a modified definition in this final rule
to address much of the feedback without expressly excluding any
specific type of entity, which we believe would be unwieldy to
appropriately administer and, more importantly, in conflict with our
overarching approach to include any individual or entity that performs
certain functional activities as outlined in the Proposed Rule.
Foremost, in this final rule, we are combining the definitions of
HIN and HIE to create one functional definition that applies to both
statutory terms in order to clarify the types of individuals and
entities that would be covered. This approach is consistent with
statements we made in the Proposed Rule noting that a HIE could also be
an HIN. In addition, section 3022 of the PHSA often groups these two
terms together, and as we noted previously, does not define them. This
approach will also eliminate stakeholder confusion as expressed by
commenters and respond to commenters who asserted the terms refer to
entities performing the same function. To this point, we have found
numerous associations and publications referring to entities that
perform the same or similar functions that we have specified in the
HIN/HIE definition as HINs, HIEs, and regional health information
organizations (RHIOs).\126\ We have finalized under Sec. 171.102 that
a health information network or health information exchange means an
individual or entity that determines, controls, or has the discretion
to administer any requirement, policy, or agreement that permits,
enables, or requires the use of any technology or services for access,
exchange, or use of EHI: (1) Among more than two unaffiliated
individuals or entities (other than the individual or entity to which
this definition might apply) that are enabled to exchange with each
other; and (2) that is for a treatment, payment, or health care
operations purpose, as such terms are defined in 45 CFR 164.501
regardless of whether such individuals or entities are subject to the
requirements of 45 CFR parts 160 and 164.
---------------------------------------------------------------------------
\126\ See HIMSS FAQ, Health Information Exchange: A catch-all
phrase for all health information exchange, including Regional
Health Information Organizations (RHIOs), Quality Information
Organizations (QIOs), Agency for Healthcare Research and Quality
(AHRQ)-funded communities and private exchanges, https://protect2.fireeye.com/url?k=7d5b6f82-210e6652-7d5b5ebd-0cc47a6a52de-fe4abdcde0e54deb&u=https://www.himss.org/library/health-information-exchange/FAQ; AHIMA, ``An HIE is the electronic movement of health-
related information among organizations according to nationally
recognized standards. HIE is also sometimes referred to as a health
information network (HIN)'', http://bok.ahima.org/PdfView?oid=104129; SHIEC Member List, SHIEC is the trade
association of HIEs, called the Strategic Health Information
Exchange collaborative, which has 17 members with ``network'' in
their name, https://protect2.fireeye.com/url?k=f84ddacd-a418d31d-f84debf2-0cc47a6a52de-8424832df6e921dc&u=https://strategichie.com/membership/member-list/.
---------------------------------------------------------------------------
In consideration of comments, we also narrowed the definition in
three ways. First, the types of actions (e.g., manages or facilitates)
that would be necessary for an actor to meet the definition of HIN or
HIE were reduced. This includes removing the ``substantially
influences'' element of the proposed definition of HIN to address
concerns about possible ambiguity. Second, we have revised the
definition to specify that to be a HIN or HIE there must be exchange
among more than two unaffiliated individuals or entities besides the
HIN/HIE that are enabled to exchange with each other. This revision
ensures that the definition does not unintentionally cover what are
essentially bilateral exchanges in which the intermediary is simply
performing a service on behalf of one entity in providing EHI to
another or multiple entities and no actual exchange is taking place
among all entities (e.g., acting as an intermediary between two
entities where the first sends non-standardized data to be converted by
the intermediary into standardized data for the receiving entity). To
be clear, to be enabled, the parties must have the ability and
discretion to exchange with each other under the policies, agreements,
technology, and/or services. Third, we focused the definition on three
activities: Treatment, payment, and health care operations, as each are
defined in the HIPAA Rules (45 CFR 164.501). The activities described
by the terms treatment, payment and health care operations were
selected for multiple reasons. Many, but not all, individuals and
entities that would meet the definition of HIN/HIE for information
blocking purposes will be familiar with these terms because they
currently function as a covered entity or business associate under the
HIPAA Rules. Last, this approach serves to ensure that certain
unintended individuals and entities are not covered by the definition,
which we discuss in more detail below.
Two important points about the definition require clarification.
First, the reference to the three types of activities does not limit
the application of the HIN/HIE definition to individuals or entities
that are covered entities or business associates (as defined in HIPAA).
For example, if three unaffiliated entities exchanging information were
health care providers that were not HIPAA covered entities, their
exchange of information for treatment purposes through a HIN or HIE
would qualify for this element of the definition even though the HIN/
HIE would not be a business associate to any of the providers. We
expect such situations to be rare, but they may occur. Second, the
three activities serve as elements of the definition such that if an
individual or entity meets them, then the individual or entity would be
considered a HIN/HIE under the information blocking regulations for any
practice they conducted while functioning as a HIN/HIE. To illustrate,
if a HIN/HIE was exchanging EHI on behalf of a health care provider for
treatment purposes, but denied an individual access to their EHI
available in the HIN/HIE, then the HIN/HIE would be considered a HIN/
HIE under the circumstances for the purposes of information blocking.
Having said this, the HIN/HIE may not have ``interfered
[[Page 25803]]
with'' the individual's access to their EHI depending on the terms of
the HIN/HIE's business associate agreements with the participating
covered entities or for other reasons such as the EHI could not be
disclosed by law or the HIN/HIE met an exception under the information
blocking provision. To be clear, the HIN/HIE definition is only
applicable to the circumstances of an information blocking claim. For
example, a health care provider that may have ownership of a HIN/HIE,
would not be considered a HIN/HIE, but instead a ``health care
provider'' with respect to situations that involve their behavior as a
health care provider, such as denying another health care provider's
ability to access, exchange, or use EHI for treatment purposes or
denying an individual's access to their EHI via the health care
provider's patient portal.
With respect to suggestions to exclude specific types of entities,
we believe that the Cures Act goals of supporting greater
interoperability, access, exchange, and use of EHI are best advanced by
a functional definition without specific exclusions. We note, however,
that the narrower definition of HIN/HIE in this final rule should
clearly exclude entities that might have been included under the
proposed definitions, such as social networks, internet service
providers, and technology that solely facilitates the exchange of
information among patients and family members. The definition in this
final rule continues to focus on the functional activity of the
individual or entity in question and not on any title or classification
of the person or entity.
The reference to ``individual'' was maintained in the final rule
because the Cures Act states that penalties apply to any individual or
entity that is a developer, network, or exchange (see section
3022(b)(2)(A) of the PHSA).
3. Electronic Health Information
In the Proposed Rule, we noted that the information blocking
definition applies to electronic health information (EHI) (section
3022(a)(1) of the PHSA). We further noted that while section 3000(4) of
the PHSA by reference to section 1171(4) of the Social Security Act
defines ``health information,'' EHI is not specifically defined in the
Cures Act, PHSA, HITECH Act, or other relevant statutes. Therefore, we
proposed to include the definition of EHI in Sec. 171.102 and define
it to mean (84 FR 7513):
(i) Electronic protected health information; and
(ii) any other information that--
is transmitted by or maintained in electronic media, as
defined in 45 CFR 160.103;
identifies the individual, or with respect to which there
is a reasonable basis to believe the information can be used to
identify the individual; and
relates to the past, present, or future health or
condition of an individual; the provision of health care to an
individual; or the past, present, or future payment for the provision
of health care to an individual (84 FR 7513).
We explained in the Proposed Rule that this definition of EHI
includes, but is not limited to: Electronic protected health
information and health information that is created or received by a
health care provider and those operating on their behalf; health plan;
health care clearinghouse; public health authority; employer; life
insurer; school; or university. In addition, we clarified that under
our proposed definition, EHI includes, but is not limited to,
electronic protected health information (ePHI) as defined in 45 CFR
160.103. We noted that EHI may also be provided, directly from an
individual, or from technology that the individual has elected to use,
to an actor covered by the information blocking provisions. We also
proposed that EHI does not include health information that is de-
identified consistent with the requirements of 45 CFR 164.514(b) (84 FR
7513).
We clarified that the EHI definition provides for an expansive set
of health information, which could include information on an
individual's health insurance eligibility and benefits, billing for
health care services, and payment information for services to be
provided or already provided, which may include price information (84
FR 7513).
We generally requested comment on this proposed definition as well
as on whether the exclusion of health information that is de-identified
consistent with the requirements of 45 CFR 164.514(b). We also sought
comment on the parameters and implications of including price
information within the scope of EHI for purposes of information
blocking (84 FR 7513).
Comments. Some commenters were strongly supportive of the proposed
EHI definition, stating that it covers the breadth of EHI that should
be addressed within the regulation. Conversely, many other commenters,
including health care providers and health IT developers, contended
that the definition was overly broad and vague. They expressed concern
about their ability to know what health information they must make
available for access, exchange, and use for the purposes of complying
with the information blocking provision. Some other commenters posited
that they could be put in a situation of having to separate EHI from
PHI for compliance purposes, noting this would be extremely burdensome.
Many commenters stated simply trying to determine what constitutes EHI
for compliance purposes would be extremely burdensome and costly.
Commenters offered various options for narrowing the scope of the
EHI definition. Many commenters suggested that EHI should only be
electronic protected health information (ePHI) as defined under the
HIPAA Rules. Some of these commenters specifically recommended that the
EHI definition be limited to align with the definition of a designated
record set under HIPAA. A few commenters stated that EHI should be
limited to observational health information as described in the
Proposed Rule (84 FR 7516). Commenters also recommended that the EHI
definition be limited to only standardized health information, with
some commenters recommending that EHI be specifically limited to
information that meets the USCDI standard.
Response. We appreciate the comments and agree that actors should
not have to separate ePHI from EHI in order to comply with both the
HIPAA Rules and the information blocking provision. It is also
important for actors to clearly understand what health information
should be available for access, exchange, and use. To address these
concerns, we have focused the EHI definition at this time on terms that
are used in the HIPAA Rules and that are widely understood in the
health care industry as well as on a set of health information that is
currently collected, maintained, and made available for access,
exchange, and use by actors. By doing so, we believe we have eliminated
any perceived burden and actors will be in a situation that will permit
them to readily and continually comply with the information blocking
provision. While we understand that some commenters supported the EHI
definition as proposed or included alternative definitions in their
comments, we believe that, for the above reasons, the EHI definition we
have codified in regulation through this final rule will enable
effective implementation.
We have defined EHI (Sec. 171.102) to mean electronic protected
health information (ePHI) as the term is defined for HIPAA in 45 CFR
160.103 to the extent that the ePHI would be included in a designated
record set as defined in 45 CFR 164.501 (other than
[[Page 25804]]
psychotherapy notes as defined in 45 CFR 164.501 or information
compiled in reasonable anticipation of, or for use in, a civil,
criminal, or administrative action or proceeding), regardless of
whether the group of records are used or maintained by or for a covered
entity as defined in 45 CFR 160.103. The ePHI definition in 45 CFR
160.103 incorporates the definitions in that section for protected
health information and electronic media. Although the definition of
designated record set refers to records maintained by or for a covered
entity, the EHI definition has been finalized to apply to groups of
records (as they are included in the designated record set) regardless
of whether they are maintained by or for a covered entity (e.g., a
developer of certified health IT, a health information network, a
health information exchange, or even a health care provider that may
not be a covered entity or may not be acting as a business associate of
a covered entity).
We did not focus the EHI definition finalized in this final rule on
observational health information (OHI) as described in the Proposed
Rule (84 FR 7516) for multiple reasons. We did not and cannot not at
this time define OHI concretely. The use of OHI as a definition would
also not align with our above stated goals to provide alignment with
the HIPAA Rules and ease of implementation for actors. We also did not
focus the EHI definition solely on the data identified in the USCDI
standard. We are strong supporters of interoperability and standards-
based access and exchange. To this point, the ONC Health IT
Certification Program (Program) supports standards-based
interoperability through the adoption of standards and the
certification of health IT to those standards. In this respect, we have
made the USCDI a baseline set of data that certified health IT must be
able to make available for access and exchange (see section IV.B.1 of
this preamble). However, this set of EHI is too limiting in terms of
what actors are capable of making available in both the near and long
term as is evident by compliance with HIPAA's right of access
regulatory provision in 45 CFR 164.524.
To be further responsive to commenters expressing compliance
concerns about the EHI definition, we have established a new ``Content
and Manner'' exception in this final rule (Sec. 171.301) that will
provide actors time to adjust to the new information blocking paradigm
and make EHI available for access, exchange, and use. The new exception
permits an actor to provide, at a minimum, a limited set of EHI
comprised of the data elements included in the USCDI for access,
exchange, and use during the first 18 months after the compliance date
of the information blocking provisions (24 months after publication of
this final rule). The data elements represented in the USCDI represent
an even more focused set of data than the finalized EHI definition
(Sec. 171.102). We refer readers to section VIII.D.2.a of this final
rule for further discussion of this new exception.
Comments. Commenters argued both for and against the inclusion of
price information in the EHI definition. Commenters that argued for the
inclusion of price information stated that it was well within the
meaning of the term health information found in the PHSA. Many of these
commenters argued that the availability of this type of information
would be helpful to patients in selecting and obtaining health care.
Commenters also contended that the availability of price information
would increase competition and reduce health care costs. Conversely,
other commenters made various arguments for not including price
information within the definition of EHI. Some of these commenters
asserted that price information was not within the scope of health
information as specified in section 3022 of the PHSA because Congress
did not specifically include it. Commenters also asserted that price
information is too vague and lacks standardization to be clearly
understood and made available for access, exchange, and use. Other
commenters contended that disclosing price information would violate
trade secret laws and would harm competitive pricing by health plans.
Response. The EHI definition codified through this final rule does
not expressly include or exclude price information. However, to the
extent that ePHI includes price information and is included in a
designated record set, it would be considered EHI. This approach is
intended to assure that the current scope of EHI for purposes of
information blocking is aligned with the definitions of ePHI and
designated record set under the HIPAA Rules, with limited exceptions.
Comments. A few commenters specifically questioned whether
algorithms or processes that create EHI, or the clinical interpretation
or relevancy of the results of the algorithms or processes, would be
considered EHI.
Response. The EHI definition codified through this final rule does
not expressly include or exclude algorithms or processes that create
EHI, or the clinical interpretation or relevancy of the results of the
algorithms or processes. However, any such information would be
considered EHI if it was ePHI included in the designated record set
(such as the inclusion of the clinical interpretation of an algorithm's
results in an individual's clinical note). Like with price information,
this approach is intended to ensure that the current scope of EHI for
purposes of information blocking is aligned with the definitions of
ePHI and designated record set under the HIPAA Rules, with limited
exception.
Comments. Many commenters supported the position that health
information which is de-identified in accordance with HIPAA regulations
should not be considered EHI.
Response. We agree that health information that is de-identified
consistent with the requirements of 45 CFR 164.514(b) should not be
included in EHI. It is not, however, necessary to specifically exclude
such de-identified information from the EHI definition because
information that does not identify an individual, and with respect to
which there is no reasonable basis to believe that the information can
be used to identify an individual, is not individually identifiable
information, so it would not be EHI (see 45 CFR 164.514(a)). To note,
once PHI has been de-identified, it is no longer considered to be PHI.
So, such information would not be considered EHI by definition (see 45
CFR 164.514 (b)).
Comments. One commenter viewed the proposed EHI definition as
overly restrictive by requiring EHI to be individually identifiable.
Response. The EHI definition codified through this final rule
retains the core requirement that the health information be
individually identifiable in order to be consistent with HIPAA and
general health care industry practice regarding use and disclosure of
health information.
4. Price Information--Request for Information
In the Proposed Rule, we requested comment on the technical,
operational, legal, cultural, environmental, and other challenges to
creating price transparency within health care, and posed multiple
specific questions for commenters to consider (84 FR 7513 and 7514).
We received over 1,000 comments regarding price information and
price transparency in response to our request, which included
recommendations from the HITAC. We thanks commenters for their comments
and have shared this
[[Page 25805]]
feedback with appropriate Department partners.
5. Interests Promoted by the Information Blocking Provision
a. Access, Exchange, and Use of EHI
We stated in the Proposed Rule that the information blocking
provision promotes the ability to access, exchange, and use EHI,
consistent with the requirements of applicable law. We interpreted the
terms ``access,'' ``exchange,'' and ``use'' broadly, consistent with
their generally understood meaning in the health IT industry and their
function and context in the information blocking provision (84 FR
7514).
We explained in the Proposed Rule that the concepts of access,
exchange, and use are closely related: EHI cannot be used unless it can
be accessed, and this often requires that the EHI be exchanged among
different individuals or entities and through various technological
means. Moreover, the technological and other means necessary to
facilitate appropriate access and exchange of EHI vary significantly
depending on the purpose for which the information will be used. We
stated that this explanation is consistent with the way these terms are
employed in the information blocking provision and in other relevant
statutory provisions. Noting, for example, that section 3022(a)(2) of
the PHSA contemplates a broad range of purposes for which EHI may be
accessed, exchanged, and used--from treatment, care delivery, and other
permitted purposes, to exporting complete information sets and
transitioning between health IT systems, to supporting innovations and
advancements in health information access, exchange, and use.
In addition, we stated in the Proposed Rule that we considered how
the terms access, exchange, and use have been defined or used in
existing regulations and other relevant health IT industry contexts. We
explained that, while those definitions have specialized meanings and
are not controlling for the purposes of information blocking, they are
instructive insofar as they illustrate the breadth with which these
terms have been understood in other contexts. We noted that the HIPAA
Security Rule defines ``access'' as the ability or the means necessary
to read, write, modify, or communicate data/information or otherwise
use any system resource (45 CFR 164.304). Last, we noted that the HIPAA
Privacy Rule defines the term ``use,'' which includes the sharing,
employment, application, utilization, examination, or analysis of
individually identifiable health information within an entity that
maintains the information (45 CFR 160.103).
We stated that the types of access, exchange, and use described
above would be promoted under the information blocking provision, as
would other types of access, exchange, or use not specifically
contemplated in these or other regulations.
We emphasized in the Proposed Rule the interrelated nature of the
definitions and proposed to define these terms in Sec. 171.102. For
example, the definition of ``use'' that we proposed includes the
ability to read, write, modify, manipulate, or apply EHI to accomplish
a desired outcome or to achieve a desired purpose, while ``access'' is
defined as the ability or means necessary to make EHI available for
use. As such, we specified that the interference with ``access'' would
include, for example, an interference that prevented a health care
provider from writing EHI to its health IT or from modifying EHI stored
in health IT, whether by the provider itself or by, or via, a third-
party app. We encouraged comment on these definitions. In particular,
we asked commenters to consider whether these definitions are broad
enough to cover all of the potential purposes for which EHI may be
needed and ways in which it could conceivably be used, now and in the
future.
Comments. Several commenters supported our proposed definitions of
``access,'' ``exchange,'' and ``use,'' based on our broad
interpretation of the definitions, which they stated supports
interoperability. Several health IT developers and developer
organizations stated that the definition of ``access'' was overly
broad. They suggested that we clarify and narrow the scope of our
proposed definition of ``access.'' One commenter specifically suggested
that we clarify that ``access'' need not be provided through a direct
interface. Some commenters suggested that we remove the proposed
language regarding ``any and all source systems.''
Some commenters expressed concern that the proposed definition of
``exchange'' is overly broad. Other commenters requested additional
clarity regarding the scope of the definition. One commenter suggested
that we clarify the meaning of ``transmission'' within the definition.
Some health care providers and provider organizations stated that
our proposed definition of ``use'' was overly broad. Some commenters
suggested that we look to more established definitions of ``use,'' such
as HIPAA. Other commenters suggested that the proposed definition would
inappropriately increase administrative burden.
Response. We have revised these definitions in response to
comments. These revisions do not narrow the scope of the definitions in
regard to their intended interpretation and purpose in supporting
interoperability and the goals of the information blocking provision.
We believe, however, the revisions and their explanations below will
provide the necessary clarifications for stakeholders to properly
implement and comply with the terms.
Access
We have finalized the definition of ``access'' as ``the ability or
means necessary to make EHI available for exchange, use, or both''
(Sec. 171.102). This final definition improves on the proposed
definition (see 84 FR 7601) in a couple of ways. First, it makes clear
that ``access'' is the ability or means necessary to make EHI available
not only for ``use,'' but also for ``exchange'' or both (the proposed
definition only included ``for use''). This modification will provide
clarity because, as we noted in the Proposed Rule, these terms are
interrelated and EHI cannot be exchanged or used if it is inaccessible.
Second, to be responsive to comments and in order to promote additional
clarity in the definition, we have removed ``including the ability to
securely and efficiently locate and retrieve information from any and
all source systems in which the information may be recorded or
maintained'' from the definition. This language was exemplary and
resulted in some confusion among stakeholders. Last, we clarify that
the definition of ``access'' is not limited to direct interfaces, which
we believe is evident by the final definition.
Exchange
We have finalized the definition of ``exchange'' as ``the ability
for electronic health information to be transmitted between and among
different technologies, systems, platforms, or networks.'' As with the
finalized ``access'' definition, we have maintained the general scope
of the proposed definition while modifying the definition for clarity.
First, we removed ``securely and efficiently'' as proposed descriptors
of the way that EHI is to be transmitted under the definition. While we
continue to advocate for and promote secure and efficient exchange, we
do not think this descriptive language is necessary within the
definition of ``exchange'' because ``exchange'' for the purposes of the
information blocking provision can
[[Page 25806]]
occur regardless of whether the transaction is ``secure'' or
``efficient.'' Our intent with this definition was never to exclude
unsecure or ``inefficient'' exchanges from the definition or
enforcement of the information blocking provision because the exchange
of EHI was not secure or ``inefficient,'' so we have removed this
extraneous language. We also refer stakeholders to the information
blocking exceptions included in this final rule that discuss how EHI
may be transmitted and the importance of security as it relates to the
access, exchange, and use of EHI.
Second, we have removed the provision at the end of the proposed
definition, that in order for ``exchange'' to occur, it must be ``in a
manner that allows the information to be accessed and used.'' This
language was potentially confusing because the manner of transmittal is
not a necessary component of the ``exchange'' definition. If EHI is
exchanged but is done so in way that does not permit the use of the
EHI, then that practice may implicate the information blocking
provision because the ``use'' of the EHI is being prevented. Further,
to be responsive to comments, we emphasize that ``transmitted'' within
the definition is not limited to a one-way transmission, but instead is
inclusive of all forms of transmission such as bi-directional and
network-based transmission. We note this as a point of clarification,
as it was always our intent that ``transmission'' would be interpreted
this way.
Use
We have finalized ``use'' to mean ``the ability for EHI, once
accessed or exchanged, to be understood and acted upon.'' Put another
way, ``use'' is an individual or entity's ability to do something with
the EHI once it has been accessed or exchanged. We believe this final
definition is more concise and clear than the proposed definition--
``the ability of health IT or a user of health IT to access relevant
EHI; to comprehend the structure, content, and meaning of the
information; and to read, write, modify, manipulate, or apply the
information to accomplish a desired outcome or to achieve a desired
purpose'' (84 FR 7602). Again, we emphasize the general scope and
meaning of the definition is the same as proposed as explained below.
First, we have removed language that is more appropriately used as
examples in this preamble. For instance, the use of the word
``understood'' in the final definition encompasses the ability to
comprehend various things such the structure, content, and meaning of
the information from the proposed definition. However, we clarify that
``understood'' just like the proposed term ``comprehend'' does not mean
the ability to understand the clinical significance or relevance of the
EHI. For example, if an ambulatory provider received patient EHI from a
hospital that included a risk score, the concept of ``use'' does not
require the hospital to provide additional resources to interpret the
score nor would the tool or technology needed to interpret the
information be considered an interoperability element because its sole
purpose is clinical interpretation.
Similarly to ``understood,'' ``acted upon'' within the final
definition encompasses the ability to read, write, modify, manipulate,
or apply the information from the proposed definition. We also clarify
that ``use'' is bi-directional (to note, we also clarified above in the
``exchange'' discussion that ``exchange'' is bi-directional). Thus, an
actor's practice could implicate the information blocking provision not
only if the actor's practice interferes with the requestor's ability to
read the EHI (one-way), but also if the actor's practice interferes
with the requestor's ability to write the EHI (bi-directional) back to
a health IT system.
We note that the ability ``to access relevant EHI'' from the
proposed definition will fall under the ``access'' definition,
particularly in light of the modifications we have made to the
``access'' definition discussed above. Last, we note that we have
removed the requirement from the final definition that it would only be
considered ``use'' if the action were ``to accomplish a desired outcome
or to achieve a desired purpose.'' We do not believe this language is
necessary because the ultimate purpose of the ``use'' of the EHI is not
relevant to the definition of ``use.''
We appreciate the comments suggesting that we look to more
established definitions of ``use,'' such as that within the HIPAA
Privacy Rule. We did consider adopting the HIPAA Privacy Rule
definition, but ultimately decided that our finalized definition is
more appropriate and easier to understand within the information
blocking context. We also appreciate the comments suggesting that the
proposed definition would inappropriately increase administrative
burden; however, we do not believe there is a basis for such assertion,
particularly with the clarifications we have provided and the focusing
of the EHI definition.
b. Interoperability Elements
We proposed to use the term ``interoperability element'' to refer
to any means by which EHI can be accessed, exchanged, or used. We
proposed that the means of accessing, exchanging, and using EHI is not
limited to functional elements and technical information but also
encompasses technologies, services, policies, and other conditions
\127\ necessary to support the many potential uses of EHI. Because of
the evolving nature of technology and the diversity of privacy and
other laws and regulations, institutional arrangements, and policies
that govern the sharing of EHI, we did not provide an exhaustive list
of interoperability elements in the Proposed Rule. We requested comment
on the proposed definition.
---------------------------------------------------------------------------
\127\ See ONC, Connecting Health and Care for the Nation: A
Shared Nationwide Interoperability Roadmap at x-xi, https://www.healthit.gov/topic/interoperability/interoperability-roadmap
(Oct. 2015) [hereinafter ``Interoperability Roadmap''].
---------------------------------------------------------------------------
Comments. Some commenters supported the proposed definition, noting
that the breadth and scope of the definition is appropriate. Some
commenters requested clarifications and modifications regarding aspects
of the proposed definition. A few commenters requested that we clarify
whether specific functionalities and technologies, such as certified
Health IT Modules and proprietary APIs, would be considered
interoperability elements. A commenter requested, within the context of
the Licensing Exception (Sec. 171.303), clarification regarding
whether interoperability elements are limited to those elements to
which an actor can lawfully confer rights or licenses without the
agreement of a third party. A few commenters stated that the definition
should exclude underlying substantive content or health facts because
such content is not a potential means by which EHI may be accessed,
exchanged, or used. One of those commenters also requested that we
clarify that legally required data tags are excluded from the
``interoperability element'' definition. A commenter suggested that we
clarify that whether a functionality is considered an interoperability
element should be determined without regard to whether it can be
protected under copyright or patent law. One commenter requested
additional examples of interoperability elements. Another commenter
requested clarification regarding the meaning of ``transmit'' within
the definition.
Some commenters stated that the definition is too broad and should
be narrowed. A couple of commenters
[[Page 25807]]
stated that the definition is confusing and ambiguous. A few commenters
noted that we should focus the definition on specific elements that are
currently certified and/or are employed to support interoperability
through existing standards and requirements that enable the exchange of
EHI in a usable fashion.
Response. We appreciate commenters' support of the proposed
definition, as well as the comments that requested clarifications and
suggested improvements to the definition. We have streamlined the
definition, with the intent of maintaining a broad definition of
interoperability elements, and leveraged other regulatory and industry
terms to add clarity. We have finalized the definition of
``interoperability element'' to mean hardware, software, integrated
technologies or related licenses, technical information, privileges,
rights, intellectual property, upgrades, or services that: (1) May be
necessary to access, exchange, or use EHI; and (2) is controlled by the
actor, which includes the ability to confer all rights and
authorizations necessary to use the element to enable the access,
exchange, or use of EHI.
While this definition remains broad, it is confined by changes we
have made to other parts of the information blocking section.
Specifically, the more focused definitions of ``electronic health
information'' and ``access,'' ``exchange,'' or ``use'' will result in a
smaller scope of interoperability elements, as defined above, being
necessary to enable access, exchange, or use of EHI. Further, under the
Content and Manner Exception (Sec. 171.301), we establish that an
actor is not required to respond to a request to access, exchange, or
use EHI in the manner requested if the actor would be required to
license its IP (which could constitute an interoperability element) and
cannot reach agreeable terms for the license with the requestor (Sec.
171.301(b)(1)(i)(B)). This means that actors who do not want to license
their interoperability elements will not be required to do so if they
are able to respond in an alternative manner in accordance with Sec.
171.301(b)(2).
We believe the above definition improves on the proposed definition
in multiple ways. First, while preserving the meaning described in the
Proposed Rule that would constitute an interoperability element (i.e.,
hardware, software, technical information, technology, service,
license, right, privilege), we have removed descriptive language and
examples from the regulation text. Such language did not add clarity,
as it was not exhaustive as noted in the regulation text, which
included the language: ``Any other means by which electronic health
information may be accessed, exchanged, or used.'' The removal of this
language makes the definition clearer and more concise. We note that we
provide examples of ``interoperability elements'' in the discussion
below.
Second, we leveraged the definition of ``health information
technology'' from title XXX of the PHSA (specifically, section 3000(5)
of the PHSA), as added by title XIII of the HITECH Act. The Cures Act
amended title XXX of the PHSA to establish the information blocking
provision in section 3022 of the PHSA. Section 3000(5) of the PHSA
defines ``health information technology'' as ``hardware, software,
integrated technologies or related licenses, intellectual property,
upgrades, or packaged solutions sold as services that are designed for
or support the use by health care entities or patients for the
electronic creation, maintenance, access, or exchange of health
information.'' We emphasize that this definition includes intellectual
property.
When we drafted the Proposed Rule, we chose to use the term
``interoperability element'' to describe the means necessary to access,
exchange, or use EHI instead of ``health IT'' because we believed that
defining a new term (interoperability element) would allow us to tailor
and focus the definition to the specific issue of information blocking.
However, after further reflection and review of stakeholder comments--
specifically those requesting additional clarity regarding the
definition of ``interoperability element''--we believe a better
approach is to leverage the definition of ``health information
technology'' from section 3000(5) of the PHSA because that definition
provides the statutory basis for the types of technology, services,
functionality necessary to support interoperability, including the
access, exchange, and use of EHI. We believe this approach of
leveraging an established, statutory definition will promote
transparency and clarify ONC's expectations for regulated actors.
As such, we have added ``integrated technologies,'' ``intellectual
property,'' and ``upgrades'' from the PHSA definition into our
definition of interoperability element. These additions will strengthen
the ``interoperability element'' definition by explicitly identifying
types of interoperability elements that would have been covered by our
proposed definition, but were not called out in the proposed definition
(these types of interoperability elements would have been covered by
the provision in the proposed definition that an interoperability
element could be any other means by which EHI may be accessed,
exchanged, or used). We chose not to substitute the PHSA health
information technology definition in its entirety for the
``interoperability element'' definition in this final rule because some
aspects do not fit within the ``interoperability element'' definition.
For instance, the concept of ``packaged solutions'' is undefined and
would not add clarity to the interoperability element definition. Thus,
we believe this approach will achieve our goal of establishing a
definition of interoperability element that is tailored for the
information blocking context.
Last, we have clarified within the definition that a requisite
component of an interoperability element is that it is controlled by
the actor. As used in the interoperability element definition,
controlled by the actor includes the ability to confer all rights and
authorizations necessary to use the element to enable the access,
exchange, or use of EHI. In order to make this point clear, we have
added and finalized paragraph (2) within the interoperability element
definition (see Sec. 171.102). Thus, if an actor could not confer a
right or authorization necessary to use the interoperability element to
enable the access, exchange, or use of electronic health information,
(e.g., by way of sub-license or assignment), the actor would not have
the requisite ``control'' under the ``interoperability element''
definition. This clarification reinforces our position that our rule
does not require or encourage actors to infringe on IP rights.
We appreciate the comments that asked that we specify whether
specific functionalities and technologies, such as certified Health IT
Modules and proprietary APIs, would be considered interoperability
elements. We clarify that most certified Health IT Modules and
proprietary APIs would be considered interoperability elements under
the interoperability element definition. We also clarify that the
underlying substantive content or health facts are not considered
interoperability elements because substantive content and health facts
are not a means by which EHI is accessed, exchanged, or used. Regarding
legally required data tags, we would need additional information
concerning the specific data tag to determine whether it could
constitute an interoperability element.
[[Page 25808]]
Generally, data tags would likely be considered technical information
under the ``interoperability element'' definition, but such data tags
would need to be necessary to access, exchange, or use EHI to be
considered an interoperability element.
A determination regarding whether a functionality is considered an
interoperability element will be determined without regard to whether
it is protected under copyright or patent law. In fact, the finalized
definition of interoperability element includes ``licenses'' and
``intellectual property.'' We have also established an exception to
information blocking that supports the licensing of intellectual
property. Thus, we make clear that functionalities generally covered by
copyright, patent, or other such laws can be interoperability elements.
In response to the commenter who requested additional examples of
interoperability elements, we provide the following non-exhaustive list
of examples:
Functional elements of health IT that could be used to
access, exchange, or use EHI for any purpose, including information
exchanged or maintained in disparate media, information systems, or by
HINs/HIEs;
Technical information that describes the functional
elements of technology, such as a standard, specification, protocol,
data model, or schema, that would be required to use a functional
element of a certain technology, including for the purpose of
developing compatible technologies that incorporate or use the
functional elements;
System resources, technical infrastructure, or HIN/HIE
elements that are required to enable the use of a compatible technology
in production environments; or
Licenses, rights, or privileges that may be required to
commercially offer and distribute compatible technologies and make them
available for use in production environments.
We appreciate the comments requesting that we clarify and narrow
the ``interoperability element'' definition. As discussed above, we
believe the revised definition addresses commenters' concerns regarding
the clarity of the definition. Responsive to commenters, the final
definition is also narrower than the proposed definition, as we have
removed the proposed provision that an interoperability element could
be any other means by which EHI may be accessed, exchanged, or used
(see 84 FR 7602).
We have decided not to focus the definition on certified elements
or existing standards or requirements because such a narrowed focus
would unduly limit the definition, interoperability, and the access,
exchange, and use of EHI. The finalized definition reflects that there
are countless means by which EHI may be accessed, exchanged, or used
that are not certified or standardized. We note that the new Content
and Manner Exception (Sec. 171.301) supports certified and standards-
based exchange as suggested by the commenter. We refer readers to
VIII.D.2.a of this preamble for a discussion of that exception.
We note that we have removed the term ``transmit'' from the
regulatory text because it no longer fit in the context of other
changes made to the definition.
6. Practices That May Implicate the Information Blocking Provision
To meet the definition of information blocking under section
3022(a) of the PHSA, a practice must be likely to interfere with,
prevent, or materially discourage the access, exchange, or use of EHI.
In this section and elsewhere in the Proposed Rule, we discussed
various types of hypothetical practices that could implicate the
information blocking provision. We did this to illustrate the scope of
the information blocking provision and to explain our interpretation of
various statutory concepts. However, we stressed that the types of
practices discussed in the preamble of the Proposed Rule are
illustrative and not exhaustive and that many other types of practices
could also implicate the provision. We emphasized that the fact that we
did not identify or discuss a particular type of practice did not imply
that it is less serious than those that were discussed in the preamble.
Indeed, we explained in the Proposed Rule that because information
blocking may take many forms, it is not possible to anticipate or
catalog all potential types of practices that may raise information
blocking concerns.
We emphasized that any analysis of information blocking necessarily
requires a careful consideration of the individual facts and
circumstances, including whether the practice was required by law,
whether the actor had the requisite knowledge, and whether an exception
applies. A practice that seemingly meets the statutory definition of
information blocking would not be information blocking if it was
required by law, if one or more elements of the definition were not
met, or if it was covered by one of the exceptions for reasonable and
necessary activities.
In accordance with section 3022(a)(3) of the PHSA, we proposed in
the Proposed Rule to establish exceptions to the information blocking
provision for certain reasonable and necessary activities. We proposed
that if an actor can establish that an exception applies to each
practice for which a claim of information blocking has been made,
including that the actor satisfied all applicable conditions of the
exception at all relevant times, then the practice would not constitute
information blocking.
Comments. There was broad support from commenters regarding the
categories of practices identified in the Proposed Rule that may
implicate the information blocking provision, as well as the non-
exhaustive list of specific examples provided in the Proposed Rule to
assist with compliance. Commenters noted that the illustrative examples
provided were helpful in providing further clarity on the scope of the
information blocking provision. Many commenters noted that considerable
barriers continue to obstruct both provider and patient access to
patient data and our approach to the information blocking provision can
increase access to this data.
Several commenters suggested the need for a comprehensive inventory
or repository of examples, including examples of information blocking
conduct that have been submitted to ONC. Many commenters suggested
specific clarifications and modifications to the examples provided in
the Proposed Rule in the sections below, as well as additional examples
for inclusion in the final rule, such as additional examples applicable
to specific contexts (e.g., imaging providers, and pharmacies) or
specific practices (e.g., practices involving clinical data registries
and pharmacogenomics).
Response. We thank commenters for their support and feedback. We
have not revised the examples provided in the Proposed Rule because we
believe they are clear, accurate, and helpful to readers. To be
responsive to commenters who requested additional examples be added to
the final rule, we have added examples in the discussion of ``Limiting
or Restricting the Interoperability of Health IT'' in section
VIII.C.6.c.ii. as well as additional examples within the preamble
discussion for the exceptions. We used commenters' suggestions to help
inform these examples and highlight important use cases and
circumstances that required additional clarification. We emphasize that
these listed examples are illustrative, but not exhaustive.
We also clarify that when we say that the actor must satisfy all
applicable conditions of the exception at all
[[Page 25809]]
relevant times to meet each exception, all relevant times means any
time when an actor's practice relates to the access, exchange, or use
of EHI.
a. Prevention, Material Discouragement, and Other Interference
We explained in the Proposed Rule that the information blocking
provision and its enforcement subsection do not define the terms
``interfere with,'' ``prevent,'' and ``materially discourage,'' and use
these terms collectively and without differentiation. Based on our
interpretation of the information blocking provision and the ordinary
meanings of these terms in the context of EHI, we interpreted these
terms to not be mutually exclusive. Instead, prevention and material
discouragement may be understood as types of interference, and that use
of these terms in the statute to define information blocking
illustrates the desire to reach all practices that an actor knows, or
should know, are likely to prevent, materially discourage, or otherwise
interfere with the access, exchange, or use of EHI. Consistent with
this understanding, we used the terms ``interfere with'' and
``interference'' as inclusive of prevention and material
discouragement.
We explained that interference could take many forms. In addition
to the prevention or material discouragement of access, exchange, or
use, we stated that interference could include practices that increase
the cost, complexity, or other burdens associated with accessing,
exchanging, or using EHI. Interference could also include practices
that limit the utility, efficacy, or value of EHI that is accessed,
exchanged, or used, such as by diminishing the integrity, quality,
completeness, or timeliness of the data. Relatedly, to avoid potential
ambiguity and clearly communicate the full range of potential practices
that could implicate the information blocking provision, we proposed to
codify a definition of ``interfere with'' in Sec. 171.102, consistent
with our interpretation set forth above (84 FR 7516).
Comments. We did not receive comments on our proposed definition of
``interfere with.''
Response. We have finalized the definition of ``interfere with''
(also referred to as ``interference'') in Sec. 171.102 as proposed,
but with a modification to remove the phrase ``access, exchange, or use
of electronic health information'' from the definition. We removed this
language because it was not necessary in the definition, and to avoid
duplication, as we often say in the preamble of this final rule that
``a practice interferes with access, exchange or use of EHI.'' We also
note that we received many comments requesting clarification of whether
certain practices would constitute interference with the access,
exchange, and use of EHI, and thus implicate the information blocking
provision. We address these comments in section VIII.C.6.c (Examples of
Practices Likely to Interfere with the Access, Exchange or Use of EHI)
below.
b. Likelihood of Interference
We noted in the Proposed Rule that the information blocking
provision is preventative in nature. That is, the information blocking
provision proscribes practices that are likely to interfere with
(including preventing or materially discouraging) access, exchange, or
use of EHI--whether or not such harm materializes. By including both
the likely and the actual effects of a practice, the information
blocking provision encourages individuals and entities to avoid
engaging in practices that undermine interoperability, and to
proactively promote access, exchange, and use of EHI.
We explained that a practice would satisfy the information blocking
provision's ``likelihood'' requirement if, under the circumstances,
there is a reasonably foreseeable risk that the practice will interfere
with access, exchange, or use of EHI. We explained that a policy or
practice that limits timely access to information in an appropriate
electronic format creates a reasonably foreseeable likelihood of
interfering with the use of the information.
We noted that whether the risk of interference is reasonably
foreseeable will depend on the particular facts and circumstances
attending the practice or practices at issue. Because of the number and
diversity of potential practices, and the fact that different practices
will present varying risks of interfering with access, exchange, or use
of EHI, we did not attempt to anticipate all of the potential ways in
which the information blocking provision could be implicated.
Nevertheless, to assist with compliance, we clarified certain
circumstances in which, based on our experience, a practice will almost
always be likely to interfere with access, exchange, or use of EHI. We
cautioned that the situations listed are not exhaustive and that other
circumstances may also give rise to a very high likelihood of
interference under the information blocking provision. We noted that in
each case, the totality of the circumstances should be evaluated as to
whether a practice is likely to constitute information blocking.
In the Proposed Rule, we stated that we believe that information
blocking concerns are especially pronounced when the conduct at issue
has the potential to interfere with the access, exchange, or use of EHI
that is created or maintained during the practice of medicine or the
delivery of health care services to patients, which we referred to
collectively as ``observational health information'' (84 FR 7516
and7517). We received a few comments seeking clarification regarding
our use of the term ``observational health information'' or that we
provide a regulatory definition for the term.
Comments. We received some comments requesting clarification
regarding the meaning of ``timely'' access in the discussion in the
Proposed Rule.
Response. We have not established a set timeframe for what
``timely'' access means because there is so much variability regarding
what ``timely'' will mean based on the specific facts and
circumstances, and particularly with regard to the broad scope of
health IT being discussed. We emphasize that whether access is
considered timely will be determined based on the specific facts and
circumstances. We refer readers to the discussion in section
VIII.C.6.c. on ``Limiting or Restricting the Interoperability of Health
IT'' where we discuss how slowing or delaying access, exchange, or use
of EHI could be considered information blocking.
Comments. We did not receive any additional comments regarding out
interpretation of the information blocking provision's ``likelihood''
requirement discussed above.
Response. We have finalized our interpretation as described above.
Comments. We received comments requesting clarification regarding
the meaning of ``observational health information'' as used in the
Proposed Rule.
Response. As discussed earlier in section VIII.C.3, after
consideration of concerns raised by commenters, we have not finalized
the definition of EHI as proposed. Instead, we have finalized a more
focused definition of EHI. Because we have finalized a definition of
EHI with a more focused scope than proposed, we no longer believe our
proposed approach regarding observational health information is
necessary. Accordingly, we are not using the term ``observational
health information'' in this final rule. We refer readers to section
VIII.C.3. for further discussion of the definition of EHI.
[[Page 25810]]
i. Purposes for Which Information May Be Needed
We explained in the Proposed Rule that the information blocking
provision will almost always be implicated when a practice interferes
with access, exchange, or use of EHI for certain purposes, including
but not limited to:
Providing patients with access to their EHI and the
ability to exchange and use it without special effort (see section
VII.B.4).
Ensuring that health care professionals, care givers, and
other authorized persons have the EHI they need, when and where they
need it, to make treatment decisions and effectively coordinate and
manage patient care and can use the EHI they may receive from other
sources.
Ensuring that payers and other entities that purchase
health care services can obtain the information they need to
effectively assess clinical value and promote transparency concerning
the quality and costs of health care services.
Ensuring that health care providers can access, exchange,
and use EHI for quality improvement and population health management
activities.
Supporting access, exchange, and use of EHI for patient
safety and public health purposes.
We emphasized that the need to ensure that EHI is readily available
and usable for these purposes is paramount. Therefore, practices that
increase the cost, difficulty, or other burdens of accessing,
exchanging, or using EHI for these purposes would almost always
implicate the information blocking provision. We stressed that
individuals and entities that develop health IT or have a role in
making these technologies and services available should consider the
impact of their actions and take steps to support interoperability and
avoid impeding the availability or use of EHI (84 FR 7517).
Comments. We did not receive comments of the discussion above.
Response. Consistent with the Proposed Rule, in this final rule we
continue to emphasize that practices that interfere with the access,
exchange, or use of EHI for the purposes listed in this section and
that do not meet any of the final exceptions will almost always
implicate the information blocking provision and will be inherently
suspect. These practices may jeopardize the core functions of the
health care system that require the access, exchange, or use of EHI. We
believe there are few, if any, legitimate reasons for an actor to
interfere with the use of EHI in the context of these purposes.
We specifically emphasize that practices that involve an actor
charging an individual a fee to access, exchange, or use their EHI
would be inherently suspect, as discussed in more detail in the Fees
Exception (section VIII.D.2.b), as there are few, if any, legitimate
reasons for an actor to charge an individual for access to their EHI.
ii. Control Over Essential Interoperability Elements; Other
Circumstances of Reliance or Dependence
We explained in the Proposed Rule that an actor may have
substantial control over one or more interoperability elements that
provide the only reasonable means of accessing, exchanging, or using
EHI for a particular purpose. We noted that, in these circumstances,
any practice by the actor that could impede the use of the
interoperability elements--or that could unnecessarily increase the
cost or other burden of using the elements--would almost always
implicate the information blocking provision.
We explained that the situation described above is most likely when
customers or users are dependent on an actor's technology or services,
which can occur for any number of reasons. For example, technological
dependence may arise from legal or commercial relations, such as a
health care provider's reliance on its EHR developer to ensure that EHI
managed on its behalf is accessible and usable when it is needed.
Relatedly, most EHI is currently stored in EHRs and other source
systems that use proprietary data models or formats. Knowledge of the
data models, formats, or other relevant technical information (e.g.,
proprietary APIs) is necessary to understand the data and make
efficient use of it in other applications and technologies. Because
this information is routinely treated as confidential or proprietary,
the developer's cooperation is required to enable uses of the EHI that
go beyond the capabilities provided by the developer's technology. This
includes the capability to export complete information sets and to
migrate data in the event that a user decides to switch to a different
technology.
We noted that separate from these contractual and intellectual
property issues, users may become ``locked in'' to a particular
technology, HIE, or HIN for financial or business reasons. For example,
many health care providers have invested significant resources to adopt
EHR technologies--including costs for deployment, customization, data
migration, and training--and have tightly integrated these technologies
into their information management strategies, clinical workflows, and
business operations. As a result, they may be reluctant to switch to
other technologies due to the significant cost and disruption this
would entail.
We explained that another important driver of technological
dependence is the ``network effects'' of health IT adoption, which are
amplified by reliance on technologies and approaches that are not
standardized and do not enable seamless interoperability. Consequently,
health care providers and other health IT users may gravitate towards
and become reliant on the proprietary technologies, HIEs, or HINs that
have been adopted by other individuals and entities with whom they have
the greatest need to exchange EHI. We noted that these effects may be
especially pronounced within particular products or geographic areas.
For example, a HIN that facilitates certain types of exchange or
transactions may be so widely adopted that it is a de facto industry
standard. A similar phenomenon may occur within a particular geographic
area once a critical mass of hospitals, physicians, or other providers
adopt a particular EHR technology, HIE, or HIN.
We emphasized that in these and other analogous circumstances of
reliance or dependence, there is a heightened risk that an actor's
conduct will interfere with access, exchange, or use of EHI. To assist
with compliance, we highlighted the following common scenarios, based
on our outreach to stakeholders, in which actors exercise control over
key interoperability elements.\128\
---------------------------------------------------------------------------
\128\ As an important clarification, we note that control over
interoperability elements may exist with or without the actor's
ability to manipulate the price of the interoperability elements in
the market.
---------------------------------------------------------------------------
Health IT developers of certified health IT that provide EHR
systems or other technologies used to capture EHI at the point of care
are in a unique position to control subsequent access to and use of
that information.
HINs and HIEs may be in a unique position to control the
flow of information among particular persons or for particular
purposes, especially if the HIN or HIE has achieved significant
adoption in a particular geographic area or for a particular type of
health information use case.
Similar control over EHI may be exercised by other
entities, such as health IT developers of certified health IT, that
supply or control proprietary technologies, platforms, or services that
are widely adopted by a class of users or that are a ``de facto
standard'' for
[[Page 25811]]
certain types of EHI exchanges or transactions.
Health care providers within health systems and other
entities that provide health IT platforms, infrastructure, or
information sharing policies may have a degree of control over
interoperability or the movement of data within a geographic area that
is functionally equivalent to the control exercised by a dominant
health IT developer, HIN, or HIE.
To avoid engaging in conduct that may be considered information
blocking, actors with control over interoperability elements should be
careful not to engage in practices that exclude persons from the use of
those elements or create artificial costs or other impediments to their
use.
We encouraged comment on these and other circumstances that may
present an especially high likelihood that a practice will interfere
with access, exchange, or use of EHI within the meaning of the
information blocking provision.
Comments. A few commenters appreciated the examples provided and
ONC's acknowledgement in the Proposed Rule that certain parties are in
a unique position to control access, exchange, and use of EHI. Other
commenters urged ONC to only hold accountable those parties that
actually have control of the EHI or control of interoperability
elements necessary to access, exchange, or use the EHI in question.
Response. We thank commenters for their support. We stress that any
analysis of whether an actor's practices constitute information
blocking will depend on the particular facts and circumstances of the
case, which may include an assessment of the actor's control over the
EHI or interoperability elements necessary to access, exchange, or use
the EHI in question, as applicable. A key element of information
blocking is that the actor's practice is likely to interfere with an
individual or entity's ability to access, exchange, or use EHI. Thus,
we look at accountability through the lens of whether the actor is the
individual or entity engaging in the practice.
Regarding the comment that we should only hold accountable those
parties that actually have control of the EHI or interoperability
elements necessary to access, exchange, or use the EHI, we note that we
have addressed this issue within preamble discussion concerning the
definition of ``interoperability element'' (VIII.C.5.b), Infeasibility
Exception (VIII.D.1.d), and Content and Manner Exception (VIII.D.2.a).
We refer readers to those discussions.
c. Examples of Practices Likely To Interfere With Access, Exchange, or
Use of EHI
To further clarify the scope of the information blocking provision,
we described in the Proposed Rule several types of practices that would
be likely to interfere with access, exchange, or use of EHI. Those
examples clarified and expanded on those set forth in section
3022(a)(2) of the PHSA.
Because information blocking can take many forms, we emphasized
that the categories of practices described in the Proposed Rule were
illustrative only and did not provide an exhaustive list or
comprehensive description of practices that may implicate the
information blocking provision and its penalties. We also reiterated
that each case will turn on its unique facts. We noted that, for the
categories of practices described in the Proposed Rule, we did not
consider the applicability of any exceptions. We reiterate that the
examples provided in the Proposed Rule were designed to provide greater
clarity on the various types of hypothetical practices that could
implicate the information blocking provision.
Comments. We received comments requesting that we revise or clarify
examples provided in the Proposed Rule in the following sections.
Response. We have not revised or clarified the majority of the
examples for purposes of this final rule, and we believe the majority
of the examples are still applicable. We note in the discussion below
necessary clarifications concerning concepts expressed in some of the
proposed examples. We refer readers to the Proposed Rule (84 FR 7518
through 7521) for a complete listing of the examples provided for each
category of practices below.
i. Restrictions on Access, Exchange, or Use
We explained in the Proposed Rule that the information blocking
provision establishes penalties, including civil monetary penalties, or
requires appropriate disincentives, for practices that restrict access,
exchange, or use of EHI for permissible purposes. We noted that one
means by which actors may restrict access, exchange, or use of EHI is
through formal restrictions. These may be expressed in contract or
license terms, EHI sharing policies, organizational policies or
procedures, or other instruments or documents that set forth
requirements related to EHI or health IT. Additionally, in the absence
of an express contractual restriction, an actor may achieve the same
result by exercising intellectual property or other rights in ways that
restrict access, exchange, or use (84 FR 7518).
We explained that access, exchange, or use of EHI can also be
restricted in less formal ways. The information blocking provision may
be implicated, for example, where an actor simply refuses to exchange
or to facilitate the access or use of EHI, either as a general practice
or in isolated instances. The refusal may be expressly stated or it may
be implied from the actor's conduct, such as where the actor ignores
requests to share EHI or provide interoperability elements; gives
implausible reasons for not doing so; or insists on terms or conditions
that are so objectively unreasonable that they amount to a refusal to
provide access, exchange, or use of the EHI (84 FR 7518).
We emphasized that restrictions on access, exchange, or use that
are required by law would not implicate the information blocking
provision. Moreover, we recognized that some restrictions, while not
required by law, may be reasonable and necessary for the privacy and
security of individuals' EHI and noted that such practices may qualify
for protection under an exception (84 FR 7519).
Comments. Commenters requested that we clarify the types of
contract and agreement terms that could implicate the information
blocking provision beyond terms specifying fees and the licensing of
intellectual property rights. Some commenters stated that ``legacy EHR
platforms'' impede real time data flow between EHRs and the clinical
workflow, including the use of third-party clinical decision support
applications, through various contract terms. Many commenters also
indicated that EHR developers place onerous contract terms on
developers of applications that enable patient access to EHI through
APIs. A few commenters asserted that a business associate (BA), as
defined under the HIPAA Privacy Rule, should not be liable under the
information blocking provision (or there should be an exception for
information blocking) for not responding to or fulfilling requests for
access, exchange, or use of EHI if such access, exchange, or use of EHI
would violate the BA's business associate agreement (BAA).
Response. We first clarify that all of the scenarios provided by
the commenters might implicate the information blocking provision. We
offer specific situations as follows where there might be an
implication. As a first example, an actor (e.g., a health care provider
that is a covered entity
[[Page 25812]]
under HIPAA) may want to engage an entity for services (e.g., use of a
clinical decision support application (``CDS App Developer'')) that
require the CDS App Developer to enter into a BAA with the health care
provider and, in order to gain access and use of the EHI held by
another BA of the health care provider (e.g., EHR developer of
certified health IT), the CDS App Developer is required by the EHR
developer of certified health IT to enter into a contract to access its
EHR technology. As a second example, an entity may offer an application
that facilitates patients' access to their EHI through an API
maintained by an actor (e.g., EHR developer of certified health IT)
that is a BA of a health care provider that is a covered entity under
HIPAA. As a third example, a health care provider may request EHI from
an actor that is a BA of another health care provider under HIPAA, such
as an EHR developer of certified health IT or HIN, that is contracted
to make EHI available for treatment purposes.
In response to comments and for the situations described above, we
clarify that contracts and agreements can interfere with the access,
exchange, and use of EHI through terms besides those that specify
unreasonable fees and commercially unreasonable licensing terms (see
sections VIII.D.2.b (Fees) and VIII.D.2.c (Licensing) for further
discussion of unreasonable fees and commercially unreasonable licensing
terms and associated exceptions to the information blocking provision).
For instance, a contract may implicate the information blocking
provision if it included unconscionable terms for the access, exchange,
or use of EHI or licensing of an interoperability element, which could
include, but not be limited to, requiring a software company that
produced a patient access application to relinquish all IP rights to
the actor or agreeing to indemnify the actor for acts beyond standard
practice, such as gross negligence on part of the actor. Such terms may
be problematic with regard to information blocking in situations
involving unequal bargaining power related to accessing, exchanging,
and using EHI.
Business Associate Agreements (BAAs)
We designed the final rule to operate in a manner consistent with
the framework of the HIPAA Privacy Rule and other laws providing
privacy rights for patients. Foremost, we do not require the disclosure
of EHI in any way that would not already be permitted under the HIPAA
Privacy Rule (or other Federal or State law). However, if an actor is
permitted to provide access, exchange, or use of EHI under the HIPAA
Privacy Rule (or any other law), then the information blocking
provision would require that the actor provide that access, exchange,
or use of EHI so long as the actor is not prohibited by law from doing
so (assuming that no exception is available to the actor).
Under the HIPAA Privacy Rule, a BAA must contain the elements
specified in 45 CFR 164.504(e), including a description of the
permitted and required uses of PHI by the business associate, and
provide that the business associate will not use or further disclose
the protected health information other than as permitted or required by
the contract or as required by law.\129\ While the information blocking
provision does not require actors to violate these agreements, a BAA or
its associated service level agreements must not be used in a
discriminatory manner by an actor to forbid or limit disclosures that
otherwise would be permitted by the Privacy Rule. For example, a BAA
entered into by one or more actors that permits access, exchange, or
use of EHI by certain health care providers for treatment should
generally not prohibit or limit the access, exchange, or use of the EHI
for treatment by other health care providers of a patient.
---------------------------------------------------------------------------
\129\ 45 CFR 164.514(e)(3) limits the use and disclosure of a
limited data set (LDS) to only the purposes of research, public
health or health care operations. Some of the other restrictions on
use and disclosure by a party that receives LDS Recipient are
similar to those imposed by the HIPAA Rules on business associates
so the discussion that follows generally applies to recipients of
LDS and their data use agreements as well as to business associates
(and their business associate agreements) to the extent of such
similar provisions.
---------------------------------------------------------------------------
To be clear, both the health care provider(s) who initiated the BAA
and the BA who may be an actor under the information blocking provision
(e.g., a health IT developer of certified health IT) would be subject
to the information blocking provision in the instance described above.
To illustrate the potential culpability of a BA, a BA with significant
market power may have contractually prohibited or made it difficult for
its covered entity customers to exchange EHI, maintained by the BA,
with health care providers that use an EHR system of one of the BA's
competitors. To determine whether there is information blocking, the
actions and processes (e.g., negotiations) of the actors in reaching
the BAA and associated service level agreements would need to be
reviewed to determine whether there was any action taken by an actor
that was likely to interfere with the access, exchange, or use of EHI,
and whether the actor had the requisite intent. We further note that if
the BA has an agreement with the covered entity to provide EHI to a
third party that requests it and the BA refuses to provide the access,
exchange, or use of EHI to a requestor in response to the request
received by the CE, then the BA (who is also an actor under the
information blocking provision) may have violated the information
blocking provision unless an exception applied.
Successors to Contractors and Agreements
We note that there may be circumstances in which there is a
successor to a contract or agreement when, for example, an actor goes
out of business, a provider leaves a practice, or an actor engages in a
merger or adopts a new corporate structure. If not handled
appropriately, it is possible that information blocking could occur.
ii. Limiting or Restricting the Interoperability of Health IT
We explained in the Proposed Rule that the information blocking
provision includes practices that restrict the access, exchange, or use
of EHI in various ways (see section 3022(a)(2) of the PHSA). These
practices could include, for example, disabling or restricting the use
of a capability that enables users to share EHI with users of other
systems or to provide access to EHI to certain types of persons or for
certain purposes that are legally permissible. In addition, the
information blocking provision may be implicated where an actor
configures or otherwise implements technology in ways that limit the
types of data elements that can be exported or used from the
technology. We noted that other practices that would be suspect include
configuring capabilities in a way that removes important context,
structure, or meaning from the EHI, or that makes the data less
accurate, complete, or usable for important purposes for which it may
be needed. Likewise, implementing capabilities in ways that create
unnecessary delays or response times, or that otherwise limit the
timeliness of EHI accessed or exchanged, may interfere with the access,
exchange, and use of that information and therefore implicate the
information blocking provision. We noted that any conclusions regarding
such interference would be based on fact-finding specific to each case
and would need to consider the applicability of the exceptions.
We explained that the information blocking provision would be
implicated if an actor were to deploy technological measures that limit
or restrict the ability to reverse engineer the functional
[[Page 25813]]
aspects of technology in order to develop means for extracting and
using EHI maintained in the technology. We noted that this may include,
for example, employing technological protection measures that, if
circumvented, would trigger liability under the Digital Millennium
Copyright Act (see 17 U.S.C. 1201) or other laws.
Additional Examples
In the context of ONC's certification rules, including
certification criteria and Conditions and Maintenance of Certification
requirements, we provide the following more explicit examples of
actions by actors that would likely constitute information blocking.
The first example of a technical interference that restricts the
interoperability of health IT relates to the publication of ``FHIR
service base URLs'' (sometimes also referred to as ``FHIR endpoints'').
As discussed in the API Condition of Certification preamble (section
VII.B.4), an API User needs to know a certified API technology's FHIR
service base URL to interact with the certified API technology. This
knowledge is foundational for the use of certified API technology
without special effort. Therefore, a FHIR service base URL cannot be
withheld by an actor as it (just like many other technical interfaces)
is necessary to enable the access, exchange, and use of EHI. Notably,
in the case of patients seeking access to their EHI, the public
availability of FHIR service base URLs is an absolute necessity and
without which the access, exchange, and use of EHI would be prevented.
Thus, any action by an actor to restrict the public availability of
URLs in support of patient access would be more than just likely to
interfere with the access, exchange, or use of EHI; it would prevent
such access, exchange, and use. Accordingly, as noted in Sec.
170.404(b)(2), a Certified API Developer must publish FHIR service base
URLs for certified API technology that can be used by patients to
access their electronic health information.
Consistent with this example, the above interpretation means that
API Information Sources (i.e., health care providers) who locally
manage their FHIR servers without Certified API Developer assistance
cannot refuse to provide to Certified API Developers the FHIR service
base URL(s) that is/are necessary for patients to use to access their
EHI. Equally, pursuant to the Maintenance of Certification requirement
finalized for Certified API Developers in Sec. 170.404, they would be
required to publish the FHIR service base URLs they centrally manage on
behalf of API Information Sources. We also clarify that the public
availability of FHIR service base URLs is a requirement that is scoped
specifically to the context of patients' access to their EHI and is not
intended to be interpreted as requiring all FHIR service base URLs to
be made publicly available (i.e., FHIR service base URLs that are
created and used among business partners would not need to be made
publicly available).
Along the same lines discussed in the example directly above, for a
patient to be able to use an application of their choice with certified
API technology, the software application will need to be
``registered.'' In that regard, as a second example, an actor's refusal
to register a software application that enables a patient to access
their EHI would effectively prevent its use given that registration is
a technical prerequisite for software applications to be able to
connect to certified API technology. As a result, such refusals in the
context of patient access unless otherwise addressed in this rule would
be highly suspect and likely to implicate information blocking. We
note, however, for the first and second example that neither app
registration nor the public availability of a FHIR service base URL
means that an application will be able to access any EHI. On the
contrary, the application would be unable to do so unless a patient
authenticates themselves via an appropriate workflow or, in the case of
a health care provider, the application is appropriately configured to
work within the provider's IT infrastructure.
As a third example, there is often specific information that may be
necessary for certain actors, in this case health care providers, to
effectively access, exchange, and use EHI via their Certified EHR
Technology and certified Health IT Modules. A health care provider's
``direct address'' is an example of this kind of information. If this
information were not made known to a health care provider upon request,
were inaccessible or hidden in a way that a health care provider could
not identify (or find out) their own direct address, or were refused to
be provided to a health care provider by a health IT developer with
certified health IT, we would consider all such actions to be
information blocking because knowledge of a direct address is necessary
to fully engage in the exchange of EHI.
As a last example, we note that, to the extent that a legal
transfer of IP to an individual or entity that is not an actor is
intended to facilitate circumvention of the information blocking
provision, the transfer itself by an actor could be considered an
interference with the access, exchange, or use of EHI.
We note that we have added definitions of ``API Information
Source,'' ``API User,'' ``Certified API Developer,'' and ``certified
API technology'' to Sec. 171.102. Each of those terms is defined as
they are in Sec. 170.404(c). We note that ``API Information Source''
replaced the proposed definition of ``API Data Provider'' and
``Certified API Developer'' replaced the proposed definition of ``API
Technology Supplier'' in order to align with the terms used in Sec.
170.404(c) (see the proposed terms in 84 FR 7601).
Comments. A few commenters requested that we provide further
clarity on whether slowing or delaying access, exchange, or use of EHI
could be considered information blocking.
Response. We clarify that slowing or delaying access, exchange, or
use of EHI could constitute an ``interference'' and implicate the
information blocking provision. We understand that some delays may be
legitimate and inevitable due to factors such as limited legal, project
management, and technical resources. Notwithstanding such
understandable challenges, we are aware that some actors use and
embellish legitimate challenges to create extended and unnecessary
delays. For instance, an actor could have legitimate technical scoping
and architecture questions regarding data integrations that require
attention and take time to address. However, these scoping and
architecture questions could constitute interference and implicate the
information blocking provision if they are not necessary to enable
access, exchange, or use of EHI and are being utilized as a delay
tactic. When assessing such practices, facts indicating that an actor
created extended or unnecessary delays may be evidence of an actor's
intent. We expect actors to make good faith efforts to work through
common and understandable challenges and limitations to enable
requestors to access, exchange, and use EHI as quickly and efficiently
as possible.
iii. Impeding Innovations and Advancements in Access, Exchange, or Use
or Health IT-Enabled Care Delivery
We explained in the Proposed Rule that the information blocking
provision encompasses practices that create impediments to innovations
and advancements to the access, exchange, and use of EHI, including
care delivery enabled by health IT (section 3022(a)(2)(C)(ii) of the
PHSA). Importantly, the information blocking provision may be
implicated and
[[Page 25814]]
penalties or appropriate disincentives may apply if an actor were to
engage in exclusionary, discriminatory, or other practices that impede
the development, dissemination, or use of interoperable technologies
and services that enhance access, exchange, or use of EHI.
We emphasized that, most acutely, the information blocking
provision may be implicated if an actor were to refuse to license or
allow the disclosure of interoperability elements to persons who
require those elements to develop and provide interoperable
technologies or services--including those that might complement or
compete with the actor's own technology or services. The same would be
true if the actor were to allow access to interoperability elements but
were to restrict their use for these purposes. We provided a list of
non-exhaustive examples to illustrate practices that would likely
implicate the information blocking provision by interfering with
access, exchange, or use of EHI (84 FR 7519 and 7520). We encourage
readers to review those examples in the Proposed Rule, as they are
still applicable.
We explained that, rather than restricting interoperability
elements, an actor may insist on terms or conditions that are
burdensome and discourage their use. These practices may implicate the
information blocking provision as well. We have chosen not to include
those examples in this final rule, but emphasize that they are still
applicable and encourage readers to review the examples in the Proposed
Rule (84 FR 7520).
We explained that the information blocking provision may also be
implicated if an actor were to discourage efforts to develop or use
interoperable technologies or services by exercising its influence over
customers, users, or other persons, and we provided a non-exhaustive
list of examples. We have chosen not to include those examples in this
final rule, but emphasize that they are still applicable and encourage
readers to review the examples in the Proposed Rule (84 FR 7520).We
noted that similar concerns would arise were an actor to engage in
discriminatory practices--such as imposing unnecessary and burdensome
administrative, technical, contractual, or other requirements on
certain persons or classes of persons--that interfere with access and
exchange of EHI by frustrating or discouraging efforts to enable
interoperability. We provided a list of non-exhaustive examples to
illustrate some ways this could occur. We have chosen not to include
those examples in this final rule, but emphasize that they are still
applicable and encourage readers to review the examples in the Proposed
Rule (84 FR 7520).
Not all instances of differential treatment would necessarily
constitute a discriminatory practice that may implicate the information
blocking provision. For example, we explained that different fee
structures or other terms may reflect genuine differences in the cost,
quality, or value of the EHI and the effort required to provide access,
exchange, or use. We also noted that, in certain circumstances, it may
be reasonable and necessary for an actor to restrict or impose
reasonable and non-discriminatory terms or conditions on the use of
interoperability elements, even though such practices could implicate
the information blocking provision. For this reason, and as further
explained in section VIII.D, we proposed to establish a narrow
exception for licensing interoperability elements (see Sec. 171.303)
that would apply to these types of practices.
Comments. We received some recommendations to describe specific
scenarios when a refusal to license would be considered information
blocking.
Response. We note that for the purposes of the categories of
practices described in the Proposed Rule (84 FR 7518 through 7521), we
did not consider the applicability of any exceptions, and strongly
encouraged readers to review the discussion of practices in this
section in conjunction with the section on the exceptions (84 FR 7518).
Regarding the specific comment above regarding licensing, we direct
readers to our discussion of the Licensing Exception (section
VIII.D.2.c.) for additional examples and a discussion of substantive
conditions we have finalized for the licensing of interoperability
elements under the exception.
We note one important clarification that applies to all examples in
the Proposed Rule concerning the licensing of interoperability
elements. As clarified in the Licensing Exception preamble discussion,
an actor will not implicate the information blocking provision in
circumstances where the entity requesting to license or use the
interoperability element is not seeking to use the interoperability
element to interoperate with either the actor or the actor's customers
in order for EHI to be accessed, exchanged, or used. In other words, if
there is no nexus between a requestor's need to license an
interoperability element and existing EHI, an actor's refusal to
license the interoperability element altogether or in accordance with
Sec. 171.303 would not constitute an interference under the
information blocking provision. We refer readers to the Licensing
Exception preamble discussion in section VIII.D.2.c.
Interference Versus Education When an Individual Chooses Technology To
Facilitate Access
In the Proposed Rule, we stated that the information blocking
provision would likely be implicated when an EHR developer of certified
health IT requires third-party applications to be ``vetted'' for
security before use but does not promptly conduct the vetting or
conducts the vetting in a discriminatory or exclusionary manner (84 FR
7519). We also stated under the proposed ``promoting the privacy of
EHI'' exception that when the consent or authorization of an individual
was necessary for access, exchange, or use of EHI, to qualify for the
exception, an actor must not have improperly encouraged or induced the
individual to not provide the consent or authorization. We further
stated that this does not mean that an actor cannot inform an
individual about the advantages and disadvantages of exchanging EHI and
any associated risks, so long as the information communicated is
accurate and legitimate. However, we noted that an actor could not
mislead an individual about the nature of the consent to be provided,
dissuade individuals from providing consent in respect of disclosures
to the actor's competitors, or impose onerous requirements to
effectuate consent that were unnecessary and not required by law (84 FR
7531).
Overview of Comments
Commenters expressed concerns that app developers not covered by
the HIPAA Rules frequently do not provide patients (individuals) with
clear terms of how their EHI will be subsequently used by the app
developer once patients authorize (approve) the app to receive their
EHI. These commenters, many of whom would be actors under the
information blocking provision, expressed these concerns in comments
recited below, while also requesting clarification about what steps
they may take to assist individuals in protecting the privacy and
security of their EHI.
Comments. Commenters requested that we clarify the extent of
vetting that would be permitted by actors for third-party apps.
Response. We first clarify that the example provided in the
Proposed Rule and recited above was to illuminate practices, such as
delaying access and
[[Page 25815]]
discriminatory behavior, which could implicate the information blocking
provision. ``Vetting'' in the example's context meant a determination
regarding whether the app posed a security risk to the EHR developer's
API, which may be the situation with a proprietary API. For certified
API technology, which includes the use of OAuth2 among other security
requirements in addition to its focus on ``read-only''/responses to
requests for EHI to be transmitted, there should be few, if any,
security concerns about the risks posed by patient-facing apps to the
disclosing actor's health IT systems (because the apps would only be
permitted to receive EHI at the patient's direction). Thus, for third-
party applications chosen by individuals to facilitate their access to
their EHI held by actors, there would generally not be a need for
``vetting'' on security grounds and such vetting actions otherwise
would be an interference. We refer readers to our discussion of
``vetting'' versus verifying an app developer's authenticity under the
API Condition of Certification earlier in section VII.B.4 of this
preamble. We do note, however, that actors, such as health care
providers, have the ability to conduct whatever ``vetting'' they deem
necessary of entities (e.g., app developers) that would be their
business associates under HIPAA before granting access and use of EHI
to the entities. In this regard, covered entities must conduct
necessary vetting in order to comply with the HIPAA Security Rule.
Comments. Several commenters stated that the information blocking
proposals would open the door for third-party apps (e.g., patient-
facing apps) to access, exchange, and use copious amounts of patient
data without providing patients with clear terms of use. Commenters
stated that most individuals may be surprised when commercial
application companies that are not subject to the HIPAA Rules shared
health information obtained from a hospital or health plan, such as
diagnoses, medications, or test results, in ways the HIPAA Rules would
not permit. These commenters asserted that individuals would
incorrectly blame the hospital or health plan if a third-party app
developer sold their EHI or used it for marketing or other purposes.
Additionally, the commenters contended that because the third-party
apps and the third-party app developers are not subject to the HIPAA
Rules, such developers may, through their apps' required terms of use,
grant the developers the right to sell the EHI received or generated by
the app without the individual's consent or could expose all of the
individual's EHI without the individual's knowledge.
Response. This final rule supports an individual's ability to
choose which third-party developer and app are best for receiving all
or part of their EHI from a health care provider and to agree to clear
and public terms of use on how that initial and ongoing engagement with
the third-party developer and app occurs. As discussed in more detail
below, this final rule also supports and strongly encourages providing
individuals with information that will assist them in making the best
choice for themselves in selecting a third-party application. We
believe that allowing actors to provide additional information to
individuals about apps will assist individuals as they choose apps to
receive their EHI and such an approach is consistent with statements in
the Proposed Rule recited above regarding informing individuals about
the advantages and disadvantages of exchanging EHI and any associated
risks. Individuals concerned about information privacy and security can
gain a better understanding about how the third-party apps are using
and storing their EHI, how individuals will be able to exercise any
consent options, and more about what individuals are consenting to
before they allow the app to receive their EHI.
Practices that purport to educate patients about the privacy and
security practices of applications and parties to whom a patient
chooses to receive their EHI may be reviewed by OIG or ONC, as
applicable, if there was a claim of information blocking. However, we
believe it is unlikely these practices would interfere with the access,
exchange, and use of EHI if they meet certain criteria. Foremost, the
information provided by actors must focus on any current privacy and/or
security risks posed by the technology or the third-party developer of
the technology. Second, this information must be factually accurate,
unbiased, objective, and not unfair or deceptive. Finally, the
information must be provided in a non-discriminatory manner. For
example, all third-party apps must be treated the same way in terms of
whether or not information is provided to individuals about the privacy
and security practices employed. To be clear, an actor may not prevent
an individual from deciding to provide its EHI to a technology
developer or app despite any risks noted regarding the app itself or
the third-party developer.
Comments. Several commenters requested that we require actors,
including API technology suppliers, to verify the existence of a
privacy notice for each application requesting registration by an API
User (third-party app developer). Commenters also suggested that the
privacy notices should be commensurate with ONC's Model Privacy Notice
(MPN). One commenter recommended that all third-party developers should
have to attest ``yes'' or ``no'' to having a privacy notice for each
app it makes available for use/(for patients to use) to access EHI. The
commenter asserted that requiring attestation would provide
transparency about the existence or lack of privacy policies and
practices and data uses and serve as a means to support enforcement of
acts of deceptive or misleading conduct in relation to stated privacy
policies and practices.
Response. As noted above, an actor may provide factually accurate,
objective, unbiased, fair, and non-discriminatory information about the
third party or third-party app that an individual chooses to use to
receive EHI on their behalf. And as also noted above, we strongly
encourage actors to educate patients and individuals about the risks of
providing other entities or parties access to their EHI. This type of
education can be designed to inform the patient about the privacy and
security practices of the third party and the third-party app,
including whether the third-party developer has not acted in accordance
with elements of its privacy policy. In this regard, we think there are
many efficient and allowable ways of providing such education without
such practices being considered or creating an interference under the
information blocking provision, including those similar to the one
suggested by the commenter.
For example, to the commenter's specific point, actors may
establish processes where they notify a patient, call to a patient's
attention, or display in advance (as part of the app authorization
process with certified API technology) whether the third-party
developer of the app that the patient is about to authorize to receive
their EHI has attested in the positive or negative whether the third
party's privacy policy and practices (including security practices such
as whether the app encrypts the EHI) meet certain ``best practices''
set by the market for privacy policies and practices. We note that we
identify minimum best practices for third-party privacy policies and
practices below. This notification, would enable a patient to pause,
consider this educational information provided by the actor, and decide
whether to proceed with approving the
[[Page 25816]]
app to receive their EHI or to stop mid-way in the process to do more
research into the app or to pick a different app, in which case the
patient would not approve the original app in question to receive their
EHI. Understandably, in order for an actor to execute this kind of
notification or attention grabbing process and to attribute certain app
developer practices to educational insights provided to a patient in
real-time, certain information may need to be collected by an actor in
advance. Such information may include whether the app developer has a
privacy notice, policies, or practices. Actors providing patients with
educational information (a notice) could help patients better
understand how their EHI may be used by the app and the third-party
developer.
While the ONC 2018 MPN is a voluntary, openly available resource
designed to help developers clearly convey comprehensive information
about their privacy and security policies and practices to their users,
the privacy notice and practices of a third-party developer's app or
personal health record does not have to be identical to the ONC's 2018
MPN. There may be other privacy policies and practices (including
security practices) of third-party developers and apps that accomplish
the same goals and even provide more information relevant to a user. At
a minimum, as it relates to the above, all third-party privacy policies
and practices should adhere to the following:
(1) The privacy policy is made publicly accessible at all times,
including updated versions;
(2) The privacy policy is shared with all individuals that use the
technology prior to the technology's receipt of EHI from an actor;
(3) The privacy policy is written in plain language and in a manner
calculated to inform the individual who uses the technology;
(4) The privacy policy includes a statement of whether and how the
individual's EHI may be accessed, exchanged, or used by any other
person or other entity, including whether the individual's EHI may be
sold at any time (including in the future); and
(5) The privacy policy includes a requirement for express consent
from the individual before the individual's EHI is accessed, exchanged,
or used, including receiving the individual's express consent before
the individual's EHI is sold (other than disclosures required by law or
disclosures necessary in connection with the sale of the application or
a similar transaction).
We note that the market may set different and more stringent
expectations for third-party privacy notices and practices than the
above minimum. As described above and in the examples below, an actor
may provide information or notice to the individual whose EHI is
requested from the actor that the privacy policy that applies to the
technology used to make the request does or does not meet the minimum
privacy policy notice and practices outlined above.
Example 1: Providing education to an individual of a third-party
app developer's privacy and security policies and practices through an
automated attestation and warning process.
An API User (third-party app developer) develops a software
application (named ``App-Y'') and registers it with the Certified API
Developer's (developer of certified health IT) authorization server.
During the registration process, the Certified API Developer requests,
as a business associate and on behalf of a HIPAA covered entity, that
the API User attest that for App-Y, the API User follows the privacy
policies and practices outlined above. Given the ``yes or no'' choice,
the API User attests ``no.'' The Certified API Developer completes App-
Y's registration process and provides it with a client identifier. An
individual seeks to use App-Y to obtain their EHI from the health care
provider (covered entity) that is a customer of the Certified API
Developer. The individual then opens App-Y on their smartphone and
after authenticating themselves to their health care provider (covered
entity), but prior to the app receiving the EHI from the health care
provider, the patient is provided with an app authorization screen
controlled by the health care provider.
Using the certified API technology and the normal OAuth2 workflow
the patient is asked by the health care provider via the app
authorization screen whether they want to approve or reject App-Y's
ability to receive their EHI via certified API technology. On the
authorization screen, there is a ``warning'' from the health care
provider that the application has not ``attested'' to having privacy
policies and practices that adhere to the minimum policies and
practices outlined above or to having other specified privacy and
security policies. When presented with that warning, the patient has
two choices: (1) Choose to ignore the warning and approve App-Y's
ability to receive their EHI and App-Y receives the patient's PHI; or
(2) reject App-Y's ability to receive their EHI, and the health care
provider does not provide the patient's EHI to App-Y.
Example 2: Patient sending EHI using certified health IT
capabilities provided by health IT developer.
An individual has made an appointment with a health care specialist
for a second medical opinion. During the initial scheduling, the
administrative staff requested that the individual bring all their
prior health information to the specialist. The patient portal of the
individual's primary care provider allows EHI to be transmitted to a
third party using Direct protocol. The individual identifies a third-
party app that is able to receive EHI using Direct protocol and creates
an account with the app as well as obtain/create a ``Direct address.''
During the account creation process with the app, the individual
reviews the ``privacy policy'' for the app. The third-party app also
sends the individual a copy of the privacy policy via email once the
individual completes the account creation process.
Subsequently, the individual logs into the primary care provider's
portal to transmit her EHI to her direct address linked to her new
account on the third-party app. Her provider uses certified health IT
that is capable of sending EHI securely using Direct protocol to third-
party organizations (including apps) with which they have exchanged
trust anchors. It turns out, the health care provider has established
prior trust with the third-party app and is able to send EHI to the
application. To note, this health care provider may offer education,
including a warning (notice), to the patient, as discussed above, if
the provider is being directed by the patient to transmit their EHI to
a recipient that is unknown to the provider.
Prior to sending the EHI, the portal provides a summary screen that
provides the privacy policy ``warning'' about the third-party app. The
patient reviews and accepts it. The provider's system/API technology
sends EHI to her Direct address. The patient logs into her application
and confirms that the EHI has been received.
Comments. Commenters stated that, given the access to personal
health information that patient-directed third-party apps are expected
to have and the potential privacy risks they pose, a process should be
implemented by the Federal Trade Commission (FTC) to vet apps for the
adequacy of the consumer disclosures which should include the privacy
and security of the information and secondary uses that should be
permitted. A commenter suggested that the vetting process should be at
the application and application developer
[[Page 25817]]
level, and that the results of such vetting process should be made
public in the form of an application ``safe list.''
Response. The privacy practices of developers of patient-facing
health IT products and services are typically regulated by the Federal
Trade Commission Act (FTC Act). The FTC Act prohibits unfair or
deceptive acts or practices in or affecting commerce (15 U.S.C.
45(a)(1)), but it does not prescribe specific privacy requirements. The
FTC has authority to enforce the FTC Act's prohibition on deception,
for example, by challenging deceptive statements made in privacy
policies, user interfaces, FAQs, or other consumer-facing materials.
The FTC could also, for example, challenge a particular use or
disclosure of EHI as unfair if it causes or is likely to cause
substantial injury to consumers that is not reasonably avoidable by
consumers themselves and not outweighed by countervailing benefits to
consumers or to competition (15 U.S.C. 45(n)). We will continue to work
with our Federal partners, including the FTC, to assess education
opportunities for consumers and app developers about the privacy and
security of EHI collected, used, or received by health apps.
Comments. A commenter recommended the development of a privacy
framework regarding how health information should be shared and to
empowering consumers; and it noted that it should be developed and
matured in concert with the modernization of our nation's health IT
infrastructure. They expressed that there are private sector and
public-private examples of models that we should look to from both
health care and other industries. They believed that the Proposed Rule
does not, however, fully address patient and consumer privacy
protections. They recommended that the Center for Medicare and Medicaid
Services and ONC should work together with relevant agencies and
departments and private-sector colleagues to develop a companion
consumer privacy framework.
Response. We are aware of various industry initiatives regarding a
``privacy framework.'' We have previously published the Nationwide
Privacy and Security Framework for Electronic Exchange of Individually
Identifiable Health Information; \130\ produced, in cooperation with
the FTC, FDA, and OCR, the Mobile Health Apps Interactive Tool; \131\
and more recently published and developed the Privacy and Security
Framework for Patient-Centered Outcomes Research (PCOR). This project
developed tools and resources that address the many different types of
data that can be used to conduct patient-centered outcomes research.
The framework consists of two initiatives: The Legal and Ethical
Architecture for PCOR Data (Architecture), which guides readers through
the responsible use and protection of electronic health data for PCOR
and The Patient Choice Technical Project which harmonized existing
technical mechanisms to enable interoperable exchange of patient
consent for basic and granular choice for research and treatment,
payment, and health care operations. This project, which remains
active, also identifies, tests and validates technical standards that
support an individual's consent preferences.\132\
---------------------------------------------------------------------------
\130\ https://www.healthit.gov/sites/default/files/nationwide-ps-framework-5.pdf.
\131\ https://www.ftc.gov/tips-advice/business-center/guidance/mobile-health-apps-interactive-tool.
\132\ See https://www.healthit.gov/topic/scientific-initiatives/pcor/privacy-and-security-framework-pcor-psp.
_____________________________________-
We will continue to monitor how individuals are educated about
potential privacy and security risks of third-party apps and will
continue to work with HHS OCR and industry stakeholders to further
educate individuals as part of our implementation of section 4006 of
the Cures Act. In this regard, we also encourage individuals to review
consumer education materials related to protecting their EHI on our
website at healthit.gov (``What You Can do to Protection Your Health
Information''--https://www.healthit.gov/topic/privacy-security/what-you-can-do-protect-your-health-information; and ``Health IT: How to
Keep Your Health Information Privacy and Secure: Fact Sheet''--https://www.healthit.gov/sites/default/files/how_to_keep_your_health_information_private_and_secure.pdf).
Comments. Commenters expressed concerns that if patients access
their health data--some of which could contain family history and could
be sensitive--through a smartphone, they should have a clear
understanding of the potential uses of that data by third-party app
suppliers.
Response. Under the HIPAA Privacy Rule, when a covered health care
provider, in the course of treating an individual, collects or
otherwise obtains an individual's family medical history, this
information may become part of the individual's medical record (45 CFR
164.501 (definition of ``Designated Record Set''). Thus, if the family
medical history becomes part of the medical record, the individual/
patient may exercise the rights under the HIPAA Privacy Rule, 45 CFR
164.524, to this information in the same fashion as any other
information in the medical record, including the right of access. As
discussed above, actors may educate patients of the risks related to
providing other persons and entities with their EHI, including the
various the types of EHI (e.g., family health history) that will be
provided to an entity (e.g., third-party app) at the patient's request.
iv. Rent-Seeking and Other Opportunistic Pricing Practices
Certain practices that artificially increase the cost and expense
associated with accessing, exchanging, and using EHI may implicate the
information blocking provision. We emphasized in the Proposed Rule that
such practices are plainly contrary to the information blocking
provision and the concerns that motivated its enactment.
We explained that an actor may seek to extract profits or capture
revenue streams that would be unobtainable without control of a
technology or other interoperability elements that are necessary to
enable or facilitate access, exchange, or use of EHI. Most EHI is
currently stored in EHRs and other source systems that use proprietary
data models or formats; this puts EHR developers (and other actors that
control data models or standards) in a unique position to block access
to (including the export and portability of) EHI for use in competing
systems or applications or to charge rents for access to the basic
technical information needed to accomplish the access, exchange, or use
of EHI for these purposes. We emphasized that these information
blocking concerns may be compounded to the extent that EHR developers
do not disclose, in advance, the fees they will charge for interfaces,
data export, data portability, and other interoperability-related
services (see 80 FR 62719 through 62725; 80 FR 16880 through 16881). We
noted that these concerns are not limited to EHR developers. Other
actors who exercise substantial control over EHI or essential
interoperability elements may engage in analogous behaviors that would
implicate the information blocking provision (84 FR 7520).
To illustrate, we provided a list of non-exhaustive examples that
reflected some of the more common types of rent-seeking and
opportunistic behaviors of which we were aware and that are likely to
interfere with access, exchange, or use of EHI. Those examples are
still applicable and we encourage readers to
[[Page 25818]]
review the examples in the Proposed Rule (84 FR 7520 and 7521).
The information blocking provision may be implicated by these and
other practices by which an actor profits from its unreasonable control
over EHI or interoperability elements without adding any efficiency to
the health care system or serving any other pro-competitive purpose.
However, we stressed that the reach of the information blocking
provision is not limited to these types of practices. We interpreted
the definition of information blocking to encompass any fee that
materially discourages or otherwise imposes a material impediment to
access, exchange, or use of EHI. We used the term ``fee'' in the
broadest possible sense to refer to any present or future obligation to
pay money or provide any other thing of value and proposed to include
this definition in Sec. 171.102. We noted that this scope may be
broader than necessary to address genuine information blocking concerns
and could unnecessarily diminish investment and innovation in
interoperable technologies and services. Therefore, as further
explained in section VIII.D, we proposed to create an exception that,
subject to certain conditions, would permit the recovery of costs that
are reasonably incurred to provide access, exchange, and use of EHI (84
FR 7521).
Comments. We did not receive comments specifically on our proposed
definition of ``fee.''
Response. We have finalized the definition in Sec. 171.102 as
proposed.
Comments. A few commenters requested additional examples and
clarity on the types of rent-seeking and opportunistic pricing
practices that would be likely to implicate the information blocking
provision.
Response. We refer readers to our discussion of the Fees Exception
(section VIII.D.2.b.) for additional examples, as well as for a
detailed discussion of fees that may and may not be charged under this
exception.
v. Non-Standard Implementation Practices
We explained in the Proposed Rule that section 3022(a)(2)(B) of the
PHSA states that information blocking may include implementing health
IT in non-standard ways that substantially increase the complexity or
burden of accessing, exchanging, or using EHI. In general, this type of
interference is likely to occur when, despite the availability of
generally accepted technical, policy, or other approaches that are
suitable for achieving a particular implementation objective, an actor
does not implement the standard, does not implement updates to the
standard, or implements the standard in a way that materially deviates
from its formal specifications. We noted that these practices lead to
unnecessary complexity and burden, such as the additional cost and
effort required to implement and maintain ``point-to-point''
connections, custom-built interfaces, and one-off trust agreements.
While each case will necessarily depend on its individual facts,
and while we recognized that the development and adoption of standards
across the health IT industry is an ongoing process, we explained that
the information blocking provision would be implicated in at least two
distinct sets of circumstances. First, we stated that information
blocking may arise where an actor chooses not to adopt, or to
materially deviate from, relevant standards, implementation
specifications, and certification criteria adopted by the Secretary
under section 3004 of the PHSA. Second, even where no federally adopted
or identified standard exists, if a particular implementation approach
has been broadly adopted in a relevant industry segment, deviations
from that approach would be suspect unless strictly necessary to
achieve substantial efficiencies.
To further illustrate these types of practices that may implicate
the information blocking provision, we provided a list of non-
exhaustive examples of conduct that would be likely to interfere with
access, exchange, or use of EHI. We have chosen not to include those
examples in this final rule, but emphasize that they are still
applicable and encourage readers to review the examples in the Proposed
Rule (84 FR 7521).
We explained that even where no standards exist for a particular
purpose, actors should not design or implement health IT in non-
standard ways that unnecessarily increase the costs, complexity, and
other burdens of accessing, exchanging, or using EHI. We also noted
that we were aware that some actors attribute certain non-standard
implementations on legacy systems that the actor did not themselves
design but which have to be integrated into the actor's health IT. We
noted that such instances will be considered on a case-by-case basis.
Comments. A few commenters requested additional clarity on when
non-standard based interoperability is permissible. Some commenters
urged ONC to be careful and flexible in its interpretation of this
information blocking practice given the complexities of health IT
implementation, such as implementing newly adopted standards or
requirements. One commenter highlighted the importance of being able to
retain certain types of optionality, especially for specialized use
cases. Other commenters expressed concern that considering non-standard
implementation practices as likely to implicate the information
blocking provision could have the unintended consequence of stymying
innovative or novel technologies used in information exchange.
Response. We appreciate the commenters' suggestions. We emphasize
that the problematic nature of non-standard design and implementation
choices was identified by Congress in section 3022(a)(2)(B) of the
PHSA, which states that information blocking may include implementing
health IT in non-standard ways that are likely to substantially
increase the complexity or burden of accessing, exchanging, or using
EHI. We continue to be concerned that these practices will lead to
unnecessary complexity and burden related to the access, exchange, or
use of EHI, and depending on the circumstances, we maintain that such
practices would be likely to interfere with access, exchange, or use of
EHI. We refer readers to the discussion of this topic in the Fees
Exception (section VIII.D.2.b).
We also agree, however, that we must give each case careful
consideration and assess the individual facts and circumstances to
determine whether such practices would be likely to interfere with
access, exchange, or use of EHI.
7. Applicability of Exceptions
a. Reasonable and Necessary Activities
Section 3022(a)(3) of the PHSA requires the Secretary to identify,
through notice and comment rulemaking, reasonable and necessary
activities that do not constitute information blocking for purposes of
the definition in section 3022(a)(1). Section 3022(a)(1) of the PHSA
defines information blocking by referring to practices likely to
interfere with, prevent or materially discourage access, exchange or
use of electronic health information. Based on this terminology used in
the PHSA, we noted that conduct that implicates the information
blocking provision and that does not fall within one of the exceptions
or does not meet all conditions for an exception, would be considered a
``practice.'' Conduct that falls within an exception and meets all the
applicable conditions for that exception would be considered
[[Page 25819]]
an ``activity.'' We noted that the challenge with this distinction is
that when examining conduct that is the subject of an information
blocking claim--an actor's actions that are likely to interfere with
access, exchange, or use of EHI--it can be illusory to distinguish, on
its face, conduct that is a practice and conduct that is an activity.
Indeed, conduct that implicates the information blocking provision but
falls within an exception could nonetheless be considered information
blocking if the actor has not satisfied the conditions applicable to
that exception.
Acknowledging the terminology used in the PHSA, we proposed to
define ``practice'' in Sec. 171.102 as one or more related acts or
omissions by an actor.
We also proposed to use the term ``practice'' throughout the
Proposed Rule when we described conduct that is likely to interfere
with, prevent, or materially discourage the access, exchange, or use of
EHI, and clarify when describing the conduct at issue whether it is a
practice that is information blocking, a practice that implicates the
information blocking provision, or a practice that is reasonable and
necessary and not information blocking (84 FR 7522). We stated that
adopting the terminology of ``activity'' to describe conduct that may
or may not be information blocking would be confusing and obfuscate our
intent in certain circumstances. Consistent with this approach, when
describing the exceptions in the final rule, we describe practices
that, if all the applicable conditions are met, are reasonable and
necessary and not information blocking.
Comments. We received no comments specifically on the distinction
between ``activities'' and ``practices'' and our proposed definition
and use of the term ``practice.''
Response. We have finalized the definition of ``practice'' in Sec.
171.102 as ``an act or omission by an actor.'' This definition is a
modification of the proposed definition, which was ``one or more
related acts or omissions by an actor.'' We finalized this definition
of ``practice'' in order to clarify that a practice need only be a
single act or omission. This modification does not substantively change
the proposed definition, as we included in the proposed definition that
a ``practice'' could be one act or omission.
We have finalized the use of the term ``practice,'' rather than the
term ``activity,'' to describe conduct that is likely to interfere
with, prevent or materially discourage the access, exchange, or use of
EHI. We have also finalized our approach that when identifying
exceptions, we describe practices that, if all the applicable
conditions are met, are reasonable and necessary and not information
blocking.
b. Treatment of Different Types of Actors
We explained in the Proposed Rule that the proposed exceptions
would apply to health care providers, health IT developers of certified
health IT, HIEs, and HINs who engage in certain practices covered by an
exception, provided that all applicable conditions of the exception are
satisfied at all relevant times and for each practice for which the
exception is sought. We noted that the exceptions are generally
applicable to all actors. However, in some instances, we proposed
conditions within an exception that apply to a particular type of
actor.
Comments. Several commenters agreed that the exceptions should
apply to all actors. A few commenters requested that ONC identify
exceptions that apply to all actors and identify exceptions that only
apply to select actors.
Response. We appreciate the support for our approach to the
exceptions, as well as the suggestion to restructure the exceptions. We
continue to believe that the clearest and most equitable approach to
the exceptions is to make all of the exceptions apply to all actors, as
proposed. We have addressed the commenters' concerns by creating
conditions within certain exceptions that apply to one or a subset of
actors, as applicable.
c. Establishing That Practices Meet the Conditions of an Exception
We proposed that, in the event of an investigation of an
information blocking complaint, an actor must demonstrate that an
exception is applicable and that the actor met all relevant conditions
of the exception at all relevant times and for each practice for which
the exception is sought (84 FR 7522). We considered this allocation of
proof to be a substantive condition of the proposed exceptions. As a
practical matter, we proposed that actors are in the best position to
demonstrate compliance with the conditions of the exceptions and to
produce the detailed evidence necessary to demonstrate that compliance.
We requested comment about the types of documentation and/or
standardized methods that an actor may use to demonstrate compliance
with the exception conditions.
Comments. Many commenters requested clarification regarding the
type and amount of documentation required to demonstrate that they have
met an exception. In particular, many commenters noted that meeting the
exceptions will substantially increase documentation burden and other
administrative costs for actors. Commenters also noted that
organizations may need to update, develop and/or implement policies and
procedures focused on documenting compliance with information blocking
exceptions. Many commenters requested that ONC develop and provide
examples, templates, and guidance on the type of documentation that
would be acceptable to support the conditions for each information
blocking exception. Several commenters noted that the supporting
documentation should clearly demonstrate why the actor qualifies for
the exception, why the exception is required, and how all conditions of
the exception are fulfilled. One commenter asked that we provide
guidance on the appropriate storage method for this documentation, as
this information may not be appropriate for the clinical record.
Response. We thank commenters for these thoughtful comments and
suggestions. We have tailored the exceptions and provided significant
detail within each exception to clearly explain what an actor must do
to meet each exception. For each exception, we have proposed and
finalized conditions that we believe can be consistently applied across
a range of actors and practices and also further the goals of the
information blocking provision. For some exceptions, this includes a
writing or documentation requirement to demonstrate that the practice
precisely meets all of the conditions to afford an actor the enhanced
assurance an exception offers. Many of these conditions are related to
other existing regulatory requirements that have similar documentation
standards. For example, an actor's practice may meet the Security
Exception at Sec. 171.203 if it is consistent with an organizational
security policy and that policy meets several requirements. We expect
that many actors have existing organizational security policies based
on the ``Policy and procedures and documentation requirements'' in the
HIPAA Security Rule at 45 CFR 164.316. Consequently, the burden
associated with meeting the documentation requirement in the Security
Exception should be less if actors are already complying with the HIPAA
Security Rule.
We encourage actors to voluntarily comply with an exception so that
their practices do not meet the definition of information blocking and
are not subject
[[Page 25820]]
to information blocking enforcement. However, failure to meet an
exception does not necessarily mean a practice meets the definition of
information blocking. If subject to an investigation, each practice
that implicates the information blocking provision and does not meet an
exception would be analyzed on a case-by-case basis to evaluate, for
example, whether it rises to the level of an interference, and whether
the actor acted with the requisite intent.
D. Exceptions to the Information Blocking Definition
We proposed to establish seven exceptions to the information
blocking provision. The exceptions would apply to certain practices
that may technically meet the definition of information blocking but
that are reasonable and necessary to further the underlying public
policies of the information blocking provision. We appreciate that most
actors will want to meet an exception to guarantee that their practice
or practices do not meet the definition of information blocking and be
subject to enforcement. The statute defines information blocking
broadly and in a manner that allows for careful consideration of
relevant facts and circumstances in individual cases, which includes
analysis of an actor's intent and whether it meets the requisite
knowledge standard.
The proposed exceptions were based on three related policy
considerations. First, each exception was limited to certain activities
that clearly advance the aims of the information blocking provision.
These reasonable and necessary activities included providing
appropriate protections to prevent harm to patients and others;
promoting the privacy and security of EHI; promoting competition and
innovation in health IT and its use to provide health care services to
consumers, and to develop more efficient means of health care delivery;
and allowing system downtime to implement upgrades, repairs, and other
changes to health IT. Second, each proposed exception addressed a
significant risk that regulated actors will not engage in these
beneficial activities because of uncertainty concerning the breadth or
applicability of the information blocking provision. Finally, each
exception was subject to strict conditions to ensure that it was
limited to activities that are reasonable and necessary.
We explained that the first three exceptions extended to certain
activities that are reasonable and necessary to prevent harm to
patients and others; promote the privacy of EHI; and promote the
security of EHI, subject to strict conditions to prevent the exceptions
from being misused. We discussed that without these exceptions, actors
may be reluctant to engage in the reasonable and necessary activities
and that this could erode trust in the health IT ecosystem and
undermine efforts to provide access and facilitate the exchange and use
of EHI for important purposes. We stressed that such a result would be
contrary to the purpose of the information blocking provision and the
broader policies of the Cures Act.
We explained that the next three exceptions addressed activities
that are reasonable and necessary to promote competition and consumer
welfare. First, we proposed to permit the recovery of certain types of
reasonable costs incurred to provide technology and services that
enable access to EHI and facilitate the exchange and use of that
information, provided certain conditions are met. Second, we proposed
to permit an actor to decline to provide access, exchange, or use of
EHI in a manner that is infeasible, subject to a duty to provide a
reasonable alternative. And third, we proposed an exception that would
permit an actor to license interoperability elements on reasonable and
non-discriminatory terms. We emphasized that the exceptions would be
subject to strict conditions to ensure that they do not extend
protection to practices that raise information blocking concerns.
The last exception recognized that it may be reasonable and
necessary for actors to make health IT temporarily unavailable for the
benefit of the overall performance of health IT. This exception would
permit an actor to make the operation of health IT unavailable to
implement upgrades, repairs, and other changes.
As context for the proposed exceptions, we noted that addressing
information blocking is critical for promoting competition and
innovation in health IT and for the delivery of health care services to
consumers. We noted that the information blocking provision itself
expressly addresses practices that impede innovation and advancement in
health information access, exchange, and use, including care delivery
enabled by health IT (section 3022(a)(2)(C)(ii) of the PHSA). We also
noted that health IT developers of certified health IT, HIEs, HINs,
and, in some instances, health care providers, may exploit their
control over interoperability elements to create barriers to entry for
competing technologies and services that offer greater value for health
IT customers and users, provide new or improved capabilities, and
enable more robust access, exchange, and use of EHI.\133\ More than
this, we emphasized that information blocking may harm competition not
just in health IT markets, but also in markets for health care
services.\134\ Dominant providers in these markets may leverage their
control over technology to limit patient mobility and choice.\135\ They
may also pressure independent providers to adopt expensive, hospital-
centric technologies that do not suit their workflows, limit their
ability to share information with unaffiliated providers, and make it
difficult to adopt or use alternative technologies that could offer
greater efficiency and other benefits.\136\ The technological
dependence resulting from these practices can be a barrier to entry by
would-be competitors. It can also make independent providers vulnerable
to acquisition or induce them into exclusive arrangements that enhance
the market power of incumbent providers while preventing the formation
of clinically-integrated products and networks that offer more choice
and better value to consumers and purchasers of health care services.
---------------------------------------------------------------------------
\133\ See also Martin Gaynor, Farzad Mostashari, and Paul B.
Ginsberg, Making Health Care Markets Work: Competition Policy for
Health Care, 16-17 (Apr. 2017), available at http://heinz.cmu.edu/news/news-detail/index.aspx?nid=3930.
\134\ See, e.g., Keynote Address of FTC Chairwoman Edith
Ramirez, Antitrust in Healthcare Conference Arlington, VA (May 12,
2016), available at https://www.ftc.gov/system/files/documents/public_statements/950143/160519antitrusthealthcarekeynote.pdf.
\135\ See, e.g., Martin Gaynor, Farzad Mostashari, and Paul B.
Ginsberg, Making Health Care Markets Work: Competition Policy for
Health Care, 16-17 (Apr. 2017), available at http://heinz.cmu.edu/news/news-detail/index.aspx?nid=3930.
\136\ See, e.g., Healthcare Research Firm Toughens Survey
Standards as More CIOs Reap the Profits of Reselling Vendor
Software, Black Book, available at http://www.prweb.com/releases/2015/02/prweb12530856.htm; Arthur Allen, Connecticut Law Bans EHR-
linked Information Blocking, Politico.com (Oct. 29, 2015).
---------------------------------------------------------------------------
We noted in the Proposed Rule that section 3022(a)(5) of the PHSA
provides that the Secretary may consult with the Federal Trade
Commission (FTC) in defining practices that do not constitute
information blocking because they are necessary to promote competition
and consumer welfare. We expressed appreciation for the expertise and
informal technical assistance of FTC staff, which we took into
consideration in developing the exceptions for recovering costs
reasonably incurred, responding to requests that are infeasible, and
licensing of interoperability elements on reasonable and non-
discriminatory terms. We noted that the language in the Cures Act
regarding information blocking is substantively and substantially
different
[[Page 25821]]
from the language and goals in the antitrust laws enforced by the FTC.
We explained that we view the Cures Act as addressing conduct that may
be considered permissible under the antitrust laws. On this basis, the
Proposed Rule required that actors who control interoperability
elements cooperate with individuals and entities that require those
elements for the purpose of developing, disseminating, and enabling
technologies and services that can interoperate with the actor's
technology.
We emphasized that ONC took this approach because we view patients
as having an overwhelming interest in EHI about themselves. As such,
access to EHI, and the EHI itself, should not be traded or sold by
those actors who are custodians of EHI or who control its access,
exchange, or use. We emphasized that such actors should not be able to
charge fees for providing electronic access, exchange, or use of
patients' EHI. We explained that the information blocking provision
prohibits actors from interfering with the access, exchange, or use of
EHI unless they are required to do so under an existing law or are
covered by one of the exceptions detailed in this preamble. In
addition, we explained that any remedy sought or action taken by HHS
under the information blocking provision would be independent of the
antitrust laws and would not prevent FTC or DOJ from taking action with
regard to the same actor or conduct.
We proposed to include a provision in Sec. 171.200 that addresses
the availability and effect of exceptions.
We requested comment on the seven proposed exceptions, including
whether they will achieve our stated policy goals.
Comments. We received comments regarding each of the proposed
exceptions.
Response. We have responded to the comments regarding each
exception in the preamble discussions for each exception. Overall, we
have made modifications to the structure and scope of the proposed
exceptions.
In this final rule, we have restructured the proposed exceptions
(proposed in Sec. Sec. 171.201-207) and have added another exception
for clarity. In addition, we have divided the exceptions into two
categories: (1) Exceptions that involve not fulfilling requests to
access, exchange, or use EHI, which are finalized in Sec. Sec.
171.201-205; and (2) exceptions that involve procedures for fulfilling
requests to access, exchange, or use EHI, which are finalized in
Sec. Sec. 171.301-303. We also changed the titles of the exceptions to
questions for additional clarity. We believe this new structure will
help actors better understand our expectations of them and enhance
transparency around the exceptions.
We note that we use the term ``fulfill'' throughout the exceptions
in the context of an actor ``fulfilling'' a request to access,
exchange, or use EHI. This term is intended to reflect not just a
response to a request to access, exchange, or use EHI, but also making
the EHI available for the requested access, exchange, or use.
We have finalized the seven exceptions with modifications discussed
below. Based on requests for comment we included in the Proposed Rule
regarding the scope of the EHI definition (84 FR 7513) and the
Infeasibility Exception (84 FR 7542 through 7544), we have also
established a new exception in Sec. 171.301 (referred to as the
Content and Manner Exception) under section 3022(a)(3) of the PHSA as a
means to identify reasonable and necessary activities that do not
constitute information blocking. We discuss the details of the new
Content and Manner Exception in section VIII.D.2.a of this preamble.
We appreciate the FTC's comments on the Proposed Rule and the
expertise and informal technical assistance provided by FTC staff for
this final rule, which we took into consideration throughout our
development of the final rule, including as it relates to the
definitions of various terms in the final rule (e.g., the definitions
of ``electronic health information'' and ``health information network''
(discussed above)) and the exceptions (e.g., the Infeasibility
Exception, Fees Exception, and Licensing Exception; as well as the
establishing of the new Content and Manner Exception).
Comments. We did not receive any comments on the provision in Sec.
171.200.
Response. We have finalized Sec. 171.200 as proposed and have
included an identical provision in Sec. 171.300 that is applicable to
Part C. This addition was necessary based on the new structure of the
exceptions discussed above.
1. Exceptions that involve not fulfilling requests to access,
exchange, or use EHI
a. Preventing Harm Exception -- When will an actor's practice that
is likely to interfere with the access, exchange, or use of electronic
health information in order to prevent harm not be considered
information blocking?
We proposed to establish an exception to the information blocking
provision in Sec. 171.201 that would apply to certain practices that
are reasonable and necessary to prevent harm to a patient or another
person. As discussed in the Proposed Rule's preamble (84 FR 7523 and
7524), this exception is intended to allow for the protection of
patients and other particular persons against substantial risks of harm
otherwise arising from the access, exchange, or use of EHI in defined
circumstances. Strict conditions were proposed to prevent this
exception from being misused.
As explained in the Proposed Rule, we use the term ``patient'' to
denote the context in which the threat of harm arises (84 FR 7523).
That is, this exception has been designed to recognize practices taken
for the benefit of recipients of health care -- those individuals whose
EHI is at issue -- and other persons whose information may be recorded
in that EHI or who may be at risk of harm because of the access, use,
or exchange of the EHI. This use of the term ``patient'' in the
Proposed Rule did not imply that practices to which the exception is
applicable could be implemented only by the licensed health
professionals with a clinician-patient relationship to the person whose
EHI is affected by the practices.
This exception was proposed to apply to practices when the actor
engaging in a practice has a reasonable belief that the practice will
directly and substantially reduce a risk of harm to the patient, and/or
other particular individuals, that would otherwise arise from the
particular access, exchange, or use of EHI affected by the practices.
We proposed that actors including but not limited to health care
providers would, consistent with conditions of the exception applicable
to the circumstances in which the practices are used, be able to engage
in practices recognized under this exception without the actor needing
to have a clinician-patient relationship with any of the individuals at
risk of harm.
Comments. Of more than ninety comment submissions specifically
referencing the Preventing Harm Exception, half expressed overarching
or general support for the exception. None of the comments specifically
referencing this exception expressed opposition to the exception. Some
commenters advocated broadening certain aspects of the proposed
exception, as discussed in more detail below. Several other commenters
expressed support for a relatively narrow exception, and a few of these
commenters recommended that once the final rule is effective ONC should
engage in monitoring to ensure the exception is not abused in practice.
Many commenters requested
[[Page 25822]]
clarification on specific points, or expressed concerns or suggested
modifications to particular aspects of the exception, as will be
discussed in more detail below.
Response. We appreciate the many thoughtful comments on the value
of this exception, particular aspects of the proposed exception, and
areas where we could streamline how we express the policy so it is
easier to understand. Considering all of the comments received, we have
decided to finalize the exception largely as proposed, with
modifications to better align with HIPAA Rules as discussed below and
to make the regulation text more easily understood. These revisions
include modification of the title of Sec. 171.201, from ``Exception--
Preventing Harm'' (84 FR 7602) to ``Preventing Harm Exception -- When
will an actor's practice that is likely to interfere with the access,
exchange, or use of electronic health information in order to prevent
harm not be considered information blocking?'' Throughout this
preamble, we use ``Preventing Harm Exception'' as a short title for
ease of reference to the exception that has been finalized in Sec.
171.201.
Comments. Several comments suggested broadening the scope of the
exception to allow a broader array of actors to decide what might pose
a risk of harm to a patient.
Response. The finalized exception is, as we proposed it would be,
available to any actor defined in Sec. 171.102, provided that the
actor's use of a practice for purposes of harm prevention meets the
conditions in Sec. 171.201. Only where practices are applied to a
specific patient's EHI and based upon a determination of a risk of harm
by a licensed health care professional in the exercise of professional
judgment does this exception explicitly require the determination to
have been made by a particular subset of actors within the definitions
in Sec. 171.102. In order to meet the risk of harm condition based on
an individualized determination consistent with Sec. 171.201(c)(1),
the licensed health care professional who made the determination must
have done so in context of a current or prior clinician-patient
relationship with the patient whose EHI is affected by the
determination.\137\ However, other actors -- such as other health care
providers treating the same patient, or an HIE/HIN supporting access,
exchange, or use of the patient's EHI -- could rely on such a
determination of a risk of harm. The actor's knowledge of a licensed
health care professional's individualized determination (consistent
with Sec. 171.201(c)(1)) that access, exchange, or use posed a risk of
a harm of a type consistent with Sec. 171.201(d)(1), (2), or (3) (as
applicable) could factor into a determination based on facts and
circumstances known or reasonably believed by the actor (consistent
with the condition finalized Sec. 171.201(f)(2)).
---------------------------------------------------------------------------
\137\ For purposes of this exception, we interpret ``clinician-
patient relationship'' to include any therapeutic or relationship
where the licensed health care professional has or at some point had
some clinical responsibility for or to the patient within the
professional's scope of practice. Thus, a clinician-patient
relationship on which a qualifying individualized determination of
risk of harm could be one of substantial duration over time or
formed in the course of the first or only occasion on which the
clinician furnishes or furnished professional services to the
patient in any setting, including but not limited to telehealth.
---------------------------------------------------------------------------
An actor could also implement practices based on knowledge of an
individualized determination of risk (Sec. 171.201(c)(1)) of harm of a
type consistent with Sec. 171.201(d)(1), (2), or (3) as applicable and
based on an organizational policy (consistent with the condition
finalized Sec. 171.201(f)(1)). Thus, the exception is broad enough to
cover all actors implementing practices that meet its conditions. We
are finalizing this aspect of the exception as proposed, with
clarifications to the regulation text to make it easier to understand
what the specific conditions of the Preventing Harm Exception are and
how they relate to one another.
Comments. A large number of commenters requested additional
guidance in this final rule preamble or through other avenues. For
example, some commenters requested sub-regulatory guidance and
educational resource materials to further illustrate and help actors
understand how the Preventing Harm Exception might apply or what it
might require without a stakeholder needing to raise particular
questions or hypothetical fact patterns.
Response. With the revisions we have made to this exception, we do
not believe sub-regulatory guidance is necessary for actors who wish to
avail themselves of this exception to understand the Preventing Harm
Exception, its conditions, or to conform their practices to the
conditions. We have made revisions to the regulation text to provide
enhanced clarity, such as separately expressing each of its substantive
conditions and incorporating granular alignment to 45 CFR 164.524(a)(3)
harm standards. This final rule preamble provides additional
information and feedback through discussion of the particular questions
and suggestions posed by various commenters and this preamble's
statements of finalized policy. We will also provide, in connection to
this final rule, educational resources such as infographics, fact
sheets, webinars, and other forms of educational materials and
outreach. We emphasize, however, that we believe the final rule clearly
describes our information blocking policies, and these educational
materials are intended only to educate stakeholders on our final
policies established in the final rule.
Comments. Several commenters questioned whether ``directly and
substantially'' may be a more stringent standard than is necessary for
the reduction of risk of harm to a patient or to another person. A
number of commenters indicated it could be difficult for actors to know
where to draw the line between direct and indirect reductions of risk
of harm, given the potential for reasonable minds to disagree on the
extent to which a risk arises directly, as opposed to indirectly, from
the EHI access, exchange, or use affected by a practice. Several
commenters recommended, as an alternative, that the condition be that
the actor have a reasonable belief the practice is ``reasonably
likely'' to reduce a risk of harm.
Response. After considering comments received, we have finalized in
Sec. 171.201(a) that the actor must hold a reasonable belief that the
practice ``will substantially reduce'' a risk of harm to a patient or
another natural person. In comparison to the regulation text of this
exception in the Proposed Rule (84 FR 7602), we have removed
``directly'' from the finalized text of Sec. 171.201(a). We believe
omitting ``directly'' from the finalized condition obviates concerns
about actors' ability to determine whether the practice directly
reduces a risk of harm that could itself arise indirectly. We have
retained ``substantially'' in the finalized Sec. 171.201(a) because we
believe it is necessary to ensure this exception cannot be misused to
justify practices that interfere with access, exchange, or use of EHI
to achieve only a trivial or illusory reduction in risk of harm. By
extension, we interpret a ``substantial reduction'' as necessarily
implying that the risk intended to be reduced was itself substantial
and not trivial or illusory.
We note that the harm standard under Sec. 164.524(a)(3) of the
HIPAA Rules includes that the access requested be ``reasonably likely''
to cause the type of harm described in the sub-paragraph applicable to
a particular denial of access under Sec. 164.524(a)(3). As discussed
in context of the finalized type of harm condition (Sec. 171.201(d)),
[[Page 25823]]
below, we have aligned the conditions of the Preventing Harm Exception
finalized in Sec. 171.201 to use the same harm standards as Sec.
164.524(a)(3) in circumstances where both apply and in circumstances
where only Sec. 171.201 applies. In order to maintain alignment and
consistency, we clarify that in circumstances where only Sec. 171.201
applies, the risk of harm must also initially be at least ``reasonably
likely,'' regardless of whether the risk of harm is consistent with
subparagraph (1) or (2) of the type of risk condition finalized in
Sec. 171.201(c). To satisfy the reasonable belief condition finalized
in Sec. 171.201(a), the actor must reasonably believe their practices
(that are likely to, or in fact do, interfere with otherwise
permissible access, exchange, or use of EHI) will substantially reduce
that likelihood of harm. Actors who are HIPAA covered entities or
business associates have extensive experience in complying with Sec.
164.524(a)(3). Therefore, we believe the belief standard finalized in
Sec. 171.201(a), combined with reliance on the harm standards used in
Sec. 164.524(a)(3), will address commenters' concerns about their
ability to understand and apply the reasonable belief and type of harm
conditions finalized under Sec. 171.201.
Comments. A number of commenters advocated closer alignment with
the HIPAA Privacy Rule. Some commenters expressed concerns about our
ability to maintain such alignment without interruption if this rule
were to be finalized prior to any applicable potential updates to the
HIPAA Privacy Rule pursuant to a proposed rule that HHS had publicly
expressed an aim to publish in 2019. Some commenters specifically
questioned whether ``life or physical safety'' would remain the
standard for the type of harm cognizable under the Privacy Rule for
denying an individual's right to access their own information. One
commenter stated they had heard the Privacy Rule harm standard might be
broadened to recognize additional types of harm, such as emotional or
psychological harm, in circumstances where the Privacy Rule would
currently recognize only danger to life or physical safety. A number of
comments stated that the requirement for the risk to be to life or
physical safety for all circumstances where this exception would apply
would conflict with current Privacy Rule provisions applicable to
individual or proxy access to PHI. A number of commenters recommended
we revise the conditions for practices to be recognized under the
Preventing Harm Exception so that harm cognizable under the Privacy
Rule under particular circumstances would also be cognizable under
Sec. 171.201.
Response. We understand commenters' concerns about inconsistency
across this exception and the Privacy Rule. In particular, concerns
that center on the fact that requiring in Sec. 171.201 that the risk
must be to the ``life or physical safety'' of the patient or another
person in all circumstances where Sec. 171.201 applies would have set
a different harm standard than applies under Sec. 164.524(a)(3) in
particular circumstances where both Sec. Sec. 171.201 and
164.524(a)(3) apply. Specifically, where Sec. 164.524(a)(3)(ii) or
(iii) apply, the reviewable grounds for denial of right of access
include where a licensed health care professional has determined, in
the exercise of professional judgment, that the access requested is
likely to cause ``substantial harm.'' In contrast, a uniform
application of the ``life or physical safety'' type of harm under Sec.
171.201 would have applied the ``life or physical safety'' type of harm
standard to practices that interfere with access, exchange, or use of
EHI for purposes of Sec. 171.201 even where Sec. 164.524(a)(3)(ii) or
(iii) would also apply and where Sec. 164.524(a)(3)(ii) or (iii) would
apply the ``substantial harm'' standard.
In response to comments, we have reviewed the potential for
conflict between Sec. 171.201 requiring ``life or physical safety'' as
the type of harm in circumstances where Sec. 164.524(a)(3(ii) or (iii)
also apply. We have determined that for particular types of
circumstances where both Sec. Sec. 171.201 and 164.524(a)(3) apply,
the best approach is to apply under Sec. 171.201 the exact same harm
standard that each specific sub-paragraph of Sec. 164.524(a)(3)
applies in each of these types of circumstances. We believe that
extending the application under Sec. 171.201 of the specific harm
standards in Sec. 164.524(a)(3)(i) through (iii) to situations that
are similar in significant respects to situations where each of these
sub-paragraphs of Sec. 165.524(a)(3) would apply, but where Sec.
164.524(a)(3) does not apply, provides consistency that simplifies
compliance for actors subject to both 45 CFR part 171 and 45 CFR part
164. Situations where Sec. 171.201 could apply but where Sec.
164.524(a)(3) would not apply include, but are not limited to, those
where the actor's practice is likely to interfere with an individual or
their legal representative's access, exchange, or use of the
individual's EHI but not to the extent of failing to provide access (as
the term is used in context of Sec. 164.524) within the timeframe
allowed under Sec. 164.524.
To make the alignment between the Preventing Harm Exception and the
Privacy Rule clear, the final regulation text at Sec. 171.201(d)
cross-references the specific types of harm that would serve as grounds
for denying an individual or their personal representative access to
their PHI under the Privacy Rule (Sec. 164.524(a)(3)) in particular
types of circumstances.\138\ By cross-referencing to Sec.
164.524(a)(3), we align the regulations to streamline compliance for
actors. We also believe this approach will allow that alignment to
remain in place if changes were to be made to Sec. 164.524(a)(3) harm
standards in the future.\139\ In particular types of circumstances
where both Sec. 164.524(a)(3) and Sec. 171.201 apply, the
subparagraphs of finalized Sec. 171.201(d) (the type of harm
condition) cross-reference to the Sec. 164.524(a)(3)(i), (ii), and
(iii) harm standard that applies under Sec. 171.201 in each of these
types of circumstances. Moreover, where only Sec. 171.201 applies to a
practice where the type of risk is consistent with Sec. 171.201(c)(1),
the finalized subparagraphs of Sec. 171.201(d) cross-reference and
apply the harm standard that Sec. 164.524(a)(3)(i), (ii), or (iii)
would apply to denial of the individual's (Sec. 164.524) right of
access to their own PHI, the individual or their representative's
access to the PII of another person within that PHI, or the
individual's personal representative's access to the individual's PHI.
---------------------------------------------------------------------------
\138\ Meeting the harm standard is necessary but not alone
sufficient for a practice to be recognized as reasonable and
necessary under this exception; all other conditions of the
exception must also be met.
\139\ Alignment between part 171 subpart B and Sec.
164.524(a)(1) and (2) is discussed in Section VIII.D.2. We also
acknowledge that it is possible some types of revision to 45 CFR
part 164 could necessitate modifications to 45 CFR part 171 in the
future.
---------------------------------------------------------------------------
One example of a particular circumstance in which both Sec.
164.524(a)(3) and Sec. 171.201 would apply is where a health care
provider (as defined in Sec. 171.102) that is also a HIPAA covered
entity (as defined in Sec. 160.103) denies the patient's personal
representative access to the patient's EHI based on a licensed health
care professional's determination in the exercise of professional
judgment (Sec. 171.201(c)(1)) that granting that personal
representative access to the patient's EHI would pose a risk of
substantial harm to the patient.\140\ In
[[Page 25824]]
this circumstance, the finalized Sec. 171.201(d)(1), which cross-
references the harm standard applicable under Sec. 165.524(a)(3)(iii),
applies. In this example situation, the qualifying determination of
risk of harm (Sec. 171.201(c)(1)) is that any access (or exchange, or
use) of the EHI by the personal representative is reasonably likely to
cause harm consistent with the standard established in Sec.
164.524(a)(3)(iii), and thus the health care professional, or another
HIPAA covered entity or business associate with knowledge of the
determination, could also deny a request by the representative to
access the individual's ePHI under Sec. 164.524(a)(iii).
---------------------------------------------------------------------------
\140\ For purposes of how the Sec. 171.201 requirements and
cross-references to Sec. 164.524 operate within this example, it
makes no difference whether the health care provider acting on the
individualized determination is the licensed health care
professional who made the determination consistent with Sec.
171.201(c)(1), another licensed health care professional, or another
type of health care provider (such as a hospital or skilled nursing
facility).
---------------------------------------------------------------------------
Under Sec. 164.524(a)(iii), the harm must be a ``substantial
harm'' to qualify for the denial of the patient's personal
representative's request to access the patient's PHI. Similarly, both
Sec. 171.201 and Sec. 164.524(a)(3) apply where an information
blocking actor that is also a HIPAA covered entity, acting in reliance
on a determination of risk of harm made by a licensed health care
professional in the exercise of professional judgment, does not provide
the patient or the patient's personal representative any access to
information within the patient's EHI that references another person. In
this type of circumstance, Sec. 171.201(d)(2) by cross-reference to
Sec. 164.524(a)(3)(ii) applies the same ``substantial harm'' standard
under Sec. 171.201 that applies to the actor's denying the patient or
their representative access to that information under Sec.
164.524(a)(3)(ii).\141\
---------------------------------------------------------------------------
\141\ Note that the ``individual'' and ``access'' have different
meanings under 45 CFR 164.524 from those in 45 CFR part 171.
Regarding an individual's right of access under 45 CFR 164.524, the
term ``access'' should be understood in that HIPAA Privacy Rule
context.
---------------------------------------------------------------------------
In Sec. 171.201(d)(1), (2), and (3), as finalized, we also apply
the harm standards described in Sec. 164.524(a)(3)(i), (ii), or (iii)
to particular types of circumstances where Sec. 164.524 does not
apply, but that are similar with respect to whether it is the patient
or their representative requesting access, and whether the access
requested is to information within the patient's EHI that is another
person's identifiable information. For example, Sec. 171.201(d)(3)
applies the harm standard described in Sec. 164.524(a)(3)(i) where
practices that are likely to interfere with a patient's access,
exchange, or use \142\ of the patient's own EHI are implemented to
substantially reduce a risk of harm arising from data that is known or
reasonably suspected to be misidentified or mismatched, corrupt due to
technical failure, or erroneous for another reason (Sec.
171.201(c)(2)). Provided its conditions are met in full, the Preventing
Harm Exception (Sec. 171.201) would apply to such practices as
delaying access, exchange, or use, for the time necessary to correct
the errors that would otherwise pose a risk of harm to the patient (or
another person) that would be cognizable under Sec. 164.524(a)(3)(i)
if Sec. 164.524(a)(3)(i) applied.\143\ Such delays are not explicitly
addressed under Sec. 164.524(a)(3), which provides a maximum timeframe
for disclosure of PHI to which patients have the right of access, and
Sec. 164.524(a)(3) does not expressly contemplate risks of harm
arising from data issues as would be consistent with Sec.
171.201(c)(2). By contrast, Sec. 171.201 defines when a practice that
is likely to, or does, interfere with the access, exchange, or use of
EHI is excepted from the definition of information blocking in Sec.
171.103 that applies to the actor engaged in the practice, and
expressly applies where the actor can demonstrate a reasonable belief
the practice will substantially reduce a risk of harm arising from data
issues consistent with Sec. 171.201(c)(2).
---------------------------------------------------------------------------
\142\ As the terms ``access,'' ``exchange,'' and ``use'' are
defined in Sec. 171.102.
\143\ Note, again, that ``access'' has a different meaning in
subpart E of 45 CFR part 164 than it does in 45 CFR part 171.
---------------------------------------------------------------------------
Because risks of harm arising from data that is known or reasonably
suspected to be misidentified or mismatched, corrupt due to technical
failure, or erroneous for another reason (Sec. 171.201(c)(2)) would
apply equally to an individual's or their representative's or their
health care provider's access, exchange, or use of the patient's EHI,
Sec. 171.201(d)(4) applies the standard in Sec. 164.524(a)(3)(i) to
all of these circumstances. Thus, as Sec. 164.524(a)(3)(i) stands at
the time of publication of this final rule, the access, exchange, or
use of the EHI affected by the practice must be reasonably likely to
endanger the life or physical safety of the patient or another person
were the practice not implemented. (Please see Table 3 for a crosswalk
of the particular types of circumstances addressed by the subparagraphs
under Sec. 171.201(d) to the Sec. 164.524 harm standard applicable to
each type of circumstance.)
The finalized regulatory text in Sec. 171.201 is revised from the
Proposed Rule to reflect this more granular and comprehensive alignment
of harm standards across the two regulatory provisions. We believe this
alignment achieves the level of granular cross-reference necessary and
that is preferable to selecting only one of these standards to apply in
all types of circumstances under Sec. 171.201. We further note that
the revised regulation text is consistent with our decision to
completely align the EHI definition with the definition of ePHI within
the designated record set.\144\
---------------------------------------------------------------------------
\144\ See section VIII.C.3 of this preamble and the finalized
definition of ``electronic health information'' in Sec. 171.102.
---------------------------------------------------------------------------
Comments. A number of commenters advocated for expanding the
definition of harm that is contemplated under this exception to
encompass psychological and/or emotional harm in addition to risks to
life or physical safety, including but not limited to expanding the
concept of individualized determinations of risk of harm by health care
professionals. A few commenters specifically advocated recognizing the
potential for financial, reputational, or social/cultural harms. A
number of other commenters expressed a concern that broadening the
exception to address additional types of potential harm could risk its
being overused to withhold information from patients where available
evidence does not indicate there is a risk. One commenter reported
having observed that some clinicians express a belief that mere
disclosure of health data directly to patients without the clinician's
professional interpretation will routinely cause harm, despite what the
commenter described as existing evidence to the contrary.
Response. We believe it would be challenging to define an
appropriate and unique standard for purposes of this exception for non-
physical harms that all actors defined in Sec. 171.102 could apply
consistently and, most importantly, without unduly restricting
patients' rights to access their health information. We also recognize,
as discussed above, the practical utility of alignment with relevant
Privacy Rule provisions. At this time, only danger to the individual's
``life or physical safety'' is recognized as grounds for denial of an
individual's right of access under Sec. 164.524(a)(3)(i). However,
``substantial harm'' is the standard applied under the Privacy Rule
where the access denied is to information identifying another person
(other than a health care provider) or where an individual's personal
representative is denied access to the individual's PHI under Sec.
164.524(a)(3)(ii) or (iii). To align with the relevant Privacy Rule
provisions, the final regulation text (Sec. 171.201(d)(1) and
[[Page 25825]]
(2)) references the same harm standards as the Privacy Rule uses where
Sec. 164.524(a)(3)(ii) or (iii) as well as Sec. 171.201 applies, and
in circumstances where Sec. 164.524(a)(3) is not implicated but the
actor's practice is both based on an individualized determination of
harm (consistent with Sec. 171.201(c)(1)) and likely to interfere
with: (Sec. 171.201(d)(2)) a patient's or their legal representative's
access, exchange, or use of information within their EHI that
identifies another person (other than a health care provider); or
(Sec. 171.201(d)(1)) the patient's legal representative's access,
exchange, or use of the patient's EHI. The finalized Sec.
171.201(d)(3) and (4) also re-use the familiar Sec. 164.524(a)(3)(i)
type of harm for the wide variety of circumstances where Sec. 171.201
applies but the type of risk is consistent with Sec. 171.201(c)(2) or
the (otherwise legally permissible) access, exchange, or use of EHI
with which the practice is likely to interfere is by someone other than
the patient or their legal representative. Thus, the finalized Sec.
171.201 does not establish a standard for non-physical harm that would
be unique to the Preventing Harm Exception but instead recognizes
``substantial harm'' in circumstances where Sec. 164.524(a)(3)(ii) or
(iii) apply, and also applies this familiar type of harm in situations
where neither Sec. 164.524(a)(3)(ii) nor (iii) applies but where re-
use of this same standard under Sec. 171.201 is consistent with the
goal of aligning the types of harm recognized under Preventing Harm
Exception with the grounds for denying a right of access request under
the Privacy Rule.
Comments. One commenter specifically recommended allowing actors to
rely on an individual's own subjective beliefs related to harm.
Response. We interpret this comment as pertaining to the beliefs of
the patient whose EHI would be affected by a practice. We appreciate
this opportunity to explain that practices implemented to honor and
apply the patient's expressed preferences regarding access, exchange,
or use of their EHI are addressed by the Privacy Exception finalized in
Sec. 171.202.
Comments. A number of commenters requested clarification of how the
Preventing Harm Exception and its conditions might operate in
situations involving minors where applicable State laws allow non-
emancipated minors to independently consent to certain types of health
care and provide for keeping records of such care confidential from the
minor's parents/guardians. Several of these commenters specifically
requested clarification about the operation of this exception where
State law provides for minors to be able to consent to some or all
types of health care but does not provide for or allow the minors to
access their health records information at all, or in specific
format(s).
Response. We appreciate commenters' offering us the opportunity to
reiterate that where a particular access, exchange, or use of EHI is
prohibited by applicable Federal, State, or tribal law, an exception to
the definition of information blocking is not needed. Nothing in part
171 calls for access, exchange, use, or other disclosure of EHI that is
prohibited by other applicable law. If an actor simply cannot
effectively segment EHI they could safely and permissibly share from
EHI they are not permitted to share in a given requested format, the
actor should refer to the exception for requests that are infeasible
(Sec. 171.204). However, if the EHI they could legally disclose could
be shared in a different manner than that initially requested but the
different manner would support segmentation, then an actor should
provide the EHI they can safely and legally share in the most
appropriate manner consistent with the Content and Manner Exception
(Sec. 171.301).
Comments. Several commenters specifically requested clarification
as to the information blocking implications where State law and/or the
organization's account provisioning process do not provide for minors
to obtain the login credentials needed to access their own records
through an electronic portal, which will often be the login credentials
a patient would use to authorize an app to receive the records through
the provider's API.
Response. Where the actor does not have a reasonable belief that a
practice interfering with minors' access to their own EHI will
substantially reduce a risk of harm cognizable under this exception,
the Preventing Harm Exception (Sec. 171.201) would not apply. This
exception would also not apply where any person--whether adult,
emancipated minor, or non-emancipated minor--is not able to provide
adequate verification of their identity consistent with the actor's
health information privacy or security protection policies. Actors
should assess practices related to verifying the identity of a patient,
or a legal representative of the patient, for consistency with the
conditions of the Privacy Exception as finalized in Sec. 171.202 and/
or the Security Exception as finalized in Sec. 171.203. Likewise,
practices implemented to confirm a representative's legal authority to
access or request or authorize access, exchange, or use of a minor's
EHI on behalf of the minor, should be analyzed in the context of the
Privacy Exception as finalized in Sec. 171.202 and/or the Security
Exception as finalized in Sec. 171.203. Where otherwise applicable law
prohibits a specific access, exchange, or use of information, an
exception to part 171 is not necessary due to the exclusion of
``required by law'' practices from the statutory information blocking
definition in section 3022 of the PHSA (as discussed in section
VIII.C.1 of this preamble). However, where an actor simply lacks the
technical capability to provide access, exchange, or use in a specific
requested mechanism, format, or manner, we would encourage the actor to
review its practices for consistency with the new Content and Manner
Exception finalized in Sec. 171.301 or the Infeasibility Exception
finalized in Sec. 171.204.
Comments. Several commenters requested clarification as to whether
the Preventing Harm Exception would apply to 42 CFR part 2 data when it
is not made available for access, exchange, or use because the patient
did not consent to its access, exchange, or use.
Response. We appreciate the opportunity to remedy any confusion
that may have been caused by the Proposed Rule's use of an illustrative
example (84 FR 7524) within which the requirement to withhold data
subject to 42 CFR part 2 regulations rendered a particular access,
exchange, or use of only a portion of the patient's EHI legally
permissible. In the example, only those portions of the patient's EHI
to which 42 CFR part 2 does not apply could be permissibly accessed,
exchanged, or used. This example was intended only to illustrate that
the mere fact that an actor has knowledge, possession, custody, or
control of more EHI than the actor could legally share would not,
itself, provide a basis for application of the Preventing Harm
Exception to the actor's withholding of any of the EHI that the actor
could legally share. When an actor that is subject to 42 CFR part 2
cannot honor a request for access, exchange, or use of data subject to
42 CFR part 2 specifically because the patient has not provided the
consent that would be required by 42 CFR part 2 before the actor could
disclose that specific data for access, exchange, or use, the
Preventing Harm Exception (Sec. 171.201) would not apply. When an
actor has 42 CFR part 2 data for a patient but does not believe it has
documented the patient consent that is legally required before the
actor can fulfill a request for
[[Page 25826]]
access, exchange, or use of that data, the actor should refer instead
to the Privacy Exception finalized in Sec. 171.202. If the actor lacks
the technical capability to effectively segment data that it can
legally share from data that it cannot legally share, the actor should
also consider the new Content and Manner Exception finalized in Sec.
171.301 or the Infeasibility Exception finalized in Sec. 171.204.
Comments. Several commenters noted that some State laws prohibit
the release of specific information, such as results of particular
diagnostic tests, to patients through electronic means (e.g., patient
portals or APIs) until particular protocols have been completed.
Commenters cited, as an example, State law mandates for initial
communication of particular information to the patient by a health
professional in real time. The commenters requested clarification of
whether or how Sec. 171.201 would apply in those circumstances.
Response. As is the case with 42 CFR part 2 data that the patient
has not consented to disclose, the exception finalized in Sec. 171.201
would not apply in these particular types of circumstances. The
information blocking definition proposed and finalized in Sec. 171.103
does not include a practice that is likely to, or in fact does,
interfere with the access, exchange, or use of EHI when the practice is
required by law. If the actor lacks the technical capability to segment
data at the level of granularity needed to withhold only those data
points, elements, or classes that it is legally prohibited from
disclosing in response to a particular request, the actor should
consider the Content and Manner Exception finalized in Sec. 171.301 or
the Infeasibility Exception finalized in Sec. 171.204.
Comments. Several commenters recommended that we recognize under
Sec. 171.201 practices requiring patients to obtain their laboratory
results information only through the ordering provider's EHR.
Commenters stated that inaccurate display of such results is a safety
risk and that other actors such as laboratories and HINs/HIEs may not
have the technical capability to display the information accurately in
a human-readable interface that would be in full compliance with
regulatory requirements otherwise applicable to human-readable displays
of laboratory results information.
Response. We agree that display of inaccurate values for laboratory
results, or other clinical observations, could represent a safety risk.
We do not believe it would be appropriate to broadly limit patients to
obtaining their laboratory information only from providers that are (or
that employ) professionals whose scope of practice allows them to order
the tests. If a laboratory, or a HIN/HIE, has the data in an
interoperable format to support its exchange across providers, but does
not have the technical capability to appropriately display it for human
readability (such as in a patient portal), then the laboratory, or HIN/
HIE, should make the data available in the interoperable format to
providers or patients who can then view the data using technology the
provider or patient has chosen as appropriate to their needs. If any
actor receives a request for data access, exchange, or use via a
specific mechanism that the actor does not have the technical
capability to support, the actor should consider the Content and Manner
Exception finalized in Sec. 171.301 or the Infeasibility Exception
finalized in Sec. 171.204.
Comments. One commenter suggested recognizing a new exception under
the Preventing Harm Exception that would allow a health care provider
who is also a research institution to require, as a condition of making
EHI available for use in research, that the health care provider be a
collaborator in that research. The commenter stated that institutions
ensure accuracy in the way data is used and analyzed by requiring they
participate in any research involving their patients' information so
that they can explain for the research team any anomalies or other
characteristics unique to their own institutions' data and collection
methods. This commenter stated that disclosing EHI for research
purposes when the research being conducted does not involve the health
care provider disclosing the EHI could lead to misinterpreted outcomes
based on flawed data that could have a negative impact on scientific
discovery.
Response. We considered this suggested expansion of the Preventing
Harm Exception specifically in the context of the definition of
``electronic health information'' that we proposed, and the more
focused definition of ``electronic health information'' that we have
finalized.\145\ The Preventing Harm Exception is intended to apply to
practices an actor reasonably believes will substantially reduce a risk
of harm (of a type cognizable under this exception) to particular
person(s), such as a patient or a natural person in the patient's life
or multiple patients whose EHI was corrupted or mismatched due to a
technical failure of an actor's systems. The risk of potential harm
described by the comment was specifically of misinterpretations of EHI
leading to research findings that negatively impact scientific
discovery. This risk is too far removed from a reasonable, and
reasonably foreseeable, likelihood of cognizable harm to particular
patients or other particular natural persons to fit within the intent
of the Preventing Harm Exception finalized in Sec. 171.201. Therefore,
we did not modify the exception in response to this comment.
---------------------------------------------------------------------------
\145\ We note that, although various types of research data and
data sets may be or include ``electronic health information'' as
defined in Sec. 171.102, not all research data or data sets are or
include data meeting this definition.
---------------------------------------------------------------------------
Finalized Belief and Harm Conditions for Sec. 171.201
Having considered comments received on the belief and harm
standards, we have finalized the exception at Sec. 171.201 with
modification, as discussed in responses to comments. These
modifications simplify the belief standard, and more thoroughly and
specifically align the harm standard applicable for this exception with
either the Privacy Rule harm standard applicable under Sec.
164.524(a)(3)(i) (in most circumstances) or the harm standard in Sec.
164.524(a)(3)(ii) or (iii) (in particular circumstances). The harm
standard in Sec. 164.524(a)(3)(ii) or (iii) applies where both
Sec. Sec. 171.201 and 164.524(a)(3)(ii) or (iii) would apply, or in
particular circumstances that are sufficiently similar as to be
analogous to circumstances where both Sec. Sec. 171.201 and
164.524(a)(3)(ii) or (iii) would apply.\146\ Please reference the
finalized Sec. 171.201(a) for the regulatory text of the belief
standard. Please reference the finalized Sec. Sec. 171.201(d)(1)-(3)
for regulatory text that establishes the specific Sec. 164.524(a)(3)
harm standard that applies in each of the three particular types of
circumstances specific to patients and their representatives' access to
the patient's EHI, and reference Sec. 171.201(d)(4) for regulatory
text establishing the specific Sec. 164.524(a)(3) harm standard
applicable in all other types of circumstances where Sec. 171.201
applies.
---------------------------------------------------------------------------
\146\ Please note that the Preventing Harm Exception will not
normally apply where a patient or their representative may seek
access to EHI that is excluded from the right of access under Sec.
164.524(a)(1) or to which access may be denied on unreviewable
grounds under Sec. 164.524(a)(2). In circumstances where Sec.
171.201 conditions are not met but an actor wishes to withhold EHI
from an individual's right of access under Sec. 164.524(a)(1) or
(2), the actor should refer to the privacy exception (Sec.
171.202).
---------------------------------------------------------------------------
The circumstances where both Sec. Sec. 171.201 and 164.524(a)(3)
would apply are where the practices do
[[Page 25827]]
interfere with access, exchange, or use by the patient or their legal
representative (who is their personal representative for purposes of
Sec. 164.524) of some or all of the patient's EHI to the point of
denying access (as used in context of Sec. 164.524) on grounds of a
risk of harm determined on an individualized basis by a licensed health
care professional in the exercise of professional judgment (Sec.
171.201(c)(1) as finalized). Circumstances where Sec. 164.524(a)(3) is
not implicated but that are analogous to circumstances where both
Sec. Sec. 164.524(a)(3) and 171.201 apply are those where the risk of
harm is determined on an individualized basis consistent with finalized
Sec. 171.201(c)(1) and the practice does not entirely deny but is
likely to, or does, interfere with the patient's or their legal
representative's access, exchange, or use of the EHI that is otherwise
legally permissible. (For example, the practice may result in delaying
access, exchange, or use of the EHI but for less time than is permitted
for granting of a right of access request under Sec. 164.524.)
In a wide variety of circumstances where Sec. 171.201 will apply,
Sec. 164.524 would not apply. Such circumstances include those where
the access, exchange, or use of EHI with which the practice is likely
to, or does, interfere is not related to right of access under the
HIPAA Privacy Rule, such as access, exchange, or use of the patient's
EHI by the patient's health care providers. Likewise, Sec. 171.201
will apply but Sec. 164.524(a)(3) will not apply when the risk of harm
arises from data issues (Sec. 171.201(c)(2)) rather than having been
determined on an individualized basis by a licensed health care
professional (Sec. 171.201(c)(1)). In these circumstances where Sec.
164.524 would not apply, and that are not analogous to circumstances
where Sec. 164.524(a)(3) would apply, Sec. 171.201(d)(4) (type of
harm condition) applies the harm standard that would be cognizable
under Sec. 164.524(a)(3)(i) so that the actor must reasonably believe
the practice will reduce a risk otherwise posed to the life or physical
safety of the patient or another natural person.\147\ This provides,
under Sec. 171.201, consistency across this wide array of
circumstances where Sec. 164.524(a)(3) would not be implicated
regardless of the extent of interference or length of delay the
practice may pose to the access, exchange, or use of the EHI. Because
the circumstances to which the finalized Sec. 171.201(d)(4) applies
include access, exchange, or use of the patient's EHI by health care
providers furnishing services to the patient, we believe it is most
appropriate to apply under Sec. 171.201(d)(4) the same standard of
harm that would apply to denying a patient access to the patient's EHI.
This is consistent with our proposal (84 FR 7602) to require that
practices likely to interfere with any access, use, or exchange of EHI
would need to reduce a risk to the ``life or physical safety'' of a
patient or another person to satisfy the conditions in Sec. 171.201
and be excepted from the definition of information blocking in Sec.
171.103. We have also clarified the regulation text so it is expressly
clear on its face that the risk to be reduced must be one that would
otherwise arise from the specific access, use, or exchange of EHI
affected by the practice.
---------------------------------------------------------------------------
\147\ Please note that although ``individual'' as defined in 45
CFR 169.103 is not limited to natural persons, the belief standard
in the finalized Sec. 171.201 is, consistent with the requirement
that in most circumstances the risk of harm at issue must be to life
or physical safety.
---------------------------------------------------------------------------
Under Sec. 164.524(a)(3)(i), a covered entity may deny an
individual access to protected health information (PHI) about that
individual in a designated record set only if a licensed health care
professional in the exercise of professional judgment determines that
releasing the information to them would endanger the life or physical
safety of the individual or another person. Under Sec. 171.201(d)(3),
an actor \148\ may implement a practice that is likely to, or does,
interfere with the patient's access, exchange, or use of their own EHI
when the actor reasonably believes the practice will substantially
reduce a risk of harm to life or physical safety of the patient or
another person, regardless of whether that risk is determined on an
individualized basis (Sec. 171.201(c)(1)) or arises from data that is
known or reasonably suspected to be corrupt due to technical failure,
erroneous for another reason, or misidentified or mismatched (Sec.
171.201(c)(2)).
---------------------------------------------------------------------------
\148\ An actor could be any individual or entity meeting the
definition of ``health care provider,'' ``health IT developer of
certified health IT'' or ``health information network or health
information exchange'' in Sec. 171.102, and may or may not also be
a HIPAA covered entity or business associate as defined in the HIPAA
Rules.
---------------------------------------------------------------------------
Under Sec. 164.524(a)(3)(ii) and (iii), the standard of
``substantial harm'' applies where the individual or their
representative are denied access to information in the individual's
record that identifies another person (other than a health care
provider), or an individual's personal representative is denied access
to the individual's information. Thus, the type of harm standard
applicable under Sec. 171.201 will in most cases require that the
actor's practice be based on a reasonable belief that the requested
access, exchange, or use with which the practice is likely to or does
interfere would otherwise endanger the ``life or physical safety'' of
the patient or another person. However, the ``substantial harm''
standard included in Sec. 164.524(a)(3)(ii) and (iii) would apply in
specific circumstances as shown in Table 3. As discussed above, we have
made this change to the finalized Sec. 171.201 to align the harm
standard applied by Sec. 171.201 with the one applied by Sec.
164.524(a)(3) where both would apply, and in analogous circumstances
(as described above). As explained above, we revised the harm standard
applicable in particular circumstances to avoid setting a higher
threshold under Sec. 171.201 for practices likely to interfere with
access, exchange, or use \149\ of EHI than would be applicable to
entirely denying access under Sec. 164.524(a)(ii) or (iii) \150\ in
the same circumstances. In the finalized Sec. 171.201(d), we have
applied the type of harm described in Sec. 164.524(a)(ii) and (iii) to
particular circumstances where Sec. 164.524(a)(ii) and (iii) do not
apply, but that are analogous to such circumstances, for the reasons
stated in responses to comments above.
---------------------------------------------------------------------------
\149\ As ``access,'' ``exchange,'' and ``use'' are defined in
Sec. 171.102.
\150\ Please note that ``access'' has a different meaning under
45 CFR 164.524 than in 45 CFR part 171. Regarding an individual's
right of access under 45 CFR 164.524, the term ``access'' should be
understood in that HIPAA Privacy Rule context.
[[Page 25828]]
Table 3--Mapping of Circumstances Under Sec. 171.201(d) to Applicable
Harm Standards
------------------------------------------------------------------------
Requirements under Sec.
171.201(d) type of harm condition Applicable harm standards \151\
------------------------------------------------------------------------
Sec. 171.201(d)(1)--where the The harm of which the actor
practice interferes with access, reasonably believes the practice
exchange, or use of the patient's will substantially reduce a risk
EHI by their legal representative must be the type of harm described
and the practice is implemented in 45 CFR 164.524(a)(3)(iii),
pursuant to an individualized which is substantial harm to the
determination of risk of harm made individual or another person.\152\
by a licensed health care
professional in the exercise of
professional judgment (Sec.
171.201(c)(1)).
Sec. 171.201(d)(2)--where the The harm of which the actor
practice interferes with the reasonably believes the practice
patient's or their legal will substantially reduce a risk
representative's access to, use or must be the type of harm described
exchange of information that in 45 CFR 164.524(a)(3)(ii), which
references another natural person is substantial harm to such other
and the practice is implemented person.
pursuant to an individualized
determination of risk of harm made
by a licensed health care
professional in the exercise of
professional judgment (Sec.
171.201(c)(1)).
Sec. 171.201(d)(3)--where the The harm of which the actor
practice interferes with the reasonably believes the practice
patient's access, exchange, or use will substantially reduce a risk
of their own EHI, regardless of must be the type of harm described
whether the risk the practice is in 45 CFR 164.524(a)(3)(i), which
implemented to substantially is a harm to the life or physical
reduce is determined on an safety of the individual or
individualized basis by a licensed another person.
health care professional in the
exercise of professional judgment
(Sec. 171.201(c)(1)) or arises
from data that is known or
reasonably suspected to be corrupt
due to technical failure,
erroneous for another reason, or
misidentified or mismatched (Sec.
171.201(c)(2)).
Sec. 171.201(d)(4)--where the The harm of which the actor
practice interferes with the reasonably believes the practice
patient's legal representative's will substantially reduce a risk
otherwise legally permissible must be the type of harm described
access, exchange, or use of the in 45 CFR 164.524(a)(3)(i), which
patient's EHI and the practice is is a harm to life or physical
implemented to reduce a risk safety of the individual or
arising from data that is known or another person.
reasonably suspected to be
misidentified or mismatched,
corrupt due to technical failure,
or erroneous for another reason
(Sec. 171.201(c)(2)).
------------------------------------------------------------------------
Types of Risk of Harm to Patients Cognizable Under This Exception
---------------------------------------------------------------------------
\151\ Note that the ``individual'' and ``access'' have different
meanings under 45 CFR 164.524 from those in 45 CFR part 171.
Regarding an individual's right of access under 45 CFR 164.524, the
term ``access'' should be understood in that HIPAA Privacy Rule
context.
\152\ Note that grounds for denial of an individual's right of
access include that the access is reasonably likely to cause the
harm identified in the particular subparagraph under Sec.
164.524(a)(3). For purposes of 45 CFR part 171, we interpret that
the stated type of harm must, to the best of the actor's knowledge
and belief, be substantial, in absence of particular practice(s), in
order for an actor to reasonably believe the practice(s) will
substantially reduce that risk. We would interpret a reasonable
likelihood of the described harm, as used under Sec. 164.524(a)(3)
to be a substantial risk for purposes of Sec. 171.201.
---------------------------------------------------------------------------
We proposed (84 FR 7524) that to qualify for this exception, an
actor's practice must respond to one or more type(s) of risk of harm
cognizable under this exception. The three types of risk of harm that
we proposed would satisfy the conditions of this exception are:
Risks arising from corrupt or inaccurate data being
recorded or incorporated in a patient's EHI;
risks arising from misidentification of a patient or
patient's EHI; and
risks identified by a determination made by a licensed
health care professional that a specific access or disclosure of EHI is
reasonably likely to endanger the life or physical safety of the
patient or another person.
We provided additional explanation and discussion of these types of
risk of harm in the preamble of the proposed rule (84 FR 7524 and
7425). We also requested comment (84 FR 7525) on:
Whether these categories of harm capture the full range of
safety risks that might arise directly from accessing, exchanging, or
using EHI; and
Whether we should consider other types of patient safety
risks related to data quality and integrity concerns or that may have a
less proximate connection to EHI but that could provide a reasonable
and necessary basis for an actor to restrict or otherwise impede
access, exchange, or use of EHI in appropriate circumstances.
We will first discuss those comments that pertain to the cognizable
types of risk of harm in general. Comments specific to each of the
three types of risk of harm will be discussed separately, in the order
they were presented in the Proposed Rule.
Comments. Overall, comments were supportive of the exception
recognizing risks of harm arising from corrupt or misidentified
information, and individualized determinations of risk of harm made by
licensed health care professionals in the exercise of professional
judgment. Numerous commenters requested clarification or additional
information to help actors more effectively understand and efficiently
document their risk determinations in connection to practices for which
they would seek to claim that the Preventing Harm Exception applies.
Response. We appreciate the feedback received. In response to
comments calling broadly for additional clarification or information,
we have provided detailed responses to comments received. Where useful
to enrich the discussion, some responses discuss hypothetical example
situations that illustrate how a particular aspect of the exception
would operate in such a situation.
Comments. Some comments suggested that the determinations and the
rationale for individualized determinations by health care
professionals in the exercise of professional judgment should be
documented in the electronic health record.
Response. We believe documentation in the EHR, such as in
appropriate notes field(s), may be a practical, efficient approach to
documentation of determinations of risk of harm consistent with Sec.
171.201 for some -- perhaps many -- licensed health care professionals.
Therefore, we confirm that EHRs are considered an appropriate approach
or method for the documenting, and for retaining documentation, of
determinations of risk consistent with Sec. 171.201(c)(1). We also
note that much (perhaps all) of the information about the patient's
individual circumstances that factors into the professional's
determination of risk will most naturally and most often be documented
in the EHR in the ordinary course of furnishing care to the patient.
Nothing in Sec. 171.201 would require duplicating information already
captured in the EHR in a different form
[[Page 25829]]
or format specific or unique to Sec. 171.201, whether in the EHR or
elsewhere. However, we also believe that there is substantial potential
for variability in health care professionals' current methods for
documenting risk factors and determinations.
In addition, we do not believe it is necessary to require different
or duplicate documentation of information that is already otherwise
captured in reliable business records consistent with the HIPAA Privacy
Rule and applicable State laws--including, but not limited to, laws
protecting patient privacy or mandating provider reporting of
particular types of abuse their patients may experience. Therefore,
requiring via regulation that all health care professionals document
their determination specifically in the EHR in order to satisfy this
exception's conditions could impose an unnecessary burden on those who
would like to conform their practices to this exception but currently
take a different approach to documenting risk factors or to documenting
individualized determinations of risk specific to access, exchange, or
use of the patient's EHI by the patient or their legal
representative(s). Thus, we have not finalized a requirement that
licensed health care professionals must document in their EHR or in any
other particular system(s) their individualized determinations of risk
of harm in order for the determinations of risk to satisfy the risk of
harm condition finalized in 171.201(c)(1).
Comments. One commenter noted that minors may not fully understand
the implications of downloading and sharing their EHI, which represents
a different type of risk than the three discussed in the Proposed Rule.
The commenter advocated for health care providers to have discretion to
impose restrictions on non-emancipated minors' ability to access their
EHI through an API.
Response. We did not modify the Preventing Harm Exception in
response to this comment. The Preventing Harm Exception (Sec. 171.201)
is intended to apply to practices an actor reasonably believes will
substantially reduce a risk of harm to one or more particular
person(s), and in many circumstances (Sec. 171.201(d)(3) or (4)) a
risk of harm to the life or physical safety of particular persons, such
as: A patient or person in the patient's life; or multiple patients
whose EHI was corrupted or mismatched due to a technical failure of an
actor's systems. Where a non-emancipated minor, or other patient, is
otherwise legally entitled to access or receive their own health
information that does not include identified information about another
person, the Preventing Harm Exception will apply only to those
practices reasonable and necessary to address risk to the life or
physical safety of another person consistent with Sec. 171.201(d)(3)
and its specific cross-reference to Sec. 164.524(a)(3)(i). The Privacy
Exception (Sec. 171.202) is intended to recognize reasonable and
necessary practices to protect patients' privacy. We also note that we
have clarified in this final rule that although practices that purport
to educate patients about the privacy and security practices of
applications and parties with which a patient chooses to share their
EHI would always be subject to review by OIG if there were a claim of
information blocking, such practices likely would not be considered to
interfere with the access, exchange, and use of EHI if they meet
certain criteria (see section VIII.C.6, above).
Risk of Corrupt or Inaccurate Data Being Recorded or Incorporated in a
Patient's Electronic Health Record
We proposed (84 FR 7524) that the Preventing Harm Exception could
apply to practices that address risks of harm arising from corrupted or
inaccurate EHI being recorded or incorporated in a patient's electronic
health record. We further proposed that recognized risks from incorrect
or inaccurate information would be limited to those arising from known
or reasonably suspected corruption and inaccuracies caused by
performance and technical issues affecting health IT. We clarified that
the Preventing Harm Exception would not extend to purported accuracy
issues arising from the incompleteness of a patient's electronic health
record generally. We acknowledged that Federal and State laws may
require an actor to obtain an individual's written consent before
sharing specific health information, such as information subject to 42
CFR part 2. However, we expressly noted in the Proposed Rule that this
exception would not apply to an actor's conduct in refusing to provide
access, exchange, or use of the remainder of the patient's record on
the basis that the information withheld per patient's non-consent would
render the remainder of the patient's record incomplete and thus
inaccurate. We also noted that known inaccuracies in some data within a
record may not be sufficient justification to withhold the entire
record so long as the remainder of the patient's EHI could be
effectively shared without also presenting the known incorrect or
corrupted information as if it were trustworthy.
Comments. Commenters were supportive of the Preventing Harm
Exception applying to appropriate practices to address corrupt or
incorrect data in EHI and the risks that would otherwise arise from
propagation of corrupt or otherwise incorrect EHI within a patient's
record.
Response. We appreciate all of the feedback received, including but
not limited to confirmation that responding stakeholders are supportive
of this exception applying to practices an actor reasonably believes
will substantially reduce a risk of harm otherwise arising from access,
exchange, or use of corrupt or inaccurate data within a patient's
record.
Comments. One commenter, acknowledging that patients' wishes that
specific information not be shared should be honored, advocated
expanding this exception to cover physicians' declining to disclose any
EHI to other physicians where withholding of some information at the
patient's request would, in the disclosing physician's view, render the
patient's record so distorted as to be misleading.
Response. As we explained in the Proposed Rule, we would not
recognize incompleteness of the EHI that an actor can disclose as a
source of a risk of harm cognizable under this exception. For instance,
patients may make requests that specific information not be accessed,
exchanged, or used beyond a specific clinician-patient (or other
relevant) relationship because the information is associated with a
stigmatized condition, or for personal reasons (such as the patient's
subjective perception the information may be embarrassing or otherwise
detrimental to them). In the Proposed Rule, we provided an illustrative
example of a patient declining consent to share 42 CFR part 2 substance
abuse treatment information, and stated we would not consider the
remainder of the patient's record inaccurate based on its
incompleteness (84 FR 7524). Health care providers receiving any
patient's records of prior care presumably have an awareness of the
potential that some information may be omitted from the information
they receive for a wide variety of reasons that include, but that are
not limited to, patients' intentional choices to withhold some
information. Therefore, we do not believe it would be appropriate to
consider EHI to be corrupt, inaccurate, or otherwise erroneous where it
is simply a subset of everything an actor knows about the patient.
We are not persuaded that a patient's withholding consent to share
specific
[[Page 25830]]
portions of their overall EHI, regardless of the patient's rationale
for withholding consent, would render the data set their physician (or
other health care provider) could share more dangerous to the patient
than sharing none of the patient's EHI with another of the patient's
providers. Instead, we remind health care providers that nothing in
part 171 overrides Federal, State, or tribal law protections of
patients' privacy preferences. Likewise, nothing in part 171 reduces
variation in what and how much information patients remember, or are
willing, to disclose to their health care providers. Patients remain
free to withhold various information from their health care providers,
including but not limited to what other providers they may have seen in
the past.
Before enactment of the Cures Act, health care providers could not
safely assume every patient record they received from any source
necessarily included all the information that could or should be known
by that source that would be relevant to the patient's health or care
by that provider, even where the source can permissibly share
everything they do know. Thus, we reiterate that we do not believe it
is reasonable or necessary for purposes of preventing harm that a
provider withhold the EHI that they could permissibly share in any
particular circumstance simply because they happen to have more EHI
than they can permissibly share.
However, we also highlight that for purposes of this exception a
data export or access mechanism appropriately showing that some data
may be unavailable or omitted from the export or presentation is
materially different from a data export or presentation that
misrepresents the patient's EHI. For example, exports or presentations
omitting all medication data and correctly stating ``medication data
not available,'' \153\ we would not consider corrupt, inaccurate, or
otherwise erroneous. By contrast, however, an export or presentation
stating ``no current medications,'' or stating ``none'' or ``none
known'' in the medication section, when in fact the system producing
the export or representation does include current known medications for
the patient, represents a type of risk recognized under Sec.
171.201(c)(2).
---------------------------------------------------------------------------
\153\ Or otherwise indicating, in a manner appropriate to the
circumstances, that absence of information in the extract or
representation should not be understood as a statement that there is
no such data in the source system.
---------------------------------------------------------------------------
Under Sec. 171.201(d)(4), as finalized, a practice that is likely
to, or that in fact does, interfere with otherwise permissible access,
exchange, or use of a patient's EHI by their health care providers must
be one the actor implementing the practice reasonably believes will
substantially reduce a risk of harm of a type that could serve as
grounds for denial of the individual's right of access to their EHI
under the 45 CFR 164.524(a)(3)(i). Therefore, in order for a practice
likely to interfere with the access, exchange, or use of EHI by one of
the patient's health care providers to satisfy the conditions of the
Preventing Harm Exception, the actor must hold a reasonable belief that
the practice will substantially reduce a risk to the patient's, or
another natural person's, life or physical safety that would otherwise
arise from the access, exchange, or use of the EHI with which the
practice interferes. Erroneous misrepresentations that a patient is not
known to be taking any medications, when in fact they are known to be
taking one or more medications, is typically a system problem and one
that can give rise to risk to the physical safety, or even the life, of
any or all patients whose EHI may be affected by the problem.
Comments. One comment submission highlighted a tension between the
data-provision preferences of health care providers requesting data and
other actors (such as other providers and their health IT developers)
from whom data is requested. This commenter indicated providers
requesting data, such as long-term/post-acute providers caring for
patients after a hospital stay, may currently have to wait days to
receive any of the patient's clinical data from the hospital stay
because the hospital or its health IT developer refuses to generate and
send the C-CDA document until every last data element is finalized. The
commenter suggested we clarify whether Sec. 171.201 would apply to
such circumstances.
Response. An actor's practice of delaying fulfillment of an
otherwise feasible and legally permissible request for exchange,
access, or use of EHI that is finalized and available to the actor
merely because the actor knows more EHI for that patient will become
available at some later date would not satisfy the conditions of Sec.
171.201. As we stated in the Proposed Rule, we do not view mere
incompleteness of a patient record as rendering the remainder of the
patient's record inaccurate (84 FR 7524). We recognize that specific
data points may not be appropriate to disclose or exchange until they
are finalized. Such data points would include, but are not necessarily
limited to: Laboratory results pending confirmation or otherwise not
yet considered by the hospital reliable for purposes of clinical
decision making; or notes that the clinician has begun to draft but
cannot finalize until they receive (confirmed) laboratory or pathology
results or other information needed to complete their decision making.
We hope it is, and will be increasingly, rare that an actor cannot
effectively sequester non-finalized EHI from finalized EHI. However, we
cannot rule out the possibility that some actors may face that problem
at some point. If an actor cannot effectively sequester non-finalized
EHI from a particular access, exchange, or use where inclusion of non-
finalized EHI would not be appropriate, the actor should refer to the
new Content and Manner Exception (finalized in Sec. 171.301) or the
Infeasibility Exception finalized in Sec. 171.204.
Comments. A number of commenters expressed concerns that many
actors' health IT systems currently lack the capability to segment data
by class and element that would be needed to withhold only those
classes or elements that were corrupted or erroneous as described in
the Proposed Rule. Commenters requested clarification on whether the
Sec. 171.201 Preventing Harm Exception would in these cases apply to
the entirety of the patient's EHI, how it would apply, or if another
exception would also be needed.
Response. In the circumstances these comments described, the
Preventing Harm Exception will apply only to the EHI known or
reasonably suspected to be corrupt or erroneous. If an actor lacks the
data segmentation capabilities that would be needed to sequester only
that data known or reasonably suspected to be corrupt or erroneous from
the requested access, exchange, or use, we would encourage the actor to
consider meeting the conditions of another exception with respect to
the remaining EHI. For example, the Content and Manner Exception (Sec.
171.301) may allow for the actor to provide the requestor with the EHI
not known or reasonably suspected to be corrupt or erroneous, albeit in
a different way than was initially requested. Or, if the actor lacks
the technical capability to share the EHI that is not known or
reasonably suspected to be corrupt or erroneous consistent with the
Content and Manner Exception (Sec. 171.301), then the actor may wish
to meet the Infeasibility Exception (Sec. 171.204). The applicability
of the exceptions will depend on the particularized circumstances,
including but not limited to the specific request made. We believe the
conditions of these exceptions also offer frameworks within which a
responding actor and an
[[Page 25831]]
EHI requester may be able to identify a mutually agreeable approach to
making trustworthy EHI appropriately available in at least some of the
instances where a request cannot be safely fulfilled in exactly the
manner of the requester's first preference.
Comments. One comment expressed a concern that some health care
providers, particularly those already receiving feedback from payers
about their data quality, might believe the Preventing Harm Exception
would allow them to withhold patients' access to the patients' own EHI
to prevent the patients from seeing data quality issues the provider
knows or believes are present in that EHI.
Response. If a provider knows that the data quality issues in their
records serve as a source of risk consistent with Sec. 171.201(c)(2),
so as to form the basis of a reasonable belief the patient's accessing
or using the data would place the patient at risk of harm cognizable
under this exception,\154\ the exception would apply if all other
conditions of the exception were met. However, known corruption or
other errors that would place a patient accessing their EHI at risk of
harm cognizable under this exception on the basis of accessing--and
presumably making health or care decisions based on--that EHI would
also raise a substantial concern regarding the safety of that EHI for
use by the provider. Thus, we would expect that whenever a given health
care provider believes the EHI within their records is safe enough for
their own use in the delivery of patient care, the Preventing Harm
Exception would not excuse the provider from honoring their patients'
requests to access, exchange, or use that EHI simply because the
patients might discover error(s) in that EHI. If, to the actor's
knowledge or reasonable belief, only some data classes or elements
within a patient's EHI are a source of risk consistent with Sec.
171.201(c)(2), the actor should continue to make the remaining data
classes and elements available to the patients and other requestors (as
appropriate under applicable law). Where the actor lacks the technical
ability to appropriately sequester only the corrupt or erroneous data
within the EHI they hold for given patient(s), the actor should
reference the Content and Manner Exception finalized in Sec. 171.301
or the Infeasibility Exception finalized in 171.204.
---------------------------------------------------------------------------
\154\ Note that where the practice interferes with a patient's
access to their own EHI, the applicable harm standard is established
in Sec. 171.201(d)(3) and is the same one established at Sec.
164.524(a)(3)(i). Currently, that would be harm to life or physical
safety.
---------------------------------------------------------------------------
Comments. Several commenters requested clarification on whether an
actor has a responsibility to assess the data in their possession,
custody, or control for risk of harm before making it available for
access, exchange, or use.
Response. The conditions finalized in Sec. 171.201 for practices
that interfere with the access, exchange, and use of EHI for purposes
of preventing harm to be excepted from the definition of information
blocking (Sec. 171.103) do not require that actors generally evaluate
data requested for data quality issues or other sources of risk of harm
before fulfilling requests for access, exchange, or use of the EHI. At
the same time, actors should be aware that where an actor may have an
affirmative duty under otherwise applicable law for the quality or
accuracy of data, or for assessing other types of risk of harm that
could be implicated by an EHI access, exchange, or use request, nothing
in Sec. 171.201 should be construed as lessening or otherwise changing
that duty. For example, the Preventing Harm Exception does not lessen
or otherwise change an actor's existing obligations to ensure patient
EHI is created, recorded, and maintained to standards of accuracy and
reliability consistent with laws, regulations, and accreditation
requirements applicable to the particular actor in any given
circumstance.
Comments. Commenters expressed appreciation for the inclusion of
this exception so that health care providers will not be forced to
share incorrect data. Several of these commenters requested we clarify
a provider's responsibility for correcting corrupt or incorrect
information once it is discovered.
Response. For health care providers, existing State and Federal
laws and regulations address the responsibility to maintain appropriate
records of health care furnished and in support of reimbursement sought
from various programs and payers. Health care providers that have
obtained voluntary accreditations may have made additional commitments
related to record-keeping and data quality in context of obtaining and
maintaining those accreditations. These existing responsibilities of
health care providers are not lessened or otherwise changed by the
Preventing Harm Exception. The exception simply provides for exception
from the definition of information blocking at Sec. 171.103 of
practices interfering with the access, exchange, or use of mismatched,
corrupt due to technical failure, or otherwise erroneous EHI in order
to substantially reduce a risk of harm. Presuming its conditions are
otherwise met, Sec. 171.201 would apply to a variety of practices
appropriate to correct mismatched, corrupt due to technical failure, or
otherwise erroneous EHI in a manner consistent with otherwise
applicable law, regulations, accreditation standards, and payment
program standards.
Comments. One comment requested clarity regarding the applicability
of this exception to data received from a third party, where the actual
accuracy of the data cannot be, or has not been, confirmed by the actor
asked to make that data available for access, exchange, or use.
Response. We recognize that in some circumstances the available and
feasible mechanisms for EHI access, exchange, or use may not support as
much data provenance information as an actor might prefer. In such
circumstances, the actor would be free to communicate supplemental
information about specific data's provenance to a requestor. However,
the conditions of the Preventing Harm Exception would not be met where
EHI requested was received from a third party and the actor could not
confirm the accuracy of the EHI.
Comments. A comment from the perspective of health IT developers
and implementers stated that this exception should allow an actor to
err on the side of caution as the actor looks to determine the extent
of potential distortions in a record before sharing it. A number of
commenters described practices used today by HIEs to assess and resolve
data quality issues, including but not limited to taking all of the
records from a particular source offline while assessing the extent or
cause of issues identified in some record(s) from that source.
Response. The Preventing Harm Exception is intended to apply to a
variety of practices reasonable and necessary to protect patients from
risk of harm arising from access, exchange, or use of data that is
known or reasonably suspected to be corrupt, inaccurate, mismatched, or
misidentified. To be covered by the exception, the practice may
interfere with the access, exchange, or use of EHI only to the minimum
extent necessary to substantially reduce a risk of harm cognizable
under the exception, but the exception does not require that every
record affected by the practice have first been confirmed to contain
corrupt, mismatched, or otherwise dangerously problematic data. In some
circumstances, such as a particular data source experiencing a
[[Page 25832]]
known or reasonably suspected system or other technical failure
producing widespread corruption, mismatching, or other dangerous
errors, the minimum reasonable and necessary precautions may make all
records from that source unavailable pending resolution of the
technical failure and its risk-producing effects. The actor's knowledge
or reasonable suspicion could be appropriately derived in various ways.
These ways would include, but are not limited to: Detection of specific
data quality issues in a sampling of records from the particular
source; or receipt of notice from a source that they had experienced
technical issues or failures resulting in corruption, mismatching, or
other data quality issues giving rise to risks of harm cognizable under
this exception.
Comments. A commenter noted that this exception should be applied
rarely, and when applied should not be a mechanism to selectively block
information from specific actors. However, several other commenters
made observations that, in current practice, EHI coming from sources
whose data has a pattern of higher-than-normal error rates may be
subjected to more extensive review, and potentially delayed in broader
availability, compared with EHI from sources whose data error rate is
within a more normal range. Comments describing such current practices
recommended that this exception should allow for continued application
of additional data quality assurance processing to EHI from sources
whose data exhibits a history or pattern of more numerous or more risky
data quality issues.
Response. If an actor were to engage in practices systematically
interfering with access, exchange, or use of EHI from a particular
source based on considerations extraneous to the prevalence and risk
profile of data quality issues in the EHI, such practices would not
meet the conditions to be excepted under Sec. 171.201 from the
definition of information blocking finalized in Sec. 171.103. Examples
of considerations we would consider to be extraneous in this context
notably include, but are not limited to, whether the data source was
competitor of the actor and whether the actor may harbor personal
animus toward the data source. However, this exception would apply to
practices not based in whole or any part on considerations extraneous
to the prevalence and risk profile of data quality issues in the EHI,
provided each such practice meets all conditions in Sec. 171.201 that
are applicable to the circumstances in which it is used.
Comments. Commenters noted that integration of data from various
types of sources is challenging because of differences in the data
elements that different types of sources can exchange, and because of
technical differences in how similar data elements may be structured,
defined, or encoded across different types of sources. Commenters also
stated that data from new exchange partners may raise questions about
potential accuracy issues in interpreting and integrating different
types of data as well as integrating similar data from various types of
sources. Commenters recommended that Sec. 171.201 recognize that
practices may delay integration and availability of EHI in order to
address these issues, and also recommended that a time limit be
established for completing evaluations of incoming data.
Response. We appreciate commenters' highlighting that the U.S.
health care system as a whole includes opportunities for access,
exchange, and use of a wider variety of data classes and elements than
are currently addressed by standards and implementation specifications
adopted in part 170, and more sources than just those actors currently
using certified health IT. We are aware that, in a variety of
circumstances, safely and appropriately integrating data from a new
source may require time to determine and apply appropriate processing
approaches to ensure that data are not corrupted in the process of
mapping or converting them to the structures and standards used by the
recipient. Our finalized exception will apply to appropriately tailored
practices for assessing and mitigating risks otherwise posed by
integration of data from new sources, that is not standardized, or that
is standardized to non-published, proprietary, or obsolete standards.
In cases where the original meaning of EHI received cannot be
determined in a manner allowing for conversion to the formats and
standards used by the recipient's systems, it may sometimes be
necessary to decline to integrate such data in the recipient's
production systems. However, we believe it would be premature to
establish via this rulemaking specific time limits for assessment and
processing of EHI received from new exchange partners, in large part
due to the considerable variability in systems and circumstances of the
actors involved in such exchange relationships. Should the need arise
to assess the reasonableness, necessity, and timeliness of an actor's
practices applied to data received from new or various types of
sources, we would do so in context of the specific circumstances in
which particular practices were applied by particular actor(s).
Finalized Policy for Risks of Harm Arising From Corrupt or Inaccurate
Data
We have finalized the type of risk condition with modifications to
the proposed regulation text. We have reorganized the regulation text,
and in the context of that reorganization rephrased the statement of
some conditions. We have also, in Sec. 171.201(c)(2) replaced the word
``inaccurate'' (used in proposed Sec. 171.201(a)(2)) with
``erroneous'' to better differentiate between normal shortfalls in the
complete accuracy of a record and risk-generating errors in the data.
We also combine all data-specific sources of risk of harm in the final
Sec. 171.201(c)(2) instead of splitting them across two paragraphs as
was the case in Sec. 171.201(a)(1) (``corrupt or inaccurate'' in the
Proposed Rule) and Sec. 171.201(a)(2) (``misidentified or mismatched''
in the Proposed Rule). We made this change because misidentified,
mismatched, corrupt, and otherwise erroneous data are all sources of
risk arising from issues with the data rather than characteristics
unique to a patient or their circumstances. Additional conditions must
be met for Sec. 171.201 to apply to practices implemented to
substantially reduce a risk of harm arising from data issues
(consistent with Sec. 171.201(c)(2)), including Sec. 171.201(a), (b),
(d)(3) or (4), and (f)(1) or (2). Whether (d)(3) or (d)(4) applies
turns on whether the practice is likely to, or does, interfere with a
patient's own or other legally permissible access, exchange, or use of
the patient's EHI. Whether (f)(1) or (f)(2) applies turns on whether
the actor implements the practice consistent with an organizational
policy (f)(1) or based on a determination based on the particularized
facts and circumstances known or reasonably believed by the actor at
the time the determination was made and while the practice remains in
use (f)(2).
For purposes of providing additional information and explanation as
requested by many commenters, we reiterate that a risk of harm arising
from data that is known or reasonably suspected to be misidentified or
mismatched, corrupt due to technical failure, or erroneous for another
reason (Sec. 171.201(c)(2) as finalized) will not, consistent with
discussion and illustrative examples in the preamble to the Proposed
Rule (84 FR 7524), satisfy the conditions of the Preventing Harm
[[Page 25833]]
Exception if it turns on mere speculation about, or possibilities of,
as-yet-undetected inaccuracies or other imperfections in the EHI. An
electronic health record, like the paper chart it replaces, is
inevitably less than perfectly complete and precisely accurate across
100 percent of the variables potentially relevant to the individual's
health. Because the risk that records in general may be imperfect is a
risk that we understand as inherent to (and thus ordinarily addressed
in the course of) clinical practice, it will not be recognized as
justifying practices that implicate the information blocking
definition. Thus, the Preventing Harm Exception finalized in Sec.
171.201 does not extend to purported accuracy issues arising from
potential, suspected, or known incompleteness of a patient's electronic
health record generally, such as the possibility of a patient choosing,
or not remembering, to mention some of the medications they regularly
take. Similarly, the possibility that any given patient's EHI could at
any time contain sporadic, undetected, inaccurate data points as a
result of data entry errors--such as an entered weight of 123 instead
of the accurate observation of 132--would not be interpreted as
satisfying the condition finalized in Sec. 171.201(c)(2).
The Preventing Harm Exception will apply in those instances where
specific EHI of one or more patients is affected by a risk consistent
with the finalized Sec. 171.201(c)(2). Assuming its other conditions
that are applicable to the specific circumstances are met, the
Preventing Harm Exception will apply to appropriately tailored
practices that affect a particular patient's EHI regardless of the
origin or cause of known or reasonably suspected data issues giving
rise to risk of harm consistent with Sec. 171.201(c)(2), and to the
use of the practices for such time as is reasonable and necessary to
amend or correct the patient's EHI. In assessing timeliness and
reasonableness of an actor's approach to making such corrections, we
would take into consideration the facts and circumstances within which
they operate, including but not limited to licensure or certification
requirements applicable to the actor's EHI governance. For a health
care provider, we anticipate such licensure or certification
requirements will typically include clinical records standards set by
State licensure laws and additional standards applicable to that
provider given their specific circumstances, such as patient records
maintenance standards set by issuing bodies of facility/organizational
accreditations or professional board certifications the provider may
also hold.
Where an actor lacks the technical capability to sequester from
otherwise legally permissible access, exchange, or use only that subset
of EHI the actor knows or reasonably suspects is affected by data
issues giving rise to risk of harm consistent with Sec. 171.201(c)(2),
the Preventing Harm Exception will not recognize withholding of the
remaining EHI. In such circumstances, an actor should refer to the
exceptions for Content and Manner (Sec. 171.301) and Infeasibility
(Sec. 171.204), as may be applicable, in regard to the EHI that they
do not know or reasonably suspect to be affected by data issues giving
rise to risk of harm consistent with Sec. 171.201(c)(2).
Risk Arising From Misidentifying a Patient or Mismatching Patients'
Electronic Health Information
The Preventing Harm Exception is intended to apply to practices
that are designed to promote data quality and integrity and to support
health IT applications properly identifying and matching patient
records or EHI. As discussed in the preamble to the Proposed Rule (84
FR 7524), accurately identifying patients and correctly attributing
their EHI to them is a complex task and involves layers of safeguards.
The task requires application of appropriate procedures for verifying a
patient's identity and properly registering the patient in health IT
systems. Safeguards include such usability and implementation decisions
such as ensuring the display of a patient's name and date of birth, and
perhaps a recent photograph, on every screen from which clinicians and
other caregivers access, enter, and/or modify data in the patient's
record. When a clinician, other health IT user, or other actor knows or
reasonably suspects that specific EHI is not correctly attributed to
one or more particular patient(s), it would be reasonable for them to
avoid sharing the EHI that could introduce or propagate errors in
patient records and thereby pose risks to the patient(s) affected.\155\
---------------------------------------------------------------------------
\155\ Please note that practices designed and implemented to
ensure that persons requesting access to their EHI are who they
claim to be and give them access to only that EHI that is theirs
would not be cognizable under the Preventing Harm Exception; we have
established two other exceptions designed to address practices
reasonable and necessary to protect the privacy (see Sec. 171.202)
and security (see Sec. 171.203) of individuals' EHI.
---------------------------------------------------------------------------
Under the Preventing Harm Exception as proposed, an actor's
response to the risk of misidentified patient health information would
need to be no broader than necessary to mitigate the risk of harm
arising from the potentially misidentified record or misattributed data
(84 FR 7524). For example, under the proposed exception, an actor--such
as a health IT developer of certified health IT--refusing to provide a
batch export on the basis that the exported records might contain a
misidentified record would not find that practice recognized under this
exception. Similarly, a health care provider or other actor that
identified that a particular piece of information had been
misattributed to a patient would not be excused under Sec. 171.201
from exchanging or providing access to all other EHI about the patient
that had not been misattributed. The actor knowing or reasonably
suspecting some data had been misidentified or misattributed would also
be expected to confirm the extent of such errors and to take
appropriate steps to correct their own records, consistent with
applicable law, regulations, and accreditation standards applicable to
the actor, and best practices or other appropriate industry benchmarks
for health records and information management.
Comments. Commenters recommended we consider that actors bear
significant responsibility to preserve and promote data quality and
integrity, and that actors generally take risk-averse approaches to
preventing and to assessing and resolving errors in identifying EHI and
matching patient EHI.
Response. We appreciate the opportunity to assure all stakeholders
that we are aware that the EHI an actor receives from various sources
may feature a variety of characteristics that call for varying degrees
of pre-processing to achieve a level of matching accuracy considered by
the health care provider community to be sufficient for safe use of the
data in patient care. In some circumstances, we understand additional
or special processing--including but not necessarily limited to human
eyes-on analysis to confirm matches--may be needed before records are
deemed to have been accurately matched, and that data requiring human
processing may be delayed in integration and availability compared with
data that can be satisfactorily matched through an actor's automated
means. Section 171.201 will apply to such practices provided all of its
conditions are met.
Comments. Commenters recommended the finalized exception recognize
as reasonable and necessary to protect patient safety practices such as
sequestering from access and exchange all records from a particular
source, or
[[Page 25834]]
affected by a particular system or technical process, until the scope
and cause of patient matching or attribution issues can be identified
and appropriately resolved. Commenters stated such practices are
commonly used today by HINs/HIEs, and provided illustrative examples of
current practice. Comments described as an example current practice of
HIEs not making available any record(s) that their monitoring for
technical or other issues identifies as an improperly matched patient
record--and any other records that may be affected by a similar
technical issue--until the record(s) can be corrected to include only
accurately matched data.
Response. We do understand that a variety of methods and approaches
may currently be needed to assess the scope, identify, and
appropriately address the cause of patient matching or attribution
errors. Section 171.201 will apply to practices otherwise meeting its
conditions that affect more patients' records than those specifically
confirmed to include mismatched or misattributed EHI. Where its
conditions are otherwise met, the exception will apply to use of
practices likely to interfere with access, exchange, or use of EHI that
the actor knows includes mismatched or misattributed data or reasonably
suspects includes such errors. Reasonable suspicion could be formed on
various bases, such as objectively observable patterns of association
between detected errors and a particular data source, application,
system, or process. However, a practice of delaying the availability of
records from any particular data source based on factors extraneous to
matching processes and accuracy would not be excepted from the
definition of information blocking. Examples of extraneous factors
include, but are not limited to, whether the data source was competitor
of the actor and whether the actor may harbor personal animus toward
the data source.
Comments. One commenter suggested the Preventing Harm Exception
allow for providers to refuse to release pediatric data to direct-to-
consumer applications unless the provider was satisfied with the
applications' ability to properly segment the data where multiple
users' records might be stored in the same instance of the application.
Specifically, the comment expressed a concern that if applications are
not set up to safely handle multiple patients, data from multiple
patients could be mixed together in ways that create a potential for
serious harm stemming from how those data might then be used or
interpreted.
Response. The potential for EHI to be mismatched (or otherwise
mishandled) by an application, whether mobile or otherwise, is neither
unique to pediatric patients' EHI nor particular to apps that receive
the patient's data from a provider's API. A patient whose provider has
not yet implemented a standards-based API could use other means to get
their EHI into their chosen direct-to-consumer app. Such means could
include accessing view, download, and transmit functionality of the
provider's certified health IT via the patient portal and transmitting
an extract of their data in C-CDA format to the recipient of the
patient's (or their legal representative's) choice. An individual or
their representative could also exercise the individual's right of
access under the HIPAA Privacy Rule to obtain the individual's EHI that
is accessible under this right, in another format in which it is
readily producible, and then upload it to an app of their choosing. In
general, we do not believe it would be appropriate to extend the
Preventing Harm Exception to apply to practices whereby actors would
limit otherwise legally permissible access, exchange, or use of patient
EHI based on concerns that a requestor will not handle patient matching
in a manner acceptable to the actor. Therefore, this exception will not
apply to actors' refusal to allow access, exchange, or use of EHI on
grounds that the actor may not know, or may not be satisfied with, the
matching methods to be used by a recipient of the EHI after the EHI has
been securely transferred to the recipient. Provided the practices meet
its conditions, the Security Exception (Sec. 171.203) will apply to a
variety of practices directly related and tailored to specific security
threats to the actor's systems and EHI within those systems that may be
posed by particular connections or interfaces with third-party systems
or software. We also note that practices that do not inappropriately
discourage patients from accessing, exchanging, or using their EHI as
they choose, but that are appropriately designed and implemented to
help patients make more informed choices about their EHI and apps can
be designed and implemented to avoid meeting the definition of
information blocking finalized in Sec. 171.103.
Comments. One commenter expressed a concern that this exception
could become a pretext for an actor to avoid sharing EHI on basis of
the actor not being satisfied with the accuracy achieved by a
prospective recipient's patient matching methods. This commenter
requested ONC clarify that this exception does not allow for an actor
to take a position that it will not share EHI unless the requesting
entity demonstrates it will match patients using a method, or to a
degree of accuracy, satisfactory to the actor being requested to share
the information.
Response. We do not believe it would be appropriate to extend the
Preventing Harm Exception to apply to practices whereby actors would
limit otherwise legally permissible access, exchange, or use of patient
EHI based on concerns that a requestor will not handle patient matching
in a manner acceptable to the actor. Various recipients and users of
EHI will have different purposes and contexts of data use and thus may
appropriately deem differing levels of assurance of match accuracy
satisfactory to meet their obligations, for patient safety or
otherwise. Therefore, this exception will not apply to actors' refusal
to allow access, exchange, or use of EHI on grounds that the actor may
not know, or may not be satisfied with, the matching methods to be used
by a recipient of the EHI after the EHI has been securely transferred
to the recipient.
Comments. Some commenters specifically discussed concerns about
potential misuse of this exception on a claim of patient matching
concerns, and that this exception could lessen actors' motivations for
improving their patient match capabilities. Some commenters suggested
specific additional requirements for applicability of this exception to
practices implemented to reduce risks of harm arising from mismatch or
misidentification of patient EHI, in order to guard against its misuse
or potentially incentivizing stagnation in rates of patient matching
capabilities advancement. Additional requirements that commenters
suggested were:
That an actor only be able to take advantage of this
exception on basis of mismatch if the actor's matching methods met or
exceeded a performance threshold;
that the actor proactively communicates to requestors the
actor's minimum matching criteria and other aspects of its matching
methods; and
a requirement for specific features in the actor's
systems, such as returning informative error messages regarding match
failures.
Response. We are aware there is variation across actors in
technical capabilities relevant to patient matching, resources to
improve those capabilities, and other operational considerations. We
are not aware of clear evidence or broad industry consensus on specific
practices or
[[Page 25835]]
performance thresholds that should apply to across all EHI use cases
and operational contexts. We believe it would be premature to limit the
availability of this exception to actors able to implement specific
practices or meet particular metrics of patient matching performance
specified through this rulemaking. Because this exception is intended
to except from the definition of information blocking in Sec. 171.103
practices that are reasonable and necessary to protect patients from
risks of cognizable harm attributable to types of risk specifically
including risks arising from mismatched EHI, rather than to drive
changes in patient matching practices in the industry, such
requirements could render this exception unavailable in circumstances
where it is intended to apply. Thus, we have determined that it is more
appropriate to leave actors engaged in using data the discretion and
responsibility for determining what level of certainty in the accuracy
of record matching is necessary for their use of the EHI. We appreciate
this opportunity to clarify that the Preventing Harm Exception would
not excuse actors from making appropriate good faith efforts to match
patient records, which we expect will ordinarily include communication
and cooperation between data sources and recipients. Moreover, we
believe an actor will generally have a natural incentive to communicate
proactively, appropriately, and in good faith with those with whom they
exchange data, specifically to minimize unnecessary extra processing
and follow-up communications on the part of both exchange partners.
Therefore, we have not modified the Preventing Harm Exception's
conditions in response to these comments.
Comments. One commenter expressed a concern that to ensure they do
not release information that has potential errors in patient matching
or attribution, they will need to invest in improved patient record
matching accuracy, which the commenter indicates would for them include
new technical solutions compared with their current practice.
Response. This exception is not intended, and we are not persuaded
that as finalized it will function, to impose a new or specific
obligation on actors to ensure they do not release information that
could contain latent errors. Other commenters did recommend we consider
doing so. However, for the reasons stated above in response to those
comments, we have not established a pre-requisite that an actor meet a
particular threshold of patient-matching performance before this
exception will apply to practices otherwise meeting the conditions of
Sec. 171.201 applicable in the particular circumstances, including
that the actor can demonstrate a reasonable belief the practice(s) will
substantially reduce a risk of harm cognizable under Sec. 171.201. We
emphasize that we have not established a pre-requisite for
applicability of Sec. 171.201 that would call upon an actor to use
particular methods, or satisfy particular threshold performance rates
on any specific metric, for patient identification and matching.
Comments. A few commenters requested clarification as to whether a
patient would be liable for accessing another patient's EHI that had
been mismatched or misattributed to the patient accessing the
information.
Response. This issue is outside the scope of this rulemaking. Those
concerned or curious about it should reference Federal,\156\ State, or
tribal law and regulations--or reliable sources of information about
Federal,\157\ State, or tribal law and regulations--applicable to any
individual's (or entity's) unauthorized access to or use of another's
personally identifiable information (PII) in the particular
jurisdiction(s) and circumstances of potential concern.
---------------------------------------------------------------------------
\156\ Potentially applicable Federal law and regulations are not
limited to HIPAA and the HIPAA Privacy Rule, but the HIPAA Privacy
Rule may be a useful place for those who share interest in the
question raised by these comments to begin obtaining additional
information.
\157\ Authoritative information about the HIPAA Privacy Rule is
available in the health information privacy section of the HHS
website, starting at https://www.hhs.gov/hipaa/index.html.
---------------------------------------------------------------------------
Comments. One commenter suggested creation of a hold-harmless or
``safe harbor'' policy protecting data recipients from liability for
actions taken in good faith reliance on information received after
applying best-practice matching methods.
Response. The suggestion appears to reference a safe harbor from
liability for decisions or other actions taken in reliance on the EHI
in question. That is outside the scope of this rule. Actors should
implement matching methodologies and practices in full awareness that
this final rule will not change their responsibility under other
applicable law for maintaining appropriately reliable medical or other
business records. This final rule also does not alter clinicians'
responsibilities for exercising sound professional judgment in making
clinical decisions based on EHI available to them in context of what
they know or reasonably believe about the EHI's reliability.
Comments. Commenters requested, in context and reference to the
Preventing Harm Exception, guidance regarding what an actor is
obligated to do if they receive EHI as a result of provider matching
failure. One commenter specifically requested guidance on what sort of
good faith efforts to direct the EHI to the correct recipient would be
expected of an inadvertent recipient of mis-directed EHI.
Response. A provider or other actor who receives EHI that they have
reason to believe may have been directed to them by mistake has no
obligation under part 171 to identify the correct recipient or to
forward the EHI to the correct recipient. The actor who believes they
may have received mis-directed EHI should upon forming such belief
follow their established practices for handling of PHI and PII received
in known or suspected error. We presume these established practices are
consistent with Federal, State, or tribal law applicable to the
particular actor in the particular operational circumstances.
Statement of Finalized Policy for Risks Arising From Misidentified or
Mismatched EHI
We are finalizing the substance of this part of the exception as
proposed, with modifications to how it is expressed in regulation text
in comparison with the Proposed Rule. We have reorganized the
regulation text in response to comments requesting our regulatory text
in general be laid out in a way that is easier to use. For example, we
have combined risks arising from misidentified or mismatched EHI with
other data-specific sources of risk of harm in the final Sec.
171.201(c)(2), instead of splitting them across two paragraphs as was
the case in Sec. 171.201(a)(1) (``corrupt or inaccurate'' in the
Proposed Rule) and Sec. 171.201(a)(2) (``misidentified or mismatched''
in the Proposed Rule). We believe this makes the finalized text of
Sec. 171.201 easier to use because misidentified, mismatched, corrupt,
and otherwise erroneous data are all sources of risk arising from
issues with the data rather than characteristics unique to a patient or
their circumstances. As was the case in the Proposed Rule, additional
conditions must be met for Sec. 171.201 to apply to practices
implemented to substantially reduce a risk of harm arising from data
issues (consistent with Sec. 171.201(c)(2)). In the structure of the
finalized regulation text, these additional conditions are found in
Sec. 171.201(a) and (b), and as applicable in the particular
circumstances also in (d)(3) or (4), and (f)(1) or (2). Whether (d)(3)
or (d)(4) sets out the harm
[[Page 25836]]
standard that applies to a practice an actor believes will
substantially reduce a risk of harm consistent with Sec. 171.201(c)(2)
turns on whether the practice is likely to, or does, interfere with a
patient's own or another other legally permissible access, exchange, or
use of the patient's EHI. (We note, however, that the harm required to
satisfy this condition is the same under (d)(3) and (d)(4), as both
cross-reference Sec. 164.524(a)(3)(i).) Whether (f)(1) or (f)(2)
applies to a practice an actor believes will substantially reduce a
risk of harm consistent with Sec. 171.201(c)(2) turns on whether the
actor implements the practice based on an organizational policy (f)(1)
or a determination based on facts and circumstances known or reasonably
believed by the actor at the time the determination was made and while
the practice remains in use (f)(2).
Determination by a Licensed Health Care Professional That the
Disclosure of EHI Is Reasonably Likely To Endanger Life or Physical
Safety (Sec. 171.201(c)(1))
We proposed that this exception would recognize practices
interfering with EHI access, exchange, or use in circumstances where a
licensed health care professional has determined, in the exercise of
professional judgment, that the access, exchange, or use of the EHI is
reasonably likely to endanger the life or physical safety of the
patient or another person (84 FR 7524 and 7525). As we explained, the
clinician may have in certain cases individualized knowledge stemming
from the clinician-patient relationship that, given the particular
patient and that patient's circumstances, harm could result if certain
EHI were shared or transmitted electronically. We proposed that,
consistent with the HIPAA Privacy Rule, a decision not to provide
access, exchange, or use of EHI on this basis would be subject to any
right that an affected individual is afforded under applicable Federal
or State laws to have the determination reviewed and potentially
reversed.
Comments. Commenters recommended that actors, such as HINs/HIEs,
implementing practices based on a determination by a health care
professional, not be required to take steps to review or assess the
reasonableness of the health care professional's judgment or
determination that a risk of harm exists or that the harm of which a
risk was determined to exist met the standard for recognition under
this exception.
Response. We did not propose to require that other actors would
ordinarily need to evaluate whether they agreed with individualized
determinations of risk made by a licensed health care professional in
order for the actor's application of practices consistent with that
determination to be recognized under this exception. The finalized
exception also does not generally require that actors relying on an
individualized determination made by a licensed health care
professional in the exercise of professional judgment take steps to
review or confirm the health care professional's judgment.\158\ Actors
other than the licensed health care professional who makes the
determination--including but not limited to HINs/HIEs or hospitals--
could implement practices based on organizational policy (consistent
with Sec. 171.201(f)(1) as finalized) to rely on such determinations
upon becoming aware of the determination and until such time as they
become aware that the determination has been reversed or revised. Such
other actors also, either in absence of such policy or in
particularized facts or circumstances not fully covered by their
existing policy at the time they became aware of a licensed health care
professional's individualized determination of risk, could demonstrate
for those particularized circumstances the reasonable belief required
by Sec. 171.201(a) by referencing the licensed health care
professional's determination in making their own determination
consistent with Sec. 171.201(f)(2).
---------------------------------------------------------------------------
\158\ To the extent any particular actor may have an obligation
under other Federal, state, or tribal law or regulations (as may be
applicable in any particularized circumstances) to afford a patient
a right of review of the determination--or to facilitate the
patient's requesting a review of the determination from another
actor--the actor's practices would need to be in compliance with
such law or regulations in order for this exception to apply to
those practices.
---------------------------------------------------------------------------
Comments. One commenter suggested that this exception should
recognize determinations of the existence of a risk of harm made by
licensed health care professionals without requiring a clinician-
patient relationship.
Response. In order for practices implemented to substantially
reduce a type of risk consistent with finalized Sec. 171.201(c)(1) to
be excepted under Sec. 171.201 from the definition of information
blocking finalized in Sec. 171.103, the individualized determination
of risk of harm in the exercise of professional judgment must be made
by a licensed health care professional who has a current or prior
clinician-patient relationship with the patient whose EHI is affected
by the determination. In the preamble to the Proposed Rule (84 FR 7524)
we explained that the clinician may have individualized knowledge
stemming from the clinician-patient relationship that, for a particular
patient and for that patient's circumstances, harm could result if
certain EHI were shared or transmitted electronically. To ensure that
both the requirement for a clinician-patient relationship and its
specificity to individualized determinations of risk of harm by
licensed health care professionals in the exercise of judgment are
immediately clear to all actors, we have stated it in the finalized
text of Sec. 171.201(c)(1). We are finalizing this as a requirement
because a clinician who has never established a clinician-patient
relationship to the particular patient would not be expected to have
the same individualized knowledge of the individual patient and that
patient's circumstances as one who has such a clinician-patient
relationship.
In contrast, however, we reiterate that a risk is less
individualized when it arises from data issues (consistent with Sec.
171.201(c)(2)) and as a result may be identified by clinicians or by
other persons with relevant expertise, including but not limited to
biomedical informaticists who are not licensed health care
professionals. Nothing in Sec. 171.201 requires the involvement of a
licensed health care professional with a clinician-patient relationship
to any patient(s) whose data may be affected by the practices in the
design of, or decision to implement, practices an actor reasonably
believes will substantially reduce a risk arising from data issues
consistent with Sec. 171.201(c)(2).
Comments. Several commenters recommended that, in the context of a
clinician-patient relationship, the clinician should have broader
latitude to consider specifics of a patient's circumstances in
determining the existence of a risk of harm or potential harm.
Response. It may be helpful to highlight the significant and broad
discretion inherent in the policy as we proposed it. An individualized
determination made in the exercise of professional judgment by a
licensed health care professional allows for that professional to
consider a wide array of individual patient characteristics and
circumstances and to apply all of the knowledge and skills within the
licensed health care professional's scope of practice. The exception's
conditions as proposed would provide licensed health care professionals
broad discretion in how or why they form a reasonable belief that a
cognizable risk of harm is associated with particular access, exchange,
or use of their
[[Page 25837]]
patient's EHI (including by the patient or their legal representative).
We have finalized this aspect of the Preventing Harm Exception as
proposed, though we have revised how the conditions, and specific
requirements within particular conditions, are organized and phrased in
regulation text. Nothing in the finalized Sec. 171.201 would limit the
types of information on which the licensed health care professional may
rely, or the factors they may consider, in exercising their
professional judgment to make individualized determinations of risk of
harm consistent with Sec. 171.201(c)(1).
Comments. A few commenters advocated for clinician discretion to
determine whether a disclosure of health information was in the
patient's best interest.
Response. We believe an individual clinician's assessment of the
patient's best interest is a less objective standard than one based on
the exercise of professional judgment paired with a defined standard of
cognizable harm. It would thus render the exception more difficult to
administer as well as more susceptible to inappropriate use of the
exception. We are finalizing the substance of this condition of the
Preventing Harm Exception as proposed: To satisfy the conditions of the
Preventing Harm Exception, an individualized determination by a
licensed health care professional in the exercise of professional
judgment must be that a risk of harm cognizable under this exception is
associated with particular access, exchange, or use of the patient's
EHI. The harm cognizable under this exception will be one that would be
recognized under Sec. 164.524(a)(3)(i) (at this time, danger to the
life or physical safety of the patient or another person) where a
practice affects a patient's access, exchange, or use of their EHI, per
the finalized Sec. 171.201(d)(3). Where Sec. 171.201(d)(1) or Sec.
171.201(d)(2) applies, the harm cognizable under this exception will be
one that would be recognized under Sec. 164.524(a)(3)(iii) or Sec.
164.524(a)(3)(ii), respectively. At this time, the harm standard in
both Sec. 164.524(a)(3)(iii) and Sec. 164.524(a)(3)(ii) is
``substantial harm.'' For all legally permissible access, exchange, or
use of the patient's EHI to which Sec. 171.201(d)(1) through (3) do
not apply, the finalized Sec. 171.201(d)(4) applies, by cross-
reference, the same Sec. 164.524(a)(3)(i) harm standard of danger to
the life or physical safety of the patient or another person that is
applicable to practices interfering with the patient's access to their
own EHI (that does not include PII of another).
Comments. Several commenters expressed a concern that the exception
as proposed might not sufficiently recognize the entire array of
circumstances where persons should not be granted access, exchange, or
use of EHI. For instance, commenters suggested no access, exchange, or
use of a patient's EHI should be available to a person suspected to be
abusing, or at risk of beginning to abuse, the patient. Commenters also
suggested that the exception should recognize that broader restrictions
of EHI access than illustrated by examples in the Proposed Rule would
in many cases be indicated by available evidence, widely recognized
clinical practice guidelines, or State laws applicable to instances of
known or suspected child, intimate partner, elder, or other abuse.
Response. This exception applies to practices the actor reasonably
believes will substantially reduce a risk of harm determined on an
individualized basis in the exercise of professional judgment by a
licensed health care professional with a clinician-patient relationship
with the patient whose EHI is affected by the determination (finalized
Sec. 171.201(c)(1)). Moreover, and as we noted in the Proposed Rule
(84 FR 7524), this exception would apply when an actor implements
practices that are likely to interfere with the access, exchange, or
use of a patient's EHI pursuant to electing to not treat a person as a
personal representative in accordance with 45 CFR 164.502(g)(5). We
have finalized the substance of this feature of the exception as
proposed, though 45 CFR 164.502(g)(5) is not expressly referenced in
the final regulation text.
The listed examples described in the Proposed Rule were intended to
be illustrative, not exhaustive. There are many other situations where
the Preventing Harm Exception will apply to an actor's practices so
long as the conditions of the exception are otherwise met. As another
illustrative example, if a determination of risk of harm consistent
with Sec. 171.201(c)(1) indicates that a broad withholding of the
patient's EHI from a known, suspected, or potential abuser is
reasonably likely to substantially reduce a risk of harm to the patient
or another person, then the exception will apply to those practices so
long as its conditions are met in full. Moreover, provided its
conditions are met in full, this exception will also apply to practices
that may be likely to, or do, interfere with a legal representative's
access, exchange, or use of a patient's EHI to a lesser degree than
might an election not to recognize the representative as the patient's
personal representative in accordance with Sec. 164.502(g)(5)(i).
Because the finalized Sec. 171.201(d)(1) applies when a practice is
likely to, or does, interfere with a legal representative's access to
the patient's EHI, the harm standard required in such a situation is
that stated in Sec. 164.524(a)(3)(iii). Currently, that harm standard
is ``substantial harm.''
We also expressly note that, although the ``substantial harm''
standard applied by Sec. 171.201(d)(1) through cross-reference to
Sec. 164.524(a)(3)(iii) is not precisely the same as the requirement
in Sec. 164.502(g)(5)(i), we will interpret as sufficient for purposes
of Sec. 171.201(c)(1) and (d)(1) a licensed health care professional's
election not to treat a person as the patient's legal representative in
accordance with Sec. 164.502(g)(5)(i). Moreover, having noted above
the broad discretion licensed health care professionals have regarding
what information to factor into their individualized determinations
consistent with Sec. 171.201(c)(1), we highlight that this broad
discretion would allow them to consider any knowledge they might have
of another licensed health care professional, or other type of covered
entity, having elected in accordance with Sec. 164.502(g)(5)(i) not to
treat a person as the patient's representative.
Comments. Some comments implied concerns about the potential
conflict between the documentation requirements of this exception and
those required under other applicable law.
Response. Provided its conditions are met, this exception is
applicable in circumstances where a licensed health care professional
in the exercise of professional judgment has determined that there is a
risk of abuse beginning, as well as circumstances in which prior or
ongoing abuse is known or suspected. Actors have significant discretion
and flexibility in determining how best to document determinations and
the bases for their determinations. Where other law or regulations--
Federal, State, or tribal--require a specific form, manner, or content
of documentation in circumstances that would serve as basis for
individualized determinations consistent with the finalized Sec.
171.201(c)(1), we would consider that documentation relevant to
assessing the applicability of this exception to those practices. In
order to avoid potentially duplicative or other unnecessary burdens on
licensed health care professionals or other actors, we have decided not
to establish at this time a specific documentation condition and have
decided not to establish other
[[Page 25838]]
unique documentation requirements for this exception.
Comments. In reference to a specific illustrative example in the
Proposed Rule, one commenter indicated that withholding or delaying
availability of only specific sensitive data elements may not be
sufficient in circumstances such as those described in the Proposed
Rule example, and that revoking a suspected abuser's proxy access on
the whole may be more clinically appropriate in such circumstances (84
FR 7525).
Response. In response to this comment, we first clarify the intent
and function of the example provided in the Proposed Rule. In the
example, the licensed health care professional in the exercise of
professional judgment had determined that only some information within
the record would need to be withheld from the patient's partner's proxy
access to her EHI (84 FR 7525). Although not specifically stated in the
Proposed Rule, the example presumes a mature technical capability to
sequester data from specific user(s) on an itemized basis. The example
also presumes that the licensed health care professional, in their
exercise of professional judgment, had not formed a reasonable belief
that ceasing to recognize the patient's partner as her personal
representative, and entirely revoking the partner's proxy access to her
EHI, would substantially reduce a risk of harm to the patient. We
intended that the example illustrate that where the licensed health
care professional determined a risk of harm would arise from making a
specific piece of information accessible to the patient's proxy, the
minimum interference necessary to substantially reduce that risk of
harm would be to withhold that specific piece of information from the
patient's partner's proxy access to her EHI.
Comments. A commenter indicated that if a clinician has a suspicion
(confirmed or not) that the patient is suffering intimate partner or
elder abuse, it is considered clinically important that notes or other
data elements indicating the suspicion not be released to the patient
in the company of the suspected abuser. The commenter stated that such
disclosure could undermine the clinician's ability to help the patient
because the patient would likely be forced to switch clinicians. The
comment also indicated there may be a risk that an abuser could harm
the patient as a result of the disclosure of the clinician's suspicion.
Response. Because information blocking policy is specific to the
access, exchange, and use of EHI, we read the commenter's example as
suggesting two considerations specific to access, exchange, and use of
EHI. First, we believe the comment indicates we should expressly
acknowledge that these types of situations are often legally as well as
clinically complex. It is not our intent that our policies
unnecessarily add to this complexity. It is also not our intent that
our policies undermine the ability of a licensed health care
professional, or other actor relying on the professional's
determination, to take appropriate steps to reduce abuse risks to which
the professional's patients would otherwise be exposed. Nothing in
Sec. 171.201, or in the information blocking provisions generally,
requires an actor to disclose their awareness or suspicion of abuse to
the patient's legal representative in order to satisfy the conditions
of the Preventing Harm Exception. Second, our understanding of this
comment indicates that in some particular individualized circumstances
the licensed health care professional may determine in the exercise of
professional judgment that to substantially reduce a risk of harm it
may be necessary to withhold some portions of a patient's EHI from the
patient's own access through an API or patient portal. We can, for
example, envision possible circumstances where a licensed health care
professional with a clinician-patient relationship to the patient knows
or has reason to believe that a person suspected of abusing a patient
routinely ``looks over the shoulder'' of the patient while they access
their EHI, or uses the patient's own credentials to access the
patient's EHI. In such circumstances, this exception would apply to
practices interfering with the patient's own access to their EHI to the
extent the practices are not inconsistent with the HIPAA Privacy Rule
or the conditions in Sec. 171.201.
Comments. Several commenters suggested that the Preventing Harm
Exception should recognize more types of abuse, and a broader array of
potential types of harm than danger to life or physical safety in the
context of interfering with access to a patient's EHI by a legal
representative suspected of abusing the patient. One commenter
advocated that the Preventing Harm Exception should recognize all types
of violence and abuse. The commenter provided citations to professional
specialty expert committee opinions in support of their recommendation.
Response. As discussed above in reference to comments that
recommended aligning this rule's harm standards more closely to the
HIPAA Privacy Rule, we have, by cross-reference in Sec. 171.201(d)(1),
finalized as the harm standard applicable to practices interfering with
a legal representative's access to a patient's EHI the same harm
standard that would apply to denying a personal representative's access
to an individual's PHI under Sec. 164.524(a)(3)(iii). As Sec.
164.524(a)(3)(iii) stands at the time this rule is finalized, it
references ``substantial harm.'' As discussed above, this exception
will also apply to practices likely to interfere with a legal
representative's access, exchange, or use that are employed pursuant to
an election not to treat that legal representative as a personal
representative in accordance with Sec. 164.502(g)(5)(i). For purposes
of Sec. 171.201, ``substantial harm'' is interpreted as it is for
purposes of Sec. 164.524(a)(3)(iii). Thus, for purposes of not
recognizing a personal representative, or otherwise restricting patient
EHI access, exchange, or use by a representative known or suspected to
be abusing the patient, we believe the harm standard applicable under
this exception to practices affecting a legal representative's access,
exchange, or use of the patient's EHI is sufficiently broad. We
interpret the discretion afforded to a licensed health care
professional in making an individualized determination of risk of harm
consistent with the finalized Sec. 171.201(c)(1) (type of risk
condition) as allowing them to take into consideration clinical
practice guidelines and clinical expert groups' studied opinions
relevant to abuse-related risks of substantial harm. Only practices
based on the potential for harms that would not be recognized as
meeting the ``substantial harm'' standard, as it is interpreted by the
HHS Office for Civil Rights for purposes of Sec. 164.524(a)(3)(iii),
would fail to satisfy the type of harm condition finalized in Sec.
171.201(d)(1). We remind actors that any decision not to provide
access, exchange, or use of EHI on the basis of determination of risk
of harm consistent with the finalized Sec. 171.201(c)(1) and Sec.
171.201(d)(1), (2), (3), or (4) is subject to rights the individual
patient whose EHI is affected may be afforded by applicable regulations
or law to have the determination reviewed and potentially reversed.
(See the ``patient right to request review of individualized
determination of risk of harm'' condition finalized in Sec.
171.201(e), for which we also use ``patient review rights condition''
as a short form of reference for ease of discussion.) Where Sec.
164.524(a)(3) applies in addition to Sec. 171.201, Sec. 164.524(a)(4)
specifically
[[Page 25839]]
provides for review of determinations made by licensed health care
professionals in the exercise of professional judgment. In
circumstances where Sec. 171.201 applies but Sec. 164.524 does not,
Sec. 171.201(e) requires that an actor's practices be consistent with
any rights of review of individualized determinations of risk of harm
that the patient may be afforded under applicable Federal, State, or
tribal law or regulations. However, for purposes of Sec. 171.201(c)(1)
determinations, the type of harm must be consistent with: The harm
standard stated in Sec. 164.524(a)(3)(i) (interpreted as it is for
purposes of Sec. 164.524(a)(3)(i)) where Sec. 171.201(d)(3) or (4)
apply; the harm standard stated in Sec. 164.524(a)(3)(ii) (interpreted
as it is for purposes of Sec. 164.524(a)(3)(ii)) where Sec.
171.201(d)(2) applies; or the harm standard stated in Sec.
164.524(a)(3)(iii) (interpreted as it is for purposes of Sec.
164.524(a)(3)(iii)) where Sec. 171.201(d)(1) applies.
Finalized Policy for an Individualized Determination of Risk of Harm by
a Licensed Health Care Professional in the Exercise of Professional
Judgment
We are finalizing the substance of this aspect of the exception
with modifications to the way it is displayed and phrased in the
finalized regulation text in comparison to the Proposed Rule. If its
other conditions are also met, the finalized Preventing Harm Exception
will apply to a practice an actor reasonably believes will
substantially reduce a risk of harm consistent with the sub-paragraph
of Sec. 171.201(d), as finalized, that applies to the specific access,
exchange, or use, where the risk of harm is determined on an
individualized basis in the exercise of professional judgment by a
licensed health care professional who has a current or prior clinician-
patient relationship with the patient whose EHI is affected by the
determination. In comparison to the proposed text of Sec. 171.201 (84
FR 7602), we have reorganized the regulation text in response to
comments requesting our regulatory text, in general, be easier to use
for purposes such as understanding how the conditions of the exception
relate to one another and how they apply to practices used in
particular types of circumstances. We have left the potential sources
of risk of harm in a single paragraph (finalized Sec. 171.201(c)), but
separated them from the reasonable belief condition paragraph
(finalized Sec. 171.201(a)). The sources of risk of harm are also, as
discussed above, presented in two sub-paragraphs in the finalized text
of Sec. 171.201(c) (type of harm) instead of being split across three
sub-paragraphs as they were in the Proposed Rule.
In subparagraph (a)(3) of the proposed text of Sec. 171.201 (84 FR
7602), we expressed the additional condition that practices based on
individualized determinations of risk of harm are subject to any rights
of review of the determination that the patient may be afforded under
applicable law. This patient review rights condition is finalized in
Sec. 171.201(e). As finalized, this condition requires that where a
risk of harm is determined on an individualized basis (consistent with
Sec. 171.201(c)(1) as finalized), the actor must honor any rights the
individual patient whose EHI is affected may have under Sec.
164.524(a)(4) or any Federal, State, or tribal law applicable in the
circumstances to have the determination reviewed and potentially
reversed. We have stated the condition for providing review rights
afforded by law in the separate paragraph (e) of Sec. 171.201 instead
of including it within subparagraph (c)(1) because in the context of
171.201 the patient review rights condition functions as a condition on
how practices based on such belief are implemented more than as a
required characteristic of the Sec. 171.201(c)(1) determination
itself.
The finalized text of Sec. 171.201(c)(1) also differs from the
proposed regulation text specific to individualized determinations of
risk in explicitly stating the requirement that the licensed health
care professional making the determination must have a current or prior
clinician-patient relationship with the patient whose EHI is affected
by the determination. For purposes of Sec. 171.201--as we discussed in
the Proposed Rule's preamble, and above in this preamble--we believe
the broad discretion afforded to licensed health care professionals to
make individualized determinations of risks of harm in the exercise of
professional judgment is appropriate in the context of the expectation
that a licensed health care professional with a clinician-patient
relationship to a patient has the opportunity to have knowledge of the
patient and their individual circumstances that is not generally
available outside the context of a clinician-patient relationship. We
believe that explicitly stating in Sec. 171.201(c)(1) the requirement
for a clinician-patient relationship accomplishes two purposes: First,
it ensures that this is immediately clear on the face of the finalized
regulation text that only determinations made by licensed health care
professionals who have or have had a clinician-patient relationship
with the patient will be considered consistent with Sec.
171.201(c)(1); and, second, it is also clear that the condition for a
clinician-patient relationship is specific and limited to
determinations of risks of harm on an individualized basis in the
exercise of professional judgment by a licensed health care
professional (Sec. 171.201(c)(1) as finalized). Please note that this
requirement is specific to the individualized determination of risk of
harm, and does not limit application of Sec. 171.201 to practices
implemented directly by the licensed health care professional making a
determination of risk of harm consistent with Sec. 171.201(c)(1) as
finalized. Appropriately tailored practices applied because the actor
has a reasonable belief the practice will substantially reduce a risk
of harm that was determined on an individualized basis consistent with
Sec. 171.201(c)(1) will, if all other applicable conditions of Sec.
171.201 are met, be recognized under this exception whether the
practices are undertaken by the licensed health care professional
making the determination or by another actor (e.g., another licensed
health care professional, a hospital, or a HIN) having custody or
control of the patient's EHI and knowledge of the individualized
determination of risk of harm associated with particular access(es),
exchange(s), or use(s) of that EHI.
As finalized, Sec. 171.201(d) differs from the proposed policy in
that it does not uniformly require that the risk determined on an
individualized basis be to life or physical safety of the patient or
another person in all circumstances. Instead, through specified cross-
references to the sub-paragraphs of Sec. 164.524(a)(3), the finalized
Sec. 171.201(d) type of harm condition uses the same harm standards
for the circumstances where both the Preventing Harm Exception and
Sec. 164.524(a)(3) apply. Also through cross-references, the type of
harm condition applies the Sec. 164.524(a)(3) harm standards in
circumstances similar to those in which Sec. 164.524(a)(3) applies but
where only Sec. 171.201 actually applies. The finalized Sec.
171.201(d) does not cross-reference Sec. 164.502(g)(5)(i), but it is
constructed so that it does apply to practices interfering with a
personal representative or other legal representative's access to a
patient's EHI consistent with an actor declining to recognize such a
representative on the same bases as a HIPAA covered entity could elect
not to recognize a person as an individual's personal representative
consistent with Sec. 164.502(g)(5)(i). In order to retain a clear,
consistent set of
[[Page 25840]]
harm standards throughout the Sec. 171.201 type of harm condition,
however, we note that where a HIPAA covered entity elects not to
recognize an individual's personal representative consistent with Sec.
164.502(g)(5)(ii), the Preventing Harm Exception would not apply.\159\
---------------------------------------------------------------------------
\159\ Because Sec. 164.502(g)(5)(ii) currently applies a
standard not of harm but of determination by the covered entity that
recognizing a person as personal representative is not in the best
interest of the individual, we have determined it is more
appropriate to address these circumstances in context of the
exception for practices promoting privacy of EHI, finalized in Sec.
171.202 and discussed in Section VIII.D.1.b of this final rule
preamble.
---------------------------------------------------------------------------
Consistent with the HIPAA Privacy Rule, a decision not to provide
access, exchange, or use of EHI on the basis finalized in Sec.
171.201(c)(1) is subject to the rights the individual patient whose EHI
is affected may be afforded by applicable law to have the determination
reviewed and potentially reversed. While any such determination reviews
may be pending, application of practices interfering with the patient's
access, exchange, or use of their EHI based on an individualized
determination by a licensed health care professional (Sec. 171.201(c))
that are otherwise compliant with the conditions of Sec. 171.201 as a
whole will be considered to be covered by the exception.
Upon becoming aware of a reversal of the determination on which the
actor's required reasonable belief was based, whether as a result of a
review requested by the patient or other processes, the actor's
continued application of practices based on the original determination
would no longer be consistent with the conditions of Sec. 171.201.
Likewise, upon becoming aware of a revision of the determination on
which the actor's required reasonable belief was originally based,
whether the revision resulted from a review requested by the patient or
other processes, practices applied to the patient's EHI after the
revision is made will need to comply with the conditions of Sec.
171.201 in light of the revised determination in order for the practice
to continue to be covered under Sec. 171.201.
For the specific purposes of Sec. 171.201, the rights to obtain
review or reconsideration of a provider's individualized determination
of risk of harm reside with the patient whose EHI is affected. The
rights in many cases may be exercised on the patient's behalf by the
patient's personal or other legal representative. However, it may not
be appropriate, or feasible, for the patient's representative to
exercise the patient's review rights in circumstances where the
individualized determination of risk of harm is or includes a
determination that recognizing that same person as the patient's
representative, or providing specific information to that same
recognized representative, would pose a risk of cognizable harm. In a
circumstance where the actor has a reasonable belief that such
disclosure could create or increase a risk of harm to the patient, this
exception does not require the candid disclosure to a known, suspected,
or potential abuser of the rationale for use of particular practices,
or even the precise practices, interfering with that representative's
access, exchange, or use of EHI. We would, however, generally expect
actors to be as candid with the patient per se as is clinically
appropriate and safely practicable in their individualized
circumstances.
Where an actor lacks the technical capability to sequester only
that EHI the actor reasonably believes poses a risk of cognizable harm
from other data for which the actor does not pose such risk of harm,
this lack of segmentation capability would not render Sec. 171.201
applicable to practices likely to, or that do, interfere with access,
exchange, or use of the other data. Rather, where such lack of
segmentation capabilities renders the actor unable to support an
otherwise legally permissible access, exchange, or use of EHI, the
actor should reference the Content and Manner Exception (Sec. 171.301)
or the Infeasibility Exception (Sec. 171.204).
Licensed health care professionals have discretion to determine how
to use their EHRs and/or other records kept in their ordinary course of
business to capture and preserve documentation of and relevant to their
individualized determinations. Information relevant to determinations
would include the facts or circumstances that substantially informed
each determination, and any other decision-making information that the
professional may otherwise have difficulty recalling or reconstructing
if later asked to explain how or why they reached their individualized
determination in a particular case.
Practices Implemented Based on an Organizational Policy or on
Determination Specific to the Facts and Circumstances
To qualify for the Preventing Harm Exception, we proposed that an
actor would be required to have, while engaging in the practice(s) for
which application of the exception is claimed, a reasonable belief that
the practice(s) will ``directly and substantially'' \160\ reduce the
likelihood of harm to a patient or another person. As discussed in the
Proposed Rule and above, the type of risk and the potential harm must
also be cognizable under this exception (84 FR 7525 and 7526).
---------------------------------------------------------------------------
\160\ As, and for the reasons, discussed earlier in this section
of this preamble, we have removed ``directly and'' from the belief
standard finalized in Sec. 171.201(a).
---------------------------------------------------------------------------
Under Sec. 171.201 as proposed, an actor would be able to
demonstrate having satisfied the condition of reasonable belief that a
practice will reduce the likelihood of harm (``reasonable belief
condition'') through a qualifying organizational policy (proposed Sec.
171.201(b)) and/or a qualifying individualized determination (proposed
Sec. 171.201(c)). We discuss below the details of our proposal,
respond to comments, and summarize finalized policy specific to each of
these approaches to demonstrating the required reasonable belief that a
practice will substantially \161\ reduce a risk of harm cognizable
under this exception.
---------------------------------------------------------------------------
\161\ As, and for the reasons, discussed earlier in this section
of this preamble, the belief standard finalized in Sec. 171.201(a)
requires the actor believe the practice will ``substantially
reduce'' a risk of harm to a patient or another natural person that
would otherwise arise from the access, exchange, or use of
electronic health information affected by the practice.
---------------------------------------------------------------------------
Practices Implemented Based on an Organizational Policy
In the Proposed Rule (84 FR 7525), we proposed that to qualify for
this exception, an actor must have had a reasonable belief that the
practice or practices will directly and substantially reduce the
likelihood of harm to a patient or another person and that the type of
risk must also be cognizable under this exception. We proposed that an
actor could meet this condition in two ways: Through a ``qualifying
organizational policy'' (Sec. 171.201(b) as proposed) or through a
``qualifying individualized finding'' (Sec. 171.201(c) as proposed).
We stated in the Proposed Rule that we anticipate that in most
instances where Sec. 171.201 would apply, the actor would demonstrate
that the practices it engaged in were consistent with an organizational
policy that was objectively reasonable and no broader than necessary
for the type of patient safety risks at issue. We also noted in the
Proposed Rule that within any type of actor defined in Sec. 171.102,
organizations may vary significantly in structure, size, and resources.
Further, even when an organizational policy exists, it may not
anticipate all of the potential risks of harm that could arise in real-
world clinical or production
[[Page 25841]]
environments of health IT. Thus, we proposed in Sec. 171.201(c) (84 FR
7602) that in lieu of demonstrating that a practice conformed to a
policy that met the conditions described in proposed Sec. 171.201(b)
and the Proposed Rule preamble at 84 FR 7525, the actor could justify
the practice(s) directly by making a finding in each case, based on the
particularized facts and circumstances.
We proposed that where the proposed Sec. 171.201(b) (84 FR 7602)
would apply, an actor's policy would need to be:
In writing;
developed with meaningful input from clinical, technical,
and other appropriate staff or others who have expertise or insight
relevant to the risk of harm that the policy addresses;
implemented in a consistent and non-discriminatory manner;
and
no broader than necessary to mitigate the risk of harm.
We stated that the proposed condition would not be met if, for
example, a hospital imposed top-down information sharing policies or
workflows established by the hospital's EHR developer and approved by
hospital administrators without meaningful input from the medical
staff, IT department, and front-line clinicians who are in the best
position to gauge how effective it will be at mitigating patient safety
risks.
Comments. Commenters expressed concern that information blocking
policy and its interaction with other applicable laws and regulations,
such as the HIPAA Rules, are complex and that there will be costs and
other burden associated with understanding how the policies affect an
actor's daily operations. Commenters also expressed concern that it
would be too burdensome to be required to demonstrate, in any of the
ways we proposed, that they have a reasonable belief that practices
would reduce a risk of cognizable harm.
Response. We understand that complexity can increase difficulty in
understanding and complying with any regulation. We also understand
that the interaction between the HIPAA Rules and the information
blocking provision is inherently complex. However, without an exception
from the information blocking definition for practices appropriately
tailored to reduce risks of harm, we believe actors would be subject to
the greater burden of needing to craft practices that avoid violating
the information blocking provision without also making EHI available
for access, exchange, or use in circumstances where that puts patients
or other natural persons at risk of harm. This exception's conditions
give actors a framework within which they can develop or refine their
practices in assurance that practices meeting the conditions in Sec.
171.201 are excepted from the definition of information blocking
finalized in Sec. 171.103. At the same time, implementing such an
exception without appropriate conditions could have the unintended and
undesirable effect of excusing conduct that would more appropriately
remain within the definition of information blocking.
Therefore, in Sec. 171.201, we have finalized conditions that
strike a practical balance between minimizing burdens on actors and
ensuring that the interests of patients in the access, exchange, and
use of their EHI are adequately protected. These conditions are, in
comparison to the Proposed Rule, more granularly and durably aligned
with relevant HIPAA right of access provisions (Sec. 164.526(a)(3))
and this alignment reduces complexity.
We have revised the way the regulation text is presented and
phrased so that it is easier to understand what is required in order
for a practice to be excepted from the definition of information
blocking under this exception. Moreover, we have avoided specifying
particular or unique forms, methods, or content of documentation for
purposes of this exception. We believe the flexibility this offers
actors to determine the most efficient approach to documenting their
practices and determinations relevant to this exception enables them to
achieve and document satisfaction of the exception's condition with the
lowest practicable burden.
Comments. A number of commenters noted that there will be burden
associated with developing or revising organizational policies and
training staff so they can use this exception in compliance with its
conditions. Several of these commenters suggested we provide additional
guidance and informational resources, in this final rule or otherwise,
to help actors develop their policies and staff training. Some
commenters advocated that we develop templates or models that actors
could use to more efficiently develop policies consistent with the
conditions for applicability of this exception.
Response. We appreciate the feedback and do recognize that
developing or revising internal policies and procedures when compliance
requirements change due to changes in law requires some effort. While
recognizing the utility of the types of resource materials suggested by
commenters, we believe they are best developed and provided outside the
rulemaking process. We will continue working to engage with the
stakeholder communities to promote understanding and foster compliance
with the information blocking provision amongst all actors within the
definitions in Sec. 171.102. We also believe that in many cases
voluntary groups with relevant expertise, such as professional
societies and provider organizations, may be in the best position to
develop resources tailored to the particular needs and preferences of
specific segments or communities within any given type of actor.
Comments. Some commenters stating that developing new or revised
organizational policies and training staff in the policies requires
time recommended that we establish a grace period before organizations'
policies and actual practices must fully comply with Sec. 171.201
conditions in order to be recognized as reasonable and necessary under
Sec. 171.201.
Response. This concern is not unique to Sec. 171.201. Commenters
also raised this concern in the context of information blocking in
general. As we stated in section VIII.B.3 of this preamble, we thank
commenters for their input. Comments related to the overall timing of
information blocking enforcement have been shared with OIG. We
emphasize that individuals and entities subject to the information
blocking provision must comply with the ONC final rule as of the
compliance date of the information blocking section of this final rule
(45 CFR part 171). We have finalized a compliance date for 45 CFR part
171 as a whole that is six months after the date this final rule is
published in the Federal Register.
OIG and ONC are coordinating timing of the compliance date of the
information blocking section of this final rule (45 CFR part 171) and
the start of information blocking enforcement. We are providing the
following information on timing for actors. Enforcement of information
blocking CMPs in section 3022(b)(2)(A) of the PHSA will not begin until
established by future notice and comment rulemaking by OIG. As a
result, actors would not be subject to penalties until CMP rules are
final. At a minimum, the timeframe for enforcement would not begin
sooner than the compliance date of the information blocking section of
this final rule (45 CFR part 171) and will depend on when the CMP rules
are final. Discretion will be exercised such that conduct that occurs
before that time will not be subject to information blocking CMP.
Specific to Sec. 171.201, as discussed above in response to other
comments
[[Page 25842]]
received specific to the Preventing Harm Exception, we have applied
Sec. 164.524(a)(3) harm standards under Sec. 171.201 to circumstances
where both sections of 45 CFR would apply, and to circumstances where
only Sec. 171.201 applies but that are similar in significant respects
to circumstances where Sec. 164.524(a)(3) applies. In substantial part
because of this alignment, we do not believe there is a need to delay
the applicability of any of the conditions for a practice to be
excepted under Sec. 171.201 from the definition of information
blocking in Sec. 171.103.
Actors who are also HIPAA covered entities or business associates
should already have policies in place consistent with the HIPAA Privacy
Rule, including but not limited to Sec. 164.524(a)(3). These actors
and their staff members should be well versed in these policies and
practices. Where Sec. 164.524(a)(3) would not apply but Sec.
171.201(d)(3) or (4) would apply, we believe using the same, familiar
standard for the risk that the actor must believe their practice would
reduce as would apply to Sec. 164.524(a)(3)(i) should facilitate
efficient updates to organizational policies and streamline any staff
training that may be indicated specific to Sec. 171.201. We also note
that the finalized Preventing Harm Exception also provides, in Sec.
171.201(f)(2), for coverage of practices implemented in absence of an
applicable organizational policy or where existing organizational
policy does not address the particular practice in the particularized
circumstances. Moreover, although we encourage actors to voluntarily
conform their practices to the conditions of an exception suited to the
practice and its purpose, an actor's choice to do so simply provides
them an enhanced level of assurance that the practices do not meet the
definition of information blocking. However, failure to meet an
exception does not necessarily mean a practice meets the definition of
information blocking. We reiterate, if subject to an investigation by
HHS, each practice that implicates the information blocking provision
would be analyzed on a case-by-case basis.
Comments. Several commenters indicated that providers' current
organizational policies call for practices that delay the release of
laboratory results so that the patient's clinician has an opportunity
to review the results before potentially needing to respond to patient
questions, or has an opportunity to communicate the results to the
patient in a way that builds the clinician-patient relationship. Some
commenters indicated their standard practice is to automatically time-
delay release of results in general, with an automatic release at the
end of a time period determined by the organizational policy in place
to ensure that patients can consistently access their information
within the timeframe targeted by relevant measures under the CMS
Promoting Interoperability Programs. Commenters requested we clarify
whether such practices would be recognized under Sec. 171.201 or that
we recognize such current organizational policies and practices as
excepted from the definition of information blocking.
Response. While we recognize the importance of effective clinician-
patient relationships and patient communications, we are not persuaded
that routinely time-delaying the availability of broad classes of EHI
should be recognized as excepted from the information blocking
definition under this exception. Consistent with Sec. 171.201(d)(3) as
finalized, the harm of which a practice must reduce a risk must, where
the practice interferes with the patient's access to their own EHI, be
one that could justify denying the patient's right of access to PHI
under Sec. 164.524(a)(3). Currently, Sec. 164.524(a)(3)(i) requires
that for a covered entity to deny an individual access to their PHI
within the designated record set, the disclosure of that PHI must be
reasonably likely to endanger the life or physical safety of the
patient or another person.\162\ No commenter cited evidence that
routinely delaying EHI availability to patients in the interest of
fostering clinician-patient relationships substantially reduces danger
to life or physical safety of patients or other persons that would
otherwise routinely arise from patients' choosing to access the
information as soon as it is finalized.
---------------------------------------------------------------------------
\162\ Note that for purposes of Sec. 164.524(a)(3)(i),
``individual'' is defined in Sec. 160.103, but for purposes of
Sec. 171.201 an actor must reasonably believe a practice will
substantially reduce a risk of cognizable harm to patient(s) or
other natural person(s).
---------------------------------------------------------------------------
Moreover, we are independently aware, and some comment submissions
confirmed, that it is not uncommon to automatically release lab and
other findings to patients electronically regardless of whether a
clinician has seen the information or discussed it with the patient
before the patient can choose to access it electronically. We presume
these types of automatic releases would not be the case if patients'
accessing their information on a timeframe that is more of their own
choosing routinely posed a risk to the life or physical safety of these
patients or other natural persons. Thus, we believe that where
applicable law does not prohibit making particular information
available to a patient electronically before it has been conveyed in
another way, deference should generally be afforded to patients' right
to choose whether to access their data as soon as it is available or
wait for the provider to contact them to discuss their results. Only in
specific circumstances do we believe delaying patients' access to their
health information so that providers retain full control over when and
how it is communicated could be both necessary and reasonable for
purposes of substantially reducing a risk of harm cognizable under
Sec. 171.201(d) (as finalized). Circumstances where Sec. 171.201
would apply to such delay are those where a licensed health care
professional has made an individualized determination of risk in the
exercise of professional judgment consistent with Sec. 171.201(c)(1),
whether the actor implementing the practice is the licensed health care
professional acting directly on their own determination or another
actor implementing the delay in reliance on that determination. An
actor could choose to demonstrate the reasonable belief required by
Sec. 171.201(a) through an organizational policy (Sec. 171.201(f)(1))
with which the practice is consistent, or based on a determination
based on facts and circumstances known or reasonably believed by the
actor at the time the determination was made and while the practice
remains in use (Sec. 171.201(f)(2)), to rely on a determination
consistent with Sec. 171.201(c)(1).
Comments. Health care professionals commented that clinical
experience indicates a systematic and substantial risk that releasing
some patient data through a patient portal or API without first
communicating the particular results or diagnosis with the patient in a
more interactive venue would pose risks of substantial harm to
patients. One example commenters specifically cited was genetic testing
results indicating a high risk of developing a neurodegenerative
disease for which there is no effective treatment or cure. Commenters
recommended that we define this exception to allowing delay of the
electronic release of such genetic testing results, as a matter of
organizational policy, to ensure patients and their families are not
exposed to this information without appropriate counseling and context.
One comment indicated that delivery by the clinician of the combined
results, counseling, and context is clinically appropriate and
consistent with the conclusions of relevant research.
[[Page 25843]]
Response. To satisfy the conditions of Sec. 171.201, and actor
would have to demonstrate that they held a reasonable belief that
delaying availability of information until the information can be
delivered in combination with appropriate counseling and context in an
interactive venue will substantially reduce a risk of harm cognizable
under this exception. An actor could accomplish such demonstration
through showing the practice is consistent with either an
organizational policy meeting Sec. 171.201(f)(1) or a determination
based on facts and circumstances known or reasonably believed by the
actor at the time the determination was made and while the practice
remains in use meeting Sec. 171.201(f)(2). However, for a practice
likely to, or that does in fact, interfere with the patient's access to
their own EHI (Sec. 171.201(d)(3)), the actor implementing these
practices must demonstrate a reasonable belief that the practice will
substantially reduce a risk of harm to the life or physical safety of
the patient. The clinician who orders testing of the sort referenced in
the comment would, we presume, do so in the context of a clinician-
patient relationship. In the context of that relationship, a licensed
health care professional should be well positioned to make
determinations consistent with Sec. 171.201(c)(1) as to specifically
when their patients, or other particular natural persons, would face a
risk of harm cognizable under Sec. 171.201(d)(3)--or Sec.
171.201(d)(1) or (2) if or as may be applicable--if the access,
exchange, or use of a particular testing result or diagnosis were to be
released electronically before it could be explained and contextualized
by an appropriately skilled professional, such as a clinician or a
health educator, in real time.
Summary of Finalized Policy: Practices Implemented Based on an
Organizational Policy
We have finalized that to demonstrate the reasonable belief
required by Sec. 171.201(a) based on an organizational policy, the
policy must:
(i) Be in writing;
(ii) Be based on relevant clinical, technical, and other
appropriate expertise;
(iii) Be implemented in a consistent and non-discriminatory manner;
(iv) Conform each practice to the conditions in paragraphs (a) and
(b) of this section, as well as the conditions of paragraphs (c)
through (e) of this section applicable to the practice and its use.
We have modified the regulation text finalized in Sec.
171.201(f)(1) consistent with other revisions to Sec. 171.201. We have
redesignated this paragraph from (b) to (f)(1), and redesignated its
proposed sub-paragraphs from (1) through (4) to (i) through (iv). We
have in comparison to the main paragraph language of the proposed Sec.
171.201(b) modified the phrasing of the finalized paragraph (f) so that
Sec. 171.201 as finalized is more immediately clear on its face that
what is finalized in Sec. 171.201(f) is a condition for practices to
meet the exception, and that paragraph (f) can be satisfied by meeting
either subparagraph (1) or (2).
Practices applied based on an organization policy to rely on
individualized determinations of risk of harm consistent with Sec.
171.201(c)(1) would be covered under Sec. 171.201 to the extent they
otherwise meets its conditions. Neither an organizational policy (Sec.
171.201(f)(1)), nor a determination based on facts and circumstances
known or reasonably believed by the actor at the time the determination
was made and while the practice remains in use ((Sec. 171.201(f)(2))
would be required to routinely evaluate or otherwise assess the
licensed health care professional's exercise of professional judgment
in order for practices implemented in reliance on the professional's
Sec. 171.201(c)(1) determination to be meet the conditions of Sec.
171.201.
Practices Implemented Based on a Determination Specific to the Facts
and Circumstances
As discussed in the Proposed Rule, we recognize that some actors
(such as small health care providers and small HINs/HIEs) may not have
comprehensive and formal policies governing all aspects of EHI and
patient safety. Additionally, even if an organizational policy exists,
it may not anticipate all of the potential risks of harm that could
arise in real-world clinical or production environments of health IT.
In these circumstances, in lieu of demonstrating that a practice
conformed to the actor's policies and that the policies met the
conditions proposed in Sec. 171.201(b), we proposed that the actor
could justify its use of particular practices by making a finding in
each case, based on the particularized facts and circumstances, that
the practice is necessary and no broader than necessary to mitigate the
risk of harm. To do so, we proposed that the actor would need to show
that the practices were approved on a case-by-case basis by an
individual with direct knowledge of the relevant facts and
circumstances and who had relevant clinical, technical, or other
appropriate expertise. Such an individual would need to reasonably
conclude, based on those particularized facts and circumstances and
his/her expertise and best professional judgment, that the practice was
necessary, and no broader than necessary, to mitigate the risk of harm
to a patient or other persons. We further proposed that a licensed
health care professional's independent and individualized judgment
about the safety of the actor's patients or other persons would be
entitled to substantial deference under this proposed exception. So
long as the clinician considered the relevant facts and determined
that, under the particular circumstances, the practice was necessary to
protect the safety of the clinician's patient or another natural
person, we would not second-guess the clinician's professional
judgment. To provide further clarity on this point, we provided an
illustrative example in the preamble to the proposed rule (see 84 FR
7525).
Comments. Commenters requested that we clarify, provide guidance,
or establish specifications for the documentation necessary to
substantiate applicability of the Preventing Harm Exception based on
qualifying determinations particularized to specific facts and
circumstances. Some commenters indicated that such specificity or
guidance is needed to avoid imposing on actors such as health care
providers and HINs/HIEs excess burden associated with documentation in
the absence of such guidance or specification.
Response. We appreciate these commenters highlighting that the
potential for uncertainty or confusion about what is minimally
necessary to demonstrate satisfaction of a new policy can often lead to
capturing and retaining a wide array of information just in case it may
be needed or useful later. We have clarified the way in which all of
the conditions in Sec. 171.201 are stated and organized within the
section. We also note here that an actor does not need to draft for
each determination consistent with Sec. 171.201(f)(2) a comprehensive
defense of their findings. We believe the finalized statement of the
condition, reinforced by this preamble discussion, provides certainty
that we do not intend or expect actors to create new records systems or
types, or to create or retain duplicate information or documentation
across their current medical and other business records. Ultimately, it
is the actor's responsibility to demonstrate they met the conditions of
an exception.
[[Page 25844]]
Summary of Finalized Policy: Practices Implemented Based on a
Determination Specific to the Facts and Circumstances
We have finalized the substance of this condition as proposed, with
modifications to the regulation text. We have also reorganized Sec.
171.201 so that it is easier to read and understand. We have
redesignated this paragraph from (c) to (f), and broken it into
subparagraphs. We have in comparison to the main paragraph language of
the proposed Sec. 171.201(c) modified the phrasing of the finalized
paragraph (f) so that Sec. 171.201 as finalized is more immediately
clear on its face that what is finalized in Sec. 171.201(f)(2) is a
means to demonstrate a practice implemented in absence of an
applicable, or perhaps any, organizational policy nevertheless meets
the conditions to be exempted under Sec. 171.201 from the definition
of information blocking in Sec. 171.103.
We have separated from both the requirements applicable to
individualized determinations of risk (finalized in the type of risk
condition in Sec. 171.201(c)(1)) and the requirements applicable to
practices implemented based on organizational policy (Sec.
171.201(f)(1)) or to practices implemented pursuant to a determination
based on the facts and circumstances (Sec. 171.201(f)(2)) the patient
review rights condition expressed in subparagraph (a)(3) of the
proposed text of Sec. 171.201 (84 FR 7602). We have finalized the
patient review rights condition in Sec. 171.201(e) instead of the
finalized (f) because it applies equally to practices implemented based
on an organizational policy and by practices implemented based on
determinations based on facts and circumstances, in parallel to the
other conditions for a practice to be excepted under Sec. 171.201 from
the definition of information blocking in Sec. 171.103.
In the finalized patient review rights condition (Sec.
171.201(e)), in comparison with proposed Sec. 171.201(a)(3) (84 FR
7602), we have revised the wording in which we state the condition for
honoring any rights that applicable law may afford patients to have
these individualized determinations reviewed and potentially reversed.
The condition finalized in Sec. 171.201(e) is that where the risk of
harm is consistent with paragraph (c)(1) of this section, the actor
must implement its practices in a manner consistent with any rights the
individual patient whose EHI is affected may have under Sec.
164.524(a)(4) of this title, or any Federal, State, or tribal law, to
have the determination reviewed and potentially reversed.
We also revised in finalized Sec. 171.201(e), in comparison with
the proposed Sec. 171.201(a)(3), the wording of the condition
finalized in Sec. 171.201(e) in comparison to the wording of this
condition as proposed in 171.201(a)(3) for two reasons. First, the
wording has been revised to fit its placement within the finalized
section. Second, the wording has been revised to more clearly and
completely state the sources of the review rights that must be
afforded, if applicable. We note that such review rights will be
afforded by Sec. 164.524(a)(4) in the circumstances where both Sec.
164.524(a)(3) and Sec. 171.201 apply. However, rights that must be
honored to meet the conditions of Sec. 171.201 are not limited to
those afforded by Sec. 164.24(a)(4) or to circumstances where Sec.
164.524 applies in addition to Sec. 171.201. Rights of review of an
individualized determination of risk of harm (Sec. 171.201(c)(1))
might also be afforded by Federal, State, or tribal law applicable in
the particular circumstances.
We do not believe it is necessary to expressly state in the
regulation text that we interpret regulations promulgated based on such
laws, and that have the force and effect of law on individuals and
entities they regulate, to be within the meaning of ``law'' for
purposes of Sec. 171.201(e). However, we expressly state this here in
order to provide the type of assurance we believe many commenters were
seeking when stating in their comment submissions requests or
recommendations for additional guidance in the final rule. In order for
the practice(s) to satisfy the condition in Sec. 171.201(e), where
otherwise applicable law affords a patient right(s) to request review
of individualized determinations of risk of harm associated with the
patient's access, exchange, or use of their EHI, the actor's
practice(s) be implemented in a manner consistent with those rights--
regardless of which specific law(s) afford the rights applicable in the
particular circumstances.
b. Privacy Exception--When will an actor's practice of not fulfilling a
request to access, exchange, or use electronic health information in
order to protect an individual's privacy not be considered information
blocking?
We proposed to establish an exception to the information blocking
provision for practices that are reasonable and necessary to protect
the privacy of an individual's EHI, provided certain conditions are met
(84 FR 7526). The exception and corresponding conditions were set forth
in the proposed regulation text in Sec. 171.202. We noted that any
interference practice that an actor is engaged in to protect the
privacy of an individual's EHI must be consistent with applicable laws
and regulations related to health information privacy, including the
HIPAA Privacy Rule, the HITECH Act, 42 CFR part 2, and State laws. We
emphasized that this exception to the information blocking provision
does not alter an actor's obligation to comply with applicable laws (84
FR 7526).
We noted that this exception is necessary to support basic trust
and confidence in health IT infrastructure. Without this exception,
there would be a significant risk that actors would share EHI in
inappropriate circumstances, such as when an individual has taken
affirmative steps to request that the EHI not be shared under certain
conditions or when an actor has been unable to verify a requester's
identity before sharing EHI.
We explained that this proposed exception was structured with
discrete ``sub-exceptions.'' An actor's practice must qualify for a
sub-exception to be covered by the exception. We noted that the sub-
exceptions were, to a large extent, crafted to closely mirror privacy-
protective practices that are recognized under State and Federal
privacy laws. In this way, the privacy sub-exceptions to the
information blocking provision recognize as reasonable and necessary
those practices that are engaged in by actors to be consistent with
existing laws, provided that certain conditions are met.
We proposed four sub-exceptions that address the following privacy
protective practices: (1) Not providing access, exchange, or use of EHI
when a State or Federal law requires that a precondition be satisfied
before an actor provides access, exchange, or use of EHI, and the
precondition is not satisfied (proposed in Sec. 171.202(b)); (2) not
providing access, exchange, or use of EHI when the actor is a health IT
developer of certified health IT that is not covered by the HIPAA
Privacy Rule in respect to a practice (proposed in Sec. 171.202(c));
(3) a covered entity, or a business associate on behalf of a covered
entity, denying an individual's request to access to their electronic
protected health information (ePHI) in the circumstances provided in 45
CFR 164.524(a)(1)(2) or (3) (proposed in Sec. 171.202(d)); and (4) not
providing access, exchange, or use of EHI pursuant to an individual's
request, in certain situations (proposed in Sec. 171.202(e)) (84 FR
7526).
We proposed that an actor would need to satisfy at least one sub-
exception with respect to a purportedly
[[Page 25845]]
privacy-protective practice that interferes with access, exchange, or
use of EHI to not be subject to the information blocking provision.
Each proposed sub-exception has conditions that must be met in order
for an actor's practice to qualify for protection under the sub-
exception (84 FR 7526).
Modification
We have changed the title of this exception from ``Exception--
Promoting the privacy of electronic health information'' in the
Proposed Rule (84 FR 7602) to ``Privacy Exception--When will an actor's
practice of not fulfilling a request to access, exchange, or use
electronic health information in order to protect an individual's
privacy not be considered information blocking?'' Throughout this final
rule preamble, we use ``Privacy Exception'' as a short form of this
title, for ease of reference. As stated in Section VIII.D of this final
rule preamble, we have changed the titles of all of the exceptions to
questions to improve clarity. We have edited the wording of the
introductory text in Sec. 171.202 as finalized, in comparison to that
proposed (84 FR 7602) so that it is consistent with the finalized title
of Sec. 171.202. We believe these conforming changes in wording of the
introductory text also improve clarity in this section.
Specific Terminology Used for the Purposes of This Proposed Exception
We noted that the proposed exception used certain terms that are
defined by the HIPAA Rules \163\ but that, for purposes of the
exception, may have a broader meaning in the context of the information
blocking provision and its implementing regulations as set forth in the
Proposed Rule. We explained that, in general, the terms ``access,''
``exchange,'' and ``use'' have the meaning in proposed Sec. 171.102.
However, we noted that in some instances we referred to ``use'' in the
context of a disclosure or use of ePHI under the HIPAA Privacy Rule, in
which case we explicitly stated that the term ``use'' had the meaning
defined in 45 CFR 160.103. Similarly, we referred in a few cases to an
individual's right of access under 45 CFR 164.524, in which case the
term ``access'' should be understood in that HIPAA Privacy Rule
context. We emphasized that, for purposes of section 3022 of the PHSA,
however, the term ``access'' includes, but is broader than, an
individual's access to their PHI as provided for by the HIPAA Privacy
Rule (84 FR 7526).
---------------------------------------------------------------------------
\163\ 45 CFR part 160 and subparts A, C, and E of part 164.
---------------------------------------------------------------------------
Finally, we noted that the term ``individual'' is defined by the
HIPAA Rules at 45 CFR 160.103. Separately, under the information
blocking enforcement provision, we noted that the term ``individual''
is used to refer to actors that are health IT developers of certified
health IT, HINs, or HIEs (see section 3022(b)(2)(A) of the PHSA). We
clarified that for purposes of this exception (and only this
exception), we used neither of these definitions. Instead, the term
``individual'' encompassed any or all of the following: (1) An
individual defined by 45 CFR 160.103; (2) any other natural person who
is the subject of EHI that is being accessed, exchanged or used; (3) a
person who legally acts on behalf of a person described in (1) or (2),
including as a personal representative, in accordance with 45 CFR
164.502(g); or (4) a person who is a legal representative of and can
make health care decisions on behalf of any person described in (1) or
(2); or (5) an executor or administrator or other person having
authority to act on behalf of the deceased person described in (1) or
(2) or the individual's estate under State or other law.
We clarified that (2) varies from (1) because there could be
individuals who could be the subject of EHI that is being accessed,
exchanged, or used under (2), but who would not be the subject of PHI
under (1). For example, an actor which is not a covered entity or
business associate as defined under HIPAA such as a health IT developer
of certified health IT may access, exchange or use a patient's
electronic health information; however this ``health information''
would not meet the definition of PHI, but nonetheless, would be subject
to this regulation.
We also clarified that (3) encompasses a person with legal
authority to act on behalf of the individual, which includes a person
who is a personal representative as defined under the HIPAA Privacy
Rule. We explained that we included the component of legal authority to
act in (3) because the HIPAA Privacy Rule gives rights to parents or
legal guardians in certain circumstances where they are not the
``personal representative'' for their child(ren). For instance, a non-
custodial parent who has requested a minor child's medical records
under a court-ordered divorce decree may have legal authority to act on
behalf of the child even if he or she is not the child's ``personal
representative.'' Further, we noted that in limited circumstances and
if permitted under State law, a family member may have legal authority
to act on behalf of a patient to make health care decisions in
emergency situations even if that family member may not be the ``legal
representative'' or ``personal representative'' of the patient.
We noted that we adopted this specialized usage to ensure that the
Privacy Exception extends protection to information about, and respects
the privacy preferences of, all individuals, not only those individuals
whose EHI is protected as ePHI by HIPAA covered entities and business
associates (84 FR 7526 and 7527).
Interaction Between Information Blocking, the Exception for Promoting
the Privacy of EHI, and the HIPAA Privacy Rule
We stated in the Proposed Rule that we consulted extensively with
the HHS Office for Civil Rights (OCR), which enforces the HIPAA
Privacy, Security and Breach Notification Rules, in developing
proposals to advance our shared goals of preventing information
blocking for nefarious or self-interested purposes while maintaining
and upholding existing privacy rights and protections for individuals.
We noted that the proposed exception for promoting the privacy of EHI
(also referred to as the ``privacy exception'') operates in a manner
consistent with the framework of the HIPAA Privacy Rule. We explained
that we designed the sub-exceptions to ensure that individual privacy
rights are not diminished as a consequence of the information blocking
provision, and to ensure that the information blocking provision does
not require the use or disclosure of EHI in a way that would not be
permitted under the HIPAA Privacy Rule. We emphasized that our intent
was that the information blocking provision would not conflict with the
HIPAA Privacy Rule. We noted that the sub-exception proposed in Sec.
171.202(d) reflects a policy that an actor's denial of access to an
individual consistent with the limited conditions for such denials that
are described in the HIPAA Privacy Rule at 45 CFR 164.524(a)(1)(2) and
(3), is reasonable under the circumstances (84 FR 7527).
We also noted that the information blocking provision may operate
to require that actors provide access, exchange, or use of EHI in
situations that the HIPAA Rules would not require access of similar
information. This is because the HIPAA Privacy Rule permits, but does
not require, covered entities to disclose ePHI in most circumstances.
We explained that the information blocking provision, on the other
hand, requires that an actor provide access to, exchange, or use of EHI
unless they are prohibited from
[[Page 25846]]
doing so under an existing law or are covered by one of the exceptions.
As an illustration, we noted that the HIPAA Privacy Rule permits health
care providers to exchange ePHI for treatment purposes but does not
require them to do so. Under the information blocking provision, unless
an exception to information blocking applies, or the interference is
required by law, a primary care provider would be required to exchange
ePHI with a specialist who requests it to treat an individual who was a
common patient of the provider and the specialist, even if the primary
care provider offered patient care services in competition with the
specialist's practice, or would usually refer its patients to another
specialist due to an existing business relationship (84 FR 7527).
Promoting Patient Privacy Rights
We stated that the information blocking provision would not require
that actors provide access, exchange, or use of EHI in a manner that is
not permitted under the HIPAA Privacy Rule or other laws. As such, the
privacy-protective controls existing under the HIPAA Rules would not be
weakened by the information blocking provision. Moreover, we described
that we structured the Privacy Exception to ensure that actors can
engage in reasonable and necessary practices that advance the privacy
interests of individuals (84 FR 7527).
We explained that unless required by law, actors should not be
compelled to share EHI against patients' expectations under applicable
law or without adequate safeguards out of a concern that restricting
the access, exchange, or use of the EHI would constitute information
blocking. We acknowledged that this could seriously undermine patients'
trust and confidence in the privacy of their EHI and diminish the
willingness of patients, providers, and other entities to provide or
maintain health information electronically. In addition, we noted that
such outcomes would undermine and not advance the goals of the
information blocking provision and be inconsistent with the broader
policy goal of the Cures Act to facilitate trusted exchange of EHI. We
stated that trusted exchange requires not only that EHI be shared in
accordance with applicable law, but also that it be shared in a manner
that effectuates individuals' expressed privacy preferences. We noted
that an individual's expressed privacy preferences will not be
controlling in all cases. An actor will not be able to rely on an
individual's expressed privacy preference in circumstances where the
access, exchange, or use is required by law (84 FR 7527).
For these reasons, we proposed that the sub-exception in Sec.
171.202(e) would generally permit an actor to give effect to
individuals' expressed privacy preferences, including their desire not
to permit access, exchange, or use of their EHI. At the same time,
however, we emphasized that the Privacy Exception must be tailored to
ensure that protection of an individual's privacy is not used as a
pretext for information blocking. Accordingly, we proposed that this
exception would be subject to strict conditions (84 FR 7527).
Privacy Practices Required by Law
We stated in the Proposed Rule that because the information
blocking provision excludes from the definition of information blocking
practices that are required by law (section 3022(a)(1) of the PHSA),
privacy-protective practices that are required by law do not implicate
the information blocking provision and do not require coverage from an
exception. We noted that practices that are ``required by law'' can be
distinguished from other practices that an actor engages in pursuant to
a law, but which are not ``required by law.'' Such laws are typically
framed in a way that permit an access, exchange or use of health
information to be made only if specific preconditions are satisfied but
do not expressly require that the actor engage in a practice that
interferes with access, exchange, or use of EHI. For example, we noted
that the HIPAA Privacy Rule provides that a covered entity may use or
disclose PHI in certain circumstances where the individual concerned
has authorized the disclosure.\164\ The effect of this condition is
that the covered entity should not use or disclose the PHI in the
absence of an individual's authorization. However, we noted that
because the condition does not prohibit the actor from exchanging the
EHI in all circumstances, the actor would be at risk of engaging in a
practice that was information blocking unless an exception applied. For
this reason, we included a sub-exception, proposed in Sec. 171.202(b),
that provided that an actor will not be engaging in information
blocking if a State or Federal law imposes a precondition to the
provision of access, exchange, or use, and that precondition has not
been satisfied (84 FR 7527 and 7528).
---------------------------------------------------------------------------
\164\ 45 CFR 164.508 (Uses and disclosures for which an
authorization is required).
---------------------------------------------------------------------------
Comments. Commenters recommended that we allow for EHI to be
withheld if there are contractual privacy restrictions for the actor
that may define conditions or limits on what the actor may do because
of those contractual restrictions. In addition, some commenters
suggested that contractual restrictions should be treated similarly to
State and Federal privacy laws under the Privacy Exception.
Response. Please see section VIII.C.6.a (Prevention, Material
Discouragement, and Other Interference) above regarding interference
that discusses contracts including business associate agreements where
this is discussed in depth.
Definitions in This Exception
As noted above, we stated in the Proposed Rule that we consulted
extensively with the HHS Office for Civil Rights (OCR), which enforces
the HIPAA Privacy, Security and Breach Notification Rules, in
developing proposals to advance our shared goals of preventing
information blocking for nefarious or self-interested purposes while
maintaining and upholding existing privacy rights and protections for
individuals (84 FR 7527).
This Privacy Exception operates in a manner consistent with the
framework of the HIPAA Rules. We have finalized the sub-exceptions to
ensure that individual privacy rights are not diminished as a
consequence of the information blocking provision, and to ensure that
the information blocking provision does not require the use or
disclosure of EHI in a way that would not be permitted under the HIPAA
Privacy Rule. We emphasize that our intent is that the information
blocking provision would not conflict with the HIPAA Rules. As such, we
added in the definitions section of this exception the term ``HIPAA
Privacy Rule'' to mean 45 CFR parts 160 and 164 to improve readability
and support the policy goal of alignment with the HIPAA Privacy Rule.
With regards to the definition of ``individual,'' we have finalized
this definition as proposed with a minor clarification, and it is not
contrary to the HIPAA Rules. We note that the term ``individual'' is
defined by the HIPAA Rules at 45 CFR 160.103. Separately, under the
information blocking enforcement provision, we noted that the term
``individual'' is used to refer to actors that are health IT developers
of certified health IT, HINs, or HIEs (see section 3022(b)(2)(A) of the
PHSA). We finalized that for purposes of this exception (and only this
exception), we used neither of these definitions. Instead, the term
``individual'' encompassed any or all of the following: (1) An
individual defined by 45 CFR
[[Page 25847]]
160.103; (2) any other natural person who is the subject of EHI that is
being accessed, exchanged or used; (3) a person who legally acts on
behalf of a person described in (1) or (2), in making decisions related
to health care, as a personal representative, in accordance with 45 CFR
164.502(g); (4) a person who is a legal representative of and can make
health care decisions on behalf of any person described in paragraph
(a)(1) or (2); or (5) an executor or administrator or other person
having authority to act on behalf of a deceased person described in (1)
or (2) or the individual's estate under State or other law.
To clarify, we have finalized that Sec. 171.202(a)(2)(iii)
encompasses only a person who is a personal representative as defined
under the HIPAA Privacy Rule. We distinguish a ``personal
representative'' defined under the HIPAA Privacy Rule from all other
natural persons who are legal representatives and who can make health
care decisions on behalf of the individual, and thus those persons are
included in Sec. 171.202(a)(2)(iv). We misstated in the Proposed Rule
that the HIPAA Privacy Rule gave rights to parents or legal guardians
in certain circumstances where they are not the ``personal
representatives.'' We clarify in this final rule that, in limited
circumstances and if permitted under State law, a family member may be
the legal representative to act on behalf of a patient to make health
care decisions in emergency situations even if that family member may
not be the ``personal representative'' of the patient.
Comments. We received no comments opposing this condition of the
proposed definition of ``individual'' in the Privacy Exception.
Response. We finalized and clarified that Sec. 171.202(a)(2)(iii)
refers to only persons who meet the definition of a personal
representative under 45 CFR 164.502(g), and Sec. 171.202(a)(2)(iv)
refers to all other persons who are legal representatives of and can
make health care decisions on behalf of any person that was proposed in
Sec. 171.202(a)(4).
Sub-Exception 1: ``Precondition Not Satisfied''
We stated in the Proposed Rule that State and Federal privacy laws
that permit the disclosure of PHI often impose conditions that must be
satisfied prior to a disclosure being made. In the final rule we are
deleting the word ``privacy'' when it refers to laws in the regulation
text in Sec. 171.202(b) in order to alleviate any ambiguity about what
is meant as a ``privacy law.''
We proposed to establish a sub-exception to the information
blocking provision that recognizes that an actor will not be engaging
in information blocking if the actor does not provide access, exchange,
or use of EHI because a necessary precondition required by law has not
been satisfied. We explained that this exception would apply to all
instances where an actor's ability to provide access, exchange, or use
is ``controlled'' by a legal obligation required by law that a certain
condition (or multiple conditions) must be met before access, exchange,
or use of the EHI may be provided. We emphasized that to be covered by
this exception, the actor must comply with certain conditions, which
are discussed below.
We noted that the nature of the preconditions that an actor must
satisfy in order to provide access, exchange, or use of EHI will depend
on the laws that regulate the actor. For example, an actor that is
regulated by a restrictive State law may need to satisfy more
conditions than an actor regulated by a less restrictive State law
before providing access, exchange, or use of EHI (84 FR 7527 and 7528).
We requested comments generally on this proposed sub-exception.
More specifically, we sought comment on how this proposed sub-exception
would be exercised by actors in the context of State laws. We noted our
awareness that actors that operate across State lines or in multiple
jurisdictions sometimes adopt organization-wide privacy practices that
conform with the most restrictive laws regulating their business. We
stated that we were considering the inclusion of an accommodation in
this sub-exception that would recognize an actor's observance of a
legal precondition that the actor is required by law to satisfy in at
least one State in which it operates. We noted that, in the event that
we did adopt such an accommodation, we would also need to carefully
consider how to ensure that before the use of the most stringent
restriction is applied in all jurisdictions, the actor has provided all
privacy protections afforded by that law across its entire business.
This type of approach would ensure that an actor cannot take advantage
of a more-restrictive law for the benefit of this exception while not
also fulfilling the privacy-protective obligations of the law being
relied on. We requested comment on whether there is a need for ONC to
adopt such an accommodation for actors operating in multiple states and
encouraged commenters to identify any additional conditions that should
attach to the provision of such an accommodation. We also requested
comment on our proposed approach to addressing variation in State laws
throughout this proposed sub-exception (84 FR 7528).
We also recognized that some states have enacted laws that more
comprehensively identify the circumstance in which an individual or
actor can and cannot provide access, exchange, or use of EHI. We stated
that we were considering to what extent health care providers that are
not regulated by the HIPAA Privacy Rule, and would rely instead on
State laws for this sub-exception, would be able to benefit from this
sub-exception when engaging in practices that interfere with access,
exchange, or use of EHI for the purpose of promoting patient privacy.
We sought comment on any challenges that may be encountered by health
care providers that are not regulated as covered entities under the
HIPAA Privacy Rule when seeking to take advantage of this proposed sub-
exception. We also sought comment on whether there exists a class of
health care provider that is not regulated by any Federal or State law
that prescribes preconditions that must be satisfied in connection with
the disclosure of EHI, and whether any such class of health care
provider would benefit from a sub-exception similar to that proposed in
Sec. 171.202(c) for health IT developers of certified health IT (84 FR
7529).
Comments. Several commenters recommended that actors who operate
across multiple states with different preconditions for disclosure
under local laws should be able to adopt uniform requirements across
their organizations that satisfy the most stringent preconditions of
those local laws for purposes of this sub-exception. They stated that
this is appropriate because it is often difficult for organizations
operating across State lines to develop different workflows for each
State. However, other commenters requested that actors should be
permitted to select which portions of a State law should be included in
procedures implemented across all states rather than being required to
provide all privacy protections afforded by that law across its entire
business. Other commenters believed that it should be left to the
actor's discretion to determine whether it is better to have a uniform
approach across all the jurisdictions it operates in or whether a
State-by-State approach is more appropriate. They mentioned that such
flexibility also would align with the Department's overall goal of
reducing administrative burden particularly on providers while ensuring
a high degree of privacy protection for patients.
[[Page 25848]]
Response. We appreciate the various comments and recognize that it
is difficult for organizations operating across State lines to have
different workflows for each State while assuring privacy, particularly
the individual's right under the HIPAA Rules to obtain their PHI.
Additionally, it is important that any uniform policies and procedures
must in fact be implemented across an actor's entire organization and
not be applied selectively in ways which might be contrary to the
information blocking provision.
Balancing these goals, this final rule provides that, except for an
individual's access to their EHI as discussed below, actors may meet
this sub-exception if they operate across multiple states and elect to
adopt and implement uniform policies and procedures required by one
State that are more restrictive (i.e., provide greater privacy
protections) than would otherwise be required by another specific State
or Federal law. To be considered more restrictive in this context, a
law might require more or different preconditions to the access,
exchange, or use of EHI than Federal law or the law of another State in
which the actor operates. Alternatively, an actor could comply with the
preconditions of each State in which it operates on a State-by-State
basis with respect to the EHI requested. These alternatives provide
multi-state actors with significant flexibility without adversely
impacting an individual's right to obtain EHI as described below.
An actor that operates in multiple states could either comply with
the laws of each State in which it operates or comply with the most
restrictive State laws in which it operates and where applicable,
comply with Federal law requirements. The actor will need to document
either approach in its policies and procedures in which the actor has
adopted and implemented in order to meet the conditions of Sec.
171.202(b)(1)(i) because the uniform approach will not be available to
actors that operate on a case by case basis without policies and
procedures as contemplated by subsection Sec. 171.202(b)(1)(ii). Those
actors without uniform policies and procedures will need to comply with
each of the applicable State and Federal laws.
As noted above, the uniform policy and procedure approach to
individual access requests for EHI must assure alignment with the HIPAA
Privacy Rule and individual access implementation specifications to
help assure that the broader policy goals for individual access to EHI
are met. Specifically, when an actor receives a request by or on behalf
of an individual under 45 CFR 164.524 for the individual's EHI, the
actor must not impose preconditions in its policies and procedures
which would affect the individual's right to access under the HIPAA
Rules even when it is operating in multiple states.
We note that an actor may not inappropriately seek to use State or
Federal laws as a shield against disclosing EHI. For example, we would
expect that actors implement State-mandated preconditions consistently
and in a non-discriminatory manner when fulfilling requests to access,
exchange, or use EHI. Additionally, we caution actors who repeatedly
change their privacy policies depending on the EHI requestor or the
request that such actions may be considered intended to materially
interfere with, prevent, or discourage the access, exchange, or use of
EHI.
We note that we have modified the introductory text in Sec.
171.202(b) for clarity and precision. The final introductory text reads
as follows: ``To qualify for the exception on the basis that one or
more Federal or State preconditions for providing access, exchange, or
use of electronic health information have not been satisfied, the
following requirements must be met . . .'' The changes to the final
introductory text from the proposed introductory text (see 84 FR 7602)
are not substantive and do not change the meaning of the introductory
text.
We also note that we have added ``and actions'' in Sec.
171.202(b)(3)--``For purposes of determining whether the actor's
privacy policies and procedures and actions satisfy the requirements of
subsections (b)(1)(i) and (b)(2) above when the actor's operations are
subject to multiple laws which have inconsistent preconditions, they
shall be deemed to satisfy the requirements of the subsections if the
actor has adopted uniform privacy policies and procedures to address
the more restrictive preconditions.'' We added this language for
accuracy and clarity.
Comments. A commenter requested that we provide clarification on
all the Federal and State privacy laws considered when developing the
``applicable State and Federal privacy laws'' threshold condition of
this sub-exception. They requested that the final rule make clear that
those State privacy laws that are more restrictive than Federal privacy
laws (e.g., 42 CFR part 2 and HIPAA) take precedence over the less
stringent Federal privacy laws.
Response. As mentioned above, for clarity purposes, we have not
included the word ``privacy'' in the final regulation text in Sec.
171.202(b) in order to alleviate any ambiguity regarding what is meant
as a ``privacy law.'' The HIPAA Privacy Rule provides a Federal floor
of privacy protections for an individual's individually identifiable
health information where that information is held by a covered entity
or by a business associate of the covered entity. This sub-exception
does not alter an actor's ability to comply with applicable Federal or
State laws.
To illustrate this sub-exception, we provided the following
examples. We note that this list of examples is not exhaustive and that
preconditions required by law that control access, exchange, or use of
EHI that are not listed below would still qualify under this proposed
sub-exception so long as all conditions are met.
Although the HIPAA Privacy Rule does not have individual
``consent'' requirements for uses and disclosures of PHI for purposes
such as treatment, payment, and health care operations, certain Federal
and State laws do require that a person provide consent before their
EHI can be accessed, exchanged, or used for specific purposes. For
example, some State laws require an individual's consent for uses and
disclosures of EHI regarding some sensitive health conditions such as
HIV/AIDS, mental health, or genetic testing. Additionally, actors that
are under ``Part 2 programs,'' which means federally assisted programs
(``federally assisted'' as defined in 42 CFR 2.12(b) and ``program'' as
defined in 42 CFR 2.11), generally are required to obtain an
individual's consent to disclose or re-disclose patient-identifying
information related to the individual's substance use disorder, such as
treatment for addiction. The sub-exception would operate to clarify an
actor's compliance obligations in these situations. In such scenarios,
it would not be considered information blocking to refuse to provide
access, exchange, or use of EHI if the actor has not received the
individual's consent, subject to requirements discussed herein.
If an actor is required by law to obtain an individual's
HIPAA authorization before providing access, exchange, or use of the
individual's EHI, then the individual's refusal to provide an
authorization would justify the actor's refusal to provide access,
exchange, or use of EHI. The actor's refusal would, subject to
conditions discussed herein, be protected under this sub-exception.
The HIPAA Privacy Rule, and many State laws, permit the
disclosure of PHI in certain circumstances only once the identity and
authority of the person requesting the information has been verified.
We acknowledge that it is
[[Page 25849]]
reasonable and necessary that actors take appropriate steps, consistent
with Federal and State laws, to ensure that EHI is not disclosed to the
wrong person or to a person who is not authorized to receive it. Where
an actor cannot verify the identity or authority of a person requesting
access to EHI, and such verification is required by law before the
actor can provide access, exchange, or use of the EHI, the actor's
refusal to provide access, exchange, or use of the EHI will, subject to
the conditions discussed herein, will not be information blocking.
Under the HIPAA Privacy Rule, a health care provider may
share information with another health care provider for a quality
improvement project if it has verified that the requesting entity has a
relationship with the person whose information is being requested.
Where the actor could not establish if the relationship existed, it
would not be information blocking for the actor to refuse to provide
access, exchange, or use, subject to the conditions discussed herein.
Comments. We received comments on the Privacy Exception expressing
concern about whether a business associate (as defined under the HIPAA
Privacy Rule) would be liable for information blocking practices for
not providing access, exchange, or use of EHI because doing so would
violate its business associate agreement.
Response. Please see section VIII.C.6.a. (Prevention, Material
Discouragement and Other Interference) above regarding interference
that discusses contracts including business associate agreements where
this is discussed in depth.
Sub-Exception 1: ``Precondition Not Satisfied'': Conditions To Be Met
To Qualify for This Sub-Exception
We noted that in most circumstances, an actor would be in a
position to influence whether a precondition is satisfied. For example,
an actor could deprive a person of the opportunity to take some step
that is a prerequisite for the exchange of their EHI, could assume the
existence of a fact prejudicial to the granting of access without
seeking to discover the actual facts, or could make a determination
that a precondition was not satisfied without properly considering or
seeking all relevant information. As such, we proposed that this
exception would be subject to conditions that ensure that the
protection of an individual's privacy is not used as a pretext for
information blocking (84 FR 7529).
We proposed that an actor can qualify, in part, for this sub-
exception by implementing and conforming to organizational policies and
procedures that identify the criteria to be used by the actor and, as
applicable, the steps that the actor will take, in order to satisfy the
precondition.
We noted that most actors are covered entities or business
associates for the purposes of the HIPAA Privacy Rule, and are already
required to have policies, procedures, and training programs in place
that address how ePHI (as defined in 45 CFR 160.103) is used and
disclosed. As such, we expected that the overwhelming majority of
actors will already be in a position to meet this condition or would be
able to meet this condition with modest additional effort. However, we
acknowledged that some actors may not, for whatever reason, have
privacy policies and practices in place, or may have implemented
privacy policies and practices that do not sufficiently address the
criteria to be used, and steps to be taken, to satisfy a precondition
relied on by the actor. As such, we proposed to provide an alternative
basis on which to qualify, in part, for this sub-exception. We proposed
to permit actors to instead document, on a case-by-case basis, the
criteria used by the actor to determine when the precondition will be
satisfied, any criteria that were not met, and the reason why the
criteria were not met (84 FR 7529).
Separately, we proposed that if the precondition that an actor
purportedly needs to satisfy relies on the provision of a consent or
authorization from an individual, it is a requirement for the
condition(s) of this sub-exception that the actor (i) did all things
reasonably necessary within its control to provide the individual with
a meaningful opportunity to provide the consent or authorization and
(ii) did not improperly encourage or induce the individual to not
provide the consent or authorization (84 FR 7529).
Sub-Exception 1: ``Precondition Not Satisfied'': Practice Must Be
Implemented in a Consistent and Non-Discriminatory Manner
We proposed that in order for a practice to qualify for this sub-
exception, the practice must be implemented in a consistent and non-
discriminatory manner (proposed Sec. 171.202(b)(3)(ii)). This
condition would provide basic assurance that the purported privacy
practice is directly related to a specific privacy risk and is not
being used to interfere with access, exchange, or use of EHI for other
purposes to which this exception does not apply.
We proposed that this condition requires that the actor's privacy-
protective practices must be based on objective criteria that apply
uniformly for all substantially similar privacy risks. We explained
that an actor could not, for example, implement an organizational
privacy policy that imposed unreasonably onerous requirements on a
certain class of individuals or entities without a legitimate
justification for doing so. We explained that this condition provides
basic assurance that the purported privacy-protective practice is not
being used to interfere with access, exchange, or use of EHI for other
purposes to which this proposed exception does not apply (84 FR 7532).
We requested comment on this proposed condition.
Comments. Commenters agreed that having an organizational policy
which outlines patient preference categories and restrictions should be
created and utilized in a consistent and non-discriminatory manner for
all patient requests.
Response. We agree with the commenters, and for clarity, we moved
this proposed section to finalize in Sec. 171.202(b)(1), in order to
address when an actor has conformed to its organizational policies and
procedures and when an actor documents on a case-by-case basis when a
precondition has been satisfied. In both cases, the actor's practice
must be implemented in a consistent and non-discriminatory manner. We
provide the following example to illustrate the requirement that a
practice must be implemented in a consistent and non-discriminatory
manner.
For example, we noted an actor that offered a patient-facing
software application (app) would not be able to benefit from this
exception if it refused to exchange EHI with a competitor app because
the individual failed to meet onerous authorization requirements that
applied only to the exchange of EHI with the competitor app and did not
apply to others that presented no greater privacy or security risk.
In context of this condition of the Privacy Exception, and
consistent with its interpretation for information blocking exceptions
defined in part 171 subpart B in general, ``consistent and non-
discriminatory'' should be understood to mean that similarly situated
actors whose interactions pose the same level of privacy risk should be
treated consistently with one another under the actor's privacy
practices. Inconsistent treatment across similarly situated actors
whose interactions pose the same level of privacy risk based on
[[Page 25850]]
extraneous factors, such as whether they are a competitor of the actor
implementing the privacy practices, would not be considered
appropriate.
Sub-Exception 1: ``Precondition Not Satisfied'': Practice Must Be
Tailored to the Applicable Precondition
We proposed that for actors who seek to qualify for this sub-
exception, an actor's privacy-protective practice (proposed (Sec.
171.202(b)(3)(i)) must be tailored to the specific privacy risks that
the practice actually addresses. This condition necessarily presupposes
that an actor has carefully evaluated the privacy requirements imposed
on the actor, the privacy interests to be managed by the actor, and has
developed a considered response that is tailored to protecting and
promoting the privacy of EHI. For example, we noted that the HIPAA
Privacy Rule at 45 CFR 164.514(h) requires that, in certain
circumstances, the disclosure of PHI is only authorized once the
identity and authority of the person requesting the information has
been verified. The privacy issue to be addressed in this instance is
the risk that PHI will be disclosed to the wrong individual or an
unauthorized person. We proposed that if an actor chooses not to
provide access, exchange, or use of EHI on the basis that the actor's
identity verification requirements have not been satisfied, the actor's
practice must be tailored to the specific privacy risks at issue. We
noted that this would require that the actor ensure that it does not
impose identity verification requirements that are unreasonably onerous
under the circumstances (84 FR 7531).
For the purposes of this sub-exception, we proposed that engaging
in an interference on the basis that a precondition has not been
satisfied would be a practice that addresses a privacy risk or
interest, and so tailoring that interference to satisfy a precondition
could satisfy this requirement if all of the elements are met.
We requested comment on this proposed condition.
Comments. Commenters expressed a belief that a requirement that a
``practice must be tailored to the specific privacy risk or interest
being addressed'' could lead to unnecessary complexity, and that such a
policy could be overly prescriptive. In addition, commenters expressed
that we should provide more use cases to help providers and others
better understand how this element of the sub-exception could be met.
Response. We agree. We believe that a precondition should be
tailored to the applicable legal requirement and not be tied only to a
privacy risk or interest. To require that an actor's practice be
tailored to the specific privacy risk or interest without a legally
imposed requirement could lead to overly strict as well as an ambiguous
requirement. As such, we believe that it is an important policy
interest that an actor carefully evaluate the State or Federal law
requirements imposed upon an actor, and that the actor develop a
response that is tailored to the legal precondition which protect and
promote the privacy of EHI. We provide the following use case to
provide a greater understanding of how this element of the sub-
exception can be met.
To meet a legal precondition whereby an actor must
identify a patient before accessing, exchanging or using EHI, an
actor's policy that a driver's license was the only accepted
government-issued form of identification (as opposed to other types of
legally acceptable forms of identification such as a valid passport)
would not be a practice that is tailored to the applicable precondition
legal requirement because the provider's preference for one form of
government-issued identification over another does not meaningfully
address this legal precondition.
We have finalized that to qualify for this sub-exception on the
basis that State or Federal law requires one or more preconditions to
be met before providing access, exchange, or use of EHI the
precondition should be based upon the applicable legal requirements.
Sub-Exception 1: ``Precondition Not Satisfied'': Organizational
Policies and Procedures or Case-by-Case Basis
We proposed that if an actor seeks to qualify for this sub-
exception, in part, by implementing and conforming to organizational
policies and procedures, such policies and procedures must be in
writing, and specify the criteria to be used by the actor, and, if
applicable, the steps that the actor will take, in order to satisfy the
precondition relied on by the actor not to provide access, exchange, or
use of EHI. We emphasized that it would not be sufficient for an actor
to simply identify the existence of the precondition in their
organizational policies and procedures.
We proposed that an actor would only be eligible to benefit from
this sub-exception if it has implemented and followed its processes and
policies. This would include taking reasonable steps to ensure that its
workforce members and agents understand and consistently apply the
policies and procedures (84 FR 7529 and 7530).
We requested comment on the proposed condition generally, and
specifically, on whether an actor's organizational policies and
procedures provide a sufficiently robust and reliable basis for
evaluating the bona fides, reasonableness, and necessity of practices
engaged in to satisfy preconditions required by State or Federal
privacy laws (84 FR 7529 and 7530).
Comments. Some commenters recommended that actors should be able to
have written organization-specific policies that may be more
restrictive than State or Federal law and that health information
networks and exchanges should be given an exemption based on their
existing written governance policies. Other commenters recommended
adding language indicating that organizational policies must comply
with Federal, State, and local laws or that the final rule should
specify that organizations should implement policies which conform to
the specific State laws in which the information originates.
Response. As noted above, this final rule includes a limited
exception that permits an actor that operates in more than one State to
adopt uniform policies and procedures based on more restrictive
provisions of State and Federal law, subject to certain conditions. ONC
reiterates that an actor's organizational policies and procedures
should not be used as a pretext for information blocking. For example,
information blocking may exist if an actor's policies and procedures
impose onerous additional privacy requirements for access, exchange or
use of EHI beyond what is required by law, or where an actor repeatedly
changes its privacy policies and procedures to circumvent this
exception. Further, the actor's policies and procedures must be
tailored and must be implemented in a consistent and non-discriminatory
manner.
We do not agree that health information exchanges or networks
should be given a blanket exemption based on their existing written
governance policies because that could lead to a situation involving
information blocking if those policies imposed conditions that conflict
with the information blocking provision. Secondly, we expect that an
actor's organizational policies will conform with applicable laws,
including the information blocking provision, so it is not necessary to
further require actors to implement policies which conform to the
specific laws, including the law of
[[Page 25851]]
the State in which the information originated.
Documenting Criteria and Rationale
If an actor's practice does not conform to an actor's
organizational policies and procedures as required by Sec.
171.202(b)(1)(i), we proposed that an actor can seek to qualify for
this sub-exception, in part, by documenting how it reached its decision
that it would not provide access, use, or exchange of EHI on the basis
that a precondition had not been satisfied. We proposed that such
documentation must be created on a case-by-case basis proposed in Sec.
171.202(b)(1)(ii). We noted that an actor will not satisfy this
condition if, for instance, it sought to document a general practice
that it had applied to all instances where the precondition had not
been satisfied. Rather, we stated that the record created by the actor
must address the specific circumstances of the specific practice (or
interference) at issue.
We proposed that the record created by the actor must identify the
objective criteria used by the actor to determine when the precondition
is satisfied. Consistent with the condition to this sub-exception that
the practice must be tailored to the privacy interest at issue, those
criteria would need to be directly relevant to satisfying the
requirement. For example, we explained that if the requirement at issue
was the provision of a valid HIPAA authorization, the actor's
documented record should reflect, at minimum, that the authorization
would need to meet each of the requirements specified for a valid
authorization at 45 CFR 164.508(c). The record would then need to
document the criteria that had not been met, and the reason why it was
not met. We noted that the actor could record that the authorization
did not contain the name or other specific identification of the person
making the request because the authorization only disclosed the
person's first initial rather than a first name, and the actor had
records about multiple people with that same initial and last name.
We noted that this condition would provide the transparency
necessary to demonstrate whether the actor has satisfied the conditions
applicable to this exception. Moreover, we noted that it will help
ensure that a decision to not provide access, exchange, or use of EHI
is considered and deliberate, and therefore reasonable and necessary
(84 FR 7530).
We requested comment on this proposed condition.
Comments. Commenters requested that we should provide specificity
on what type of documentation would suffice to demonstrate that an
actor met this sub-exception. Commenters were concerned that these were
stringent documentation requirements and that provider practices may
inadvertently trigger a violation of information blocking. Other
commenters suggested that we should remove or consider reducing onerous
requirements for documentation for qualifying for the privacy sub-
exceptions, and other commenters requested specification on what form
the documentation must be and to specify whether existing documentation
required by the HIPAA Rules (e.g., patient informed consent and
authorization forms, Notice of Privacy Practices, Security Risk
Analysis, etc.) would satisfy the documentation requirements under this
Privacy Exception.
Response. The documentation requirements are for the actor to
comply with applicable State and Federal laws and to assure that after
the fact rationalizations are not used to justify practices that have
already occurred, consistent with the policy objectives of the
information blocking provision.
To finalize the documentation requirements we looked to OIG, which
has authority under section 3022(b) of the PHSA to investigate any
claim that an actor engaged in information blocking. OIG regulations in
other contexts include a writing requirement. For example, OIG has
promulgated the ``safe harbors'' provisions at 42 CFR 1001.952,
specifying various payment and business practices that would not be
subject to sanctions under the Anti-Kickback Statute. Several of these
safe harbors include a writing requirement to document in writing an
agreement, lease, or other transaction. These documentation
requirements do not often get into specific terms or requirements, but
rather tend to be more general in nature. However, the documentation
requirements do provide indicia of evidence that an entity has met the
requirements of the safe harbor provisions.
In addition, we considered the documentation requirements in the
HIPAA Rules. The HIPAA Privacy Rule at 45 C.F.R 164.530 (j) requires a
covered entity to maintain its policies and procedures in written or
electronic form for six years from the date of its creation or the date
when it last was in effect, whichever is later. In our review of the
OIG and HIPAA regulations, we believe that the documentation
requirement for this sub-exception is consistent with the safe harbor
and HIPAA Privacy Rule documentation requirements. Further, we do not
believe this documentation requirement would be onerous.
Therefore, we have finalized the following requirements for this
sub-exception. An actor must document its organizational policies and
procedures and specify the criteria used by the actor and as
applicable, the steps that the actor will take to satisfy the
precondition. Such steps may include providing the actor's workforce
members with training on those policies and procedures. Alternatively,
we have finalized a requirement an actor must document on a case-by-
case basis how it reached its decision that it would not provide
access, use, or exchange of EHI on the basis that a precondition had
not been satisfied, including the criteria it used to determine when
the precondition is satisfied. That is, an actor can provide
documentation that identifies the objective criteria that the actor
applied in order to determine whether the precondition had been
satisfied. Additionally, the actor must provide documentation that the
practice is tailored to those criteria that are directly relevant to
satisfying the precondition.
Sub-Exception 1: ``Precondition Not Satisfied'': Precondition Relies on
a Consent or Authorization
We proposed that if the precondition that an actor purports to rely
upon requires the provision of a consent or authorization from an
individual, it is a condition of this sub-exception that the actor must
have done all things reasonably necessary within its control to provide
the individual with a meaningful opportunity to provide that consent or
authorization. We noted that this requirement will be relevant when,
for example, a State privacy law or the HIPAA Privacy Rule requires an
individual to provide consent and/or a HIPAA authorization before
identifiable information can be accessed, exchanged, or used for
specific purposes.
We stated that we were considering addressing this condition in
further detail, whether by way of additional guidance or in regulation
text. To this end, we requested comments regarding what actions an
actor should take, within the actor's control, to provide an individual
with a meaningful opportunity to provide a required consent or HIPAA
authorization, and whether different expectations should arise in the
context of a consent versus a HIPAA authorization. Separately, we
proposed that to qualify for this sub-exception, to the extent that the
precondition at issue was the provision of a consent or HIPAA
authorization by an individual, the actor must not have
[[Page 25852]]
improperly encouraged or induced the individual to not provide the
consent or HIPAA authorization. We clarified that this does not mean
that the actor cannot inform an individual about the advantages and
disadvantages of exchanging EHI and any associated risks, so long as
the information communicated is accurate and legitimate. However, we
noted that an actor would not meet this condition in the event that it
misled an individual about the nature of the consent to be provided,
dissuaded individuals from providing consent in respect of disclosures
to the actor's competitors, or imposed onerous requirements to
effectuate consent that were unnecessary and not required by law.
We requested comment on whether the proposed condition requiring
the provision of a meaningful opportunity and prohibiting improper
encouragement or inducement should apply to preconditions beyond the
precondition that an individual provide consent or authorization. We
requested comment on whether the conditions specified for this sub-
exception, when taken in total, are sufficiently particularized and
sufficiently strict to ensure that actors that are in a position to
influence whether a precondition is satisfied will not be able to take
advantage of this sub-exception and seek protection for practices that
do not promote the privacy of EHI. We also requested comment on whether
we should adopt a more tailored approach to conditioning the
availability of this exception. For example, we noted that we were
considering whether different conditions should apply depending on: (i)
The nature of the EHI at issue; (ii) the circumstances in which the EHI
is being access, exchanged, or used; (iii) the interest being protected
by the precondition; or (iv) the nature of the precondition to be
satisfied. We encouraged commenters to identify scenarios in which the
application of the conditions applicable to this sub-exception, as
proposed, give rise to unnecessary burden, or would require activities
that do not advance the dual policy interests of preventing information
blocking and promoting privacy and security (84 FR 7530 and 7531).
Comments. Some commenters noted that the entire condition was too
vague and generally inconsistent with current standard industry
relationships and practices. Several commenters suggested that the
burden to obtain the consent should be on the organization requesting
the data rather than on the organization that holds the data. However,
commenters who suggested this often acknowledged that modifying our
proposal to fit their suggestion would require an actor to receive
assurances that consents are legitimate and in their possession before
sharing any data. These commenters often noted that it was not clear
how recipients of health care data subject to authorizations and
consent would be expected to provide individuals with a meaningful
opportunity to consent if they do not have an existing relationship
with that individual or means to contact that individual. A few
commenters recommended modifying this condition so that an actor that
does not have a direct relationship with patients is not required to
obtain patient consent or authorization.
Response. We agree with the commenters and have attempted to
address concerns about vagueness and consistency with industry
practices and relationships. This finalized sub-exception requires the
actor to have used reasonable efforts within its control if the actor
has already received a form of required consent or authorization that
does not meet all applicable requirements. Specifically, the actor must
have used reasonable efforts within its control to provide the
individual with a consent or authorization form that satisfies all
applicable requirements or have provided other reasonable assistance
with respect to the deficiencies. In effect, this places more of an
obligation on the party requesting the EHI and the individual to
attempt to satisfy the precondition by providing a consent or
authorization. This final rule does not require the actor that receives
the request to obtain a patient's consent or authorization to do all
things reasonably necessary within its control to provide the
individual with a meaningful opportunity to provide the consent or
authorization. Rather, the final rule requires that the actor is
obligated to take reasonable steps to provide a sufficient consent or
authorization form or other reasonable assistance.
Providing other reasonable assistance does not mean that the actor
needs to ``chase'' the individual to obtain a sufficient consent or
authorization. Such other reasonable assistance might include notifying
the individual of elements that are missing in the consent or
authorization initially provided, such as a witness or an expiration
date if legally required.
We believe that setting the standard for an actor's actions with
respect to an insufficient consent or authorization at reasonable
efforts is an appropriate standard to use because it aligns with the
case-by-case approach that is captured in the information blocking
provision that is the subject of this final rule.
We recognize that actors must accommodate variations in laws across
the states in which they operate. As discussed above, this final rule
provides flexibility to multi-state providers with respect to how they
may structure uniform policies and procedures regarding consents and
authorizations provided that they do in fact apply them. We also
recognize that some types of actors will not have the necessary legal
rights or the technical access to detailed patient information to
determine if a consent or authorization is required as a precondition.
We intend that each actor must do what is reasonable and what is
within its control. This applies to actors who are providers that have
a direct patient relationship and to actors that are supporting a
health care provider with respect to an insufficient consent or
authorization that must also use reasonable efforts to avoid possible
information blocking.
A health information network that receives an insufficient consent
or authorization might find that this sub-exception helpful if it does
not have lawful access to the individual's information to determine
what consent might be required under State or Federal confidentiality
laws that apply to information about mental health, substance abuse,
HIV status or other highly confidential diseases or conditions. We also
note that if a network is not able to review such information under
applicable law, providing a corrected consent would not be within its
control.
Comments. Many commenters were concerned that our definition of
``meaningful opportunity'' was too broad. These few commenters
suggested that, as proposed, our definition of ``meaningful
opportunity'' could place a significant burden on providers.
Specifically, these commenters suggested that adding a ``meaningful''
opportunity to consent to the patient, with its requisite new forms and
procedures, would add new burdens on actors without appearing to solve
any existing problems.
One commenter recommended that we modify this requirement to
include a reasonable opportunity for the provider to obtain the
individual's consent the next time the patient visits the office if the
patient is not present in the office to provide consent.
Response. We appreciate the comments that we have received on the
meaningful opportunity provision. After considering the comments, we
[[Page 25853]]
eliminated the ``meaningful opportunity'' provision in this final rule.
However, this sub-exception still requires the actor to use reasonable
efforts within its control and to provide reasonable assistance, which
might include explaining the required elements of a consent or
authorization, or providing a witness if required by law and requested
by the patient at an office visit with the actor.
However, the requirement of reasonable efforts is based on an
assumption that actors may not use the protection of an individual's
privacy as pretext for information blocking. If a requestor provides or
obtains some form of patient documented consent or authorization that
requires the actor's assistance to satisfy elements that are not
required by law and the actor does not provide such assistance, the
actor may be engaged in information blocking.
We recognize that meeting certain preconditions may be outside the
direct control of the provider. For example, the actor may have a pre-
existing consent form from the individual that needs to be modified due
to a change in applicable law. The actor may have a very difficult time
tracking down a former patient to provide the updated consent form. In
most cases, it would be reasonable to mail or email the updated form to
the patient's last address on the actor's records or present it to the
patient at visit scheduled in the near future. If the patient cancels
the visit, it may be reasonable for the actor to wait to obtain the
consent until the next time the patient visits the physical location of
the actor's office, so long as the actor explains the insufficiency and
provides a sufficient consent form at the next visit.
Comments. Commenters have mentioned that a health information
network (HIN) does not have operational control over or visibility into
the detailed decision-making of an individual's consent or
authorization of its participants, and they argue that an actor such as
a HIN should not be obligated to review or confirm the individuals'
consent or authorization, and that such confirmation is a requirement
of the health care provider because health care provider has a direct
relationship with the patient.
Response. We believe that actors such as a HIN do have the
obligation to comply with the conditions of this sub-exception. We have
taken the approach that each actor must use its ``reasonable efforts''
and focus on what reasonable steps they can take to provide their
reasonable efforts. We do not, however, believe that actors who have a
direct patient relationship would have a higher standard of reasonable
efforts than those actors such as HINs which do not have a direct
relationship with a patient and are acting on behalf of a health care
provider. However, even actors that do not have a direct relationship
with an individual, should use their reasonable efforts for the
activities under their control as it relates to supporting the
providing or obtaining of a consent or authorization.
Comments. Commenters expressed concerns that actors would be
required to create new policies beyond HIPAA aimed at offering patients
a ``meaningful'' opportunity to consent, and as a result, more
challenges than solutions would result from this policy. Commenters
noted unnecessary administrative burdens, confusion with HIPAA
requirements, and complexity for actors as some of the possible
challenges.
Response. As noted above, the ``meaningful opportunity''
requirement was not included in this final rule.
Comments. Many commenters expressed the opinion that actors meeting
certain preconditions may be outside the direct control of the actor
and recommended that examples should be provided about what actions are
sufficient to meet the ``reasonably necessary'' standard. Another
commenter argued that the reasonably necessary standard for the
meaningful opportunity requirement only stands to further aggravate the
burdensome nature of more stringent privacy laws. Other commenters were
concerned that the requirement that the actor ``did all things
reasonably necessary within its control to provide the individual with
a meaningful opportunity to provide the consent or authorization'' was
too rigid a requirement and that even if one possible action was not
done, the exception would not apply. Other commenters argued that this
standard was an extremely onerous requirement and contradicts the
stated intent of reducing the overall administrative burden on health
care practices.
Response. As noted above, the standard is now based on reasonable
efforts within the actor's control, and it applies only after the actor
receives a consent or authorization form that does not satisfy all
applicable conditions. We believe that this change addresses the
comments noted above. We note that we have slightly modified the
terminology used in Sec. 171.202(b)(2)(i). We proposed ``a form of
consent or authorization'' (84 FR 7602) and have change that language
in the final rule to ``a consent or authorization form'' for clarity.
This modification does not change the meaning of Sec.
171.202(b)(2)(i).
Comments. A commenter expressed concern to modify this exception to
make it clear that a hospital or health system may claim the exception
when an entity requesting patient data does not communicate that it has
obtained consent.
Response. As noted above, this condition of the sub-exception
applies only after an insufficient consent or authorization is
received. This condition of the sub-exception in the final rule does
not apply when the actor has not received anything regarding the
individual's consent or authorization. In such cases, the actor would
not be required to communicate to the entity requesting the EHI that
the actor has not obtained the individual's consent or authorization in
order to meet this sub-exception.
Comments. A commenter argued that actors should provide the
individual with a ``reasonably convenient opportunity'' to provide the
consent or authorization, rather than requiring ``all things reasonably
necessary within its control'' to provide consent or authorization. The
commenter noted that where entities make the request on behalf of the
individual, the actor making the request should facilitate the
gathering of the consent or authorization.
Response. As noted above, both the ``reasonable opportunity'' and
the ``all things reasonably necessary'' language are not included in
this final rule, but the actor must satisfy the reasonable efforts
standard when an insufficient consent or authorization has been
received. This might include providing a correct form or reasonable
assistance to the individual to solve any consent or authorization
documentation problems necessary to address the insufficiency.
Sub-Exception 1: Precondition Not Satisfied: Did Not Improperly
Encourage or Induce the Individual To Withhold the Consent or
Authorization
We proposed that to qualify for this sub-exception, to the extent
that the precondition at issue was the provision of a consent or
authorization by an individual, the actor must not have improperly
encouraged or induced the individual to not provide the consent or
authorization. As proposed, an actor would not meet this condition in
the event that it misled an individual about the nature of the consent
to be provided, dissuaded individuals from providing consent in respect
of disclosures to the actor's competitors, or imposed onerous
requirements to effectuate consent that
[[Page 25854]]
were unnecessary and not required by law.
We sought comment on whether the proposed condition requiring the
provision of prohibiting improper encouragement or inducement should
apply to preconditions beyond the precondition that an individual
provide consent or authorization. We sought comment on whether the
conditions specified for this sub-exception, when taken in total, are
sufficiently particularized and sufficiently strict to ensure that
actors that are in a position to influence whether a precondition is
satisfied will not be able to take advantage of this sub-exception and
seek protection for practices that do not promote the privacy of EHI.
We also sought comment on whether we should adopt a more tailored
approach to conditioning the availability of this sub-exception (84 FR
7531).
Comments. We received no comments opposing this condition
applicable to practices that implement the provision of a consent or
authorization from an individual to an actor.
Response. Within the sub-exception (Sec. 171.202(b)) applicable to
practices that implement a consent or authorization, we are finalizing
in Sec. 171.202(b)(2)(ii) as proposed.
Sub-Exception 2: Sub-Exception: Health IT Developer of Certified Health
IT Not Covered by HIPAA
The sub-exception we proposed in Sec. 171.202(b) recognized as
reasonable and necessary the activities engaged in by actors consistent
with the controls placed on access, exchange, or use of EHI by Federal
and State laws. We noted that the sub-exception was limited to actors
that are subject to those Federal and State laws; an actor that is not
regulated by HIPAA cannot benefit from the exception proposed in Sec.
171.202(b).
We proposed to establish a sub-exception to the information
blocking provision that would apply to actors that are health IT
developers of certified health IT but not regulated by the HIPAA
Privacy Rule in respect to the operation of the actor's health IT
product or service (referred to as ``non-covered actors'' for this sub-
exception). We noted that we expect that the class of actors to which
this proposed sub-exception applies will be very small. We explained
that the vast majority of health IT developers of certified health IT
operate as business associates to covered entities under HIPAA. As
business associates, they are regulated by the HIPAA Privacy Rule, and
may be able to benefit from the exception proposed in Sec. 171.202(b)
to the extent that the HIPAA Privacy Rule (or applicable State law)
imposes preconditions to the provision of access, exchange, or use of
EHI. However, we recognized that direct-to-consumer health IT products
and services are a growing sector of the health IT market. The privacy
practices of consumer-facing health IT products and services are
typically regulated by the Federal Trade Commission Act (FTC Act).
However, while the FTC Act prohibits unfair or deceptive acts or
practices in or affecting commerce (15 U.S.C. 45(a)(1)), it does not
prescribe specific privacy requirements.\165\
---------------------------------------------------------------------------
\165\ See HHS, Examining Oversight of the Privacy & Security of
Health Data Collected by Entities Not Regulated by HIPAA, https://www.healthit.gov/sites/default/files/non-covered_entities_report_june_17_2016.pdf.
---------------------------------------------------------------------------
We proposed that where a health IT developer of certified health IT
offers a health IT product or service not regulated by the HIPAA
Privacy Rule, such product or service is still subject to the
information blocking provision. We wanted to ensure that such non-
covered actors under the information blocking provisions are able to
avail themselves of the Privacy Exception. As such, we proposed that an
entity that is not covered by HIPAA will not engage in information
blocking if the actor declines to provide access, exchange, or use of
EHI where the practice implements a process that is described in the
actor's organizational privacy policy and has been disclosed to any
individual or entity that uses the actor's health IT. We proposed this
sub-exception in Sec. 171.202(c) which sets forth additional detail
(84 FR 7532).
In the final rule, we have finalized that when engaging in a
practice that promotes the privacy interests of an individual, the non-
covered actor must implement the practice according to a process
described in the organizational privacy policies, disclosed those
organizational privacy policies to the individuals and entities that
use the actor's product or service before they agreed to use them, and
the non-covered actor's organizational privacy policies must: (1)
Comply with applicable State or Federal laws; (2) be tailored to the
specific privacy risk or interest being addressed; and (3) be
implemented in a consistent and non-discriminatory manner. Public
comments on specific conditions are summarized below, in context of
each condition proposed. We believe our responses to these comments
furnish the clarity non-covered actors need to understand the
conditions of the sub-exception finalized in Sec. 171.202(c).
Practice Must Implement Privacy Policy
We proposed that in order to qualify for this sub-exception, the
practice engaged in by the non-covered actor--the interference with
access, exchange, or use of EHI--must also implement a process
described in the actor's organizational privacy policy. This requires
that a non-covered actor must have documented in detail in its
organizational privacy policy the processes and procedures that the
actor will use to determine when the actor will not provide access,
exchange, or use of EHI. For example, we explained that a non-covered
actor that proposed to require the provision of written consent for the
use or disclosure of EHI would need to describe in its organizational
privacy policy the processes and procedures to be utilized by the actor
to implement that privacy-protective practice so that the practice be
considered reasonable and necessary and qualify for this sub-exception.
We noted that compliance with this condition ensures that the sub-
exception recognizes only legitimate practices that have been tailored
to the privacy needs of the individuals that use the non-covered
actor's health IT, and does not recognize practices that are a pretext
or after-the-fact rationalization for actions that interfere with
access, exchange, or use of EHI.
We also proposed that the non-covered actor's practice must
implement its documented organizational privacy policy. We noted that
practices that diverge from an actor's documented policies, or which
are not addressed in an actor's organizational privacy policy, would
not qualify for this proposed sub-exception (84 FR 7532).
Policies Must Have Been Disclosed to Users
We proposed that a non-covered actor that seeks to benefit from the
sub-exception must also ensure that it has previously disclosed the
privacy-protective practice to the individuals and entities that use,
or will use, the health IT. These users are affected by the practices
engaged in by a non-covered actor but may otherwise have no visibility
of the non-covered actor's approach to protecting the privacy of EHI.
We noted that we expect that non-covered actors will seek to satisfy
this condition by using a privacy notice.\166\
[[Page 25855]]
We emphasized that the disclosure must be meaningful. In assessing
whether a non-covered actor's disclosure was meaningful, we explained
that regard will be paid to whether the disclosure was in plain
language and conspicuous, including whether the disclosure was located
in a place, and presented in a manner, that is accessible and obvious
to the individuals and entities that use, or will use, the health IT.
---------------------------------------------------------------------------
\166\ ONC has provided a Model Privacy Notice (MPN) that is a
voluntary, openly available resource designed to help developers
clearly convey information about their privacy and security policies
to their users. The MPN provides a snapshot of a company's existing
privacy practices encouraging transparency and helping consumers
make informed choices when selecting products. The MPN does not
mandate specific policies or substitute for more comprehensive or
detailed privacy policies. See https://www.healthit.gov/topic/privacy-security-and-hipaa/model-privacy-notice-mpn.
---------------------------------------------------------------------------
We proposed that to qualify for this sub-exception, a non-covered
actor would not be required to disclose its organizational privacy
policy to its customers or to the public generally. Rather, the non-
covered actor need only describe, with sufficient detail and precision
to be readily understood by users of the non-covered actor's health IT,
the privacy-protective practices that the non-covered actor has adopted
and will observe. We explained that this is necessary because a non-
covered actor that is not subject to prescribed privacy standards in
connection with the provision of health IT will have significant
flexibility in the privacy-protective practices that it adopts. If a
non-covered actor is not required to inform the individuals and
entities that use, or will use, the health IT, about the privacy-
protective practices that it will implement in its product, or when
providing its service, we noted that there is a risk that the sub-
exception will give deference to policies and processes that are post
hoc rationalizations used to justify improper practices. We stated that
this condition also serves as a check on the nature of the
interferences that a non-covered actor writes into its organizational
privacy policies; transparency will help to ensure that a non-covered
actor takes a balanced approach to protecting privacy interests on one
hand, and pursuing business interests that might be inconsistent with
the information blocking provision, on the other hand (84 FR 7533).
We proposed that it will be a matter for non-covered actors to
determine the most appropriate way to communicate its privacy practices
to users. We noted that it would be reasonable that non-covered actors
would, at a minimum, post their privacy notices, or otherwise describe
their privacy-protective practices, on their websites (84 FR 7533).
Practice Must Be Tailored to Privacy Risk and Implemented in a Non-
Discriminatory Manner
Finally, we proposed that in order for a practice to qualify for
this sub-exception, an actor's practice must be tailored to the
specific privacy risks that the practice actually addresses and must be
implemented in a consistent and non-discriminatory manner.
We requested comment on this proposed sub-exception generally.
Specifically, we requested comment on whether HIEs or HINs would
benefit from a similar sub-exception. We also requested comment on
whether the conditions applicable to this sub-exception are sufficient
to ensure that non-covered actors cannot take advantage of the
exception by engaging in practices that are inconsistent with the
promotion of individual privacy. We also requested comment on the level
of detail that non-covered actors should be required to use when
describing their privacy practices and processes to user of health IT
(84 FR 7533).
Comments. Some commenters believed that this sub-exception could be
helpful for those developing their own health IT tools, which are
outside of the electronic health record.
Response. We agree that this sub-exception would be helpful for
those developing their own health IT tools. The sub-exception address
those certified Health IT products not covered by HIPAA and would have
in place an organizational privacy policy which is tailored to a
specific privacy risk or interest.
Comments. Commenters noted that regarding the sub-exception
proposed for ``non-covered actors'' that develop patient-facing health
IT, they urged the need to balance the conditions of this sub-exception
with the requirements placed on actors who institute organizational
privacy policies.
Response. We appreciate the comment. In order to meet this sub-
exception, the organizational privacy policies of a non-covered actor
would need to comply with other applicable State and Federal laws.
Further, we have finalized that non-covered actors that seek to benefit
from this sub-exception must also ensure that their organizational
privacy policies are disclosed to the individuals and entities that use
their product or service before the individuals and entities agree to
use them. The organizational privacy policies are important for
transparency for users of the certified technologies and to demonstrate
compliance with applicable State and Federal laws. Non-covered actors
have the discretion to determine the most appropriate way to
communicate their privacy policies to individuals and users. As stated
above and in the Proposed Rule (84 FR 7533), it would be reasonable for
non-covered actors to, at a minimum, post their privacy notices, or
otherwise describe their privacy-protective practices, on their
websites.
Comments. A few commenters stated that it is unclear whether
application developers are subject to HIPAA if they are not business
associates or covered entities.
Response. We appreciate the feedback. Where application developers
are not defined as a covered entity or business associate as defined
under 45 CFR 160.103, then the application developer is not covered
under the HIPAA Privacy Rule or HIPAA Security Rule.
Comments. Some commenters expressed concern that data will be made
available to third-party application suppliers, commercial analytics
companies, and/or entities that are not governed by HIPAA and that such
availability of data would not serve patients' best interests and could
result in potential misuse of patient data.
Response. We appreciate the feedback and agree that an actor who is
a health IT developer of certified health IT that is not required to
comply with the HIPAA Privacy Rule must comply with all applicable
State and Federal laws, including the FTC Act. Further, such actors
must have an organizational privacy policy that is tailored to the
privacy risk or interest being addressed in order to meet this sub-
exception. We emphasize that where a health IT developer of certified
health IT offers a health IT product or service not regulated by the
HIPAA Privacy Rule, such product or service is subject to the
information blocking provision. Our goal is to ensure that non-covered
actors that engage in reasonable and necessary privacy-protective
practices that interfere with the access, exchange, or use of EHI could
seek coverage under the sub-exception.
Comments. Some commenters stated that actors that are not covered
by HIPAA should make their privacy policies publicly available. Other
commenters did not believe that the Proposed Rule fully addressed
patient and consumer privacy protections.
Response. We appreciate the comments. We believe that it is
important that users know what to expect when electing to use a non-
covered actor's product or service.
[[Page 25856]]
Sub-Exception 3: Denial of an Individual's Request for Their Electronic
Protected Health Information in the Circumstances Provided in 45 CFR
164.524(a)(1) and (2)
We proposed a limited sub-exception to the information blocking
provision that would permit a covered entity or business associate to
deny an individual's request for access to their PHI in the
circumstances provided under 45 CFR 164.524(a)(1) (2) and (3). We noted
that this exception would avoid a potential conflict between the HIPAA
Privacy Rule and the information blocking provision. Specifically, the
HIPAA Privacy Rule contemplates circumstances under which covered
entities, and in some instances business associates, may deny an
individual access to PHI and distinguishes those grounds for denial
which are reviewable from those which are not. We proposed that this
exception applies to both the ``unreviewable grounds'' and ``reviewable
grounds'' of access. We noted that the ``unreviewable grounds'' for
denial for individuals include situations involving: (1) Certain
requests that are made by inmates of correctional institutions; (2)
information created or obtained during research that includes
treatment, if certain conditions are met; (3) denials permitted by the
Privacy Act; and (4) information obtained from non-health care
providers pursuant to promises of confidentiality. In addition, we
noted that two categories of information are expressly excluded from
the HIPAA Privacy Rule individual right of access: (1) Psychotherapy
notes, which are the notes recorded by a health care provider who is a
mental health professional documenting or analyzing the contents of a
conversation during a private counseling session and that are
maintained separate from the rest of the patient's medical record; and
(2) information compiled in reasonable anticipation of, or for use in,
a civil, criminal, or administrative action or proceeding.\167\
---------------------------------------------------------------------------
\167\ See 45 CFR 164.501; 45 CFR 164.524 (a)(1)(i) and (ii).
---------------------------------------------------------------------------
We noted the ``reviewable grounds'' of access as described in Sec.
164.524(a)(3), which provides that a covered entity may deny access
provided that the individual is given a right to have such denials
reviewed under certain circumstances. We explained that one such
circumstance is when a licensed health care professional, in the
exercise of professional judgment, determines that the access requested
is reasonably likely to endanger the life or physical safety of the
individual or another person. In addition, we noted that if access is
denied, then the individual has the right to have the denial reviewed
by a licensed health professional who is to act as a reviewing official
and did not participate in the original decision to deny access (see
generally 45 CFR 164.524(a)(3)) (84 FR 7533 and 7534).
As mentioned above with regards to the harm exception (Sec.
171.201) our purpose is to avoid unnecessary complexity. By including
the ``reviewable grounds'' of 45 CFR 164.524(a)(3) in the harm
exception at Sec. 171.201, we align these regulations in a way that
streamlines compliance for actors subject to the HIPAA Privacy Rule and
this regulation. We removed the 45 CFR 164.524(a)(3) reference in the
privacy sub-exception in Sec. 171.202(d) and moved it to the harm
exception in Sec. 171.201 in order to promote clarity and alignment
with the inter-relationship between this final rule and the HIPAA
Privacy Rule.
In restricting this privacy sub-exception to only ``unreviewable
grounds'' in 45 CFR 164.524(a)(1) and (2), we clarify the regulation
text so that it is immediately clear that actors who are covered
entities, and in some instances business associates, may deny an
individual access to EHI of the individual and such denials would not
provide an opportunity for review of the denial under certain
circumstances. We clarify in the final rule that if an individual
requests EHI under the right of access provision under 45 CFR
164.524(a)(1) from an actor that must comply with 45 CFR 164.524(a)(1),
the actor's practice must be consistent with 45 CFR 164.524(a)(2).
These ``unreviewable grounds'' are related to specific privacy risks or
interests and have been established for important public policy
purposes, such as when a health care provider is providing treatment in
the course of medical research or when a health care provider is acting
under the direction of a correctional institution.
Unlike the ``unreviewable grounds,'' the ``reviewable grounds''
that are finalized Sec. 171.201 are directly related to the likelihood
of harm to a patient or another person and requires that actors seeking
to avail themselves of this exception must have a reasonable belief
that the practice will substantially reduce a risk of harm that would
otherwise arise from the specific access, use, or exchange of EHI
affected by the practice, and the harm must be one that would be
cognizable under 45 CFR 164.524(a)(3) as a basis for denying an
individual's right of access to their PHI in analogous circumstances.
In other words, the ``reviewable grounds'' of access as described in 45
CFR 164.524(a)(3), provides that a covered entity may deny access
provided that the individual is given a right to have such denials
reviewed when a licensed health care professional, in the exercise of
professional judgment, determines that the access requested is
reasonably likely to endanger the life or physical safety of the
individual or another person. In addition, we noted that if access is
denied, then the individual has the right to have the denial reviewed
by a licensed health professional who is to act as a reviewing official
and did not participate in the original decision to deny access and the
risk to be reduced must be one that would otherwise arise from the
specific access, use, or exchange of EHI affected by the practice.
We proposed that if an actor who is a covered entity or its
business associate denies an individual's request for access to their
PHI on the basis of these unreviewable grounds, and provided that the
denial of access complies with the requirements of the HIPAA Privacy
Rule in each case, then the actor would qualify for this exception and
these practices would not constitute information blocking (84 FR 7534).
We requested comment on this proposed sub-exception.
Comments. Commenters were concerned that HINs that are business
associates may not be authorized to provide individual access on the
behalf of covered entity. Further, commenters sought clarification that
this sub-exception would also apply in circumstances where as a
business associate, the HIN would deny the individual's request for
access because of its obligations as a business associate.
Response. We share this concern. To meet this privacy sub-
exception, if an individual requests their ePHI under 45 CFR
164.524(a)(1), the actor may deny the request in the circumstances
provided in 45 CFR 164.524(a)(1) or (2). That is, an actor that is a
covered entity may deny an individual's request for access to all or a
portion of the PHI and must meet its requirements under the HIPAA
Privacy Rule. As we discussed earlier, an individual's right under the
HIPAA Privacy Rule to access PHI about themselves includes PHI in a
designated record set maintained by a business associate on behalf of a
covered entity. However, if the same PHI that is the subject of an
access request is maintained in both the designated record set of the
covered entity and the designated record set of the business associate,
the PHI need only be
[[Page 25857]]
produced once in response to the request for access.\168\
---------------------------------------------------------------------------
\168\ 45 CFR 164.524(c)(1).
---------------------------------------------------------------------------
Comments. Commenters requested clarification that covered entities
and business associates could meet this sub-exception when conducting
clinical research with a blinded or masked designed. The EHI is
typically `tagged' as part of a blinded or masked research during a
research study.
Response. To meet this privacy sub-exception, if an individual
requests their ePHI under 45 CFR 164.524(a)(1), the actor may deny the
request in the circumstances provided in 45 CFR 164.524(a)(1) or (2).
Under certain limited circumstances under the Privacy Rule, a covered
entity may deny an individual's request for access to all or a portion
of the PHI requested. In some of these circumstances, an individual
does not a right to have the denial reviewed by a licensed health care
professional. It is known as ``unreviewable grounds'' for denial.\169\
One of the ``unreviewable grounds'' involves individual access to ePHI
in a research study. An actor may deny access to an individual provided
that the requested PHI is in a designated record set that is part of a
research study that includes treatment (e.g., clinical trial) and is
still in progress, provided the individual agreed to the temporary
suspension of access when consenting to participate in the research.
The individual's right of access can be reinstated upon completion of
the research study.
---------------------------------------------------------------------------
\169\ 45 CFR 164.524(a)(2).
---------------------------------------------------------------------------
Sub-Exception 4: Sub-Exception: Respecting an Individual's Request Not
To Share Information
We proposed to establish an exception to the information blocking
provision that would, in certain circumstances, permit an actor not to
provide access, exchange, or use of EHI if an individual has
specifically requested that the actor not do so. This sub-exception was
proposed in Sec. 171.202(e). We noted that this sub-exception is
necessary to ensure that actors are confident that they can respect
individuals' privacy choices without engaging in information blocking,
and to promote public confidence in the health IT infrastructure by
effectuating patients' preference about how and under what
circumstances their EHI will be accessed, exchanged, and used. We
recognized in the Proposed Rule that individuals may have concerns
about permitting their EHI to be accessed, exchanged, or used
electronically under certain circumstances. As a matter of public
policy, we explained that these privacy concerns, if expressed by an
individual and agreed to by an actor, would be reasonable and
necessary, and an actor's conduct in abiding by its agreement would, if
all conditions are met, be an exception to the information blocking
provision (84 FR 7534).
We proposed that this proposed sub-exception would not apply under
circumstances where an actor interferes with a use or disclosure of EHI
that is required by law, including when EHI is required by the
Secretary to enforce HIPAA under 45 CFR 164.502(a)(2)(ii) and 45 CFR
164.502(a)(4)(i). Stated differently, this sub-exception would not
operate to permit an actor to refuse to provide access, exchange, or
use of EHI when that access, exchange, or use is required by law. We
noted that this sub-exception recognizes and supports the public policy
objective of the HIPAA Privacy Rule, which identifies uses and
disclosures of EHI for which the public interest in the disclosure of
the individual's information outweighs the individual's interests in
controlling the information.
We proposed that this sub-exception would permit an actor not to
share EHI if the following conditions are met: (1) The individual made
the request to the actor not to have their EHI accessed, exchanged, or
used; (2) the individual's request was initiated by the individual
without any improper encouragement or inducement by the actor; and (3)
the actor or its agent documents the request within a reasonable time
period.
We described that to qualify for this sub-exception, the request
that the individual's EHI not be accessed, exchanged, or used must come
from the individual. Moreover, the individual must have made the
request independently and without any improper encouragement or
inducement by the actor.
We proposed that if an individual submits a request to an actor not
to disclose her EHI, and the actor agrees with and documents the
request, the request would be valid for purposes of this sub-exception
unless and until it is subsequently revoked by the individual. We
proposed that once the individual makes the request, she should not,
subject to the requirements of applicable Federal or State laws and
regulations, have to continually reiterate her privacy preferences,
such as having to re-submit a request every year. Likewise, we proposed
that once the actor has documented an individual's request, the actor
should not have to repeatedly reconfirm and re-document the request. We
requested comment, however, regarding whether this approach is too
permissive and could result in unintended consequences. We also sought
comment on this proposed sub-exception generally, including on
effective ways for an individual to revoke their privacy request for
purposes of this sub-exception.
We also proposed that in order for a practice to qualify for this
sub-exception, an actor's practice must be implemented in a consistent
and non-discriminatory manner. This condition would provide basic
assurance that the purported privacy practice is directly related to
the risk of disclosing EHI contrary to the wishes of an individual, and
is not being used to interfere with access, exchange, or use of EHI for
other purposes to which this exception does not apply. We noted that
this condition requires that the actor's privacy-protective practice
must be based on objective criteria that apply uniformly for all
substantially similar privacy risks (84 FR 7534 and 7535).
We noted that under the HIPAA Privacy Rule, individuals have the
right to request restrictions on how a covered entity will use (as that
term is defined in 45 CFR 160.103) and disclose PHI about them for
treatment, payment, and health care operations pursuant to 45 CFR
164.522(a)(1). Under 45 CFR 164.522(a), a covered entity is not
required to agree to an individual's request for a restriction (other
than in the case of a disclosure to a health plan under 45 CFR
164.522(a)(1)(vi)), but is bound by any restrictions to which it agrees
(84 FR 7534).
We proposed that if an individual submitted a request to an actor
not to disclose her EHI, and the actor agreed with and documents the
request, the request would be valid for the purposes of this sub-
exception unless and until it was subsequently revoked by the
individual. We believed that this approach would minimize compliance
burdens for actors while also respecting individuals' requests. We
sought comment on this proposed sub-exception generally, including on
effective ways for individuals to revoke their privacy request for
purposes of this sub-exception (84 FR 7534). In the final rule, we
align with the HIPAA Privacy Rule, specifically, 45 CFR 164.522(a)(2)
which includes specific requirements with respect to the termination of
an individual's restriction. Similar to the HIPAA Privacy Rule, we
include Sec. 171.202(e)(4) to address situations where the individual
terminates its individual's restriction.
An actor may terminate a restriction with the individual's written
or oral agreement. If the individual's agreement
[[Page 25858]]
is obtained orally, the actor must document that agreement. A note in
the certified EHR or similar notation is sufficient documentation. If
the individual agrees to terminate the restriction, the actor may use
and disclose EHI as otherwise permitted under this final rule. An actor
may only access, exchange or use EHI after it informs the individual of
the termination. The restriction continues to apply to EHI accessed,
exchanged or used prior to informing the individual of the termination.
That is, any EHI that had been collected before the termination may not
be accessed, exchanged or used in a way that is inconsistent with the
restriction, but any information that is collected after informing the
individual of the termination of the restriction may be used or
disclosed as otherwise permitted under the final rule. In Sec.
171.201(e)(4), we clarify that an actor must document a restriction to
which it has agreed. We do not require a specific form of
documentation; a note in the certified EHR or similar notation is
sufficient.
A restriction is only binding on the actor that agreed to the
restriction. We encourage actors to inform others of the existence of a
restriction when it is appropriate to do so. If a restriction does not
permit an actor to disclose EHI to a particular person, the actor must
carefully consider whether disclosing the existence of the restriction
to that person would also violate the restriction.
We clarified that for the purposes of this proposed sub-exception,
the actor may give effect to an individual's request not to have an
actor disclose EHI even if State or Federal laws would allow the actor
not to follow the individual's request. We explained that this is
consistent with our position that, absent improper encouragement or
inducement, and subject to appropriate conditions, it should not be
considered information blocking to give effect to patients' individual
preferences about how their EHI will be shared or how their EHI will
not be shared.
We requested comments on this sub-exception generally.
Specifically, we sought comment on what would be considered a
reasonable time frame for documentation. In addition, we also sought
comment on how this sub-exception would affect public health
disclosures and health care research, if an actor did not share a
patient's EHI due to a privacy preference, including any effects on
preventing or controlling diseases, injury, or disability, and the
reporting of disease, injury, and vital events such as births or
deaths, and the conduct of public health surveillance and health care
research (84 FR 7534 and 7535).
Comments. Commenters recommended that we provide guidance regarding
what could be considered a ``reasonable time period'' under Sec.
171.202(e)(3) and to provide clarity to health information
professionals that will be tasked with documenting the individual's
privacy preferences in accordance with this regulation.
Response. In order to align with HIPAA, we looked to the HIPAA
Privacy Rule at 45 CFR 164.522 for guidance on this issue. The HIPAA
Privacy Rule requires a covered entity to document a restriction of
PHI, but gives covered entities the discretion to determine the exact
timing of the documentation. The documentation requirement is
consistent with the HIPAA Privacy Rule, which is already being observed
by covered entities and business associates.
Under the HIPAA Privacy Rule, a covered entity may voluntarily
choose, but is not required, to obtain the individual's consent for it
to use and disclose information about him or her for treatment,
payment, and health care operations.\170\ A ``consent'' document is not
a valid permission to use or disclose PHI for a purpose that requires
an ``authorization'' under the HIPAA Privacy Rule (see 45 CFR 164.508),
or where other requirements or conditions exist under the HIPAA Privacy
Rule for the use or disclosure of PHI.
---------------------------------------------------------------------------
\170\ See 45 CFR 164.506(b).
---------------------------------------------------------------------------
Similarly, we believe that actors should be given the discretion to
document an individual's request and such documentation should be
within a reasonable period of time after making such a request.
Although we do not require the request form to be dated at the time it
is signed, we would recommend that it be dated so that actors and
others can document that the request was obtained prior to an actor's
agreement for the restriction of the individual's access, exchange or
use of EHI. What would be deemed as an unreasonable period of time
would be the unreasonable delay in performance and in documentation by
the actor as well as whether there were any objective manifestations of
expectation expressed between the individual and the actor.
Comments. A commenter recommended that a reasonable time frame
should balance and not burden an individual or organization such as
reviewing preferences with the individual each year and that the risk/
benefit profile in the fast-changing health-IT market may well have
changed and that the individual has a right to have those changes
disclosed to make an informed decision. Another commenter expressed a
belief that not asking the individual to reconfirm their preference is
too permissive.
Response. We agree that once the individual makes the request to an
actor, she should not, subject to the requirements of applicable
Federal or State laws and regulations, have to continually reiterate
her privacy preferences, such as having to re-submit a request every
year. Likewise, we finalized that once the actor has documented an
individual's request within a reasonable period of time, then the actor
is not required to repeatedly reconfirm and re-document the request.
Comments. A commenter recommended that the request needs to be in
writing, and suggested that we provide guidance regarding how the
individual's request could be documented. Another commenter requested
that we develop a template consent form whereby patients could indicate
if they would like to have their health information disclosed to third
parties and to ensure that the content of this form would be absent of
any ``improper encouragement or inducement'' and that we should work in
consultation with OCR to develop the recommended language for a model
consent form.
Response. We agree that an individual's request and an individual's
request for revocation should be in writing assuming such a request is
not required or prohibited by law. Alternatively, an actor could
document a conversation with an individual. Such documentation could be
documented in a certified EHR in some manner, and if the individual was
provided a specific request form, the form could be included in a
certified EHR. We believe that an individual should have sufficient
opportunity to consider whether to provide a request and that an actor
should minimize the possibility of coercion or undue influence and
refrain from any improper encouragement or inducement. Any form
provided by the actor should have information provided in plain
language that is understandable to the individual.
For example, we noted that it would be improper to discourage
individuals from sharing information with unaffiliated providers on the
basis of generalized or speculative risks of unauthorized disclosure.
On the other hand, we noted that if the actor was aware of a specific
privacy or security risk, it would be proper to inform individuals of
that risk. Likewise, an
[[Page 25859]]
actor would be permitted to provide an individual with general
information about her privacy rights and options, including for
example, the option to not provide consent, provided the information is
presented accurately, does not omit important information, and is not
presented in a way that is likely to improperly influence the
individual's decision about how to exercise their rights.
It is important to note that the sub-exception conditions in the
regulation are not intended to preempt any applicable Federal, State,
or local laws that may require additional information to be disclosed
for an agreement to be legally effective. We will continue to work in
consultation with OCR to develop resources as necessary to support
actors' compliance with the conditions of this Privacy Exception.
Comments. Commenters requested greater clarity on how this
regulation would affect public health disclosures and health care
research, if an actor did not share a patient's EHI due to a privacy
preference, including any effects on preventing or controlling
diseases, injury, or disability, and the reporting of disease, injury,
and vital events such as births or deaths, and the conduct of public
health surveillance and health care research.
Response. With regard to public health disclosures, to the extent
that such disclosures are required by law, the actor would not be in a
position to grant the patient's request for restriction. With regard to
EHI used for research, the unavailability of the individual's
information resulting from a restriction would be consistent with the
patient's right to withhold authorization for research uses and
disclosures. However, an Institutional Review Board may approve a
consent procedure that alters some or all of the elements of informed
consent, or waive the requirement to obtain informed consent under HHS
regulations at 45 CFR 46.116(c), and to the extent that the researcher
has obtained a waiver of informed consent, research could be
compromised by the unavailability of certain EHI. One possible way to
resolve this issue would be the establishment of a field that actors
covered could check in a certified EHR that would indicate that
restrictions have been applied to the individual's EHI (without
providing detail of the nature of such restriction). In this case,
actors could exclude the individual's EHI from research.
Comments. A commenter suggested that EHI should be accessed,
exchanged or used despite a patient's privacy agreement with an actor
in emergency treatment situations particularly when an individual is
unavailable to provide a revocation. The commenter was concerned that
if the EHI was not disclosed to health care provider in an emergency,
the individual could be subject to imminent harm or death.
Response. In the Proposed Rule (proposed Sec. 171.202(e)), we did
not provide how an individual could revoke her privacy agreement with
the actor. In response, we included in the final rule in Sec.
171.202(e)(4) to specifically address the termination of an
individual's request. In order to address these specific circumstances
and align with the HIPAA Privacy Rule, we agree that an individual's
restriction may need to be compromised in emergency treatment
situations, and we have finalized that an actor may terminate an
individual's request for a restriction to not provide access, exchange
or use of EHI under limited circumstances.
c. Security Exception--When will an actor's practice that is likely
to interfere with the access, exchange, or use of electronic health
information in order to protect the security of electronic health
information not be considered information blocking?
We proposed in the Proposed Rule (84 FR 7535 through 7538) to
establish an exception to the information blocking provision that would
permit actors to engage in practices that are reasonable and necessary
to promote the security of EHI, subject to certain conditions. We
explained that, without this exception, actors may be reluctant to
implement security measures or engage in other activities that are
reasonable and necessary for safeguarding the confidentiality,
integrity, and availability of EHI. This could undermine the ultimate
goals of the information blocking provision by discouraging best
practice security protocols and diminishing the reliability of the
health IT ecosystem.
We noted (84 FR 7535) that robust security protections are critical
to promoting patients' and other stakeholders' trust and confidence
that EHI will be collected, used, and shared in a manner that protects
individuals' privacy and complies with applicable legal requirements.
We also noted that public confidence in the security of their EHI has
been challenged by the growing incidence of cyber-attacks in the health
care sector. More than ever, we explained, health care providers,
health IT developers, HIEs and HINs must be vigilant to mitigate
security risks and implement appropriate safeguards to secure the EHI
they collect, maintain, access, use, and exchange.
We emphasized (84 FR 7535) that, while the importance of security
practices cannot be overstated, the proposed exception would not apply
to all practices that purport to secure EHI. Rather, we stated that the
exception would only be available when the actor's security-based
practice satisfies the conditions applicable to this exception.\171\ We
noted that it would not be appropriate to prescribe a ``maximum'' level
of security or to dictate a one-size-fits-all approach for all actors
as that may not be appropriate in all circumstances and may not
accommodate new threats, countermeasures, and best practices in a
rapidly changing security landscape. We further noted that we did not
intend for the proposed exception to dictate a specific security
approach. Moreover, we emphasized that effective security best
practices focus on the mitigation and remediation of risks to a
reasonable and acceptable level.
---------------------------------------------------------------------------
\171\ In the Proposed Rule (84 FR 7535), we used the phrase
``conditions applicable to this exception'' to mean the conditions
(inclusive of requirements within specific conditions) of the
exception applicable to a particular practice in a particular
circumstance. Where we are not summarizing what we stated in the
proposed rule, in this preamble we have generally used plainer-
language phrasings, such as ``the conditions of the exception that
are applicable to a practice [in the particular circumstances].''
---------------------------------------------------------------------------
With consideration of the above (84 FR 7535), we proposed that
actors would be able to satisfy the exception through practices that
implement either security policies and practices developed by the
actor, or case-by-case determinations made by the actor. We proposed
that whether a security-motivated practice meets this exception would
be determined on a case-by-case basis using a fact-based analysis of
the conditions set forth in the Proposed Rule.
We emphasized (84 FR 7535) that the practices implemented by a
single physician office with limited technology resources, for example,
will be different to those implemented by a large health system, and
that this difference does not affect an actor's ability to qualify for
this exception. The fact-based approach that we proposed would allow
each actor to implement policies, procedures, and technologies that are
appropriate for its particular size, organizational structure, and
risks to individuals' EHI. We noted that a fact-based analysis also
aligns with the HIPAA Security Rule \172\ concerning the security of
ePHI. The HIPAA Security Rule requires HIPAA covered entities or
business associates to develop security practices and implement
administrative, physical, and
[[Page 25860]]
technical safeguards that take into account: The entity's size,
complexity, and capabilities; technical, hardware, and software
infrastructure; the costs of security measures; and the likelihood and
possible impact of potential risks to ePHI.\173\ We noted (84 FR 7535
and 7536), however, that while our proposed approach would be
consistent with the regulation of security practices under the HIPAA
Security Rule, the fact that a practice complies with the HIPAA
Security Rule would not establish that it meets the conditions of the
exception to the information blocking provision. We emphasized (84 FR
7536) that the HIPAA Security Rule and the proposed exception have
different foci. The HIPAA Security Rule establishes a baseline by
requiring certain entities to ensure the confidentiality, integrity,
and availability of ePHI by implementing security measures, among other
safeguards, that the entities determine are sufficient to reduce risks
and vulnerabilities to a reasonable and appropriate level. In contrast,
we explained that the purpose of the exception to the information
blocking provision is to provide flexibility for reasonable and
necessary security practices without excepting from the definition of
information blocking in Sec. 171.103 practices that purport to promote
the security of EHI but that are unreasonably broad and onerous on
those seeking access to EHI, not applied consistently across or within
an organization, or otherwise may unreasonably interfere with access,
exchange, or use of EHI.
---------------------------------------------------------------------------
\172\ 45 CFR 164.306, 308, 310, and 312.
\173\ 45 CFR 164.306(b)
---------------------------------------------------------------------------
To qualify for this exception, we proposed that an actor's conduct
must satisfy threshold conditions. As discussed in detail in the
Proposed Rule (84 FR 7535 through 7538), the particular security-
related practice must be directly related to safeguarding the
confidentiality, integrity, and availability of EHI, implemented
consistently and in a non-discriminatory manner, and tailored to
identified security risks (84 FR 7535). We also proposed (84 FR 7537)
that where an actor has documented security policies that align with
applicable consensus-based standards, and where the policies are
implemented in a consistent and non-discriminatory manner, a practice's
conformity with such policies would provide a degree of assurance that
the practice was reasonable and necessary to address specific security
risks and thus should not constitute information blocking. We also
stated in the Proposed Rule (84 FR 7537) that we recognize that EHI
security may present novel and unexpected threats that even a best-
practice risk assessment and security policy cannot anticipate. We
stated that if a practice that does not implement an organizational
security policy is to qualify for this exception; however, it must meet
certain conditions. The public comments received, our responses to
these comments, and the conditions as finalized in Sec. 171.203 are
discussed below in this section of this final rule preamble.
We encouraged comment on these conditions (84 FR 7538), and our
overall approach to the proposed exception, including whether our
proposal provided adequate flexibility for actors to implement measures
that are commensurate to the threats they face, the technology
infrastructure they possess, and their overall security profiles and,
equally important, whether this exception adequately mitigates the risk
that actors will adopt security policies that are unnecessarily
restrictive or engage in practices that unreasonably interfere with
access, exchange, or use of EHI. Commenters were encouraged to propose
additional conditions that may be necessary to ensure that the
exception is tailored and does not extend protection to practices that
are not reasonable and necessary to promote the security of EHI and
that could present information blocking concerns. We also requested
comment on whether the use of consensus-based standards and guidance
provides an appropriate reference point for the development of security
policies.
Finally, we asked commenters to offer an alternative basis for
identifying practices that do not offer a security benefit (compared
with available alternatives) but that cause an information blocking
harm by interfering with access, exchange, or use of EHI (84 FR 7538).
Comments. We received several comments supporting, and did not
receive any comments opposed to, the establishment of the Security
Exception. We also received no comments offering an alternative basis
for identifying practices that do not offer a security benefit
(compared with other available alternatives) but that cause an
information blocking harm by interfering with access, exchange, or use
of EHI to a greater degree than necessary. We received a number of
comments requesting additional guidance about how the exception's
conditions can be met in practice. Commenters asked questions about, or
recommended that we furnish additional guidance on how an actor might
determine which a security practices meet the conditions in Sec.
171.203 to qualify for the exception.
Response. We appreciate commenters' feedback. We have finalized the
exception in Sec. 171.203, with some modification to the regulation
text. We have changed the title of the exception from ``Exception--
Promoting the security of electronic health information'' in the
Proposed Rule (84 FR 7603) to ``Security Exception--When will a
practice likely to interfere with access, exchange, or use of
electronic health information in order to protect the security of
electronic health information not be considered information blocking?''
Throughout this final rule preamble, we use ``Security Exception'' as a
short form of this title, for ease of reference. As stated in Section
VIII.D of this final rule preamble, we have changed the titles of all
of the exceptions to questions to improve clarity. We have edited the
wording of the introductory text of Sec. 171.203 as finalized, in
comparison to that proposed (84 FR 7603) so that it is consistent with
the finalized title of Sec. 171.203. We believe these conforming
changes in wording of the introductory text also improve clarity of
expression in this section.
Comments on specific conditions are summarized below, in context of
each condition proposed. We believe our responses to these comments
furnish the clarity actors need to understand the conditions and of the
exception finalized in Sec. 171.203 for practices likely to interfere
with access, exchange, or use of EHI in order to protect the security
of EHI to be considered excepted from the definition of information
blocking in Sec. 171.103.
Condition: The Practice Must Be Directly Related to Safeguarding the
Confidentiality, Integrity, and Availability of Electronic Health
Information
We proposed that, as a threshold condition, the exception would not
apply to practices that are not directly related (84 FR 7536) to
safeguarding the security of EHI. We explained that, in assessing the
practice, we would consider whether and to what extent the practice
directly addressed specific security risks or concerns. We noted that
we would also consider whether the practice served any other purposes
and, if so, whether those purposes were merely incidental to the
overriding security purpose or provided an objectively distinct, non-
security-related rationale for engaging in the practice.
We noted (84 FR 7536) that it should not be particularly difficult
or onerous for an actor to demonstrate that its
[[Page 25861]]
practice was directly related to a specific security risk or concern.
For example, we explained that the actor may show that the practice was
a direct response to a known security incident or threat; or that the
practice directly related to the need to verify a person's identity
before granting access to EHI; or that the practice was directly
related to ensuring the integrity of EHI.
We emphasized (84 FR 7536) that the salient issue under this
condition, therefore, would be whether the security practice was
actually necessary and directly related to the specific security risk
being addressed. To that end, we noted that we would consider the
actor's purported basis for adopting the particular security practice,
which could be evidenced by the actor's organizational security policy,
risk assessments, and other relevant documentation, which most actors
are already required to develop pursuant to requirements under the
HIPAA Rules. However, we proposed that the documentation of an actor's
decision making would not necessarily be dispositive. For example, we
noted that if the practice had the practical effect of disadvantaging
competitors or steering referrals, this could be evidence that the
practice was not directly related and tailored to the specific security
risk. We proposed that such an inference would also not be warranted
where the actor has not met the other conditions of this exception, as
where the actor's policies were not developed or implemented in a
reasonable manner; its security policies or practices were not tailored
to specific risks; or it applied its security policies or practices in
an inconsistent or discriminatory manner.
Comments. We received a number of comments supporting the
applicability of this exception to practices directly related to
safeguarding the confidentiality, integrity, and availability of EHI
and that are consistent with the HIPAA Security Rule. We received no
comments recommending that this exception not be applicable to such
practices.
Response. We have finalized this condition as proposed. In order to
meet this specific condition (finalized in Sec. 171.203(a)), a
practice must be directly related to safeguarding the confidentiality,
integrity, and availability of EHI.
Comments. Commenters expressed concerns with what commenters
described as the complexity of fact-based analysis and use of terms
such as ``directly related.'' Commenters stated that analyzing their
policies and practices against such standards could be burdensome,
especially in the context of the requirement to meet all conditions at
all relevant times.
Response. While fact-based analysis may not be as simple as
determining if a particular security practice does or does not conform
to a pre-specified approach, we believe that it is the most practical
approach given the inherent complexity of the regulatory and threat
landscapes relevant to an actor's cybersecurity practices. This
landscape complexity contributes substantially to our belief that a
one-size-fits-all detailed definition or test for security measures or
methods to be deemed ``directly related'' to safeguarding the
confidentiality, integrity, and availability of EHI would not be the
optimal approach at this time. We have not established a specific,
regulatory definition for ``directly related'' as we are using both
``directly'' and ``related'' in their ordinary meanings.\174\
---------------------------------------------------------------------------
\174\ Ordinary meanings of the adverb ``directly'' and the
adjective ``related'' in American usage can be found in widely
published dictionaries, such as The American Heritage Dictionary of
the English Language, Dictionary.com, or Merriam-Webster.com.
---------------------------------------------------------------------------
With respect to the condition that a practice meet all conditions
in Sec. 171.203 at all relevant times in order to satisfy the
exception, we do not believe it would be particularly difficult, in
context of a fact-specific analysis, for an actor to demonstrate that
its practice was directly related to a specific security risk or
concern. For example, the actor may show that the practice was a direct
response to a known security incident or threat, or that the practice
was directly related to the need to verify a person's identity before
granting access to EHI. We also note that, although we encourage actors
to voluntarily conform their practices to the conditions of an
exception suited to the practice and its purpose, an actor's choice to
do so simply provides it an enhanced level of assurance that the
practices do not meet the definition of information blocking. Failure
to meet an exception does not necessarily mean a practice meets the
definition of information blocking. If subject to an investigation by
HHS, each practice that implicates the information blocking provision
and that does not meet any exception would be analyzed on a case-by-
case basis.
The overarching purpose of the Security Exception is to provide
flexibility for reasonable and necessary security practices while
screening out practices that purport to promote the security of EHI but
that otherwise unreasonably and/or unnecessarily interfere with access,
exchange, and use of EHI. Confidentiality, integrity and availability,
also known as the CIA triad, is a model designed to guide policies for
information security practices within an organization. The elements of
the triad are considered the three most crucial components of
information security practices.\175\ In assessing whether a practice
meets the condition finalized in Sec. 171.203(a), the information that
we would expect to consider includes, but is not necessarily limited
to, the actor's purported basis for adopting the particular security
practice, which could be evidenced by the actor's organizational
security policy, risks assessments the actor had performed that
informed the actor's security-based practice(s), and other relevant
documentation that an actor maintains. We also reiterate our
observation that many actors are also HIPAA covered entities or
business associates. For that reason, many actors are likely to have,
pursuant to their meeting the requirements of the HIPAA Security Rule,
documentation relevant to showing their security-based practice(s)
satisfy the Security Exception condition that is finalized in Sec.
171.203(a).\176\
---------------------------------------------------------------------------
\175\ See NIST Special Publication 800-12, revision 1, An
Introduction to Information Security.
\176\ 45 CFR 164.316
---------------------------------------------------------------------------
Condition: The Practice Must Be Tailored to the Specific Security Risk
Being Addressed
To meet the exception, we proposed (84 FR 7536) that an actor's
security-related practice must be tailored to specific security risks
that the practice actually addressed. We explained that this condition
necessarily presupposes that an actor has carefully evaluated the risk
posed by the security threat and developed a considered response that
is tailored to mitigating the vulnerabilities of the actor's health IT
or other related systems.
Comments. Commenters expressed concerns with what commenters
described as the complexity of fact-based analysis and use of terms
such as ``tailored.'' Commenters stated that analyzing their policies
and practices against such standards could be burdensome, especially in
context of the requirement to meet all conditions at all relevant
times.
Response. While fact-specific analysis may not be as simple as
determining if a particular security practice does or does not conform
to a pre-specified approach, we believe that it is the most practical
approach given the inherent complexity of the regulatory and threat
landscapes relevant to an actor's cybersecurity practices. This
landscape
[[Page 25862]]
complexity contributes substantially to our belief that a one-size-
fits-all definition or test for security measures or methods to be
deemed conformant with the condition finalized in Sec. 171.203(b)
would not be the optimal approach at this time. Instead, we have
finalized the condition proposed in Sec. 171.201(b) as proposed. We
believe requiring that the actor's policies and practices be tailored
to the risk being addressed is currently the most appropriate and
practical approach. We intend for this exception to be applicable to a
wide array of practices that are reasonable and necessary to protect
the security of EHI in various actors' specific operational contexts.
In assessing whether a practice meets the condition finalized in Sec.
171.203(b), we would consider whether and to what extent the practice
directly addresses specific security risks or concerns and whether it
was tailored to those risks. We would also consider whether the
practice served any other purposes and if so, whether those purposes
were merely incidental to an overriding security purpose or provided an
objectively distinct, non-security related rationale for engaging in
the practice. We also believe the ordinary meaning of ``tailored''
\177\ provides sufficient clarity that we expect the practices to be
made or adapted to serve the particular purpose or need for which they
are deployed. With respect to the requirement that a practice meet all
conditions in Sec. 171.203 at all relevant times in order to satisfy
the exception, we do not believe it would be particularly difficult, in
context of a fact-specific analysis, for an actor to demonstrate that
each practice was made or adapted to serve the particular purpose or
need for which is was deployed. For example, where a practice meets the
condition finalized in Sec. 171.203(a) by being a direct response to a
known security incident or threat, it logically follows that the
practice should also be made or adapted to the purpose of responding to
such incident or threat. In which case, the practice's inherent
characteristics would support the actor's ability to show that it meets
the condition finalized in Sec. 171.203(b). Similarly, where an
identity-proofing practice satisfies the condition finalized in Sec.
171.203(b) by being directly related to the need to verify a person's
identity before granting access to EHI, it would be logical to expect
the practice would also be tailored to address that need.
---------------------------------------------------------------------------
\177\ See, e.g., sense 1.b. of the entry for the verb ``tailor''
in the Merriam-Webster dictionary: ``to make or adapt to suit a
special need or purpose'' (https://merriam-webster.com/dictionary/tailor, last accessed Feb. 6, 2020). See also, e.g., sense 3 of the
entry for the verb ``tailor'' in The American Heritage Dictionary of
the English Language: ``to make, alter, or adapt for a particular
end or purpose'' (https://ahdictionary.com, last accessed Feb 6,
2020).
---------------------------------------------------------------------------
Comments. Commenters recommended that actors should be permitted to
develop and implement security policies that exceed the minimum
requirements of HIPAA with the intent to promote data security or to
comply with State law or policies.
Response. If its conditions are otherwise met, this exception would
apply to security-based practices that exceed the minimum conditions of
the HIPAA Security Rule. As would be the case with a practice
implemented to comply with the HIPAA Security Rule requirements, the
fact that a practice was implemented to meet another applicable legal
mandate would be considered in assessing whether a practice meets this
exception. However, a practice that is consistent with a law or
regulation setting a minimum requirement for protecting
confidentiality, integrity, and availability of EHI might not meet this
exception. For example, a practice that is consistent with a minimum
legal condition related to the security of EHI might not meet this
exception if it is not also tailored to avoid interfering with the
access, exchange, or use of EHI to a greater extent than reasonable and
necessary to appropriately mitigate the risk it addresses.
We have finalized this condition in Sec. 171.203(b) without
modification to the text of this condition as proposed (84 FR 7603).
Condition: The Practice Must Be Implemented in a Consistent and Non-
Discriminatory Manner
We proposed (84 FR 7536 and 7537) that in order for a practice to
qualify for this exception, the actor's practice must have been
implemented in a consistent and non-discriminatory manner. We explained
that this condition would provide basic assurance that the purported
security practice is directly related to a specific security risk and
is not being used to interfere with access, exchange, or use of EHI for
other purposes to which this exception does not apply.
As an illustration solely of the non-discriminatory manner
condition (84 FR 7536 and 7537), we discussed a hypothetical example of
a health IT developer of certified health IT that offers apps to its
customers via an app marketplace. We stated that if the developer
requires that third-party apps sold (or made available) via the
developer's app marketplace meet certain security requirements, those
security requirements must be imposed in a non-discriminatory manner.
We noted that this would mean, for example, that if a developer imposed
a requirement that third-party apps include two-factor authentication
for patient access, the developer would need to ensure that the same
requirement was imposed on, and met by, all other apps, including any
apps made available by the developer itself. We also noted that such a
developer requirement must also meet the other conditions of the
exception (e.g., the condition that the practice be tailored to the
specific security risk being addressed).
Comments. We received no comments opposed to the condition that
practices must be implemented in a consistent and non-discriminatory
manner. We did receive one comment recommending that we recognize under
this exception risk-based cybersecurity practices that may result in
applying different security requirements to different exchange partners
based on risk posed.
Response. We intend this exception, including but not limited to
this specific condition, to allow for recognition of risk-based
security practices. Assessment of whether practices satisfy the
conditions of this exception will be fact-based. We also recognize that
objectively reasonable practices applied on the basis of the
cybersecurity risks posed by particular system connections or data
exchanges may result in practices that are tailored to this risk and
thus not necessarily identical across all connections, interchanges,
and therefore all individuals or entities with whom an actor engages.
In context of this condition of the Security Exception, ``consistent
and non-discriminatory'' should be understood to mean that similarly
situated actors whose interactions pose the same level of security risk
should be treated consistently with one another under the actor's
security practices. Inconsistent treatment across similarly situated
actors whose interactions pose the same level of security risk based on
extraneous factors, such as whether they are a competitor of the actor
implementing the security practices, would not be considered
appropriate.
We have finalized this condition as proposed. It is codified in
Sec. 171.203(c).
Condition Applicable to Practices That Implement an Organizational
Security Policy
We discussed in the Proposed Rule (84 FR 7537) that an actor's
approach to information security management would reflect the actor's
particular size, organizational structure, and risk
[[Page 25863]]
posture. Because of this, we emphasized that actors should develop and
implement organizational policies that secure EHI. We proposed that,
where an actor has documented security policies that align with
applicable consensus-based standards, and where the policies are
implemented in a consistent and non-discriminatory manner, a practice's
conformity with such policies would provide a degree of assurance that
the practice was reasonable and necessary to address specific security
risks and thus should not constitute information blocking.
We stated (84 FR 7537) that a practice that went beyond an actor's
established policies or procedures by imposing security controls that
were not documented would not qualify for this exception under this
condition (although the actor may be able to qualify under the
alternative basis for practices that do not implement a security
policy). We further stated that such practices would be suspect under
the information blocking provision if there were indications that the
actor's security-related justification was a pretext or after-the-fact
rationalization for its conduct or was otherwise unreasonable under the
circumstances.
We reiterated (84 FR 7537) that, to the extent that an actor seeks
to justify a practice on the basis of its organizational security
policies, such policies must be in writing and implemented in a
consistent and non-discriminatory manner. We emphasized that what a
policy requires will depend on the facts and circumstances. However, we
proposed that to support a presumption that a practice conducted
pursuant to the actor's security policy was reasonable, the policy
would have to meet conditions stated and discussed in Section VIII.D.3
of the Proposed Rule (84 FR 7537). The details within paragraph (d) of
Sec. 171.203 were proposed in regulation text (84 FR 7603). The
detailed requirements of the condition as proposed in Sec. 171.203(d)
were: If the practice implements an organizational security policy the
policy must--
Be in writing;
Have been prepared on the basis of, and directly respond
to, security risks identified and assessed by or on behalf of the
actor;
Align with one or more applicable consensus-based
standards or best practice guidance; and
Provide objective timeframes and other parameters for
identifying, responding to, and addressing security incidents.
We discuss each of these requirements (subparagraphs) within the
condition applicable to practices that implement an organizational
security policy (Sec. 171.203(d)) in more detail below.
Paragraph (d)(1): Security Policy in Writing
We proposed that the actor's security policy must be in writing (84
FR 7537). This requirement is applicable to practices that implement an
organizational security policy and is consistent with the HIPAA
Security Rule.\178\ The importance of written security policies is also
consistent with consensus-based standard and best practice
guidance.\179\
---------------------------------------------------------------------------
\178\ 45 CFR 164.316
\179\ See SP 800-53 Rev. 5 Security and Privacy Controls for
Information Systems and Organizations.
---------------------------------------------------------------------------
Comments. We received no comments opposed to this condition
proposed in Sec. 171.203(d).
Response. Within the condition (Sec. 171.203(d)) applicable to
practices that implement an organizational security policy, we have
finalized in Sec. 171.203(d)(1) the requirement that the policy must
be in writing. We have finalized this condition as proposed.
Paragraph (d)(2): Security Risks Identified and Assessed
We proposed (84 FR 7537) that the actor's security policy must be
informed by an assessment of the security risks facing the actor. While
we did not propose any requirements as to a risk assessment, we noted
that a good risk assessment would use an approach consistent with
industry standards,\180\ and would incorporate elements such as threat
and vulnerability analysis, data collection, assessment of current
security measures, likelihood of occurrence, impact, level of risk, and
final reporting.\181\
---------------------------------------------------------------------------
\180\ See OCR, Guidance on Risk Analysis, https://www.hhs.gov/hipaa/for-professionals/security/guidance/guidance-risk-analysis/index.html?language=es.
\181\ ONC and OCR have jointly launched the HHS HIPAA Security
Risk Assessment (SRA) Tool, https://www.healthit.gov/providers-professionals/security-risk-assessment-tool.
---------------------------------------------------------------------------
Comments. We received no comments opposed to requiring a linkage
between an organization's security policy and a risk assessment. We did
receive a couple of comments expressing a concern that not all actors
may yet be proficient in identifying and assessing the risks associated
with specific health IT functionalities, such as standards-based APIs.
Response. Within the condition (Sec. 171.203(d)) applicable to
practices that implement an organizational security policy, we have
finalized Sec. 171.203(d)(2) with a revision to the wording of the
regulation text in comparison with that proposed (84 FR 7603).
Specifically, we have replaced ``and respond directly to'' that
appeared in the regulation text with ``and be directly responsive to''
in the text finalized in Sec. 171.203(d)(2). Thus, the finalized text
in Sec. 171.203(d)(2) reads: ``have been prepared on the basis of, and
be directly responsive to, security risks identified and assessed by or
on behalf of the actor.''
We made this editorial revision because we believe it makes the
resulting regulation text easier to read. Although actors may have
obligations under other existing law or regulations, such as the HIPAA
Security Rule, to conduct security risk assessments, this condition,
which is applicable to security-based practices that implement an
organizational security policy, does not establish a set threshold for
an actor's proficiency in identifying, assessing, and responding to
security risks. If any actor believes it may lack the technical or
other expertise necessary to conduct a risk assessment appropriate to
its operations and the EHI for which it is responsible, we would
encourage that actor to seek additional information, training, or
support from an individual or entity with the required expertise. As
finalized in Sec. 171.203(d)(2), the requirement that risks have been
identified and assessed expressly provides for this to have been done
either by the actor or on the actor's behalf. We are sensitive to the
possibility that some actors, including but not limited to small
clinician practices, may not be in a position to meet the condition
finalized in paragraph (d) of Sec. 171.203 immediately or for all of
their security-based practices, and we therefore reiterate that we have
finalized in Sec. 171.203(e) an alternative condition that an actor
may choose to meet in circumstances where it may not be practical for
them to meet the condition finalized in Sec. 171.203(d).
We also reiterate that, while we do encourage actors to voluntarily
conform their practices to the conditions of an exception suited to the
practice and its purpose, an actor's choice to do so simply provides
them an enhanced level of assurance that the practices do not meet the
definition of information blocking. Failure to meet an exception does
not necessarily mean a practice meets the definition of information
blocking. If subject to an investigation by HHS, each practice that
implicates the information blocking provision and that does not meet
any exception would be analyzed on a case-by-case basis.
[[Page 25864]]
Paragraph (d)(3): Consensus-Based Standards or Best Practice Guidance
We proposed (84 FR 7537) that the actor's policy must align with
one or more applicable consensus-based standards or best practice
guidance. We noted that at present, examples of relevant best practices
for development of security policies include, but are not limited to:
NIST-800-53 Rev. 5; the NIST Cybersecurity Framework; and NIST SP 800-
100, SP 800-37 Rev. 2, SP 800-39, as updated and as interpreted through
formal guidance. We noted that best practice guidance on security
policies is also developed by consensus standards bodies such as ISO,
IETF, or IEC. We stated that HIPAA covered entities and business
associates may be able to leverage their HIPAA Security Rule compliance
activities and can, if they choose, align their security policy with
those parts of the NIST Cybersecurity Framework that are referenced in
the HIPAA Security Rule Crosswalk to NIST Cybersecurity Framework to
satisfy this condition. We noted that relevant consensus-based
standards and frameworks provide actors of varying sizes and resources
with the flexibility needed to apply the right security controls to the
right information systems at the right time to adequately address risk.
Comments. One commenter expressed a concern that a small
independent clinician practice that conducts a risk analysis consistent
with its obligation under the HIPAA Security Rule may lack the
technical expertise or other organizational capabilities needed to
develop a customized security policy that appropriately applies
consensus-based standards to each risk identified. This commenter
recommended that we incorporate in Sec. 171.203(d) regulation text a
statement that these conditions apply ``subject to the actor's
sophistication and technical capabilities.''
Response. We appreciate the point highlighted by the commenter
that, even within a given type of actor, specific individuals or
organizations may have different operational contexts that include
variations in their technical capabilities, expertise, and other
resources. We do not, however, believe it is necessary to revise the
regulation text as recommended in order to allow for assessment of
whether the actor's practices, such as its organizational security
policy, were objectively reasonable in the circumstances in which they
were implemented.
Comments. A number of commenters requested that this exception
allow providers to be proactive when promoting the security of EHI
rather than taking a reactive stance. Commenters contended that for
novel threats, consensus-based standards and best practice guidance may
not exist, making it impossible for an actor to meet the condition that
the organizational security policy align with such standards.
Response. With cybersecurity risk continuously evolving and the
large number of threat sources active in the modern cybersecurity
landscape, we recognize that actors must continuously monitor, assess,
and respond to security risks that can themselves represent an
impediment to EHI access, exchange, and use. Thus, this exception
allows actors flexibility in selecting and tailoring their practices to
mitigate specific security risks, provided each such practice otherwise
meets the conditions of this exception, notably including that it be
directly related and tailored to the specific security risk being
addressed and be implemented in a consistent and non-discriminatory
manner. We also note that best security practices in security
mitigation can take a proactive as well as a reactive approach. A
documented policy that provides explicit references to consensus-based
standards and best practice guidance (such as the NIST Cybersecurity
Framework) offers an objective and robust means by which we can
evaluate the reasonableness of a particular security control for the
purpose of the exception. We also recognize that, as a practical
matter, some actors (such as small health care providers or those with
limited resources) may have organizational security policies that are
less robust or that otherwise fall short of the minimum conditions
proposed. In such circumstances an actor can still benefit from this
exception by demonstrating that the practice met the conditions of this
exception for circumstances where no formal (organizational) security
policy was implemented (see our discussion under ``conditions
applicable to practices that do not implement an organizational
security policy'' header, below within this section of this final rule
preamble).
Comments. A commenter noted that it could be a difficult for an
actor to meet the standard to that the actor's organizational policy on
security must align with one or more consensus-based standards or best
practice guidance because there are many emerging security threats that
occur that are new and unexpected.
Response. We do not believe that it would be difficult for an
actor's organizational policy on security to align with one or more
consensus-based standards or best practice guidance documents. An
actor's written security policies should be based on consensus-based
standards or best practice guidance documents which specifically
address security risks and threats. A security policy should be clearly
written and observed and refers to clear, comprehensive, and well-
defined plans, rules, and practices that regulate access to an actor's
information systems and the EHI included in it. We believe a good
policy serves as a prominent statement to the outside world about the
actor's commitment to security, and that such a policy should be based
on objective consensus-based standards and should not be ad hoc or
arbitrary.
We do agree that there are emerging and novel security threats that
occur, and in those situations which are not specifically addressed by
an actor's security policies, we included in the exception as proposed
an alternative condition (proposed in Sec. 171.203(e)) to address
those situations in which those security risks can be addressed based
on particularized facts and circumstances.
Within the condition (Sec. 171.203(d)) applicable to practices
that implement an organizational security policy, the actor's policy
must align with one or more applicable consensus-based standards or
best practice guidance. The finalized condition is codified in Sec.
171.203(d)(3).
Paragraph (d)(4): Objective Timeframes and Other Parameters
We proposed that the actor's security policy must provide objective
timeframes and common terminology used for identifying, responding to,
and addressing security incidents. We noted examples of acceptable
sources for development of a security response plan include: NIST
Incident Response Procedure (https://csrc.nist.gov/publications/detail/sp/800-61/rev-2/final), US-CERT for interactions with government
systems (https://www.us-cert.gov/government-users/reporting-requirements), and ISC-CERT for critical infrastructure (https://ics-cert.us-cert.gov/) (84 FR 7537).
As a point of clarification, we noted that an actor's compliance
with the HIPAA Security Rule (if applicable to the actor) would be
relevant to, but not dispositive of, whether the actor's policies and
procedures were objectively reasonable for the purpose of the
exception. We explained that an actor's documentation of its security
policies and procedures for compliance with the HIPAA Security Rule may
not offer a sufficient basis to evaluate whether the actor's security
practices
[[Page 25865]]
unnecessarily interfere with access, exchange, or use of EHI. We
further noted that a documented policy that provides explicit
references to consensus-based standards and best practice guidance
(such as the NIST Cybersecurity Framework) would offer an objective and
robust means by which to evaluate the reasonableness of a particular
security control for the purpose of the exception (84 FR 7537).
Comments. We received no comments opposing this requirement of the
condition applicable to practices that implement an organizational
security policy.
Response. Within the condition (Sec. 171.203(d)) applicable to
practices that implement an organizational security policy, we have
finalized in Sec. 171.203(d)(4) the condition that the actor's
organizational security policy ``provide objective timeframes and other
parameters for identifying, responding to, and addressing security
incidents.'' We have finalized this condition as proposed.
Condition Applicable to Practices That Do Not Implement an
Organizational Security Policy
In the Proposed Rule (84 FR 7537), we recognized that, as a
practical matter, some actors (such as small health care providers or
those with limited resources) may have organizational security policies
that are less robust or that otherwise fall short of the minimum
conditions proposed. We proposed that in these circumstances an actor
could still benefit from the exception by demonstrating that the
practice at issue was objectively reasonable under the circumstances,
without regard to a formal policy. While we noted in the Proposed Rule
(84 FR 7537) that we expect that most security practices engaged in by
an actor will implement an organizational policy, we recognized that
EHI security may present novel and unexpected threats that even a best-
practice risk assessment and security policy cannot anticipate. We
noted that if a practice that does not implement an organizational
policy is to qualify for this exception, however, it must meet certain
conditions. We stated that the actor's practice must, based on the
particularized facts and circumstances, be necessary to mitigate the
security risk. Importantly, we proposed that the actor would have to
demonstrate that it considered reasonable and appropriate alternatives
that could have reduced the likelihood of interference with access,
exchange, or use of EHI and that there were no reasonable and
appropriate alternatives that were less likely to interfere with
access, exchange or use of EHI.
We noted (84 FR 7538) that an actor's consideration of reasonable
and appropriate alternatives will depend on the urgency and nature of
the security threat in question. We further noted that we anticipate
that an actor's qualification for the exception would accommodate
exigent circumstances. For example, we stated that we would not expect
an actor to delay the implementation of a security practice in response
to an emergency on the basis that it has not yet been able to initiate
a fully realized risk assessment process. However, we also stated that
we would expect that in these exigent circumstances, where the actor
has implemented a security practice without first considering whether
there were reasonable and appropriate alternatives that were less
likely to interfere with access, exchange or use of EHI, the actor
would expeditiously make any necessary changes to the practice based on
the actor's re-consideration of reasonable and appropriate alternatives
that are less likely to interfere with access, exchange or use of EHI.
We proposed that the exception would apply in these instances so long
as an actor takes these steps and complies with all other applicable
conditions.
Comments. Commenters stated that the absence of a policy means that
one is dealing with an unexpected and evolving situation as best one
can (e.g., a sustained and sophisticated attack). Commenters suggested
we create a further ``safety valve'' for short-lived actions that are
taken in good faith while a situation is being evaluated and understood
and that we should recognize the valid need to allow for due diligence
as distinct from simply delaying access and such due diligence should
not need the Security Exception to avoid implicating or being judged as
engaged in information blocking. Commenters stated this is a core need
for small medical practices with limited resources.
Response. We anticipate that the exception's conditions as proposed
and finalized would accommodate exigent circumstances. For example, we
would not expect an actor to delay the implementation of a security
measure in response to an emergency such as a cyberattack simply
because it has not yet been able to implement a fully realized risk
assessment process. We believe the exception as posed does provide a
``safety valve'' for situations where an actor in direct response to
exigent circumstances may have implemented in good faith a security
practice without first considering whether there were reasonable and
appropriate alternatives that were less likely to interfere with
access, exchange, or use of EHI, but where the initial-response
practice may be in place for only a short while. Presumably, such
initial-response practices are in place for only a short time precisely
because, upon more fully identifying and assessing current risks in
context or as follow-up to the exigent circumstances, the actor will
have concluded it carried a greater than necessary burden--including
the burden of interference with access, exchange or use of EHI--and
consequently modified or replaced its initial-response practice with a
less onerous alternative that was reasonable and appropriately tailored
to the specific risk addressed.
Comments. A commenter agreed that this exception allows for an
actor to maintain flexibility in its approach to address security
incidents or threats.
Response. We agree that this exception provides an actor the
flexibility to address security incidents or threats based on
particularized facts and circumstances which are necessary to mitigate
the security risk to EHI, provided that there are no reasonable and
appropriate alternatives to the practice that address the security risk
that are less likely to interfere with, prevent, or materially
discourage access, exchange or use of EHI.
We have finalized as proposed, in Sec. 171.203(e), the
requirements applicable to practices that meet the threshold conditions
established in Sec. Sec. 171.203(a), (b) and (c) and that do not
implement an organizational security policy.
d. Infeasibility Exception--When will an actor's practice of not
fulfilling a request to access, exchange, or use electronic health
information due to the infeasibility of the request not be considered
information blocking?
We proposed in the Proposed Rule in Sec. 171.205 (84 FR 7542 and
7603) to establish an exception to the information blocking provision
that would permit an actor to decline to provide access, exchange, or
use of EHI in a manner that is infeasible, provided certain conditions
are met. We proposed that in certain circumstances legitimate practical
challenges beyond an actor's control may limit its ability to comply
with requests for access, exchange, or use of EHI. In some cases, the
actor may not have--and may be unable to obtain--the requisite
technological capabilities, legal rights, financial resources, or other
means necessary to provide a particular form of access, exchange, or
use. In other cases, the actor may be able to comply with the
[[Page 25866]]
request, but only by incurring costs or other burdens that are clearly
unreasonable under the circumstances (84 FR 7542).
We proposed that the exception would permit an actor to decline a
request in certain narrowly-defined circumstances when doing so would
be infeasible (or impossible) and when the actor otherwise did all that
it reasonably could do under the circumstances to facilitate
alternative means of accessing, exchanging, and using the EHI. We
proposed a structured, fact-based approach for determining whether a
request was ``infeasible'' within the meaning of the exception. We
noted that this approach would be limited to a consideration of factors
specifically delineated in the exception and that the infeasibility
inquiry would focus on the immediate and direct financial and
operational challenges of facilitating access, exchange, and use, as
distinguished from more remote, indirect, or speculative types of
injuries (84 FR 7542).
We encouraged comment on these and other aspects of this proposal
(84 FR 7542).
Comments. We received several comments in general support of the
proposed exception.
Response. We thank commenters for their support of our proposal. We
note that we have changed the title of this exception from
``Exception--Responding to requests that are infeasible'' (84 FR 7603)
to ``When will an actor's practice of not fulfilling a request to
access, exchange, or use electronic health information due to the
infeasibility of the request not be considered information blocking?''
Throughout this final rule preamble, we use ``Infeasibility Exception''
as a short form of this title, for ease of reference. As stated in
Section VIII.D of this final rule preamble, we have changed the titles
of all of the exceptions to questions to improve clarity. We have also
edited the wording of the introductory text in Sec. 171.204 as
finalized, in comparison to that proposed (84 FR 7603 and 7604), so
that it is consistent with the finalized title of Sec. 171.204. We
believe these conforming changes in wording of the introductory text
also improve clarity in this section.
i. Infeasibility of the Request
To qualify for the exception, we proposed that compliance with the
request for access, exchange, or use of EHI must be infeasible. We
proposed a two-step test that an actor would need to meet in order to
demonstrate that a request was infeasible. Under the first step of the
infeasibility test, we proposed that the actor would need to show that
complying with the particular request in the manner requested would
impose a substantial burden on the actor. Second, we proposed that the
actor must also demonstrate that requiring it to comply with the
request--and thus to assume the substantial burden demonstrated under
the first part of the test--would have been plainly unreasonable under
the circumstances (84 FR 7542 and 7543). We proposed that whether it
would have been plainly unreasonable for the actor to assume the burden
of providing access, exchange, or use will be highly dependent on the
particular facts and circumstances. We proposed to rely primarily on
the following key factors enumerated in proposed Sec. 171.205(a)(1):
The type of EHI and the purposes for which it may be
needed;
The cost to the actor of complying with the request in the
manner requested;
The financial, technical, and other resources available to
the actor;
Whether the actor provides comparable access, exchange, or
use to itself or to its customers, suppliers, partners, and other
persons with whom it has a business relationship;
Whether the actor owns or has control over a predominant
technology, platform, health information exchange, or health
information network through which EHI is accessed or exchanged;
Whether the actor maintains ePHI on behalf of a covered
entity, as defined in 45 CFR 160.103, or maintains EHI on behalf of the
requestor or another person whose access, exchange, or use of EHI will
be enabled or facilitated by the actor's compliance with the request;
Whether the requestor and other relevant persons can
reasonably access, exchange, or use the information from other sources
or through other means; and
The additional cost and burden to the requestor and other
relevant persons of relying on alternative means of access, exchange,
or use (84 FR 7543).
We acknowledged in the Proposed Rule that there may be situations
when complying with a request for access, exchange, or use of EHI would
be considered infeasible because an actor is unable to provide such
access, exchange, or use due to unforeseeable or unavoidable
circumstances that are outside the actor's control. As examples, we
stated that an actor could seek coverage under this exception if it is
unable to provide access, exchange, or use of EHI due to a natural
disaster (such as a hurricane, tornado or earthquake) or war. We
emphasized that, consistent with the requirements for demonstrating
that practices meet all the conditions of a proposed exception, the
actor would need to produce evidence and ultimately prove that
complying with the request for access, exchange, or use of EHI in the
manner requested would have imposed a clearly unreasonable burden on
the actor under the circumstances (84 FR 7543 and 7544).
We stated that certain circumstances would not constitute a burden
to the actor for purposes of this exception and would not be considered
in determining whether complying with a request would have been
infeasible. We proposed that it would not be considered a burden if
providing the requested access, exchange, or use of EHI in the manner
requested would have (1) facilitated competition with the actor; or (2)
prevented the actor from charging a fee (84 FR 7544).
We requested comment on the proposed approach for determining
whether a request is ``infeasible'' within the meaning of the
exception. We encouraged comment on, among other issues, whether the
factors we specifically delineated properly focus the infeasibility
inquiry; whether our approach to weighing these factors is appropriate;
and whether there are additional burdens, distinct from the immediate
and direct financial and operational challenges, that are similarly
concrete and should be considered under the fact-based rubric of the
exception (84 FR 7544).
Comments. We received several comments in support of our proposed
approach for determining whether a request was ``infeasible.'' We also
received several comments that expressed various concerns and
suggestions for improvement regarding our proposals. Several commenters
expressed concern that the language in the proposed exception,
particularly regarding the ``infeasibility'' of a request, was too
vague or ambiguous and that the inclusion of undefined terms could
create uncertainty for actors regarding whether they meet the
conditions under the exception. Commenters noted that such uncertainty
could dissuade actors from taking advantage of the exception.
Commenters requested additional examples and guidance to clarify the
conditions under the exception.
A few commenters questioned whether it would be considered
information blocking if they could not segment EHI to respond to a
request for a patient's EHI (e.g., when patient consent to share EHI
subject to 42 CFR part 2 or a State privacy law has not been provided).
These commenters
[[Page 25867]]
expressed concern about the ability of their technology to segment a
patient's EHI.
Response. We thank commenters for their support of our proposed
approach for determining whether a request is ``infeasible,'' as well
as the constructive feedback. We agree with commenters that each
exception should clearly explain the conduct that would and would not
be covered by each exception. We also reiterate that failure to meet
the exception does not mean that an actor's practice related to
infeasible requests necessarily meets the information blocking
definition. However, as we noted in the Proposed Rule, the broad
definition of information blocking in the Cures Act means that any
practice that is likely to interfere with the access, exchange, or use
of EHI implicates the information blocking provision. As a result,
practices that do not meet the exception will have to be assessed on a
case-by-case basis to determine, for example, the actor's intent and
whether the practice rises to the level of an interference.
We have restructured this exception to provide further clarity.
Toward that end, we have eliminated the proposed two-step test that an
actor would need to meet in order to demonstrate that a request is
infeasible (84 FR 7542 and 7543). Instead, we have finalized a revised
framework for this exception that provides two new conditions that must
be met in order for an actor to be covered by the exception and a
revised condition that provides an exception for those actors unable to
meet the new Content and Manner Exception. When the practice by an
actor meets one of the conditions in Sec. 171.204(a) and the actor
meets the requirements for responding to requests in Sec. 171.204(b)
(which are discussed in more detail below), the actor is not required
to fulfill a request for access, exchange, or use of EHI due to the
infeasibility of the request.
The first new condition is that the actor cannot fulfill the
request for access, exchange, or use of EHI due to events beyond the
actor's control, namely a natural or human-made disaster, public health
emergency, public safety incident, war, terrorist attack, civil
insurrection, strike or other labor unrest, telecommunication or
internet service interruption, or act of military, civil or regulatory
authority (Sec. 171.204(a)(1)). This is consistent with our statements
in the Proposed Rule describing events that an actor could seek
coverage for under this exception if it is was unable to provide
access, exchange, or use of EHI due to events beyond its control (84 FR
7543). This new condition makes clear that such events are all that are
necessary to meet this exception and no consideration of factors must
be demonstrated and proven.
The second new condition is that the actor is not required to
fulfill a request for access, exchange, or use of EHI if the actor
cannot unambiguously segment the requested EHI from other EHI: (1)
Because of a patient's preference or because the EHI cannot be made
available by law; or (2) because the EHI is withheld in accordance with
the Harm Exception in Sec. 171.201 (Sec. 171.204(a)(2)). For
instance, an actor will be covered under this condition if the actor
could not fulfill a request to access, exchange, or use EHI because the
requested EHI could not be unambiguously segmented from patient records
created by federally assisted programs (i.e., Part 2 Programs) for the
treatment of substance use disorder (and covered by 42 CFR part 2) or
from records that the patient has expressed a preference not to
disclose.
The revised condition in Sec. 171.204(a)(3)(i) specifically aligns
with our proposal (84 FR 7543) in that an actor would not be required
to fulfill a request for access, exchange, or use of EHI if the actor
demonstrates, through contemporaneous written record or other
documentation, its consideration of the following factors in a
consistent and non-discriminatory manner, prior to responding to the
request pursuant to paragraph (b) of this section, that led to its
determination that complying with the request would be infeasible under
the circumstances:
The type of EHI and the purposes for which it may be
needed;
The cost to the actor of complying with the request in the
manner requested;
The financial and technical resources available to the
actor;
Whether the actor's practice is non-discriminatory and the
actor provides the same access, exchange, or use of EHI to its
companies or to its customers, suppliers, partners, and other persons
with whom it has a business relationship;
Whether the actor owns or has control over a predominant
technology, platform, health information exchange, or health
information network through which electronic health information is
accessed or exchanged; and
Why the actor was unable to provide access, exchange, or
use of EHI consistent with the Content and Manner Exception in Sec.
171.301.
We note that the above provisions align with our proposal in the
Proposed Rule that the actor must provide the requestor with a detailed
written explanation of the reasons why the actor cannot accommodate the
request (84 FR 7544). The difference in the final language is that we
have not specified the level of detail required in the written record
or other documentation, and have clarified that such a written record
or other documentation must be contemporaneous so that an actor cannot
use a post hoc rationalization for claiming the request was infeasible
under circumstances that were not considered at the time the request
was received.
We proposed in the Proposed Rule (84 FR 7544) and have finalized in
this final rule in Sec. 171.204(a)(3)(ii) the following factors that
may not be considered in the determination: (1) Whether the manner
requested would have facilitated competition with the actor; and (2)
whether the manner requested prevented the actor from charging a fee or
resulted in a reduced fee. We note that we have clarified in the final
rule that charging ``a'' fee includes a reduced fee as well. Our
rationale for carving out these considerations is that the purpose of
the Infeasibility Exception is to provide coverage to actors who face
legitimate practical challenges beyond their control that limit their
ability to comply with requests to access, exchange, or use EHI. We do
not believe that whether the manner requested would have facilitated
competition with the actor or prevented the actor from charging a fee
or resulted in a reduced fee qualify as the type of legitimate
practical challenges beyond the actor's control that should be covered
by the exception. Regarding the consideration of fees, the actor is
able to charge fees for costs reasonably incurred, with a reasonable
profit margin, for accessing, exchanging, or using EHI under the Fees
Exception in Sec. 171.302.
We have finalized in Sec. 171.204(a)(3)(i)(F) the criterion that
considers an actor's ability to provide access, exchange, and use of
EHI consistent with the Content and Manner Exception in Sec. 171.301
in order to assure alignment of this exception with the Content and
Manner Exception. We further discuss the Content and Manner Exception
in section VIII.D.2.a of this final rule.
We did not finalize three factors that were proposed in the context
of the infeasibility analysis: (1) Whether the actor maintains
electronic protected health information on behalf of a covered entity,
as defined in 45 CFR 160.103, or maintains electronic health
information on behalf of the requestor or another person whose access,
exchange, or use of electronic health information will be enabled or
facilitated by the
[[Page 25868]]
actor's compliance with the request; (2) whether the requestor and
other relevant persons can reasonably access, exchange, or use the
electronic health information from other sources or through other
means; and (3) the additional cost and burden to the requestor and
other relevant persons of relying on alternative means of access,
exchange, or use (see the proposed factors at 84 FR 7543). We removed
the first factor because it was confusing and was not a strong
indicator of whether a request was infeasible. We removed the second
and third factors because we proposed them with the intention that they
would be indicators of whether the relative burden on the requestor was
greater than that on the actor. However, we have shifted away from this
relative burden analysis in the final rule. To illustrate,
consideration does not have to be given as to whether other means are
available for access, exchange, or use of EHI or the cost to the
requestor for that alternative means because of the new Content and
Manner Exception (Sec. 171.301) and its relationship to this
exception.
Comments. One commenter recommended that claims of infeasibility
based on the classification of EHI as proprietary and claims of
infeasibility rooted in discriminatory practices should not be included
in the exception, as they do not support ONC's policy goals of
promoting competition and innovation in health IT and ultimately
disadvantage customers and patients.
Response. We agree with the commenter that claiming the EHI itself
as proprietary is not a justification for claiming this exception. As
discussed in more detail in the Fees Exception, we emphasize that
almost all of the patient EHI found in the U.S. health care system has
been generated and paid for with either public dollars through Federal
programs, including Medicare and Medicaid, or directly subsidized
through the tax preferences for employer-based insurance.
We explained in the Proposed Rule how use of IP rights for
interoperability elements can serve to interfere with access, exchange,
and use of EHI. We also explained in the Proposed Rule that the mere
fact that EHI is stored in a proprietary format or has been combined
with confidential or proprietary information does not alter the actor's
obligations under the information blocking provision to facilitate
access, exchange, and use of the EHI in response to a request (84 FR
7517). We emphasize that actors who control proprietary
interoperability elements and demand royalties or license terms from
competitors or other persons who are technologically dependent on the
use of those interoperability elements would also be subject to the
information blocking provision, unless they meet all conditions of the
Licensing Exception (Sec. 171.303).
We note, however, that actors may seek coverage under the
Infeasibility Exception (Sec. 171.204) or Content and Manner Exception
(Sec. 171.301) for certain issues related to IP. For instance, an
actor may claim to be unable to fulfill a request to access, exchange,
or use EHI because the actor is not the owner of the IP rights and
lacks requisite authority to provide the requested access, exchange, or
use of EHI. In such a situation, the actor could claim that the request
is infeasible under the circumstances (see Sec. 171.204(a)(3)). Under
Sec. 171.204(a)(3)(i)(E), one factor that can be considered when
determining whether a practice is infeasible under the circumstances is
whether the actor owns or has control over a predominant technology,
platform, HIE, or HIN through which EHI is accessed or exchanged. The
actor could also seek coverage under the Content and Manner Exception.
Under Sec. 171.301(b)(2), an actor may provide the EHI requested in an
alternative manner if responding to the request in the manner requested
would require the actor to license IP. As we have explained throughout
this final rule, each information blocking case, and whether the
actor's practice would meet all conditions of an exception, will depend
on its own unique facts and circumstances. We refer readers to the
detailed discussions regarding the Content and Manner Exception
(VIII.D.2.a) and Licensing Exception (VIII.D.2.c) in this preamble.
We also agree with the commenter that infeasibility rooted in
discriminatory practices should not be a justification for claiming
this exception. It was never our intention to allow such conduct to be
covered by this exception. In response to this comment, we have
clarified the factor in Sec. 171.204(a)(3)(i)(D) to explicitly state
that one consideration for determining whether a request is infeasible
under the circumstances is whether the actor's practice is non-
discriminatory and the actor provides the same access, exchange, or use
to its companies or to its customers, suppliers, partners, and other
persons with whom it has a business relationship.
Comments. Some commenters expressed concern that this exception
does not fully consider potential conflicts between valid contracts,
such as business associate agreements (BAAs), and subsequent requests
for access, exchange, and use of EHI that are inconsistent with those
contracts. Commenters urged ONC to specify whether an actor can refuse
a request to access, exchange, or use EHI as being infeasible due to
such contractual restrictions and obligations.
Response. We appreciate these comments. We reiterate, as we
explained in the Proposed Rule, that one means by which actors restrict
access, exchange, or use of EHI is through formal restrictions, such as
contract or license terms, EHI sharing policies, organizational
policies or procedures, or other instruments or documents that set
forth requirements related to EHI or health IT (84 FR 7518). We
emphasize that such restrictions are one of the forms of information
blocking the Cures Act and our final rule seek to address. We refer
readers to the discussion of ``Practices that May Implicate the
Information Blocking Provision'' in section VIII.C.6 of this final rule
for a more detailed discussion of when contracts and agreements will be
considered an ``interference'' with access, exchange, or use of EHI.
Comments. A few commenters encouraged ONC to add a provision to the
exception that would enable entities who have joined Trusted Exchange
Framework and Common Agreement (TEFCA) to claim the Infeasibility
Exception if a requestor or third party refused to join the TEFCA and
instead demanded a one-off interface.
Response. We appreciate these comments, but have decided not to
adopt this suggested addition at this time. The TEFCA is still new, the
Common Agreement is not yet finalized, and it would be premature to
establish special treatment for entities that join the TEFCA. We may
reconsider this suggestion at a later date. We note that this does not
necessarily mean that actors in these situations will not be covered by
the exception, as they could still show that a request for a one-off
interface is infeasible under the circumstances (see Sec.
171.204(a)(3)). However, not joining TEFCA is not de facto proof of
infeasibility. We note that in addition to seeking coverage for
infeasibility under the circumstances, the actor could also seek
coverage from: (1) The Content and Manner Exception if the actor could
not fulfill request to access, exchange, or use EHI in the manner
requested (via a one-off interface), but could fulfill the request
through an acceptable alternative manner (see Sec. 171.301(b)); or (2)
the Fees Exception or Licensing Exception if the actor chooses to
provide the one-off interface as requested, but charges
[[Page 25869]]
fees/royalties related to developing or licensing the one-off
interface, which could include fees or royalties that result in a
reasonable profit margin (see Sec. 171.302 and 303).
ii. Responding to Requests--Timely and Written Responses
We proposed, in addition to demonstrating that a particular request
was infeasible, that an actor would have to show that it satisfied
additional conditions. Specifically, we proposed that to qualify for
the exception, the actor must have timely responded to all requests
relating to access, exchange, and use of EHI. Further, we proposed that
for any request that the actor claims was infeasible, the actor must
have provided the requestor with a detailed written explanation of the
reasons why the actor could not accommodate the request. We proposed
that the actor's failure to meet any of these conditions would
disqualify the actor from the exception and could also be evidence that
the actor knew that it was engaging in practices that contravened the
information blocking provision (84 FR 7544).
We proposed that the duty to timely respond and provide reasonable
cooperation would necessarily be assessed from the standpoint of what
is objectively reasonable for an individual or entity in the actor's
position. We emphasized that we will look at the specific facts and
circumstances of each case to determine whether the practice is
objectively reasonable (84 FR 7544).
We encouraged comment on these conditions and related
considerations. Specifically, we requested comment regarding potential
obstacles to satisfying these conditions and improvements we could make
to the proposed process (84 FR 7544).
Comments. Many commenters, primarily provider organizations,
expressed concern that the proposed response requirements could create
burden on providers, hospitals, and clinical data registries.
Commenters explained that each time a requester makes a request that an
actor deems infeasible, the actor would be required to timely respond
and provide a detailed written explanation of its reasons for denial. A
commenter also recommended that, in the event a request is infeasible
and a written explanation is necessary, that such explanation need not
contain detailed technical information.
Response. We appreciate these comments and have revised the
response condition in this exception to address commenters' concerns
and establish a set timeframe for responding to requests (Sec.
171.204(b)). We removed the use of the term ``timely'' and restructured
the provision to more clearly explain ONC's expectations for responding
to requests. Under the response condition, if an actor does not fulfill
a request for access, exchange, or use of EHI for any of the reasons in
Sec. 171.204(a), the actor must, within ten business days of receipt
of the request, provide to the requestor in writing the reason why
meeting the request was infeasible. Our decision to finalize a 10-
business day response timeframe was informed by our knowledge of the
industry, stakeholder commenters, and a desire to create consistent
timeframes across exceptions, such as alignment with the 10-business
day response timeframe in the Licensing Exception (see Sec.
171.303(a)(1)).
In instances when an actor is unable to respond within 10 business
days, the actor may be unable to avail themselves of the requirements
of the exception. As part of an information blocking investigation, ONC
and OIG may consider documentation or other writings maintained by the
actor around the time of the request that provide evidence of the
actor's intent. Additional documentation would not permit the actor to
avail themselves of this exception, but ONC or OIG could examine the
actor's intent using this documentation when assessing the information
blocking claim.
We have decided not to specify the level of detail or specific type
of information (such as technical information) that must be contained
in a written response. We believe it would be imprudent to create such
boundaries for the written response given that the facts and
circumstances will vary significantly from case to case. Instead, the
finalized provision allows actors to determine what content is
necessary to include in the written response in order to explain the
reason the request is infeasible. We note that we have revised the
requirement for the written response from the Proposed Rule. In the
Proposed Rule an actor was required to provide a ``detailed written
explanation of the reasons why the actor cannot accommodate the
request'' (84 FR 7544) whereas we have finalized the requirement that
the actor must provide ``in writing the reason(s) why the request is
infeasible'' (Sec. 171.204(b)). We believe this revised requirement
will alleviate burden on actors by providing them discretion to decide
the appropriate level of detail to include in their written responses.
It also places a greater emphasis on establishing that the request was
infeasible to meet.
Reasonable Alternative
We proposed that, if the actor could not meet the request for EHI,
the actor must work with the requesting party in a timely manner to
identify and provide a reasonable alternative means of accessing,
exchanging, or using the EHI, as applicable (84 FR 7544).
Comments. Commenters, primarily provider organizations, were
supportive of the proposed requirement to provide a reasonable
alternative. We also received a range of comments related to improving
ONC's proposals regarding the provision of a reasonable alternative,
including comments requesting more examples and guidance as to what
would be considered a ``reasonable alternative.'' Another commenter
requested that ONC provide greater deference to the actor to determine
the appropriate format/functionality for sharing the requested EHI when
a comparable functionality, distinct from the format/functionality
requested, is made available and enables access, exchange, or use of
EHI on equivalent terms. One commenter requested ONC place guardrails
around requests for information sharing, such that if an actor is able
to share data in an industry-accepted format, the requesting
organization cannot make an information blocking claim if that format
does not meet their preferred, specific data transmission standard.
A few commenters requested that ONC remove the requirement that an
actor both ``identify'' and ``provide'' a reasonable alternative means
of accessing EHI, and instead require only that an actor ``identify'' a
reasonable alternative. One commenter requested that ONC clarify that
the proposed requirement to identify a reasonable alternative means of
accessing, exchanging, or using EHI is only necessary where any such
alternative exists. The commenter noted that there could be instances
in which no reasonable alternative exists, and the request is in effect
impossible to comply with. One commenter requested that ONC clarify
that, regarding the provision of a reasonable alternative, an actor
must only work with the requestor in a timely manner to identify and
provide a reasonable alternative means of accessing, exchanging, or
using the EHI as applicable. One commenter expressed concern that this
exception could be used to send patients to other sources to get their
health information because that approach would be less burdensome than
providing the information to the patient directly. The commenter
recommended that ONC
[[Page 25870]]
preclude the use of this exception for patient access requests.
Some provider, hospital, and clinical data registry commenters
expressed concern regarding the potential burden on the actor related
to identifying and providing a reasonable alternative means of
accessing, exchanging or using the EHI. Other commenters, primarily
health IT developers, expressed concern regarding the potential impact
and burden on health IT developers, HINs, and HIEs of complying with a
request to access, exchange, or use EHI, especially when the request
requires custom development. Commenters explained that if a system,
even a large system, were required to comply with many custom forms of
integration, collectively they would cause a significant burden to both
business and budget. Some commenters also noted that the proposed
exception seems imbalanced, favoring the requester of the EHI over the
actor providing the EHI.
Response. We appreciate the support for our proposal, as well as
the array of constructive comments. We first note that, in many
instances, the exceptions, including the finalized third condition of
this exception (Sec. 171.204(a)(3)), favor the request for EHI because
the overall information blocking paradigm is to eliminate interference
with access, exchange, and use of EHI. We have removed the ``reasonable
alternative'' requirement from this exception and instead have
finalized the new Content and Manner Exception in Sec. 171.301 that
establishes the content (i.e., the EHI) required in the response and
the manner in which the actor may respond to the request for access,
exchange, or use of EHI. This new exception improves on the
``reasonable alternative'' requirement in the Proposed Rule by
clarifying actors' obligations for providing access, exchange, or use
of EHI in all situations and creating actionable technical procedures.
We believe the Content and Manner Exception in Sec. 171.301 is
responsive to the above comments, will reduce burden on actors, and is
principled and tailored in a manner that will promote basic fairness
and encourage parties to work cooperatively to implement efficient
solutions to interoperability challenges. We refer readers to the
Content and Manner Exception and the discussion of such exception in
this preamble in sections VIII.C and VIII.D.2.a. With regard to the
comment suggesting that no reasonable alternative may exist, we believe
that the new exception will address this concern. However, if the actor
still could not meet the new exception, the actor could avail itself of
the third condition in this exception and demonstrate that the request
was infeasible under the circumstances.
e. Health IT Performance Exception--When will an actor's practice that
is implemented to maintain or improve health IT performance and that is
likely to interfere with the access, exchange, or use of electronic
health information not be considered information blocking?
We proposed to establish an exception to the information blocking
provision for certain practices that are reasonable and necessary to
maintain and improve the overall performance of health IT, provided
certain conditions are met (84 FR 7550). We stated in the Proposed Rule
that this exception would apply to the unavailability of health IT
occasioned by both planned and unplanned maintenance and improvement.
We noted that planned maintenance or improvements are often carried out
at regular intervals and address routine repairs, updates, or new
releases while unplanned maintenance or improvements typically respond
to urgent or time-sensitive issues. We proposed to codify the
exception's regulation text in Sec. 171.207 (84 FR 7605).
To ensure that the actor's practice of making health IT, and in
turn EHI, unavailable for the purpose of carrying out maintenance or
improvements is reasonable and necessary, we proposed conditions that
would need to be satisfied at all relevant times a practice to be
recognized as excepted from the definition of information blocking
under this proposed exception.
Comments. We received numerous comments supporting the
establishment of this exception. We did not receive comments opposing
the establishment of this exception. Many of the comments received
requested clarification or recommended revisions to specific points
within the proposed exception. The comments requesting clarification or
making recommendations are summarized below.
Response. We appreciate the feedback. We have established the
proposed exception with modifications from the regulation text proposed
in the Proposed Rule. We have retitled the exception from ``Exception--
Maintaining and improving health IT performance'' (proposed Sec.
171.207, at 84 FR 7605) to ``Health IT Performance Exception--When will
a practice that is implemented to maintain or improve health IT
performance and that is likely to interfere with the access, exchange,
or use of electronic health information not be considered information
blocking?'' (Sec. 171.205 as finalized). For ease of reference and
discussion, we use ``Health IT Performance Exception'' as a short title
for the finalized exception throughout this preamble. Unless we are
directly quoting the Proposed Rule or accurate re-statement of Proposed
Rule content requires otherwise, we use ``Health IT Performance
Exception'' in this section of this preamble when discussing this
exception as proposed as well as the finalized exception. As stated in
section VIII.D of this preamble (under the heading ``modifications''),
we changed the titles of all of the information blocking exceptions to
questions for additional clarity. We revised the wording of the
finalized Sec. 171.205 introductory text in comparison with that
proposed in Sec. 171.207 so that it is consistent with the finalized
title of the exception (and Sec. 171.205). Consistent with the
restructuring of part 171 that is also described in section VIII.D of
this preamble (under the heading ``modifications''), this exception has
been redesignated from Sec. 171.207 in the Proposed Rule (84 FR 7605)
to Sec. 171.205 as finalized. Commenters' requests for clarification
and suggested revisions on specific points are discussed below. Other
revisions we have made to the regulation text finalized in Sec.
171.205 in comparison to that proposed in Sec. 171.207 are also
discussed below.
Unavailability of Health IT Must Be for No Longer Than Necessary To
Achieve the Maintenance or Improvements for Which the Health IT Was
Made Unavailable
We proposed that any unavailability of health IT must be for a
period of time no longer than necessary to achieve the maintenance or
improvement purpose for which the health IT is made unavailable or its
performance degraded (84 FR 7550 and 7551). We provided as an
illustrative example that a health IT developer of certified health IT
that has the right under its contract with a large health system to
take its system offline for four hours each month to conduct routine
maintenance would not qualify for this exception if an information
blocking claim was made about a period of unavailability during which
no maintenance was performed.
Comments. We received comments from a variety of stakeholders on
the proposed requirement that any unavailability of health IT would
need to be for a period of time no longer than necessary to achieve the
maintenance or improvements for which the health IT was made
unavailable. Some commenters agreed that temporary unavailability of
health IT ``for a period
[[Page 25871]]
of time no longer than necessary'' created an appropriate standard for
both planned and unplanned downtimes. Other commenters indicated they
did not support this standard, stating concerns that the requirement
that the health IT be made unavailable ``for a period of time no longer
than necessary'' would be too difficult to assess without more specific
criteria such as defined time periods. Some commenters suggested we
modify our language to allow for greater flexibility in maintenance
downtime situations.
Response. We have finalized within the condition for maintenance
and improvements to health IT in Sec. 171.205(a)(1) the requirement
proposed in Sec. 171.201(a)(1), with modifications to the regulation
text that are described below (immediately preceding the preamble
discussion of the next subparagraph of Sec. 171.205(a)). When an actor
choosing to conform its practice to the health IT performance exception
implements a practice that makes health IT under that actor's control
temporarily unavailable, or temporarily degrades the performance of
health IT, in order to perform maintenance or improvements to the
health IT, the actor's practice must be (Sec. 171.205(a)(1))
implemented for a period of time no longer than necessary to complete
the maintenance or improvements for which the health IT was made
unavailable or the health IT's performance degraded. We believe that
establishing specific timeframes applicable to various maintenance and
improvement purposes would be impractical at this time due to the wide
variety of system architectures and operational contexts in which
health IT to which part 171 is applicable is currently, or may in the
future be, deployed. We have finalized the ``no longer than necessary''
requirement of this condition, which we believe provides substantial
flexibility to consider the particular circumstances of each case, and
a variety of factors including but not limited to the service level
agreements in place for the specific health IT at issue, the type of
maintenance or improvements, the technical resources available to the
actor, or best practices or other industry benchmarks relevant to the
particular maintenance or improvements.
Comments. Noting our use of the phrase ``as soon as possible'' in
the Proposed Rule's preamble discussion of this condition (84 FR 7551),
specifically in an example where an actor takes health IT offline in
response to a software failure, some commenters requested we clarify
how we interpret that phrase. A commenter described practices such as
procedures that phased restoration of full functionality across a
complex system, to manage system loads or confirm the original failure
is fully resolved, and asked if we would interpret this exception's
proposed conditions as excluding such procedures. Some comments from
members of the developer community suggested that we modify our
proposed language from ``for a period of time no longer than
necessary'' to ``a reasonable period of time.''
Response. The ``no longer than necessary'' standard provides actors
substantial flexibility to address the particular circumstances of each
case, allowing for consideration of a variety of factors including but
not limited to the service level agreements in place for the specific
health IT at issue, the type of maintenance or improvements, the
technical resources available to the actor, or best practices or other
industry benchmarks relevant to the particular maintenance or
improvements. In response to comments requesting we clarify how we
interpret ``as soon as possible'' and how it would apply to specific
types of practices, we first ask readers to note that in this final
rule preamble for the Health IT Performance Exception we use the phrase
``as soon as possible'' only in summarizing and responding to these
comments. We see how this phrase could be read as implying that we
might uniformly expect restarts in a shorter time or more abrupt manner
than might be consistent with best practices for ensuring the affected
component(s) or production environment are restored to stable, reliable
operating status. We do not, however, interpret the finalized condition
as uniformly mandating immediate full restarts of any or every system.
In determining whether an actor's practice made health IT under its
control unavailable, or degraded the health IT's performance, for
longer than was necessary in the particular circumstances, we would
consider a variety of factors such as (but not limited to) the service
level agreements in place for the specific health IT at issue, the type
of maintenance or improvements, the technical resources available to
the actor, or best practices or other industry benchmarks relevant to
the particular maintenance or improvements.
Comments. Several commenters recommended that this exception apply
to downtime necessary for testing whether a maintenance or improvement
activity, such as deploying a new or updated application into a
particular production environment for the first time, will operate in
that environment as it is intended to operate or without adversely
affecting other functions of the system.
Response. We interpret ``minimum time necessary'' to complete a
maintenance or improvement purpose, objective, or activity to include
reasonable and necessary practices, such as confirmatory testing and
phased restart protocols, to ensure that a newly deployed or newly
updated application functions in a particular production environment as
it is intended to perform and does not adversely affect system
stability or the performance of critical functions or components of
that system. In determining whether an actor's practice affected health
IT's availability or performance for longer than was necessary in the
particular circumstances, we reiterate that we would consider a variety
of factors such as (but not limited to) the service level agreements in
place for the specific health IT at issue, the type of maintenance or
improvements, the technical resources available to the actor, or best
practices or other industry benchmarks relevant to the particular
maintenance or improvements.
Comments. Some commenters recommended that we recognize there may
be circumstances where an instance of downtime may exceed service level
agreements but still be no longer than necessary to address the issue.
These commenters suggested such violations of service level agreements
and other provisions of contracts between the parties should remain to
be resolved through contractual mechanisms and not automatically
considered information blocking on basis of exceeding the terms of the
agreements. One commenter suggested actors who make their health IT
temporarily unavailable under this exception be held to industry
standards for necessary timeframes to complete any maintenance or
improvements.
Response. For purposes of determining whether a period of health IT
unavailability or performance degradation is (or was) no longer than
necessary to accomplish its purpose, we note that service level
agreements and industry practices would be relevant information to be
considered but not necessarily dispositive. For example, a period of
health IT unavailability or performance degradation could be within the
parameters of applicable service level agreements but still be longer
than necessary to accomplish the maintenance or improvement purpose for
the health IT was made unavailable or its performance degraded. For a
contrasting example, a period of health IT unavailability or
performance
[[Page 25872]]
degradation could be outside the parameters of applicable service level
agreements--a contractual matter for the parties to resolve through
other appropriate channels--without being ``longer than necessary'' in
the totality of applicable circumstances and, therefore, without
necessarily constituting information blocking as defined in Sec.
171.103.
Comments. Several commenters requested we clarify whether this
exception would apply to practices that degrade some aspects of a
health IT system's performance, without making it entirely unavailable,
for purposes of conducting maintenance and improvement of the health IT
system or some of its components.
Response. We appreciate the feedback. We agree that there may be
circumstances where the minimum disruption of an overall health IT
system's availability needed to accomplish particular maintenance or
improvement purposes may be less than total. We do not intend that this
exception would apply only to complete unavailability of health IT. We
intend the exception to apply to reasonable and necessary practices
that disrupt EHI access, exchange, or use not only for the shortest
time but also to the least extent practicable to accomplish their
specific maintenance or improvement purposes under the particular
circumstances. Accordingly, we have modified the language of Sec.
171.205(a)(1) as finalized to expressly include temporary performance
degradation as well as temporary unavailability of health IT affected
by maintenance and improvement practices.
Discussion of Finalized Text of Sec. 171.205(a)(1)
The regulation text finalized in Sec. 171.205(a)(1) has been
modified in comparison to the regulation text proposed in Sec.
171.207(a)(1) in several ways. The finalized regulation text expressly
includes ``or the health IT's performance degraded,'' for the reasons
stated in response to comments (above). In the text of this provision,
finalized at Sec. 171.205(a)(1), we have also replaced the verb ``to
achieve'' with the verb ``to complete.'' Reflecting on the comments
received, we have reviewed the dictionary definition of ``achieve'' and
now believe that our use of ``achieve'' in the regulation text proposed
in in Sec. 171.207(a)(1) may have contributed to commenters' concerns
about whether we would interpret time for confirmatory testing of
system performance or phased restart protocols as falling within the
``minimum time necessary'' for any particular maintenance or upgrade.
We believe ``complete'' less ambiguously expresses our intent that
this requirement of this condition encompasses the minimum time
necessary, in the totality of the particular circumstances, to fully
complete the maintenance or improvement activity, including any
confirmatory testing or other protocols necessary to ensure an orderly
and reliable restoration of normal operating status. We have also
revised the wording of Sec. 171.205(a) as finalized so that it is
consistent with the title and introductory text of Sec. 171.205 as
finalized.\182\ We made modifications to the titles and introductory
text of all of the finalized exceptions for reasons described in
section VIII.D of this preamble (under the heading ``modifications'').
As finalized, Sec. 171.205(a)(1) requires, in order to meet the
condition in Sec. 171.205(a), that when an actor implements a practice
that makes health IT under that actor's control temporarily
unavailable, or temporarily degrades the performance of health IT, in
order to perform maintenance or improvements to the health IT, the
actor's practice must be implemented for a period of time no longer
than necessary to complete the maintenance or improvements for which
the health IT was made unavailable or the health IT's performance
degraded.
---------------------------------------------------------------------------
\182\ As noted above in this section of this preamble, titles of
all the finalized exceptions have been revised to be more clear and
easy to understand.
---------------------------------------------------------------------------
Unavailability of Health IT for Maintenance or Improvements Must Be
Implemented in a Consistent and Non-Discriminatory Manner
We proposed (in proposed Sec. 171.207(a)(2)) that any
unavailability of health IT occasioned by the conduct of maintenance or
improvements must be implemented in a consistent and non-discriminatory
manner (84 FR 7551). We explained that this condition provides a basic
assurance that when health IT is made unavailable for the purpose of
performing maintenance or improvements the unavailability is not abused
by the actor that controls the health IT. However, we indicated that
this condition would not require that actors conduct all planned
maintenance or improvements simultaneously, or require that every
health IT contract provide the same promises in regard to planned
maintenance or improvements. We further noted that a recipient of
health IT could agree to a longer window for unavailability in exchange
for a reduced fee for system maintenance, which would not contravene
this condition of this exception.
Comments. Several commenters expressed support for requiring
practices be implemented in a non-discriminatory manner to meet the
conditions of the Health IT Performance Exception. One commenter
supported the requirement but stated that they believed practices
applied selectively against an actor or third-party application
inappropriately accessing interoperability resources should be exempt
from this condition.
Response. We appreciate the opportunity to clarify two points.
First, we want to reiterate that there is an important distinction
between conduct of individuals or entities (or the behavior of
applications) that poses a security risk and conduct or behavior that
may merely adversely affect performance of a health IT system or its
core functions. If an actor or an application is making or attempting
unauthorized access to systems or to EHI, the actor with control of the
system subject to that security risk should take prompt action to
address that risk. As stated in the finalized Sec. 171.205(d), the
Health IT Performance Exception expressly does not apply to security-
related practices. If the unavailability of health IT for maintenance
or improvements is initiated by an actor in response to a security risk
to electronic health information, the actor does not need to satisfy
the conditions of Sec. 171.205, but must comply with all applicable
conditions of Sec. 171.203 at all relevant times if they wish to seek
the added assurance of conforming their practices to an exception to
the information blocking provision. Second, we recognize there are
circumstances where an application's behavior does not pose a security
risk but does adversely impact the performance of a health IT system's
overall or core functions performance. We decline to modify Sec.
171.205(a)(2) in the manner the commenter recommended in order to
address adverse impacts on health IT performance. Instead, in response
to this and other comments, we have finalized in Sec. 171.205(b) an
alternative condition that expressly provides for the finalized Health
IT Performance Exception to apply to practices implemented to mitigate
a third-party application's negative impact on an actor's health IT's
performance.
[[Page 25873]]
Unavailability of Health IT for Maintenance or Improvements Must Be
Agreed
In order to benefit from this exception, we proposed that the
unavailability of health IT due to maintenance or improvements
initiated by a health IT developer of certified health IT, HIE, or HIN,
must be agreed to by the individual or entity to whom the health IT is
supplied (84 FR 7551). We noted that the availability of health IT is
typically addressed in a written contract or other written agreements,
that puts the recipient of the health IT on notice about the level of
EHI and health IT unavailability that can be expected for users of the
health IT. By such agreements, the recipient of the health IT willfully
agrees to that level of planned and unplanned unavailability (typically
referred to in health IT contracts as ``downtime''). We proposed that
in circumstances where health IT needs to be taken offline for
maintenance or improvements on an urgent basis and in a way that is not
expressly permitted under a health IT contract an actor could satisfy
the proposed condition so long as the maintenance or improvements are
agreed to by the recipient of the health IT. We proposed that this
could be achieved by way of an oral agreement such as reached between
the parties by telephone, but we noted that because an actor must
demonstrate that it satisfies the conditions of this exception, it
would be best practice for an actor to ensure the agreement was in
writing or, at minimum, contemporaneously documented.
We proposed that this condition would only apply when the
unavailability of health IT is caused by a health IT developer of
certified health IT, HIE, or HIN because it is the supplier of the
health IT and thus controls if and when health IT is intentionally
taken offline for maintenance or improvements. We proposed that this
condition would not apply when health IT is made unavailable for
maintenance or improvements at the initiative of a recipient (or
customer) of health IT, noting that when it is a customer of health IT
who initiates unavailability, the unavailability would not need to be
the subject of an agreement with the supplier of that health IT, nor
anyone else, in order for the customer of health IT to benefit from
this exception.
Comments. Several commenters from the provider community
recommended advance notice of downtime. Several commenters from the
provider community suggested that planned downtimes should be
documented, scheduled, and executed within a predefined window of time.
One commenter recommended that actors create a public website that
displays planned and unplanned system downtime and allow other actors
to subscribe to notifications of these downtimes. One commenter
suggested we explicitly prohibit an entity from regularly scheduling
extensive time periods where query and response services are
unavailable. Another commenter suggested we make allowances within the
conditions of this exception for an actor who may fall slightly out of
compliance with terms agreed to regarding downtime in a service level
agreement if the impact is de minimis and the actor was acting in good
faith. One commenter contended that the information blocking provisions
should not regulate the level of service provided by health IT
developers to their customers. We also received several comments from
members of the HIE and HIN community that recommended against any
requirement to include specific details such as dates and times for
maintenance because such a requirement could result in HIEs and HINs
having to undertake the process of amending thousands of legal
agreements.
Response. We do not believe it is necessary to dictate the
availability or health IT or other contractually defined details of the
business relationship between parties for the purposes of this
exception. Parties to a health IT contract can determine and
communicate their respective service level needs and capabilities or
commitments in legally enforceable contracts. Contractual provisions
can establish specific details of service levels, planned downtime,
unplanned downtime, and communications regarding planned and unplanned
downtime, that are practical and appropriate to the context of a
particular contract. In the event parties do not honor such contract
provisions, remedies are available to the parties outside and
independent of part 171. We also agree with commenters' observations
that any specific requirements, such as those recommended by some other
commenters, could require amending contracts in ways that could create
significant burden and costs for actors. Thus, we did not modify this
exception in response to commenters' recommendations that we require
service level or other contractual agreements between parties conform
to specific prescribed timeframes, scheduling (including specifically
or query and response services), notice, and scope of planned downtimes
expectations in order for maintenance and improvement health IT
downtimes to meet the information blocking exception for maintenance
and improvement. Similarly, we have not modified the exception in
response to recommendations from some commenters that we require
display of planned and unplanned downtime on publicly available
websites. We are not persuaded such measures would generally render
benefits commensurate with the time and effort that would be needed for
actors to implement and maintain them.
Comments. Two commenters disagreed with our proposed requirement
that temporary unavailability initiated by a health IT developer of
certified health IT, HIE, or HIN must be agreed to by the individual or
entity to whom the health IT developer of certified health IT, HIE, or
HIN supplied the health IT. Both commenters recommended removing the
``agreed upon with user'' provision we proposed and recommended that
ONC eliminate the requirement for prior agreement of planned downtime
in order to meet the conditions of this exception. These commenters
suggested that we instead allow for unilateral notice to organizations
at least 10 days prior to scheduled maintenance.
Response. We continue to believe that unplanned downtime must be
done with the agreement of the individual or entity to which the health
IT is supplied. This condition protects health care providers and other
uses or health IT under the specific circumstance of health IT being
made temporarily unavailable due to unplanned maintenance or
improvements. It also reduces the potential for downtime purportedly
for purposes of health IT maintenance or improvement to be a pretext
for information blocking and thus makes it less likely that this
exception will be abused. However, the conditions of this exception
finalized in Sec. 171.205 can be met by unplanned downtime in the
absence of contemporaneous agreement so long as it is consistent with
an existing service level agreement. We also note that specific
agreement by all users to temporary unavailability is not required in
all instances of unplanned downtime not already covered by an existing
service level or other contractual agreement, such as downtime
resulting from events beyond the actor's control that prevent it from
meeting the requirement, and practices that are consistent with the
conditions of the Preventing Harm Exception (Sec. 171.201),
[[Page 25874]]
Security Exception (Sec. 171.203), or Infeasibility Exception (Sec.
171.204).
Comments. Several commenters from the developer community expressed
appreciation for the opportunity to comment on throttling, arguing that
it is a reasonable approach to maintain access to functionality. Many
of these commenters stated that, when applied with the agreement of
health IT users, strategies such as throttling or metering certain
health IT functions should not be considered information blocking. One
commenter suggested that throttling should not be considered
information blocking if the health IT developer or health care provider
is forced to throttle access so as not to negatively impact hospital
operations. The commenter recommended that when requests for EHI from
third-party applications created an unreasonable and significant burden
on health IT and the installed infrastructure, the two contracting
parties could mutually agree that the third-party application was
poorly designed and could be throttled or even denied access. Another
commenter suggested that the practice of throttling should only occur
if that portion of the health IT affected by an application is
impacting highly critical functions such as inpatient or emergency
department care delivery and documentation. The commenter stated that
it was important to distinguish between the practice of throttling
generally and the practice of throttling as a response to impact on
critical functions because the practice of throttling generally could
be applied too broadly.
Response. We appreciate commenters' input. We recognize that in
some circumstances it may be appropriate for actors to take action
(e.g., deny access, throttle, or meter) to limit the negative impact on
the performance of health IT that may result from the technical design,
features, or behavior of a third-party application. This would include,
but not be limited to, third-party applications that a patient might
choose to use to access their EHI. The regulation text finalized in
Sec. 171.205 has been expanded, in comparison to the text proposed in
Sec. 171.207 (84 FR 7605), to include paragraph (b), which we have
titled ``assured level of performance.'' As finalized, Sec. 171.205(b)
establishes a condition expressly applicable to actions taken against a
third-party application that is negatively impacting the health IT's
performance. The specific requirements for action against a third-party
application to meet the condition finalized in Sec. 171.205(b) and
thus be excepted from the definition of information blocking parallel
the requirements finalized in Sec. 171.205(a), the condition
applicable to practices that make health IT temporarily unavailable, or
its performance degraded, for purposes of maintenance and improvement.
To meet the Health IT Performance Exception under the assured level
of performance condition, an action against a third-party application
(Sec. 171.205(b)) must be: (1) For a period of time no longer than
necessary to resolve any negative impacts; (2) implemented in a
consistent and non-discriminatory manner; and (3) consistent with
existing service level agreements, where applicable. For example, if
the service level agreement stated how and to what extent negative
impacts should be addressed (e.g., over-capacity), then it is expected
that such provisions of an existing service level agreement would be
followed unless they violated one of the other requirements of the
(Sec. 171.205(b)) assured level of performance condition (e.g.,
resulted in discriminatory application or lasted longer than necessary
to resolve the negative impacts). We believe this approach will help to
address situations where actions such as throttling become necessary to
protect the overall performance of health IT.
Interaction With the Preventing Harm and Security Exceptions
We proposed that when health IT is made unavailable for maintenance
or improvements aimed at preventing harm to a patient or other person,
or securing EHI, an actor must comply with the conditions specified in
the proposed Harm Exception or proposed Security Exception,
respectively, in order for these particular practices to be excepted
from the definition of information blocking in Sec. 171.103.
Comments. We received a few comments that expressed concern that
our maintenance exception, as proposed, did not address unplanned
downtime without notice in the instance of a potential threat to
security of EHI.
Response. Unplanned downtime or other practices reasonable and
necessary in response to exigent threats to EHI security should be
implemented consistent with the conditions for the Security Exception
as finalized in Sec. 171.203. We expressly stated in the proposed
regulation text at Sec. 171.207(c), and have finalized in Sec.
171.205(d), that if the unavailability of health IT for maintenance or
improvements is initiated by an actor in response to a security risk to
EHI, the actor does not need to satisfy the conditions of the Health IT
Performance Exception, but must comply with all conditions of Sec.
171.203 at all relevant times for such practices to be excepted from
the definition of information blocking in Sec. 171.103. We believe
this paragraph of the finalized Health IT Maintenance Exception's
regulation text (finalized in Sec. 171.205(d)) provides ample clarity
that this exception is not intended to apply to unplanned downtime
implemented specifically in response to emergent security threats. We
have finalized this approach to the relationship between the Health IT
Performance Exception and Security Exception as proposed, because we
continue to believe it ensures that the Health IT Performance Exception
cannot be used to avoid compliance with conditions applicable under the
Security Exception when the practice leading to unplanned downtime is
implemented specifically in response to a risk to security of EHI.
Comments. We received several comments from stakeholders in the
developer community that it would be impossible for certified health IT
developers, HIEs, or HINs to meet the conditions of this exception as
proposed in the event of downtime as a result of something like a
natural disaster because those parties would be unable to secure
agreement from entities and individuals prior to uncontrollable
downtime.
Response. The Infeasibility Exception finalized in Sec. 171.204
has been revised, in comparison to the proposed regulation text in the
Proposed Rule, to expressly address uncontrollable events. In cases of
natural or human-made disaster, public health emergency, public safety,
incident war, terrorist attack, civil insurrection, strike or other
labor unrest, telecommunication or internet service interruption, or
act of military, civil or regulatory authority, an actor can avail
itself of the Infeasibility Exception. We determined these situations
should be addressed in the Infeasibility Exception rather than the
Health IT Performance Exception in part because the breadth of
circumstances where access, exchange, or use of EHI may be interfered
with due to these uncontrollable events is more consistent with the
intent and function of the Infeasibility Exception. Thus, we have not
modified the Health IT Maintenance Exception (Sec. 171.205) to address
uncontrollable events of the type expressly addressed by the finalized
Infeasibility Exception (Sec. 171.204).
We have finalized the substance of the relationship between the
Health IT Maintenance Exception and the Preventing Harm and Security
Exceptions as proposed. We have also
[[Page 25875]]
finalized as proposed the provisions of the Health IT Maintenance
Exception specific to ``practices that prevent harm'' and ''security-
related practices,'' but have redesignated them within the structure of
the Health IT Maintenance Exception as finalized in Sec. 171.205 in
comparison to the structure proposed at Sec. 171.207 (84 FR 7605).
Specifically, the ``practices that prevent harm'' provision is
finalized in paragraph (c) of the finalized Health IT Maintenance
Exception in Sec. 171.205 instead of paragraph (b) as was the case in
the Proposed Rule (84 FR 7605). Likewise, the ``security-related
practices'' provision is finalized in paragraph (d) of the finalized
Health IT Maintenance Exception in Sec. 171.205 instead of paragraph
(c) as was the case in the Proposed Rule (84 FR 7605). Both of these
provisions were moved down to accommodate the addition of the ``assured
level of performance'' condition as paragraph (b) of Sec. 171.205 as
finalized.
The paragraph of the Health IT Maintenance Exception finalized in
Sec. 171.205(c), specific to ``practices that prevent harm,''
continues to provide that if the unavailability of health IT for
maintenance or improvements is initiated by an actor in response to a
risk of harm to a patient or another person, the actor does not need to
satisfy the requirements of this section, but must comply with all
conditions of Sec. 171.201 at all relevant times to qualify for an
exception. Likewise, the paragraph of the Health IT Maintenance
Exception finalized in Sec. 171.205(d), specific to ``security-related
practices,'' continues to provide that if the unavailability of health
IT for maintenance or improvements is initiated by an actor in response
to a security risk to electronic health information, the actor does not
need to satisfy the requirements of this section, but must comply with
all conditions of Sec. 171.203 at all relevant times to qualify for an
exception.
Request for Comment
We requested comments on the exception in general, and on whether
the proposed conditions would impose appropriate limitations on actor-
initiated health IT maintenance or improvement activities that lead to
temporary unavailability of EHI.
Comments. We did not receive comments generally opposed to the
establishment of this exception. One commenter recommended that if a
patient is affected by a practice that could be recognized under this
exception, such as unavailability of health IT for an app registration,
the patient should be provided an opportunity to access the EHI through
another means, such as the patient portal.
Response. The Health IT Performance Exception is applicable to a
variety of specific practices making health IT unavailable. It does not
recognize only downtime or performance degradation of an actor's entire
health IT system. An actor who takes down one means of EHI access to
conduct health IT maintenance or improvement could provide alternative
access to EHI, in circumstances where this may be practical, and remain
in compliance with the requirements for their practices to be excepted
under Sec. 171.205 from the definition of information blocking in
Sec. 171.103. However, we stress that an actor conducting maintenance
or improvement of health IT in the actor's control is not required to
provide an alternative electronic health information access mechanism
during the downtime in order for the Health IT Performance Exception to
apply to the actor's maintenance or improvement practices. We are aware
that actors' operational contexts and existing health IT capabilities
vary substantially throughout the health IT ecosystem. In a variety of
circumstances where downtime or performance degradation may be
reasonable and necessary to maintain or improve health IT performance,
an actor may not have the capability needed to meet a requirement that
EHI must always be immediately available in response to every patient
request. For example, in some circumstances it may be impossible to
achieve a particular maintenance or improvement purpose within a
specific system without temporarily rendering all EHI in the system
unavailable to all functions, services, and other components of the
system (such as APIs and portals) through which EHI is ordinarily
accessed, exchanged, or used.
2. Exceptions that involve procedures for fulfilling requests to
access, exchange, or use EHI
a. Content and Manner Exception--When will an actor's practice of
limiting the content of its response to or the manner in which it
fulfills a request to access, exchange, or use electronic health
information not be considered information blocking?
In this final rule, we have established a new exception in Sec.
171.301 (referred to as the Content and Manner Exception) under section
3022(a)(3) of the PHSA as a means to identify reasonable and necessary
activities that do not constitute information blocking. Although we did
not propose this exception in the Proposed Rule, it is related to our
proposals and requests for comment in the Proposed Rule regarding the
proposed EHI definition (84 FR 7513) and the proposed requirement to
identify and provide a reasonable alternative means for accessing,
exchanging, or using EHI as part of the proposed Infeasibility
Exception (84 FR 7544). We discuss below the connection between these
proposals and requests for comment in the Proposed Rule and the
conditions in the Content and Manner Exception.
We note that a failure to meet the Content and Manner Exception
does not mean that an actor's practice meets the information blocking
definition. However, as we noted in the Proposed Rule, the broad
definition of information blocking in the Cures Act means that any
practice that is likely to interfere with the access, exchange, or use
of EHI implicates the information blocking provision (see 84 FR 7515).
As a result, practices that do not meet the Content and Manner
Exception will have to be assessed on a case-by-case basis to
determine, for example, the actor's intent and whether the practice
rises to the level of an interference. We discuss the comments received
regarding the proposals related to the EHI definition (84 FR 7513) and
the requirement to identify and provide a reasonable alternative means
for accessing, exchanging, or using EHI under the Infeasibility
Exception (84 FR 7544) below.
Comments. As discussed in more detail section VIII.C.3, we received
many comments expressing concerns regarding the breadth of the proposed
EHI definition and requesting flexibility in the implementation of the
information blocking provision. Many commenters stated that it would be
difficult for actors to provide the full scope of EHI as it was
proposed to be defined, particularly as soon as the final rule was
published. Some commenters opined that we were trying to do too much
too fast. Commenters requested that we provide flexibility for actors
to adjust to the scope of the EHI definition, as well as the
exceptions. Commenters asserted that such an approach would permit them
to adapt their processes, technologies, and systems to enable the
access, exchange, and use of EHI as required by the Cures Act and this
final rule. Some commenters suggested that EHI under the information
blocking provision should be limited to ePHI as defined in 45 CFR
160.103, while others requested that ONC consider constraining the EHI
covered by the information blocking provision to only the data included
in the USCDI.
[[Page 25876]]
We also received a range of comments requesting clarification and
concerning improvements to our proposal in the Infeasibility Exception
that, for any request that the actor claims is infeasible, the actor
must work with the requesting party in a timely manner to identify and
provide a reasonable alternative means of accessing, exchanging, or
using the EHI, as applicable (proposed in Sec. 171.205(d), 84 FR
7604). Commenters, primarily provider organizations, were supportive of
the proposed condition. Some commenters requested clarification and
additional examples about what manner of response would constitute a
``reasonable alternative'' and when it would be acceptable to enable
requestors to access, exchange, or use EHI in an alternative manner.
One commenter requested that ONC place guardrails around requests for
information sharing, such that if an actor is able to share data in an
industry-accepted format, the requesting organization cannot make an
information blocking claim if that format does not meet the
organization's preferred, specific data transmission standard. One
commenter requested that ONC clarify that the proposed requirement to
identify a reasonable alternative means of accessing, exchanging, or
using EHI is only necessary where any such alternative exists. The
commenter noted that there could be instances in which no reasonable
alternative exists, and the request is in effect impossible to comply
with.
A few commenters requested that ONC remove the requirement that an
actor both ``identify'' and ``provide'' a reasonable alternative means
of accessing EHI, and instead require only that an actor ``identify'' a
reasonable alternative. One commenter expressed concern that this
exception could be used to send patients to other sources to get their
health information because that approach would be less burdensome than
providing the information to the patient in the manner requested. The
commenter recommended that ONC preclude the use of this exception for
patient access requests.
Some provider, hospital, and clinical data registry commenters
expressed concern regarding the potential burden on the actor related
to identifying and providing a reasonable alternative means of
accessing, exchanging or using the EHI. Other commenters, primarily
health IT developers, expressed concern regarding the potential impact
and burden on health IT developers, HINs, and HIEs of complying with a
request to access, exchange, or use EHI, especially when the request
requires custom development. Some commenters also noted that the
proposed exception seems imbalanced, favoring the requester of the EHI
over the actor providing the EHI.
Response. The Content and Manner Exception in Sec. 171.301
addresses the two groups of comments noted above: (1) Comments
expressing concerns regarding the breadth of the proposed EHI
definition (proposed in Sec. 171.102, 84 FR 7601) and requesting
flexibility in the implementation of the information blocking
provision; and (2) comments requesting clarification concerning and
improvement to our proposal in the Infeasibility Exception regarding
the provision of a reasonable alternative (proposed in Sec.
171.205(d), 84 FR 7604). In response to these comments, we have removed
the reasonable alternative provision from the Infeasibility Exception
and we have finalized the Content and Manner Exception in Sec. 171.301
which describes the content (i.e., the EHI) required to be provided in
an actor's response to a request to access, exchange, or use EHI and
the manner in which an actor must fulfill the request in order to
satisfy the exception. We believe this new exception will address the
broad range of comments we received about the content of an actor's
response to and manner for fulfilling a request to access, exchange, or
use EHI, and will provide the clarity and transparency sought by
commenters. We also believe, as discussed in more detail below, that
this new exception provides market participants the ability to reach
and maintain market negotiated terms for the access, exchange, and use
of EHI.
Content
The first condition of this exception (``content condition'') in
Sec. 171.301(a) establishes the content an actor must provide in
response to a request to access, exchange, or use EHI in order to meet
this exception. As discussed in section VIII.C.3 of this preamble, we
have focused the scope of the EHI definition in this final rule to ePHI
as defined in 45 CFR 160.103 to the extent that it would be included in
a designated record set as defined in 45 CFR 164.501, with limited
exception. We also address commenter concerns regarding the scope of
the EHI definition and the pace at which we are implementing the
information blocking provision through the Content and Manner
Exception. Specifically, section 171.301(a)(1) states that for up to
May 2, 2022, an actor must respond to a request to access, exchange, or
use EHI with, at a minimum, the EHI identified by the data elements
represented in the United States Core Data for Interoperability (USCDI)
standard adopted in Sec. 170.213. Section 171.301(a)(2) states that on
and after May 2, 2022, an actor must respond to a request to access,
exchange, or use EHI with EHI as defined in Sec. 171.102.
We explained in section VIII.C of this final rule that we have
finalized a new paragraph in the information blocking definition in
Sec. 171.103 that aligns with the content condition described above.
That new paragraph, which is finalized in Sec. 171.103(b), states
that, until May 2, 2022, EHI for purposes of part 171 is limited to the
EHI identified by the data elements represented in the USCDI standard
adopted in Sec. 170.213. We have included a detailed discussion in
section VIII.C of our rationale for including the content condition in
the Content and Manner Exception and for including paragraph (b) in
Sec. 171.103. That discussion includes an explanation of how those
provisions address the commenters' concerns detailed above. We refer
readers to the discussion in section VIII.C.
Manner
The second condition of this exception (``manner condition'') in
Sec. 171.301(b) establishes the manner in which an actor must fulfill
a request to access, exchange, or use EHI in order to meet this
exception. This condition is similar to our proposal in the
Infeasibility Exception in the Proposed Rule that, for any request the
actor claims is infeasible, the actor must have worked with the
requesting party in a timely manner to identify and provide a
reasonable alternative means of accessing, exchanging, or using the
EHI, as applicable (see proposed Sec. 171.205(d), 84 FR 7604). We
explained in the Proposed Rule that this proposed condition would
minimize the risk that the Infeasibility Exception could protect
improper refusals to enable access, exchange or use of EHI, including
discriminatory blanket refusals as well as other practices, such as
improper delays for access or exchange that would present information
blocking concerns (84 FR 7544).
After review of comments, further consideration of proposed
conditions, and taking into account the revised structure of the
exceptions, we determined that the concept of providing a ``reasonable
alternative'' fits better in the Content and Manner Exception than in
the Infeasibility Exception. As such, we removed the ``reasonable
alternative'' requirement from the Infeasibility Exception and
incorporated the general concept into
[[Page 25877]]
the Content and Manner Exception. We believe this approach improves on
the ``reasonable alternative'' requirement in the Proposed Rule by
clarifying actors' obligations for providing access, exchange, or use
of EHI in all situations; creating actionable technical procedures; and
aligning the requirement for providing an alternative with the Fees and
Licensing Exceptions.
Under Sec. 171.301(b)(1), an actor must fulfill a request
described in the content condition (paragraph (a) of the exception) in
any manner requested, unless the actor is technically unable to fulfill
the request or cannot reach agreeable terms with the requestor to
fulfill the request (Sec. 171.301(b)(1)(i)). If an actor fulfills a
request described in the content condition in any manner requested: (1)
Any fees charged by the actor in relation to its response are not
required to satisfy the Fees Exception in Sec. 171.302; and (2) any
license of interoperability elements granted by the actor in relation
to fulfilling the request is not required to satisfy the Licensing
Exception in Sec. 171.303 (Sec. 171.301(b)(1)(ii)).
Section 171.301(b)(2) provides requirements for fulfilling a
request to access, exchange, or use EHI in an alternative manner than
the manner requested. If an actor does not fulfill a request described
in the content condition of this exception in any manner requested
because it is technically unable to fulfill the request or cannot reach
agreeable terms with the requestor to fulfill the request, the actor
must fulfill the request in an alternative manner in order to satisfy
the exception. Section 171.301(b)(2)(i) states that the actor must
fulfill the request without unnecessary delay in the following order of
priority, starting with the first paragraph and only proceeding to the
next consecutive paragraph if the actor is technically unable to
fulfill the request in the manner identified in a paragraph. That order
of priority is as follows: (1) Using technology certified to
standard(s) adopted in part 170 that is specified by the requestor
(Sec. 171.301(b)(2)(i)(A)); (2) using content and transport standards
specified by the requestor and published by the Federal Government or a
standards developing organization accredited by the American National
Standards Institute (ANSI) \183\ (Sec. 171.301(b)(2)(i)(B)); and (3)
using an alternative machine-readable format, including the means to
interpret the EHI, agreed upon with the requestor (Sec.
171.301(b)(2)(i)(C)). Section 171.301(b)(2)(ii) requires that any fees
charged by the actor in relation to fulfilling the request must satisfy
the Fees Exception in Sec. 171.302. Similarly, Sec.
171.301(b)(2)(iii) requires that any license of interoperability
elements granted by the actor in relation to fulfilling the request is
required to satisfy the Licensing Exception in Sec. 171.303.
---------------------------------------------------------------------------
\183\ See https://www.ansi.org/.
---------------------------------------------------------------------------
We chose this approach because we believe actors should, first and
foremost, attempt to fulfill requests to access, exchange, or use EHI
in the manner requested. This principle is central to our information
blocking policies (e.g., it was part of the proposed Infeasibility
Exception) and will help ensure that EHI is made available where and
when it is needed. Our approach acknowledges, however, that there may
be instances when an actor should not be required to respond in the
manner requested.
First, if an actor is technically unable to fulfill a request to
access, exchange, or use EHI in the manner requested, the actor is
allowed to fulfill the request in an alternative manner (Sec.
171.301(b)(1)(i)). We emphasize that we use ``technically unable'' in
this context to mean that actors cannot fulfill a request to access,
exchange, or use EHI due to technical limitation. For example, if an
individual requested their EHI via an API and the actor could not
fulfill the request via the API, but the individual then requested the
EHI be provided via email and the actor was technically able to do so,
we expect that the actor would fulfill the request in that ``manner
requested.'' This standard sets a very high bar, and would not be met
if the actor is technically able to fulfill the request, but chooses
not to fulfill the request in the manner requested due to cost, burden,
or similar justifications. If, for instance, under the alternative
manner, fulfilling the request would prove costly for the actor, the
actor would be able to charge a fee that results in a reasonable profit
margin under the Fees Exception in Sec. 171.302 or license any
requisite interoperability elements and make reasonable royalties under
the Licensing Exception in Sec. 171.303. If the burden on the actor
for fulfilling the request is so significant that the actor chooses not
to fulfill the request at all, the actor could seek coverage under the
Infeasibility Exception in Sec. 171.204. We believe this framework for
utilizing this exception, which works in harmony with the Infeasibility
Exception (Sec. 171.204), Fees Exception (Sec. 171.302), and
Licensing Exception (Sec. 171.303), is principled and tailored in a
manner that will promote basic fairness and encourage parties to work
cooperatively to implement efficient solutions to interoperability
challenges.
Second, we establish that an actor is not required to fulfill a
request to access, exchange, or use EHI in the manner requested if the
actor cannot reach agreeable terms with the requestor to fulfill the
request (Sec. 171.301(b)(1)(i)). We also establish that if an actor
fulfills a request to access, exchange, or use EHI in any manner
requested, the fees or licenses associated with fulfilling such
requests will not be limited by the conditions in the Fees Exception or
Licensing Exception. These provisions will allow actors to first
attempt to negotiate agreements in any manner requested with whatever
terms the actor chooses and at the ``market'' rate--which supports
innovation and competition. We then allow flexibility for actors to
still satisfy the exception by fulfilling the request in an alternative
manner if the actor cannot reach agreeable terms with the requestor to
fulfill the request. For instance, under the exception, actors who
cannot reach agreeable terms with the requestor to fulfill the request
are not required to license their IP to proprietary technology in order
to satisfy the exception.
In contrast, Sec. 171.301(b)(2)(ii) and (iii) require that any
fees charged or licenses granted by the actor in relation to fulfilling
a request to access, exchange, or use EHI in an alternative manner must
satisfy the Fees Exception in Sec. 171.302 and the Licensing Exception
in Sec. 171.303. We recognize that it is possible that responding in
an alternative manner may require licensing of interoperability
elements. However, we do not believe that, in most cases, licensing
certified technology (Sec. 171.301(b)(2)(i)(A)) or standards-based
technology (Sec. 171.301(b)(2)(i)(B)) would involve the type of
licensing of proprietary interoperability elements that concerned the
majority of commenters because the standards in Sec.
171.301(b)(2)(i)(a) and (B) are ``open'' standards. Therefore, it is
our understanding that a health IT developer of certified health IT
would not normally be required to license its IP in order to meet the
requirements for fulfilling a request to access, exchange, or use EHI
in those alternative manners. On the other hand, the technology/
software that the developer uses to fulfill a request in any manner
requested could constitute the developer's IP, depending on the
request. We emphasize that this exception does not require developers
to open-source their technology/software.
For instance, if a health IT developer of certified health IT
enables access to
[[Page 25878]]
EHI using HL7 (which is an ANSI-accredited standards developing
organization) FHIR Release 2 (R2) Standard, that means the developer
will provide EHI in the format specified in FHIR R2. In this example,
the actual software code that is used by the developer to convert the
EHI from the developer's proprietary format to FHIR R2 is the
developer's IP and is not required to be provided to the requestor. We
also note that our experience and knowledge of the health IT landscape
indicate that the market is increasingly moving toward open standards,
and we believe this movement will further decrease the need to license
IP in the future. We believe this framework and approach are supportive
of innovation and address commenter concerns regarding their ability to
protect their IP.
We included in Sec. 171.301(b)(2)(i) that an actor must fulfill
the request without unnecessary delay in order to make clear that
actors seeking coverage under this exception by responding in an
alternative manner will be held to same unnecessary delay or
``timeliness'' considerations as all actors are in determining whether
there is an interference under the information blocking provision. The
fact that an actor responds in an alternative manner does not entitle
that actor to any additional time to respond to a request to access,
exchange, or use of EHI that the actor would not be afforded if
responding in any manner requested. As such, any unnecessary delays
related to responding in an alternative manner could disqualify an
actor from meeting the alternative manner condition in the same way
that an unnecessary delay in responding to a request to access,
exchange, or use EHI in any manner requested could constitute an
interference. We refer readers to the discussion of ``Limiting or
Restricting the Interoperability of Health IT'' in section
VIII.C.6.c.ii.
Under Sec. 171.301(b)(2)(i)(A), if an actor does not fulfill a
request described in the content condition of this exception in any
manner requested because it is technically unable to fulfill the
request or cannot reach agreeable terms with the requestor to fulfill
the request, the actor must fulfill the request in an alternative
manner. Specifically, the actor must attempt to fulfill the request
using technology certified to standards adopted in part 170 specified
by the requestor. This manner of response is given precedence because
it advances a certified, standards-based approach that supports the
Promoting Interoperability Programs (previously Medicare and Medicaid
EHR Incentive Programs) administered by the Centers for Medicare &
Medicaid Services (CMS), other Federal and State programs that use
certified health IT, and other Federal Departments (Department of
Defense and Veterans Affairs). In addition, the certification criteria
under the ONC Health IT Certification Program (the Program) include
robust oversight, including technical and interoperability
requirements, ONC-Authorized Certification Body (ONC-ACB) in-the-field
surveillance expectations, and cost transparency and other disclosure
requirements. To illustrate how this would work, if the requestor only
requests the EHI using the C-CDA 2.1 content standard, then the actor
would not have to also use the Direct transport standard to provide the
EHI. However, if the requestor requests the EHI through the use of both
standards, then the actor would be expected to respond in such a manner
if the actor has certified health IT that supports both standards.
If the actor is technically unable to respond using technology
certified to standards adopted in part 170 specified by the requestor,
then the actor may respond using content and transport standards
specified by the requestor and published by the Federal Government or a
standards developing organization accredited by the ANSI (Sec.
171.301(b)(2)(i)(B)). We chose to specify that standards published by a
standards developing organization accredited by ANSI would qualify for
this manner of response because ANSI oversees the development of
voluntary consensus standards in the United States and it accredits
standards that are developed by representatives of other standards
organizations. ANSI accreditation signifies that the procedures used by
standards developing organizations meet the institute's requirements
for openness, balance, consensus, and due process. Voluntary consensus
standards developed by an ANSI-accredited standards developing
organization carry a high degree of acceptance both in United States
and internationally. ANSI has broad membership across government
agencies, industry, academia, and international bodies and is the
official United States representative to the International Organization
of Standards (ISO). This manner of response also advances
interoperability through standards-based exchange, even if the standard
is not certified under the Program.
As noted above, the ``manner'' of response specific in Sec.
171.301(b)(2)(i)(B) includes two distinct components: (1) Content
standard; and (2) transport standard. The content standard deals with
whether the information is in an appropriate format and is universally
understood. This standard includes the structure (i.e., syntax) and
terminology (i.e., semantics) of the EHI. Examples of content standards
include: US Fast Healthcare Interoperability Resources (FHIR) Core IG;
Consolidated Clinical Document Architecture (C-CDA 2.1); HL7 V2.5.1;
HL7 v2.7 (which is a standard that is not part of certification from an
ANSI-accredited standards developing organization); and Argonaut Data
Query Implementation Guide. The transport standard is the method to
connect two or more parties without a focus on the data that is
transported from one party to another. Put another way, the transport
standard is the method by which information moves from one point to
another. Examples of transport standards include: Direct Project
Standard, ONC Applicability Statement for Secure Health Transport,
Version 1.0 (incorporated by reference in Sec. 170.299) (Sec.
170.202(a)); and Simple Object Access Protocol (SOAP) based exchange
specifications such as ``Nationwide Health Information Network
Messaging Platform Specification.'' \184\ Under the manner condition,
an actor could proceed to the next consecutive ``manner'' under Sec.
171.301(b)(2)(i) if the actor was technically unable to respond with
either the content standard or the transport standard requested.
---------------------------------------------------------------------------
\184\ See ONC, Connecting Health and Care for the Nation, A
Shared Nationwide Interoperability Roadmap, FINAL Version 1.0,
https://www.healthit.gov/sites/default/files/hie-interoperability/nationwide-interoperability-roadmap-final-version-1.0.pdf; ONC, 2015
Interoperability Standards Advisory, https://www.healthit.gov/isa/sites/default/files/2015interoperabilitystandardsadvisory01232015final_for_public_comment.pdf.
---------------------------------------------------------------------------
Last, if an actor is technically unable to fulfill a request for
access, exchange, or use of EHI using a content and transport standard
specified by the requestor and published by the Federal Government or a
standards developing organization accredited by ANSI, only then can the
actor respond using an alternative machine-readable format, including
the means to interpret the EHI, agreed to by the actor and requestor
(Sec. 171.301(b)(2)(i)(C)). This option to respond using an agreed
upon alternative machine-readable format is a flexible option for
actors who cannot meet the ``manner'' requirements in Sec.
171.301(b)(2)(i)(A) and (B), but still want to be responsive to the
requestor and seek coverage under this exception. Examples of
alternative machine readable formats include CSV, public domain
standards, public advisory
[[Page 25879]]
standards, and other community efforts used to represent the data.
We emphasize two key components of Sec. 171.301(b)(2)(i)(C).
First, the alternative machine-readable format must include the means
to interpret the EHI. The goal with this requirement is to ensure that,
if an actor fulfills a request for access, exchange, or use of EHI
using an alternative machine-readable format, the EHI provided through
that format will be usable by the requestor. As an example, the format
used for the EHI Export functionality (Sec. 170.315(b)(10)) discussed
earlier in this final rule could be used to fulfill such a request.
Second, the alternative machine-readable format must be agreed upon
with the requestor. This condition ensures that, even if the actor is
technically unable to meet the requirements in Sec.
171.301(b)(2)(i)(A) and (B), the actor is still providing the requestor
the opportunity to access, exchange, or use the EHI in a manner that is
amenable to the requestor.
b. Fees Exception--When will an actor's practice of charging fees for
accessing, exchanging, or using electronic health information not be
considered information blocking?
We proposed in the Proposed Rule to establish an exception at Sec.
171.204 (84 FR 7589) to the information blocking provision that would
permit the recovery of certain costs reasonably incurred for the
access, exchange, or use of EHI. We interpreted the definition of
information blocking to include any fee that is likely to interfere
with the access, exchange, or use of EHI. We noted that this
interpretation may be broader than necessary to address genuine
information blocking concerns and could have unintended consequences on
innovation and competition. Specifically, unless we establish an
exception, actors may be unable to recover costs that they reasonably
incur to develop technologies and provide services that enhance
interoperability. This could undermine the ultimate goals of the
information blocking provision by diminishing incentives to invest in,
develop, and disseminate interoperable technologies and services that
enable more robust access, exchange, and use of EHI. Therefore, we
proposed to establish an exception that would permit the recovery of
certain costs that we believe are unlikely to present information
blocking concerns and would generally promote innovation, competition,
and consumer welfare, provided certain conditions are met. We
emphasized that actors can make a reasonable profit under this
exception, provided that all applicable conditions are met (84 FR 7538
through 7541).
We proposed that the exception would be subject to strict
conditions to prevent its potential abuse. Specifically, we explained
our concern that a broad or insufficiently tailored exception for the
recovery of costs could protect rent-seeking, opportunistic fees, and
exclusionary practices that interfere with the access, exchange, and
use of EHI. We explained that these practices fall within the
definition of information blocking and reflect some of the most serious
concerns that motivated its enactment (see 84 FR 7538 and section
VIII.B of this preamble). For example, in the Information Blocking
Congressional Report,\185\ we cited evidence of wide variation in fees
charged for health IT products and services. While we cautioned that
the issue of fees is nuanced, and that variations in fees could be
attributable in part to different technology architectures, service
models, capabilities, service levels, and other factors, we concluded
that these factors alone could not adequately explain all of the
variation in prices that we had observed. Based on these and other
indications, we concluded that some actors were engaging in
opportunistic pricing practices or, in some cases, charging prices
designed to deter connectivity or exchange with competing technologies
or services. In the time since we published the Information Blocking
Congressional Report, these practices have persisted and, in certain
respects, become more pronounced. In a national survey of HIE
executives published in 2017, 47 percent of respondents reported that
EHR developers ``often/routinely'' charge high fees for exchange that
are unrelated to cost, and another 40 percent reported that they
``sometimes'' do.\186\ Meanwhile, we have continued to receive credible
evidence of rent-seeking and other opportunistic behaviors, such as
fees for data export and data portability that are not plausibly
related to any time, materials, or other costs that a developer would
reasonably incur to provide these services. And, while some practices
described in the Information Blocking Congressional Report have become
less prevalent (such as the charging of per-transaction fees), other
practices have emerged that are equally concerning (84 FR 7538).
---------------------------------------------------------------------------
\185\ ONC, Information Blocking Congressional Report (April
2015), https://www.healthit.gov/sites/default/files/reports/info_blocking_040915.pdf.
\186\ Julia Adler-Milstein and Eric Pfeifer, Information
Blocking: Is It Occurring And What Policy Strategies Can Address
It?, 95 Milbank Quarterly 117, 124-25 (Mar. 2017), available at
http://onlinelibrary.wiley.com/doi/10.1111/1468-0009.12247/full.
---------------------------------------------------------------------------
As just one illustration, some EHR developers have begun
conditioning access or use of customer EHI on revenue-sharing or
royalty agreements that bear no plausible relation to the costs
incurred by the EHR developer to grant access to the EHI. We have also
heard of discriminatory pricing policies that have the obvious purpose
and effect of excluding competitors from the use of interoperability
elements. Many of the industry stakeholders who shared their
perspectives with us in listening sessions prior to the Proposed Rule,
including several health IT developers of certified health IT,
condemned these practices and urged us to swiftly address them (84 FR
7538).
In light of these concerns, we proposed that this exception would
apply only to the recovery of certain costs and only when the actor's
methods for recovering such costs comply with certain conditions at all
relevant times. In general, these conditions would require that the
costs the actor recovered were reasonably incurred, did not reflect
costs that are speculative or subjective, were appropriately allocated,
and based on objective and verifiable criteria. Further, the exception
would not apply to certain fees, such as those based on the profit or
revenue associated with the use of EHI (either being earned by the
actor, or that could be realized by another individual or entity) that
exceed the actor's reasonable costs for providing access, exchange, or
use of the EHI (84 FR 7539 through 7541).
Finally, the exception would provide additional conditions
applicable to fees charged in connection with: (1) The certified APIs
described in Sec. 170.404 (84 FR 7594); and (2) the EHI export
criterion proposed in Sec. 170.315(b)(10) (84 FR 7590) to support
single patient EHI export and to support the export of all EHI when a
health care provider chooses to migrate information to another health
IT system. We emphasized that access to EHI that is provisioned by
supplying some form of physical media, such as paper copies (where the
EHI is printed out), or where EHI is copied onto a CD or flash-drive,
would not be a practice that implicated the information blocking
provision provided that the fee(s) charged for that access complied
with the HIPAA Privacy Rule (45 CFR 164.524(c)(4)) (84 FR 7539).
Clarification
We clarify that the Fees Exception we have finalized in this rule
in no way supports or encourages the sale of EHI.
[[Page 25880]]
We emphasize that this exception permits the recovery of certain costs
reasonably incurred for the access, exchange, or use of EHI. We note
that many individuals and entities who are considered ``actors'' under
the information blocking provision are also subject to the HIPAA
Privacy Rule and therefore prohibited from selling PHI unless certain
conditions are met, and in particular, receiving remuneration for a
disclosure of PHI in accordance with 45 CFR 164.502(a)(5)(ii). This
exception to the information blocking definition in no way affects
existing HIPAA Privacy Rule compliance responsibilities of entities
subject to the HIPAA Rules.
Comments. We received many comments in general support of the
proposed exception. Commenters appreciated ONC's goal of addressing
rent-seeking, opportunistic fees, and exclusionary practices that
interfere with the access, exchange, and use of EHI. Some commenters
suggested that ONC should take additional steps and measures to ensure
that the requirements under this exception are clear. A couple of
commenters recommended that fees and costs of information exchange
should be made publicly available. Another commenter suggested that ONC
develop a process for actors to routinely report their use of this
exception, including specific timeframes for actors to submit
information to ONC and for ONC to determine whether the exception can
be applied under specific circumstances.
Response. We thank commenters for their support of and feedback on
this exception. We appreciate the suggestions for improved transparency
under this exception. We believe actors should have discretion to
decide if they would like to enhance transparency by making fees and
costs of information exchange publicly available. We believe that
choosing not to disclose fees, on its own, would not likely implicate
the information blocking provision. Further, while we wholeheartedly
support the goal of enhanced transparency and commend commenters'
desire to enhance transparency in the final rule, we believe their
suggestions could create additional burden for actors and such burden
could outweigh the benefits of the measures they suggest. We will
continue to consider steps to further promote transparency regarding
our information blocking policies in future rulemakings.
We appreciate the comment that we should develop a process for
letting actors know whether this exception could be applied under
certain circumstances. We may consider developing materials in the
future regarding the application of the exceptions should the need
arise. However, we believe the final rule clearly describes the
conditions actors must meet in order to be covered by each exception,
and informational materials are not necessary at this time.
Requirement That Costs Be Reasonably Incurred
In the Proposed Rule, we stated that, regardless of the type of
cost at issue, a basic condition of the proposed exception was that any
costs the actor seeks to recover must have been reasonably incurred to
provide the relevant interoperability elements for the access,
exchange, or use of EHI. Whether a cost was reasonably incurred will
ultimately depend on the particular facts and circumstances. We
requested comment on considerations that may be relevant to assessing
the reasonableness of costs incurred for purposes of this exception (84
FR 7539).
Comments. Several commenters requested additional clarity in the
final rule regarding various terms and concepts in the proposed
exception. Commenters noted that many terms and concepts regarding the
reasonableness of fees, and which fees would or would not be considered
``reasonably incurred'' under the exception, were ambiguous and overly
broad. Some commenters were concerned that such ambiguity and vagueness
could undercut ONC's overall intent to prevent rent-seeking and
opportunistic fees and could create a loophole that would enable actors
to use the exception to continue to charge unreasonably high fees. Some
commenters requested additional examples of ``costs reasonably
incurred'' under the exception. One commenter asked that ONC outline
different cost categories (such as development costs, deployment costs,
usage costs) and indicate which of those costs would or would not fall
under the exception. A couple of commenters requested that ONC
explicitly state that fees the actor pays to a developer for ``Release
of Information'' (ROI) services and technology would be considered
``costs reasonably incurred.''
Response. We appreciate these comments. Actors may choose to
satisfy the conditions of this exception to be certain that the fees
they charge for the access, exchange, or use of EHI do not implicate
the information blocking provision. We reiterate that failure to meet
the exception does not mean that an actor's practice related to
charging fees meets the information blocking definition. However, as we
explained in the Proposed Rule, we interpret the broad definition of
information blocking in section 3022(a) of the PHSA to encompass any
fee that is likely to interfere with the access, exchange, or use of
EHI (84 FR 7521). Fees that do not meet this exception may implicate
the information blocking provision and will have to be assessed on a
case-by-case basis to determine, for example, the actor's intent and
whether the practice rises to the level of an interference. Consistent
with the conditions of this exception, an actor seeking the significant
protection afforded by this exception will have to assess the fees they
charge in light of the costs incurred.
We emphasize that our intention with this exception is not to set
any particular fees related to products or services for accessing,
exchanging, or using EHI, but rather to allow the market to define the
appropriate price for such products or services so long as certain
methods are followed and certain criteria are met. We believe this
approach is appropriate for this exception in light of the considerable
diversity in the types of costs actors might incur and the range of
factors that could bear on the reasonableness of those costs. For
example, the costs of developing software may vary with the purposes it
is intended to serve, the settings in which it will be deployed, the
types and scope of capabilities included, and the extent to which these
development efforts build on existing development efforts and know-how.
Additionally, the costs of providing services, including the
implementation of technology in production environments, may vary based
on the technology design or architecture, individual customer needs,
local implementation conditions, and other factors. An analysis of the
approach for recovering costs will also account for different
distribution and service models under which the costs are calculated.
For these reasons, we have decided not to specify cost categories, such
as development costs, deployment costs, usage costs, or ROI services
and technology costs. However, we note that if an actor meets all
necessary conditions of the finalized exception, the actor could
recover such categories of cost under the exception.
We have taken a few distinct steps to clarify this exception and
address the overall concern from commenters regarding the clarity of
this exception. First, we have restructured the exception for clarity.
We have changed the title of the exception from ``Exception--Recovering
costs reasonably incurred'' to ``When will an actor's practice of
charging fees for
[[Page 25881]]
accessing, exchanging, or using electronic health information not be
considered information blocking?'' Throughout this final rule preamble,
we use ``Fees Exception'' as a short form of this title, for ease of
reference. As stated in Section VIII.D of this final rule preamble, we
have changed the titles of all of the exceptions to questions to
improve clarity. We have also edited the wording of the introductory
text in Sec. 171.302, in comparison to that proposed (84 FR 7603), so
that it is consistent with the finalized title in Sec. 171.302. We
believe these conforming changes in wording of the introductory text
also improve clarity in this section.
We have also divided the exception into three conditions in Sec.
171.302--(a) Basis for fees condition; (b) Excluded fees condition; and
(c) Compliance with the Conditions of Certification condition. We
explain upfront in the introductory sentence of the exception that,
pursuant to these conditions, an actor may charge fees, including fees
that result in a reasonable profit margin, for the access, exchange, or
use of EHI without implicating the information blocking provision. We
believe this framework provides actors with a clear roadmap for
voluntarily satisfying the conditions of the exception. We discuss the
substantive changes we have made to these provisions in the discussion
of each condition later in this section of the preamble.
We also note that we have further clarified the fees allowed under
this exception by focusing the scope of the EHI definition (discussed
in section VIII.C.3 of this preamble) and adding paragraph (b) to the
information blocking definition in Sec. 171.103 (discussed in section
VIII.C of this preamble). By changing the definition of EHI to
electronic protected health information (ePHI) as defined in 45 CFR
160.103 included in a designated record set as defined in 45 CFR
164.501, we have focused the scope of information covered by the
information blocking provision. In addition, under the finalized
information blocking definition, for up to 18 months after the six-
month delayed compliance date of the information blocking section of
this final rule (part 171) (a total of 24 months after the publication
date of this final rule), EHI for purposes of the information blocking
definition is limited to the EHI identified by the data elements
represented in the USCDI standard adopted in Sec. 170.213 (see (Sec.
171.103(b)).
Basis for Fees Condition
To qualify for this exception, we proposed that the method by which
the actor seeks to recover its costs must meet certain conditions. We
proposed that this would require that the actor base its recovery of
costs on objective and verifiable criteria that are uniformly applied
for all substantially similar or similarly situated classes of persons
and requests. We proposed that any differences in prices or price terms
would have to be based on actual differences in the costs that the
actor incurred or other reasonable and non-discriminatory criteria. We
further proposed to require that the method by which the actor recovers
its costs must be reasonably related to the actor's costs of providing
the type of access, exchange, or use to, or at the request of, the
person or entity to whom the fee is charged (84 FR 7539).
We also proposed that the costs must be reasonably allocated among
all customers to whom the technology or service is supplied, or for
whom the technology is supported. A reasonable allocation of costs
would require that the actor allocate its costs in accordance with
criteria that are reasonable and between only those customers that
either cause the costs to be incurred or benefit from the associated
supply or support of the technology (84 FR 7539).
We proposed that the exception would not apply if the method by
which the actor recovers its costs is based, in any part, on whether
the requestor or other person is a competitor, potential competitor, or
will be using the EHI in a way that facilitates competition with the
actor. The use of such criteria would be suspect because it suggests
the fee the actor is charging is not based on its reasonable costs to
provide the services and may have the purpose or effect of excluding or
creating impediments for competitors, business rivals, or other persons
engaged in developing or enabling the use of interoperable technologies
and services (84 FR 7539).
Last, we stated that the method by which the actor recovers its
costs must not be based on the sales, profit, revenue, or other value
that the requestor or other persons derive or may derive from the
access to, exchange of, or use of EHI, including the secondary use of
such information, that exceeds the actor's reasonable costs for the
access, exchange, or use of EHI (84 FR 7539).
We requested comment on the proposed conditions and other issues we
should consider in assessing whether the methodology by which an actor
distributes costs and charges fees should be considered reasonable and
necessary for purposes of the exception. In particular, we noted that
we were considering whether to introduce specific factors and methods
for assessing when profit will be reasonable. We requested comment on
whether the pro-competitive or efficiency-adding aspect of an actor's
approach to providing access, exchange, or use of EHI should be taken
into account when assessing the reasonableness of profits. We asked
commenters to consider whether there are specific use cases for which
actors' profits should be limited or prohibited for purposes of meeting
the exception (84 FR 7539).
We also asked commenters to consider alternate approaches to the
exception that would also achieve the goal of allowing actors to
recover certain types of costs that would promote innovation,
competition and consumer welfare and that are unlikely to present
information blocking concerns. In assessing other potential approaches
to this exception, we encouraged commenters to contemplate such
considerations as enforceability, potential burden on the parties, and
overall effectiveness in meeting the above stated goals (84 FR 7539).
Comments. We received several comments regarding our proposed
approach for cost recovery and profits. Some commenters supported our
proposed approach. A couple of commenters recommended that we prohibit
all profits under the exception to ensure that actors cannot continue
rent-seeking and exclusionary pricing practices. Several commenters
requested clarification regarding the profits that would be allowed
under the exception and expressed concern that the regulation text does
not clearly state that profits are allowed under the exception. Several
other commenters, primarily health IT developers, disagreed with the
proposed cost recovery approach and limits on profits, expressing
concern that ONC's proposals will serve as a barrier to innovation,
competition, and interoperability. Some commenters stated that ONC's
proposals regarding fees and profits go beyond the congressional intent
in the Cures Act and questioned whether ONC has regulatory authority to
regulate costs and profits.
We received some comments that recommended we take a different
approach for assessing whether an actor's costs recovered are
reasonable. Commenters recommended using an approach that
distinguishes, as appropriate, between: (1) Pure cost or expense
recovery, with no provision for margin or profit; (2) ``cost-based
pricing'' or ``cost plus accounting,'' where margin or profit is
allowed; and (3) ``market-based pricing,'' where there
[[Page 25882]]
are no restrictions on pricing. A couple of commenters recommended that
where a cost-based pricing mechanism is required, the method for
assessing the cost basis should be reasonably associated with the
complexity or cost of providing the capabilities. Such methods could
include reasonable heuristics, estimates, or other commonly used
methods.
Commenters recommended that we distinguish ``basic access'' (with
no profits or limited profits) from ``value-added'' access, exchange,
or use (which would allow for increased profits). A couple of
commenters recommended that allowed fees for ``basic access'' be on a
pure direct cost recovery basis only. Those commenters recommended that
the cost to develop and/or map to standards should not be part of the
cost basis for fees for ``basic access;'' rather any such costs should
be a part of the fees for the health IT. The commenters recommended
that when the outputs of value-added services are incorporated into, or
from, an essential part of the legal medical record, or are routinely
used for decision making, they constitute part of the set to which
basic access is required. The commenters also recommended that we
distinguish between intellectual property (IP) rights that are
essential to access EHI and IP rights that allow for value-added
services.
Response. We thank commenters for their support of our proposals
and for the thoughtful comments on this aspect of the exception. We
appreciate that commenters were concerned both about the elimination of
rent-seeking, opportunistic fees, and exclusionary pricing practices
that interfere with the access, exchange, and use of EHI as well as the
importance of finalizing policies that support and promote innovation.
We have finalized the proposed approach for determining whether the
basis for fees charged is acceptable under this exception, with some
clarifications and updates detailed below.
As we discussed in the Proposed Rule, we believe our approach will
provide actors that seek to meet this exception certainty that charging
fees to recover certain costs reasonably incurred for the access,
exchange, or use of EHI will not implicate the information blocking
provision, provided the actor's practice meets the conditions of the
exception. We reiterate that an actor who seeks to comply with the
conditions of this exception will not be prevented from making a
reasonable profit in connection with the access, exchange, or use of
EHI, provided that all applicable conditions are met. We emphasize that
our intention with this exception is not to set any particular costs
that would be considered ``reasonably incurred,'' but rather to allow
the market to define the appropriate price so long as certain methods
are followed and certain criteria are met as established by the
conditions. To be responsive to comments, we have added text in the
introductory sentence of this exception that clarifies that fees that
result in a reasonable profit margin will be covered by this exception
so long as they are in compliance with the conditions in the exception
(Sec. 171.302).
We also appreciate the comments that encouraged us to prohibit all
profits under this exception. We considered this approach, but believe
that actors should be able to make a reasonable profit margin, subject
to the conditions in this exception. The allowance of a reasonable
profit margin is necessary to incentivize innovation and allow
innovators to earn returns on the investments they have made to
develop, maintain, and update innovations that ultimately improve
health care delivery and benefit patients. We believe the finalized
approach strikes the appropriate balance of addressing the rent-seeking
and exclusionary pricing practices noted by the commenters while
enabling and supporting innovation. However, to be responsive to these
comments related to limiting profits, we added a provision in Sec.
171.302(a)(1)(iv) that the fees an actor charges must be based on costs
not otherwise recovered for the same instance of service to a provider
and third party. The intent of this provision is that the exception
will not apply to practices where an actor charges twice for the same
exact service. For example, the exception likely would not apply where
an actor charges a hospital for providing a third party that the
hospital contracts with access to certain EHI, and then charges that
same third party an additional fee for access to the same EHI. This
condition creates a necessary guardrail to address potential misuse of
this exception that could result in a windfall for certain actors who
charge fees for the same services multiple times.
We have also modified other aspects of this final rule that address
commenter concerns regarding this exception. First, as discussed
previously in this section and in more detail in section VIII.C.3 of
this preamble, we have focused the scope of the EHI definition. This
change addresses commenters' concerns regarding potential ambiguity
regarding the types of information for which profits could be realized.
Actors seeking certainty about their practices related to charging fees
only need to comply with this exception if their practices interfere
with the access, exchange, and use of EHI. We emphasize that we are not
limiting the fees and/or profits related to the access, exchange, or
use of information outside the scope of EHI. We refer readers to
section VIII.C.3 of this preamble for a detailed discussion of focused
scope of the EHI definition.
Second, under the finalized information blocking definition, for up
to 18 months after the six-month delayed compliance date of the
information blocking section of this final rule (part 171) (a total of
24 months after the publication date of this final rule), EHI for
purposes of part 171 is limited to the EHI identified by the data
elements represented in the USCDI standard adopted in Sec. 170.213
(see (Sec. 171.103(b)). The fees an actor charges during that time
will only be limited pursuant to the conditions in this exception for
that subset of EHI.
We note that we revised Sec. 171.302(a)(1)(i) for clarity by
limiting the requirement to ``objective and verifiable criteria that
are uniformly applied for all similarly situated classes of persons and
requests'' instead of ``objective and verifiable criteria that are
uniformly applied for all substantially similar or similarly situated
classes of persons and requests.'' We believe the final standard
achieves the same goal as the proposed standard and provides a clearer
condition for the regulated community to follow. We updated Sec.
171.302(a)(2)(ii) by removing the illustrative language regarding the
``secondary use of such information'' and by removing the proposed
language about exceeding the actor's reasonable costs for providing
access, exchange, or use of EHI (see 84 FR 7539). The provision
finalized in Sec. 171.302(a)(1)(ii)--that an actor's fees must be
reasonably related to the actor's costs of providing the type of
access, exchange, or use of EHI to, or at the request of, the person or
entity to whom the fee is charged--achieves the same purpose of
limiting fees to those necessary to recover the costs reasonably
incurred.
We removed the ``secondary use'' language because it seemed
superfluous to include in the regulation text; however, we emphasize
that we maintain that the fees an actor charges must not be based on
the sales, profit, revenue or other value that the requestor or other
persons derive or may derive from the subsequent use of EHI. Our policy
on this point has not changed from the Proposed Rule. Practices that
use this method to recover costs will not
[[Page 25883]]
benefit from this exception and may implicate the information blocking
provision. Last, we note that we have added ``or entities'' to follow
``person'' to align with the language in Sec. 171.302(a)(1)(ii).
We note, with regard to the ``basis for fees'' and ``excluded
fees'' conditions (Sec. 171.302(a) and (b), respectively), that each
provision under these conditions was proposed in the Proposed Rule with
the exception of two new provisions: (1) The fees an actor charges must
be based on costs not otherwise recovered for the same instance of
service to a provider and third party (Sec. 171.302(a)(1)(iv)); and
(2) the fees an actor charges must not be based on any costs that led
to the creation of IP, if the actor charged a royalty for that IP
pursuant to Sec. 171.303 and that royalty included the development
costs for the creation of the intellectual property (Sec.
171.302(a)(2)(vi)). We discuss each of these additions in the
discussion below. Regarding the conditions that were included in the
proposed exception, we note that some of the conditions were in
different subsections of the proposed exception and/or have been
updated for clarity and consistency with other sections of this final
rule. We describe all the substantive changes to these provisions in
this preamble, but refer readers to the proposed exception to review
the full scope of structural changes and clarifications we have made
(see 84 FR 7603).
Comments. We received some comments regarding the scaling of fees
and the proposed condition that the method by which the actor recovers
its costs must be reasonably allocated among all customers to whom the
technology or service is supplied or for whom the technology is
supported. Some commenters stated that the notion that costs can be
evenly divided among clients is flawed. Commenters requested that ONC
allow a fee scale as opposed to a blanket fee structure. Commenters
noted that a sliding scale structure would ensure that smaller entities
would not be limited by a restrictive pricing application that
threatens their operating costs, which may exist on a slim margin. A
couple of commenters requested that ONC recognize that for many
organizations, especially non-profits, it is common and appropriate for
fees to scale with the size of a member/participant organization.
Several HIEs and HINs expressed concern that the proposed condition
regarding the reasonable allocation of costs could have the unintended
effect of prohibiting the fee structure of many public HIEs/HINs.
Commenters noted that many HIEs/HINs choose to charge fees to only a
subset of their participants. However, as proposed, the condition that
costs be reasonably allocated among all customers could undercut this
ability. Commenters emphasized that the ability to offer free services
to smaller providers, particularly as HIEs/HINs work to engage
providers across the care continuum, is an important flexibility for
such organizations. Commenters requested that HIE/HIN membership/
participation costs and subscription fees not be considered restricted
fees under the information blocking provision.
Response. We thank commenters for these thoughtful comments. We
maintain that the condition regarding reasonable allocation of costs in
Sec. 171.302(a)(iii) is necessary to ensure that actors do not
allocate fees in an arbitrary or anti-competitive manner. The final
condition requires that an actor allocate its costs in accordance with
criteria that are reasonable and between only those customers that
either cause the costs to be incurred or benefit from the associated
supply or support of the technology. We have finalized this condition
with a modification discussed below.
We agree with commenters that there may be situations when it would
be reasonable for an actor to allocate costs differently for different
classes of customers. In response to these comments, we have revised
the condition in Sec. 171.302(a)(1)(iii) so that the fees an actor
charges must be reasonably allocated among all similarly situated
customers to whom the technology or service is supplied, or for whom
the technology is supported. This addition addresses commenters'
concerns by providing actors with the discretion to allocate costs
differently for different classes of customers, while ensuring that any
differences in cost allocation are based on actual differences in the
class of customer. For instance, under this provision, fees must be
reasonably allocated among all similarly situated large hospital
systems (above a certain established size threshold) to whom a
technology or service is supplied, or for whom the technology is
supported. However, the allocation of fees for the same technology or
service could be quite different for a small, non-profit, rural health
clinic.
We also note that we have replaced ``customers'' with ``persons or
entities'' in Sec. 171.302(a)(1)(iii) in order to align the language
with Sec. 171.302(a)(1)(i) and (ii). We believe aligning the
provisions within Sec. 171.302(a) will strengthen the exception and
provide actor's with clarity regarding what is necessary to meet the
exception.
Comments. We received many comments, primarily from providers and
provider organizations, regarding the potential financial burden the
proposed exception will place on actors. Commenters recommended that
ONC carefully consider the downstream financial impact of new
requirements, especially that providers, including providers without
certified health IT and who do not participate in CMS programs, will
bear the brunt of the financial burden of these policies. More
specifically, commenters expressed concern regarding potential
recordkeeping and administrative burden caused by this exception.
Commenters explained that actors may need to retain extensive records
to document all of the costs that the actor incurred so that it can
prove that its fees only constitute those costs plus a reasonable
profit. Further, commenters stated that the administrative burden
required to assess and monitor this exception would be significant and
not sustainable. Commenters explained that cost accounting is
challenging for even very large and well-resourced organizations and
there is concern that the exception will result in unintended negative
consequences for many actors.
Response. We appreciate these comments. We reiterate that actors
may choose to satisfy the conditions of this exception to be certain
that the fees they charge for the access, exchange, or use of EHI do
not implicate the information blocking provision. We also reiterate
that failure to meet the exception does not mean that an actor's
practice related to charging fees meets the information blocking
definition. However, as we explained in the Proposed Rule, we interpret
the broad definition of information blocking in section 3022(a) of the
PHSA to encompass any fee that is likely to interfere with the access,
exchange, or use of EHI (84 FR 7521). Fees that do not meet this
exception may implicate the information blocking provision and will
have to be assessed on a case-by-case basis to determine, for example,
the actor's intent and whether the practice rises to the level of an
interference. This exception, as well as the other finalized
exceptions, strike a balance by identifying, as the Cures Act requires,
activities that interfere with access, exchange, or use of EHI but
which are reasonable and necessary.
We believe the overwhelming benefits of the information blocking
provision and the exceptions to the information blocking definition--
which enable patients to access, exchange, and use their EHI where and
when it is
[[Page 25884]]
needed--far outweigh the potential burden on actors. We believe the
revisions we have made to this exception, the addition of paragraph (b)
in the information blocking definition (see Sec. 171.103(b)) and the
discussion in section VIII.C of this preamble), the addition of the
Content and Manner Exception, as well as the revisions we have made to
the other exceptions and relevant terms will have the overall effect of
reducing burden on actors. The fact the information blocking section of
this rule (part 171) has a 6-month delayed compliance date from the
publication date of this final rule will also relieve the burden on
actors and give them time to prepare for administrative changes.
Comments. We received comments about the interplay and potential
overlap between the proposed Fees Exception and Licensing Exception.
Some commenters suggested that we combine the two exceptions for
clarity. Some commenters requested clarification as to whether an actor
may charge both a fee to recover reasonable costs associated with EHI
services and a reasonable royalty for licensing interoperability
elements. One commenter expressed concern that the overlap between the
two exceptions creates the potential for actors to recover the same
costs twice. The commenter explained that licensing of IP is intended
to recoup the costs of development of that IP, so where the IP is an
interoperability element, the costs reasonably incurred for its
development should be incorporated into the royalty rate. The commenter
recommended that we should be clearer that, in these circumstances,
only a single recovery is permitted.
Response. We thank commenters for the thoughtful feedback and agree
that the distinction between the Fees Exception and the Licensing
Exception (Sec. 171.303) must be clear. We emphasize that both
exceptions deal with the fees actors may charge regarding the access,
exchange, or use of EHI and under both exceptions actors use
interoperability elements (as defined in Sec. 171.102) to facilitate
the access, exchange, or use of EHI. The exception for recovering costs
reasonably incurred enables actors to recover their costs to develop
technologies and provide services that enhance interoperability. On the
other hand, the exception for licensing interoperability elements
specifically addresses circumstances when it is necessary for an actor
to license interoperability elements in order fulfill a request to
access exchange, or use EHI. The Licensing Exception deals with the
requisite licensing conditions. We believe there should be a
distinction made between these two exceptions, and have therefore
decided not to combine the two exceptions.
We agree with the commenter that actors should not be able to
recover the same costs twice and have added a provision in Sec.
171.302(a)(2)(vi) that the fees an actor charges must not be based on
any costs that led to the creation of IP, if the actor charged a
royalty for that IP pursuant to Sec. 171.303 and that royalty included
the development costs for the creation of the intellectual property.
Excluded Fees Condition
We proposed that certain costs should be explicitly excluded from
the exception regardless of the method for recovering the costs (84 FR
7540).
Comments. We did not receive comments regarding the overall
proposed approach of excluding certain costs from this exception.
Response. We have finalized the structure of this exception to
exclude certain fees with the changes described in the discussions
above and below. We note that we have substituted the ``or'' that
preceded the final excluded fee in the proposed exception (see 84 FR
7603) with an ``and'' in the final exception. This is not a substantive
change, as our intent has always been that the exception does not apply
to each of ``excluded fees.'' This revision clarifies that point.
Costs Due to Non-Standard Design or Implementation Choices
We proposed that this exception would not permit the recovery of
any cost that the actor incurred due to the health IT being designed or
implemented in non-standard ways that unnecessarily increase the
complexity, difficulty or burden of accessing, exchanging, or using
EHI. To the extent that such costs can be reasonably avoided, we stated
that we believe that actors should internalize the costs of such
behaviors, which do not benefit consumers, and which create unnecessary
impediments to access, exchange, and use of EHI. We requested comments
on the proposed exclusion of these types of costs from the exception
(84 FR 7540).
Comments. We received several comments regarding the proposed
exclusion of costs due to non-standard design or implementation choices
from this exception. A couple of commenters expressed support for the
proposal. A couple of other commenters disagreed with the proposal and
recommended that actors should be able to recover all reasonable
implementation costs independent of design decisions. One commenter
requested additional clarity about what ``non-standard'' means. A
couple of commenters noted that requestors may prefer information in a
non-standard manner to meet their business purposes, due to their own
constraints, or for other reasons.
Response. We thank commenters for their support of this proposal,
as well as the constructive feedback. We emphasize that the problematic
nature of non-standard implementation choices was identified by
Congress in the Cures Act. Section 3022(a)(2)(B) of the PHSA states
that information blocking may include implementing health IT in non-
standard ways that are likely to substantially increase the complexity
or burden of accessing, exchanging, or using EHI. Due to Congress's
clear objective to restrict these practices, along with our continued
concern that these practices will lead to unnecessary complexity and
burden related to the access, exchange, or use of EHI, we have
finalized the proposed provision regarding non-standard design and
implementation choices. We have updated Sec. 171.302(a)(2)(iii) to
address comments indicating that requestors may prefer information in a
non-standard manner to meet their business purposes, due to their own
constraints, or for other reasons. We agree with commenters that in
those situations--when the requestor requests access, exchange or use
of EHI in the non-standard way--the exception should allow the actor to
charge fees for the reasonable costs associated with the requested non-
standard design or implementation. We emphasize, however, and make
clear in Sec. 171.302(a)(2)(iii), that such fees related to non-
standard design or implementation are only covered by the exception
when the requestor agreed to the fee associated with the non-standard
design or implementation to access, exchange, or use EHI. We note that
this provision was proposed as an ``excluded cost'' but has been
finalized within the ``Basis for fees condition'' for clarity and to
align with the revised structure of this exception.
We also note that the new Content and Manner Exception in Sec.
171.301 further addresses commenter concerns because it provides actors
with clear procedures regarding the manner in which they may provide
access, exchange, or use of EHI if they are technically unable to
respond in the manner requested or the manner requested requires the
actor to license intellectual property and the actor cannot reach
agreeable terms with the requestor (discussed in section VIII.D.2.a of
this preamble). If an actor
[[Page 25885]]
meets that exception, its practice would not implicate the information
blocking provision. For instance, if a requestor requested that the
actor provide EHI in a non-standard manner, but the actor is
technically unable to provide the EHI in the manner requested, the
actor's response to the request would not implicate the information
blocking provision if it provides the EHI via an alternative manner in
accordance with Sec. 171.301(b). The actor could also potentially seek
coverage under the Infeasibility Exception if the request is infeasible
and the actor meets all the conditions in Sec. 171.204.
Regarding the comment concerning additional clarity about what
``non-standard'' means, we explained and provided examples in the
Proposed Rule of practices related to implementing health IT in non-
standard ways that substantially increase the complexity or burden of
accessing, exchanging, or using EHI, and therefore implicate the
information blocking provision (84 FR 7521). In addition, the Cures Act
specifically describes information blocking practices to include
implementing health IT in nonstandard ways that are likely to
substantially increase the complexity or burden of accessing,
exchanging, or using electronic health information (see section
3022(a)(2)(B) of the PHSA). Therefore, the Proposed Rule discussion
regarding non-standard ways of implementing health IT also applies for
purposes of the Fees Exception. As explained in the Proposed Rule, non-
standard implementation of health IT may arise where an actor chooses
not to adopt, or to materially deviates from, relevant standards,
implementation specifications, and certification criteria adopted by
the Secretary under section 3004 of the PHSA (84 FR 7521). Even where
no federally adopted or identified standard exists, if a particular
implementation approach has been broadly adopted in a relevant industry
segment, deviations from that approach will be suspect unless strictly
necessary to achieve substantial efficiencies. For further discussion
regarding our rationale for this provision, as well as specific, non-
exhaustive examples of conduct that would be likely to interfere with
the access, exchange, or use of EHI, we refer readers to the Proposed
Rule (84 FR 7521).
Subjective or Speculative Costs
We proposed to limit this exception to the recovery of costs that
an actor actually incurred to provide the relevant interoperability
element or group of elements (which may comprise either products or
services). We proposed that the exception would not permit the recovery
of certain types of costs that are subjective or speculative. We noted
two important examples of this limitation. First, we proposed that an
actor would not be permitted to recover any costs associated with
intangible assets (including depreciation or loss of value), other than
the actual development or acquisition costs of such assets. For
example, an actor could not charge a customer a fee based on the
purported ``cost'' of allowing the customer to use the actor's patented
technology, computer software, databases, trade secrets, copyrighted
works, and the like. We noted that the customer's use of the asset
could be considered a ``cost'' in the sense that, were it not for the
information blocking provision, the actor could charge a royalty or
other fee for the use of its intangible assets. For this reason we
proposed to permit an actor to license most interoperability elements
on reasonable and non-discriminatory terms, subject to certain
conditions. For purposes of this more general exception, however, we
explained that it would be inappropriate to permit an actor to charge a
fee based on these considerations, which are inherently subjective and
could invite the kinds of rent-seeking and opportunistic pricing
practices that fall squarely within the definition of information
blocking. We proposed that an actor's practices could qualify for both
this exception (Fees Exception) and the Licensing Exception (finalized
in Sec. 171.303). In that case, the actor could recover costs under
both exceptions (84 FR 7540).
Second we stated the exception would not apply to ``opportunity
costs,'' such as the revenues that an actor could have earned had it
not provided the interoperability elements. We clarified that the
exclusion of opportunity costs would not preclude an actor from
recovering its reasonable forward-looking cost of capital (84 FR 7540).
Comments. We did not receive any comments on our proposals
regarding subjective or speculative costs.
Response. We have finalized this provision as proposed with some
modifications for clarity. We have modified the provision regarding
intangible assets in Sec. 171.301(a)(2)(iv) by removing the
parenthetical that noted that such costs include the depreciation or
loss of value. The parenthetical was illustrative and was not necessary
in the regulation text, as it is just one of the many types of
intangible assets on which a fee must not be based. We have also
modified the provision regarding opportunity costs in Sec.
171.301(a)(2)(v) by clarifying that the specific opportunity costs on
which a fee must not be based are those unrelated to the access,
exchange, or use of EHI instead of the proposed qualifying language of
``except for the reasonable forward-looking cost of capital'' (see 84
FR 7603). We believe this finalized language is clearer than the
proposed language. In addition, it is more precise than the proposed
language because it creates a connection to the information blocking
definition. We note that we proposed these provisions as ``excluded
costs'' (see 84 FR 7603) but have finalized them within the ``Basis for
fees condition'' for clarity.
Fee Prohibited by 45 CFR 164.524(c)(4)
We also proposed that the exception would not apply to fees
prohibited by 45 CFR 164.524(c)(4). We noted in the Proposed Rule that
the HIPAA Privacy Rule permits a covered entity to impose a reasonable,
cost-based fee if the individual requests a copy of the PHI (or agrees
to receive a summary or explanation of the information). The fee may
include only the cost of: (1) Labor for copying the PHI requested by
the individual, whether in paper or electronic form; (2) supplies for
creating the paper copy or electronic media (e.g., CD or USB drive) if
the individual requests that the electronic copy be provided on
portable media; (3) postage, when the individual requests that the
copy, or the summary or explanation, be mailed; and (4) preparation of
an explanation or summary of the PHI, if agreed to by the individual
(45 CFR 164.524(c)(4)). The fee may not include costs associated with
verification; documentation; searching for and retrieving the PHI;
maintaining systems; recouping capital for data access, storage, or
infrastructure; or other costs not listed above even if such costs are
authorized by State law (84 FR 7540).
Comments. We received a couple of comments regarding copying fees
allowed under the HIPAA Privacy Rule. One commenter stated that
reasonable, cost-based fees for certain costs, consistent with the
HIPAA Privacy Rule individual access provisions, should not be allowed
under the exception. One commenter requested that ONC harmonize the
exception with the HIPAA Privacy Rule provisions that govern the
charging of fees for electronic copies of medical records.
Response. We appreciate these comments. We have decided to finalize
the provision as proposed, which harmonizes this part of the exception
(Sec. 171.302) with those provisions of the HIPAA Privacy Rule. The
exception does not apply to fees prohibited by 45 CFR 164.524(c)(4).
Consistent with the
[[Page 25886]]
HIPAA Privacy Rule's individual access fee implementation
specification, an actor can charge a reasonable, cost-based fee related
to certain costs (described above) if a patient requests a copy of her
records.
Individual Electronic Access
We proposed that the exception would not apply if the actor charged
a fee based in any part on the electronic access by an individual or
their personal representative, agent, or designee to the individual's
EHI. We stated that such fees are distinguished from the cost-based
fees that a covered entity is permitted to charge individuals for the
provision of copies of ePHI under the HIPAA Privacy Rule access
provisions (45 CFR 164.524(c)(4)), and similar allowable costs under
State privacy laws, which would not be excluded from the costs
recoverable under the exception. We clarified that access to EHI that
is provisioned by supplying some form of physical media, such as paper
copies (where the EHI is printed out), or where EHI is copied onto a CD
or flash-drive, would not be a practice that implicated the information
blocking provision provided that the fee(s) charged for that access
complied with the HIPAA Privacy Rule access provisions (45 CFR
164.524(c)(4)) (84 FR 7540).
We stated that a fee based on electronic access by an individual or
their personal representative, agent, or designee to the individual's
EHI, in contrast, would arise if an actor sought to impose on
individuals, or their personal representatives, agents, or designees, a
fee that operated as a toll to electronically access, exchange, or use
EHI. For example, a health care provider that charges individuals a fee
in order for the individuals to receive access to their EHI via the
health care provider's patient portal or another internet-based method,
would not be able to benefit from this exception. Similarly, where an
individual authorizes (approves) a consumer-facing app to receive EHI
on the individual's behalf, the exception would not apply to practices
where an actor charges the app or its developer a fee to access or use
APIs that enable an individual's access to the individual's EHI. We
explained that this would be true whether the actor is a supplier of
the API technology or an individual or entity that has deployed the API
technology, such as a health care provider (84 FR 7540).
Comments. Commenters expressed overwhelming support for our
proposal regarding individual electronic access. Commenters from across
stakeholder groups emphasized that patients have a fundamental right to
access their data and should be able to access, exchange, and use their
EHI at no charge. Commenters emphasized that the EHI belongs to the
patient, and neither health care providers, EHR developers, nor payers
should profit from the sale of EHI, as that will only serve to limit
data transfer, increase health care costs, and adversely affect patient
care.
Commenters strongly supported our proposal (within the API
Condition of Certification) that API fees should not be a barrier in
allowing patient access to their EHI (see proposed Sec. 170.404 and 84
FR 7487 through 7491). They stressed that neither individuals nor app
developers (i.e., API Users) should be charged a fee for API uses that
are associated with the access, exchange, and use of EHI by patients or
their applications, technologies, or services. Several commenters
supported our efforts to bolster patient access, noting that the
capacity to offer a patient access to EHI, through an API, without
cost, is well-supported in the Proposed Rule. One commenter requested
that we differentiate between an individual electronically accessing
EHI and third parties, at the direction of the individual,
electronically accessing EHI.
Response. We thank commenters for the support and have finalized
this provision as proposed with a slight modification to the text in
Sec. 171.302(b)(2) and clarification of the meaning of electronic
access, which we have codified in Sec. 171.302(d). We have reordered
the language for clarity and, in order to clarify the terms ``agent''
and ``designee,'' we have replaced them with ``another person or entity
designated by the individual.'' These other individuals or entities
(e.g., a third-party app) receive access to EHI at the direction of the
individual and individuals control whether the third-party receives
access to the individual's EHI. This modification is merely a
clarification of our proposal and is not a substantive change as we
clearly stated in the Proposed Rule that, as summarized above, this
exception would not apply to practices where an actor charges the app
or its developer a fee to access or use APIs that enable access to the
individual's EHI. Fees can be a method of interfering with the access,
exchange, and use of EHI, as we have emphasized in the Proposed Rule
and this final rule. When it comes to an individual's electronic access
to their EHI, we believe that any fee, whether direct or indirectly
passed on through a fee charged to a third-party app that the
individual has chosen to facilitate access to their EHI, could
interfere with an individual's access and use of their EHI. ONC's
implementation of the Cures Act is predicated on an understanding that
access to EHI should not be treated as a commodity that should be
traded or sold. ONC takes this approach because we view patients as
having an overwhelming interest in EHI about themselves, and because we
understand that the true value of EHI can only be realized if it is
available where and when it is needed, including providing electronic
access to patients. Patients have already effectively paid for their
health information, either directly or through their employers, health
plans, and other entities that negotiate and purchase health care items
and services on their behalf. We have codified this provision in Sec.
170.302(b)(2) to not permit ``[a] fee based in any part on the
electronic access of an individual's EHI by the individual, their
personal representative, or another person or entity designated by the
individual.''
For purposes of the Fees Exception, we define electronic access to
mean an internet-based method that makes EHI available at the time the
EHI is requested and where no manual effort is required to fulfill the
request (Sec. 171.302(d)). We discussed the meaning of ``electronic
access'' in the Proposed Rule (see 45 FR 7540). We have defined
``electronic access'' in Sec. 171.302(d) in this final rule consistent
with the Proposed Rule, including distinguishing it from the methods
and efforts we cited in the Proposed Rule that we did not consider
electronic access and for which a fee could be charged (see 45 FR
7540). We have chosen ``internet-based method'' in lieu of the proposed
``web-based delivery'' because it more technically aligns with the
concept we were attempting to convey in the Proposed Rule. Such methods
would be, as described in part in the Proposed Rule, access via an API,
patient portal, or other internet-based means. To note, the 2015
Edition ``view, download, and transmit to 3rd party'' certification
criterion uses this same concept of ``internet-based'' to convey that
``patients (and their authorized representatives) must be able to use
internet-based technology to view, download, and transmit. . . .'' In
terms of fulfilling a request without manual effort, we clarify that it
entails the completion of the process where there is no manual effort
involved to meet the request at the time of the request. To illustrate
the inverse, we recognize that there are times that manual effort may
be involved in collating or assembling EHI from various systems in
response to a request. In such instances, this provision (Sec.
170.302(b)(2)) would not
[[Page 25887]]
apply to the costs of those efforts because the efforts would not fall
under the definition of ``electronic access.''
We reaffirm that this exception would not apply to an actor that
charges individuals a fee in order for the individuals to receive
access to their EHI using an internet-based delivery method, including
where an individual uses consumer-directed technology (e.g., patient-
chosen apps, personal health apps, standalone/untethered personal
health records (PHR), email) to request and/or receive their EHI. This
includes sharing it with an entity designated by the individual (e.g.,
allowing individuals to donate/share EHI with a biomedical research
program of the individual's choice). Practices that involve an actor
charging an individual (or the individual's personal representative or
another person or entity designated by the individual) a fee to access,
exchange, or use their EHI would be inherently suspect and would be
extremely likely to implicate the information blocking provision. We
emphasize that practices that do not meet this condition, or any other
conditions in the Fees Exception, would be subject to case-by-case
review (unless another exception applies). We further refer readers to
our discussion of ``interfere with'' or ``interference,'' including
examples of practices that would likely interfere with access,
exchange, and use of EHI (section VIII.C.6).
Export and Portability of EHI Maintained in EHR Systems
We explained in the Proposed Rule that the definition of
information blocking specifically mentions transitions between health
IT systems and the export of complete information sets as protected
forms of access, exchange, and use (see section 3022(a)(2)(C)(i) of the
PHSA). We noted that in our experience, health care providers
frequently encounter rent-seeking and opportunistic pricing practices
in these and other contexts in which they are attempting to export EHI
from their systems for use in connection with other technologies or
services that compete with or could reduce the revenue opportunities
associated with an EHR developer's own suite of products and services.
We explained that most EHI is currently maintained in EHRs and other
source systems that use proprietary data models or formats; this puts
EHR developers in a unique position to block the export and portability
of EHI for use in competing systems or applications, or to charge rents
for access to the basic technical information needed to facilitate the
conversion or migration of data for these purposes. We emphasized that
our concerns are compounded by the fact that EHR developers rarely
disclose in advance the fees they will charge for data export and data
portability services (see 80 FR 62719; 80 FR 16880 and 81).
For these reasons, we proposed that fees charged for the export,
conversion, or migration of data from an EHR technology would not
qualify for this exception unless they also meet two additional
conditions. First, we proposed that health IT developers of certified
health IT would, for purposes of the exception, be precluded from
charging a fee to perform an export of EHI via the capability of health
IT certified to the proposed 2015 Edition ``EHI export'' certification
criterion for the purposes of supporting single patient EHI export upon
a valid request from that patient or a user on the patient's behalf, or
supporting the export of all EHI when health care provider chooses to
transition or migrate information to another health IT system. We
stated that, as part of the ``Assurances'' Condition of Certification,
health IT developers that produce and electronically manage EHI would
need to be certified to the criterion and provide the functionality to
its customers. We stated that fees or limitations associated with the
use of the ``EHI export'' certification criterion (as distinguished
from deployment or other costs reasonably incurred by the developer)
would not receive protection under the exception and may be suspect
under the information blocking provision (84 FR 7541).
We clarified that the condition would not preclude a developer from
charging a fee to deploy the ``EHI export'' certification criterion in
a health care provider's production environment, or to provide
additional services in connection with this capability other than those
reasonably necessary to enable its intended use. For example, we
explained that this condition would not preclude a developer from
charging a fee to perform an export of EHI via the capability of health
IT certified to the proposed Sec. 170.315(b)(10) for a third-party
analytics company. We noted in the Proposed Rule that, because the
certification criterion provides only a baseline capability for
exporting data, we anticipated that health IT developers of certified
health IT will need to provide other data portability services to
facilitate the smooth transition of health care providers between
different health IT systems. We proposed that such fees may qualify for
protection under the exception, but only if they meet the other
conditions described above and in proposed Sec. 171.205(a).
Second, we proposed that the exception would not apply to a fee to
export or convert data from an EHR technology unless such fee was
agreed to in writing at the time the technology was acquired, meaning
when the EHR developer and the customer entered into a contract or
license agreement for the EHR technology (84 FR 7541).
Comments. A commenter requested clarification regarding the
proposal to exclude from the exception costs related to fees to export
or convert data from an EHR technology, unless such fee was agreed to
in writing at the time the technology was acquired. The commenter asked
that ONC clarify if this provision is applicable to export or the
conversion of EHI from certified health IT or if it is applicable to
any export or conversion of EHI from any health IT. The commenter also
requested that ONC clarify if this provision is prospective in nature,
meaning it would only apply to agreements entered into after the
effective date of a final rule. The commenter recommended that ONC
change the focus of this proposal so that it only requires that the
parties agree in writing that fees of a particular nature may be
charged for the export of EHI.
Response. We appreciate this comment. In response to the comment,
we clarify that this exclusion from the exception is not limited to the
export of EHI from certified health IT. Instead, this provision applies
to the export or conversion of any EHI from an actor's technology(ies).
As we discuss elsewhere in this Final Rule, we interpret the
information blocking provision broadly such that practices of a health
IT developer of certified health IT that do not pertain specifically to
certified health IT may implicate the information blocking provision.
Consistent with this interpretation of the information blocking
provision, the exception will not protect practices where an actor
charges fees to export or convert data from any EHR technology, unless
such fee was agreed to in writing at the time technology was acquired.
Further, we clarify that if a fee to export or convert data is not
subject to this exclusion in Sec. 171.302(b)(4) because it was agreed
to in writing, it still must meet the other applicable conditions in
Sec. 171.302 to be covered by the Fees Exception.
Without this exclusion, actors may seek to take advantage of the
exception and enable rent-seeking or opportunistic pricing practices.
Thus, we have decided not to limit the condition so that it only
requires that the parties
[[Page 25888]]
agree in writing that fees of a particular nature may be charged for
the export of EHI as suggested by the commenter. Only requiring the
parties to agree to the fee in writing (without applying the other
conditions in this exception), may allow an actor to charge an
unreasonable fee or engage in a practice that is likely to interfere
with the access, exchange, or use of EHI. While a party may agree to
pay a fee under specific circumstances, that agreement does not change
the fact that the fee must be reasonably related to the actor's costs
or may otherwise interfere with the access, exchange, or use of EHI.
We have finalized these provisions as proposed with a slight
modification. We changed the condition from ``A fee to export or
convert data from an EHR technology, unless such fee was agreed to in
writing at the time the technology was acquired'' (see 84 FR 7603) to
``A fee to export or convert data from an EHR technology that was not
agreed to in writing at the time the technology was acquired'' (Sec.
171.302(b)(4)). We made this change for clarity based on the change we
made to the introductory language in the exception, that a practice
will not be considered information blocking when the practice meets the
conditions in paragraph (a), does not include any of the excluded fees
in paragraph (b), and, as applicable, meets the condition in paragraph
(c). This modification does not change the substance of this condition
in any way.
Compliance With the Conditions of Certification
We stated in the Proposed Rule that health IT developers of
certified health IT subject to the API Condition of Certification may
not charge certain types of fees and are subject to more specific cost
accountability provisions than apply generally under this proposed
exception. We noted that the failure of developers to comply with these
additional requirements would impose impediments to consumer and other
stakeholder access to EHI without special effort and would be suspect
under the information blocking provision. We proposed, therefore, that
a health IT developer of certified health IT subject to the API
Condition of Certification must comply with all requirements of that
condition for all practices and at all relevant times in order to
qualify for the exception (84 FR 7541).
We also stated that a health care provider that acts as an API Data
Provider should be subject to the same constraints. We noted that the
API Condition of Certification prohibits a health IT developer from
charging a usage fee to patient-oriented apps. We noted that
information blocking concerns would arise if a provider were to charge
such a fee, notwithstanding the fact that the provider is not subject
to the certification requirements. For this reason, we proposed that,
if the actor is an API Data Provider, the actor would only be permitted
to charge the same fees that an API Technology Supplier would be
permitted to charge to recover costs consistent with the permitted fees
specified in the Condition of Certification (84 FR 7541).
Comments. We did not receive comments on these proposals.
Response. We have finalized the first provision detailed above as
proposed with a slight modification for clarity. The final provision in
Sec. 171.302(c) states: Notwithstanding any other provision of this
exception, if the actor is a health IT developer subject to the
Conditions of Certification in Sec. 170.402(a)(4), Sec. 170.404, or
both of this subchapter, the actor must comply with all requirements of
such conditions for all practices and at all relevant times. We added
``or both'' into the final language because a health IT developer could
be subject to both Sec. 170.402(a)(4) and Sec. 170.404 and in such
instances would be covered by this provision.
We have removed the second provision detailed above regarding a
health care provider that acts as an API Data Provider (see the
Proposed Rule at 84 FR 7603) for clarity, as not all of the permitted
fees specified in the API Condition of Certification (Sec. 170.404)
are applicable for API Data Providers.
Application of the Exception to Individual Practices
We stated in the Proposed Rule that the conditions of this
exception, including those governing the methodology and criteria by
which an actor calculates and distributes its costs, must be satisfied
for each and every fee that an actor charges to a customer, requestor,
or other person for accessing, exchanging, or using EHI. All applicable
conditions of the exception must be met at all relevant times for each
practice (84 FR 7541).
Comments. We did not receive any comments on this proposed policy.
Response. We have finalized this policy as proposed.
c. Licensing Exception--When will an actor's practice to license
interoperability elements in order for electronic health information to
be accessed, exchanged, or used not be considered information blocking?
We proposed in the Proposed Rule in Sec. 171.206 to establish an
exception to the information blocking provision that would permit
actors to license interoperability elements on reasonable and non-
discriminatory (RAND) terms, provided that certain conditions are met.
We proposed that the information blocking provision would be implicated
if an actor were to refuse to license or allow the disclosure of
interoperability elements to persons who require those elements to
develop and provide interoperable technologies or services--including
those that might complement or compete with the actor's own technology
or services (84 FR 7544). Moreover, we proposed that the information
blocking provision would be implicated if the actor licensed such
interoperability elements subject to terms or conditions that have the
purpose or effect of excluding or discouraging competitors, rivals, or
other persons from engaging in these pro-competitive and
interoperability-enhancing activities. Thus, we proposed the Licensing
Exception would apply in both vertical and horizontal relationships and
provided an example emphasizing that point in the Proposed Rule (see 84
FR 7544).
We noted in the Proposed Rule that some licensees do not require
interoperability elements to develop products or services that can be
interoperable with the actor's health IT. We explained that there may
be firms that simply want to license the actor's technology for use in
developing their own interoperability elements. Their interest would be
for access to the technology itself--not for the use of the technology
to interoperate with either the actor or its customers to enable the
access, exchange, or use of EHI. We emphasized that in such cases, the
actor's licensing of its intellectual property (IP) in such a context
would not implicate the information blocking provision (in other words,
would not be in scope for information blocking). For a non-exhaustive
list of examples of situations that would implicate the information
blocking provision, see the Proposed Rule (84 FR 7544-45).
In our experience, contractual and IP rights are frequently used to
extract unreasonable rents for access to EHI or to prevent competition
from developers of interoperable technologies and services. These
practices frustrate access, exchange, and use of EHI and stifle
competition and innovation in the health IT sector. As a case in point,
we noted in the Proposed Rule that even following the enactment of the
Cures Act, some health IT developers had been selectively prohibiting--
whether expressly or through commercially unreasonable terms--the
disclosure or
[[Page 25889]]
use of technical interoperability information required for third-party
applications to access, exchange, and use EHI maintained in EHR
systems. We noted that such practices limit health care providers' use
of the EHI maintained on their behalf to the particular capabilities
and use cases that their EHR developer happens to support. More than
this, by limiting the ability of providers to choose what applications
and technologies they can use with their EHR systems, we indicated that
these practices close off the market to innovative applications and
services that providers and other stakeholders need to deliver greater
value and choice to health care purchasers and consumers (84 FR 7545).
Despite these serious concerns, we recognized in the Proposed Rule
that the definition of information blocking may be broader than
necessary and could have unintended consequences. We proposed that it
is generally appropriate for actors to license their IP on RAND terms
that do not interfere with access, exchange, or use of EHI provided
certain conditions were met. We explained that these practices would
further the goals of the information blocking provision by allowing
actors to protect the value of their innovations and earn returns on
the investments made to develop, maintain, and update those
innovations. We explained that this would protect future incentives to
invest in, develop, and disseminate interoperable technologies and
services. Conversely, we explained that if actors cannot (or believe
they cannot) protect and commercialize their innovations, they may not
engage in these productive activities that improve access, exchange,
and use of EHI (84 FR 7545).
We proposed that the exception would be subject to strict
conditions to ensure, among other things, that actors license
interoperability elements on RAND terms and that actors do not impose
collateral terms or engage in other practices that would impede the use
of the interoperability elements or otherwise undermine the intent of
the exception (84 FR 7545). We acknowledged that preventing IP holders
from extracting rents for access to EHI may differ from standard IP
policy. We proposed that absent specific circumstances, IP holders are
generally free to negotiate with prospective licensees to determine the
royalty to practice their IP, and this negotiated royalty frequently
reflects the value the licensee would obtain from exercising those
rights. However, in the context of EHI, we proposed that a limitation
on rents is essential due to the likelihood that rents will frustrate
access, exchange, and use of EHI, particularly because of the power
dynamics that exist in the health IT market (84 FR 7545).
We also emphasized that actors are not required to seek the
protection under this (or any other) exception. We explained that if an
actor does not want to license a particular technology in accordance
with the exception, it may choose to comply with the information
blocking provision in another way, such as by developing and providing
alternative means of accessing, exchanging, and using EHI that are
similarly efficient and efficacious (84 FR 7545).
Comments. We received many comments in support of this proposed
exception. One commenter highlighted the significance of the exception,
noting that data is often locked in proprietary software systems, at
times preventing providers from being able to connect and exchange
information. Some commenters requested additional examples and that ONC
issue guidance to assist actors in understanding how they can determine
whether a request to license is valid, when this exception would apply,
and what steps actors would be required to take to attain coverage
under the exception. A couple of commenters suggested that there should
be a distinction between requests to license interoperability elements
to facilitate a patient's treatment or individual access versus
requests that are simply for the requestor's own business purposes,
such as commercializing a competing product. A couple of commenters
requested additional provisions in the final rule to improve
transparency regarding licensing of interoperability elements.
Commenters recommended that ONC require regulated actors who engage in
RAND licensing of interoperability elements to publish either standard
licensing rate offers or actual licenses.
Response. We thank commenters for their support for this exception
as well as the constructive feedback. We may consider developing
materials in the future regarding the application of the exceptions
should the need arise. However, we believe the final rule clearly
describes the conditions actors must meet in order to be covered by
each exception, and informational materials are not necessary at this
time.
We appreciate the comments that recommended that there should be a
distinction between requests for licensing of interoperability elements
to facilitate a patient's treatment or individual access versus
requests that are simply for the requestor's own business purposes. We
emphasize that we made such a distinction in the Proposed Rule and we
reiterate that distinction here in the final rule. In order for an
actor to consider licensing its interoperability elements under this
exception, the requestor would need to have a claim to the underlying,
existing EHI for which the interoperability element would be necessary
for access, exchange, or use (see the Privacy Exception discussion in
VIII.D.1.b). An actor will not implicate the information blocking
provision and does not need to seek coverage under this exception in
circumstances where the entity requesting to license or use the
interoperability element is not seeking to use the interoperability
element to interoperate with either the actor or the actor's customers
in order for EHI to be accessed, exchanged, or used. For instance, an
actor would not need to consider licensing its interoperability
elements in accordance with this exception to a firm that requested a
license solely for that firm's use in developing its own technologies
or business when no EHI is sought to be accessed, exchanged, or used.
In other words, if there is no nexus between a requestor's need to
license an interoperability element and existing EHI on one or more
patients, an actor does not need to consider licensing the
interoperability element requested in accordance with this exception.
For example, if a developer of certified health IT included proprietary
APIs in its product to support referral management, it would not need
to license the interoperability element(s) associated with those
referral management APIs simply because a requestor ``knocked on the
actor's door'' and asked for a license with no EHI involved. The
license request from a requestor must always be based on a need to
access, exchange, or use EHI at the time the request is made--not on
the requestor's prospective intent to access, exchange, or use EHI at
some point in the future.
We appreciate the recommendation that ONC should require regulated
actors who license interoperability elements to publish either standard
licensing rate offers or actual licenses. However, we have decided not
to finalize such a requirement because we believe actors should have
discretion to decide whether to publish their licensing rates and/or
licenses. We believe this exception will still effectively regulate the
licensing of interoperability elements even if it does not require the
publication of such rates and licenses. Nonetheless, we commend
[[Page 25890]]
commenters' desire to enhance transparency in the final rule and will
continue to consider steps to further promote transparency regarding
our information blocking policies in future rulemakings.
We note that we have changed the title of this exception from
``Exception--Licensing of interoperability elements on reasonable and
non-discriminatory terms'' to ``When will an actor's practice to
license interoperability elements in order for electronic health
information to be accessed, exchanged, or used not be considered
information blocking?'' Throughout this final rule preamble, we use
``Licensing Exception'' as a short form of this title, for ease of
reference. As stated in Section VIII.D of this final rule preamble, we
have changed the titles of all of the exceptions to questions to
improve clarity. We have also edited the wording of the introductory
text in Sec. 171.303, in comparison to that proposed (84 FR 7602), so
that it is consistent with the finalized title in Sec. 171.303. We
believe these conforming changes in wording of the introductory text
also improve clarity in this section.
Comments. We received many comments requesting greater clarity and
precision regarding key terms within the proposed exception in order to
clarify the scope and application of the exception.
Response. We appreciate these comments and agree with commenters
that it is essential that our final policies are clear, administrable,
and actionable. Accordingly, we have made several updates to this
exception as well as to terms and concepts that apply broadly
throughout the information blocking section. Notably, we have: (1)
Revised the definition of interoperability element (see section
VIII.C.3.b); (2) clarified the process and timeframe for negotiating a
license (see the discussion later in this section of the preamble); (3)
removed the ``RAND'' framework, which commenters noted was confusing
(see the discussion later in this section of the preamble); and (4)
clarified the relationship between this exception and the Fees
Exception (see Sec. 171.302 and the discussion later in this section
of the preamble).
Comments. A few commenters requested clarification regarding
whether the information blocking provision, and particularly this
exception, applies to all licensing agreements already in effect; only
licensing agreements that were entered into following the effective
date of the Cures Act; or only those licensing agreements entered into
after the effective date of ONC's final rule. Commenters recommended
that licensing agreements that were entered into prior to the effective
date of the final rule should be considered valid and effective.
Commenters also recommended that all negotiations and licensing
agreements entered into after the effective date of ONC's final rule
should comply with the requirements of the final rule. Commenters
requested that if ONC plans to enforce provisions of the final rule
retroactively, ONC should allow actors to review and renegotiate
licensing agreements for compliance with the terms at the request of
the licensee.
Response. We thank commenters for these comments. We emphasize that
actors are expected to be in full compliance with the information
blocking provision when this rule becomes effective. We note that the
information blocking section of this final rule (part 171) will not
become effective until 6 months after the publication date of the final
rule. We believe this delayed compliance date will provide actors with
adequate time to assess their existing licensing contracts or
agreements and make appropriate changes and amendments to comply with
this final rule.
OIG and ONC are coordinating timing of the compliance date of the
information blocking section of this final rule (45 CFR part 171) and
the start of information blocking enforcement. We are providing the
following information on timing for actors. Enforcement of information
blocking CMPs in section 3022(b)(2)(A) of the PHSA will not begin until
established by future notice and comment rulemaking by OIG. As a
result, actors would not be subject to penalties until CMP rules are
final. At a minimum, the timeframe for enforcement would not begin
sooner than the compliance date of this final rule and will depend on
when the CMP rules are final. Discretion will be exercised such that
conduct that occurs before that time will not be subject to information
blocking CMPs.
We are aware that some actors may currently have in place licensing
agreements that contravene the information blocking provision and do
not meet the requisite conditions for this exception. We expect actors
in these situations to take immediate steps to come into compliance
with the information blocking provision by amending their contracts or
agreements to eliminate or void any clauses that contravene the
information blocking provision. We emphasize that an existing license
is no excuse or justification for information blocking. One of the ways
we have heard that actors interfere with the access, exchange, and use
of EHI is through formal restrictions, such as discriminatory licensing
agreements, and this final rule, as well as this exception, seek to
address those very circumstances and situations.
Comments. One commenter expressed concern about this exception on
privacy and security grounds. The commenter noted that a proliferation
of EHI to a multitude of entities who have not and cannot be vetted is
likely to increase the risks to the privacy and security of such data
and create secondary and tertiary markets for such data without clear
regulation and oversight.
Response. We appreciate this comment and understand that the
secondary use of data creates privacy and security challenges in the
health care industry and beyond. We refer readers to section VIII.C.6
of this preamble for a detailed discussion of how we are addressing
this issue in this rule.
i. Responding to Requests
We proposed that, upon receiving a request to license or use
interoperability elements, an actor would be required to respond to the
requestor within 10 business days from receipt of the request. We noted
that the request could be made to ``license'' or ``use'' the
interoperability elements because a requestor may not always know that
``license'' is the legal mechanism for ``use'' when making the request
(84 FR 7546).
In order to meet this condition, we proposed that the actor would
be required to respond to the requestor within 10 business days from
the receipt of the request by: (1) Negotiating with the requestor in a
RAND fashion to identify the interoperability elements that are needed;
and (2) offering an appropriate license with RAND terms, consistent
with its other obligations under the exception. We emphasized that, in
order to qualify for the proposed exception, the actor would only be
required to negotiate with the requestor in a RAND fashion and to offer
a license with RAND terms. We proposed that the actor would not be
required to grant a license in all instances. We did not propose a set
timeframe for when the negotiations must be resolved (84 FR 7546).
We requested comment on whether 10 business days is an appropriate
amount of time for the actor to respond to the requestor. We noted that
we considered proposing response timeframes ranging from 5 business
days to 15 business days. We also considered proposing two separate
timeframes for: (1) Negotiating
[[Page 25891]]
with the requestor; and (2) offering the license. We stated that if
commenters prefer a different response timeframe or approach than
proposed, we requested that commenters explain their rationale with as
much detail as possible. In addition, we requested comment on whether
we should create set limits for: (1) The amount of time the requestor
has to accept the actor's initial offer or make a counteroffer; (2) if
the requestor makes a counteroffer, the amount of time the actor has to
accept the requestor's counteroffer or make its own counteroffer; and
(3) an allowable number of counteroffers in negotiations (84 FR 7546).
Comments. We received many comments regarding the proposed
framework and timeframe for responding to requests to license or use
interoperability elements. Some commenters were supportive of our
proposal and stated that 10 business days is an appropriate amount of
time for the actor to respond to the requestor. Other commenters
disagreed with the proposed timeframe, explaining that 10 business days
is insufficient time to begin a license negotiation. Commenters
suggested various alternate timeframes ranging from 20 to 90 business
days. One commenter requested that ONC consider differentiating the
timeline expected for making an offer predicated on an interoperability
element being available as an existing capability, as opposed to an
interoperability element requiring new formal licensure or requiring
one off ``custom'' or ``spec'' development. Another commenter
recommended that the process be divided into a series of steps with a
requirement that a request for information be acknowledged and
negotiations begin within 10 business days and completed within 20
business days. One commenter recommended that the 10-day timeframe be
for beginning negotiations with the intent to furnish a quotation for a
license. Some commenters stated that timeframes should not be set, as
the license negotiation process is highly variable based on the
specific requestor and circumstances. One commenter expressed concern
that the proposed exception would increase the administrative burden on
covered entities, particularly regarding the response timeframe and the
actor's inability to review and/or vet the appropriateness of a request
before responding.
Response. We thank commenters for these thoughtful comments. To be
responsive to comments, we have updated the response and license
negotiation framework and timeframe. The finalized provision in Sec.
171.303(a) states that, upon receiving a request to license an
interoperability element for the access, exchange, or use of EHI, the
actor must: (1) Begin license negotiations with the requestor within 10
business days from receipt of the request (Sec. 171.303(a)(1)); and
(2) negotiate a license with the requestor, subject to the licensing
conditions in paragraph (b) of the exception, within 30 business days
from receipt of the request (Sec. 171.303(a)(2)). We note that the
expectation in (2) above is that the actor will negotiate with the
requestor in good faith. If it is determined that the negotiation is
not in good faith, the actor would not qualify for this exception.
These provisions create a clear and administrable timeline for actors
to follow that is informed by stakeholder comments and will reduce
potential burden on actors. Further, it provides actors with
appropriate flexibility for negotiating a good faith license, taking
into consideration the potential complexity and variability associated
with negotiations for licensing interoperability elements.
In instances when an actor is unable to negotiate a good faith
license subject to the requirements in Sec. 171.303(a)(2), the actor
may not meet the conditions of this exception. As part of an
information blocking investigation, ONC and OIG may consider
documentation or other writings maintained by the actor around the time
of the request that indicate why the actor was unable to meet the
conditions. This would not permit the actor to be covered by this
exception, but discretion in determining whether to enforce the
information blocking provision may be exercised.
We note that we have revised paragraph Sec. 171.303(a) by changing
``a request to license or use'' to ``a request to license'' for
clarity. We emphasize, however, that this change does not alter the
meaning or application of the provision. We reiterate, as we proposed,
that the request could be made to ``license'' or ``use'' the
interoperability elements because a requestor may not always know that
``license'' is the legal mechanism for ``use'' when making the request
(see 84 FR 7546). We believe it is unnecessary to include ``or use'' in
the regulation text because actors should know that a request to
``use'' would be synonymous with a request to ``license'' and would
thus be covered by this exception. Further, the inclusion of ``or use''
could be confusing since ``use'' is a defined term in the context of
``access, exchange, or use'' of EHI, but would carry different meaning
in the context of ``using'' an interoperability element, as opposed to
``using'' EHI.
ii. Licensing Conditions
We proposed to require, as a condition of this exception, that any
terms upon which an actor licenses interoperability elements must be
reasonable and non-discriminatory (RAND). We recognized in the Proposed
Rule that strong legal protections for IP rights can promote
competition and innovation. Nevertheless, IP rights can also be abused
in ways that undermine these goals. We explained that we believe this
potential for abuse is heightened when the IP rights pertain to
functional aspects of technology that are essential to enabling
interoperability. We emphasized that to the extent that the
interoperability elements are essential to enable the efficient access,
exchange, or use of EHI by particular persons or for particular
purposes, any practice by the actor that could impede the use of the
interoperability elements for that purpose--or that could unnecessarily
increase the cost or other burden of using the elements for that
purpose--would give rise to an obvious risk of interference with
access, exchange, or use of EHI under the information blocking
provision (84 FR 7546).
We explained that our goal was to balance the need for IP
protections with the need to ensure that this proposed exception does
not permit actors to abuse their IP or other proprietary rights in
inappropriate ways that would block the development, adoption, or use
of interoperable technologies and services. The abuse of IP rights in
such ways is incompatible with the information blocking provision,
which protects the investments that taxpayers and the health care
industry have made to adopt technologies that will enable the efficient
sharing of EHI to benefit consumers and the health care system. We
emphasized that while actors are entitled to protect and exercise their
IP rights, to benefit from the exception to the information blocking
provision they must do so on terms that do not undermine these efforts
and prevent the appropriate flow of EHI. We proposed that these
requirements would apply to both price terms (such as royalties and
license fees) and other terms, such as conditions or limitations on
access to interoperability elements or the purposes for which they can
be used (see 84 FR 7546).
Comments. Several health IT developers strongly disagreed with the
framework and conditions of this exception. These commenters stated
that compulsory licensing of health IT on RAND terms is inconsistent
with the usual use of RAND with regards to
[[Page 25892]]
standards development. The commenters opined that the proposed
exception is a significant overstep that exceeds Congressional intent
in the Cures Act and would have a detrimental effect on innovation in
the industry. Commenters stated that IP rights would not be adequately
protected under the exception, as the exception would allow
unprecedented access to IP, and requested that ONC better protect IP
rights in the final rule. One commenter recommended that ONC make clear
that there are other ways for actors to be in compliance with the
information blocking provision besides licensing interoperability
elements to all.
Response. We appreciate these comments. Responsive to these
comments, we have removed all references to ``RAND.'' However, we have
finalized the majority of the substantive conditions for the licensing
of interoperability elements under this exception (Sec. 171.303(b)) as
proposed (i.e., the sections on scope of rights, reasonable royalty,
non-discriminatory terms, collateral terms, and non-disclosure
agreement), with slight modifications discussed below.
In response to comments regarding compulsory licensing, we
emphasize that we do not view this exception as constituting compulsory
licensing. Each exception is voluntary and actors may choose whether or
not they want to seek coverage under an exception. The exceptions
operate to the benefit of actors and are intended to provide actors
with certainty that certain practices that would normally constitute
information blocking will not be considered information blocking,
provided the actor's practice meets the conditions of the exception.
The fact that a practice to license interoperability elements does not
meet the conditions of an exception does not mean that the practice
would necessarily constitute information blocking. As a result,
practices that do not meet the exception will have to be reviewed on a
case-by-case basis in order to assess the specific facts and
circumstances and to determine, for example, the actor's intent and
whether the practice rises to the level of an interference.
In addition, under the Content and Manner Exception (Sec.
171.301), we establish that an actor is not required to respond to a
request to access, exchange, or use EHI in the manner requested if the
actor would be required to license IP and cannot reach agreeable terms
for the license with the requestor (Sec. 171.301(b)(1)(ii)). This
provision allows actors who do not want to license their IP to respond
in an alternative manner that does not require the licensing of
proprietary IP. Further, if the actor chooses to respond in the manner
requested, and such manner requires the licensing of an
interoperability element(s), the actor could license the
interoperability elements(s) with whatever terms the actor chooses, so
long as the actor is able to reach agreeable terms with the requestor.
We refer readers to the discussion in the Content and Manner Exception
in VIII.D.2.a, which highlights how the Content and Manner Exception
supports an actor's ability to protect their IP.
We understand and appreciate that health IT developers and other
entities have invested significant resources to innovate and our
policies aim to support these innovations and advancements regarding
the access, exchange, and use of EHI. We stress that this exception was
drafted with innovation in mind and operates to benefit health IT
developers and other actors by allowing them to obtain remuneration for
their IP. The Cures Act did not create a specific carve out to the
information blocking provision for IP rights, but did provide HHS with
the authority to establish reasonable and necessary exceptions that do
not constitute information blocking. We interpret the definition of
information blocking in the Cures Act (section 3022(a) of the PHSA) to
encompass any fee that materially discourages or otherwise inhibits the
access, exchange, or use of EHI, so long as the actor has the requisite
intent in the statute. Thus, without clarifying this exception, an
actor could implicate the information blocking provision whenever it
charged any royalty to license its interoperability elements. We
believe this broad interpretation of the information blocking provision
would have a detrimental effect of innovation, competition, and
consumer welfare. As such, we established this exception to provide
assurances to actors that licensing of interoperability elements for
access, exchange, or use will not be considered information blocking,
so long as the actor's practice meets all conditions in the exception.
We reiterate that the actor would also need to have the requisite
intent, as set forth in the statute. We emphasize that actors are able
to make reasonable profits from the licensing of interoperability
elements, so long as such profits comply with the ``reasonable
royalty'' provision in this exception in Sec. 171.303(b)(2). We also
note that the non-disclosure agreement provision in Sec. 171.303(b)(5)
establishes additional IP protections.
We emphasize that, in the context of information blocking, control
of interoperability elements is often a proxy for control of access,
exchange and use of EHI. For example, where EHI is stored in a
proprietary format, the EHI cannot be accessed or used if information
about the proprietary format does not accompany the EHI. Similarly,
when EHI is stored electronically, a technological solution must exist
to make the EHI available for use by others. We clarify that health IT
developers are not required to license all of their IP. As discussed
earlier in this section, an actor would not need to seek coverage under
this exception if the actor's practice is not likely to interfere with
the access, exchange, or use of actual EHI. Thus, an essential element
of the information blocking provision is that there is actual EHI at
stake. Further, as discussed above, there would also need to be a nexus
between a requestor's need to license an interoperability element and
the existing EHI. If there is not such a nexus, the actor would not
need to seek coverage under this exception (see the Privacy Exception
discussion in VIII.D.1.b).
We clarify that, if an actor licenses an interoperability element
to one requestor, the actor must license that same interoperability
element to future similarly situated requestors with the same terms.
Once an actor has granted a license for a particular interoperability
element, an actor cannot choose to license an interoperability element
to one requestor and then refuse or use different terms to license the
same interoperability element to a second similarly situated requestor,
even if the actor offers to provide the EHI via an alternative manner
in accordance with the Content and Manner Exception in Sec. 171.301.
In other words, an actor cannot pick and choose who can license a given
interoperability element or who gets favorable license terms based on
the actor's relationship with the requestor.
Comments. A couple of commenters noted that there is a wide-
spectrum of perspectives among stakeholders of common license agreement
terms such as limitations on liability and indemnification, which may
make reasonableness and non-discriminatory aspects challenging to
interpret.
Response. We appreciate these concerns and understand that there is
the potential for significant variability in the terms included in
license agreements, particularly for licensing interoperability
elements. We believe the conditions adopted in this final exception are
clear, equitable, and implementable. We emphasize that each information
blocking case will turn on its own unique facts and circumstances.
[[Page 25893]]
This fact-based approach is appropriate for this exception particularly
due to the potential variability in interoperability elements and
licensing terms noted by the commenters.
Scope of Rights
To qualify for the proposed exception, we proposed that the actor
must license the requested interoperability elements with all rights
necessary to access and use the interoperability elements for the
following purposes, as applicable:
All rights necessary to access and use the
interoperability elements for the purpose of developing products or
services that are interoperable with the actor's health IT or with
health IT under the actor's control and/or any third party who
currently uses the actor's interoperability elements to interoperate
with the actor's health IT or health IT under the actor's control.
These rights would include the right to incorporate and use the
interoperability elements in the licensee's own technology to the
extent necessary to accomplish this purpose.
All rights necessary to market, offer, and distribute the
interoperable products and services described above to potential
customers and users, including the right to copy or disclose the
interoperability elements as necessary to accomplish this purpose.
All rights necessary to enable the use of the
interoperable products or services in production environments,
including using the interoperability elements to access and enable the
exchange and use of EHI (84 FR 7546 and 7547).
We requested comment on whether these rights are sufficiently
inclusive to support licensees in developing interoperable
technologies, bringing them to market, and deploying them for use in
production environments. We also requested comment on the breadth of
these required rights and if they should be subject to any limitations
that would not interfere with the uses we have described above (84 FR
7547).
Comments. We received a couple of comments regarding the scope of
rights under this exception. One commenter recommended that ONC specify
that actors can require that licensees of the proprietary IP embodied
in an interoperability element use that IP only for the licensed
purpose, or ONC should allow actors to decline to license that IP at
all. One commenter suggested that we broaden the scope of rights
regarding the development of products or services that are
interoperable so that interoperability does not need to be tied to the
actor's health IT, health IT under the actor's control, or any third
party who currently uses the actor's interoperability elements to
interoperate with the actor's health IT or health IT under the actor's
control.
Response. We thank commenters for these thoughtful comments. We
have streamlined the ``scope of rights'' section of this exception for
clarity and to align with the overarching goal throughout the
information blocking section of enabling the access, exchange, and use
of EHI. The finalized ``scope of rights'' section in Sec.
171.303(c)(1) states that the license must provide all rights necessary
to: (1) Enable the access, exchange, or use of EHI; and (2) achieve the
intended access, exchange, or use of EHI via the interoperability
element(s). These rights replaced the rights we proposed in the ``scope
of rights'' section (see proposed Sec. 171.206(b)(1)(i)-(iii) and 84
FR 7546 and 7547) because they more clearly and succinctly explain the
scope of rights we were trying to convey in the Proposed Rule. The
proposed scope of rights included examples that are not necessary in
the regulatory text.
Regarding the comment that we should specify that actors can
require that licensees of the proprietary IP embodied in an
interoperability element use that IP only for the licensed purpose, or
ONC should allow actors to decline to license that IP at all, we
clarify that actors may require that licensees of the proprietary IP
embodied in an interoperability element only use that IP for the
licensed purpose, so long as such limits are in compliance with all the
conditions in Sec. 171.303, including the scope of rights provisions
in Sec. 171.303(c)(1). For instance, an actor could place a limitation
in the license that the license only covers a one-time use of the
interoperability element for accessing and exchanging certain EHI. In
this scenario, this limitation could be allowed under the exception if:
(1) Despite the limitation, the licensee's request for access,
exchange, or use of EHI is met; and (2) the limitation complies with
the conditions in Sec. 171.303. Similarly, if an app developer
requests to license a health IT developer's interoperability element in
order to enable the exchange of EHI by integrating the app developer's
CDS software into Provider A's EHR, the health IT developer could scope
the rights in the license to restrict the app developer from using the
license to complete the same integration for Provider B, so long as the
license complies with the conditions in Sec. 171.303. We also
emphasize that under the Content and Manner Exception (Sec. 171.301),
actors are decline to license their proprietary IP so long as they are
able to respond to the request to access, exchange, or use EHI through
an alternative manner specified in Sec. 171.301(b)(2)(ii)(A)-(C).
We have decided not to broaden the scope of rights regarding the
development of products or services that are interoperable as suggested
by the commenter because we believe this provision, as proposed, is
appropriately tailored to addresses information blocking and should be
focused on health IT under the actor's control or any third party who
currently uses the actor's interoperability elements to interoperate
with health IT under the actor's control.
Reasonable Royalty
As a condition of this exception, we proposed that if an actor
charges a royalty for the use of interoperability elements, the royalty
base and rate must be reasonable. Importantly, we proposed that the
reasonableness of any royalties would be assessed solely on the basis
of the independent value of the actor's technology to the licensee's
product, not on any strategic value stemming from the actor's control
over essential means of accessing, exchanging, or using EHI (84 FR
7547).
In evaluating the actor's assertions and evidence that the royalty
was reasonable, we proposed that ONC may consider the following
factors:
The royalties received by the actor for the licensing of
the proprietary elements in other circumstances comparable to RAND-
licensing circumstances.
The rates paid by the licensee for the use of other
comparable proprietary elements.
The nature and scope of the license.
The effect of the proprietary elements in promoting sales
of other products of the licensee and the licensor, taking into account
only the contribution of the elements themselves and not of the
enhanced interoperability that they enable.
The utility and advantages of the actor's interoperability
element over the existing technology, if any, that had been used to
achieve a similar level of access, exchange, or use of EHI.
The contribution of the elements to the technical
capabilities of the licensee's products, taking into account only the
value of the elements themselves and not the enhanced interoperability
that they enable.
The portion of the profit or of the selling price that may
be customary in the particular business or in comparable businesses to
allow for the use of the proprietary elements or analogous
[[Page 25894]]
elements that are also covered by RAND commitments.
The portion of the realizable profit that should be
credited to the proprietary elements as distinguished from non-
proprietary elements, the manufacturing process, business risks,
significant features or improvements added by the licensee, or the
strategic value resulting from the network effects, switching costs, or
other effects of the adoption of the actor's technology.
The opinion testimony of qualified experts.
The amount that a licensor and a licensee would have
agreed upon (at the time the licensee began using the elements) if both
were considering the RAND obligation under the exception and its
purposes, and had been reasonably and voluntarily trying to reach an
agreement (84 FR 7547).
We noted that these factors mirror those used by courts that have
examined the reasonableness of royalties charged pursuant to a
commitment to a standards developing organization to license standard-
essential technologies on RAND terms (see Microsoft Corp. v. Motorola,
Inc.; \187\ In re Innovatio IP Ventures, LLC Patent Litig.; \188\ and
Realtek Semiconductor Corp. v. LSI Corp. \189\ ). We noted, however,
that we adapted the factors to the information blocking context (84 FR
7547).
---------------------------------------------------------------------------
\187\ Case No. 10-cv-1823 JLR, 2013 WL 2111217 (W.D.Wash. Apr.
25, 2013).
\188\ MDL 2303, 2013 WL 5593609 (N.D.Ill. Oct. 3, 2013).
\189\ Case No. 5:12-cv-03451-RMW, 2014 WL 46997 (N.D.Cal. Jan.
6, 2014).
---------------------------------------------------------------------------
We proposed that the RAND inquiry should focus on whether the
royalty demanded by the actor represents the independent value of the
actor's proprietary technology. We proposed that if the actor has
licensed the interoperability element through a standards developing
organization in accordance with such organization's policies regarding
the licensing of standards-essential technologies on RAND terms, the
actor may charge a royalty that is consistent with such policies. We
proposed that we would ask whether the actor is charging a royalty that
is not based on the value of its technology (embodied in the
interoperability elements) but rather includes the strategic value
stemming from the adoption of that technology by customers or users. We
proposed that we would consider the technical contribution of the
actor's interoperability elements to the licensee's products--such as
any proprietary capabilities or features that the licensee uses in its
product--but would screen out any functional aspects of the actor's
technology that are used only to establish interoperability and enable
EHI to be accessed, exchanged, and used. Additionally, we proposed that
to address the potential risk of royalty stacking, we would need to
consider the aggregate royalties that would apply if owners of other
essential interoperability elements made royalty demands of the
implementer. Specifically, we proposed that, to qualify for the
exception, the actor must grant licenses on terms that are objectively
commercially reasonable taking into account the overall licensing
situation, including the cost to the licensee of obtaining other
interoperability elements that are important for the viability of the
products for which it is seeking to license interoperability elements
from the actor (84 FR 7547 and 7548).
We clarified that this condition would not preclude an actor from
licensing its interoperability elements pursuant to an existing RAND
commitment to a standards developing organization. We also noted that,
in addition to complying with the requirements described above, to meet
this proposed condition, any royalties charged must meet the condition,
proposed separately below, that any license terms be non-discriminatory
(84 FR 7548).
We requested comment on these aspects of the proposed exception. We
encouraged commenters to consider, in particular, whether the factors
and approach we described will be administrable and appropriately
balance the unreasonable blocking by actors of the use of essential
interoperability elements with the need to provide adequate assurance
to investors and innovators that they will be able to earn a reasonable
return on their investments in interoperable technologies. Further, we
noted that if our proposed approach did not adequately balance these
concerns or would not achieve our stated policy goals, we asked that
commenters suggest revisions or alternative approaches. We asked that
such comments be as detailed as possible and provide rigorous economic
justifications for any suggested revisions or alternative approaches
(84 FR 7548).
Comments. We received many comments regarding reasonable royalties
and the ability of actors to make a profit. Some commenters supported
the proposed framework. A couple of commenters recommended that we not
allow any royalty for licensing interoperability elements. One of those
commenters suggested we require ``RAND-Zero'' licensing, by which the
copyright holder may still impose non-discriminatory licensing terms on
the licensee but may not charge a royalty. The commenter also expressed
concern that the overlap between this exception and the exception for
recovering costs reasonably incurred creates the potential for actors
to earn a double recovery. The commenter explained that licensing of IP
is intended to recoup the costs of development of that IP, so where the
IP is an interoperability element, the costs reasonably incurred for
its development should be incorporated into the royalty rate. The
commenter recommended that we be clearer that in these circumstances,
only a single recovery is permitted. Provider and registry
organizations were concerned that the ability to charge reasonable
royalties to license interoperability elements may present an opening
for health IT developers to charge unreasonably high fees for
exchanging information with provider groups and registries. As such,
the commenters recommended that ONC require actors to disclose the
methodology behind their fees.
Alternatively, other commenters, consisting primarily of health IT
developers, expressed concern that the proposals regarding reasonable
royalties were too restrictive. Commenters were concerned that the
exception, as proposed, would have a detrimental effect on innovation
in the industry as it provides disincentives for established companies
to develop new, forward-leaning solutions. A few commenters recommended
that the value of the actor's technology must be constructed on a
``fair market'' basis. Commenters stated that ONC should not set or
determine the reasonableness of royalties. However, if ONC decided to
set or define the reasonableness of royalties, the primary factor for
such a determination should be the willingness of licensees to agree to
a given royalty rate. A couple of commenters requested clarification
regarding ONC's approach for calculating reasonable royalties and ONC's
basis for determining whether a royalty is ``reasonable.''
Response. We thank commenters for these thoughtful comments. First,
we note, as discussed previously in this section, we have removed all
references to ``RAND.'' However, we have finalized this reasonable
royalty provision (Sec. 171.303(c)(2)) as proposed, with a slight
modification for consistency and the addition of a paragraph in Sec.
171.303(c)(2)(iv). The slight modification was made to Sec.
171.303(c)(2)(iii), in which we deleted ``on reasonable and non-
discriminatory terms'' in order to align with the overall approach of
removing ``RAND''
[[Page 25895]]
throughout the exception. In response to comment, we added a paragraph
in Sec. 171.303(c)(2)(iv) to address the potential for double recovery
in this exception and the Fees Exception (Sec. 171.302). The new
paragraph states that an actor may not charge a royalty for IP if the
actor recovered any development costs pursuant to Sec. 171.302 that
led to the creation of the IP.
In response to the commenters who expressed concern that our
approach for allowing reasonable royalties is too restrictive and could
slow innovation, we emphasize that our regulatory approach to
implementing the information blocking provision of the Cures Act is
informed by years of research and stakeholder engagement indicating
that information blocking undermines public and private sector
investments in the nation's health IT infrastructure and frustrates
efforts to use modern technologies to improve health care quality and
efficiency, accelerate research and innovation, and provide greater
value and choice to health care consumers. In our experience,
contractual and IP rights are frequently used to extract rents for
access to EHI or to prevent competition from health IT developers of
interoperable technologies and services. These practices frustrate
access, exchange, and use of EHI and stifle competition and innovation
in the health IT sector.
We believe the general claim that the limits on licensing royalties
within this exception would inhibit innovation misstates the
experiences many stakeholders face today. Our experience in the health
IT industry has highlighted that innovation has struggled under current
market practices, in which there is no limit on fees and royalties for
access and use of interoperability elements. In fact, the ability of
large entities with significant market power to prevent access and use
of essential interoperability elements has prevented and continues to
prevent large amounts of potential investment in innovative solutions
for the United States health care market. We also refer readers to the
Content and Manner Exception (Sec. 171.301), where we further address
commenter concerns regarding protections for their proprietary IP.
We also appreciate the comments that suggested we not allow any
royalty for licensing interoperability elements because allowing a
royalty could create an opening for actors to continue to charge
unreasonably high fees for the exchange of EHI. We have decided to
allow reasonable royalties that must meet certain requirements (see
Sec. 171.303(b)(2)) because the allowance of such royalties will
promote competition, consumer welfare, and investment in innovation.
The conditions we have finalized in Sec. 171.303(b)(2) are
specifically tailored to address the type of abuse about which
commenters expressed concern. Under the finalized reasonable royalty
provision, it would generally be appropriate for actors to license
their IP on terms that are non-discriminatory and do not interfere with
the access, exchange, or use of EHI so long as the actor meets all of
the conditions in Sec. 171.303. We emphasize that actors are able to
make reasonable profits from the licensing of interoperability
elements, so long as such profits comply with Sec. 171.303(b)(2).
These licensing practices will further the goals of the information
blocking provision by allowing actors to protect the value of their
innovations and earn returns on the investments they have made to
develop, maintain, and update those innovations. This approach will
also protect future incentives to invest in, develop, and disseminate
interoperable technologies and services that could improve the lives
and safety of patients nationwide.
We acknowledge that limiting the royalties IP holders can charge
for access, exchange, or use of EHI departs from IP policy. Absent
specific circumstances, IP holders are generally free to negotiate with
prospective licensees to determine the royalty to practice their IP,
and this negotiated royalty frequently reflects the value the licensee
would obtain from exercising those rights. However, in the context of
EHI, a limitation on royalties is essential due to the likelihood that
unreasonable royalties would frustrate access, exchange, and use of the
EHI, particularly because of the imbalanced power dynamics that
currently exist in the health IT market.
In response to commenters who requested clarification regarding
ONC's approach for calculating reasonable royalties, we emphasize that
each case of potential information blocking, as well as the
``reasonableness'' of a royalty, will hinge on the specific facts and
circumstances of the case. We explained in the Proposed Rule that the
actor would need to show that the royalty base was reasonable and that
the royalty was within a reasonable range for the interoperability
elements at issue. Importantly, we explained that the reasonableness of
any royalties would be assessed solely on the basis of the independent
value of the actor's technology to the licensee's product, not on any
strategic value stemming from the actor's control over essential means
of accessing, exchanging, or using EHI (84 FR 7547 and 7548). For
additional clarification regarding the specific factors to be
considered in evaluating an actor's assertion and evidence that a
royalty was reasonable, we refer reader to the discussion above and the
discussion in the Proposed Rule regarding reasonable royalties (see 84
FR 7547 and 7548).
Non-Discriminatory Terms
We proposed that for the exception to apply, the terms on which an
actor licenses and otherwise provides interoperability elements must be
non-discriminatory. We explained that this condition would apply to
both price and non-price terms, and thus would apply to the royalty
terms discussed immediately above as well as other types of terms that
may be included in licensing agreements or other agreements related to
the provision or use of interoperability elements (84 FR 7548).
We proposed that to comply with this condition, the terms on which
the actor licensed the interoperability elements must be based on
criteria that the actor applied uniformly for all substantially similar
or similarly situated classes of persons and requests. In order to be
considered non-discriminatory, such criteria would have to be objective
and verifiable, not based on the actor's subjective judgment or
discretion. We emphasized that this proposal does not mean that the
actor must apply the same terms for all persons or classes of persons
requesting a license. However, any differences in terms would have to
be based on actual differences in the costs that the actor incurred or
other reasonable and non-discriminatory criteria. Moreover, we proposed
that any criteria upon which an actor varies its terms or conditions
would have to be both competitively neutral--meaning that the criteria
are not based in any part on whether the requestor or other person is a
competitor, potential competitor, or will be using EHI obtained via the
interoperability elements in a way that facilitates competition with
the actor--and neutral as to the revenue or other value that the
requestor may derive from access, exchange, or use of the EHI obtained
via the interoperability elements, including any secondary use of such
EHI (84 FR 7548). For a detailed example regarding this proposed
condition, see the Proposed Rule (84 FR 7548).
We noted that the foregoing conditions were not intended to limit
an actor's flexibility to set different terms based on legitimate
differences in the
[[Page 25896]]
costs to different classes of persons or in response to different
classes of requests, so long as any such classification was in fact
based on neutral criteria (in the sense described above) that are
objectively verifiable and were applied in a consistent manner for
persons and/or requests within each class. For instance, the proposed
condition would not preclude an actor from pursuing strategic
partnerships, joint ventures, co-marketing agreements, cross-licensing
agreements, and other similar types of commercial arrangements under
which it provides more favorable terms than for other persons with whom
it has a more arms-length relationship. We explained that in these
instances, the actor should have no difficulty identifying substantial
and verifiable efficiencies that demonstrate that any variations in its
terms and conditions were based on objective and neutral criteria (84
FR 7548).
We proposed that a health IT developer of certified health IT who
is an ``API Technology Supplier'' under the Condition of Certification
proposed in Sec. 170.404 would not be permitted to offer different
terms in connection with the APIs required by that Condition of
Certification. We proposed that API Technology Suppliers are required
to make these APIs available on terms that are no less favorable than
provided to their own customers, suppliers, partners, and other persons
with whom they have a business relationship (84 FR 7548 and 7549).
We requested comments on the foregoing conditions (84 FR 7549).
Comments. One commenter disagreed with the proposal that the terms
must not be based in any part on revenue or other value the requestor
may derive from access, exchange, or use of EHI obtained via the
interoperability elements, including the secondary use of such EHI. The
commenter stated that such information should be considered.
Response. We thank the commenter for this feedback, but have
decided to finalize this provision as proposed, with slight
modification. We continue to believe that license terms for licensing
interoperability elements required for the access, exchange, or use of
EHI should not be based in any part of the revenue or other value the
requestor may derive from access, exchange, or use of EHI obtained via
the interoperability elements, including the subsequent use of such
EHI. The allowance of such terms could enable the type of opportunistic
pricing and anti-competitive behavior that this exception seeks to
address. We note that we have removed the proposed example about
``secondary use'' from the regulation text because such an example is
not necessary in the regulation text (see 84 FR 7604). We emphasize,
however, that we continue to maintain that the terms must not be based
on revenue or other value derived from the subsequent use of EHI. Our
policy on this point has not changed from the Proposed Rule. The terms
and conditions could vary based on neutral, objectively verifiable, and
uniformly applied criteria. These might include, for example,
significantly greater resources consumed by certain types of apps, such
as those that export large volumes of data on a continuous basis, or
the heightened risks associated with apps designed to ``write'' data to
the EHR database or to run natively within the EHR's user interface.
We emphasize that health IT developers that license
interoperability elements in order for EHI to be accessed, exchanged,
or used could not vary the license terms and conditions based on
subjective criteria, such as whether it thinks an app will be
``popular'' or is a ``good fit'' for its ecosystem. Nor could
developers offer different terms or conditions on the basis of
objective criteria that are not competitively neutral, such as whether
an app ``connects to'' other technologies or services, provides
capabilities that the EHR developer plans to incorporate in a future
release of its technology, or enables an efficient means for customers
to export data for use in other databases or technologies that compete
directly with the EHR developer. Similarly, the EHR developer could not
set different terms or conditions based on how much revenue or other
value the app might generate from the information it collects through
the APIs, such as by introducing a revenue-sharing requirement for apps
that use data for secondary purposes that are very lucrative and for
which the EHR developer would like a ``piece of the pie.'' Such
practices would disqualify the actor from this exception and would
implicate the information blocking provision.
We note that we made a slight modification to Sec.
171.303(c)(3)(i) in that we removed ``substantially similar.'' We
believe ``similarly situated,'' without ``substantially similar'' is
clearer, maintains the intended effect, and is consistent with language
used in other exceptions.
Collateral Terms
We proposed five additional conditions that would reinforce the
requirements of the proposed exception. We explained that these
additional conditions would provide bright-line prohibitions for
certain types of collateral terms or agreements that we believe are
inherently likely to interfere with access, exchange, or use of EHI. We
proposed that any attempt to require a licensee or its agents or
contractors to do or agree to do any of the following would disqualify
the actor from the exception and would be suspect under the information
blocking provision (84 FR 7549).
First, we proposed that the actor must not require the licensee or
its agents or contractors to not compete with the actor in any product,
service, or market, including markets for goods and services,
technologies, and research and development. We explained that we are
aware that such agreements have been used to either directly exclude
suppliers of interoperable technologies and services from the market or
to create exclusivity that reduces the range of technologies and
options available to health care providers and other health IT
customers and users (84 FR 7549).
Second, we proposed that the actor must not require the licensee or
its agents or contractors to deal exclusively with the actor in any
product, service, or market, including markets for goods and services,
technologies, and research and development (84 FR 7549).
Third, we proposed that the actor must not require the licensee or
its agents or contractors to obtain additional licenses, products, or
services that are not related to or can be unbundled from the requested
interoperability elements. We explained that without this condition, we
believe that an actor could require a licensee to take a license to
additional interoperability elements that the licensee does not need or
want, which could enable the actor to extract royalties that are
inconsistent with its RAND obligations under this exception. We
clarified that this condition would not preclude an actor and a willing
licensee from agreeing to such an arrangement, so long as the
arrangement was not required (84 FR 7549).
Fourth, we proposed that the actor must not condition the use of
interoperability elements on a requirement or agreement to license,
grant, assign, or transfer the licensee's own IP to the actor. We
explained that it would raise information blocking concerns for an
actor to use its control over interoperability elements as leverage to
obtain a ``grant back'' of IP rights or other consideration whose value
may exceed that of a reasonable royalty. We proposed that, consistent
with our approach under other conditions of this exception, this
condition would not preclude an actor
[[Page 25897]]
and a willing licensee from agreeing to a cross-licensing, co-
marketing, or other agreement if they so choose. However, the actor
could not require the licensee to enter into such an agreement. We
proposed that the actor must offer the option of licensing the
interoperability elements without a promise to provide consideration
beyond a reasonable royalty (84 FR 7549).
Finally, we proposed that the actor must not condition the use of
interoperability elements on a requirement or agreement to pay a fee of
any kind whatsoever unless the fee meets either the narrowly crafted
condition to this exception for a reasonable royalty, or,
alternatively, the fee satisfies the separate exception in Sec.
171.302, which permits the recovery of certain costs reasonably
incurred (84 FR 7549).
We requested comment on these categorical exclusions. In
particular, we encouraged commenters to weigh in on our assumption that
these practices are inherently likely to interfere with access,
exchange, or use of EHI. We also encouraged commenters to suggest any
conceivable benefits that these practices might offer for
interoperability or for competition and consumers that we might have
overlooked. Again, we asked that to the extent possible commenters
provide detailed economic rationale in support of their comments (84 FR
7549).
Comments. One commenter noted that situations exist where licensors
do not have the ability to lawfully confer rights or licenses to
information or products without the agreement of a third party. The
commenter recommended that we add ``except as required by law'' to the
collateral terms provisions in order to clarify that the expectation is
not that an actor must obtain such rights on behalf of the requestor.
Response. We appreciate this comment, but have decided not to make
the suggested edit because we do not believe such an addition is
necessary. The collateral terms provisions do not address whether an
actor is expected to obtain rights from a third party to lawfully
confer rights or licenses to interoperability elements. Instead, the
collateral terms provisions describe conditions that the actors must
not require of the licensee or its agents or contractors to do because
such conditions are inherently likely to interfere with access,
exchange, or use of EHI. We note that we have revised the definition of
``interoperability element'' (see Sec. 171.102) to clarify that in
order to meet the definition, the element must be ``controlled by the
actor,'' which addresses the commenter's concern. We have also defined
``controlled by the actor'' in Sec. 171.102 in the context of the
interoperability element definition for clarity. If the actor could not
lawfully confer a right or authorization, the actor would not have the
requisite ``control'' under the ``interoperability element.'' Last, we
emphasize that in situations when an actor does not have the ability to
lawfully confer rights or licenses to enable the access, exchange, or
use of EHI, the actor could seek coverage under the Infeasibility
Exception (see Sec. 171.204(a)(3)) or the Content and Manner Exception
(see Sec. 171.301(b)).
Comments. We did not receive any other comments regarding the
proposed collateral terms proposals except those noted in the comment
summary above.
Response. We have finalized the collateral terms as proposed.
Non-Disclosure Agreement
We proposed that an actor would be permitted under this exception
to require a licensee to agree to a confidentiality or non-disclosure
agreement (NDA) to protect the actor's trade secrets, provided that the
NDA is no broader than necessary to prevent the unauthorized disclosure
of the actor's trade secrets. Further, we proposed that the actor would
have to identify (in the NDA) the specific information that it claims
as trade secrets, and that such information would have to meet the
definition of a trade secret under applicable law. We noted that if the
actor is a health IT developer of certified health IT, it may be
subject to the Condition of Certification that prohibits certain health
IT developer prohibitions and restrictions on communications about a
health IT developer's technology and business practices. We emphasized
that the exception would not in any way abrogate the developer's
obligations to comply with that condition. We encouraged comment on
this condition of the proposed exception (84 FR 7549).
Comments. We received a couple of comments regarding the proposed
NDA provision. One commenter recommended that we state in the final
rule that interoperability elements themselves may not be protected as
trade secrets. Another commenter expressed concern that this exception
acts to require NDAs in certain circumstances. The commenter also
suggested edits to preamble language that would allow the actor to
``generally'' identify the information that it claims as trade secrets,
as opposed to the proposed language of identifying the ``specific''
information that it claims as trade secrets.
Response. We thank commenters for these thoughtful comments. We
clarify that interoperability elements may be protected as trade
secrets. Trade secrets are a type of IP that consist of information and
can include a formula, pattern, compilation, program, device, method,
technique or process,\190\ and could fall within the definition of
``interoperability element'' (see Sec. 171.102). We note, as discussed
in more detail in VIII.C.5.b, that we have leveraged the definition of
``health information technology'' from section 3000(5) of the PHSA for
the definition of ``interoperability element'' in Sec. 171.102, and
that IP is included in that definition of ``health information
technology.'' The PHSA defines ``health information technology'' as
``hardware, software, integrated technologies or related licenses,
intellectual property, upgrades, or packaged solutions sold as services
that are designed for or support the use by health care entities or
patients for the electronic creation, maintenance, access, or exchange
of health information.''
---------------------------------------------------------------------------
\190\ USPTO, Trade Secret Policy, https://www.uspto.gov/patents-getting-started/international-protection/trade-secrets-policy.
---------------------------------------------------------------------------
In response to the commenter that expressed concern that this
exception acts to require NDAs in certain circumstances, we emphasize
that we are not requiring NDAs. We included this provision in order to
help actors protect their IP and actors may draft the NDA in a manner
that best suits their needs so long as the NDA meets the requisite
conditions in Sec. 171.303(b)(5). We have decided not to allow actors
to ``generally'' identify the information that they claim as trade
secrets because such a change could enable actors to make broad
assertions of trade secret protection that exceed the actual trade
secrets. The safeguards we have finalized in the NDA provision (e.g.,
that the agreement is no broader than necessary to prevent unauthorized
disclosure of the actor's trade secrets and the agreement states with
particularity all information the actor claims as trade secrets) are
necessary to ensure that the NDA is not used to impose restrictions or
burdensome requirements that are not actually necessary to protect the
actor's trade secrets and that impede the use of the interoperability
elements. We emphasize that the use of an NDA for such purposes would
preclude an actor from qualifying for this exception and would
implicate the information blocking provision.
[[Page 25898]]
iii. Additional Requirements Relating to the Provision of
Interoperability Elements
We proposed that an actor's practice would need to comply with
additional conditions that ensure that actors who license
interoperability elements on RAND terms do not engage in separate
practices that impede the use of those elements or otherwise undermine
the intent of this exception. We explained that these conditions are
analogous to the conditions described in our proposal concerning
collateral terms but address a broader range of practices that may not
be effected through the license agreements themselves or that occur
separately from the licensing negotiations and other dealings between
the actor and the licensee. Specifically, we proposed that an actor
would not qualify for this exception if it engaged in a practice that
had the purpose or effect of impeding the efficient use of the
interoperability elements to access, exchange, or use EHI for any
permissible purpose; or the efficient development, distribution,
deployment, or use of an interoperable product or service for which
there is actual or potential demand. We explained that the exception
would not apply if the developer licensed its proprietary APIs for use
by third-party apps but then prevented or delayed the use of those apps
in production environments by, for example, restricting or discouraging
customers from enabling the use of the apps, or engaging in ``gate
keeping'' practices, such as requiring apps to go through a vetting
process and then applying that process in a discriminatory or
unreasonable manner. Finally, to ensure the actor's commitments under
this exception are durable, we proposed one additional safeguard: An
actor could not avail itself of this exception if, having licensed the
interoperability elements, the actor makes changes to the elements or
its technology that ``break'' compatibility or otherwise degrade the
performance or interoperability of the licensee's products or services
(84 FR 7549 and 7550).
We emphasized that this proposed condition would in no way prevent
an actor from making improvements to its technology or responding to
the needs of its own customers or users. However, to benefit from the
exception, the actor's practice would need to be necessary to
accomplish these purposes and the actor must have afforded the licensee
a reasonable opportunity under the circumstances to update its
technology to maintain interoperability (84 FR 7550).
Comments. One commenter stated that the proposed restriction
regarding breaking compatibility or otherwise degrading the performance
or interoperability of the licensee's products or services is too
broad. The commenter suggested that ONC add procedural safeguards to
avoid misuse and unpredictable enforcement. Specifically, the commenter
recommended that ONC: (1) Institute a grace period for licensors to
provide fixes where interoperability elements are inadvertently
unavailable due to software changes; (2) permit health IT developers to
maintain their existing processes to notify customers about upgraded
standards on a reasonable timeframe; (3) allow, with a year's notice,
retirement of functionality in future versions of the software; (4)
acknowledge that the use of interoperability elements will always
require some initial work and ongoing upkeep by the licensee, such as
testing and continuous work to deploy technology at health systems with
different workflows; and (5) the ONC-administered advisory opinion
process should account for review of RAND licensing terms to provide
clarity to the regulated actors.
Response. We agree with the commenter that it is critical that the
final exceptions are transparent and cannot be misused. Each exception
should clearly explain what conduct would be covered by the exception
and what conduct falls outside the scope of the exception. In response
to the commenter, we note that we have not prevented health IT
developers from maintaining their existing processes to notify
customers about upgraded standards on a reasonable timeframe, nor have
we instituted any new policies regarding the retirement of
functionality in future versions of software. Further, we acknowledge
that the use of interoperability elements may require some initial work
and ongoing upkeep by the licensee, such as testing and continuous work
to deploy technology in health systems with different workflows.
However, we emphasize that such initial work, ongoing upkeep, or any
additional burden on licensees must meet all the conditions of this
exception as all relevant times.
We have decided not to institute a grace period for licensors to
provide fixes where interoperability elements are inadvertently
unavailable due to software changes because we do not believe such a
grace period is necessary. Having consulted with OIG, we note that OIG
generally does not pursue civil monetary penalties for actors who make
innocent mistakes or for accidental conduct. Future notice and comment
rulemaking by OIG will provide more additional detail regarding
information blocking enforcement.
We may consider developing materials in the future regarding the
application of the exceptions should the need arise. However, we
believe the final rule clearly describes the conditions actors must
meet in order to be covered by each exception, and informational
materials are not necessary at this time.
iv. Compliance With Conditions of Certification
As a final condition of the proposed exception, we proposed that
health IT developers of certified health IT who are subject to the
Conditions of Certification proposed in Sec. Sec. 170.402, 170.403,
and 170.404 must comply with all requirements of those Conditions of
Certification for all practices and at all relevant times (84 FR 7550).
Comments. We did not receive any comments on this proposed
condition.
Response. We have removed this proposed condition from the final
rule for consistency with other exceptions and for clarity, as the
condition is not necessary.
E. Additional Exceptions--Request for Information
1. Exception for Complying With Common Agreement for Trusted Exchange
In the Proposed Rule, we included a request for information (RFI)
regarding whether we should propose, in a future rulemaking, a narrow
exception to the information blocking provision for practices that are
necessary to comply with the requirements of the Common Agreement (84
FR 7552). The most recent draft Trusted Exchange Framework and Common
Agreement was released for public comment on April 19, 2019.\191\
---------------------------------------------------------------------------
\191\ ONC, Draft 2 Trusted Exchange Framework and Common
Agreement, https://www.healthit.gov/sites/default/files/page/2019-04/FINALTEFCAQTF41719508version.pdf.
---------------------------------------------------------------------------
Comments. We received over 40 comment submissions on this RFI
expressing various viewpoints on the purpose, need, and structure of a
TEFCA exception.
Response. We thank commenters for their feedback. As noted in the
Proposed Rule, we may use this feedback to inform a future rulemaking.
2. New Exceptions
In the Proposed Rule, we included an RFI regarding any potential
new exceptions we should consider for future rulemaking (84 FR 7552).
[[Page 25899]]
Comments. We received a number of requests for a new exception to
cover sensitive and/or privileged information. A health IT developer
suggested a new exception to allow actors to withhold sensitive
information. The commenter expressed concern that EHI at a certain data
class or data element level will require health care providers to exert
substantial manual effort to mediate disclosure. Health care providers
and provider organizations suggested an exception that would exempt
actors from the information blocking provision if they are protecting
privileged information. One commenter expressed concern about providing
access, exchange, or use of quality program and reporting data. A
hospital suggested that requiring providers to waive privilege in order
to avoid information blocking would have a detrimental effect on peer
reviews and safety assessments that help providers resolve adverse
events.
Response. We thank commenters for these suggestions. We first note
that the health information must fall within the EHI definition, which
aligns with the ePHI definition contained in the HIPAA Rules. We note
that actors faced with a request to access, exchange, We note that
actors faced with a request to access, exchange, or use sensitive and/
or privileged information can seek coverage under the exceptions for
preventing harm (Sec. 171.201), promoting the privacy of EHI (Sec.
171.202), promoting the security of EHI (Sec. 171.203), or
infeasibility (Sec. 171.204), depending on the specific information at
issue and the circumstances of the case. We refer readers to those
exceptions, as well as the preamble discussions at sections VIII.D.1
(Preventing Harm Exception), VIII.D.2 (Privacy Exception), VIII.D.3
(Security Exception), and VIII.D.4 (Infeasibility Exception). We also
note that an actor would not be required to share EHI if the
interference with access, exchange, or use of the EHI is explicitly
required by State or Federal law (see the discussion regarding
``required by law'' at section VIII.C.1 of this preamble). We emphasize
that this final rule does not require actors to waive privilege
provided by law.
Comments. Some commenters expressed concern about the effect of the
information blocking provision on research. Public health organizations
proposed an exception to exclude research (as defined by 45 CFR
164.501) and non-direct clinical care conducted by public health
authorities, from implicating the information blocking provision. A
hospital requested that we establish a new sub-exception under the
exception for preventing harm that would allow health care providers
who conduct research at their institutions to require that other
providers who request EHI are also collaborators in that research. One
commenter suggested an exception for health care providers who cannot
send data to a public health registry when the public health agency is
not ready to onboard the provider due factors outside of the provider's
control (e.g., lack of resources or a backup in the onboarding queue).
Response. We thank commenters for these suggestions. We note that
actors faced with a request to access, exchange, or use EHI related to
research can seek coverage under the exceptions for promoting the
privacy of EHI (Sec. 171.202) or infeasibility (Sec. 171.204),
depending on the specific research being conducted and EHI at issue. We
refer readers to those exceptions, as well as the preamble discussions
at sections VIII.D.2 (Privacy Exception) and VIII.D.4 (Infeasibility
Exception). We also note that an actor would not be required to share
EHI if the interference with access, exchange, or use of the EHI is
explicitly required by State or Federal law (see the discussion
regarding ``required by law'' at section VIII.C.1 of this preamble).
Comments. Some commenters requested a new exception to protect
actors who seek independent opinions from external validators regarding
their business practices, in case one of those practices falls within
the definition of information blocking.
Response. We appreciate this suggestion. With regard to private
``external validators,'' we note that we are not restricting an actor's
ability to hire private companies to assess its business practices.
Comments. A commenter recommended an exception for standard
business practices. The commenter explained that examples of such
conduct include suspending the access of any health IT developer or e-
prescribing application that is not compliant with State laws or uses
the provider's technology platform for reasons that compromises the
integrity of the provider's network (e.g., using the network for
commercial messaging).
Response. We appreciate this suggestion. While we would need more
facts to properly assess these scenarios, we believe that such
situations could likely be covered by either the exception for
promoting the privacy of EHI (Sec. 171.202) or the exception for
promoting the security of EHI (Sec. 171.203). We refer readers to
those exceptions, as well as the preamble discussions at sections
VIII.D.2 (Privacy Exception) and VIII.D.3 (Security Exception). We also
note that the actor would not be required to share EHI if the
interference with access, exchange, or use of the EHI is explicitly
required by State or Federal law (see the discussion regarding
``required by law'' at section VIII.C.1 of this preamble).
F. Complaint Process
We explained in the Proposed Rule that section 3022(d)(3)(A) of the
PHSA directs the National Coordinator to implement a standardized
process for the public to submit reports on claims of information
blocking (84 FR 7552). Section 3022(d)(3)(B) further requires that the
complaint process provide for the collection of such information as the
originating institution, location, type of transaction, system and
version, timestamp, terminating institution, locations, system and
version, failure notice, and other related information.
In the Proposed Rule, we stated that we intend to implement and
evolve the complaint process by building on existing mechanisms,
including the process for providing feedback and expressing concerns
about health IT that is currently available at https://www.healthit.gov/healthit-feedback (84 FR 7553). We requested comment
on this approach and any alternative approaches that would best
effectuate this aspect of the Cures Act. In addition to any other
comments that the public may have wished to submit, we specifically
requested comment on several specific questions. The scope of these
questions was specific to the information blocking complaint submission
process and the information collection necessary to enable effective
investigations and safeguard the confidentiality of information
submitted through the complaint process.
Comments. We received over 25 comment submissions that included
suggestions for the information blocking complaint process. A few
commenters responded to one or more of the specific questions in the
Proposed Rule, offering suggestions for specific data elements that
complainants should be able to enter as part of a complaint. Some
commenters suggested specific features such as: A dedicated secure
online portal for entry of information blocking complaints and any
supporting documents; a dedicated email box or toll-free phone number
for submission of information blocking complaints; the ability to batch
multiple instances of potential information blocking activity by the
same actor into one complaint submission; and a user interface of pick-
lists to help submitters more easily categorize their concerns and/or
mark specific portions of or attachments to
[[Page 25900]]
their complaints according to their level of sensitivity or requested
confidentiality. Numerous commenters expressed support for the
existence of a publicly available, user-friendly complaint process and
recommended that the development and publication of the complaint
process include robust educational and informational materials. A few
commenters requested an opportunity for public comment on the complaint
process's operational details prior to it going live.
Response. We note that the complaint process is not required by
statute to be established through rulemaking and we did not intend to
give an impression that it would by including the request for
information about the complaint process in the Proposed Rule. Rather,
as was the intended outcome, we have received thoughtful suggestions
that have informed our initial rollout of the information blocking
complaint process as well as have provided considerations for further
evolution of the process.
We have identified several themes and specific suggestions in the
comments that we will address below for the purposes of transparency
and to inform stakeholders. We have developed a dedicated complaint
process that is based upon and informed by our experience with our
current health IT feedback process and the comments received on the
Proposed Rule. We also plan to publish informational materials to
accompany the rollout of this dedicated information blocking complaint
process so that potential complainants across the affected stakeholder
categories can successfully use it to submit complaints where they
believe they have experienced or observed conduct that constitutes
information blocking. While we do not anticipate publishing potential
operational details of the complaint process and submission mechanism
in advance of its rollout, we would like to amplify a point we noted in
the Proposed Rule, which is that we intend to implement and evolve the
complaint process. After we launch the information blocking complaint
process, we anticipate using our own experience and users' feedback
about the information blocking complaint process to identify
opportunities to further evolve and enhance all aspects of the
information blocking complaint process, including but not limited to
its associated informational materials.
Comments. Several commenters requested that all information
blocking complaints be publicly posted and available. Conversely, many
commenters were in strong support of ONC ensuring adequate
confidentiality for those who submit information blocking complaints.
Response. Section 3022(d)(2) of the PHSA exempts from public
disclosure ``any information that is received by the National
Coordinator in connection with a claim or suggestion of possible
information blocking and that could reasonably be expected to
facilitate identification of the source of the information'' except as
may be necessary to carry out the purpose of PHSA section 3022. We
believe the publishing of complaints could lead to the identification
of the source of the information or reasonably facilitate
identification of the source; therefore, we do not intend to make
complaints publicly available. In specific reference to health IT
developers of certified health IT, however, we note that we publish in
the Certified Health IT Product List (CHPL) information about non-
conformities with Program requirements, which would include any non-
conformities with the Information Blocking Condition of Certification
requirement. We also note that the information blocking complaint
process offers the option for users to submit anonymously, explaining
in multiple places types of submission information to exclude for those
who would like to maintain confidentiality.
Comments. Several commenters requested that complainants be
required to submit sufficient evidence of intentional information
blocking in the complaint submission process. Another commenter
suggested complainants be required to meet particular qualifications in
order to submit a formal complaint.
Response. We thank commenters for their input. However, we do not
believe requiring a complaint submission to include more than the
minimum information necessary to understand the complainant's concern
would best serve the purpose of the complaint process. We believe that
requiring that a complainant meet a proof, evidentiary, or
qualification standard as a pre-requisite to them submitting a
complaint would inappropriately discourage or prevent many individuals
and organizations who are subjected to conduct that may meet the
definition of information blocking from sharing their concerns with us.
G. Disincentives for Health Care Providers--Request for Information
Section 3022(b)(2)(B) of the PHSA provides that any health care
provider determined by OIG to have committed information blocking shall
be referred to the appropriate agency to be subject to appropriate
disincentives using authorities under applicable Federal law, as the
Secretary sets forth through notice and comment rulemaking. We
requested comment on potential disincentives and whether modifying
disincentives already available under existing Department programs and
regulations would provide for more effective deterrents (84 FR 7553).
We also sought information on the implementation of section
3022(d)(4) of the PHSA, which provides that in carrying out section
3022(d) of the PHSA, the Secretary shall, to the extent possible, not
duplicate penalty structures that would otherwise apply with respect to
information blocking and the type of individual or entity involved as
of the day before December 13, 2016--enactment of the Cures Act.
Comments. We received over 40 submissions on this RFI. We have
organized and summarized the comments by topic below.
Need for Disincentives
Views on the need for additional disincentives generally diverged
based on stakeholder type. Health care providers were generally opposed
to additional disincentives. Provider organizations were opposed to any
new disincentives. Nearly all these organizations stated that any
additional disincentives would be duplicative of disincentives for
information blocking put in place through the QPP and Promoting
Interoperability Programs. In particular, hospitals noted concerns that
they are already subject to a 75 percent negative adjustment to their
market basket increase if they are unable to make the Medicare Access
and CHIP Reauthorization Act of 2015 (MACRA)-mandated attestation that
they have not engaged in information blocking. However, a few provider
organizations noted that any new disincentives would only be
duplicative for providers that are eligible for these specific CMS-
administered programs, recognizing that the existing disincentives
under Medicare would not reach providers that do not participate in QPP
or PI Programs.
Multiple provider organizations stated that additional
disincentives would be duplicative of fines for HIPAA Rules violations
and mentioned that the Office for Civil Rights (OCR) has expressed an
intent to increase HIPAA Rules enforcement on providers.
A patient-facing app developer commented that the HIPAA Rule's
disincentives, attestation, and public reporting are not enough to
discourage information blocking.
Several health IT developers were neutral on the topic, stating
that it was
[[Page 25901]]
unclear if additional disincentives would duplicate disincentives in
other programs.
One payer, one patient advocacy organization, and one HIN were
supportive of additional provider disincentives.
The HITAC recommended that ONC work with CMS to build information
blocking disincentives into a broad range of CMS programs, and that ONC
work with other Federal departments and agencies that contract with
providers (e.g., Veterans Health Administration, Department of Defense
Military Health System, Indian Health Service, Centers for Disease
Control and Prevention) to similarly build information blocking
disincentives into contracting and other programs. The HITAC also
recommended that providers be required to attest to compliance with
requirements to avoid information blocking as part of Conditions of
Participation, Conditions for Coverage, contracts, and other similar
relationships, covering fee-for-service (FFS), value-based care, and
direct payment relationships. The HITAC noted that such an attestation
requirement could potentially allow for pursuit of serious penalties
should OIG find the provider engaged in information blocking.
Magnitude of Penalties
While health care providers were generally opposed to
disincentives, some did offer recommendations for keeping penalties to
a minimum. About half of the provider organizations commenting stated
that any fines for providers should not be at the same level as those
levied against health IT developers, HINs, and HIEs. Other provider
organizations had more specific recommendations, including a tiered
approach to penalties. One provider organization recommended a two-
tiered approach, with more significant financial penalties for large
hospitals and health systems and public reporting or QPP score
reductions for physicians. Another provider organization recommended a
tiered approach that mimics the approach used under HIPAA (as modified
by HITECH), in which penalties increase based on the nature and extent
of the violation and resulting harm. Another provider organization
recommended that organizations found to engage in information blocking
be disqualified from the PI category in QPP.
Some health IT developers recommended significant penalties for
providers. Several health IT developers recommended that ONC work with
CMS to utilize and enhance existing disincentive mechanisms, with one
developer specifically recommending utilization of the Conditions of
Participation, Conditions for Coverage, and Requirements for
Participation. One app developer recommended that fines for information
blocking be substantial and per record blocked. The HITAC stated that
fines should be significant enough to discourage problematic behavior,
encourage compliance, and incent providers to address and remediate
problematic behavior. A payer commented that fines should be consistent
with those levied against developers, HINs, and HIEs.
Enforcement
Most health care providers and provider organizations recommended
that providers be given the opportunity to become compliant before
being subject to any fines, except in instances of clear, egregious
violations. Some provider organizations recommended that there be an
appeals process for disincentives or findings that health care
providers had violated the information blocking provision, with one
organization noting that an appeals process is especially needed for
small and rural practices.
Response. We have shared all the comments received with the
appropriate agencies and offices within the Department for
consideration in subsequent rulemaking to implement section
3022(b)(2)(B) and (d) of the PHSA.
IX. Registries Request for Information
In the Proposed Rule, we included a Request for Information (RFI)
on how health IT solutions and the proposals in the Proposed Rule could
aid bidirectional exchange with registries for a wide range of public
health, quality reporting, and clinical quality improvement initiatives
(84 FR 7553). We received 75 comments in response to this RFI. We thank
commenters for their input and we may consider including this
information in a future rulemaking.
X. Patient Matching Request for Information
Patient matching is a critical component to interoperability and
the nation's health IT infrastructure. In the Proposed Rule, we
included a Request for Information (RFI) on additional opportunities
that may exist in the patient matching space and ways that ONC can lead
and contribute to coordination efforts with respect to patient matching
(84 FR 7554). We received 128 comments in response to this RFI. We
appreciate the input provided by commenters and may use this
information to inform future rulemaking.
XI. Incorporation by Reference
The Office of the Federal Register has established requirements for
materials (e.g., standards and implementation specifications) that
agencies incorporate by reference in the Code of Federal Regulations
(79 FR 66267; 1 CFR 51.5). Specifically, Sec. 51.5(b) requires
agencies to discuss, in the preamble of a final rule, the ways that the
materials they incorporate by reference are reasonably available to
interested parties and how interested parties can obtain the materials,
and to summarize, in the preamble of the final rule, the material they
incorporate by reference.
To make the materials we intend to incorporate by reference
reasonably available, we provide a uniform resource locator (URL) for
the standards and implementation specifications. In many cases, these
standards and implementation specifications are directly accessible
through the URLs provided. In instances where they are not directly
available, we note the steps and requirements necessary to gain access
to the standard or implementation specification. In most of these
instances, access to the standard or implementation specification can
be gained through no-cost (non-monetary) participation, subscription,
or membership with the adopted standards developing organization (SDO)
or custodial organization. In certain instances, where noted, access
requires a fee or paid membership. As an alternative, a copy of the
standards may be viewed for free at the U.S. Department of Health and
Human Services, Office of the National Coordinator for Health
Information Technology, 330 C Street SW, Washington, DC 20201. Please
call (202) 690-7171 in advance to arrange inspection.
The National Technology Transfer and Advancement Act (NTTAA) of
1995 (15 U.S.C. 3701 et seq.) and the Office of Management and Budget
(OMB) Circular A-119 require the use of, wherever practical, technical
standards that are developed or adopted by voluntary consensus
standards bodies to carry out policy objectives or activities, with
certain exceptions. The NTTAA and OMB Circular A-119 provide exceptions
to selecting only standards developed or adopted by voluntary consensus
standards bodies, namely when doing so would be inconsistent with
applicable law or otherwise impractical. As discussed in section IV of
this preamble, we have followed the
[[Page 25902]]
NTTAA and OMB Circular A-119 in adopting standards and implementation
specifications for adoption, including describing any exceptions in the
adoption of standards and implementation specifications. Over the years
of adopting standards and implementation specifications for
certification, we have worked with SDOs, such as HL7, to make the
standards we adopt and incorporate by reference in the Federal Register
available to interested stakeholders. As described above, this includes
making the standards and implementation specifications available
through no-cost memberships and no-cost subscriptions.
As required by 1 CFR 51.5(b), we provide summaries of the standards
we have adopted and incorporate by reference in the Code of Federal
Regulations (CFR). We also provide relevant information about these
standards and implementation specifications throughout the preamble.
We have organized the standards and implementation specifications
that we have adopted through this rulemaking according to the sections
of the Code of Federal Regulation (CFR) in which they will be codified
and cross-referenced for associated certification criteria and
requirements that we have adopted.
Content Exchange Standards and Implementation Specifications for
Exchanging Electronic Health Information--45 CFR 170.205
CMS Implementation Guide for Quality Reporting Document
Architecture Category I Hospital Quality Reporting Implementation Guide
for 2019, May 4, 2018
URL: https://ecqi.healthit.gov/system/files/QRDA_HQR_2019_CMS_IG_final_508.pdf.
This is a direct access link.
Summary: This guide is a CMS Quality Reporting Document
Architecture Category I (QRDA I) implementation guide to the HL7
Implementation Guide for CDA Release 2: Quality Reporting Document
Architecture Category I, Release 1, STU Release 5 (published December
2017), and referred to as the HL7 QRDA IG STU R5 in this guide. This
guide describes additional conformance statements and constraints for
electronic health record (EHR) data submissions that are required for
reporting information to the Centers for Medicare & Medicaid Services
(CMS) for the Hospital Inpatient Quality Reporting Program 2019
Reporting Period. The purpose of this guide is to serve as a companion
to the base HL7 QRDA I STU R5 for entities such as Eligible Hospitals
(EH), Critical Access Hospitals (CAH), and developers to submit QRDA I
data for consumption by CMS systems including for Hospital Quality
Reporting (HQR).
CMS Implementation Guide for Quality Reporting Document
Architecture Category III Eligible Clinicians and Eligible
Professionals Programs Implementation Guide for 2019, October 8, 2018
URL: https://ecqi.healthit.gov/system/files/2019_CMS_QRDA_III_Eligible_Clinicians_and_EP_IG-508.pdf.
This is a direct access link.
Summary: The Health Level Seven International (HL7) Quality
Reporting Document Architecture (QRDA) defines constraints on the HL7
Clinical Document Architecture Release 2 (CDA R2). QRDA is a standard
document format for the exchange of electronic clinical quality measure
(eCQM) data. QRDA reports contain data extracted from EHRs and other
information technology systems. The reports are used for the exchange
of eCQM data between systems for quality measurement and reporting
programs. This QRDA guide contains the CMS supplemental implementation
guide to the HL7 Implementation Guide for CDA Release 2: Quality
Reporting Document Architecture, Category III, STU Release 2.1 (June,
2017) for the 2019 performance period. This HL7 base standard is
referred to as the HL7 QRDA-III STU R2.1.
Health Level 7 (HL7[supreg]) CDA R2 Implementation Guide: C-
CDA Templates for Clinical Notes R2.1 Companion Guide, Release 2-US
Realm, October 2019
URL: http://www.hl7.org/implement/standards/product_brief.cfm?product_id=447.
Access requires a ``user account'' and a license agreement. There
is no monetary cost for a user account and license agreement.
Summary: The Companion Guide to Consolidated Clinical Document
Architecture (C-CDA) R2, provides essential implementer guidance to
continuously expand interoperability for clinical information shared
via structured clinical notes. The guidance supplements specifications
established in the Health Level Seven (HL7) CDA[supreg] R2.1 IG: C-CDA
Templates for Clinical Notes. This additional guidance is intended to
make implementers aware of emerging expectations and best practices for
C-CDA document exchange. The objective is to increase consistency and
expand interoperability across the community of data sharing partners
who utilize C-CDA for information exchange.
National Council for Prescription Drug Programs (NCPDP),
SCRIPT Standard Implementation Guide, Version 2017071 (Approval Date
for ANSI: July 28, 2017)
URL: http://www.ncpdp.org/Standards/Standards-Info.
Access requires registration, a membership fee, a user account, and
a license agreement to obtain a copy of the standard.
Summary: NCPDP SCRIPT standards are developed for transmitting
prescription information electronically between prescribers,
pharmacies, payers, and other entities for new prescriptions, changes
of prescriptions, prescription refill requests, prescription fill
status notifications, cancellation notifications, relaying of
medication history, transactions for long-term care, electronic prior
authorization and other transactions. New transactions in this update
include Prescription drug administration message, New prescription
requests, New prescription response denials, Prescription transfer
message, Prescription fill indicator change, Prescription
recertification, Risk Evaluation and Mitigation Strategy (REMS)
initiation request, REMS initiation response, REMS request, and REMS
response.
Standards for Health Information Technology To Protect Electronic
Health Information Created, Maintained, and Exchanged--45 CFR 170.210
ASTM E2147-18 Standard Specification for Audit and Disclosure
Logs for Use in Health Information Systems, approved May 1, 2018
URL: https://www.astm.org/Standards/E2147.htm.
This is a direct access link. However, a fee is required to obtain
a copy of the standard.
Summary: This specification describes the security requirements
involved in the development and implementation of audit and disclosure
logs used in health information systems. It specifies how to design an
access audit log to record all access to patient identifiable
information maintained in computer systems, and includes principles for
developing policies, procedures, and functions of health information
logs to document all disclosure of confidential health care information
to external users for use in manual and computer systems. This
specification has two main purposes, namely: To define the nature,
role, and function of system access audit logs and
[[Page 25903]]
their use in health information systems as a technical and procedural
tool to help provide security oversight; and to identify principles for
establishing a permanent record of disclosure of health information to
external users and the data to be recorded in maintaining such record
of disclosure.
United States Core Data for Interoperability--45 CFR 170.213
United States Core Data for Interoperability (USCDI), February
2020, Version 1 (v1)
URL: https://www.healthit.gov/USCDI.
This is a direct access link.
Summary: The United States Core Data for Interoperability (USCDI)
establishes a minimum set of data classes that are required to be
interoperable nationwide and is designed to be expanded in an iterative
and predictable way over time. Data classes listed in the USCDI are
represented in a technically agnostic manner.
Application Programming Interface Standards--45 CFR 170.215
HL7 FHIR[supreg] US Core Implementation Guide STU 3.1.0,
November 6, 2019
URL: http://hl7.org/fhir/us/core/STU3.1/.
This is a direct access link.
Summary: The US Core Implementation Guide STU 3.1.0 is based on
FHIR Version R4 and defines the minimum conformance requirements for
accessing patient data. The Argonaut pilot implementations, ONC 2015
Edition Common Clinical Data Set (CCDS), and the latest ONC United
States Core Data for Interoperability (USCDI) provided the requirements
for this guide. The prior Argonaut search and vocabulary requirements,
based on FHIR DSTU2, are updated in this guide to support FHIR Version
R4.
Health Level 7 (HL7) Version 4.0.1 Fast Healthcare
Interoperability Resources Specification (FHIR) Release 4, October 30,
2019
URL: http://hl7.org/fhir/R4/.
This is a direct access link.
Summary: The HL7 Version 4.0.1 Fast Healthcare Interoperability
Resources (FHIR) Release 4, which also includes technical corrections
to R4, provides the first set of normative FHIR resources. This
normative designation means that the future changes will be backward
compatible for the first time. These resources define the content and
structure of core health data which can be used by developers to build
standardized applications. Release 4 provides new standard operation on
how to obtain data from multiple patients via FHIR. API services that
focus on multiple patients would enable health care providers to manage
various internal patient populations as well as external services a
health care provider may contract for to support quality improvement,
population health management, and cost accountability vis-[agrave]-vis
the provider's partners (e.g., health plans).
HL7 FHIR Bulk Data Access (Flat FHIR) (v1.0.0: STU 1), August
22, 2019
URL: http://hl7.org/fhir/uv/bulkdata/.
This is a direct access link.
Summary: This implementation specification defines a standardized,
HL7 FHIR-based approach for exporting health information for multiple
patients from a server compliant with the HL7 FHIR standard. This
implementation specification is intended to be used by apps to request
information on multiple patients. The implementation specification
includes OperationDefinitions, which define how the multiple patient
export operations are invoked by clients, and the SMART Backend
Services: Authorization Guide, which describes how a client can
register with and obtain an access token from a server compliant with
the implementation specification.
HL7 FHIR SMART Application Launch Framework Implementation
Guide Release 1.0.0, November 13, 2018
URL: http://hl7.org/fhir/smart-app-launch/.
This is a direct access link.
Summary: SMART on FHIR provides reliable, secure authorization for
a variety of app architectures through the use of the OAuth 2.0
standard. This Authorization Guide supports the four use cases defined
for Phase 1 of the Argonaut Project. This profile is intended to be
used by developers of apps that need to access FHIR resources by
requesting access tokens from OAuth 2.0 compliant authorization
servers. The profile defines a method through which an app requests
authorization to access a FHIR resource, and then uses that
authorization to retrieve the resource. Other security mechanisms
required by the HIPAA Security Rule, such as end-user authentication,
session time-out, security auditing, and accounting of disclosures, are
outside the scope of this profile.
OpenID Connect Core 1.0 Incorporating Errata Set 1, November
8, 2014
URL: http://openid.net/specs/openid-connect-core-1_0.html.
This is a direct access link.
Summary: OpenID Connect 1.0 is a simple identity layer on top of
the OAuth 2.0 protocol. It enables clients to verify the identity of
the end user based on the authentication performed by an authorization
server, as well as to obtain basic profile information about the end
user in an interoperable and REST-like manner. This specification
defines the core OpenID Connect functionality: Authentication built on
top of OAuth 2.0 and the use of claims to communicate information about
the end user. It also describes the security and privacy considerations
for using OpenID Connect.
Incorporation by Reference--45 CFR 170.599
ISO/IEC 17025:2017(E)--General Requirements for the Competence
of Testing and Calibration Laboratories, (Third Edition), November 2017
URL: https://www.iso.org/standard/66912.html.
This is a direct access link. However, a fee is required to obtain
a copy of the standard.
Summary: This document has been developed with the objective of
promoting confidence in the operation of laboratories. This document
contains requirements for laboratories to enable them to demonstrate
they operate competently and are able to generate valid results.
Laboratories that conform to this document will also operate generally
in accordance with the principles of ISO 9001. This document requires
the laboratory to plan and implement actions to address risks and
opportunities. Addressing both risks and opportunities establishes a
basis for increasing the effectiveness of the management system,
achieving improved results, and preventing negative effects. The
laboratory is responsible for deciding which risks and opportunities
need to be addressed. This third edition cancels and replaces the
second edition (ISO/IEC 17025:2005), which has been technically
revised.
ISO/IEC 17065:2012 (E)--Conformity Assessment--Requirements
for Bodies Certifying Products, Processes and Services (First Edition),
September 2012
URL: https://www.iso.org/standard/46568.html.
[[Page 25904]]
This is a direct access link. However, a fee is required to obtain
a copy of the standard.
Summary: This International Standard specifies requirements, the
observance of which is intended to ensure that certification bodies
operate certification schemes in a competent, consistent and impartial
manner, thereby facilitating the recognition of such bodies and the
acceptance of certified products, processes, and services on a national
and international basis and so furthering international trade.
XII. Collection of Information Requirements
Under the Paperwork Reduction Act of 1995 (PRA), codified as
amended at 44 U.S.C. 3501 et seq., agencies are required to provide a
60-day notice in the Federal Register and solicit public comment on a
proposed collection of information before it is submitted to the Office
of Management and Budget for review and approval. In order to fairly
evaluate whether an information collection should be approved by the
OMB, the PRA requires that we solicit comment on the following issues:
1. Whether the information collection is necessary and useful to
carry out the proper functions of the agency;
2. The accuracy of the agency's estimate of the information
collection burden;
3. The quality, utility, and clarity of the information to be
collected; and
4. Recommendations to minimize the information collection burden on
the affected public, including automated collection techniques.
Under the PRA, the time, effort, and financial resources necessary
to meet the information collection requirements referenced in this
section are to be considered. We solicited comment on these issues in
the Proposed Rule (84 FR 7558 and 7559) for the matters discussed in
detail below.
A. ONC-ACBs
In the Proposed Rule, we proposed to add new ONC--Authorized
Certification Bodies (ONC-ACB) collection and reporting requirements
for the certification of health IT to the updated 2015 Edition (and any
subsequent edition certification) in Sec. 170.523(p), (q), (t), and
Sec. 170.550(1).
As stated in the Proposed Rule per Sec. 170.550(l), ONC-ACBs would
not be able to certify health IT until they review and verify health IT
developers' attestations confirming that the developers are compliant
with Conditions and Maintenance of Certification requirements. ONC-ACBs
would also submit the health IT developer attestations to ONC per Sec.
170.523(q).
As stated in the Proposed Rule for Sec. 170.523(p)(3), ONC-ACBs
would be required to collect and report certain information to ONC
related to real world testing plans and results. ONC-ACBs would be
required to verify that the health IT developer submits an annual,
publicly available real world testing plan and perform a completeness
check for both real world testing plans and results.
In the Proposed Rule, we stated for Sec. 170.523(t), ONC-ACBs
would ensure health IT developers opting to take advantage of the
Standard Version Advancement Process flexibility per Sec. 170.405(b)
provide timely advance written notice to the ONC-ACB and all affected
customers. ONC-ACBs would maintain a record of the date of issuance and
the content of developers' notices, and timely post content of each
notice received publicly on the CHPL attributed to the certified Health
IT Module(s) to which it applies.
In the 2015 Edition proposed rule (80 FR 16894), we estimated fewer
than ten annual respondents for all of the regulatory ``collection of
information'' requirements that applied to the ONC-ACBs, including
those previously approved by OMB. In the 2015 Edition final rule (80 FR
62733), we concluded that the regulatory ``collection of information''
requirements for the ONC-ACBs were not subject to the PRA under 5 CFR
1320.3(c).
Comments. We did not receive any comments specific to the new ONC-
ACB collection and reporting requirements for the certification of
health IT to the 2015 Edition (and any subsequent edition
certification) in Sec. 170.523(p), (q), (t), and Sec. 170.550(1).
Response. We continue to maintain our past determinations in that
we estimate less than ten annual respondents for all of the regulatory
``collection of information'' requirements for ONC-ACBs under part 170
of title 45, including those previously approved by OMB and in this
final rule, and that the regulatory ``collection of information''
requirements under the Program described in this section are not
subject to the PRA under 5 CFR 1320.3(c). For the cost estimates of
these new regulatory requirements, we refer readers to section XIII
(Regulatory Impact Analysis) of this final rule.
B. Health IT Developers
We proposed two separate collections from health IT developers in
the Proposed Rule. First, we proposed in 45 CFR 170.580(a)(2)(iii) that
ONC may take action against a health IT developer for failure to comply
with Conditions and Maintenance of Certification requirements. As
stated in the Proposed Rule, we proposed to generally use the same
processes previously codified in regulation (Sec. Sec. 170.580 and
170.581) to take administrative enforcement action. These processes
would require health IT developers to submit information to ONC to
facilitate and conclude ONC's review. The PRA, however, exempts these
information collections. We explained in the Proposed Rule that,
specifically, 44 U.S.C. 3518(c)(1)(B)(ii) excludes collection
activities during the conduct of administrative actions or
investigations involving the agency against specific individuals or
entities.
Secondly, we proposed in 45 CFR 170.402(b)(1) that a health IT
developer must, for a period of 10 years beginning from the date each
of a developer's health IT is first certified under the Program, retain
all records and information necessary to demonstrate initial and
ongoing compliance with the requirements of the Program for each health
IT product. We stated in the Proposed Rule that it would take
approximately two hours per week, on average, to comply with our
proposed record retention requirement. We welcomed comments on whether
more or less time should be included in our estimate.
[[Page 25905]]
Table 4--Estimated Annualized Total Burden Hours for Health IT Developers To Comply With Records and Information
Retention Requirements
----------------------------------------------------------------------------------------------------------------
Number of
Code of Federal Regulations section health IT Average Total
developers burden hours
----------------------------------------------------------------------------------------------------------------
45 CFR 170.402(b)(1)............................................ 458 104 47,632
-----------------------------------------------
Total Burden Hours.......................................... .............. .............. 47,632
----------------------------------------------------------------------------------------------------------------
Comments. We did not receive any comments specific to either
collection of information from health IT developers or our
corresponding PRA determinations.
Response. For the first information collection, we continue to
maintain that information collected pursuant to an administrative
enforcement action is not subject to the PRA under 44 U.S.C.
3518(c)(1)(B)(ii), which excludes collection activities during the
conduct of administrative actions or investigations involving the
agency against specific individuals or entities. For the second
information collection, we continue to believe it will take
approximately two hours per week on average to comply with our records
and information retention requirements as reflected in Table 4. We
refer readers to section XIII (Regulatory Impact Analysis) of this
final rule for the cost estimates of the second information collection.
XIII. Regulatory Impact Analysis
A. Statement of Need
This final rule is necessary to meet our statutory responsibilities
under the 21st Century Cures Act (Cures Act) and to advance HHS policy
goals to promote interoperability and mitigate burden for stakeholders.
The provisions finalized in this rule that could result in monetary
costs for stakeholders include the: (1) Updates to the 2015 Edition
health IT certification criteria; (2) Conditions and Maintenance of
Certification requirements for a health IT developer; (3) oversight for
the Conditions and Maintenance of Certification requirements; and (4)
information blocking.
While much of the costs of this final rule will fall on health IT
developers that seek to certify health IT under the ONC Health IT
Certification Program (Program), we believe the implementation and use
of health IT certified to the 2015 Edition (including the new and
updated criteria in this final rule), compliance with the Conditions
and Maintenance of Certification requirements, and the limited
exceptions to information blocking would ultimately result in
significant benefits for health care providers and patients. We outline
some of these benefits below. We emphasize in this regulatory impact
analysis (RIA) that we believe this final rule will create
opportunities for health IT innovation through new market entrants and
remove barriers to interoperability and electronic health information
exchange. These efforts would greatly benefit health care providers and
patients by increasing access to important health information and new
technologies resulting in improvements in health care delivery and
patient outcomes.
The provisions in this final rule seek to advance an interoperable
health system that empowers individuals to use their electronic health
information (EHI) to the fullest extent and enable health care
providers and communities to deliver smarter, safer, and more efficient
care. Given this goal, there will be instances where the benefits and
costs are multifaceted and unquantifiable. We note in this RIA when we
had difficulty quantifying benefits and costs due to lack of applicable
research or data. Additionally, there are ongoing regulatory and policy
activities outside of this final rule that might influence the rule's
impact in an unquantifiable manner. When possible, we acknowledge these
complexities as well. Unquantifiable costs and benefits identified in
this rule are summarized in Table 31.
B. Alternatives Considered
In the Proposed Rule, we noted that we were unable to identify
alternatives to our proposals that would appropriately implement our
responsibilities under the Cures Act and support interoperability. At
the time, we assessed whether there were alternatives to our proposals,
specifically our proposals concerning EHI export, application
programming interfaces (APIs), and real world testing. We concluded
that our proposals took the necessary steps to fulfill the mandates
specified in the Public Health Service Act (PHSA), as amended by the
Health Information Technology for Economic and Clinical Health (HITECH)
Act and the Cures Act, in the least burdensome way. We welcomed
comments on our assessment and any alternatives that we should
consider.
Comments. We received comments suggesting alternatives to our
proposals. Specifically, some commenters stated that we should consider
an alternative approach to the EHI export (Sec. 170.315(b)(10))
certification criterion's scope to align with other regulations and
data standards, such as the USCDI. Other commenters requested we
reconsider the adoption of the consent management for APIs (Sec.
170.315(g)(11)) certification criterion or use a different platform
because the consent2share (C2S) platform was not mature enough. We also
received comments requesting we consider alternative definitions for
various information blocking terms and reconsider our approach to
certain information blocking exceptions. Commenters recommended that we
consider these alternatives in order to provide clarity to and reduce
potential burden for the regulated community.
Response. Based on comments received, we considered and adopted
revisions to our proposals that will substantially reduce real and
perceived burden. For the certification criteria, we revised and
narrowed the scope of the EHI export certification criterion so that it
is more manageable and less administratively burdensome for health IT
developers. The criterion will link the data exported to the focused
definition of EHI as finalized (see section IV.B.6.c). We also
reevaluated and determined, consistent with commenter input, that there
is continued work to be done to ballot and field test the C2S platform
and the Consent Implementation Guide and, therefore, did not adopt the
consent management for APIs (Sec. 170.315(g)(11)) certification
criterion in this final rule (see section IV.B.9.b).
Within the information blocking section, we have focused the scope
of many terms to address commenter concerns and reduce potential burden
on actors. We have focused the definition of EHI (Sec. 171.102) (see
VIII.C.3). We have also focused the
[[Page 25906]]
Health Information Network (HIN) definition in consideration of
comments in four ways. First, we combined the definitions of HIN and
Health Information Exchange (HIE) to create one functional definition
that applies to both statutory terms in order to clarify the types of
individuals and entities that would be covered. Second, we limited the
types of actions that would be necessary for an actor to meet the
definition of HIN or HIE. Third, we have revised the definition to
specify that to be a HIN or HIE there must be exchange among more than
two unaffiliated individuals or entities besides the HIN/HIE that are
enabled to exchange with each other. Fourth, we focused the definition
on treatment, payment, and health care operations, as each are defined
in the HIPAA Rules (45 CFR 164.501) (see VIII.C.2.c). We have also
clarified the scope of the ``access,'' ``exchange,'' and ``use''
definitions and refer readers to the discussion of those changes in
section VIII.C.5.a.
We have also considered and finalized alternatives relating to the
information blocking exceptions. Of note, we have finalized the new
Content and Manner Exception (see Sec. 171.301 and the preamble
discussion in section VIII.D.2.a), which will significantly reduce
burden on actors. First, the content condition (Sec. 171.301(a))
establishes that, in order to satisfy the exception, for up to May 2,
2022, an actor must respond to a request to access, exchange, or use
EHI with, at a minimum, the EHI identified by the data elements
represented in the USCDI standard adopted in Sec. 170.213. Second, the
manner condition (Sec. 171.301(b)) explains acceptable alternative
manners for fulfilling a request to access, exchange, or use EHI when
an actor is technically unable to fulfill a request in any manner
requested or cannot reach agreeable terms with the requestor to fulfill
the request in any manner requested. This exception creates a
transparent and flexible framework for actors to fulfill requests for
access, exchange, or use of EHI. We refer readers to the discussion of
the Content and Manner Exception in section VIII.D.2.a, as well as the
broader discussion within the information blocking section where we
discuss various other changes we have made in response to comments that
will reduce burden (see section VIII.D).
C. Overall Impact
We have examined the impact of this final rule as required by
Executive Order 12866 on Regulatory Planning and Review (September 30,
1993), Executive Order 13563 on Improving Regulation and Regulatory
Review (January 18, 2011), Executive Order 13771 on Reducing Regulation
and Controlling Regulatory Costs (January 30, 2017), the Regulatory
Flexibility Act (5 U.S.C. 601 et seq.), section 202 of the Unfunded
Mandates Reform Act of 1995 (2 U.S.C. 1532), and Executive Order 13132
on Federalism (August 4, 1999).
1. Executive Order 13771--Reducing Regulation and Controlling
Regulatory Costs
Executive Order 13771 on Reducing Regulation and Controlling
Regulatory Costs was issued on January 30, 2017 and directs agencies to
repeal two existing regulations for each new regulation issued in
fiscal year (FY) 2017 and thereafter. It further directs agencies, via
guidance issued by the Office of Management and Budget (OMB), that the
total incremental costs of all regulations should be no greater than
zero in FY 2018. The analysis required by Executive Order 13771, as
supplemented by Executive Order 13777, adds additional requirements for
analysis of regulatory actions. The new requirements under Executive
Orders 13771 and 13777 do not change or reduce existing requirements
under Executive Orders 12866 or 13563. This final rule is an E.O. 13771
regulatory action. We estimate this rule generates $0.84 billion in
annualized costs in 2016 dollars, discounted at 7 percent relative to
year 2016 over a perpetual time horizon.
2. Executive Orders 12866 and 13563--Regulatory Planning and Review
Analysis
Executive Orders 12866 on Regulatory Planning and Review and 13563
on Improving Regulation and Regulatory Review direct agencies to assess
all costs and benefits of available regulatory alternatives and, if
regulation is necessary, to select regulatory approaches that maximize
net benefits (including potential economic, environmental, public
health and safety effects, distributive impacts, and equity). A
regulatory impact analysis (RIA) must be prepared for major rules with
economically significant effects ($100 million or more in any one
year). Pursuant to the Congressional Review Act (5 U.S.C. 801 et seq.),
the Office of Information and Regulatory Affairs designated this rule
as a `major rule' as defined by 5 U.S.C. 804(2). OIRA has also
determined that this final rule is an economically significant rule as
we have estimated the costs to implement this final rule may be greater
than $100 million per year. Accordingly, we have prepared an RIA that
to the best of our ability presents the costs and benefits of this
final rule.
a. Costs and Benefits
We have estimated the monetary costs and benefits of this final
rule for health IT developers, health care providers, patients, ONC--
Authorized Certification Bodies (ONC-ACBs), ONC--Authorized Testing
Laboratories (ONC-ATLs), and the Federal Government (i.e., ONC), and
have broken those costs and benefits out into the following categories:
(1) Deregulatory actions (no associated costs); (2) updates to the 2015
Edition health IT certification criteria; (3) Conditions and
Maintenance of Certification requirements for a health IT developer;
(4) oversight for the Conditions and Maintenance of Certification
requirements; and (5) information blocking.
In accordance with Executive Order 12866, we have included the RIA
summary table as Table 30. In addition, we have included a summary to
meet the regulatory reform analysis requirements under Executive Order
13771.
Cost and benefit calculations were performed in 2017 dollars, as
this year was the most recent data available to address all cost and
benefit estimates consistently. For summary tables 29 through 31, all
estimates are rounded to the nearest dollar and expressed in 2016
dollars to meet regulatory reform analysis requirements under Executive
Order 13771.
We note that estimates presented in the following ``Employee
Assumptions and Hourly Wage,'' ``Quantifying the Estimated Number of
Health IT Developers and Products,'' and ``Number of End Users that
Might Be Impacted by ONC's Final Rule'' sections are used throughout
this RIA.
In this final rule, we used a number of methods to quantify direct
and indirect benefits of our provisions. For provisions where no such
research was available, we developed estimates based on a reasonable
proxy. Interoperability, for example, can positively impact patient
safety, care coordination, and improve health care processes and health
outcomes.\192\ However, achieving interoperability is a function of
several factors, not just the capability of the technology used by
health care providers. Therefore, to assess some of the benefits of
this final rule, we used regression analysis to assess their
[[Page 25907]]
respective effects on interoperability holding other factors constant.
---------------------------------------------------------------------------
\192\ https://www.qualityforum.org/Publications/2017/09/Interoperability_2016-2017_Final_Report.aspx.
---------------------------------------------------------------------------
One example of this approach is the methodology used to quantify
the benefits of our real world testing and API provisions on
interoperability. We used regression analysis to calculate the impact
of our real world testing and API provisions on interoperability. We
assumed that the real world testing and API provisions would
collectively have the same impact on interoperability as upgrading
health IT certified to the 2014 Edition. Therefore, we estimated linear
probability models that identified the impact of 2014 Edition certified
health IT on hospitals' interoperability.\193\ We used data from the
2014 and 2015 American Hospital Association (AHA) Annual Survey
Information Technology Supplement (IT Supplement), which consists of an
analytic sample of 4,866 observations of non-Federal acute care
hospitals that responded to the IT Supplement.\194\ We controlled for
additional factors such as participation in a health information
exchange organization, hospital characteristics, and urban/rural
status. More specifically, we used the following explanatory variables:
---------------------------------------------------------------------------
\193\ The interoperability dependent variable is a binary
indicator for whether a hospital routinely sends, receives, and
integrates summary of care records electronically outside of its
system and finds any health information electronically outside of
its system.
\194\ American Hospital Association Health IT Supplement Survey,
http://www.ahadata.com/aha-healthcare-database/.
Edition = 1 if a hospital adopted 2014 Edition EHR, 0 otherwise
RHIO = 1 if a hospital participates in health information exchange
organization, 0 otherwise
Government = 1 if a hospital is publicly owned, 0 otherwise
Alt_teaching = 1 if a hospital is teaching, 0 otherwise
Nonprofit = 1 if a hospital is not for profit, 0 otherwise
Largebed = 1 if a hospital has more than 399 beds, 0 otherwise
Medbed = 1 if a hospital's number of beds is between 100 and 399, 0
otherwise
Urban_rural = 1 if a hospital is urban, 0 otherwise
CAH = 1 if a hospital is critical access, 0 otherwise
Year = year of the data (2014 and 2015)
S = state fixed effects
We found a statistically significant marginal effect of using 2014
Edition certified health IT associated with a five percentage point
increase in interoperability.\195\
---------------------------------------------------------------------------
\195\ Results were similar when we used logit or Probit
specifications. Note, the percentage point refers to the arithmetic
difference between two percentages.
---------------------------------------------------------------------------
While we acknowledge that there might be shared benefits across
provisions, we have taken steps to ensure that the benefits attributed
to each provision is unique to the provision referenced. For example,
in the case of assessing the impact of our real world testing and API
provisions on interoperability, we assumed that the marginal effect is
true and distributed the five percentage point benefit across our
provisions at (0.1-1) to (1-4) percentage points respectively. Given
data limitations, we believe this approach allowed us to estimate the
benefits of our final provisions without double counting the impact
each provision might have on interoperability.
Employee Assumptions and Hourly Wage
We have made employee assumptions about the level of expertise
needed to complete the requirements in this section of the final rule.
For wage calculations for Federal employees and ONC-ACBs, we have
correlated the employee's expertise with the corresponding grade and
step of an employee classified under the General Schedule (GS) Federal
Salary Classification, relying on the associated employee hourly rates
for the Washington, DC locality pay area as published by the Office of
Personnel Management for 2017.\196\ We have assumed that overhead costs
(including benefits) are equal to 100 percent of pre-tax wages.
Therefore, we have doubled the employee's hourly wage to account for
overhead costs. We have concluded that a 100 percent expenditure on
overhead costs which includes benefits is an appropriate estimate based
on research conducted by HHS.\197\
---------------------------------------------------------------------------
\196\ https://www.opm.gov/policy-data-oversight/pay-leave/salaries-wages/salary-tables/pdf/2017/DCB_h.pdf.
\197\ See U.S. Department of Health and Human Services, Office
of the Assistant Secretary for Planning and Evaluation (ASPE),
Guidelines for Regulatory Impact Analysis, at 28-30 (2016),
available at https://aspe.hhs.gov/system/files/pdf/242926/HHS_RIAGuidance.pdf.
---------------------------------------------------------------------------
We have used Bureau of Labor Statistics (BLS) data to calculate
private sector employee wage estimates (e.g., health IT developers,
health care providers, health information networks (HINs), attorneys,
etc.), as we believe BLS provides the most accurate and comprehensive
wage data for private sector positions. Just as with the General
Schedule Federal Salary Classification calculations, we have assumed
that overhead costs (including benefits) are equal to 100 percent of
pre-tax wages.
We estimated using 2016 dollars in the Proposed Rule. However, we
stated in the Proposed Rule that we would consider using 2017 and even
2018 dollars, if available, for our cost and benefit estimates in the
final rule. Therefore, in this final rule, we updated our estimates
using 2017 dollars for the GS Federal Salary Classification and the BLS
data.
Quantifying the Estimated Number of Health IT Developers and Products
We derived our estimates for the potential impact of the new 2015
criteria on the number of certified products in the health IT market.
This analysis is based on the number of certified health IT products
(i.e., Health IT Modules), product capability, and the number of health
IT developers that left, merged, and/or entered the ONC Health IT
Certification Program between the 2011 Edition health IT certification
criteria (2011 Edition) and the implementation of the 2014 Edition
health IT certification criteria (2014 Edition).\198\
---------------------------------------------------------------------------
\198\ Availability of 2014 CEHRT for Meaningful Users Providers,
Health IT Policy Committee Data Update (Sept. 9, 2015), available at
http://www.healthit.gov/FACAS/sites/faca/files/HITPC_Data_Update_Presentation_Final_2015-09-09.pdf.
---------------------------------------------------------------------------
In Table 5, we quantify the extent to which the certified health IT
market consolidated between the 2011 Edition and 2014 Edition. We found
that the number of health IT developers certifying products between the
2011 Edition and 2014 Edition decreased by 22.1 percent and the number
of products available decreased by 23.2 percent.
[[Page 25908]]
Table 5--Certified Health IT Market Consolidation From the 2011 Edition to the 2014 Edition
----------------------------------------------------------------------------------------------------------------
Market
2011 Edition 2014 Edition consolidation
(%)
----------------------------------------------------------------------------------------------------------------
Health IT Developers............................................ 1,017 792 -22.1
Products Available.............................................. 1,408 1,081 -23.2
----------------------------------------------------------------------------------------------------------------
\A\ For the purposes of these market consolidation calculations, we included the total number of active or
suspended health IT products and their developers. Withdrawn products and their developers were excluded from
this total.
Using the rates identified in Table 5, we then applied our estimate
for market consolidation to estimate the number 2015 Edition certified
health IT products and health IT developers that would be impacted by
our policies in this final rule. Specifically, to estimate the number
of 2015 Edition products and health IT developers in the market, we
assumed:
Products capable of recording EHI will include new
certification criteria. We assume that products capable of recording
patient health data will be the types of products most likely to be
impacted by and include the new certification criteria.
Products capable of recording EHI data available in 2015
equal the number of products available in 2014. In 2014, there were 710
products by 588 developers capable of recording EHI. Since the new
criteria involve the access to and movement and exchange of EHI, we
used only products that record EHI as a basis for our estimates. We
believe the 2014 totals reflect a realistic estimate of the currently
available products and their developers that could include the new 2015
certification criteria.
Market consolidation rates denoted in Table 5 hold
constant. We assume that the rate of market consolidation for products
(-23.2 percent) and health IT developers (-22.1 percent) from the 2011
Edition to the 2014 Edition holds constant for the 2015 Edition.
Although we are using this number to estimate product availability, we
are unable to assess how market consolidation might impact other
production costs such as the supply and demand for personnel over time.
As shown in Table 6, based on the assumptions, we have estimated
the total number of 2015 products (545) and their developers (458).
Table 6--Total Number of Health IT Developers and Products by Scenario
------------------------------------------------------------------------
Estimated
number of Estimated
Scenario health IT number of
developers products
------------------------------------------------------------------------
2015 Edition Projection--All Products... 617 830
2015 Edition Projection--Products 458 545
Capable of Recording EHI...............
------------------------------------------------------------------------
Number of End Users That Might Be Impacted by ONC's Final Rule
For the purpose of this analysis, the population of end users
differs according to the regulatory action finalized. In many cases,
the end-user population impacted is the number of hospitals and health
care providers that possess certified health IT. Due to data
limitations, our analysis regarding the number of hospitals and health
care providers impacted by the regulatory action is based on the number
of hospitals and health care providers that have historically
participated in the Centers for Medicare & Medicaid Services (CMS) EHR
Incentive Programs (now Promoting Interoperability (PI) Programs).
One limitation of this approach is that we are unable to account
for the impact of our provisions on users of health IT that were
ineligible or did not participate in the CMS EHR Incentive Programs.
For example, in 2017, 78 percent of home health agencies and 66 percent
of skilled nursing facilities reported adopting an EHR.\199\ Nearly
half of these facilities reported engaging aspects of health
information exchange. However, we are unable to quantify, specifically
the use of certified health IT products, among these provider types.
---------------------------------------------------------------------------
\199\ Henry, J., Pylypchuck, Y., & Patel, V. (November 2018)
Electronic Health Record Adoption and Interoperability among U.S.
Skilled Nursing Facilities in 2017. ONC Data Brief, no. 41. Office
of the National Coordinator for Health Information Technology:
Washington, DC.
---------------------------------------------------------------------------
Despite these limitations, participants in the CMS EHR Incentive
Programs represent an adequate sample on which to base our
estimates.\200\ There were 439,187 health care providers \201\ in
95,470 clinical practices \202\ and 4,519 hospitals \203\ that
participated in the CMS EHR Incentive Program. We estimate that these
entities will be impacted by our rule.
---------------------------------------------------------------------------
\200\ See Office of the National Coordinator for Health
Information Technology, Office-based Health Care Professionals
Participating in the CMS EHR Incentive Programs (Aug. 2017),
dashboard.healthit.gov/quickstats/pages/FIG-Health-Care-Professionals-EHR-Incentive-Programs.php; Office of the National
Coordinator for Health Information Technology, Hospitals
Participating in the CMS EHR Incentive Programs (Aug. 2017),
dashboard.healthit.gov/quickstats/pages/FIG-Hospitals-EHR-Incentive-Programs.php.
\201\ This estimate is the total number of eligible providers
that ever participated in the CMS Medicare and Medicaid Electronic
Health Record Incentive Program.
\202\ This number was estimated based on the de-duplicated
number of practices that had at least one clinician participate in
the CMS Medicare Electronic Health Record Incentive Program.
\203\ This estimate is the total number of eligible hospitals
that ever participated in the CMS Medicare Electronic Health Record
Incentive Program.
---------------------------------------------------------------------------
General Comments on the RIA
Comments. Several commenters expressed concern that the estimated
costs and developer hours in the proposed rule were significantly
underestimated. One commenter stated that the cost estimates did not
accurately reflect provider implementations costs, including those
related to ensuring compliance with the HIPAA Rules, 42 CFR part 2 and
other Federal and State privacy laws. Some commenters were concerned
about the impact of the requirements, as proposed in the Proposed Rule,
on existing small health IT developers and their ability to
[[Page 25909]]
compete with large developers, as well as the impact on potential new
market entrants. One commenter stated that this environment will result
in only a small number of health IT developers surviving while also
limiting market entry. One commenter expressed concern that the
Proposed Rule will provide unfettered access to the intellectual
property of health IT developers while increasing their compliance
costs, which will limit their potential investment returns and create
barriers to market entry. A few commenters expressed concern that the
costs incurred by health IT developers to improve interoperability and
comply with other aspects of the rule as proposed will be passed on to
providers and patients.
Response. We thank commenters for their input regarding our
estimated costs and developer hours in the Proposed Rule. We considered
and adopted revisions to our proposals based on comments that would
substantially reduce any real or perceived burden. We reanalyzed our
approach and made adjustments for this final rule. For instance, we
have included additional developer hours for the additional data
elements we finalized in this final rule. We have also included
additional costs for the bulk data standard support and API support.
Lastly, with regards to the comment that the cost estimates did not
accurately reflect implementation costs to providers, when possible ONC
has quantified provider costs associated with the deployment of new
certified health IT functionalities and the optional acquisition of
emerging API technologies. Costs that are not quantifiable are noted in
Table 31. However, costs related to ensuring compliance with the HIPAA
Rules, 42 CFR part 2 and other Federal and State privacy laws, are
beyond the scope of the certification criteria and are not included in
the final rule.
We understand commenters' concerns about the impact of the
provisions as proposed on small health IT developers and the potential
impact on new market entrants. However, we continue to believe that
while much of the costs of the final rule will fall on health IT
developers seeking to certify health IT under the Program, the
implementation and use of health IT certified to the 2015 Edition
(including the updated and new criteria in this final rule), compliance
with the Conditions and Maintenance of Certification requirements, and
the limited exceptions to information blocking would ultimately result
in significant benefits for health care providers and patients. We also
emphasize that we believe the final rule will create opportunities for
new market entrants and will remove barriers to interoperability and
electronic health information exchange, which will greatly benefit
health care providers and patients as well.
(1) Deregulatory Actions
Costs
We do not expect incurred costs to be associated with the
deregulatory actions in this final rule, but rather cost savings as
detailed further in this Regulatory Impact Analysis.
Benefits
We expect the deregulatory actions of the rulemaking to result in
benefits for health IT developers, providers, ONC-ACBs, ONC-ATLs, and
ONC.
(i) Removal of the Randomized Surveillance Minimum Threshold
Requirements
In this final rule, we have revised Sec. 170.556(c) to specify
that ONC-ACBs may conduct in-the-field, randomized surveillance. We
have removed Sec. 170.556(c)(2), which specifies that ONC-ACBs must
conduct randomized surveillance for a minimum of two percent of
certified health IT products per year. Additionally, we have removed
the requirement that ONC-ACBs make a good faith effort to complete
randomized surveillance and the circumstances permitted for exclusion
from the requirement found in Sec. 170.556(c)(5).
In the 2015 Edition final rule, we did not independently estimate
the costs for randomized surveillance. Rather, we relied on prior
regulatory cost estimates for all surveillance actions. One of our four
ONC-ACBs charges a $3,000 annual fee per product for surveillance due
to the new randomized surveillance requirements and to help normalize
their revenue stream during down cycles between certification editions.
Using this fee as a cost basis and assuming it would apply to all
certified health IT (as opposed to the market-adjusted universe of
health IT that is used in other calculations in this RIA), we estimated
that the removal of the randomized surveillance ``two percent minimum
threshold'' requirements will result in cost savings between $6.8 and
$13.7 million for all stakeholders. To arrive at this estimate, we
multiplied the $3000 annual fee per product for surveillance by the
total number of products certified to the 2014 Edition which was 4,559
products at the time ($3,000*4,559 = $13.7 million). We anticipate the
number of products certified for 2014 to decrease to a little as half
of the original count over time. Therefore, we estimated the low end to
be half of the $13.7 million (0.5*$13.7 million = $6.8 million). This
estimate is based on feedback we received from our ONC-ATLs and ONC-
ACBs. ONC-ACBs performed randomized surveillance an average of 22 times
the first year the requirement was in effect. The following year
surveillance was performed an average of two times. We cannot predict
how many randomized surveillance events the ONC-ACBs will perform now
that we are not enforcing the requirement. It will be completely at the
discretion of the ONC-ACBs.
In the Proposed Rule, we noted that we considered other potential
benefits that we were unable to quantify. For instance, we considered
that health care provider burden may decrease from the elimination of
the two percent minimum threshold requirements because a provider would
previously aid the ONC-ACB in software demonstrations.
We welcomed comments on potential means, methods, and relevant
comparative studies and data that we could use to better quantify these
benefits.
Comments. We did not receive any comments specific to the
calculation of benefits of the elimination of the two percent minimum
threshold requirements.
Response. We have maintained our approach in calculating the
benefits of this provision in this final rule. We believe the removal
of the randomized surveillance minimum threshold requirements will
reduce the burden on health care providers by reducing their exposure
to randomized in-the-field surveillance of their health IT products.
Health care providers previously expressed concern about the time
commitment to support ONC-ACB randomized surveillance of health IT
products, particularly if no non-conformities with certified health IT
were found. Providers have generally stated that reactive surveillance
(e.g., complaint-based surveillance) is a more logical and economical
approach to surveillance of health IT products implemented in a health
care setting. We also believe the removal of these requirements will
provide health IT developers more time to focus on interoperability,
and will provide ONC-ACBs more time to respond to reactive
surveillance, including health care provider complaints about certified
health IT.
(ii) Removal of the 2014 Edition From the Code of Federal Regulations
We estimate that health IT developers would realize monetary
savings from no
[[Page 25910]]
longer supporting the 2014 Edition certification criteria due to a
reduction in activities related to maintaining certification and
surveillance. We are aware that one of our ONC-ACBs charges an
inherited certified status (ICS) fee of $1,000. This fee has been
applied over the last calendar year. Over that time period, the number
of new, unique 2014 Edition products has been declining (24 products,
and no new products in the last four months) compared to the number of
ICS certifications (569). Just assuming the cost of continued ICS
certification, health IT developers would be paying approximately
$569,000 each year to keep their 2014 Edition products up to date.
Based on recent analysis of the number of unique 2014 Edition products,
our assumptions hold true.
We are not aware of comparable fees charged by ONC-ATLs; however,
based on our experience with the Program, we expect health IT
developers would realize similar cost savings associated with ONC-ATL
maintenance of the testing component associated with ICS. Thus, we
estimate an additional $569,000 cost savings for health IT developers
due to the reduced testing requirements.
We also attempted to identify a potential reduction in maintenance
and administrative costs as a result of removing 2014 Edition
certification criteria. We could not obtain data to conduct a full
quantitative analysis specific to the reduction of health IT developer
and health care provider costs related to supporting and maintaining
the 2014 Edition. However, we invited comments on methods to quantify
potential costs for maintaining and supporting products to previous
editions.
We did conduct a review of academic literature and qualitative
analysis regarding potential savings from no longer supporting the 2014
Edition. We looked at data in IT industry systems as whole, which
showed that upgrading outdated legacy systems saves resources otherwise
spent on maintaining compatibilities to multiple systems and also
increases quality and efficiency.\204\ Furthermore, as technology
evolves, newer software and products allow for smoother updates
compared to their predecessors. Newer products provide better security
features that can address both new and existing issues. In addition,
older software has an increased risk of failure, which, in the health
IT industry, increases risk to patient safety.
---------------------------------------------------------------------------
\204\ James Crotty and Ivan Horrocks, Managing legacy system
costs: A case study of a meta-assessment model to identify solutions
in a large financial services company, Applied Computing and
Informatics (2017), at 1-9.
---------------------------------------------------------------------------
From the implementer's perspective, the research indicated that
retaining legacy systems tends to inhibit scalability and growth for
businesses. The perpetuity of outdated legacy systems increases
connection and system integration costs and limits the ability to
realize increased efficiency through IT implementation. Newer products
are developed to current specifications and updated standards, which
decreases barriers and marginal cost of ancillary product
implementation and increases the accessibility of data in ancillary
systems--including via mobile devices and the latest applications.
Finally, office staff in a health care setting would no longer need to
be trained to accommodate differing data access needs or workarounds
required to integrate to the legacy product.\205\
---------------------------------------------------------------------------
\205\ Id.
---------------------------------------------------------------------------
The research also indicates that retaining legacy software would
not be beneficial or profitable to the health IT market. Prolonging
backwards compatibility of newer products to legacy systems encourages
market fragmentation.\206\ We intend to encourage the health IT market
to keep progressing with a baseline expectation of functionalities that
evolve over time. This requires limiting fragmentation by no longer
supporting outdated or obsolete legacy software.\207\
---------------------------------------------------------------------------
\206\ Il-Horn Hann, Byungwan Koh, and Marius F. Niculescu, The
Double-Edged Sword of Backward Compatibility: The Adoption of
Multigenerational Platforms in the Presence of Intergenerational
Services, Inform. Systems Res. (2016), at 112-30.
\207\ Id.
---------------------------------------------------------------------------
We also estimate that additional savings could be realized by
reducing regulatory complexity and burden caused by having two
certification editions. We observed that the task of managing two
different editions within different rules increases complexity and
burden for ONC staff, contractors, ONC-ACBs, CMS programs referencing
the certification criteria, and other stakeholders, as compared to
removing the 2014 Edition certification criteria. However, we were
unable to estimate these benefits because we have no means for
quantifying the benefits gained from only using the 2015 Edition.
We also expect that health care providers would benefit from
removing the 2014 Edition certification criteria because such action
would likely motivate health IT developers to certify health IT
products to the 2015 Edition, thus enabling providers to use the most
up-to-date and supported systems to care for patients.
Comments. We did not receive comments specific to our methods for
quantifying the potential costs for maintaining and supporting products
to previous editions.
Response. We have maintained our approach for quantifying costs for
health IT developers maintaining and supporting products to the
previous 2014 Edition. We have also emphasized again that the research
indicates that retaining legacy software would not be beneficial or
profitable to the health IT market.
(iii) Removal of the ONC-Approved Accreditor From the ONC Health IT
Certification Program
We expect ONC to realize monetary cost savings from removing the
ONC-Approved Accreditor (ONC-AA) from the Program. We expect ONC to
realize costs savings from no longer: (1) Developing and publishing a
Federal Register Notice and listserv; (2) monitoring the open
application period and reviewing and making decisions regarding
applications; and (3) oversight and enforcement of the ONC-AA. We have
calculated the estimated annual cost savings for removing the ONC-AA
from the Program, taking into consideration that the ONC-AA renewed its
status every three years.
For our calculations, we used the estimated hours for collaborating
with and informing an ONC-AA in 2017 (using 2017 wage estimates). We
estimated that ONC spent approximately 110 hours collaborating with the
ONC-AA in 2017, which includes (all at the GS-13, Step 1 level): Annual
assessments; providing appropriate guidance; implementing new
requirements and initiatives; and consultations as necessary. The
hourly wage with benefits for a GS-13, Step 1 employee located in
Washington, DC is approximately $91. Therefore, we estimated the annual
cost savings to be $3,337.
We estimate that ONC would commit approximately eight hours of
staff time to develop the Federal Register Notice, which would include
approximately: Four hours for drafting and review by an analyst at the
GS-13, Step 1 level; two hours for review and analysis by senior
certification staff at the GS-14, Step 1 level; and two hours for
review and submittal for publication by Immediate Office staff at the
GS-15, Step 1 level. The hourly wage with benefits for a GS-13, Step 1
employee located in Washington, DC is approximately $91. The hourly
wage with benefits for a GS-14, Step 1 employee located in
[[Page 25911]]
Washington, DC is approximately $107. The hourly wage with benefits for
a GS-15, Step 1 employee located in Washington, DC is approximately
$126. Therefore, we estimate the annual cost savings to be $277.
Additionally, we estimate a cost of $477 to publish each page in the
Federal Register, which includes operational costs. The Federal
Register Notice for ONC-AAs requires, on average, one page in the
Federal Register (every three years), so we estimated an additional
annual cost savings of $159.
We estimated that ONC will commit approximately two hours of staff
time by an analyst at the GS-13, Step 1 level to draft, review, and
publish the listserv to announce the Federal Register Notice. The
hourly wage with benefits for a GS-13, Step 1 employee located in
Washington, DC is approximately $91. Therefore, we estimate the annual
cost savings to be $61.
We estimated that ONC would commit approximately 25 hours of staff
time to manage the open application process, review applications and
reach application decisions, which would include approximately: 20
hours by an analyst at the GS-13, Step 1 level; three hours by senior
certification staff at the GS-14, Step 1 level; and two hours for
review and approval by Immediate Office staff at the GS-15, Step 1
level. The hourly wage with benefits for a GS-13, Step 1 employee
located in Washington, DC is approximately $91. The hourly wage with
benefits for a GS-14, Step 1 employee located in Washington, DC is
approximately $107. The hourly wage with benefits for a GS-15, Step 1
employee located in Washington, DC is approximately $126. Therefore, we
estimated the annual cost savings to be $798.
Taking all of these potential costs savings into consideration, we
estimated the overall annual costs savings for removing the ONC-AA from
the Program to be $4,632.
(iv) Removal of Certain 2015 Edition Certification Criteria
In section III.B.4 of this final rule, we removed the following
certification criteria from the 2015 Edition: Sec. 170.315(b)(4)
``Common Clinical Data Set summary--create;'' (b)(5) ``Common Clinical
Data Set summary--receive'' and Sec. 170.315(a)(11) ``Smoking
status.'' We did not finalize the proposal to remove of Sec.
170.315(a)(10) ``Drug formulary and preferred drug list checks,'' Sec.
170.315(a)(13) ``Patient-specific education resources'' and Sec.
170.315(e)(2) ``Secure messaging'' but rather will only permit ONC-ACBs
to issue certificates for these criteria until January 1, 2022 to align
with requirements of the CMS Medicaid PI Program.
For determining calculations for the majority of the 2015 Edition
certification criteria we removed, we used the following assumptions.
(For the removal of Sec. 170.315(b)(4) Common Clinical Data Set
summary--create and (b)(5) Common Clinical Data Set summary--receive,
we outlined the slightly different approach used).
In the 2015 Edition final rule, we estimated the costs for
developing and preparing health IT to meet the 2015 Edition
certification criteria. The development and preparation costs we
estimated were derived through a health IT developer per criterion
cost. We estimated the development and preparation costs over a four-
year period, and we projected the costs would be unevenly distributed.
In figuring out the cost savings for the deregulatory actions, we
initially used the distribution from the 2015 Edition, but then
adjusted the percentages of development and preparation costs due to
current empirical and anecdotal evidence. The distribution was
reevaluated to account for 2019 and we estimated the actual development
and preparation distribution for 2018 to be 35 percent and for 2019 to
be 15 percent. We took the average development and preparation cost
estimates (low and high) per criterion from Table 14 of the 2015
Edition final rule (80 FR 62737). We then used our new distribution to
identify the cost per year for years 2018 and 2019. We took the total
estimated costs for 2018 and 2019 and divided that by 12 to determine
the cost savings per month and took a range of 6 to 12 months. Based on
analysis of recent data, our assumptions continue to hold true.
To determine the testing costs of the deregulatory actions, we took
the number of health IT developers who develop products for
certification for the identified criteria from the 2015 Edition final
rule and then figured out the average cost per criterion. Based on the
costs that one of the ONC-ATLs charges for testing, we estimated the
average cost for testing per criterion and determined subsequent cost
savings. In 2017, only about five to ten percent of products have been
tested and certified compared to the number of certified 2014 Edition
products. Therefore, up to 90 to 95 percent of products remain to be
tested and certified to the 2015 Edition. Based on analysis of recent
data, our assumptions continue to hold true.
We estimated the total cost savings by multiplying the number of
health IT developers who developed products for certification to a
certain criterion by the estimated cost per criterion, $475. We then
took five percent of that number to identify the high end for the cost
savings. We then took 10 percent to identify the low end. The five
percent was derived from looking at the number of unique developers who
have at least one active 2014 Edition product and the number of unique
developers who have at least one active 2015 Edition. The denominator
is the number of unique developers who have at least one active 2014
Edition product, which is 793. The numerator is the number of unique
developers who have at least one active 2015 Edition product and one
active 2014 edition product, which is 41. (41/793 = 0.0517024 or 5
percent).
(A) Common Clinical Data Set Summary Record Criteria
In this final rule, we removed the Common Clinical Data Set
summary--create (Sec. 170.315(b)(4)) and Common Clinical Data Set
summary--receive (Sec. 170.315 (b)(5)) criteria.
Our expectation was for ONC to realize cost savings associated with
internal infrastructure support and maintenance, which would include
actions such as: (1) Developing and maintaining information regarding
these criteria on the ONC website; (2) creating documents related to
these criteria and making those documents 508 compliant; (3) updating,
revising, and supporting Certification Companion Guides, test
procedures, and test tools; and (4) responding to inquiries concerning
these criteria. Based on ONC data on the number of inquiries received
since early 2016, we estimated approximately 12 annual inquiries about
Sec. 170.315(b)(4) and (5) respectively, (24 total inquiries for two
criteria). We estimate it will take an analyst at the GS-13, Step 1
level an average of two hours to conduct all tasks associated with each
inquiry. The hourly wage with benefits for a GS-13, Step 1 employee
located in Washington, DC is approximately $91. Based on analysis of
recent data, our assumptions continue to hold true.
Therefore, we estimated the annual cost savings to be $4,360.
We do not expect cost savings associated with software maintenance
because both criteria incorporate the Common Clinical Data Set and
essentially the same data input and validation requirements as the
transitions of care criterion (Sec. 170.315(b)(1)). The removal of
these two criteria would not affect the test data and software
maintenance costs, as the same test data and software validation
elements remain in
[[Page 25912]]
Sec. 170.315(b)(1) and the Common Clinical Data Set used in other
criteria.
ONC-ACBs could realize minimal savings, as they would need to
conduct slightly less surveillance based on the two products that are
currently certified to these criteria. We estimated the overall annual
costs savings for removing the Common Clinical Data Set summary record
certification criteria from the 2015 Edition to be $4,368.
Comments. We did not receive comments specific to the removal of
the Common Clinical Data Set summary--create (Sec. 170.315(b)(4)) and
Common Clinical Data Set summary--receive (Sec. 170.315 (b)(5))
criteria.
Response. We maintained our approach and estimates for removing the
Common Clinical Data Set summary record certification criteria from the
2015 Edition. However, we did update estimates to 2017 dollars.
(B) Smoking Status
In this final rule, we removed the 2015 Edition ``smoking status''
criterion (Sec. 170.315(a)(11)), which would include removing it from
the 2015 Edition Base EHR definition. To calculate the cost savings for
removing this criterion, we used the 2015 Edition estimated costs of
developing and preparing the criterion to the 2015 Edition, between
$15,750 and $31,500 and estimated that 35 percent of developers would
be newly certified in 2018 and 15 percent in 2019. We estimated the
cost of development and preparation costs to be between $5,512.50 and
$11,025 for 2018 and $2,362.50 and $4,725 for 2019. We calculated the
cost per month for years 2018 and 2019 and using the high point
estimates, estimated the development and preparation costs over a 6 to
12 month period between August 2018 and August 2019. We estimated the
costs to be between $4,068.75 at six months and $6,825 at 12 months.
Based on analysis of recent data, our assumptions continue to hold
true.
To calculate the cost for testing for this criterion, five
developers were estimated in the 2015 Edition to develop products to
this criterion. We multiplied the five developers by our estimated cost
to test per criterion of $475. This estimated cost per criterion was
based on what one ONC-ATL charged for testing and averaged per
criterion. To be conservative, we reduced the number by ten percent and
five percent respectively resulting in $2,137.50 and $2,256.25.
Taking these estimated costs into account we expect the cost
savings for removing the 2015 Edition ``smoking status'' criterion to
be between $8,962.50 and $9,081.25.
Comments. We did not receive comments specific to the removal of
the 2015 Edition ``smoking status'' criterion (Sec. 170.315(a)(11)).
Response. We maintain our approach and estimates for removing the
2015 Edition ``smoking status'' criterion (Sec. 170.315(a)(11)) from
the 2015 Edition. However, we did update estimates to 2017 dollars.
(v) Removal of Certain Certification Requirements
In this final rule, we removed Sec. 170.523(k)(1)(iii)(B), which
requires ONC-ACBs to ensure that certified health IT includes a
detailed description of all known material information concerning
limitations that a user may encounter in the course of implementing and
using the certified health IT, whether to meet ``meaningful use''
objectives and measures or to achieve any other use within the scope of
the health IT's certification. We also removed Sec.
170.523(k)(1)(iv)(B) and (C), which state that the types of information
required to be disclosed include, but are not limited to: (B)
Limitations, whether by contract or otherwise, on the use of any
capability to which technology is certified for any purpose within the
scope of the technology's certification; or in connection with any data
generated in the course of using any capability to which health IT is
certified; (C) limitations, including, but not limited to, technical or
practical limitations of technology or its capabilities, that could
prevent or impair the successful implementation, configuration,
customization, maintenance, support, or use of any capabilities to
which technology is certified; or that could prevent or limit the use,
exchange, or portability of any data generated in the course of using
any capability to which technology is certified.
To calculate the savings related to removing these two disclosure
requirements, we estimated 830 products certified to the 2015 Edition.
We did so by applying the market consolidation rate of -23.2 percent
which was the rate observed between 2011 and 2014 Editions. If an ONC-
ACB spends 1 hour on average reviewing costs, limitations and mandatory
disclosures, we estimated the time saved by no longer having to review
the limitations to be two-thirds of an hour. The hourly wage with
benefits for a GS-13, Step 1 employee located in Washington, DC is
approximately $91 and we assume this to be the hourly rate for an ONC-
ACB reviewer. We multiplied 830, the projected number of certified
products, by two-thirds of an hour and the assumed hourly rate and
calculated the cost savings to be $50,353.
(2) Updates to the 2015 Edition Certification Criteria
The following section details the costs and benefits for updates to
the 2015 Edition health IT certification criteria, which includes costs
and benefits to update certain 2015 Edition criteria to due to the
adoption of the United States Core Data for Interoperability (USCDI) as
a standard, and costs for new or revised 2015 Edition criteria for: EHI
export, API, privacy and security transparency attestations, and
security tags.
(i) United States Core Data for Interoperability
In order to advance interoperability by ensuring compliance with
new structured data and code sets that support the data, we have
replaced the ``Common Clinical Data Set'' (CCDS) definition and its
references with the ``United States Core Data for Interoperability''
(USCDI) standard, naming Version 1 (v1) in Sec. 170.213 and
incorporated it by reference in Sec. 170.299. The USCDI will replace
the CCDS 24 months after the publication date of this final rule. The
USCDI v1 establishes a minimum set of data classes (including
structured data) that are required for health IT to be interoperable
nationwide and is designed to be expanded in an iterative and
predictable way over time.
The USCDI v1 adds three new data classes, ``Allergies and
Intolerances,'' ``Clinical Notes,'' and ``Provenance;'' and adds to
``Patient Demographics'' the data elements ``Previous Address,''
``Phone Number,'' ``Phone Number Type,'' and ``Email Address'' that
were not defined in the CCDS. This requires updates to the Consolidated
Clinical Document Architecture (C-CDA) standard and updates to the
following certification criteria: Sec. 170.315(b)(1) (transitions of
care); (e)(1) (view, download, and transmit to 3rd party); (g)(6)
(Consolidated CDA creation performance); (f)(5) (transmission to public
health agencies--electronic case reporting); and (g)(9) (application
access--all data request). From our analysis of the C-CDA standard, we
concluded that the requirements of the ``Provenance'' data class are
already met by the existing C-CDA standard and will not require any new
development. Therefore, we have estimated the cost to health IT
developers to add support for ``Allergies and Intolerances'' and
``Clinical Notes'' data classes and ``Previous Address,'' ``Phone
Number,''
[[Page 25913]]
``Phone Number Type,'' and ``Email Address'' data elements in C-CDA,
and the necessary updates to the affected certification criteria. These
estimates are detailed in Table 7 and are based on the following
assumptions:
Health IT developers will use the same labor costs and
data models. Table 7 shows the estimated labor costs per product for a
health IT developer to develop support for the additional USCDI data
element in the C-CDA standard and affected certification criteria. We
recognize that health IT developer costs will vary; however, our
estimates in this section assume all health IT developers will incur
the costs noted in Table 7.
A proxy is needed to project the number of 2015 Edition
certified health IT products. As the 2015 Edition certification is
ongoing, using the current count of developers and products would
underestimate the overall costs and benefits, so we therefore use a
proxy. We estimate that 545 products from 458 developers will be
affected. Our proxy is based on the number of 2014 Edition certified
health IT products that are capable of recording patient data.\208\
There were 710 products by 588 developers with at least one 2014
Edition product capable of recording patient data. We then multiplied
these numbers by our certified health IT market consolidation estimates
of -22.1 percent and -23.2 percent to project the number of 2015
developers and products, respectively.
---------------------------------------------------------------------------
\208\ We defined ``products capable of recording patient data''
as any 2014 Edition health IT product that was certified for at
least one of the following criteria: Demographics ((a)(5)),
Medication List ((a)(7)), Medication Allergy List ((a)(8)), Problem
List ((a)(6)), and Family Health History ((a)(12)).
---------------------------------------------------------------------------
According to the May 2017 BLS occupational employment
statistics, the mean hourly wage for a ``Software Developer'' is
$53.74.\209\
---------------------------------------------------------------------------
\209\ See ``software developer, systems software''--https://www.bls.gov/oes/2017/may/oes151133.htm.
Table 7--Costs to Health IT Developers To Develop Support for the Additional USCDI Data Element in C-CDA
Standard and Affected Certification Criteria
[2017 Dollars]
----------------------------------------------------------------------------------------------------------------
Lower bound Upper bound
Tasks Details hours hours Remarks
----------------------------------------------------------------------------------------------------------------
Update C-CDA creation............. New development to 1,200 2,400 (1) Lower bound
support ``Allergies assumes health IT
and Intolerances,'' already has
``Clinical Notes,'' developed C-CDA R2.1
``Previous into their system
Address,'' ``Phone and only needs to be
Number,'' ``Phone updated for new data
Number Type,'' and elements.
``Email Address'' (2) Upper bound
for C-CDA and C-CDA estimates effort for
2.1 Companion Guide. organizations that
are on older
versions of C-CDA
standard, for
example C-CDA R1.1.
Sec. 170.315(b)(1) (transitions New development to 200 600 Necessary updates to
of care). support ``Allergies health IT to support
and Intolerances,'' the new data class
``Clinical Notes,'' to meet the criteria
``Previous requirements.
Address,'' ``Phone
Number,'' ``Phone
Number Type,'' and
``Email Address''
for C-CDA and C-CDA
2.1 Companion Guide.
Sec. 170.315(e)(1) (view, New development to 400 1,000 Necessary updates to
download, and transmit to 3rd support ``Allergies health IT to support
party). and Intolerances,'' the new data class
``Clinical Notes,'' to meet the criteria
``Previous requirements.
Address,'' ``Phone
Number,'' ``Phone
Number Type,'' and
``Email Address''
for C-CDA and C-CDA
2.1 Companion Guide.
Sec. 170.315(g)(6) (Consolidated New development to 200 600 Sec. 170.315(b)(1)
CDA creation performance). support ``Allergies and Sec.
and Intolerances,'' 170.315(g)(6) are
``Clinical Notes,'' related and may be
``Previous developed together.
Address,'' ``Phone
Number,'' ``Phone
Number Type,'' and
``Email Address''
for C-CDA and C-CDA
2.1 Companion Guide.
--------------------------------
Total Hours................... ..................... 2,000 4,600 .....................
--------------------------------
Hourly Rate................... ..................... $107 .............. .....................
--------------------------------
Cost per Product.............. ..................... $214,000 $492,200 .....................
--------------------------------
Total Cost (545 products)..... ..................... $116.6 million $268.2 million .....................
----------------------------------------------------------------------------------------------------------------
We estimated that the cost to a health IT developer to develop
support for the additional USCDI data elements would range $214,000 to
$492,200. Therefore, assuming 545 products, we estimate that the total
annual cost to all health IT developers would, on average, range from
$116.6 million to $268.2 million. This would be a one-time cost to
developers per product that is certified to the specified certification
criteria and would not be perpetual.
We believe this would benefit health care providers, patients, and
the industry as a whole. Clinical notes and provenance were included in
the draft USCDI v1 based on significant feedback from the industry,
which highly
[[Page 25914]]
regarded their desirability as part of interoperable exchanges. The
free text portion of the clinical notes was most often relayed by
clinicians as the data they sought, but were often missing during
electronic health information exchange. Similarly, the provenance of
data was also referenced by stakeholders as a fundamental need to
improve the trustworthiness and reliability of the data being
exchanged.
We expect improvements to interoperable exchange of information and
data provenance to significantly benefit providers and patients. For
example, in 2018, among individuals who had viewed their online medical
record within the past year (representing 30 percent nationally), about
half indicated that clinical notes were included in their online
medical record.\210\ Additionally, seven percent of individuals who
viewed their online medical record requested a correction of inaccurate
information. Thus, enabling patients to have access to their clinical
notes might assist in reducing medical coding errors.
---------------------------------------------------------------------------
\210\ Patel V & Johnson C. (May 2019). Trends in Individuals'
Access and Use of Online Medical Records and Technology for Health
Needs: 2017-2018. ONC Data Brief, no.48 Office of the National
Coordinator for Health Information Technology: Washington DC.
---------------------------------------------------------------------------
Patient matching is a barrier to interoperability. In 2017, 36
percent of non-Federal acute care hospitals reported difficulty
matching or identifying the correct patient between systems.\211\ The
data elements ``Previous Address,'' ``Phone Number,'' ``Phone Number
Type,'' and ``Email Address'' were included in the USCDI v1 based on
feedback from industry, for their usage in accurate patient matching.
---------------------------------------------------------------------------
\211\ Pylypchuk Y., Johnson C., Henry J. & Ciricean D. (November
2018). Variation in Interoperability among U.S. Non-Federal Acute
Care Hospitals in 2017. ONC Data Brief, no.42. Office of the
National Coordinator for Health Information Technology: Washington
DC.
---------------------------------------------------------------------------
However, we are not aware of an approach for quantifying these
benefits and we welcomed comments on potential approaches to
quantifying these benefits in the Proposed Rule.
Comments. We did not receive comments regarding an approach to
quantify benefits. However, we did receive comment regarding estimation
of the time and effort on behalf of health IT developers to update to
the USCDI. Commenters stated that we have underestimated the number of
hours necessary for health IT developers, suggesting that it is triple
our estimates.
Response. We thank commenters for their input. We maintain the
approach we proposed in the Proposed Rule in regard to our estimates
for updating the USCDI. This final rule constrains ``provenance'' to
only the scope of data for which the health IT developer is the owner/
steward. Hence, the scope is fairly limited and therefore, we believe
our estimates to be accurate. We note the removal of ``data export''
(Sec. 170.315(b)(6)) from the cost estimate in Table 6, in alignment
with our final policy decisions and no longer updating the criterion to
USCDI. We did, however, increase the hour per developer based on
additional data elements included in this final rule.
(ii) Electronic Health Information Export
In this final rule, we adopted a modified version of the ``EHI
export'' criterion in Sec. 170.315(b)(10). Notably, we have defined
and further constrained the criterion's scope of data for export as
EHI, as defined in Sec. 171.102, that can be stored at the time of
certification by the product, of which the Health IT Module is a part.
The final criterion provides a focused set of data from a scope
perspective and clarifies what a product with a certified Health IT
Module must be capable of exporting. The intent of this criterion aims
to provide Health IT Module users the functionality to efficiently
export or direct the export of EHI for a single patient or a patient
population in a computable, electronic format.
(A) Costs To Develop and Maintain EHI Export Criterion
This section describes the estimated costs of the ``EHI export''
criterion. The cost estimates are based on the following assumptions:
Health IT developers will use the same labor costs and
data models. Table 8 shows the estimated labor costs per product for a
health IT developer to develop and maintain the EHI export
functionality. We recognize that health IT developer costs will vary;
however, our estimates in this section assume all health IT developers
will incur the costs noted in Table 8.
A proxy is needed to project the number of 2015 Edition
certified health IT products containing the ``EHI export'' criterion.
We estimated that 545 products from 458 developers will contain the
``EHI export'' criterion. To develop these estimates, we first
identified a proxy for the number of health IT developers that may
create a 2015 Edition certified health IT product containing the ``EHI
export'' criterion. Our proxy is based on the number of 2014 Edition
certified health IT products that are capable of recording patient
data.\212\ We based our estimates on these products because data must
be captured to be exported under the adopted criterion. There were 710
products by 588 developers with at least one 2014 Edition product
capable of recording patient data. We then multiplied these numbers by
our certified health IT market consolidation estimates of -22.1 percent
and -23.2 percent to project the number of 2015 developers and
products, respectively.
---------------------------------------------------------------------------
\212\ We defined ``products capable of recording patient data''
as any 2014 Edition product that was certified for at least one of
the following criteria: Demographics ((a)(5)), Medication List
((a)(7)), Medication Allergy List ((a)(8)), Problem List ((a)(6)),
and Family Health History ((a)(12)).
---------------------------------------------------------------------------
Wages are determined using BLS estimates. According to the
May 2017 BLS occupational employment statistics, the mean hourly wage
for a ``Software Developer'' is $53.74.\213\ As noted previously, we
have assumed that overhead costs (including benefits) are equal to 100
percent of pre-tax wages, so the hourly wage including overhead costs
is $107.
---------------------------------------------------------------------------
\213\ https://www.bls.gov/oes/2017/may/oes151133.htm.
[[Page 25915]]
Table 8--Estimated Labor Costs To Develop and Maintain the EHI Export Criterion per Product
----------------------------------------------------------------------------------------------------------------
Lower bound Upper bound
Activity hours hours Remarks
----------------------------------------------------------------------------------------------------------------
Task 1: Developing the Data Dictionary 160 1,600 This is the effort to document all
software capability to export EHI in a the data exported by the product
developer format (per product). for a single patient and for all
patients.
The lower bound assumes that the
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 assumes that
the developer will be able to use
the format of their choice.
Task 2: Updating the Data Dictionary and 80 500 This is the maintenance cost to
publishing the updated format (per update the data dictionary
product). published by the product to ensure
that the data dictionary is
compatible with newer releases of
the product. The lower bound
estimate assumes the effort when
there are only minor changes to
the formats of the data stored by
the product. The upper bound
estimate assumes the effort when
the product makes substantial
changes to the formats of the
data.
Task 3: Updating the software that performs 80 500 This is the maintenance cost to
EHI Export (per product). upgrade the software that would
generate the EHI export files. The
lower bound estimates the cost to
maintain the software when there
are only minor changes to the
product, including updates to
underlying software (e.g.,
database versions, operating
systems, etc.). The upper bound
estimate accounts for substantial
reworking of the export software
program to export in new formats
or based on substantial changes
made to the underlying storage
system.
--------------------------------
Total Labor Hours...................... 320 2,600 ...................................
----------------------------------------------------------------------------------------------------------------
Table 9--Example Calculation for the Lower Bound Estimated Cost To Health IT Developers To Perform Task 1 for
the EHI Export Criterion
[2016 Dollars]
----------------------------------------------------------------------------------------------------------------
Estimated labor
Activity hours lower Developer Projected
bound salary products
----------------------------------------------------------------------------------------------------------------
Task 1....................................................... 160 hours $107 per hour 545 products
----------------------------------------------------------------------------------------------------------------
Example Calculation
----------------------------------------------------------------------------------------------------------------
160 hours * $107 * 545 products = $9,330,400
----------------------------------------------------------------------------------------------------------------
Table 10--Total Cost To Develop and Maintain the EHI Export Criterion
[2017 Dollars]
------------------------------------------------------------------------
Estimated cost
Activity -------------------------------
Lower bound Upper bound
------------------------------------------------------------------------
Task 1 (545 products)................... $9,330,400 $93,304,000
Task 2 (545 products)................... 4,665,200 29,157,500
Task 3 (545 products)................... 4,665,200 29,157,500
-------------------------------
Total (545 products)................ 18,660,800 151,619,000
------------------------------------------------------------------------
(B) Costs To Implement and Support the EHI Export Criterion
The cost estimates are based on the following assumptions:
Health care providers will use the same costs and data
models. Table 11 shows the estimated costs to implement and support the
EHI Export criterion. The cost estimates used in this calculation were
published by the Agency for Healthcare Research and Quality and were
based on the average cost to implement an EHR for a clinical
practice.\214\ This publication was based on the implementation of an
entire EHR system. We assume that all stakeholders impacted by this
rule will already have a base EHR system implemented, therefore we
discounted these estimates by a factor of 10 to better reflect the cost
to implement an EHI Export module only. We did not have cost estimates
for hospitals. Therefore, to estimate the cost for a hospital to
implement an EHR system, we multiplied the estimate to
[[Page 25916]]
implement an EHR for a clinical practice by a factor of 10. We believe
this will better reflect the increased magnitude and complexity of
implementing and supporting a new health IT module in a hospital
compared to a clinical practice. We recognize that costs health care
providers incur will vary; our estimates in this section assume health
care providers incur the costs noted in Table 11.
---------------------------------------------------------------------------
\214\ Fleming, N., Impact of Health Information Technology on
Primary Care Workflow and Financial Measures AHRQ Publication No.
11-0081-4-EF, October 2011 https://digital.ahrq.gov/sites/default/files/docs/page/Fleming_SS_508_20111021_d.pdf.
---------------------------------------------------------------------------
Hospitals and clinical practices that have participated in
the CMS EHR Incentive Program will be impacted. We estimate that 95,470
clinical practices \215\ and 4,519 hospitals \216\ will be impacted by
our rule.
---------------------------------------------------------------------------
\215\ This number was estimated based on the de-duplicated
number of practices that had at least one clinician participate in
the CMS Medicare Electronic Health Record Incentive Program.
\216\ This estimate is the total number of eligible hospitals
that ever participated in the CMS Medicare Electronic Health Record
Incentive Program.
Table 11--Estimated Cost to Hospitals and Clinical Practices To Implement and Support the EHI Export Criterion
[2017 Dollars]
--------------------------------------------------------------------------------------------------------------------------------------------------------
Cost per entity
Task Entity type Number of -------------------------------- Remarks
entities Lower bound Upper bound
--------------------------------------------------------------------------------------------------------------------------------------------------------
Task 1: Implementation and Support....... Clinical Practices......... 95,470 $2,000 $4,000 This task would involve costs
associated with staff support
during implementation, workflow
mapping and redesign, content
development and customization,
project management, and other
technical deployment including
networking.
Hospitals.................. 4,519 20,000 40,000
Task 2: Staff Training................... Clinical Practices......... 95,470 500 1,000 This task would involve staff
training for implementation
teams and staff end users.
Hospitals.................. 4,519 5,000 10,000
--------------------------------------------------------------------------------------------------------------------------------------------------------
Table 12--Total Cost To Implement and Support the EHI Export Criterion
[2017 Dollars]
----------------------------------------------------------------------------------------------------------------
Task Lower bound Upper bound
----------------------------------------------------------------------------------------------------------------
Task 1: Implementation and Support......... Clinical Practices........... $190,940,000 $381,880,000
Hospitals.................... 90,380,000 180,760,000
Task 2: Staff Training..................... Clinical Practices........... 47,735,000 95,470,000
Hospitals.................... 22,595,000 45,190,000
--------------------------------------------------------------------
Total Cost............................. ............................. 351,650,000 703,300,000
----------------------------------------------------------------------------------------------------------------
Based on the stated assumptions and costs outlined in Tables 8 and
10, the total estimated cost for health IT developers to develop
products to the ``EHI export'' criterion will range from $18.7 million
to $151.6 million. Assuming 458 health IT developers, there would be an
average cost per health IT developer ranging from $40,744 to $331,045.
We note that the development costs, which equal half of the total,
would be a one-time cost and would not be perpetual. The total
estimated cost for hospitals and clinical practices to implement and
support the EHI Export will range from $351.7 million to $703.3
million. The midpoint of ranges stated is used as the primary estimate
of costs.
(C) Benefits
Health care providers may choose to change their EHRs for a number
of reasons. However, the steps and costs associated with switching
one's EHR are complex. Market forces, such as health IT developers'
business incentives, make it difficult and costly for EHR users to
transfer system data from one developer to another. Data transfer costs
vary depending on how contracts are structured.\217\ Specifically,
contracts might include high data-transfer fees or do not include
conditions for data transfer. Providers may also pay fees for
consultants or technical staff to help with the data-transfer process
given differences in how data may be mapped from one developer to
another. Hence, health care providers will experience benefits
associated with the standardization proposed in the EHI export
functionality.
---------------------------------------------------------------------------
\217\ Pratt, Mary, The True Cost of Switching EHRs, Medical
Economics, May 30, 2018, Volume: 96 Issue: 10.
---------------------------------------------------------------------------
Because of the EHI export functionality, providers will no longer
incur the costs associated with mapping data from their health IT
database into standard terms or exporting said data using a
standardized format when switching EHRs. In our analysis, we calculated
the benefits in terms of the reduced costs to providers as a result of
our rule eliminating these two tasks. The benefit calculations below
are based on the following assumptions:
On average, five percent of providers and hospitals switch
their health IT annually. Using CMS Medicare EHR Incentive Program data
from years 2013-2016, we estimate the rate of providers (hospitals and
eligible professionals) that changed their health IT developer. We
believe that the EHI export functionality would help alleviate the
burden of switching between health IT systems by increasing portability
of EHI that can be stored at the time of certification by the product,
of which the Health IT Module is a part. Thus, the benefit calculations
are based on assumptions regarding the number of clinical practices (n
= 4,774) and hospitals (n = 226) that are projected to switch products
in a year.
[[Page 25917]]
Health IT consultants \218\ will use the same labor costs
and data models. Table 13 shows the estimated labor costs per product
for a hospital or health care provider to hire a health IT consultant
to perform data export of EHI, as defined in 45 CFR 171.102, without
the EHI export functionality. We recognize that these costs will vary
based on the size of the hospital or clinical practice.
---------------------------------------------------------------------------
\218\ ``Health IT consultant'' refers to a technical expert that
a hospital or provider will hire to migrate their data from a legacy
system to a new EHR.
---------------------------------------------------------------------------
Wages are determined using BLS estimates. According to the
May 2017 BLS occupational employment statistics, the mean hourly wage
for a ``Software Developer'' is $53.74.\219\ As noted previously, we
have assumed that overhead costs (including benefits) are equal to 100
percent of pre-tax wages, so the hourly wage including overhead costs
is $107.
---------------------------------------------------------------------------
\219\ https://www.bls.gov/oes/2017/may/oes151133.htm.
Table 13--Cost per Provider To Perform Data Export Without EHI Export Functionality When Switching Health IT
Products
[2017 Dollars]
----------------------------------------------------------------------------------------------------------------
Estimated cost Estimated cost
per health IT per health IT
Activity switch (lower switch (upper Remarks
bound) (hours) bound) (hours)
----------------------------------------------------------------------------------------------------------------
Task 1: Understanding and mapping the data 320 3,200 The lower bound is an estimate for
in health IT database into standard terms. a small provider practice using
the standard instance of a
certified health IT product with
no customization and use of
nationally recognized content
standards. The upper bound
estimates a medium to large
practice with substantial local
customization of content.
Task 2: Exporting the data from the health 160 1,600 The lower bound assumes that the
IT into a format that can be subsequently certified health IT product is
used to import. capable of exporting most of the
data into standard output format
such as C-CDA. The upper bound
estimates the case where a large
amount of data is not easily
exported by the 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 14 provides an example calculation for how we calculated our
total costs presented in Table 15.
Table 14--Example Calculation for the Lower Bound Estimated Cost to Providers To Hire a Health IT Consultant To
Perform Task 1 Without the EHI Export Criterion
[2017 Dollars]
----------------------------------------------------------------------------------------------------------------
Estimated annual
Activity Estimated labor Developer salary number of health
hours lower bound IT switches
----------------------------------------------------------------------------------------------------------------
Task 1.............................................. 320 hours $107 per hour 5,000 switches
----------------------------------------------------------------------------------------------------------------
Example Calculation:
320 hours * $107 * 5000 switches = $171,200,000.
----------------------------------------------------------------------------------------------------------------
Table 15--Total Cost to Providers To Perform Data Export Without the EHI
Export Criterion When Switching Health IT Products
[2017 Dollars]
------------------------------------------------------------------------
Estimated cost
Activity -------------------------------------
Lower bound Upper bound
------------------------------------------------------------------------
Task 1............................ $171,200,000 $1,712,000,000
Task 2............................ 85,600,000 856,000,000
-------------------------------------
Total Cost Savings (5,000 256,800,000 2,568,000,000
switches)....................
------------------------------------------------------------------------
[[Page 25918]]
We multiplied the costs to switch health IT by the estimated number
of hospitals and clinical practices affected. Thus the estimated annual
benefit, in terms of cost savings to hospitals and clinical practices,
would range from $256.8 million to $2.6 billion.
(iii) Application Programming Interfaces
The API requirements in this final rule reflect the full depth and
scope of what we believe is necessary to implement the API Condition of
Certification requirement described in section 4002 of the Cures Act.
We have adopted new standards, new implementation specifications, a new
certification criterion, and detailed Conditions and Maintenance of
Certification requirements in Sec. Sec. 170.213 and 170.215, 170.315,
and 170.404, respectively. We also modified the Base EHR definition in
Sec. 170.201.
(A) Costs To Develop and Maintain Certified API Technology
This section describes the potential costs of the API certification
criterion. The cost estimates below are based on the following
assumptions:
Health IT developers will use labor costs and data models
based on whether they have adopted aspects of the API certification
criterion. Tables 16 A and 16 B show the estimated labor costs per
product for a health IT developer to develop and maintain an API. We
recognize that health IT developer costs will vary based on whether
they have already implemented aspects of the API certification
criterion; including adopting the Fast Healthcare Interoperability
Resources (FHIR[supreg]) API. To account for this variation, we have
estimated two cost tables. Table 16 A reflects the range of costs
incurred for new products or those developers that have not previously
certified to the API certification criteria. Table 16 B shows the cost
for developers that have already implemented the API criteria. We have
assumed in our calculations that all health IT developers will incur
costs noted in either Table 16 A or Table 16 B.
A proxy is needed to project the number of 2015 Edition
certified health IT products containing the API certification
criterion. We estimated that 459 products from 394 developers will
contain the API criterion. We used a proxy to determine the number of
health IT developers that may develop an API for the certification to
the 2015 Edition. There were 598 products and 506 developers with at
least one 2014 Edition certified health IT product that could perform
transitions of care. We then multiplied this number by our certified
health IT market consolidation estimates of -22.1 percent and -23.2
percent to project the number of 2015 developers and products,
respectively. Some developers and products are already leveraging
aspects of the API certification criterion. This could reduce their
cost to implement the criterion. To determine the number of developers
and products applicable to cost Table 16 A or 16 B, we calculated the
proportion of products and developers that have already certified to
API certification criterion. We then applied this estimate to the
projected number of 2015 Edition certified health IT products.
Specifically, we estimate that 50 percent of products (230) and 55
percent of developers (217) will incur costs reflected in Table 16 A
because they have no prior experience with certifying to the API
criteria. We believe this estimate serves as a reasonable proxy for
products' capability to send patient data and the cost of
implementation. The API functionality required by the 2015 Edition
achieves a similar end by allowing providers to retrieve patient data
from secure data servers hosted by other developers, as well as
providing patients access to their medical records through third-party
applications connected to these same secure servers.
Wages are determined using BLS estimates. According to the
May 2017 BLS occupational employment statistics, the mean hourly wage
for a ``Software Developer'' is $53.74.\220\
---------------------------------------------------------------------------
\220\ https://www.bls.gov/oes/2017/may/oes151133.htm.
Table 16 A--Estimated Labor Hours To Develop and Maintain API--New Products
----------------------------------------------------------------------------------------------------------------
Estimated labor hours
Activity Details -------------------------------- Remarks
Lower bound Upper bound
----------------------------------------------------------------------------------------------------------------
Task 1: Implementing security (1) New development to 1000 1500 (1) Lower bound
via SMART App Launch Framework support OpenID Connect. assumes health IT has
IG (per product). (2) Implementation of already implemented
the Smart Guide with security via SMART
support for refresh App Launch Framework
tokens and the core IG and need to be
capabilities specified updated to account
in the rule. for additional
(3) New development to requirements in the
respond to request for rule including
access token Support for
verification. additional ``core''
capabilities required
by rule and Token
Introspection.
(2) Upper bound
assumes new
development for
implementation of
SMART App Launch
Framework IG, and
additional
requirements in the
rule including Token
Introspection.
Task 2: Develop support for (1) New development to 2000 6000 (1) Lower bound
Fast Healthcare support FHIR R4. assumes health IT
Interoperability Resources (2) Implementation to already has developed
(FHIR[supreg]) API and the FHIR US Core IG. FHIR DSTU2 2015
associated IGs (per product). Edition for data
classes that were
specified in prior
rule and only needs
to be updated to R4
and new data classes
specified in the rule
(2) Upper bound
assumes new
development of FHIR
API for all resources
[[Page 25919]]
Task 3: Develop API for (1) New development to 2000 4500 (1) Lower bound
Population Level Services (per support FHIR Bulk Data assumes health IT
product). Access IG. already has an
Note: One-time cost............ existing API for
population level
services; and need to
migrate to the
standardized API
specified in the
rule.
(2) Upper bound
assumes new
development of FHIR
Bulk Data Access IG.
Task 4: Development of App (1) New registration 1000 2500 (1) Lower bound
registration Server and Portal server development (or assumes that the
(per developer). updates to existing developer already has
server) to support existing application
registration registration
timeliness and infrastructure in
publication of FHIR place, and only needs
endpoints. to update it to
(2) Development of support the API
portal and managing Maintenance of
the application Certification
registration system. requirements.
(2) Upper bound is new
development of an
application
registration service
and portal.
Task 5: Update Application (1) Yearly updates and 400 1300 (1) Lower bound
Registration Server and Portal maintenance to keep estimates hours to
(per developer). the portal running. We keep it running with
do not anticipate any junior staff.
major changes to the (2) Upper bound
standard and will be estimates small
primarily driven by updates.
usage and developer
interest.
Task 6: Develop support for (1) Develop capability 250 1500 (1) Lower bound
patients to revoke access to to identify apps assumes that the
authorized app (per product).. authorized by developer already has
Note: One-time cost............ registered users. a portal used by
(2) Provide capability patients for managing
to remove access at their preferences and
patient direction. new development will
be needed to provide
patients with ability
to view and revoke
access to their
authorized apps.
(2) Upper bound
assumes that
developer's current
capability of
managing registered
patients need to be
significantly
enhanced to support
enabling patients to
revoke access to the
authorized apps.
Other costs (50% per product, (1) Server costs for $7,500 $30,000 (1) Estimated as
50% per developer) \(2017 application monetized costs and
Dollars)\. registration, sandbox, not as hours; most of
Note: One-time cost............ bulk data storage, and the costs would be
costs associated with one-time procurement
making documentation costs plus yearly
publicly available. maintenance.
(2) Software costs
(e.g., databases,
application servers,
portal technology).
----------------------------------------------------------------------------------------------------------------
Table 16 B--Estimated Labor Hours To Develop and Maintain API--Currently Certified Products
----------------------------------------------------------------------------------------------------------------
Estimated labor hours
Activity Details -------------------------------- Remarks
Lower bound Upper bound
----------------------------------------------------------------------------------------------------------------
Task 1: Implementing security (1) Development to 800 1000 (1) Lower bound
via SMART App Launch Framework support OpenID Connect. assumes health IT has
IG (per product). (2) Implementation of already implemented
the Smart Guide with security via SMART
support for refresh App Launch Framework
tokens and the core IG and need to be
capabilities specified updated to account
in the rule. for additional
(3) Development to requirements in the
respond to request for rule.
access token (2) Upper bound
verification. assumes additional
development for
implementation of
SMART App Launch
Framework IG, and
additional
requirements in the
rule.
Task 2: Develop support for (1) Development to 1600 2000 (1) Lower bound
Fast Healthcare support FHIR R4. assumes health IT
Interoperability Resources (2) Implementation to already has developed
(FHIR[supreg]) API and the FHIR US Core IG. FHIR R4 for data
associated IGs (per product). classes that were
specified in prior
rule and only needs
to be updated to new
data classes
specified in the
rule.
(2) Upper bound
assumes health IT was
originally developed
for FHIR DSTU2 and
needs additional
development of FHIR
API to support
upgrading to FHIR R4
and new data classes.
[[Page 25920]]
Task 3: Develop API for (1) New development to 2000 4500 (1) Lower bound
Population Level Services (per support FHIR Bulk Data assumes health IT
product). Access IG. already has an
Note: One-time cost............ existing API for
population level
services; and need to
migrate to the
standardized API
specified in the
rule.
(2) Upper bound
assumes new
development of FHIR
Bulk Data Access IG.
Task 4: Development of App (1) New registration 800 1000 (1) Lower bound
registration Server and Portal server development (or assumes that the
(per developer). updates to existing developer already has
server) to support existing application
registration registration
timeliness and infrastructure in
publication of FHIR place, and only needs
endpoints. to update it to
(2) Development of support the API
portal and managing Maintenance of
the application Certification
registration system. requirements.
(2) Upper bound
assumes additional
development to
support requirements
in rule.
Task 5: Update Application (1) Yearly updates and 320 400 (1) Lower bound
Registration Server and Portal maintenance to keep estimates hours to
(per developer). the portal running. We keep it running with
do not anticipate any junior staff.
major changes to the (2) Upper bound
standard and will be estimates small
primarily driven by updates.
usage and developer
interest.
Task 6: Develop support for (1) Develop capability 150 250 (1) Lower bound
patients to revoke access to to identify apps assumes the developer
authorized app (per product). authorized by provides this
Note: One-time cost............ registered users. functionality based
(2) Provide capability on 2015 ONC Edition
to remove access at and needs to perform
patient direction. minimum verification.
(2) Upper bound
assumes that the
developer already has
a portal used by
patients for managing
their preferences and
new development will
be needed to provide
patients with ability
to view and revoke
access to their
authorized apps.
Other costs (50% per product, (1) Server costs for $6000 $7,500 (1) Estimated as
50% per developer) \(2017 application monetized costs and
Dollars)\. registration, sandbox, not as hours; most of
Note: One-time cost............ bulk data storage, and the costs would be
costs associated with one-time procurement
making documentation costs plus yearly
publicly available. maintenance.
(2) Software costs
(e.g., databases,
application servers,
portal technology).
----------------------------------------------------------------------------------------------------------------
Table 17 provides an example calculation for how we calculated our
total costs presented in Tables 18 A and 18 B.
Table 17--Example Calculation for the Lower Bound Estimated Cost to New Products To Perform Task 1 in Table 13 A
To Develop API
[2017 Dollars]
----------------------------------------------------------------------------------------------------------------
Estimated labor hours
Activity ------------------------- Developer salary Projected products
Lower bound
----------------------------------------------------------------------------------------------------------------
Task 1............................... 1,000 hours............ $107 per hour.......... 230 products.
----------------------------------------------------------------------------------------------------------------
Example Calculation:
1,000 hours * $107 * 230 products
= $24,610,000.
----------------------------------------------------------------------------------------------------------------
Table 18 A--Total Cost To Develop and Maintain API--New Products
[2017 Dollars]
------------------------------------------------------------------------
Estimated lost
Activity -------------------------------
Lower bound Upper bound
------------------------------------------------------------------------
Task 1 (230 products)................... $24,556,500 $36,834,750
Task 2 (230 products)................... 49,113,000 147,339,000
Task 3 (230 products)................... 49,113,000 110,504,250
[[Page 25921]]
Task 4 (217 developers)................. 23,186,900 57,967,250
Task 5 (217 developers)................. 9,274,760 30,142,970
Task 6 (230 products)................... 6,152,500 36,915,000
Other Costs (230 products).............. 860,625 3,442,500
Other Costs (217 developers)............ 812,625 3,250,500
-------------------------------
Total (230 products and 217 163,069,910 426,396,220
developers)........................
------------------------------------------------------------------------
Table 18 B--Total Cost To Develop and Maintain API--Currently Certified
Products
[2017 Dollars]
------------------------------------------------------------------------
Estimated cost
Activity -------------------------------
Lower bound Upper bound
------------------------------------------------------------------------
Task 1 (229 products)................... $19,645,200 $24,556,500
Task 2 (229 products)................... 39,290,400 49,113,000
Task 3 (229 products)................... 49,113,000 110,504,250
Task 4 (177 developers)................. 15,176,880 18,971,100
Task 5 (177 developers)................. 6,070,752 7,588,440
Task 6 (229 products)................... 3,675,450 6,125,750
Other Costs (229 developers)............ 688,500 860,625
Other Costs (177 products).............. 531,900 664,875
-------------------------------
Total (229 products and 177 134,192,082 218,384,540
developers)........................
------------------------------------------------------------------------
We note that we have adopted in Sec. 170.404(b)(3) a specific
requirement that an API Technology Supplier must support the
publication of Service Base URLs for all of its customers that are
centrally managed by the Certified API Developer, and make such
information publicly available (in a computable format) at no charge.
Thus, we are placing the responsibility of publishing the URLs on
health IT developers and those costs are captured in the registration
portal cost estimation in this RIA.
Based on the stated assumptions and costs outlined in Tables 16 A
and 16 B, the total estimated costs for health IT developers to develop
and maintain a product to the API criterion would range from $297.3
million to $644.8 million with an average cost per developer ranging
from $0.75 million to $1.64 million. We note that the ``other costs''
and costs associated with tasks 3 and 6, which account for $110.9
million to $272.3 million of this total, are one-time costs and are not
perpetual.
(B) Optional Cost To Acquire and Use Applications That Interact With
Certified API Technology
We believe the API certification criterion and associated Condition
and Maintenance of Certification requirements finalized in this rule
will create an environment that promotes innovation for software
developers to connect new tools and services that create efficiencies
for health care providers throughout their course of care delivery.
Software applications that connect to APIs is an emerging market that
we believe will be further enhanced by the standards, transparency, and
pro-competitive requirements finalized in this rule. As of October 25,
2018, researchers identified nearly 300 software applications being
marketed on EHR vendors' app stores. The majority of these applications
are designed for health care providers to help support use cases for
population health analytics, clinical decision support, patient
education, as well as to conduct administrative and financial
tasks.\221\ Although not required under this rule, this section
describes the potential costs of health care providers to acquire and
use new software applications that interact with certified API
technology. The cost estimates are based on the following assumptions:
---------------------------------------------------------------------------
\221\ Dullabh P, Hovey L, Heaney-Huls K, Rajendron N, Wright A,
Sittig D. Application Programming Interfaces in Health Care:
Findings from a Current-State Sociotechnical Assessment. Applied
Clinical Informatics. 2020; 11(01): 059-069.
---------------------------------------------------------------------------
Health care providers will use the same costs and data
models. Table 19 shows the estimated costs to acquire and use software
applications that interact with certified API technology. We recognize
that costs health care providers incur will vary based on several
factors including, but not limited to, size of the health care entity,
application usage, and complexity of deployment and maintenance.
However, our estimates in this section assume health care providers
incur the costs noted in Table 19.
Hospitals and clinical practices that have participated in
the CMS EHR Incentive Program will be impacted. We estimate that 95,470
clinical practices \222\ and 4,519 hospitals \223\ will be impacted by
our rule.
---------------------------------------------------------------------------
\222\ This number was estimated based on the de-duplicated
number of practices that had at least one clinician participate in
the CMS Medicare Electronic Health Record Incentive Program.
\223\ This estimate is the total number of eligible hospitals
that ever participated in the CMS Medicare Electronic Health Record
Incentive Program.
[[Page 25922]]
Table 19--Estimated Cost to Hospitals and Clinical Practices To Acquire and Use Software Applications That
Engage With Certified API Technology
[2017 Dollars]
----------------------------------------------------------------------------------------------------------------
Cost per entity Total cost
Entity type Number of ---------------------------------------------------------------
entities Lower bound Upper bound Lower bound Upper bound
----------------------------------------------------------------------------------------------------------------
Clinical Practices.............. 95,470 $1,000 $5,000 $95,470,000 $477,350,000
Hospitals....................... 4,519 10,000 100,000 45,190,000 451,900,000
-------------------------------------------------------------------------------
Total....................... .............. .............. .............. 140,660,000 929,250,000
----------------------------------------------------------------------------------------------------------------
The total cost to health care providers to acquire and use software
applications that engage with certified API technology would range from
$140.6 million to $929.3 million. The midpoint of ranges stated is used
as the primary estimate of costs.
(C) Benefits
The Medicare Access and CHIP Reauthorization Act (MACRA), (Pub. L.
114-10), tasks ONC with measuring interoperability in the health IT
industry.\224\ The measurement concepts developed include a multi-part
approach analyzing not only adoption of health IT functionalities
supporting information exchange but the downstream impact of these
technologies on data completeness, data integration, and supports for
core functions of patient care. The benefits of our API proposal are
similarly multifaceted.
---------------------------------------------------------------------------
\224\ Health IT Buzz Blog, Measuring Interoperability: Listening
and Learning, https://www.healthit.gov/buzz-blog/electronic-health-and-medical-records/interoperability-electronic-health-and-medical-records/measuring-interoperability-listening-learning/.
---------------------------------------------------------------------------
Our API proposal will increase interoperability by ensuring that
more data is available and shared between EHR users. The proposal will
also make data more widely available to software developers outside of
those specializing in EHR development. As a result, this data will lead
to greater innovation in the app market resulting in new technologies
for health care providers and patients alike. In the analysis, we
quantify benefits in the following three areas: First, provider time
saved as a result of new efficiencies in care delivery due to new
technologies, such as provider facing apps. Second, the effects of
interoperability on cost-savings associated with reductions in
duplicate lab tests, readmissions, emergency room (ER) visits, and
adverse drug events. We focused on these outcomes for two reasons:
Evidence in literature indicates that health information exchange
impacts the chosen measures; and cost of care associated with these
measures is high and the impact of health information exchange is
likely to result in significant benefits in the form of a cost
reduction.\225\ Finally, we quantify an increase in the number of
individuals with access to their health information through a mechanism
of their choice such as apps.
---------------------------------------------------------------------------
\225\ Analyzing the Public Benefit Attributable to Interoperable
Health Information Exchange https://aspe.hhs.gov/pdf-report/analyzing-public-benefit-attributable-interoperable-health-information-exchange.
---------------------------------------------------------------------------
The benefit calculations are based on the following assumptions:
Benefits noted in academic literature are assumed
accurate. Estimates of the benefits are based on estimates obtained
from peer reviewed academic literature. ONC reviewed academic articles
for validity; however, models were not replicated.
Hospitals and eligible professionals that have
participated in the CMS EHR Incentive Programs will be impacted:
Estimates assume that 439,187 health care providers and/or 4,519
hospitals would be affected by this regulatory action.
(D) Benefits: Provider Time Saved as a Result of New Efficiencies in
Care Delivery Due to the Optional Purchase of New Technologies, Such as
Provider Facing Apps
Improvements in technology result in benefits for consumers and
producers through increased production efficiencies (Stoneman
2018).\226\ The introduction of EHRs into the health care industry is
an example of this. Sinsky (2016) found physicians spend 27 percent of
their total time on direct clinical face time with patients, and 49.2
percent of their time on EHR and desk work.\227\ Outside of office
hours, physicians spend another one to two hours of personal time each
night doing additional computer and other clerical work. Despite the
number of hours providers spend in their EHR, there is evidence that
the introduction of EHRs is associated with time saved. Adler-Milstein
(2013) found that EHR use compared to non-EHR use resulted in a 5.3
percent increase in work relative value units per clinician work
day.\228\
---------------------------------------------------------------------------
\226\ Stoneman P, Bartoloni E., Baussola M. The Microeconomics
of Product Innovation. Oxford, United Kingdom: Oxford University
Press, 2018.
\227\ 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.
\228\ Julia Adler-Milstein and Robert S. Huckman, The Impact of
Electronic Health Record Use on Physician Productivity, Am J Manag
Care (Nov. 19, 2013).
---------------------------------------------------------------------------
Improved efficiencies are not limited to the installation of an
EHR. Providers also benefit from the use of emerging technologies.
Amusan (2008) found that EHR and computerized provider order entry
(CPOE) implementation was associated with 3.69 minutes of time saved
five months post implementation.\229\ Similarly, Helmons (2015) found
that the impact of suppressing clinically irrelevant alerts and adding
clinical-decision support to EHRs saved providers about two percent of
their time.
---------------------------------------------------------------------------
\229\ 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.
---------------------------------------------------------------------------
To measure the benefits of the API provision on providers' time as
a result of new technologies, we examined the literature on the impact
of IT on productivity across various industries. As explained in Bartel
(2007), improvements in IT could affect productivity through multiple
mechanisms that are not necessarily associated with the underlying
intention of that technology.\230\ When examining the effect of IT in
manufacturing, researchers found that adoption of IT affected
production plants' composition of products, reduced time of production
processes, and increased hiring of skilled workers. We adopt the same
logic here. Specifically, we assume that the impact of the data made
available under our API provisions will not be
[[Page 25923]]
through a single mechanism, such as an EHR, but will have multiple
spillover effects. For example, data made available through an API
could be used by a software developer to create tools to improve
patient scheduling and billing processes. Use of this tool could result
in improvements in the providers' workflow. Thus, is important to
quantify the impacts of data made available through APIs on the future
health IT market.
---------------------------------------------------------------------------
\230\ Bartel, Ann & Ichniowski, Casey & Shaw, Kathryn. (2007).
How Does Information Technology Affect Productivity? Plant-Level
Comparisons of Product Innovation, Process Improvement, and Worker
Skills. The Quarterly Journal of Economics. 122. 1721-1758. 10.1162/
qjec.2007.122.4.1721.
---------------------------------------------------------------------------
Table 20 provides a summary of the results of the literature review
used to quantify this benefit.
Table 20--Findings From Literature on the Impact of Information Technology on Productivity
----------------------------------------------------------------------------------------------------------------
Study Description Findings: (%)
----------------------------------------------------------------------------------------------------------------
Bartel et al (2007)........................... Identify impact in improvements in information 4-8
technology on production time of valve
manufacturing. IT is defined as adoption of
separated information system that enable
various automations.
Lee et al (2013).............................. Identified impact of IT capital on hospital 3-6
productivity where IT capital is defined as
hospital expenditure on IT.
Shao and Lin (2002)........................... Identifies impact of IT expense on productivity 2-7
of fortune 500 firms.
Adler-Milstein et al (2013)................... Identifies the impact of the introduction of the 5
EHR on providers' time compared to non-EHR
users.
Helmons et al (2015).......................... Identifies impact of suppressing clinically 2
irrelevant alerts and adding clinical-decision
support to EHRs on time saved.
Wagholikar KB, et al (2015)................... Identifies impact of clinical-decision support 1
on time saved among primary care providers.
----------------------------------------------------------------------------------------------------------------
Sources:
\a\ Jinhyung Lee Jeffrey S. McCullough Robert J. Town. The impact of health information technology on hospital
productivity. The RAND Journal of Economics 44(3):545.
\b\ Shao, W. Lin, Technical efficiency analysis of information technology investments: a two-stage empirical
investigation, Information and Management 39, 2002, pp. 391-401.
\c\ Adler-Milstein, J. and Huckman, R, The Impact of Electronic Health Record Use on Physician Productivity, AM
J Manage Care, Nov. 19, 2013.
\d\ Helmons PJ1, Suijkerbuijk BO2, Nannan Panday PV3, Kosterink JG4. Drug-drug interaction checking assisted by
clinical decision support: a return on investment analysis. J Am Med Inform Assoc. 2015 Jul; 22(4):764-72.
doi: 10.1093/jamia/ocu010. Epub 2015 Feb 10.
\e\ Wagholikar KB1, Hankey RA2, Decker LK2, Cha SS2, Greenes RA3, Liu H2, Chaudhry R2. Evaluation of the effect
of decision support on the efficiency of primary care providers in the outpatient practice. J Prim Care
Community Health. 2015 Jan;6(1):54-60. doi: 10.1177/2150131914546325. Epub 2014 Aug 25.
As illustrated in the Table 20, the incremental effects of
improvements in IT on productivity range from one percent to eight
percent. Based on these findings, we assume the impact of the API
provision on providers' time ranges between one percent and five
percent. The lower bound estimate of one percent assumes that, at a
minimum, providers will use one new app created as a result of the data
made available under the API provision. We assume that this app will
save providers time equivalent to the introduction of clinical decision
support tools found in Wagholikar (2015). The upper bound estimate of
five percent assume that, at a maximum, providers will use multiple
apps created such that the combination will result in an increase in
productivity. Furthermore, we assume that the API provision will affect
only providers with certified EHRs and those that participated in the
CMS EHR Incentive Program (439,187). Given that an average provider
spends six hours with an EHR per day,\231\ earns $97.85 per hour, and
works 260 days per year, physicians' time saved attributed to API
technology range from $670 million to $3.4 billion per year.
---------------------------------------------------------------------------
\231\ 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.
---------------------------------------------------------------------------
(E) Benefits: Reduced Costs Associated With the Impact of
Interoperability on Health Outcomes
To identify the impact of the API proposal on interoperability and
therefore identified health outcomes, we used regression analysis.
Specifically, we estimated linear probability models that identified
the impact of 2014 Edition certified EHR on hospitals' interoperability
(whether a hospital sends, receives, finds, and integrates summary of
care records). Using data from the American Hospital Association (AHA)
\232\ from years 2014 to 2015 in the model, we controlled for hospital
size, profit status, participation in a health information
organization, and state and year fixed effects. The marginal effect of
using a 2014 Edition certified health IT equated to a five percent
increase in interoperability. This is an upper bound estimate. For the
purpose of this analysis, we assume that one to four percentage points
would be a reasonable range for API's marginal impact on
interoperability.
---------------------------------------------------------------------------
\232\ American Hospital Association Health IT Supplement Survey,
http://www.ahadata.com/aha-healthcare-database/.
---------------------------------------------------------------------------
As noted previously, there might be shared benefits across certain
provisions, and we have taken steps to ensure that the benefits
attributed to each provision are unique to the specific provision. We
assumed that the collective impact of real world testing and API
proposals on interoperability would not exceed the impact of 2014
Edition certified health IT (estimated at five percent). We distributed
the five percent benefit across our real world testing and API
proposals at (0.1-1 percent) to (1-4 percent) respectively. Moreover,
the number of providers impacted is specific to each provision. Thus,
to finalize our calculations of the reduced costs related to reductions
in duplicate lab tests, readmissions, emergency room (ER) visits, and
adverse drug events due to increased interoperability, we leveraged
evidence from the literature that found an association between
providers' rates of interoperability and applied the estimated marginal
effect of each proposal on interoperability. Given data limitations, we
believe this approach allows us to estimate the benefits of our final
rule without double counting the impact each provision might have on
interoperability.
[[Page 25924]]
Table 21--Benefit of API on Health Care Outcomes
[2017 dollars]
--------------------------------------------------------------------------------------------------------------------------------------------------------
Overall interop Impact of API Percentage of Total benefit \a\
Benefit type Number impact (marginal ------------------ Total cost total cost ---------------------------------
affected effect) Min Max impacted Min Max
--------------------------------------------------------------------------------------------------------------------------------------------------------
Duplicate testing........... 439,187 0.09 \b\............ 0.01 0.04 $200 billion 100 $185 million $742 million
providers. \c\. per year. per year.
Avoidable hospitalizations 4,519 hospitals 0.09 \b\............ 0.01 0.04 $41 billion \d\ 100 $38 million per $152 million
and readmissions. year. per year.
ER visits................... 131 million 0.03 \b\............ 0.01 0.04 $1,233 per ER 100 $50 million per $200 million
visits \e\. visit. year. per year.
Adverse drug events......... 20 of events 22 \f\.............. 0.01 0.04 $30 billion \g\ 20 $14 million per $54 million per
affected. year. year.
--------------------------------------------------------------------------------------------------------------------------------------------------------
\a\ Total benefit is a product of total cost, percent of total cost impacted, overall impact of interoperability, and impact of API, adjusted for
inflation (1.03).
\b\ Stephen E. Ross, Tiffany A. Radcliff, William G. Leblanc, L. Miriam Dickinson, Anne M. Libby, and Donald E. Nease Jr., Effects of health information
exchange adoption on ambulatory 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 redundant imaging? Evidence from
emergency departments, Med Care (Mar. 2014), at 227-34.
\c\ National Academy of Medicine. (2016), http://money.cnn.com/2017/05/20/news/economy/medical-tests/index.html.
\d\ Agency for Healthcare Research and Quality (AHRQ) Statistical Brief #199 (Dec. 2015), https://www.hcup-us.ahrq.gov/reports/statbriefs/sb199-Readmissions-Payer-Age.pdf; AHRQ Statistical Brief #72, Nationwide Frequency and Costs of Potentially Preventable Hospitalizations (Apr. 2009), https://www.hcup-us.ahrq.gov/reports/statbriefs/sb72.pdf.
\e\ National Center for Health Statistics (NCHS) Data Brief No. 252 (June 2016), https://www.cdc.gov/nchs/data/databriefs/db252.pdf; Nolan Caldwell,
Tanja Srebotnjak, Tiffany Wang, and Renee Hsia, ``How Much Will I Get Charged for This?'' Patient Charges for Top Ten Diagnoses in the Emergency
Department (2013), https://doi.org/10.1371/journal.pone.0055491.
\f\ M.F. Furukawa, W.D. Spector, M.R. Limcangco, and W.E. Encinosa, Meaningful use of health information technology and declines in in-hospital adverse
drug events, J. of the Am. Med. Informatics Assoc. (2017).
\g\ Janet Sultana, Paola Cutroneo, and Gianluca Trifir[ograve], Clinical and economic burden of adverse drug reactions.
Based on this analysis, the benefits of the API provision on
reduced costs on health outcomes range from $287 million to $1.1
billion.
(F) Benefits: Increase in Percent of Individuals With Access to Their
Health Information
This provision will also provide individuals with better access to
their data. APIs make it easier for patients to transmit data to
smartphone health applications. According to the Health Information
National Trends Survey,\233\ nearly 20 percent of Americans were
offered access and viewed their online medical record using smartphone
health applications in 2019. The proportion of individuals accessing
their online medical records using smartphone health applications is
expected to grow as APIs become more widespread. This will result in
cost savings to patients. Specifically, patients who use new
applications to access copies of their medical record instead of
contacting their provider will have cost savings.
---------------------------------------------------------------------------
\233\ These estimates were derived from Health Information
National Trends Survey 5, Cycle 1 (2017).
---------------------------------------------------------------------------
Under the HIPAA Privacy Rule, individuals have the right to access
their Protected Health Information (PHI) (45 CFR 164.524), and 45 CFR
164.524(c)(4) sets forth implementation specifications for fees that
covered entities may charge individuals for access to their PHI. Under
45 CFR 164.524(c)(4), a covered entity may impose a reasonable, cost-
based fee (consistent with the conditions in Sec. 164.524(c)(4)(i)
through (iv)). For purposes of this analysis, we assume covered
entities can charge a flat fee not to exceed $6.50 (inclusive of all
labor, supplies, and any applicable postage). The API Condition and
Maintenance of Certification requirements finalized in Sec. 170.404 do
not allow for a ``Certified API Developer'' (as defined in Sec.
170.404(c)) to charge patients for connecting to an API to access,
exchange, or use their EHI. A Certified API Developer is permitted to
charge fees to an API Information Source related to the use of
certified API technology. The fees must be limited to the recovery of
incremental costs reasonably incurred by the Certified API Developer
when it hosts certified API technology on behalf of the API Information
Source (Sec. 170.404). Thus, patients would ultimately see cost
savings by accessing their online medical record using a smartphone
health application instead of contacting their provider for an
electronic copy.
To identify the potential cost savings this rule will have for
patients, we used data from the Health Information National Trends
Survey to estimate the proportion of individuals who reported having to
bring a test result to a doctor's appointment at least once in the past
year. In 2018, approximately 81 percent of Americans reported that they
saw a doctor in the past year and about 19 percent of these individuals
reporting having to bring a test result to an appointment. Therefore,
using Census data from December 31, 2017, we conducted the following
calculation (total U.S. population 325.9M) * (81 percent of individuals
saw a doctor in the past year) * (19 percent of individuals who had to
bring a test result to an appointment). This resulted in an estimate of
50.2 million Americans who bring test results to a doctor's appointment
each year. We recognize that not all of these individuals will have the
capability to access an online medical record using a smartphone health
application. Therefore, we discounted this estimate based on the
proportion of individuals who currently access their online medical
records using a smartphone health applications (14 percent), as our
lower bound. Our upper bound is the proportion of individuals who
reported being offered access to an online medical record by a health
care provider or insurer (58 percent). These calculations are in Table
22.
[[Page 25925]]
Table 22--Benefit of API on Patients Having Access To their Health Information
[2017 Dollars]
--------------------------------------------------------------------------------------------------------------------------------------------------------
Proportion of individuals impacted Total benefit
Benefit type Number affected ---------------------------------------- Total cost savings ---------------------------------------
Min Max Min Max
--------------------------------------------------------------------------------------------------------------------------------------------------------
Cost savings to patients for 50,156,010 \a\ 14% \b\........... 58% \b\........... $6.50 \c\ per $45.8 million per $189.8 million per
requesting an electronic copy patients. patient. year. year.
of their medical record.
--------------------------------------------------------------------------------------------------------------------------------------------------------
\a\ This represents the number of individuals who had to bring a medical test result to an appointment with a health care provider in the past year.
Calculation: US Population on December 31, 2017 (325.9M)*81 percent who saw a doctor in the past year*19 percent who had to bring a test result to an
appointment. Sources: (1) https://www.census.gov/popclock/; (2) https://dashboard.healthit.gov/quickstats/pages/consumers-gaps-in-information-exchange.php.
\b\ Lower bound represents the proportion of individuals nationwide who were offered access to their online medical record by a health care provider or
insurer. Upper bound represents the proportion of individuals nationwide who were offered access and subsequently viewed their online medical record
using a smartphone health app. Source: Johnson C. & Patel V. The Current State of Patients' Access and Using their Electronic Health Information.
Presented at the ONC Annual Meeting on January 27, 2020.
\c\ We assume that providers charge individuals a flat fee for all requests for electronic copies of PHI maintained electronically, provided the fee
does not exceed $6.50, inclusive of all labor, supplies, and any applicable postage.
Based on the above calculations, we estimated the annual benefit to
health care providers for the use of these API capabilities would, on
average, range from $6.7 million to $140 million. We estimated the
annual benefit due to improved health outcomes would, on average, range
from $287 million to $1.1 billion. We estimated the annual benefit to
patients having access to their online medical record would, on
average, range from $45.8 million and $189.8 million. Therefore, we
estimated the total annual benefit of APIs, on average, to range from
$0.34 billion to $1.43 billion.
Comments. We did not receive comments specific to our approach to
estimating the benefits of API support.
Response. We have maintained our overall approach for the costs and
benefits associated with the API provisions of this rule. As discussed
in section IV.B.7 of this final rule preamble, we have added a new
requirement in the finalized Sec. 170.315(g)(10) that gives patients
the capability to revoke access to an authorized application. Cost
estimates for this new requirement were added to cost tables 16 A and
16 B as task six. The task of meeting this additional finalized
requirement increased the overall cost estimate for the API provisions
by $9.8 million to $43 million. Due to this increase in cost, we re-
evaluated our benefits estimates associated with increasing patients'
access to their health information. In the Proposed Rule, we
qualitatively discussed benefits of patients having increased access to
their health information. However, upon further consideration, and
additional data sources, we were able to estimate cost savings to
patients for requesting electronic copies of their medical record.
These estimates are reflected in Table 22. We provided additional
rationale to substantiate our approach and we updated estimates to 2017
dollars.
(iv) New Privacy and Security Certification Criteria
As specified in section IV.C.3 of this final rule, we have adopted
two new privacy and security transparency attestation certification
criteria in Sec. 170.315(d)(12) and (13) that are part of the 2015
Edition privacy and security certification framework. The criteria will
serve to identify whether certified health IT supports encrypting
authentication credentials and/or multi-factor authentication (MFA).
They do not require new development or implementation to take place in
order to be met. However, certification to these criteria will provide
increased transparency and, perhaps, motivate the small percentage of
health IT developers that do neither to encrypt authentication
credentials and/or support multi-factor authentication, which will help
prevent exposure to unauthorized persons/entities.
(A) Costs
Comments. We did not receive any comment specific to any method we
could use to quantify the costs of the new privacy and security
certification criteria, encrypt authentication credentials (Sec.
170.315(d)(12)) and multi-factor authentication (MFA) (Sec. 170.315
(d)(13)), and requiring health IT developers to assess their Health IT
Modules' capabilities and attest ``yes'' or ``no'' to the certification
criteria.
Response. We have maintained our estimates of the costs of this
provision in the final rule.
(B) Benefits
As stated previously, we have not required health IT developers to
encrypt authentication credentials or support multi-factor
authentication (MFA). Instead, we have required that they attest to
whether or not they support the certification criteria. By requiring an
attestation, we are promoting transparency, which might motivate some
health IT developers that do not currently encrypt authentication
credentials or support MFA to do so. If health IT developers are
motivated by these criteria and ultimately do encrypt authentication
credentials and/or support MFA, we acknowledge that there would be
costs to do so; however, we assume that the benefits will substantially
exceed the costs. Such encryption and adopting MFA would reduce the
likelihood that authentication credentials would be compromised and
would eliminate an unnecessary use of IT resources. Encrypting
authentication credentials and adopting MFA could directly reduce
providers' operating and support costs, which will reduce their
administrative and financial burden. Encrypting authentication
credentials will also help decrease costs and burdens by reducing the
number of password resets due to possible phishing or other
vulnerabilities.
According to Verizon's 2017 Data Breach Investigations Report, 81
percent of hacking-related breaches leveraged either stolen and/or weak
passwords.\234\ The Verizon report encourages customers to vary their
passwords and use two-factor authentication. Also, National Institute
of Standards and Technology (NIST) Special Publication 800-63B: Digital
Identity Guidelines, Authentication and Lifecycle
[[Page 25926]]
Management,\235\ recommends the use of, and provides the requirements
for multi-factor authenticators.
---------------------------------------------------------------------------
\234\ https://enterprise.verizon.com/resources/reports/2017_dbir.pdf.
\235\ https://pages.nist.gov/800-63-3/sp800-63b.html.
---------------------------------------------------------------------------
Based on these reports and other anecdotal evidence, we believe
encrypting authentication credentials and supporting MFA are
established best practices among industry developers, including health
IT developers. As described above, in this final rule, we required
health IT developers to attest to whether they encrypt authentication
credentials. We do not have access to published literature that details
how health IT developers are already encrypting authentication
credentials and supporting MFA industry-wide, but we believe most
health IT developers, or around 80 percent, are taking such actions. We
assume that building this functionality is in the future project plans
for the remaining 20 percent because, as noted previously, adopting
these capabilities is an industry best practice. Health IT developers
that have not yet adopted these capabilities are likely already making
financial investments to get up to speed with industry standards. We
believe the adoption of these criteria will motivate these health IT
developers to speed their implementation process, but we have not
attributed a monetary estimate to this potential benefit because our
rule is not a direct cause of health IT developers adopting these
capabilities. We anticipate that when we release this final rule, many
more, or perhaps all, health IT developers will likely already be
encrypting authentication credentials and supporting MFA. We welcomed
comments on this expectation and any means or methods we could use to
quantify these benefits.
Comments. We did not receive any comment specific to any means or
methods we could use to quantify the costs and benefits of having the
new privacy and security transparency attestation certification
criteria, encrypt authentication credentials (Sec. 170.315(d)(12)) and
multi-factor authentication (MFA) (Sec. 170.315(d)(13)), and requiring
health IT developers to assess their Health IT Modules' capabilities
and attest ``yes'' or ``no'' to the certification criteria.
Response. We maintain our estimates of the costs and benefits of
this provision in the final rule. We also continue to believe that the
adoption of these criteria will motivate these health IT developers to
speed their implementation process.
(v) Security Tags--Summary of Care--Send and Security Tags--Summary of
Care--Receive
In this final rule, we updated the 2015 Edition Data Segmentation
for Privacy (DS4P) certification criteria in Sec. 170.315(b)(7) and
(8) to support a more granular approach to privacy tagging data for
health information exchange. We also renamed the criteria to reduce
confusion and better align with the criteria, ``Security tags--Summary
of Care--send'' and ``Security tags--Summary of Care--receive.'' The
criteria will remain based on the C-CDA and the HL7 DS4P standard.
These criteria will include capabilities for applying the DS4P standard
at the document, section, and entry level. In the Proposed Rule, we
proposed to adopt a third 2015 Edition DS4P certification criterion,
``consent management for APIs'' (Sec. 170.315(g)(11)), that requires
health IT to be capable of responding to requests for data through an
API in accordance with the Consent Implementation Guide, which we did
not finalize.
(A) Costs
We anticipate these updated criteria will result in up-front costs
to health IT developers as health IT would be required to support all
three levels--document, section, and entry--as specified in the current
DS4P standard. However, we note that these criteria are not being
required in any program at this time. As of the beginning of the fourth
quarter of the 2019 calendar year, only about 30 products (products
with multiple certified versions were counted once) were certified to
the current 2015 Edition DS4P certification criteria. We estimated that
10 to 15 products will implement the new DS4P criteria. Developers may
need to perform fairly extensive health IT upgrades to support the more
complex and granular data tagging requirements under these criteria. We
anticipate developers will need approximately 1,500 to 2,500 hours to
upgrade databases and/or other backend infrastructure to appropriately
apply security tags to data and/or develop access control capabilities.
Moreover, developers will likely incur costs to upgrade health IT to
generate a security-labeled C-CDA conforming to the DS4P standard. We
estimated developers will need 400 to 600 hours per criterion to make
these upgrades on systems that had previously certified to the
document-level DS4P criteria, or 720 to 1220 hours per criterion for
systems that are implementing these criteria for the first time. We
believe this work would be performed by a ``Software Developer.''
According to the May 2017 BLS occupational employment statistics, the
mean hourly wage for software developer is $53.74. As noted previously,
we have assumed that overhead costs (including benefits) are equal to
100 percent of pre-tax wages, so the hourly wage including overhead
costs is $107. Therefore, we estimated the total cost to developers
could range from $2,910,400 to $6,933,600. We note that this would be a
one-time cost. The midpoint of ranges stated is used as the primary
estimate of costs.
Additionally, we proposed that the health IT support the capability
to respond to requests for patient consent information through an API
compatible with FHIR Release 3. However, we did not finalize that
proposal. Therefore, we did not include an estimate in this final rule.
We have estimated costs using the following assumptions:
For the two Security tags--Summary of Care criteria, we
anticipate developers will need approximately 1,500 to 2,500 hours to
upgrade databases and/or other backend infrastructure to appropriately
apply security tags to data and/or develop access control capabilities.
We expect that this would be a one-time cost.
According to the May 2017 BLS occupational employment
statistics, the mean hourly wage for a ``Software Developer'' is
$53.74.
Our cost estimates are explained in the Table 23.
[[Page 25927]]
Table 23--Costs Related to Security Tags--Summary of Care Criteria
[2017 Dollars]
----------------------------------------------------------------------------------------------------------------
Tasks Lower bound Upper bound Remarks
----------------------------------------------------------------------------------------------------------------
Task 1: Enhancements to health IT 1,500 hours.............. 2,500 hours............. This is a one-time cost
to upgrade databases and/or for health IT systems
other backend infrastructure to to support data
appropriately apply security segmentation for
tags to data and/or develop discrete data.
access control capabilities.
Total Labor Hours............ 1,500 hours.............. 2,500 hours.............
-----------------------------------------------------
Hourly Rate.................. $107 per hour
---------------------------------------------------------------------------------------
Cost per Product............. $160,500................. $267,500................
Total Cost (23 products)..... $3,691,500............... $6,152,500..............
----------------------------------------------------------------------------------------------------------------
We believe the voluntary nature of these criteria would
significantly mitigate health IT developer costs. We also expect
developers to see a return on their investment in developing and
preparing their health IT for these certification criteria given the
benefits to interoperable exchange.
We anticipate potential costs for ONC related to the updated DS4P
criteria (Security tags--Summary of Care--send and Security tags--
Summary of Care--receive) associated with: (1) Developing and
maintaining information regarding these updated criteria on the ONC
website; (2) creating documents related to these updated criteria and
making those documents 508 compliant; (3) updating, revising, and
supporting Certification Companion Guides, test procedures, and test
tools; and (4) responding to inquiries concerning these criteria. We
estimate an ONC analyst at the GS-13, Step 1 level staff would devote,
on average, 200 hours to the above tasks annually. The hourly wage with
benefits for a GS-13, Step 1 employee located in Washington, DC is
approximately $91. Therefore, we estimate the annual costs to be
$18,200.
(B) Benefits
We believe leveraging the DS4P standard's ability to allow for both
document level and more granular tagging would offer functionality that
is more valuable to providers and patients, especially given the
complexities of the privacy landscape for multiple care and specialty
settings. The updated DS4P criteria (Security tags--Summary of Care--
send and Security tags--Summary of Care--receive) would benefit
providers, patients, and ONC because it would support more complete
records, contribute to patient safety, and enhance care coordination.
We believe this will also reduce burden for providers by enabling an
automated option, rather relying on case-by-case manual redaction and
subsequent workarounds to transmit redacted documents. Implementing
security tags enables providers to more effectively share patient
records with sensitive information, thereby protecting patient privacy
while still delivering actionable clinical content. We emphasize that
health care providers already have processes and workflows to address
their existing compliance obligations, which could be made more
efficient and cost effective through the use of health IT. We expect
these benefits for providers, patients, and ONC to be significant;
however, we are unable to quantify these benefits at this time because
we do not have adequate information to support quantitative estimates.
We welcomed comments regarding potential approaches for quantifying
these benefits.
Comments. Several commenters indicated there would be cost burden
associated with our proposal of adopting two new DS4P certification
criteria and a consent management for API criterion. Commenters stated
that ONC needs to quantify and include the cost of this burden in our
impact analysis section. Another commenter conducted their own analysis
and indicated a cost of $5-6 billion with a multi-year implementation
timeframe. Commenters stated there could be significant upfront costs
and ongoing costs for maintenance of the systems necessary to comply
with these criteria and one commenter further explained that segmenting
data at the document, section, and entry level as opposed to the
document level only, would significantly increase costs and could
potentially impact system performance. One commenter was specifically
concerned that the proposal would broadly impact HIEs both in terms of
administration and implementation but did not state specifics.
Response. We thank commenters for their input. We did not finalize
the consent management for API criterion. For the DS4P-related criteria
(Security tags--Summary of Care--send and Security tags--Summary of
Care--receive), the developer costs were estimated for supporting DS4P
IG enhancements to include tagging the data at the section and entry
level when exchanged using the C-CDA. The lower bound estimates include
developers who are already supporting the DS4P IG for tagging data at
``document'' level and estimates additional effort to support tagging
at ``section'' and ``entry'' level. The criteria do not require the
capability to segment the data, only to tag the data.
The certification criteria does not make any additional
expectations around compliance beyond what the providers are currently
expected to do, nor does it add any additional requirements for
developers around how they handle the data received with the tags.
Therefore, we disagree with the commenters about underestimating the
cost. Rather, the commenters may be suggesting implementation costs
which are beyond the costs associated with the certification criteria
itself. These costs are unquantifiable and are noted in Table 31.
(3) Conditions and Maintenance of Certification Requirements
(i) Information Blocking
For a discussion of the costs and benefits of the exceptions to
information blocking, please see section (5) of this RIA.
(ii) Assurances
In this final rule, we included a provision that requires health IT
developers to make certain assurances as Conditions and Maintenance of
Certification requirements: (1) Assurances regarding the ``EHI export''
certification criterion in Sec. 170.315(b)(10) and (2) assurances
regarding retaining records and information in 170.402(b)(1)(i)-(ii).
[[Page 25928]]
(A) Electronic Health Information Export
Alongside the criterion revisions in Sec. 170.315(b)(10), we have
finalized in Sec. 170.402(a)(4), that a health IT developer of a
certified health IT Modules that is part of a health IT product which
electronically stores EHI must certify to the certification criterion
in Sec. 170.315(b)(10). We have finalized in Sec. 170.402(b)(2) that
within 36 months from the final rule's publication date, a health IT
developer that must comply with the requirements of paragraph Sec.
170.402(a)(4) of this section must provide all of its customers of
certified health IT with the health IT certified to the certification
criterion in Sec. 170.315(b)(10). We also finalized that on and after
36 months from the publication of this final rule, health IT developers
that must comply with the requirements of Sec. 170.402(a)(4) must
provide all of their customers of certified health IT with health IT
certified to Sec. 170.315(b)(10). In addition, a health IT developer
must attest accurately in accordance with Sec. 170.402(a)(4) and
(b)(2) if the Health IT Module presented for certification is part of a
heath IT product which can electronically store EHI. If the product
stores such information, the health IT developer must ensure all EHI is
available for export in accordance with Sec. 170.315(b)(10).
For a detailed discussion of the costs and benefits of the
assurances regarding the criterion in Sec. 170.315(b)(10), please see
section (2)(ii) (EHI export) of this RIA above.
(B) Records and Information Retention
As a Maintenance of Certification requirement in Sec.
170.402(b)(1), a health IT developer must, for a period of 10 years
beginning from the date of certification, retain all records and
information necessary that demonstrate initial and ongoing compliance
with the requirements of the ONC Health IT Certification Program. In an
effort to reduce administrative burden, we also finalized that in
situations where applicable certification criteria are removed from the
Code of Federal Regulations before the 10 years have expired, records
must only be kept for three years from the date of removal for those
certification criteria and related Program provisions unless that
timeframe would exceed the overall 10-year retention period. This
``three-year from the date of removal'' records retention period also
aligns with the records retention requirements for ONC-ACBs and ONC-
ATLs under the Program.
As stated in the Proposed Rule, currently, there are no existing
regulatory requirements regarding record and information retention by
health IT developers. We expect there are costs to developers to retain
the records and information described above but they may be mitigated
due to other factors. For example, we expect that health IT developers
are already keeping most of their records and information in an
electronic format. We also expect that some developers may already be
retaining records and information for extended periods of time due to
existing requirements of other programs, including for those programs
their customers participate in. For instance, Medicaid managed care
companies are required to keep records for 10 years from the effective
date of a contract.
We estimated that each health IT developer will, on average, spend
two hours each week to comply with our proposed record retention
requirement. We expect that a health IT developer's office clerk could
complete the record retention responsibilities. According to the May
2017 BLS occupational employment statistics, the mean hourly wage for
an office clerk is $16.30.\236\ As noted previously, we have assumed
that overhead costs (including benefits) are equal to 100 percent of
pre-tax wages, so the hourly wage including overhead costs is $32.
---------------------------------------------------------------------------
\236\ See https://www.bls.gov/oes/2017/may/oes439061.htm.
---------------------------------------------------------------------------
Therefore, we estimated the annual cost per developer on average,
would be $3,328 and the total annual cost for all health IT developers
(458 health IT developers have products certified to the 2015 Edition
that are capable of recording patient health data) on average, would be
$1.5 million. We note that this is a perpetual cost.
(iii) Prohibition or Restriction of Communications
(A) Costs
Health IT developers need to notify their customers about the
unenforceability of communications and contract provisions that violate
the Communications Condition of Certification requirements in Sec.
170.403(a). Generally, health IT developers already have mechanisms in
place, whether via online postings, email, mail, or phone, for alerting
customers to changes in their policies and procedures. Such alerts
should be standard practice. However, we have estimated the potential
costs for health IT developers to draft the notice and mail the notice
as appropriate. We estimated that a health IT developer's office clerk
will commit (overall) approximately 40 hours to drafting and mailing
notices when necessary. According to the May 2017 BLS occupational
employment statistics, the mean hourly wage for an office clerk is
$16.30.\237\ As noted previously, we have assumed that overhead costs
(including benefits) are equal to 100 percent of pre-tax wages, so the
hourly wage including overhead costs is $32. Therefore, we estimated
the annual cost per developer to be $1,280 and the total cost for all
health IT developers (792 health IT developers certified to the 2014
Edition) to be $1 million. We note that a developer must notify all
customers annually until any contracts contravening the Condition are
amended.
---------------------------------------------------------------------------
\237\ See https://www.bls.gov/oes/2017/may/oes439061.htm.
---------------------------------------------------------------------------
We also note that mailing is one option for delivery, along with
other means such as email. We do not have information concerning how
health IT developers will deliver their notices. We have estimated a
total cost for all developers to mail the initial notices (including
postage) to be $80,000. As noted above, this notice may have to be
provided annually, depending on when contracts contravening this
provision are amended.
In order to meet the Cures Act requirement that health IT
developers do not prohibit or restrict communication regarding health
IT, some health IT developers will eventually need to amend their
contracts to reflect such a change. Many standard form health IT
contracts limit the ability of users to voluntarily discuss problems or
report usability and safety concerns that they experience when using
their health IT. This type of discussion or reporting is typically
prohibited through broad confidentiality, nondisclosure, and
intellectual property provisions in the developer's standard form
health IT contract. Some standard form health IT contracts may also
include non-disparagement clauses that prohibit customers from making
statements that could reflect negatively on the health IT developer.
These practices are often referred to colloquially in the industry as
``gag clauses.'' We expect amendments to these clauses to be
accomplished in the normal course of business, such as when
renegotiating contracts or updating them for HIPAA Rules or other
compliance requirements outside of the ONC Health IT Certification
Program. As such, we do not estimate any direct or indirect costs
[[Page 25929]]
for health IT developers to amend their contracts to comply with this
Condition of Certification requirement.
(B) Benefits
We expect health care providers to benefit from this provision.
There is growing recognition that these practices of prohibiting or
restricting communication do not promote health IT safety or good
security hygiene and that health IT contracts should support and
facilitate the transparent exchange of information relating to patient
care. We were unable to estimate these benefits because we do not have
adequate information to determine the prevalence of gag clauses and
other restrictive practices, nor do we have a means to quantify the
value to providers of being able to freely communicate and share
information. We welcomed comments on approaches to quantify these
benefits.
Comments. We did not receive comments specific to our approach of
quantifying the benefits of our provision to inform customers regarding
the prohibition or restriction of communications. We did receive
several comments stating that our notification and contract revision
estimates underestimate the volume of agreements for large developers
and the cost of compliance. We also received several comments that the
burden for revising contracts could be significant and costly,
particularly in the timeframe originally proposed, with one comment
adding that the cost for revising contracts should be included in the
impact analysis.
Response. We maintain that we were unable to estimate the benefits
of the provision due to inadequate information however, we believe that
prohibiting or restricting communication does not promote health IT
safety or good security hygiene and that health IT contracts should
support and facilitate the transparent exchange of information relating
to patient care. We maintain our notification estimates as we believe
that large developers would have efficient means of sending
notifications i.e. by email. We reiterate that we expect revision of
contracts to be accomplished in the normal course of business and do
not estimate any direct or indirect costs for health IT developers to
amend their contracts to comply.
(iv) Application Programming Interfaces
For a discussion of the costs and benefits of the new API criterion
in Sec. 170.315(g)(10), please see section (2)(iii) of this RIA.
(A) Transparency Requirements for Application Programming Interfaces
In this final rule, as part of the Conditions and Maintenance of
Certification requirements in Sec. 170.404, we have required that API
Technology Suppliers make specific business and technical documentation
necessary to interact with the APIs in production freely and publicly
accessible. We expect that the API Technology Suppliers will perform
the following tasks related to transparency of business and technical
documentation and would devote the following number of hours annually
to such tasks: (1) Health Level 7's (HL7[supreg]) Fast Healthcare
Interoperability Resources (FHIR[supreg]) API documentation (the
developer would most likely point to the HL7 FHIR standard for API
documentation) (estimated eight hours); (2) patient application
registration documentation, which will include a development effort to
create a website that manages the application registration activity
(estimated 40 hours); (3) publication of the FHIR Endpoint--Base URLs
for all centrally managed providers (estimated 40 hours); (4)
publication of FHIR Endpoints for provider-managed APIs (estimated 160
hours); and (5) API cost information documentation, which will
typically be documented as a tiered rate based on usage or some form of
monthly rate (estimated 40 hours).
We believe each of the above tasks would be performed by a
``Software Developer.'' According to the May 2017 BLS occupational
employment statistics, the mean hourly wage for software developer is
$53.74.\238\ As noted previously, we have assumed that overhead costs
(including benefits) are equal to 100 percent of pre-tax wages, so the
hourly wage including overhead costs is $107. Therefore, we estimated
the cost per developer to be $30,816. As noted in section (2)(iii) of
this RIA, we estimated that 459 products from 394 developers will
contain the API criterion. Therefore, we estimated the total developer
cost would be $12.1 million. We note that this is a one-time cost and
would not be perpetual. We did not receive comments on this discussion
and have therefore finalized our figures.
---------------------------------------------------------------------------
\238\ See https://www.bls.gov/oes/2017/may/oes439061.htm.
---------------------------------------------------------------------------
(v) Real World Testing
The objective of real world testing in Sec. 170.405 is to verify
the extent to which deployed health IT products in operational
production settings are demonstrating compliance to certification
criteria and functioning with the intended use cases for continued
maintenance of certification requirements. Real world testing should
ensure certified health IT products have the ability to share
electronic health information between systems. Real world testing
should assess that the certified health IT is meeting the intended use
case(s) of the certification criteria to which it is certified within
the workflow, health IT architecture, and care/practice setting in
which the health IT is implemented. We note that we expect real world
testing would take about three months of the year to perform.
(A) Costs
This section describes the potential costs of the real world
testing requirements in this final rule. The costs estimates are based
on the following assumptions:
Health IT developers will use the same labor costs. Table
24 shows the estimated labor costs for a health IT developer to perform
real world testing. We recognize that health IT developer costs will
vary; however, our estimates in this section assume all developers will
incur the costs noted in Table 24.
Proxy needed to project the number of 2015 Edition
products impacted by real world testing. We estimated that 523 products
from 429 developers will be impacted by real world testing. We used a
proxy to determine developers that would be subject to real world
testing. There were 681 products and 551 developers with at least one
of its 2014 Edition certified products that could perform transitions
of care and/or send any type of public health data. We then multiplied
these numbers by our estimates for certified health IT market
consolidation by -22.1 percent and -23.2 percent to project the number
of 2015 developers and products, respectively. We believe this estimate
serves as a reasonable proxy for products impacted by real world
testing, as these products primarily focus on interoperability.
The tables below describe the various costs to health IT developers
to perform real world testing by task.
[[Page 25930]]
Table 24--Estimated Cost to Health IT Developers To Perform Real World Testing
[2017 Dollars]
----------------------------------------------------------------------------------------------------------------
Tasks and labor category Hours Rate Total
----------------------------------------------------------------------------------------------------------------
Task 1: Design Real world Testing Approach and Submit Plan (per .............. .............. $34,560
developer).....................................................
15-1133 Software Developers, Systems Software............... 80 107 8,560
15-1143 Computer Network Architects......................... 120 104 12,480
15-1121 Computer Systems Analysts........................... 80 89 7,120
15-1199 Computer Occupations, All Other..................... 40 88 3,520
27-3042 Technical Writers................................... 40 72 2,880
Task 2: Prepare Staff and Environments (per developer).......... .............. .............. 14,920
15-1121 Computer Systems Analysts........................... 40 89 3,560
15-1142 Network and Computer Systems Administrators......... 40 83 3,320
15-1152 Computer Network Support Specialists................ 40 65 2,600
15-1199 Computer Occupations, All Other..................... 40 88 3,520
15-1122 Information Security Analysts....................... 20 96 1,920
Task 3: Perform Testing (per product)........................... .............. .............. 32,240
15-1121 Computer Systems Analysts........................... 80 89 7,120
15-1133 Software Developers, Systems Software............... 40 107 4,280
15-1199 Computer Occupations, All Other..................... 160 88 14,080
15-1142 Network and Computer Systems Administrators......... 40 83 3,320
15-1141 Database Administrators............................. 40 86 3,440
Task 4: Collect Results and Prepare-Submit Report (per .............. .............. 20,560
developer).....................................................
15-1199 Computer Occupations, All Other..................... 120 88 10,560
15-1121 Computer Systems Analysts........................... 80 89 7,120
27-3042 Technical Writers................................... 40 72 2,880
-----------------------------------------------
Total Labor Hours........................................... 1,140
Other Direct Costs--printing, publishing (per product).. .............. .............. 150.00
----------------------------------------------------------------------------------------------------------------
Table 25--Real World Testing Total Annual Cost
[2017 Dollars]
------------------------------------------------------------------------
Task Calculation Total cost
------------------------------------------------------------------------
Task 1............................ $34,560 * 429 $14,826,240
developers.
Task 2............................ $14,920 * 429 6,400,680
developers.
Task 3............................ $32,240 * 523 16,861,520
products.
Task 4............................ $20,560 * 429 8,820,240
developers.
Other Direct Costs................ $150 * 523 products. 78,450
-------------------------------------
Total Cost.................... .................... 46,987,130
------------------------------------------------------------------------
Based on the stated assumptions and costs outlined in the above
tables, we estimated the total annual cost for real world testing
would, on average, be $47 million with an average cost per developer of
$109,557.
(B) Benefits
There are several benefits that can be attributed to real world
testing. Real world testing may impact the effective integration of
varied health IT systems, including integration of certified health IT
with non-certified and ancillary technologies such as picture archiving
and communications systems (PACS) or specialty-specific interfaces.
This could result in greater interoperability among health IT systems.
For providers that are currently dissatisfied with how their health IT
is performing, real world testing might also influence the effective
implementation of workflows in a clinical setting. In this analysis, we
calculated the benefits in the following categories: For providers that
have complained about their EHR system, time saved documenting in their
EHR due to improved usability; for providers that are dissatisfied with
their EHR, increased provider satisfaction resulting in fewer providers
incurring the costs of switching products; and benefits related to
reductions in duplicate lab tests, readmissions, ER visits, and adverse
drug events due to increased interoperability. We focused on these
outcomes for two reasons: (i) Evidence in literature indicates that
health information exchange impacts the chosen measures; and (ii) cost
of care associated with these measures is high and the impact of health
information exchange is likely to result in significant benefits in the
form of reduced costs.
The benefit calculations were based on the following assumptions:
Benefits noted in academic literature are assumed accurate
and results were not externally validated.
Hospitals and eligible professionals that participate in
the CMS Promoting Interoperability Programs will be impacted. Estimates
were based on the assumption that 439,187 health care providers and/or
4,519 hospitals will be affected by this regulatory action.
Estimates of the impact of real world testing on rates of
interoperability (0.1 to 1 percent) are based on ONC analysis. To
identify the impact of real world testing on interoperability, we used
regression analysis. Specifically, we estimated linear probability
models that identified impact of 2014 Edition certified EHR on
hospitals' interoperability (whether a hospital sends, receives, finds,
and integrates summary of care records). Using data from the AHA from
years 2014 and 2015 in the model, we controlled for hospital size,
profit status, participation in a health information organization, and
state and year fixed effects. The marginal effect of using a 2014
Edition was a five percentage point increase in interoperability. This
is an upper bound estimate. For the purpose of this
[[Page 25931]]
analysis, we assume 0.1 percent to 1 percent would be a reasonable
range for real world testing to impact interoperability.
Impact of real world testing is also based on the
estimated number of providers that switch health IT developers (rate =
five percent) and are dissatisfied with their current EHR (44 percent).
To calculate the number of providers that are likely to switch their
EHR due to dissatisfaction with their system, we estimate the rate of
switching using CMS Medicare EHR Incentive Program data from years 2013
to 2016. This results in 4,774 clinical practices and 226 hospitals
that are projected to switch products in a year. We then leverage
results from Stanford Medicine's research conducted by The Harris Poll
which reports that nearly 44 percent of providers are not satisfied
with their EHR.\239\ Based on this research, we assume that
approximately 2,195 providers are less likely to switch their EHR with
real world testing.
---------------------------------------------------------------------------
\239\ How Doctors Feel About Electronic Health Records National
Physician Poll by The Harris Poll http://med.stanford.edu/content/dam/sm/ehr/documents/EHR-Poll-Presentation.pdf.
---------------------------------------------------------------------------
Estimates of the rate of eligible professionals (10
percent) and hospitals (five percent) that will be impacted by real
world testing are based on ONC complaint data. We recognize that the
benefits of real world testing are limited to those providers that have
systems that might be underperforming. Therefore, we estimated that the
providers impacted by this rule are limited to the proportion of
providers that have issued complaints about their system to ONC.
As noted previously in this analysis, we acknowledge that there
might be shared benefits across certain provisions and have taken steps
to ensure that the benefits attributed to each provision are unique to
the provision referenced. Specifically, we used regression analysis to
calculate the impact of our real world testing and API provisions on
interoperability. We assumed that the real world testing and API
provisions would collectively have the same impact on interoperability
as use of 2014 Edition certified health IT. Therefore, we estimated
linear probability models that identified the impact of 2014 Edition
certified health IT on hospitals' interoperability.\240\ We controlled
for additional factors such as participation in a health information
exchange organization, hospital characteristics, and urban/rural
status. We found the marginal effect of using 2014 Edition certified
health IT was a five percentage point increase in interoperability.
---------------------------------------------------------------------------
\240\ American Hospital Association Health IT Supplement Survey,
http://www.ahadata.com/aha-healthcare-database.
---------------------------------------------------------------------------
We assumed that this marginal effect is true for our provisions and
distributed the five percent benefit across our real world testing and
API provisions at (0.1 to 1 percent) to (1 to 4 percent) respectively.
Moreover, the number of providers impacted is provision specific. Given
data limitations, we believe this approach allows us to estimate the
benefits of our provisions without double counting the impact each
provision might have on interoperability.
Table 26 shows the benefits of real world testing for providers. We
quantified the monetary benefits of real world testing based on a
reduction in the amount of time a provider spends on their EHR by
improving its usability or the cost-savings associated with switching
from an underperforming EHR system. Note, these benefits are limited to
providers who have expressed dissatisfaction with their EHR and only
represent a fraction of all health care providers. Table 27 quantifies
the benefits associated with improved interoperability for these
providers. This is primarily because provider behavior is more directly
affected by improvements in interoperability.
Table 26--Benefit of Real World Testing for Providers
[2017 Dollars]
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Hours saved (percent) A B Number of Total benefit C
Benefit type Number affected Hourly wage -------------------------------- Hours per day working days -------------------------------------------------
Min Max with EHR in a year Min Max
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Reduction in provider time spent in 43,919 providers or 10% $97.85 1 5 6 E 260 $65 million per year... $335 million per year.
health IT by improving usability and D (based on complaint
interoperability. data).
Number of providers switching health 2,195; Cost of .............. .............. .............. .............. .............. $34M per year.......... $158M per year.
IT F. Switching.
Min = $15,000..........
Max = $70,000..........
-------------------------------------------------
Total Benefit.................... ....................... .............. .............. .............. .............. .............. $99M per year.......... $493M per year.
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
\A\ Julia Adler-Milstein and Robert S. Huckman, The Impact of Electronic Health Record Use on Physician Productivity, Am J Manag Care (Nov. 19, 2013).
\B\ Amusan, Tongen, Speedie, and Mellin, A time-motion study to evaluate the impact of EMR and CPOE implementation on physician efficiency, J. Healthcare Inf. Manag. (Fall 2008), at 31-7.
\C\ Total benefits for the provider and administrative time spent in health IT by improving usability and interoperability. Total benefits from switching EHR developer is a product of the
number providers switching and cost of EHR.
\D\ The estimate is based on the number of providers that currently possess products with complaints. This is identified by flagging health IT developers and products about whom/which
complaints are logged on ONC's database. These health IT developers are then matched to physicians using the Meaningful Use database.
\E\ Christine Sinsky et al., Allocation of Physician Time in Ambulatory Practice: A Time and Motion Study in 4 Specialties, Ann Intern Med. (Dec. 6, 2016), at 753-60. Physician Practice,
Calculating the Right Number of Staff for Your Medical Practice, available at http://www.physicianspractice.com/blog/calculating-right-number-staff-your-medical-practice.
\F\ This estimate was obtained from Meaningful Use data from years 2013-2016. ``Switching'' is defined as an annual change in all health IT developers by providers/hospitals.
[[Page 25932]]
Table 27--Benefit of Real World Testing for Patients and Payers
[2017 Dollars]
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Overall Impact of real world testing Total benefit A
interop impact -------------------------------- Percentage of ---------------------------------------------
Benefit type Population 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 $1.9 million per year $18.5 million per
year.
Avoidable hospitalizations and 5% of hospitals (n = B 0.09 0.001 0.01 $41 billion D........ 5 $0.2 million per year $1.9 million per
readmissions. 226). year.
ER visits.......................... 5% of visits affected B 0.03 0.001 0.01 $1,233, Per ER visit 5 $0.2 million per year $2.54 million per
(n = 131 million). E. year.
Adverse drug events................ 5% of events affected. F 0.22 0.001 0.01 $30 billion G........ 5 $0.3 million per year $3.4 million per
year.
---------------------------------------------
Total Benefit.................. ...................... .............. .............. .............. ..................... .............. $2.6 million......... $26.3 million.
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
\A\ Total benefit is a product of total cost, percent of total cost impacted, overall impact of interoperability, and impact of real world testing.
\B\ Stephen E. Ross, Tiffany A. Radcliff, William G. Leblanc, L. Miriam Dickinson, Anne M. Libby, and Donald E. Nease Jr., Effects of health information exchange adoption on ambulatory testing
rates, J. Am. Med. Inform. Assoc. (2013), at 1137-1142; Bridget A. Stewart, Susan Fernandes, Elizabeth Rodriguez-Huertas, and Michael Landzberg, A preliminary look at duplicate testing
associated with lack of electronic health record interoperability for transferred patients, J. of the Am. Med. Informatics Assoc. (2010), at 341-344; Sezgin Ayabakan, Indranil R. Bardhan,
Zhiqiang (Eric) Zheng, and Kirk Kirksey Value of health information sharing in reducing healthcare waste: An analysis of duplicate testing across hospitals, MIS Quarterly (Jan. 1, 2017);
Eric J. Lammers, Julia Adler-Milstein, and Keith E. Kocher, Does health information exchange reduce redundant imaging? Evidence from emergency departments, Med Care (Mar. 2014), at 227-34.
\C\ National Academy of Medicine. (2016), http://money.cnn.com/2017/05/20/news/economy/medical-tests/index.html.
\D\ Agency for Healthcare Research and Quality (AHRQ) Statistical Brief #199 (Dec. 2015), https://www.hcup-us.ahrq.gov/reports/statbriefs/sb199-Readmissions-Payer-Age.pdf; AHRQ Statistical
Brief #72, Nationwide Frequency and Costs of Potentially Preventable Hospitalizations (Apr. 2009), https://www.hcup-us.ahrq.gov/reports/statbriefs/sb72.pdf.
\E\ National Center for Health Statistics (NCHS) Data Brief No. 252 (June 2016), https://www.cdc.gov/nchs/data/databriefs/db252.pdf; Nolan Caldwell, Tanja Srebotnjak, Tiffany Wang, and Renee
Hsia, ``How Much Will I Get Charged for This?'' Patient Charges for Top Ten Diagnoses in the Emergency Department (2013), https://doi.org/10.1371/journal.pone.0055491.
\F\ M.F. Furukawa, W.D. Spector, M.R. Limcangco, and W.E. Encinosa, Meaningful use of health information technology and declines in in-hospital adverse drug events, J. of the Am. Med.
Informatics Assoc. (2017).
\G\ Janet Sultana, Paola Cutroneo, and Gianluca Trifir[ograve], Clinical and economic burden of adverse drug reactions (Dec. 2013).
Based on the stated assumptions and benefits outlined in Table 26,
we estimate the total annual benefit for real world testing to
providers would range, on average, from $99 million to $493 million.
Based on the stated assumptions and benefits outlined in Table 27, we
estimate the total annual benefit for patients and payers would range,
on average, from $2.6 million to $26.3 million. Therefore, we estimate
the total benefit of real world testing would range, on average, from
$101.6 million to $519.3 million.
We recognize that health IT developers may deploy their systems in
a number of ways, including cloud-based deployments, and requested
comment on whether our cost estimates of real world testing should
factor in such methods of system deployment. For example, we requested
feedback about whether health IT developers would incur reduced real
world testing costs through cloud-based deployments as opposed to other
deployment methods. We specifically solicited comment on the general
ratio of cloud-based to non-cloud-based deployments within the health
care ecosystem and specific cost variations in performing real world
testing based on the type of deployment. We also requested comment on
our assumptions about the burden to providers in time spent assisting
health IT developers since we encourage health IT developers to come up
with ways to perform real world testing that mitigate provider
disruption.
Comments. We did not receive comment specific to whether health IT
developers would incur reduced real world testing costs through cloud-
based deployments as opposed to other deployment methods. We also did
not receive comments regarding the ratio of cloud-based to non-cloud
based deployments and cost variations regarding different types of
deployments. We also did not receive comments regarding the burden to
providers in time spent assisting health IT developers.
Response. We maintain our assumptions and estimates as proposed
regarding real world testing.
(C) Real World Testing Maintenance Requirements
In this final rule, we revised the Principle of Proper Conduct in
Sec. 170.523(m) to require ONC-ACBs to collect, no less than
quarterly, all updates successfully made to standards in certified
health IT pursuant to the developers having opted to avail themselves
of the Standards Version Advancement Process flexibility under the real
world testing Condition of Certification requirement. Under Sec.
170.523(p), ONC-ACBs will be responsible for: (1) Reviewing and
confirming that applicable health IT developers submit real world
testing plans in accordance with Sec. 170.405(b)(1); (2) reviewing and
confirming that applicable health IT developers submit real world
testing results in accordance with Sec. 170.405(b)(2); and (3)
submitting real world testing plans by December 15 and results by March
15 of each calendar year to ONC for public availability. In addition,
under Sec. 170.523(t), ONC-ACBs will be required to: (1) Maintain a
record of the date of issuance and the content of developers' notices;
and (2) timely post content of each notice on the CHPL.
Using the information from the ``Real World Testing Costs'' section
of this RIA, we estimated that 429 developers will be impacted by real
world testing. We estimate that, on average, it will take an ONC-ACB
employee at the GS-13, Step 1 level approximately 30 minutes to collect
all updates made to standards in Health IT Modules in accordance with
Sec. 170.523(m). The hourly wage with benefits for a GS-13, Step 1
employee located in Washington, DC is approximately $91. Since the
collection must occur no less than quarterly, we assume it occurs, on
average, four times per year. Therefore, we estimate the annual cost to
ONC-ACBs to comply with the collection requirements under Sec.
170.523(m) to be $78,078.
We estimated that, on average, it will take an ONC-ACB employee at
the GS-
[[Page 25933]]
13, Step 1 level approximately one hour to review and confirm that
applicable health IT developers submit real world testing plans in
accordance with Sec. 170.405(b)(1). We estimate that, on average, it
will take an ONC-ACB employee at the GS-13, Step 1 level approximately
30 minutes to review and confirm that applicable health IT developers
submit real world testing results in accordance with Sec.
170.405(b)(2). We estimate that, on average, it will take an ONC-ACB
employee at the GS-13, Step 1 level approximately 30 minutes to submit
real world testing plans and results to ONC for public availability.
The hourly wage with benefits for a GS-13, Step 1 employee located in
Washington, DC is approximately $91. Therefore, we estimate the annual
cost to ONC-ACBs to comply with the submission and reporting
requirements under Sec. Sec. 170.523(m) and 170.550(l) to be $156,156.
Throughout the RIA we have used 830 products as our 2015 Edition
projection. We came up with this projection by multiplying a -23.2
percent market consolidation rate from the total number of products
certified to 2014 Edition. This assumption was based on the market
consolidation rate observed between the 2011 and 2014 Editions. We have
estimated the number of 2015 Edition products that will certify each
criterion included in the real world testing Condition of Certification
requirement. We assume that there will be a cost associated with a
notice for each certified criterion (even if an individual product were
to update the same standard across multiple criteria that use that
standard). This estimation was calculated by multiplying the current
percent of 2015 Edition products that certify a criterion by the
estimated number of total 2015 Edition products (830). For example, we
calculated that 43 percent of 2015 Edition products certified
170.315(b)(1); we then multiplied this percentage by 830--the predicted
number of 2015 Edition products. Thus, based on this calculation, for
2015 Edition, we predict that 359 products will certify the
170.315(b)(1) criterion. This method was used across all criteria
included in the real world testing Condition of Certification
requirement.
We assume that the amount of time for an ONC-ACB staff person to:
(1) Maintain a record of the date of issuance and the content of
developers' notices; and (2) to timely post content of each notice on
the CHPL can be anywhere from 30 minutes to one hour.
The hourly wage with benefits for a GS-13, Step 1 employee located
in Washington, DC is approximately $91. This was the hourly rate we
used for this RIA, so it is consistent with prior calculations. This
wage is used to determine the ONC-ACB time cost to complete this
requirement under Sec. 170.523(t). For this estimate, we take half the
hourly rate and multiply it by the number of products predicted to
certify each of the applicable criteria. For each criterion, we
estimate a lower bound and upper bound prediction. The lower bound
assumes that 25 percent of certified products update any of the
applicable standards. The upper bound prediction assumes that all
certified products update any of the applicable standards. These
estimates are calculated for each criterion and then the cumulative sum
of all the individual criterion calculations is made. We estimate, at
30 minutes per notice, it will cost $60,606 if 25 percent of certified
products update any of the applicable standards across all criteria,
and if all products update any of the applicable standards, we estimate
it will cost $242,424. Our maximum estimate for time to comply is one
hour per notice.
Using the same methodology explained above, we estimate, at 60
minutes per notice, it will cost $121,212 if 25 percent of certified
products update any of the applicable standards across all criteria,
and if all products update any of the applicable standards, we estimate
it will cost $484,848. Our lower bound estimate for the cost of this
requirement is $60,606. Our upper bound estimate for the cost of this
requirement is $484,848.
Comments. We received a comment recommending that ONC add
accountability to the real world testing process by having ONC-ACBs
review a randomly selected percentage of submitted results for
potential non-conformity with certification requirements.
Response. We thank commenters for their input. It is within ONC-
ACBs' rights and interests to randomly select certified Health IT
Modules that have been real world tested as part of their surveillance
activities. ONC will be working closely with ONC-ACBs to provide
direction on how ONC-ACBs can leverage existing Program and ISO/IEC
17065 requirements to provide oversight without increasing burden by
setting a minimum expectation in regulation. Setting a regulatory quota
could potentially create burden as workloads amongst the different ONC-
ACBs vary. Additionally, it limits ONC-ACBs to what is adopted in the
final rule and prevents future adjustments that may be needed to
improve efficiency without additional rulemaking. We have finalized our
estimates.
(vi) Attestations
The Cures Act requires that a health IT developer, as a Condition
and Maintenance of Certification requirement under the Program, provide
to the Secretary an attestation to all the Conditions and Maintenance
of Certification requirements specified in the Cures Act, except for
the ``EHR Reporting Program'' Condition of Certification requirement.
It also requires that a health IT developer attest that its health IT
allows for health information to be exchanged, accessed, and used in
the manner described by the API Condition of Certification requirement.
We have finalized our proposal to implement the Cures Act
``attestations'' requirement in Sec. 170.406 by requiring health IT
developers to attest to the aforementioned Conditions. For the purposes
of estimating the potential burden of these attestations on health IT
developers, ONC-ACBs, and ONC, we estimate that all health IT
developers under the Program will submit an attestation biannually. As
noted previously in this RIA, there are 792 health IT developers
certified to the 2014 Edition.
We estimated it would take a health IT developer employee
approximately one hour on average to prepare and submit each
attestation to the ONC-ACB. According to the May 2017 BLS occupational
employment statistics, the mean hourly wage for a software developer is
$53.74.\241\ Therefore, we estimated the annual cost including overhead
costs to be $84,744. We have finalized that attestations will be
submitted to ONC-ACBs on behalf of ONC and the Secretary. We assume
there will be four ONC-ACBs as this is the current number of ONC-ACBs,
and we also assume an equal distribution in responsibilities among ONC-
ACBs. ONC-ACBs would have two responsibilities related to attestations.
One responsibility we finalized in Sec. 170.523(q) is that an ONC-ACB
must review attestations for completion and submit the health IT
developers' attestations to ONC. We estimate it will take an ONC-ACB
employee at the GS-13, Step 1 level approximately 30 minutes on average
to review and submit each attestation to ONC. The other responsibility
we are finalizing in Sec. 170.550(l) is that an ONC-ACB would need to
ensure that the health IT developer of the Health IT Module has
[[Page 25934]]
met its responsibilities related to the Conditions and Maintenance of
Certification requirements as solely evidenced by its attestation. We
estimate it will take an ONC-ACB employee at the GS-13, Step 1 level
approximately one hour on average to complete this task. The hourly
wage with benefits for a GS-13, Step 1 employee located in Washington,
DC is approximately $91. Therefore, we estimate the annual cost to ONC-
ACBs to be $108,108.
---------------------------------------------------------------------------
\241\ See https://www.bls.gov/oes/2017/may/oes439061.
---------------------------------------------------------------------------
We have finalized that we would make the attestations publicly
available on the CHPL once they are submitted by the ONC-ACBs. ONC
posts information regularly to the CHPL and we estimate the added costs
to post the attestation will be de minimis.
Comments. We did not receive comment specific to the methods
related to the estimates for posting attestations.
Response. We maintain our assumptions and estimates as proposed
regarding attestations.
(4) Oversight for the Conditions and Maintenance of Certification
Requirements
Our processes for overseeing the Conditions and Maintenance of
Certification requirements will, for the most part, mirror our
processes for direct review of non-conformities in certified health IT
as described in current Sec. 170.580. We may directly review a health
IT developer's actions to determine whether they conform to the
Conditions and Maintenance of Certification requirements finalized in
this final rule. The estimated costs and benefits for such oversight
and review are detailed below.
(i) Costs
We estimated the potential monetary costs of allowing ONC to
directly review a health IT developer's actions to determine whether
the actions conform to the requirements of the Program as follows: (1)
Costs for health IT developers to correct non-conforming actions
identified by ONC; (2) costs for health IT developers and ONC costs
related to ONC review and inquiry into non-conforming actions by the
health IT developer; and (3) costs for ONC-ACBs related to the new
reporting requirement in the Principles of Proper Conduct in Sec.
170.523(s).
(A) Costs for Health IT Developers to Correct Non-Conforming Actions
Identified by ONC
We do not believe health IT developers face additional direct costs
for the ONC direct review of health IT developer actions (see cost
estimates for the Conditions and Maintenance of Certification
requirements). However, we acknowledge that this final rule may
eventually require health IT developers to correct certain actions or
non-conformities with their health IT that do not conform to the
Conditions and Maintenance of Certification requirements.
If we identify a non-conforming action by a health IT developer,
the costs incurred by the health IT developer to bring its actions into
conformance will be determined on a case-by-case basis. Factors that
will be considered include, but are not limited to: (1) The extent of
customers and/or business affected; (2) how pervasive the action(s) is
across the health IT developer's business; (3) the period of time that
the health IT developer was taking the action(s) in question; and (4)
the corrective action required to resolve the issue. We are unable to
reliably estimate these costs as we do not have cost estimates for a
comparable situation. We requested comment on existing relevant data
and methods we could use to estimate these costs.
Comments. We did not receive any comments specific to the relevant
data and methods used to estimate the costs to correct non-conforming
actions identified by ONC.
Response. We maintain our approach used to estimate the costs to
correcting identified non-conformities.
(B) Costs for Health IT Developers and ONC Costs Related to ONC Review
and Inquiry Into Health IT Developer Actions
In order to calculate the potential costs to health IT developers
and ONC related to ONC review and inquiry into health IT developer
actions, we have created the following categories for potential costs:
(1) ONC review and inquiry prior to the issuance of a notice of non-
conformity; (2) ONC review and inquiry following the issuance of a
notice of non-conformity and the health IT developer does not contest
ONC's findings (i.e., no appeal); and (3) ONC review and inquiry
following the issuance of a notice of non-conformity and the health IT
developer contests ONC's findings (i.e., appeal).
(C) ONC Review and Inquiry Prior to the Issuance of a Notice of
Nonconformity
We anticipate that ONC will receive, on average, between 100 and
200 complaints per year concerning the Conditions and Maintenance of
Certification requirements that will warrant review and inquiry by ONC.
We estimate that such initial review and inquiry by ONC will require,
on average, two to three analysts at the GS-13 level working one to two
hours each per complaint. The hourly wage with benefits for a GS-13,
Step 1 employee located in Washington, DC is approximately $91.
Therefore, we estimate each review and inquiry will cost ONC, on
average, between $182 and $546. We estimate the total annual cost to
ONC will, on average, range from $18,200 and $109,200. This range takes
into account both the low end of reviews that are resolved quickly and
the high end in which staff will need to discuss issues with ONC
leadership or in some cases, HHS senior leadership including the Office
of General Counsel. We have not estimated health IT developer costs
associated with ONC review prior to the issuance of a notice of non-
conformity because, in most cases, health IT developers are not
required to take action prior to the notice of non-conformity.
(D) ONC Review and Inquiry Following the Issuance of a Notice of Non-
Conformity and the Health IT Developer Does Not Contest ONC's Findings
This category captures cases that require review and inquiry
following ONC's issuance of a notice of non-conformity, but that do not
proceed to the appeals process. Examples of such situations would
include, but not be limited to: (1) A health IT developer violates a
Condition of Certification requirement and does not contest ONC's
finding that it is in violation of the Condition of Certification
requirement; or (2) a health IT developer fails to meet a deadline,
such as for its corrective action plan (CAP). We estimate that ONC
will, on average, conduct between 12 and 18 of these reviews annually.
We estimate that a health IT developer may commit, on average and
depending on complexity, between 10 and 40 hours of staff time per case
to provide ONC with all requested records and documentation that ONC
would use to review and conduct an inquiry into health IT developer
actions, and, when necessary, make a certification ban and/or
termination determination. We assumed that the work will be performed
by a ``Computer Systems Analyst.'' According to the May 2017 BLS
occupational employment statistics, the mean hourly wage for computer
systems analyst is $44.59.\242\ As noted previously, we have assumed
that overhead costs (including benefits) are equal to 100 percent of
pre-tax wages, so the hourly wage including overhead costs would be
$89. Therefore,
[[Page 25935]]
we estimate the average annual cost for health IT developers would
range from $10,680 to $64,080. We note that some health IT developers'
costs are expected to be less and some health IT developers' costs are
expected to be more than this estimated cost range. Further, we note
that these costs would be perpetual.
---------------------------------------------------------------------------
\242\ https://www.bls.gov/oes/2017/May/oes151121.htm.
---------------------------------------------------------------------------
We estimate that ONC may commit, on average and depending on
complexity, between eight and 80 hours of staff time to complete a
review and inquiry into health IT developer actions. We assume that the
expertise of a GS-15, Step 1 Federal employee(s) will be necessary. The
hourly wage with benefits for a GS-15, Step 1 employee located in
Washington, DC is approximately $126. Therefore, based on the estimate
of between 12 and 18 cases each year, we estimate ONC's annual costs
would range, on average, from $12,096 to $181,440. We note that some
reviews and inquiries may cost less and some may cost more than this
estimated cost range. Further, we note that these costs would be
perpetual.
We welcomed comments on our estimated costs and any comparable
processes and costs that we could use to improve our estimates.
Comments. We did not receive any comments specific to the relevant
data and methods used to estimate the costs to: (1) ONC review and
inquiry prior to the issuance of a notice of non-conformity; (2) ONC
review and inquiry following the issuance of a notice of non-conformity
and the health IT developer does not contest ONC's findings (i.e., no
appeal); and (3) ONC review and inquiry following the issuance of a
notice of non-conformity and the health IT developer contests ONC's
findings (i.e., appeal).
Response. We maintain our approach used to estimate the costs to
health IT developers and to ONC, related to ONC review and inquiry into
health IT developer actions.
(E) ONC Review and Inquiry Following the Issuance of a Notice of Non-
Conformity and the Health IT Developer Contests ONC's Findings
As discussed in section VII.C of this preamble, we permit a health
IT developer to appeal an ONC determination to issue a certification
ban and/or terminate a certification under Sec. 170.580(a)(2)(iii).
This category of cost calculations captures cases that require review
and inquiry following ONC's issuance of a notice of non-conformity and
where the health IT developer contests ONC's finding and files an
appeal. We estimate that ONC will, on average, conduct between three
and five of these reviews annually.
We estimated that a ``Computer Systems Analyst'' for the health IT
developer may commit, on average and depending on complexity, between
20 and 80 hours to provide the required information to appeal a
certification ban and/or termination under Sec. 170.580(a)(2)(iii) and
respond to any requests from the hearing officer. According to the May
2017 BLS occupational employment statistics, the mean hourly wage for a
computer systems analyst is $44.59.\243\ Assuming that overhead costs
(including benefits) are equal to 100 percent of pre-tax wages, the
hourly wage including overhead costs is $89. Therefore, we estimate the
annual cost, including overhead costs, for a health IT developer to
appeal a certification ban and/or termination under Sec.
170.580(a)(2)(iii) would, on average, range from $5,340 to $35,600. We
note that some health IT developers' costs are expected to be less and
some health IT developers' costs are expected to be more than this
estimated cost range. Further, we note that these costs would be
perpetual.
---------------------------------------------------------------------------
\243\ See https://www.bls.gov/oes/2017/May/oes151121.htm.
---------------------------------------------------------------------------
We estimated that ONC would commit, on average and depending on
complexity, between 40 and 160 hours of staff time to conduct each
appeal. This will include the time to represent ONC in the appeal and
support the costs for the hearing officer. We assume that the expertise
of a GS-15, Step 1 Federal employee(s) would be necessary. The hourly
wage with benefits for a GS-15, Step 1 employee located in Washington,
DC is approximately $126. Therefore, based on the estimate of between
three and five cases each year, we estimate the cost for ONC to conduct
an appeal would range, on average, from $15,120 to $100,800. We note
that some appeals may cost less and some may cost more than this
estimated cost range. Further, we note that these costs would be
perpetual.
Based on the above estimates, we estimated the total annual costs
for health IT developers related to ONC review and inquiry into health
IT developer actions would range, on average, from $16,020 to $99,680.
We estimated the total annual costs for ONC related to ONC review and
inquiry into health IT developer actions would range, on average, from
$44,603 to $383,345.
Comments. We did not receive any comments specific to the relevant
data and methods used to estimate the costs of (1) ONC review and
inquiry prior to the issuance of a notice of non-conformity; (2) ONC
review and inquiry following the issuance of a notice of non-conformity
and the health IT developer does not contest ONC's findings (i.e., no
appeal); and (3) ONC review and inquiry following the issuance of a
notice of non-conformity and the health IT developer contests ONC's
findings (i.e., appeal).
Response. We maintain our approach used to estimate the costs to
health IT developers and to ONC, related to ONC review and inquiry into
health IT developer actions.
(F) Costs for ONC-ACBs
We also note that ONC-ACBs could realize costs associated with the
new reporting requirement in the Principles of Proper Conduct in Sec.
170.523(s) that they report, at a minimum, no later than a week after
becoming aware of, any information that could inform whether ONC should
exercise direct review under Sec. 170.580(a). We estimate that, on
average, it will take an ONC-ACB employee at the GS-13, Step 1 level
approximately 30 minutes to prepare the report. The hourly wage with
benefits for a GS-13, Step 1 employee located in Washington, DC is
approximately $91. Since the collection must occur no less than weekly,
we will assume it occurs, on average, 52 times per year. Therefore,
given that there are currently three ONC-ACBs, we estimate the annual
cost to ONC-ACBs to comply with the reporting requirement under Sec.
170.523(s) would, on average, be $7,098. We did not receive comments
regarding our calculations. We have finalized these estimates.
(ii) Benefits
This final rule's provisions for ONC direct review of the
Conditions and Maintenance of Certification requirements would promote
health IT developers' accountability for their actions and ensure that
health IT developers' actions conform with the requirements of the
Cures Act and Conditions and Maintenance of Certification requirements
in Sec. Sec. 170.400-406. Specifically, ONC's direct review of health
IT developer actions will facilitate ONC's ability to require
comprehensive corrective action by health IT developers to address non-
conforming actions determined by ONC. If ONC ultimately implements a
certification ban and/or terminates a certification(s), such action
will serve to protect the integrity of the Program and users of health
IT. While we do not have available means to quantify the benefits of
ONC direct review of health IT developer actions, we note that ONC
[[Page 25936]]
direct review supports and enables the National Coordinator to fulfill
his responsibilities under the HITECH Act and Cures Act, instills
public confidence in the Program, and protects public health and
safety. We did not receive comments regarding our calculations. We have
finalized these estimates. (5) Information Blocking
(i) Costs
We expect ONC to incur an annual cost for issuing educational
resources related to the information blocking ``reasonable and
necessary'' exceptions. We estimate that ONC issues educational
resources each quarter, therefore, four per year. We assume that the
educational resources would be provided by ONC staff with the expertise
of a GS-15, Step 1 Federal employee(s). The hourly wage with benefits
for a GS-15, Step 1 employee located in Washington, DC is approximately
$126. We estimate it would take ONC staff between 200 and 400 hours to
develop the guidance. Therefore, we estimate the annual cost to ONC
would range, on average, from $100,800 to $201,600.
Comments. We did not receive any comments regarding the specific
costs associated with information blocking.
Response. We have adopted our estimates as proposed. We note that
we did receive comments regarding ``burden'' on various stakeholder
groups related to our information blocking proposals, and those
comments are addressed throughout the information blocking section
(section VIII) of this final rule.
(ii) Benefits
Information blocking not only interferes with effective health
information exchange, but also negatively impacts many important
aspects of health and health care. For a detailed discussion of the
negative impacts of information blocking, we refer readers to section
XIV.C.2.a(2) of the Proposed Rule (84 FR 7584).
The exceptions to the information blocking definition adopted in
this final rule create clear guidelines for industry regarding pro-
competitive and other beneficial activities and will enable
stakeholders to determine more easily and with greater certainty
whether their activities are excepted from the information blocking
definition. Overall, the finalized exceptions are accommodating to
legitimate industry practices for health IT developers, hospitals, and
health care providers and, we believe, will ease the burden and
compliance costs for these parties.
To estimate the benefits of information blocking, we first examined
existing data sources to identify a proxy that will indicate the extent
to which information blocking is occurring. According to analysis of
data from the American Hospital Association IT Supplement survey, 53
percent of non-Federal acute care hospitals reported that they had
challenges with exchanging data across different vendor platforms.\244\
Moreover, 31 percent reported that they must pay additional costs to
exchange information with organizations outside of the system. Nearly
one in four hospitals reported that they had to develop customized
interfaces to electronically exchange information.
---------------------------------------------------------------------------
\244\ Pylypchuk Y., Johnson C., Henry J. & Ciricean D. (November
2018). Variation in Interoperability among U.S. Non-Federal Acute
Care Hospitals in 2017. ONC Data Brief, no.42. Office of the
National Coordinator for Health Information Technology: Washington
DC.
---------------------------------------------------------------------------
To quantify the magnitude of information blocking and the benefits
of restricting information blocking, we estimated the following, which
gives us the imposed cost of information blocking for each health
outcome: [Percent of providers that engage in cross-vendor exchange] *
[marginal effect (ME) of information blocking on interoperability] *
[ME effect of interoperability on the health outcome] * [total cost of
health outcome].
We extracted the ``ME effect of interoperability on the health
outcome'' and ``cost of health outcomes'' from academic literature (see
citations in Table 24). We then determined a proxy for the number of
providers that engage in cross-vendor exchange. We did this by
leveraging hospital referral data from 2015 to determine the proportion
of hospitals that referred patients to a provider outside of their
system where the receiving provider used a different EHR vendor. We
determined that 82 percent of hospitals engaged in cross-vendor
exchange. This estimate was used as the proxy for ``providers that
engaged in cross-vendor exchange.''
We estimated the ``ME of information blocking on interoperability''
through the following research design:
Y = b1InforBlock + X'B + e
Where y = 1 if a hospital routinely engages in four domains of
interoperability--sending, receiving, finding, and integrating data, 0
otherwise. The variable InforBlock is a binary indicator for whether a
hospital reported experiencing challenges with exchanging data across
different vendor platforms. We assume the impact of reporting this
barrier is a proxy for the extent to which vendors hinder a hospital's
interoperability. In the model, we control for the following:
Hospital's primary vendor, participation in health exchange
organization, participation in five different networks, system
ownership, level of system centralization, bed size, profit status,
public status, region, location in urban area. The marginal effect of b
is 0.04. We assume that this effect may capture other reasons not
related to information blocking, so we use half of this estimate for
our benefit calculations--0.02.
Table 28--Benefits of Prohibiting and/or Deterring Information Blocking
[2017 Dollars]
--------------------------------------------------------------------------------------------------------------------------------------------------------
Marginal
Overall Percent of effect of
interop impact providers information Benefit
Benefit type Total cost impacted Total cost (marginal susceptible to blocking benefit A
effect) information (percentage
blocking points)
--------------------------------------------------------------------------------------------------------------------------------------------------------
Duplicate testing.................... 100%.................... 200 billion B.......... C 0.09 82 0.02 $295,200,000
Avoidable hospitalizations and 100%.................... $41 billion D.......... 0.09 82 0.02 60,516,000
readmissions.
ER visits............................ 131 million visits E.... Cost per ER visit 0.03 82 0.02 79,469,316
$1,233.
Adverse drug events.................. 20%..................... $30 billion F.......... 0.22 82 0.02 21,648,000
[[Page 25937]]
Total benefit per year........... ........................ ....................... .............. .............. .............. $456,833,316
--------------------------------------------------------------------------------------------------------------------------------------------------------
\A\ Total benefit would be a product of % of total cost impacted, total cost, overall interop impact, percent of providers susceptible to information
blocking, and marginal effect of information blocking; however, no reasonable estimate of the marginal effect of information blocking is currently
available.
\B\ National Academy of Medicine (2016), http://money.cnn.com/2017/05/20/news/economy/medical-tests/index.html.
\C\ Stephen E. Ross, Tiffany A. Radcliff, William G. Leblanc, L. Miriam Dickinson, Anne M. Libby, and Donald E. Nease Jr., Effects of health 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 Michael Landzberg, A preliminary look at duplicate testing associated with lack of electronic health record interoperability
for transferred patients, J. of the Am. Med. Informatics Assoc. (2010), at 341-344; Sezgin Ayabakan, Indranil R. Bardhan, Zhiqiang (Eric) Zheng, and
Kirk Kirksey Value of health information sharing in reducing healthcare waste: An analysis of duplicate testing across hospitals, MIS Quarterly (Jan.
1, 2017); Eric J. Lammers, Julia Adler-Milstein, and Keith E. Kocher, Does health information exchange reduce redundant imaging? Evidence from
emergency departments, Med Care (Mar. 2014), at 227-34.
\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 Trifir[ograve], Clinical and economic burden of adverse drug reactions.
As a result of this calculation, we estimate that the benefit of
the information blocking provision is $456 million.
Comments. We did not receive any comments regarding our approach to
estimating benefits or the specific benefit estimates associated with
information blocking.
Response. ONC has revised its methodological approach to
quantifying the benefits of our information blocking provision. This
new methodology is described in the RIA.
(6) Total Annual Cost Estimate
The total annual cost estimate is expressed in 2016 dollars to meet
regulatory reform analysis requirements under Executive Order 13771. We
estimated that the total cost for this final rule for the first year
after it is finalized (including one-time costs), based on the cost
estimates outlined above and throughout this RIA, would range, on
average, from $953 million to $2.6 billion with an average annual cost
of $1.8 billion. We estimated that the total perpetual cost for this
final rule (starting in year two), based on the cost estimates outlined
above, would range, on average, from $366 million to $1.3 billion with
an average annual cost of $840 million. We also included estimates
based on the stakeholder groups affected. We estimated the total costs
to health IT developers to be between $483 million and $1.1 billion
(including one-time and perpetual costs) with $633,000 in cost savings
from deregulatory actions. Assuming that 458 health IT developers will
be impacted, the cost per developer will range from $1.1 million to
$2.4 million. Based on previous participation in the CMS EHR Incentive
Program, we estimated that 439,187 health care providers in 95,470
clinical practices and 4,519 hospitals that participated in the CMS EHR
Incentive Program will be impacted by this final rule. We estimated the
total cost to health care providers to be between $478 million to $1.6
billion. We did not calculate per entity costs for health care
providers. We acknowledged that costs may be passed from health IT
developers to their customers (i.e. health care providers) during the
licensing of their health IT modules. We estimated the total costs to
ONC-ACBs to be between $391,000 and $792,000. We estimated the
government costs (through labor hours of ONC staff) to be between
$159,000 and $586,000 with $4,497 in cost savings from deregulatory
actions. In addition to the above-mentioned cost savings that are
attributable to specific stakeholder groups, we estimated an additional
cost savings of $6.6 million to $13.3 million to all stakeholders
affected by this provision. We are unable to attribute these amounts to
specific stakeholder groups. We did not receive comment regarding these
calculations. We have finalized our estimates.
(7) Total Annual Benefit Estimate
The total annual benefit estimate is expressed in 2016 dollars to
meet regulatory reform analysis requirements under Executive Order
13771. We estimated the total annual benefit for this final rule, based
on the benefit estimates outlined above, would range from $1.2 billion
to $5.0 billion with primary estimated annual benefit of $3.1 billion.
Our estimates include benefits attributed to the entire health care
system, including hospitals, clinicians, payers and patients.(8) Total
Annualized Net Benefit
The total annualized net benefit is expressed in 2016 dollars to
meet regulatory reform analysis requirements under Executive Order
13771. We estimate the total annualized net benefit for this final
rule, based on the estimates outlined above, would range from $191
million to $2.3 billion with a primary net benefit estimate of $1.3
billion.
b. Accounting Statement and Table
When a rule is considered an economically significant rule under
Executive Order 12866, we are required to develop an accounting
statement indicating the classification of the expenditures associated
with the provisions of the proposed rule. Monetary annual benefits are
presented as discounted flows using three percent and seven percent
factors in Table 29. We are not able to explicitly define the universe
of all costs, but have provided an average of likely costs of this
final rule as well as a high and low range of likely costs.
Unquantifiable costs and benefits are noted in Table 31. This final
rule requires no Federal transfers, but it might bring about a
reduction in fraudulent payments to providers by the
[[Page 25938]]
Federal Government and other payers.\245\
---------------------------------------------------------------------------
\245\ Parente, Stephen T., Karen Mandelbaum, Susan P. Hanson,
Bonnie S. Cassidy and Donald W. Simborg. ``Crime and Punishment: Can
the NHIN Reduce the Cost of Healthcare Fraud?'' Journal of
Healthcare Information Management 22(3): 42-51. June 2008.
Table 29--EO 12866 Summary Table
[In $ millions, 2016 Dollars]
--------------------------------------------------------------------------------------------------------------------------------------------------------
Lower bound Upper bound Lower bound Upper bound
Primary (3%) (3%) (3%) Primary (7%) (7%) (7%)
--------------------------------------------------------------------------------------------------------------------------------------------------------
Present Value of Quantified Costs....................... 6,454 2,966 9,943 4,574 2,120 7,028
Present Value of Quantified Benefits.................... 23,411 8,831 37,991 16,552 6,244 26,859
Present Value of Net Benefits........................... 16,957 5,865 28,049 16,552 4,124 19,832
Annualized Quantified Costs............................. 852 391 1,312 854 396 1,312
Annualized Quantified Benefits.......................... 3,089 1,165 5,013 2,184 824 3,544
Annualized Net Quantified Benefits...................... 2,237 774 3,701 1,330 428 2,232
--------------------------------------------------------------------------------------------------------------------------------------------------------
Table 30--E.O. 12866 Summary Table Non-Discounted Flows
[2016 Dollars]
----------------------------------------------------------------------------------------------------------------
Year 1 Year 2 Year 3 Year 4 Year 5
----------------------------------------------------------------------------------------------------------------
Costs........................... 942,795,801 839,887,346 839,887,346 839,887,346 839,887,346
Benefits........................ 3,088,980,583 3,088,980,583 3,088,980,583 3,088,980,583 3,088,980,583
----------------------------------------------------------------------------------------------------------------
Year 6 Year 7 Year 8 Year 9 Year 10
----------------------------------------------------------------------------------------------------------------
Costs........................... 839,887,346 839,887,346 839,887,346 839,887,346 839,887,346
Benefits........................ 3,088,980,583 3,088,980,583 3,088,980,583 3,088,980,583 3,088,980,583
----------------------------------------------------------------------------------------------------------------
Table 31--Non-Quantifiable Benefits
[2016 Dollars]
----------------------------------------------------------------------------------------------------------------
Present value of 10 years by Annualized value over 10 years
discount rate (in millions) by discount rate (in millions)
Benefits ---------------------------------------------------------------
3 Percent 7 Percent 3 Percent 7 Percent
----------------------------------------------------------------------------------------------------------------
Quantified Benefits............................. 23,411 16,552 3,089 2,184
----------------------------------------------------------------------------------------------------------------
Non-quantified Benefits:
Impact on users of health IT that were ineligible or did not participate in the CMS EHR Incentive Programs;
developer cost savings from no longer supporting the 2014 Edition; provider and patient benefit from
implementation of USCDI and Security tags (DS4P) provisions due to improvements in interoperability;
benefits associated with communication provision because we do not have adequate information to determine
the prevalence of gag clauses and other such restrictive practices nor do we have a means to quantify the
value to providers of being able to freely communicate and share information; benefit of ONC oversight on
real world testing and non-conformance; external regulatory and policy activities..........................
----------------------------------------------------------------------------------------------------------------
Costs 3 Percent 7 Percent 3 Percent 7 Percent
----------------------------------------------------------------------------------------------------------------
Quantified Costs................................ 6,454 4,574 852 396
----------------------------------------------------------------------------------------------------------------
Non-quantified Costs:
Impact of provisions on health IT production costs such as the supply and demand for personnel over time;
costs developers to correct non-conformities; ONC cost to review non-conformities, real-world testing
maintenance by ACBs; additional provider implementation activities related to USCDI and DS4P; external
regulatory and policy activities...........................................................................
----------------------------------------------------------------------------------------------------------------
3. Regulatory Flexibility Act
The Regulatory Flexibility Act (RFA) requires agencies to analyze
options for regulatory relief of small businesses if a rule has a
significant impact on a substantial number of small entities. The Small
Business Administration (SBA) establishes the size of small businesses
for Federal Government programs based on average annual receipts or the
average employment of a firm.\246\ The entities that are likely to be
directly affected by the requirements in this final rule are health IT
developers. We note that the reasonable and necessary activities that
do not constitute information blocking provide flexibilities and relief
for health IT developers of certified health IT, health information
networks, health information exchanges, and health care providers in
relation to the information blocking provision of the Cures Act. These
reasonable and necessary activities also take into account the
potential burden on small entities to
[[Page 25939]]
meet these ``exceptions'' to information blocking, such as with
considering the size and resources of small entities when meeting
security requirements to qualify for the ``promoting the security of
electronic health information'' exception.
---------------------------------------------------------------------------
\246\ The SBA references that annual receipts means ``total
income'' (or in the case of a sole proprietorship, ``gross income'')
plus ``cost of goods sold'' as these terms are defined and reported
on Internal Revenue Service tax return forms.
---------------------------------------------------------------------------
While health IT developers that pursue certification of their
health IT under the Program represent a small segment of the overall
information technology industry, we believe that many health IT
developers impacted by the requirements in this final rule most likely
fall under the North American Industry Classification System (NAICS)
code 541511 ``Custom Computer Programming Services.'' \247\ The SBA
size standard associated with this NAICS code is set at $27.5 million
annual receipts or less. There is enough data generally available to
establish that between 75 percent and 90 percent of entities that are
categorized under the NAICS code 541511 are under the SBA size
standard. We also note that with the exception of aggregate business
information available through the U.S. Census Bureau and the SBA
related to NAICS code 541511, it appears that many health IT developers
that pursue certification of their health IT under the Program are
privately held or owned and do not regularly, if at all, make their
specific annual receipts publicly available. As a result, it is
difficult to locate empirical data related to many of these health IT
developers to correlate to the SBA size standard. However, although not
perfectly correlated to the size standard for NAICS code 541511, we do
have information indicating that over 60 percent of health IT
developers that have had Complete EHRs and/or Health IT Modules
certified to the 2011 Edition had less than 51 employees (80 FR 62741).
---------------------------------------------------------------------------
\247\ https://www.sba.gov/sites/default/files/files/Size_Standards_Table_2017.pdf.
---------------------------------------------------------------------------
We estimated that the requirements in this final rule will have
effects on health IT developers, some of which may be small entities,
that have certified health IT or are likely to pursue certification of
their health IT under the Program. We believe, however, that we have
finalized the minimum amount of requirements necessary to accomplish
our primary policy goal of enhancing interoperability. Further, as
discussed in section XIII.B of this RIA above, there are no appropriate
regulatory or non-regulatory alternatives that could be developed to
lessen the compliance burden associated with this final rule because
many of the provisions are derived directly from legislative mandates
in the Cures Act. Additionally, we have attempted to offset some of the
burden imposed on health IT developers in this final rule with cost
saving provisions through deregulatory actions (see section III).
Additionally, the Secretary certifies that this final rule will not
have a significant impact on a substantial number of small entities.
4. Executive Order 13132--Federalism
Executive Order 13132 establishes certain requirements that an
agency must meet when it promulgates a final rule that imposes
substantial direct requirement costs on State and local governments,
preempts State law, or otherwise has federalism implications. Nothing
in this final rule imposes substantial direct compliance costs on State
and local governments, preempts State law, or otherwise has federalism
implications. We are not aware of any State laws or regulations that
are contradicted or impeded by any of the provisions in this final
rule.
5. Unfunded Mandates Reform Act of 1995
Section 202 of the Unfunded Mandates Reform Act of 1995 requires
that agencies assess anticipated costs and benefits before issuing any
rule that imposes unfunded mandates on State, local, and tribal
governments or the private sector requiring spending in any one year of
$100 million in 1995 dollars, updated annually for inflation. The
current inflation-adjusted statutory threshold is approximately $150
million. While the estimated potential cost effects of this final rule
reach the statutory threshold, we do not believe this final rule
imposes unfunded mandates on State, local, and tribal governments or
the private sector.
OMB reviewed this final rule.
List of Subjects
45 CFR Part 170
Computer technology, Electronic health record, Electronic
information system, Electronic transactions, Health, Health care,
Health information technology, Health insurance, Health records,
Hospitals, Incorporation by reference, Laboratories, Medicaid,
Medicare, Privacy, Reporting and recordkeeping requirements, Public
health, Security.
45 CFR Part 171
Computer technology, Electronic health record, Electronic
information system, Electronic transactions, Health, Health care,
Health care provider, Health information exchange, Health information
technology, Health information network, Health insurance, Health
records, Hospitals, Privacy, Reporting and recordkeeping requirements,
Public health, Security.
For the reasons set forth in the preamble, 45 CFR subtitle A,
subchapter D, is amended as follows:
PART 170--HEALTH INFORMATION TECHNOLOGY STANDARDS, IMPLEMENTATION
SPECIFICATIONS, AND CERTIFICATION CRITERIA AND CERTIFICATION
PROGRAMS FOR HEALTH INFORMATION TECHNOLOGY
0
1. The authority citation for part 170 continues to read as follows:
Authority: 42 U.S.C. 300jj-11; 42 U.S.C 300jj-14; 5 U.S.C. 553
0
2. Revise Sec. 170.101 to read as follows:
Sec. 170.101 Applicability.
The standards, implementation specifications, and certification
criteria adopted in this part apply to Health IT Modules and the
testing and certification of such Health IT Modules.
0
3. Amend Sec. 170.102 by:
0
a. Removing the definitions of ``2014 Edition Base EHR'' and ``2014
Edition EHR certification criteria'';
0
b. Revising paragraph (3) in the definition of ``2015 Edition Base
EHR'';
0
c. Revising the definition of ``Common Clinical Data Set'';
0
d. Removing the definition of ``Complete EHR, 2014 Edition''; and
0
e. Adding in alphabetical order definitions for ``Electronic Health
Information'', ``Fee'', ``Health information technology'',
``Interoperability'', and ``Interoperability element''.
The revisions and additions read as follows:
Sec. 170.102 Definitions.
* * * * *
2015 Edition Base EHR * * *
(3) Has been certified to the certification criteria adopted by the
Secretary in--
(i) Section 170.315(a)(1), (2), or (3); (a)(5), (a)(9), (a)(14),
(b)(1), (c)(1), (g)(7) and (9), and (h)(1) or (2);
(ii) Section 170.315(g)(8) or (10) until May 2, 2022; and
(iii) Section 170.315(g)(10) on and after May 2, 2022.
* * * * *
Common Clinical Data Set means the following data expressed, where
indicated, according to the specified standard(s):
(1) Patient name.
(2) Sex: The standard specified in Sec. 170.207(n)(1).
(3) Date of birth.
[[Page 25940]]
(4) Race:
(i) The standard specified in Sec. 170.207(f)(2); and
(ii) The standard specified in Sec. 170.207(f)(1) for each race
identified in accordance Sec. 170.207(f)(2).
(5) Ethnicity:
(i) The standard specified in Sec. 170.207(f)(2); and
(ii) The standard specified in Sec. 170.207(f)(1) for each
ethnicity identified in accordance Sec. 170.207(f)(2).
(6) Preferred language: The standard specified in Sec.
170.207(g)(2).
(7) Smoking status.
(8) Problems: At a minimum, the standard specified in Sec.
170.207(a)(4).
(9) Medications: At a minimum, the standard specified in Sec.
170.207(d)(3).
(10) Medication allergies: At a minimum, the standard specified in
Sec. 170.207(d)(3).
(11) Laboratory test(s): At a minimum, the standard specified in
Sec. 170.207(c)(3).
(12) Laboratory value(s)/result(s).
(13) Vital signs:
(i) The patient's diastolic blood pressure, systolic blood
pressure, body height, body weight, heart rate, respiratory rate, body
temperature, pulse oximetry, and inhaled oxygen concentration must be
exchanged in numerical values only; and
(ii) In accordance with the standard specified in Sec.
170.207(c)(3) and with the associated applicable unit of measure for
the vital sign measurement in the standard specified in Sec.
170.207(m)(1).
(iii) Optional: The patient's BMI percentile per age and sex for
youth 2-20 years of age, weight for age per length and sex for children
less than 3 years of age, and head occipital-frontal circumference for
children less than 3 years of age must be recorded in numerical values
only in accordance with the standard specified in Sec. 170.207(c)(3)
and with the associated applicable unit of measure for the vital sign
measurement in the standard specified in Sec. 170.207(m)(1). For BMI
percentile per age and sex for youth 2-20 years of age and weight for
age per length and sex for children less than 3 years of age, the
reference range/scale or growth curve should be included as
appropriate.
(14) Procedures:
(i) At a minimum, the version of the standard specified in Sec.
170.207(a)(4) or Sec. 170.207(b)(2); or
(ii) For technology primarily developed to record dental
procedures, the standard specified in Sec. 170.207(b)(3).
(iii) Optional: The standard specified in Sec. 170.207(b)(4).
(15) Care team member(s).
(16) Immunizations: In accordance with, at a minimum, the standards
specified in Sec. 170.207(e)(3) and (4).
(17) Unique device identifier(s) for a patient's implantable
device(s): In accordance with the ``Product Instance'' in the
``Procedure Activity Procedure Section'' of the standard specified in
Sec. 170.205(a)(4).
(18) Assessment and plan of treatment:
(i) In accordance with the ``Assessment and Plan Section (V2)'' of
the standard specified in Sec. 170.205(a)(4); or
(ii) In accordance with the ``Assessment Section (V2)'' and ``Plan
of Treatment Section (V2)'' of the standard specified in Sec.
170.205(a)(4).
(19) Goals: In accordance with the ``Goals Section'' of the
standard specified in Sec. 170.205(a)(4).
(20) Health concerns: In accordance with the ``Health Concerns
Section'' of the standard specified in Sec. 170.205(a)(4).
* * * * *
Electronic health information (EHI) is defined as it is in Sec.
171.102.
Fee is defined as it is in Sec. 171.102 of this subchapter.
* * * * *
Health information technology means hardware, software, integrated
technologies or related licenses, IP, upgrades, or packaged solutions
sold as services that are designed for or support the use by health
care entities or patients for the electronic creation, maintenance,
access, or exchange of health information.
* * * * *
Interoperability is, with respect to health information technology,
such health information technology that--
(1) Enables the secure exchange of electronic health information
with, and use of electronic health information from, other health
information technology without special effort on the part of the user;
(2) Allows for complete access, exchange, and use of all
electronically accessible health information for authorized use under
applicable State or Federal law; and
(3) Does not constitute information blocking as defined in Sec.
171.103 of this subchapter.
Interoperability element is defined as it is in Sec. 171.102 of
this subchapter.
* * * * *
Sec. 170.200 [Amended]
0
4. Amend Sec. 170.200 by removing the phrase ``Complete EHRs and''.
Sec. 170.202 [Amended]
0
5. Amend Sec. 170.202 by removing and reserving paragraph (a)(1).
Sec. 170.204 [Amended]
0
6. Amend Sec. 170.204 by removing and reserving paragraphs (b)(1) and
(2) and removing paragraph (c).
0
7. Amend Sec. 170.205 by:
0
a. Removing and reserving paragraphs (a)(1) and (2);
0
b. Adding paragraphs (a)(5) and (b)(1);
0
c. Removing and reserving paragraphs (d)(3), (e)(3), and (h)(1);
0
d. Adding paragraph (h)(3);
0
e. Removing and reserving paragraphs (i)(1) and (j); and
0
f. Adding paragraph (k)(3).
The additions read as follows:
Sec. 170.205 Content exchange standards and implementation
specifications for exchanging electronic health information.
(a) * * *
(5) Standard. HL7 CDA[supreg] R2 Implementation Guide: C-CDA
Templates for Clinical Notes R2.1 Companion Guide, Release 2
(incorporated by reference in Sec. 170.299).
* * * * *
(b) * * *
(1) Standard. National Council for Prescription Drug Programs
(NCPDP): SCRIPT Standard Implementation Guide; Version 2017071
(incorporated by reference in Sec. 170.299).
* * * * *
(h) * * *
(3) Standard. CMS Implementation Guide for Quality Reporting
Document Architecture: Category I; Hospital Quality Reporting;
Implementation Guide for 2019 (incorporated by reference in Sec.
170.299).
* * * * *
(k) * * *
(3) Standard. CMS Implementation Guide for Quality Reporting
Document Architecture: Category III; Eligible Clinicians and Eligible
Professionals Programs; Implementation Guide for 2019 (incorporated by
reference in Sec. 170.299).
* * * * *
Sec. 170.207 [Amended]
0
8. Amend Sec. 170.207 by removing and reserving paragraphs (d)(2),
(e)(2), (g)(1), (h), and (j).
Sec. 170.210 [Amended]
0
9. Amend Sec. 170.210:
0
a. By removing and reserving paragraphs (a)(1) and (c)(1);
0
b. In paragraph (e)(1)(i), by removing the words ``7.2 through 7.4,
7.6, and 7.7'' and adding in their place ``7.1.1 through 7.1.3 and
7.1.6 through 7.1.9''; and
0
c. In paragraph (h), by removing the words ``ASTM E2147-01 (Reapproved
2013)'' and adding in their place ``ASTM E2147-18''.
[[Page 25941]]
0
10. Add Sec. 170.213 to read as follows:
Sec. 170.213 United States Core Data for Interoperability
Standard. United States Core Data for Interoperability (USCDI),
Version 1 (v1) (incorporated by reference in Sec. 170.299).
0
11. Add Sec. 170.215 to read as follows:
Sec. 170.215 Application Programming Interface Standards.
The Secretary adopts the following application programming
interface (API) standards and associated implementation specifications:
(a)(1) Standard. HL7[supreg] Fast Healthcare Interoperability
Resources (FHIR [supreg]) Release 4.0.1 (incorporated by reference in
Sec. 170.299).
(2) Implementation specification. HL7 FHIR US Core Implementation
Guide STU 3.1.0. (incorporated by reference in Sec. 170.299).
(3) Implementation specification. HL7 SMART Application Launch
Framework Implementation Guide Release 1.0.0, including mandatory
support for the ``SMART Core Capabilities'' (incorporated by reference
in Sec. 170.299).
(4) Implementation specification. FHIR Bulk Data Access (Flat FHIR)
(v1.0.0: STU 1), including mandatory support for the ``group-export''
``OperationDefinition'' (incorporated by reference in Sec. 170.299).
(b) Standard. OpenID Connect Core 1.0, incorporating errata set 1
(incorporated by reference in Sec. 170.299).
0
12. Amend Sec. 170.299 by:
0
a. Revising paragraph (c)(1);
0
b. Removing and reserving paragraphs (c)(2) and (3) and (d)(2), (7),
and (8);
0
c. Adding paragraphs (e)(4) and (5);
0
d. Removing and reserving paragraphs (f)(3), (6), (7), (10), and (11);
0
e. Adding paragraphs (f)(30) through (34);
0
f. Removing and reserving paragraphs (h)(1) and (j)(1);
0
g. Adding paragraph (k)(3);
0
h. Removing and reserving paragraph (l)(3);
0
i. Adding paragraph (m)(5);
0
j. Redesignating paragraphs (n) through (r) as paragraphs (o) through
(s), respectively;
0
k. Adding new paragraph (n); and
0
l. Removing and reserving newly redesignated paragraphs (r)(4) and (5).
The revision and additions read as follows:
Sec. 170.299 Incorporation by reference.
* * * * *
(c) * * *
(1) ASTM E2147-18 Standard Specification for Audit and Disclosure
Logs for Use in Health Information Systems, approved May 1, 2018, IBR
approved for Sec. 170.210(h).
* * * * *
(e) * * *
(4) CMS Implementation Guide for Quality Reporting Document
Architecture Category I Hospital Quality Reporting Implementation Guide
for 2019; published May 4, 2018, IBR approved for Sec. 170.205(h).
(5) CMS Implementation Guide for Quality Reporting Document
Architecture Category III Eligible Clinicians and Eligible
Professionals Programs Implementation Guide for 2019; published October
8, 2018, IBR approved for Sec. 170.205(k).
(f) * * *
(30) HL7[supreg] CDA[supreg] R2 Implementation Guide: C-CDA
Templates for Clinical Notes R2.1 Companion Guide, Release 2-US Realm,
October 2019, IBR approved for Sec. 170.205(a).
(31) HL7 FHIR[supreg] Bulk Data Access (Flat FHIR[supreg]) (v1.0.0:
STU 1), August 22, 2019, IBR approved for Sec. 170.215(a).
(32) HL7 FHIR SMART Application Launch Framework Implementation
Guide Release 1.0.0, November 13, 2018, IBR approved for Sec.
170.215(a).
(33) HL7 Fast Healthcare Interoperability Resources Specification
(FHIR[supreg]) Release 4, Version 4.0.1: R4, October 30, 2019,
including Technical Correction #1, November 1, 2019, IBR approved for
Sec. 170.215(a).
(34) HL7 FHIR[supreg] US Core Implementation Guide STU3 Release
3.1.0, November 06, 2019, IBR approved for Sec. 170.215(a).
* * * * *
(k) * * *
(3) SCRIPT Standard, Implementation Guide, Version 2017071
(Approval Date for ANSI: July 28, 2017), IBR approved for Sec.
170.205(b).
* * * * *
(m) * * *
(5) United States Core Data for Interoperability (USCDI), Version
1, February 2020, IBR approved for Sec. 170.213; available at https://
www.healthit.gov/USCDI.
* * * * *
(n) OpenID Foundation, 2400 Camino Ramon, Suite 375, San Ramon, CA
94583, Telephone +1 925-275-6639, http://openid.net/.
(1) OpenID Connect Core 1.0 Incorporating errata set 1, November 8,
2014, IBR approved for Sec. 170.215(b).
(2) [Reserved]
* * * * *
Sec. 170.300 [Amended]
0
13. Amend Sec. 170.300 in paragraphs (a) and (c) by removing the
phrase ``Complete EHRs and''.
Sec. 170.314 [Removed and Reserved]
0
14. Remove and reserve Sec. 170.314.
0
15. Amend Sec. 170.315:
0
a. By removing and reserving paragraphs (a)(6) through (8);
0
b. In paragraph (a)(9)(ii)(B)(1)(iii) by removing ``medication
allergy'' and adding in its place ``allergy and intolerance'';
0
c. In paragraph (a)(9)(ii)(B)(2) by removing ``medication allergies''
and adding in its place ``allergies and intolerance'';
0
d. By removing and reserving paragraph (a)(11);
0
e. In paragraphs (b)(1)(ii)(A) introductory text, (b)(1)(ii)(A)(2) and
(3), (b)(1)(ii)(B), and (b)(1)(ii)(C) introductory text, by removing
the reference ``Sec. 170.205(a)(3) and Sec. 170.205(a)(4)'' and
adding in its place the reference ``Sec. 170.205(a)(3), (4), and
(5)'';
0
f. In paragraph (b)(1)(iii) introductory text, by removing the
reference ``Sec. 170.205(a)(4)'' and adding in its place the reference
``Sec. 170.205(a)(3), (4), and (5)'';
0
g. By revising paragraphs (b)(1)(iii)(A) and (b)(2) and (3);
0
h. By removing and reserving paragraphs (b)(4) and (5);
0
i. By revising paragraphs (b)(7) through (9);
0
j. By adding paragraph (b)(10);
0
k. By revising paragraph (c)(3);
0
l. By adding paragraphs (d)(12) and (13);
0
m. By revising paragraphs (e)(1)(i)(A)(1) through (5);
0
n. By adding paragraphs (e)(1)(i)(A)(6) and (7)
0
o. In paragraph (e)(1)(i)(B)(1)(ii) and (e)(1)(i)(B)(2) introductory
text, by removing the reference ``Sec. 170.205(a)(4)'' and adding in
its place the reference ``Sec. 170.205(a)(4) and (5)'';
0
p. By removing and reserving paragraph (e)(1)(ii)(B);
0
q. By revising paragraphs (f)(5)(iii)(B)(1) through (4),
0
r. By adding paragraph (f)(5)(iii)(B)(5);
0
s. By revising paragraphs (g)(1) and (2), (g)(3)(i), and (g)(6)
0
t. By removing paragraphs (g)(7)(ii)(A)(3) and (g)(8)(ii)(A)(3);
0
u. By revising paragraph (g)(9)(i)(A);
0
v. By removing paragraph (g)(9)(ii)(A)(3); and
0
w. By adding paragraph (g)(10).
The revisions and additions read as follows:
Sec. 170.315 2015 Edition health IT certification criteria.
* * * * *
(b) * * *
(1) * * *
[[Page 25942]]
(iii) * * *
(A)(1) The data classes expressed in the standard in Sec. 170.213
and in accordance with Sec. 170.205(a)(4), (5), and paragraphs
(b)(1)(iii)(A)(3)(i) through (iii) of this section, or
(2) The Common Clinical Data Set in accordance with Sec.
170.205(a)(4) and paragraph (b)(1)(iii)(A)(3)(i) through (iv) of this
section for the period until May 2, 2022, and
(3) The following data classes:
(i) Assessment and plan of treatment. In accordance with the
``Assessment and Plan Section (V2)'' of the standard specified in Sec.
170.205(a)(4); or in accordance with the ``Assessment Section (V2)''
and ``Plan of Treatment Section (V2)'' of the standard specified in
Sec. 170.205(a)(4).
(ii) Goals. In accordance with the ``Goals Section'' of the
standard specified in Sec. 170.205(a)(4).
(iii) Health concerns. In accordance with the ``Health Concerns
Section'' of the standard specified in Sec. 170.205(a)(4).
(iv) Unique device identifier(s) for a patient's implantable
device(s). In accordance with the ``Product Instance'' in the
``Procedure Activity Procedure Section'' of the standard specified in
Sec. 170.205(a)(4).
(2) Clinical information reconciliation and incorporation--(i)
General requirements. Paragraphs (b)(2)(ii) and (iii) of this section
must be completed based on the receipt of a transition of care/referral
summary formatted in accordance with the standards adopted in Sec.
170.205(a)(3) through (5) using the Continuity of Care Document,
Referral Note, and (inpatient setting only) Discharge Summary document
templates on and after May 2, 2022.
(ii) Correct patient. Upon receipt of a transition of care/referral
summary formatted according to the standards adopted Sec.
170.205(a)(3) through (5), technology must be able to demonstrate that
the transition of care/referral summary received can be properly
matched to the correct patient.
(iii) Reconciliation. Enable a user to reconcile the data that
represent a patient's active medication list, allergies and intolerance
list, and problem list as follows. For each list type:
(A) Simultaneously display (i.e., in a single view) the data from
at least two sources in a manner that allows a user to view the data
and their attributes, which must include, at a minimum, the source and
last modification date.
(B) Enable a user to create a single reconciled list of each of the
following: Medications; Allergies and Intolerances; and problems.
(C) Enable a user to review and validate the accuracy of a final
set of data.
(D) Upon a user's confirmation, automatically update the list, and
incorporate the following data expressed according to the specified
standard(s) on and after May 2, 2022:
(1) Medications. At a minimum, the version of the standard
specified in Sec. 170.213;
(2) Allergies and intolerance. At a minimum, the version of the
standard specified in Sec. 170.213; and
(3) Problems. At a minimum, the version of the standard specified
in Sec. 170.213.
(iv) System verification. Based on the data reconciled and
incorporated, the technology must be able to create a file formatted
according to the standard specified in Sec. 170.205(a)(4) using the
Continuity of Care Document template and the standard specified in
Sec. 170.205(a)(5) on and after May 2, 2022.
(3) Electronic prescribing. (i) For technology certified prior to
May 2, 2022, subject to the real world testing provisions at Sec.
170.405(b)(5),
(A) Enable a user to perform the following prescription-related
electronic transactions in accordance with, at a minimum, the version
of the standard specified in Sec. 170.207(d)(3) as follows:
(1) Create new prescriptions (NEWRX).
(2) Change prescriptions (RXCHG, CHGRES).
(3) Cancel prescriptions (CANRX, CANRES).
(4) Refill prescriptions (REFREQ, REFRES).
(5) Receive fill status notifications (RXFILL).
(6) Request and receive medication history information (RXHREQ,
RXHRES).
(B) For each transaction listed in paragraph (b)(3)(i)(A) of this
section, the technology must be able to receive and transmit the reason
for the prescription using the diagnosis elements in the DRU Segment.
(C) Optional: For each transaction listed in paragraph (b)(3)(i)(A)
of this section, the technology must be able to receive and transmit
the reason for prescription using the indication elements in the SIG
Segment.
(D) Limit a user's ability to prescribe all oral liquid medications
in only metric standard units of mL (i.e., not cc).
(E) Always insert leading zeroes before the decimal point for
amounts less than one and must not allow trailing zeroes after a
decimal point when a user prescribes medications.
(ii) For technology certified subsequent to June 30, 2020:
(A) Enable a user to perform the following prescription-related
electronic transactions in accordance with the standard specified in
Sec. 170.205(b)(1) and, at a minimum, the version of the standard
specified in Sec. 170.207(d)(3) as follows:
(1) Create new prescriptions (NewRx).
(2) Request and respond to change prescriptions (RxChangeRequest,
RxChangeResponse).
(3) Request and respond to cancel prescriptions (CancelRx,
CancelRxResponse).
(4) Request and respond to renew prescriptions (RxRenewalRequest,
RxRenewalResponse).
(5) Receive fill status notifications (RxFill).
(6) Request and receive medication history (RxHistoryRequest,
RxHistoryResponse).
(7) Relay acceptance of a transaction back to the sender (Status).
(8) Respond that there was a problem with the transaction (Error).
(9) Respond that a transaction requesting a return receipt has been
received (Verify).
(B) Optionally, enable a user to perform the following
prescription-related electronic transactions in accordance with the
standard specified in Sec. 170.205(b)(1) and, at a minimum, the
version of the standard specified in Sec. 170.207(d)(3) as follows:
(1) Create and respond to new prescriptions (NewRxRequest,
NewRxResponseDenied).
(2) Receive fill status notifications (RxFillIndicator).
(3) Ask the Mailbox if there are any transactions (GetMessage).
(4) Request to send an additional supply of medication (Resupply).
(5) Communicate drug administration events (DrugAdministration).
(6) Request and respond to transfer one or more prescriptions
between pharmacies (RxTransferRequest, RxTransferResponse,
RxTransferConfirm).
(7) Recertify the continued administration of a medication order
(Recertification).
(8) Complete Risk Evaluation and Mitigation Strategy (REMS)
transactions (REMSInitiationRequest, REMSInitiationResponse,
REMSRequest, and REMSResponse).
(9) Electronic prior authorization transactions
(PAInitiationRequest, PAInitiationResponse, PARequest, PAResponse,
PAAppealRequest, PAAppealResponse, PACancelRequest, and
PACancelResponse).
(C) For the following prescription-related transactions, the
technology must be able to receive and transmit the
[[Page 25943]]
reason for prescription using the diagnosis elements:
or :
(1) Required transactions:
(i) Create new prescriptions (NewRx).
(ii) Request and respond to change prescriptions (RxChangeRequest,
RxChangeResponse).
(iii) Cancel prescriptions (CancelRx).
(iv) Request and respond to renew prescriptions (RxRenewalRequest,
RxRenewalResponse).
(v) Receive fill status notifications (RxFill).
(vi) Receive medication history (RxHistoryResponse).
(2) Optional transactions:
(i) Request to send an additional supply of medication (Resupply)
(ii) Request and respond to transfer one or more prescriptions
between pharmacies (RxTransferRequest, RxTransferResponse)
(iii) Complete Risk Evaluation and Mitigation Strategy (REMS)
transactions (REMSInitiationRequest, REMSInitiationResponse,
REMSRequest, and REMSResponse).
(iv) Electronic prior authorization (ePA) transactions
(PAInitiationRequest, PAInitiationResponse, PARequest, PAResponse,
PAAppealRequest, PAAppealResponse and PACancelRequest,
PACancelResponse).
(D) Optional: For each transaction listed in paragraph
(b)(3)(ii)(C) of this section, the technology must be able to receive
and transmit reason for prescription using the
element in the SIG segment.
(E) Limit a user's ability to prescribe all oral liquid medications
in only metric standard units of mL (i.e., not cc).
(F) Always insert leading zeroes before the decimal point for
amounts less than one and must not allow trailing zeroes after a
decimal point when a user prescribes medications.
* * * * *
(7) Security tags--summary of care--send. Enable a user to create a
summary record formatted in accordance with the standard adopted in
Sec. 170.205(a)(4) that is tagged as restricted and subject to
restrictions on re-disclosure according to the standard adopted in
Sec. 170.205(o)(1) at the:
(i) Document, section, and entry (data element) level; or
(ii) Document level for the period until May 2, 2022.
(8) Security tags--summary of care--receive. (i) Enable a user to
receive a summary record that is formatted in accordance with the
standard adopted in Sec. 170.205(a)(4) that is tagged as restricted
and subject to restrictions on re-disclosure according to the standard
adopted in Sec. 170.205(o)(1) at the:
(A) Document, section, and entry (data element) level; or
(B) Document level for the period until May 2, 2022; and
(ii) Preserve privacy markings to ensure fidelity to the tagging
based on consent and with respect to sharing and re-disclosure
restrictions.
(9) Care plan. Enable a user to record, change, access, create, and
receive care plan information in accordance with:
(i) The Care Plan document template, including the Health Status
Evaluations and Outcomes Section and Interventions Section (V2), in the
standard specified in Sec. 170.205(a)(4); and
(ii) The standard in Sec. 170.205(a)(5)) on and after May 2, 2022.
(10) Electronic Health Information export--(i) Single patient
electronic health information export. (A) Enable a user to timely
create an export file(s) with all of a single patient's electronic
health information that can be stored at the time of certification by
the product, of which the Health IT Module is a part.
(B) A user must be able to execute this capability at any time the
user chooses and without subsequent developer assistance to operate.
(C) Limit the ability of users who can create export file(s) in at
least one of these two ways:
(1) To a specific set of identified users
(2) As a system administrative function.
(D) The export file(s) created must be electronic and in a
computable format.
(E) The publicly accessible hyperlink of the export's format must
be included with the exported file(s).
(ii) Patient population electronic health information export.
Create an export of all the electronic health information that can be
stored at the time of certification by the product, of which the Health
IT Module is a part.
(A) The export created must be electronic and in a computable
format.
(B) The publicly accessible hyperlink of the export's format must
be included with the exported file(s).
(iii) Documentation. The export format(s) used to support
paragraphs (b)(10)(i) and (ii) of this section must be kept up-to-date.
(c) * * *
(3) Clinical quality measures--report. Enable a user to
electronically create a data file for transmission of clinical quality
measurement data in accordance with the applicable implementation
specifications specified by the CMS implementation guides for Quality
Reporting Document Architecture (QRDA), category I, for inpatient
measures in Sec. 170.205(h)(3) and CMS implementation guide for QRDA,
category III for ambulatory measures in Sec. 170.205 (k)(3).
* * * * *
(d) * * *
(12) Encrypt authentication credentials. Health IT developers must
make one of the following attestations and may provide the specified
accompanying information, where applicable:
(i) Yes--the Health IT Module encrypts stored authentication
credentials in accordance with standards adopted in Sec.
170.210(a)(2).
(ii) No--the Health IT Module does not encrypt stored
authentication credentials. When attesting ``no,'' the health IT
developer may explain why the Health IT Module does not support
encrypting stored authentication credentials.
(13) Multi-factor authentication. Health IT developers must make
one of the following attestations and, as applicable, provide the
specified accompanying information:
(i) Yes--the Health IT Module supports the authentication, through
multiple elements, of the user's identity with the use of industry-
recognized standards. When attesting ``yes,'' the health IT developer
must describe the use cases supported.
(ii) No--the Health IT Module does not support authentication,
through multiple elements, of the user's identity with the use of
industry-recognized standards. When attesting ``no,'' the health IT
developer may explain why the Health IT Module does not support
authentication, through multiple elements, of the user's identify with
the use of industry-recognized standards.
(e) * * *
(1) * * *
(i) * * *
(A) * * *
(1) The data classes expressed in the standards in Sec. 170.213
(which should be in their English (i.e., non-coded) representation if
they associate with a vocabulary/code set), and in accordance with
Sec. 170.205(a)(4) and (a)(5), and paragraphs (e)(1)(i)(A)(3)(i)
through (iii) of this section, or
(2) The Common Clinical Data Set in accordance with Sec.
170.205(a)(4) and paragraphs (e)(1)(i)(A)(3)(i) through (iv) of this
section for the period until May 2, 2022.
(3) The following data classes:
(i) Assessment and plan of treatment. In accordance with the
``Assessment and Plan Section (V2)'' of the standard specified in Sec.
170.205(a)(4); or in accordance with the ``Assessment
[[Page 25944]]
Section (V2)'' and ``Plan of Treatment Section (V2)'' of the standard
specified in Sec. 170.205(a)(4).
(ii) Goals. In accordance with the ``Goals Section'' of the
standard specified in Sec. 170.205(a)(4).
(iii) Health concerns. In accordance with the ``Health Concerns
Section'' of the standard specified in Sec. 170.205(a)(4).
(iv) Unique device identifier(s) for a patient's implantable
device(s). In accordance with the ``Product Instance'' in the
``Procedure Activity Procedure Section'' of the standards specified in
Sec. 170.205(a)(4).
(4) Ambulatory setting only. Provider's name and office contact
information.
(5) Inpatient setting only. Admission and discharge dates and
locations; discharge instructions; and reason(s) for hospitalization.
(6) Laboratory test report(s). Laboratory test report(s),
including:
(i) The information for a test report as specified all the data
specified in 42 CFR 493.1291(c)(1) through (7);
(ii) The information related to reference intervals or normal
values as specified in 42 CFR 493.1291(d); and
(iii) The information for corrected reports as specified in 42 CFR
493.1291(k)(2).
(7) Diagnostic image report(s).
* * * * *
(f) * * *
(5) * * *
(iii) * * *
(B) * * *
(1) The data classes expressed in the standards in Sec. 170.213,
and in accordance with Sec. 170.205(a)(4) and (5), or
(2) The Common Clinical Data Set in accordance with Sec.
170.205(a)(4) for the period until May 2, 2022.
(3) Encounter diagnoses. Formatted according to at least one of the
following standards:
(i) The standard specified in Sec. 170.207(i).
(ii) At a minimum, the version of the standard specified in Sec.
170.207(a)(4).
(4) The provider's name, office contact information, and reason for
visit.
(5) An identifier representing the row and version of the trigger
table that triggered the case report.
* * * * *
(g) Design and performance--(1) Automated numerator recording. For
each Promoting Interoperability Programs percentage-based measure,
technology must be able to create a report or file that enables a user
to review the patients or actions that would make the patient or action
eligible to be included in the measure's numerator. The information in
the report or file created must be of sufficient detail such that it
enables a user to match those patients or actions to meet the measure's
denominator limitations when necessary to generate an accurate
percentage.
(2) Automated measure calculation. For each Promoting
Interoperability Programs percentage-based measure that is supported by
a capability included in a technology, record the numerator and
denominator and create a report including the numerator, denominator,
and resulting percentage associated with each applicable measure.
(3) * * *
(i) User-centered design processes must be applied to each
capability technology includes that is specified in the following
certification criteria: Paragraphs (a)(1) through (5), (9), and (14),
and (b)(2) and (3).
* * * * *
(6) Consolidated CDA creation performance. The following technical
and performance outcomes must be demonstrated related to Consolidated
CDA creation. The capabilities required under paragraphs (g)(6)(i)
through (v) of this section can be demonstrated in tandem and do not
need to be individually addressed in isolation or sequentially.
(i) This certification criterion's scope includes:
(A) The data classes expressed in the standard in Sec. 170.213,
and in accordance with Sec. 170.205(a)(4) and (5) and paragraphs
(g)(6)(i)(C)(1) through (3) of this section; or
(B) The Common Clinical Data Set in accordance with Sec.
170.205(a)(4) and paragraphs (g)(6)(i)(C)(1) through (4) of this
section for the period until May 2, 2022.
(C) The following data classes:
(1) Assessment and plan of treatment. In accordance with the
``Assessment and Plan Section (V2)'' of the standard specified in Sec.
170.205(a)(4); or in accordance with the ``Assessment Section (V2)''
and ``Plan of Treatment Section (V2)'' of the standard specified in
Sec. 170.205(a)(4).
(2) Goals. In accordance with the ``Goals Section'' of the standard
specified in Sec. 170.205(a)(4).
(3) Health concerns. In accordance with the ``Health Concerns
Section'' of the standard specified in Sec. 170.205(a)(4).
(4) Unique device identifier(s) for a patient's implantable
device(s). In accordance with the ``Product Instance'' in the
``Procedure Activity Procedure Section'' of the standard specified in
Sec. 170.205(a)(4).
(ii) Reference C-CDA match. (A) For health IT certified to
(g)(6)(i)(A) of this section, create a data file formatted in
accordance with the standard adopted in Sec. 170.205(a)(4) and (5)
that matches a gold-standard, reference data file.
(B) For health IT certified to (g)(6)(i)(B) of this section, create
a data file formatted in accordance with the standard adopted in Sec.
170.205(a)(4) that matches a gold-standard, reference data file.
(iii) Document-template conformance. (A) For health IT certified to
(g)(6)(i)(A) of this section, create a data file formatted in
accordance with the standard adopted in Sec. 170.205(a)(4) and (5)
that demonstrates a valid implementation of each document template
applicable to the certification criterion or criteria within the scope
of the certificate sought.
(B) For health IT certified to (g)(6)(i)(B) of this section, create
a data file formatted in accordance with the standard adopted in Sec.
170.205(a)(4) that demonstrates a valid implementation of each document
template applicable to the certification criterion or criteria within
the scope of the certificate sought.
(iv) Vocabulary conformance. (A) For health IT certified to
(g)(6)(i)(A) of this section, create a data file formatted in
accordance with the standard adopted in Sec. 170.205(a)(4) and (5)
that demonstrates the required vocabulary standards (and value sets)
are properly implemented.
(B) For health IT certified to (g)(6)(i)(B) of this section, create
a data file formatted in accordance with the standard adopted in Sec.
170.205(a)(4) that demonstrates the required vocabulary standards (and
value sets) are properly implemented.
(v) Completeness verification. Create a data file for each of the
applicable document templates referenced in paragraph (g)(6)(iii) of
this section without the omission of any of the data included in either
paragraph (g)(6)(i)(A) or (B) of this section, as applicable.
* * * * *
(9) * * *
(i) * * *
(A)(1) Respond to requests for patient data (based on an ID or
other token) for all of the data classes expressed in the standards in
Sec. 170.213 at one time and return such data (according to the
specified standards, where applicable) in a summary record formatted in
accordance with Sec. 170.205(a)(4) and (5) following the CCD document
template, and as specified in paragraphs (g)(9)(i)(A)(3)(i) through
(iii) of this section, or
[[Page 25945]]
(2) The Common Clinical Data Set in accordance with paragraphs
(g)(9)(i)(A)(3)(i) through (iv) of this section for the period until
May 2, 2022, and
(3) The following data classes:
(i) Assessment and plan of treatment. In accordance with the
``Assessment and Plan Section (V2)'' of the standards specified in
Sec. 170.205(a)(4); or in accordance with the ``Assessment Section
(V2)'' and ``Plan of Treatment Section (V2)'' of the standards
specified in Sec. 170.205(a)(4).
(ii) Goals. In accordance with the ``Goals Section'' of the
standards specified in Sec. 170.205(a)(4).
(iii) Health concerns. In accordance with the ``Health Concerns
Section'' of the standards specified in Sec. 170.205(a)(4).
(iv) Unique device identifier(s) for a patient's implantable
device(s). In accordance with the ``Product Instance'' in the
``Procedure Activity Procedure Section'' of the standards specified in
Sec. 170.205(a)(4).
* * * * *
(10) Standardized API for patient and population services. The
following technical outcomes and conditions must be met through the
demonstration of application programming interface technology.
(i) Data response. (A) Respond to requests for a single patient's
data according to the standard adopted in Sec. 170.215(a)(1) and
implementation specification adopted in Sec. 170.215(a)(2), including
the mandatory capabilities described in ``US Core Server
CapabilityStatement,'' for each of the data included in the standard
adopted in Sec. 170.213. All data elements indicated as ``mandatory''
and ``must support'' by the standards and implementation specifications
must be supported.
(B) Respond to requests for multiple patients' data as a group
according to the standard adopted in Sec. 170.215(a)(1), and
implementation specifications adopted in Sec. 170.215(a)(2) and (4),
for each of the data included in the standard adopted in Sec. 170.213.
All data elements indicated as ``mandatory'' and ``must support'' by
the standards and implementation specifications must be supported.
(ii) Supported search operations. (A) Respond to search requests
for a single patient's data consistent with the search criteria
included in the implementation specification adopted in Sec.
170.215(a)(2), specifically the mandatory capabilities described in
``US Core Server CapabilityStatement.''
(B) Respond to search requests for multiple patients' data
consistent with the search criteria included in the implementation
specification adopted in Sec. 170.215(a)(4).
(iii) Application registration. Enable an application to register
with the Health IT Module's ``authorization server.''
(iv) Secure connection. (A) Establish a secure and trusted
connection with an application that requests data for patient and user
scopes in accordance with the implementation specifications adopted in
Sec. 170.215(a)(2) and (3).
(B) Establish a secure and trusted connection with an application
that requests data for system scopes in accordance with the
implementation specification adopted in Sec. 170.215(a)(4).
(v) Authentication and authorization--(A) Authentication and
authorization for patient and user scopes--(1) First time connections--
(i) Authentication and authorization must occur during the process of
granting access to patient data in accordance with the implementation
specification adopted in Sec. 170.215(a)(3) and standard adopted in
Sec. 170.215(b).
(ii) An application capable of storing a client secret must be
issued a refresh token valid for a period of no less than three months.
(2) Subsequent connections. (i) Access must be granted to patient
data in accordance with the implementation specification adopted in
Sec. 170.215(a)(3) without requiring re-authorization and re-
authentication when a valid refresh token is supplied by the
application.
(ii) An application capable of storing a client secret must be
issued a new refresh token valid for a new period of no less than three
months.
(B) Authentication and authorization for system scopes.
Authentication and authorization must occur during the process of
granting an application access to patient data in accordance with the
``SMART Backend Services: Authorization Guide'' section of the
implementation specification adopted in Sec. 170.215(a)(4) and the
application must be issued a valid access token.
(vi) Patient authorization revocation. A Health IT Module's
authorization server must be able to revoke an authorized application's
access at a patient's direction.
(vii) Token introspection. A Health IT Module's authorization
server must be able to receive and validate tokens it has issued.
(viii) Documentation. (A) The API(s) must include complete
accompanying documentation that contains, at a minimum:
(1) API syntax, function names, required and optional parameters
supported and their data types, return variables and their types/
structures, exceptions and exception handling methods and their
returns.
(2) The software components and configurations that would be
necessary for an application to implement in order to be able to
successfully interact with the API and process its response(s).
(3) All applicable technical requirements and attributes necessary
for an application to be registered with a Health IT Module's
authorization server.
(B) The documentation used to meet paragraph (g)(10)(viii)(A) of
this section must be available via a publicly accessible hyperlink
without any preconditions or additional steps.
* * * * *
0
16. Add subpart D to part 170 to read as follows:
Subpart D--Conditions and Maintenance of Certification Requirements for
Health IT Developers
Sec.
170.400 Basis and scope.
170.401 Information blocking.
170.402 Assurances.
170.403 Communications.
170.404 Application programming interfaces.
170.405 Real world testing.
170.406 Attestations.
Subpart D--Conditions and Maintenance of Certification Requirements
for Health IT Developers
Sec. 170.400 Basis and scope.
This subpart implements section 3001(c)(5)(D) of the Public Health
Service Act by setting forth certain Conditions and Maintenance of
Certification requirements for health IT developers participating in
the ONC Health IT Certification Program.
Sec. 170.401 Information blocking.
(a) Condition of Certification requirement. A health IT developer
must not take any action that constitutes information blocking as
defined in 42 U.S.C. 300jj-52 and Sec. 171.103 on or after November 2,
2020.
(b) [Reserved]
Sec. 170.402 Assurances.
(a) Condition of Certification requirement. (1) A health IT
developer must provide assurances satisfactory to the Secretary that
the health IT developer will not take any action that constitutes
information blocking as defined in 42 U.S.C. 300jj-52 and Sec. 171.103
on and after November 2, 2020, unless for legitimate purposes as
specified by the Secretary; or any other action that may inhibit the
appropriate exchange, access, and use of electronic health information.
[[Page 25946]]
(2) A health IT developer must ensure that its health IT certified
under the ONC Health IT Certification Program conforms to the full
scope of the certification criteria.
(3) A health IT developer must not take any action that could
interfere with a user's ability to access or use certified capabilities
for any purpose within the full scope of the technology's
certification.
(4) A health IT developer of a certified Health IT Module that is
part of a heath IT product which electronically stores EHI must certify
to the certification criterion in Sec. 170.315(b)(10).
(b) Maintenance of Certification requirements. (1) A health IT
developer must retain all records and information necessary to
demonstrate initial and ongoing compliance with the requirements of the
ONC Health IT Certification Program for:
(i) A period of 10 years beginning from the date a developer's
Health IT Module(s) is first certified under the Program; or
(ii) If for a shorter period of time, a period of 3 years from the
effective date that removes all of the certification criteria to which
the developer's health IT is certified from the Code of Federal
Regulations.
(2)(i) Within 36 months of May 1, 2020, a health IT developer that
must comply with the requirements of paragraph (a)(4) of this section
must provide all of its customers of certified health IT with the
health IT certified to the certification criterion in Sec.
170.315(b)(10).
(ii) On and after 36 months from May 1, 2020, a health IT developer
that must comply with the requirements of paragraph (a)(4) of this
section must provide all of its customers of certified health IT with
the health IT certified to the certification criterion in Sec.
170.315(b)(10).
Sec. 170.403 Communications.
(a) Condition of Certification requirements. (1) A health IT
developer may not prohibit or restrict any communication regarding--
(i) The usability of its health IT;
(ii) The interoperability of its health IT;
(iii) The security of its health IT;
(iv) Relevant information regarding users' experiences when using
its health IT;
(v) The business practices of developers of health IT related to
exchanging electronic health information; and
(vi) The manner in which a user of the health IT has used such
technology.
(2) A health IT developer must not engage in any practice that
prohibits or restricts a communication regarding the subject matters
enumerated in paragraph (a)(1) of this section, unless the practice is
specifically permitted by this paragraph and complies with all
applicable requirements of this paragraph.
(i) Unqualified protection for certain communications. A health IT
developer must not prohibit or restrict any person or entity from
communicating any information whatsoever (including proprietary
information, confidential information, and intellectual property) when
the communication is about one or more of the subject matters
enumerated in paragraph (a)(1) of this section and is made for any of
the following purposes:
(A) Making a disclosure required by law;
(B) Communicating information about adverse events, hazards, and
other unsafe conditions to government agencies, health care
accreditation organizations, and patient safety organizations;
(C) Communicating information about cybersecurity threats and
incidents to government agencies;
(D) Communicating information about information blocking and other
unlawful practices to government agencies; or
(E) Communicating information about a health IT developer's failure
to comply with a Condition of Certification requirement, or with any
other requirement of this part, to ONC or an ONC-ACB.
(ii) Permitted prohibitions and restrictions. For communications
about one or more of the subject matters enumerated in paragraph (a)(1)
of this section that is not entitled to unqualified protection under
paragraph (a)(2)(i) of this section, a health IT developer may prohibit
or restrict communications only as expressly permitted by paragraphs
(a)(2)(ii)(A) through (E) of this section.
(A) Developer employees and contractors. (1) A health IT developer
may prohibit or restrict the communications of the developer's
employees or contractors.
(2) A self-developer must not prohibit or restrict communications
of users of their health IT who are also employees or contractors.
(B) Non-user-facing aspects of health IT. A health IT developer may
prohibit or restrict communications that disclose information about
non-user-facing aspects of the developer's health IT.
(C) Intellectual property. A health IT developer may prohibit or
restrict communications that involve the use or disclosure of
intellectual property existing in the developer's health IT (including
third-party intellectual property), provided that any prohibition or
restriction imposed by a developer must be no broader than necessary to
protect the developer's legitimate intellectual property interests and
consistent with all other requirements of paragraph (a)(2)(ii) of this
section. A restriction or prohibition is deemed broader than necessary
and inconsistent with the requirements of paragraph (a)(2)(ii) of this
section if it would restrict or preclude a public display of a portion
of a work subject to copyright protection (without regard to whether
the copyright is registered) that would reasonably constitute a ``fair
use'' of that work.
(D) Screenshots and video. A health IT developer may require
persons who communicate screenshots or video to--
(1) Not alter the screenshots or video, except to annotate the
screenshots or video or resize the screenshots or video;
(2) Limit the sharing of screenshots to the relevant number of
screenshots needed to communicate about the health IT regarding one or
more of the six subject areas in paragraph (a)(1) of this section; and
(3) Limit the sharing of video to:
(i) The relevant amount of video needed to communicate about the
health IT regarding one or more of the six subject areas in paragraph
(a)(1) of this section; and
(ii) Only videos that address temporal matters that cannot be
communicated through screenshots or other forms of communication.
(E) Pre-market testing and development. A health IT developer may
prohibit or restrict communications that disclose information or
knowledge solely acquired in the course of participating in pre-market
product development and testing activities carried out for the benefit
of the developer or for the joint benefit of the developer and
communicator. A developer must not, once the subject health IT is
released or marketed for purposes other than product development and
testing, and subject to the permitted prohibitions and restrictions
described in paragraph (a)(2)(ii) of this section, prohibit or restrict
communications about matters enumerated in paragraph (a)(1) of this
section.
(b) Maintenance of Certification requirements--(1) Notice. Health
IT developers must issue a written notice to all customers and those
with which it has contracts or agreements containing provisions that
contravene paragraph (a) of this section annually, beginning in
calendar year 2020, until
[[Page 25947]]
paragraph (b)(2)(ii) of this section is fulfilled, stating that any
communication or contract provision that contravenes paragraph (a) of
this section will not be enforced by the health IT developer.
(2) Contracts and agreements. (i) A health IT developer must not
establish, renew, or enforce any contract or agreement that contravenes
paragraph (a) of this section.
(ii) If a health IT developer has a contract or agreement in
existence as of November 2, 2020, that contravenes paragraph (a) of
this section, then the developer must amend the contract or agreement
to remove or void the contractual provision that contravenes paragraph
(a) of this section whenever the contract is next modified for other
reasons or renewed.
(c) Communication, defined. ``Communication'' as used in this
section means any communication, irrespective of the form or medium.
The term includes visual communications, such as screenshots and video.
Sec. 170.404 Application programming interfaces.
The following Condition and Maintenance of Certification
requirements apply to developers of Health IT Modules certified to any
of the certification criteria adopted in Sec. 170.315(g)(7) through
(10).
(a) Condition of certification requirements--(1) General. A
Certified API Developer must publish APIs and allow electronic health
information from such technology to be accessed, exchanged, and used
without special effort through the use of APIs or successor technology
or standards, as provided for under applicable law, including providing
access to all data elements of a patient's electronic health record to
the extent permissible under applicable privacy laws.
(2) Transparency conditions--(i) Complete business and technical
documentation. A Certified API Developer must publish complete business
and technical documentation, including the documentation described in
paragraph (a)(2)(ii) of this section, via a publicly accessible
hyperlink that allows any person to directly access the information
without any preconditions or additional steps.
(ii) Terms and conditions--(A) Material information. A Certified
API Developer must publish all terms and conditions for its certified
API technology, including any fees, restrictions, limitations,
obligations, registration process requirements, or other similar
requirements that would be:
(1) Needed to develop software applications to interact with the
certified API technology;
(2) Needed to distribute, deploy, and enable the use of software
applications in production environments that use the certified API
technology;
(3) Needed to use software applications, including to access,
exchange, and use electronic health information by means of the
certified API technology;
(4) Needed to use any electronic health information obtained by
means of the certified API technology;
(5) Used to verify the authenticity of API Users; and
(6) Used to register software applications.
(B) API fees. Any and all fees charged by a Certified API Developer
for the use of its certified API technology must be described in
detailed, plain language. The description of the fees must include all
material information, including but not limited to:
(1) The persons or classes of persons to whom the fee applies;
(2) The circumstances in which the fee applies; and
(3) The amount of the fee, which for variable fees must include the
specific variable(s) and methodology(ies) that will be used to
calculate the fee.
(3) Fees conditions--(i) General conditions--(A) All fees. All fees
related to certified API technology not otherwise permitted by this
section are prohibited from being imposed by a Certified API Developer.
The permitted fees in paragraphs (a)(3)(ii) and (iv) of this section
may include fees that result in a reasonable profit margin in
accordance with Sec. 171.302.
(B) Permitted fees requirements. For all permitted fees, a
Certified API Developer must:
(1) Ensure that such fees are based on objective and verifiable
criteria that are uniformly applied to all similarly situated API
Information Sources and API Users;
(2) Ensure that such fees imposed on API Information Sources are
reasonably related to the Certified API Developer's costs to supply
certified API technology to, and if applicable, support certified API
technology for, API Information Sources;
(3) Ensure that such fees to supply and, if applicable, support
certified API technology are reasonably allocated among all similarly
situated API Information Sources; and
(4) Ensure that such fees are not based on whether API Information
Sources or API Users are competitors, potential competitors, or will be
using the certified API technology in a way that facilitates
competition with the Certified API Developer.
(C) Prohibited fees. A Certified API Developer is prohibited from
charging fees for the following:
(1) Costs associated with intangible assets other than actual
development or acquisition costs of such assets;
(2) Opportunity costs unrelated to the access, exchange, or use of
electronic health information; and
(3) The permitted fees in this section cannot include any costs
that led to the creation of intellectual property if the actor charged
a royalty for that intellectual property pursuant to Sec. 171.303 and
that royalty included the development costs for the creation of the
intellectual property.
(D) Record-keeping requirements. A Certified API Developer must
keep for inspection detailed records of any fees charged with respect
to the certified API technology, the methodology(ies) used to calculate
such fees, and the specific costs to which such fees are attributed.
(ii) Permitted fee--development, deployment, and upgrades. A
Certified API Developer is permitted to charge fees to an API
Information Source to recover the costs reasonably incurred by the
Certified API Developer to develop, deploy, and upgrade certified API
technology.
(iii) Permitted fee--recovering API usage costs. A Certified API
Developer is permitted to charge fees to an API Information Source
related to the use of certified API technology. The fees must be
limited to the recovery of incremental costs reasonably incurred by the
Certified API Developer when it hosts certified API technology on
behalf of the API Information Source.
(iv) Permitted fee--value-added services. A Certified API Developer
is permitted to charge fees to an API User for value-added services
related to certified API technology, so long as such services are not
necessary to efficiently and effectively develop and deploy production-
ready software that interacts with certified API technology.
(4) Openness and pro-competitive conditions; general condition. A
Certified API Developer must grant an API Information Source the
independent ability to permit an API User to interact with the
certified API technology deployed by the API Information Source.
(i) Non-discrimination. (A) A Certified API Developer must provide
certified API technology to an API Information Source on terms that are
no less favorable than it provides to itself and its own customers,
suppliers, partners, and other persons with whom it has a business
relationship.
[[Page 25948]]
(B) The terms on which a Certified API Developer provides certified
API technology must be based on objective and verifiable criteria that
are uniformly applied to all substantially similar or similarly
situated classes of persons and requests.
(C) A Certified API Developer must not offer different terms or
services based on:
(1) Whether a competitive relationship exists or would be created;
(2) The revenue or other value that another party may receive from
using the API technology.
(ii) Rights to access and use certified API technology--(A) Rights
that must be granted. A Certified API Developer must have and, upon
request, must grant to API Information Sources and API Users all rights
that may be reasonably necessary to:
(1) Access and use the Certified API Developer's certified API
technology in a production environment;
(2) Develop products and services that are designed to interact
with the Certified API Developer's certified API technology; and
(3) Market, offer, and distribute products and services associated
with the Certified API Developer's certified API technology.
(B) Prohibited conduct. A Certified API Developer is prohibited
from conditioning the receipt of the rights described in paragraph
(a)(4)(ii)(A) of this section on:
(1) Receiving a fee, including but not limited to a license fee,
royalty, or revenue-sharing arrangement;
(2) Agreeing to not compete with the Certified API Developer in any
product, service, or market;
(3) Agreeing to deal exclusively with the Certified API Developer
in any product, service, or market;
(4) Obtaining additional licenses, products, or services that are
not related to or can be unbundled from the certified API technology;
(5) Licensing, granting, assigning, or transferring any
intellectual property to the Certified API Developer;
(6) Meeting any Certified API Developer-specific testing or
certification requirements; and.
(7) Providing the Certified API Developer or its technology with
reciprocal access to application data.
(iii) Service and support obligations. A Certified API Developer
must provide all support and other services reasonably necessary to
enable the effective development, deployment, and use of certified API
technology by API Information Sources and API Users in production
environments.
(A) Changes and updates to certified API technology. A Certified
API Developer must make reasonable efforts to maintain the
compatibility of its certified API technology and to otherwise avoid
disrupting the use of certified API technology in production
environments.
(B) Changes to terms and conditions. Except as exigent
circumstances require, prior to making changes to its certified API
technology or to the terms and conditions thereof, a Certified API
Developer must provide notice and a reasonable opportunity for API
Information Sources and API Users to update their applications to
preserve compatibility with certified API technology and to comply with
applicable terms and conditions.
(b) Maintenance of certification requirements--(1) Authenticity
verification and registration for production use. The following apply
to a Certified API Developer with a Health IT Module certified to the
certification criterion adopted in Sec. 170.315(g)(10):
(i) Authenticity verification. A Certified API Developer is
permitted to institute a process to verify the authenticity of API
Users so long as such process is objective and the same for all API
Users and completed within ten business days of receipt of an API
User's request to register their software application for use with the
Certified API Developer's Health IT Module certified to Sec.
170.315(g)(10).
(ii) Registration for production use. A Certified API Developer
must register and enable all applications for production use within
five business days of completing its verification of an API User's
authenticity, pursuant to paragraph (b)(1)(i) of this section.
(2) Service base URL publication. A Certified API Developer must
publish the service base URLs for all Health IT Modules certified to
Sec. 170.315(g)(10) that can be used by patients to access their
electronic health information. The Certified API Developer must
publicly publish the service base URLs:
(i) For all of its customers regardless of whether the Health IT
Modules certified to Sec. 170.315(g)(10) are centrally managed by the
Certified API Developer or locally deployed by an API Information
Source; and
(ii) In a machine-readable format at no charge.
(3) Rollout of (g)(10)-certified APIs. A Certified API Developer
with certified API technology previously certified to the certification
criterion in Sec. 170.315(g)(8) must provide all API Information
Sources with such certified API technology deployed with certified API
technology certified to the certification criterion in Sec.
170.315(g)(10) by no later than May 2, 2022.
(4) Compliance for existing certified API technology. By no later
than November 2, 2020, a Certified API Developer with Health IT
Module(s) certified to the certification criteria in Sec.
170.315(g)(7), (8), or (9) must comply with paragraph (a) of this
section, including revisions to their existing business and technical
API documentation and make such documentation available via a publicly
accessible hyperlink that allows any person to directly access the
information without any preconditions or additional steps.
(c) Definitions. The following definitions apply to this section:
API Information Source means an organization that deploys certified
API technology created by a ``Certified API Developer;''
API User means a person or entity that creates or uses software
applications that interact with the ``certified API technology''
developed by a ``Certified API Developer'' and deployed by an ``API
Information Source;''
Certified API Developer means a health IT developer that creates
the ``certified API technology'' that is certified to any of the
certification criteria adopted in Sec. 170.315(g)(7) through (10); and
Certified API technology means the capabilities of Health IT
Modules that are certified to any of the API-focused certification
criteria adopted in Sec. 170.315(g)(7) through (10).
Sec. 170.405 Real world testing.
(a) Condition of Certification requirement. A health IT developer
with Health IT Module(s) certified to any one or more 2015 Edition
certification criteria in Sec. 170.315(b), (c)(1) through (3), (e)(1),
(f), (g)(7) through (10), and (h) must successfully test the real world
use of those Health IT Module(s) for interoperability (as defined in 42
U.S.C.300jj(9) and Sec. 170.102) in the type of setting in which such
Health IT Module(s) would be/is marketed.
(b) Maintenance of Certification requirements--(1) Real world
testing plan submission. A health IT developer with Health IT Module(s)
certified to any one or more of the criteria referenced in paragraph
(a) of this section must submit to its ONC-ACB an annual real world
testing plan addressing each of those certified Health IT Modules by a
date determined by the ONC-ACB that enables the ONC-ACB to publish a
publicly available hyperlink to the plan on CHPL no later than December
15 of each calendar year.
(i) The plan must be approved by a health IT developer authorized
representative capable of binding the
[[Page 25949]]
health IT developer for execution of the plan and include the
representative's contact information.
(ii) The plan must include all health IT certified to any one or
more of the criteria referenced in paragraph (a) of this section as of
August 31 of the year in which the plan is submitted, and address the
real world testing to be conducted in the calendar year immediately
following plan submission.
(iii) The plan must address the following for each of the
certification criteria identified in paragraph (a) of this section that
are included in each Health IT Module's scope of certification:
(A) The testing method(s)/methodology(ies) that will be used to
demonstrate real world interoperability and conformance to the full
scope of the certification criterion's requirements, including
scenario- and use case-focused testing;
(B) The care setting(s) that will be tested for real world
interoperability and an explanation for the health IT developer's
choice of care setting(s) to test;
(C) For any standards and implementation specifications referenced
by the criterion that the developer has chosen to certify to National
Coordinator-approved newer versions pursuant to paragraph (b)(8) or (9)
of this section, a description of how the developer will test and
demonstrate conformance to all requirements of the criterion using all
versions of the adopted standards to which each Health IT Module was
certified as of August 31 of the year in which the real world testing
plan is due.
(D) A schedule of key real world testing milestones;
(E) A description of the expected outcomes of real world testing;
(F) At least one measurement/metric associated with the real world
testing; and
(G) A justification for the health IT developer's real world
testing approach.
(2) Real world testing results reporting. (i) If in the course of
conducting real world testing the developer discovers one or more non-
conformities with the full scope of any certification criterion under
the Program, the developer must report that non-conformity to the ONC-
ACB within 30 days.
(ii) For real world testing activities conducted during the
immediately preceding calendar year, a health IT developer must submit
to its ONC-ACB an annual real world testing results report addressing
each of its certified Health IT Modules that include certification
criteria referenced in paragraph (a) of this section by a date
determined by the ONC-ACB that enables the ONC-ACB to publish a
publicly available hyperlink to the results report on CHPL no later
than March 15 of each calendar year. The real world testing results
must report the following for each of the certification criteria
identified in paragraph (a) of this section that are included in the
Health IT Module's scope of certification:
(A) The method(s) that was used to demonstrate real world
interoperability;
(B) The care setting(s) that was tested for real world
interoperability;
(C) The voluntary updates to standards and implementation
specifications that the National Coordinator has approved through the
Standards Version Advancement Process;
(D) A list of the key milestones met during real world testing;
(E) The outcomes of real world testing including a description of
any challenges encountered during real world testing; and
(F) At least one measurement/metric associated with the real world
testing.
(3) USCDI Updates for C-CDA. A health IT developer with health IT
certified to Sec. 170.315(b)(1), (b)(2), (e)(1), (g)(6), (f)(5), and/
or (g)(9) on May 1, 2020, must:
(i) Update their certified health IT to be compliant with the
revised versions of these criteria adopted in this final rule; and
(ii) Provide its customers of the previously certified health IT
with certified health IT that meets paragraph (b)(3)(i) of this section
by May 2, 2022.
(4) C-CDA Companion Guide Updates. A health IT developer with
health IT certified to Sec. 170.315(b)(1), (b)(2), (b)(9), (e)(1),
(g)(6), and/or (g)(9) prior to May 1, 2020, must:
(i) Update their certified health IT to be compliant with the
revised versions of the Program criteria in the 2015 Edition; and
(ii) Provide its customers of the previously certified health IT
with certified health IT that meets paragraph (b)(4)(i) of this section
by May 2, 2022.
(5) Electronic prescribing. A health IT developer with health IT
certified to Sec. 170.315(b)(3) prior to November 2, 2020, must:
(i) Update their certified health IT to be compliant with the
revised versions of this criteria adopted in Sec. 170.315(b)(3)(ii);
and
(ii) Provide its customers of the previously certified health IT
with certified health IT that meets paragraph (b)(5)(i) of this section
by May 2, 2022
(6) Security tags. A health IT developer with health IT certified
to Sec. 170.315(b)(7) and/or Sec. 170.315(b)(8) prior to May 1, 2020,
must:
(i) Update their certified health IT to be compliant with the
revised versions of the criteria adopted in Sec. 170.315(b)(7) and/or
the revised versions of the criteria adopted in Sec. 170.315(b)(8);
and
(ii) Provide its customers of the previously certified health IT
with certified health IT that meets paragraph (b)(6)(i) of this section
by May 2, 2022.
(7) ASTM updates. A health IT developer with health IT certified to
Sec. 170.315(d)(2), (3), and/or (d)(10) prior to May 1, 2020, must:
(i) Update their certified health IT to be compliant with Sec.
170.210(e)(1) and the standard specified in Sec. 170.210(h); and
(ii) Provide its customers of the previously certified health IT
with certified health IT that meets paragraph (b)(7)(i) of this section
by May 2, 2022.
(8) Standards Version Advancement Process--voluntary updates of
certified health IT to newer versions of standards and implementation
specifications. A health IT developer subject to this paragraph (b) is
permitted to update Health IT Module(s) certified to any one or more of
the certification criteria referenced in paragraph (a) of this section
to a newer version of any adopted standard or implementation
specification included in the criterion, provided that newer version is
approved by the National Coordinator for use in certifications issued
under the ONC Health IT Certification Program. A developer that pursues
such updates to its certified Health IT Module(s) must:
(i) Provide advance notice to all affected customers and its ONC-
ACB--
(A) Expressing its intent to update the certified Health IT
Module(s) to the National Coordinator-approved advanced version of the
standard implementation specification;
(B) The developer's expectations for how the update(s) will affect
real world interoperability for the Health IT Module(s);
(C) Whether the developer intends to continue to support the
certificate(s) for the existing certified Health IT Module(s)
version(s) for some period of time and how long or if the existing
certified Health IT Module(s) version(s) will be deprecated; and
(ii) Successfully demonstrate conformance with approved more recent
versions of the standard(s) or implementation specification(s) included
in each certification criterion under which the developer chooses to
update its certified Health IT Module(s).
(iii) Maintain the updated certified Health IT Module(s) in full
conformance
[[Page 25950]]
with all applicable Program requirements.
(9) Standards Version Advancement Process--voluntary certification
to newer versions of standards and implementation specifications. A
Health IT developer is permitted to seek certification for its Health
IT Module(s) to any one or more of the certification criteria
referenced in paragraph (a) of this section using a newer version of
any adopted standard(s) or implementation specification(s) included in
the criterion without first obtaining certification to the version of
that adopted standard or implementation specification that is
incorporated by reference in Sec. 170.299, provided that the newer
version is approved by the National Coordinator for use in
certifications issued under the ONC Health IT Certification Program.
Developers may, for each standard and implementation specification
included in each criterion, choose on an itemized basis whether to seek
certification to the version incorporated by reference in Sec.
170.299, or to one or more newer version(s) approved by the National
Coordinator for use in Health IT Module certifications issued pursuant
to section 3001(c)(5) of the Public Health Service Act, or to both.
Sec. 170.406 Attestations.
(a) Condition of Certification requirement. A health IT developer,
or its authorized representative that is capable of binding the health
IT developer, must provide the Secretary an attestation of compliance
with the following Conditions and Maintenance of Certification
requirements:
(1) Section 170.401;
(2) Section 170.402, but only for Sec. 170.402(a)(4) and (b)(2) if
the health IT developer certified a Health IT Module(s) that is part of
a health IT product which can store electronic health information;
(3) Section 170.403;
(4) Section 170.404 if the health IT developer has a Health IT
Module(s) certified to any of the certification criteria adopted in
Sec. 170.315(g)(7) through (10); and such health IT developer must
also ensure that health IT allows for health information to be
exchanged, accessed, and used, in the manner described in Sec.
170.404; and
(5) Section 170.405 if a health IT developer has a Health IT
Module(s) certified to any one or more 2015 Edition certification
criteria in Sec. 170.315(b), (c)(1) through (3), (e)(1), (f), (g)(7)
through (10), and (h).
(b) Maintenance of Certification requirement. (1) A health IT
developer, or its authorized representative that is capable of binding
the health IT developer, must provide the attestation specified in
paragraph (a) of this section semiannually for any Health IT Modules
that have or have had an active certification at any time under the ONC
Health IT Certification Program during the prior six months.
(2) [Reserved].
Subpart E--ONC Health IT Certification Program
Sec. 170.501 [Amended]
0
17. Amend Sec. 170.501:
0
a. In paragraph (a), by removing the phrase ``Complete EHRs,'';
0
b. In paragraph (b), by removing the phrase ``Complete EHRs and''; and
0
c. By removing and reserving paragraph (c).
Sec. 170.502 [Amended]
0
18. Amend Sec. 170.502:
0
a. In the definition of ``Deployment site'', by removing the phrase
``Complete EHR,'';
0
b. In the definition of ``Development site'', by removing the phrase
``Complete EHR,'';
0
c. In the introductory text to the definition of ``Gap certification'',
by removing the phrase ``Complete EHR or'';
0
d. By removing the definition of ``ONC-Approved Accreditor or ONC-AA'';
0
e. In the definition of ``ONC-Authorized Certification Body or ONC-
ACB'', by removing the phrase ``Complete EHRs,''; and
0
f. In the definition of ``ONC-Authorized Testing Lab or ONC-ATL,'' by
removing the phrase ``Complete EHRs and''.
Sec. Sec. 170.503 and 170.504 [Removed and Reserved]
0
19. Remove and reserve Sec. Sec. 170.503 and 170.504.
0
20. Revise Sec. 170.505 to read as follows:
Sec. 170.505 Correspondence.
(a) Correspondence and communication with ONC or the National
Coordinator shall be conducted by email, unless otherwise necessary or
specified.
(1) Consideration for providing notice beyond email, such as by
regular, express, or certified mail, will be based on, but not limited
to, whether: The party requests use of correspondence beyond email; the
party has responded via email to our communications; we have sufficient
information from the party to ensure appropriate delivery of any other
method of notice; and the matter involves an alleged violation within
ONC's purview under Sec. 170.580 that indicates a serious violation
under the ONC Health IT Certification Program with potential
consequences of suspension, certification termination, or a
certification ban.
(2) The official date of receipt of any email between ONC or the
National Coordinator and an applicant for ONC-ACB status, an applicant
for ONC-ATL status, an ONC-ACB, an ONC-ATL, health IT developer, or a
party to any proceeding under this subpart is the date on which the
email was sent.
(b) In circumstances where it is necessary for an applicant for
ONC-ACB status, an applicant for ONC-ATL status, an ONC-ACB, an ONC-
ATL, health IT developer, or a party to any proceeding under this
subpart to correspond or communicate with ONC or the National
Coordinator by regular, express, or certified mail, the official date
of receipt for all parties will be the date of the delivery
confirmation to the address on record.
Sec. 170.510 [Amended]
0
21. Amend Sec. 170.510 by removing paragraph (a) and redesignating
paragraphs (b) and (c) as paragraphs (a) and (b).
0
22. Amend Sec. 170.520 by revising paragraph (a)(3) to read as
follows:
Sec. 170.520 Application.
(a) * * *
(3) Documentation that confirms that the applicant has been
accredited to ISO/IEC 17065 (for availability, see Sec. 170.599), with
an appropriate scope, by any accreditation body that is a signatory to
the Multilateral Recognition Arrangement (MLA) with the International
Accreditation Forum (IAF).
* * * * *
0
23. Amend Sec. 170.523:
0
a. By revising paragraph (a);
0
b. By adding subject headings to paragraphs (b), (c), (d) introductory
text, and (e);
0
c. In paragraph (f) introductory text, by adding a subject heading and
removing the phrase, ``Complete EHRs,'' and;
0
d. By removing and reserving paragraph (f)(2);
0
e. Revising paragraphs (g) and (h);
0
f. Adding subject headings to paragraphs (i) introductory text and (j)
introductory text;
0
g. In paragraph (k) introductory text, by adding a subject heading and
removing the phrase ``Complete EHRs and'';
0
h. In paragraph (k)(1), by removing the phrase ``Complete EHR or'';
[[Page 25951]]
0
i. By revising paragraphs (k)(1)(ii) and (iii);
0
j. By removing and reserving paragraphs (k)(1)(iv)(B) and (C) and
(k)(2) and (3);
0
k. By revising paragraph (k)(4);
0
l. By adding a subject heading to paragraph (l);
0
m. By revising paragraph (m);
0
n. In paragraph (o), by adding a subject heading and removing the
phrase ``Complete EHR or''; and
0
o. By adding paragraphs (p) through (t).
The revisions and additions read as follows:
Sec. 170.523 Principles of proper conduct for ONC-ACBs.
* * * * *
(a) Accreditation. Maintain its accreditation in good standing to
ISO/IEC 17065 (incorporated by reference in Sec. 170.599).
(b) Mandatory training. * * *
* * * * *
(c) Training program. * * *
* * * * *
(d) Reporting. * * *
* * * * *
(e) Onsite observation. * * *
(f) Certified product listing. * * *
* * * * *
(g) Records retention. (1) Retain all records related to the
certification of Complete EHRs and Health IT Modules to an edition of
certification criteria beginning with the codification of an edition of
certification criteria in the Code of Federal Regulations through a
minimum of 3 years from the effective date that removes the applicable
edition from the Code of Federal Regulations; and
(2) Make the records available to HHS upon request during the
retention period described in paragraph (g)(1) of this section;
(h) Certification decision. Only certify Health IT Modules that
have been:
(1) Tested, using test tools and test procedures approved by the
National Coordinator, by an:
(i) ONC-ATL;
(ii) ONC-ATL, National Voluntary Laboratory Accreditation Program-
accredited testing laboratory under the ONC Health IT Certification
Program, and/or an ONC-ATCB for the purposes of performing gap
certification; or
(2) Evaluated by it for compliance with a conformance method
approved by the National Coordinator.
(i) Surveillance. * * *
* * * * *
(j) Refunds. * * *
* * * * *
(k) Disclosures. * * *
(1) * * *
(ii) For a Health IT Module certified to the 2015 Edition health IT
certification criteria, the information specified by paragraphs
(f)(1)(i), (vi) through (viii), (xv), and (xvi) of this section as
applicable for the specific Health IT Module.
(iii) In plain language, a detailed description of all known
material information concerning additional types of costs or fees that
a user may be required to pay to implement or use the Health IT
Module's capabilities, whether to meet provisions of HHS programs
requiring the use of certified health IT or to achieve any other use
within the scope of the health IT's certification. The additional types
of costs or fees required to be disclosed include but are not limited
to costs or fees (whether fixed, recurring, transaction-based, or
otherwise) imposed by a health IT developer (or any third party from
whom the developer purchases, licenses, or obtains any technology,
products, or services in connection with its certified health IT) to
purchase, license, implement, maintain, upgrade, use, or otherwise
enable and support the use of capabilities to which health IT is
certified; or in connection with any data generated in the course of
using any capability to which health IT is certified.
* * * * *
(4) A certification issued to a Health IT Module based solely on
the applicable certification criteria adopted by the ONC Health IT
Certification Program must be separate and distinct from any other
certification(s) based on other criteria or requirements.
(l) Certification and Design Mark. * * *
(m) Adaptations and updates. On a quarterly basis each calendar
year, obtain a record of:
(1) All adaptations of certified Health IT Modules;
(2) All updates made to certified Health IT Modules affecting the
capabilities in certification criteria to which the ``safety-enhanced
design'' criteria apply;
(3) All uses cases for Sec. 170.315(d)(13);
(4) All updates made to certified Health IT Modules in compliance
with Sec. 170.405(b)(3); and
(5) All updates to certified Health IT Modules and all
certifications of Health IT Modules issued including voluntary use of
newer standards versions per Sec. 170.405(b)(8) or (9). Record of
these updates may be obtained by aggregation of ONC-ACB documentation
of certification activity.
* * * * *
(o) Scope reduction. * * *
(p) Real world testing. (1) Review and confirm that applicable
health IT developers submit real world testing plans in accordance with
Sec. 170.405(b)(1).
(2) Review and confirm that applicable health IT developers submit
real world testing results in accordance with Sec. 170.405(b)(2).
(3) Submit real world testing plans by December 15 of each calendar
year and results by March 15 of each calendar year to ONC for public
availability.
(q) Attestations. Review and submit health IT developer Conditions
and Maintenance of Certification requirements attestations made in
accordance with Sec. 170.406 to ONC for public availability.
(r) Test results from ONC-ATLs. Accept test results from any ONC-
ATL that is:
(1) In good standing under the ONC Health IT Certification Program,
and
(2) Compliant with its ISO/IEC 17025 accreditation requirements as
required by 170.524(a).
(s) Information for direct review. Report to ONC, no later than a
week after becoming aware of, any information that could inform whether
ONC should exercise direct review under Sec. 170.580(a).
(t) Health IT Module voluntary standards and implementation
specifications updates notices. Ensure health IT developers opting to
take advantage of the flexibility for voluntary updates of standards
and implementation specifications in certified Health IT Modules per
Sec. 170.405(b)(8) provide timely advance written notice to the ONC-
ACB and all affected customers.
(1) Maintain a record of the date of issuance and the content of
developers' Sec. 170.405(b)(8) notices; and
(2) Timely post content or make publicly accessible via the CHPL
each Sec. 170.405(b)(8) notice received, publicly on the CHPL
attributed to the certified Health IT Module(s) to which it applies.
0
24. Amend Sec. 170.524:
0
a. By adding subject headings to paragraphs (a) through (c), (d)
introductory text, and (e);
0
b. By revising paragraph (f);
0
c. By adding a subject heading to paragraph (g) and paragraph (h)
introductory text; and
0
d. In paragraph (h)(3), by removing the phrase ``Complete EHRs and/
or''.
The additions and revisions read as follows:
Sec. 170.524 Principles of proper conduct for ONC-ATLs.
* * * * *
[[Page 25952]]
(a) Accreditation. * * *
(b) Mandatory training. * * *
(c) Training program. * * *
(d) Reporting. * * *
* * * * *
(e) Onsite observation. * * *
(f) Records retention. (1) Retain all records related to the
testing of Complete EHRs and/or Health IT Modules to an edition of
certification criteria beginning with the codification of an edition of
certification criteria in the Code of Federal Regulations through a
minimum of three years from the effective date that removes the
applicable edition from the Code of Federal Regulations; and
(2) Make the records available to HHS upon request during the
retention period described in paragraph (f)(1) of this section;
(g) Approved testing methods. * * *
(h) Refunds. * * *
* * * * *
Sec. 170.545 [Removed and Reserved]
0
25. Remove and reserve Sec. 170.545.
0
26. Amend Sec. 170.550 by:
0
a. Adding subject headings to paragraphs (a),(b), and (d), and adding
paragraph (e);
0
b. Removing and reserving paragraph (f);
0
c. Adding a subject heading to paragraph (g) introductory text and
adding paragraph (g)(5);
0
d. Revising paragraph (h); and
0
e. Adding paragraphs (l) and (m).
The additions and revisions read as follows:
Sec. 170.550 Health IT Module certification.
(a) Certification scope. * * *
(b) Health IT product scope options. * * *
* * * * *
(d) Upgrades and enhancements. * * *
(e) Standards updates. ONC-ACBs must provide an option for
certification of Health IT Modules consistent with Sec. 171.405(b)(7)
or (8) to any one or more of the criteria referenced in Sec.
170.405(a) based on newer versions of standards included in the
criteria which have been approved by the National Coordinator for use
in certification.
* * * * *
(g) Health IT module dependent criteria. * * *
(5) Section 170.315(b)(10) when a health IT developer presents a
Health IT Module for certification that can store electronic health
information at the time of certification by the product, of which the
Health IT Module is a part.
(h) Privacy and security certification framework--(1) General rule.
When certifying a Health IT Module to the 2015 Edition health IT
certification criteria, an ONC-ACB can only issue a certification to a
Health IT Module if the privacy and security certification criteria in
paragraphs (h)(3)(i) through (ix) of this section have also been met
(and are included within the scope of the certification).
(2) Testing. In order to be issued a certification, a Health IT
Module would only need to be tested once to each applicable privacy and
security criterion in paragraphs (h)(3)(i) through (ix) of this section
so long as the health IT developer attests that such privacy and
security capabilities apply to the full scope of capabilities included
in the requested certification, except for the following:
(i) A Health IT Module presented for certification to Sec.
170.315(e)(1) must be separately tested to Sec. 170.315(d)(9); and
(ii) A Health IT Module presented for certification to Sec.
170.315(e)(2) must be separately tested to Sec. 170.315(d)(9).
(3) Applicability. (i) Section 170.315(a)(1) through (3), (5),
(12), (14), and (15) are also certified to the certification criteria
specified in Sec. 170.315(d)(1) through (7), (d)(12), and (13).
(ii) Section 170.315(a)(4), (9), (10), and (13) are also certified
to the certification criteria specified in Sec. 170.315(d)(1) through
(3), and (d)(5) through (7), (d)(12), and (13).
(iii) Section 170.315(b)(1) through (3) and (6) through (9) are
also certified to the certification criteria specified in Sec.
170.315(d)(1) through (3) and (d)(5) through (8), (12), and (13);
(iv) Section 170.315(c) is also certified to the certification
criteria specified in Sec. 170.315(d)(1), (d)(2)(i)(A), (B),
(d)(2)(ii) through (v), (d)(3), (5), (12), and (13);
(v) Section 170.315(e)(1) is also certified to the certification
criteria specified in Sec. 170.315(d)(1) through (3), (5), (7), (9),
(12), and (13);
(vi) Section 170.315(e)(2) and (3) is also certified to the
certification criteria specified in Sec. 170.315(d)(1), (d)(2)(i)(A)
and (B), (d)(2)(ii) through (v), (d)(3), (5), (9), (12), and (13);
(vii) Section 170.315(f) is also certified to the certification
criteria specified in Sec. 170.315(d)(1) through (3), (7), (12), and
(13);
(viii) Section 170.315(g)(7) through (10) is also certified to the
certification criteria specified in Sec. 170.315(d)(1), (9), (12), and
(13); and (d)(2)(i)(A) and (B), (d)(2)(ii) through (v), or (d)(10);
(ix) Section 170.315(h) is also certified to the certification
criteria specified in Sec. 170.315(d)(1), (d)(2)(i)(A) and (B),
(d)(2)(ii) through (v), (d)(3), (12), and (13); and
* * * * *
(l) Conditions of certification attestations. Ensure that the
health IT developer of the Health IT Module has met its
responsibilities under subpart D of this part.
(m) Time-limited certification and certification status for certain
2015 Edition certification criteria. An ONC-ACB may only issue a
certification to a Health IT Module and permit continued certified
status for:
(1) Section 170.315(a)(10) and (13) and Sec. 170.315(e)(2) until
January 1, 2022.
(2) Section 170.315(b)(6) until May 1, 2023.
(3) Section 170.315(g)(8) until May 2, 2022.
0
27. Amend Sec. 170.555:
0
a. In paragraph (a) by removing the words ``Complete EHRs and/or''; and
0
b. By revising paragraph (b)(1).
The revision reads as follows:
Sec. 170.555 Certification to newer versions of certain standards.
* * * * *
(b) * * *
(1) ONC-ACBs are not required to certify Health IT Module(s)
according to newer versions of standards adopted and named in subpart B
of this part, unless:
(i) The National Coordinator approves a newer version for use in
certification and a health IT developer voluntarily elects to seek
certification of its health IT in accordance with Sec. 170.405(b)(9)
or update its certified health IT to the newer version in accordance
with Sec. 170.405(b)(8); or
(ii) The new version is incorporated by reference in Sec. 170.299.
* * * * *
0
28. Amend Sec. 170.556:
0
a. By removing the phrases ``certified Complete EHR or'' and ``Complete
EHR or'', wherever they occur;
0
b. By revising paragraph (a) introductory text and paragraph (c)
introductory text;
0
c. By removing and reserving paragraph (c)(2);
0
d. In paragraph (c)(3), by removing the phrase ``certified Complete
EHRs''; and
0
e. By removing paragraphs (c)(5) and (6).
The revisions read as follows:
Sec. 170.556 In-the-field surveillance and maintenance of
certification for Health IT.
(a) In-the-field surveillance. Consistent with its accreditation
under 170.523(a) to ISO/IEC 17065 and the requirements of this subpart,
an ONC-
[[Page 25953]]
ACB must initiate surveillance ``in the field'' as necessary to assess
whether a certified Health IT Module continues to conform to the
requirements in subparts A, B, C and E of this part once the certified
Health IT Module has been implemented and is in use in a production
environment.
* * * * *
(c) Randomized surveillance. During each calendar year surveillance
period, an ONC-ACB may conduct in-the-field surveillance for certain
randomly selected Health IT Modules to which it has issued a
certification.
* * * * *
Sec. Sec. 170.560, 170.565, and 170.570 [Amended]
0
29. In the table below, for each section and paragraph indicated in the
first two columns, remove the phrase indicated in the third column:
------------------------------------------------------------------------
Section Paragraphs Remove
------------------------------------------------------------------------
Sec. 170.560...... (a)(2)......... ``Complete EHRs and/or''
Sec. 170.565...... (d)(1)(ii) and ``Complete EHRs or''
(iii).
Sec. 170.565...... (h)(2)(iii).... ``Complete EHRs and''
Sec. 170.570...... (a), (b)(2), ``Complete EHRs and/or''
(c)
introductory
text, and
(c)(1) and (2).
------------------------------------------------------------------------
Sec. 170.575 [Removed and Reserved]
0
30. Remove and reserve Sec. 170.575.
0
31. Amend Sec. 170.580:
0
a. By revising paragraph (a)(1) and the subject headings to paragraphs
(a)(2)(i) and(ii);
0
b. By adding paragraph (a)(2)(iii);
0
c. By revising paragraphs (a)(3)(i), (iv), and (v);
0
d. By adding paragraph (a)(4);
0
e. By revising paragraphs (b)(1)(i) and (b)(1)(iii)(D), (b)(2)(i), and
(b)(3)(i) and (ii);
0
f. By adding paragraphs (b)(3)(iii) and (iv);
0
g. By revising paragraph (c)(1);
0
h. In paragraphs (d)(1), (d)(2)(i)(C), and (d)(4), by removing the
phrase ``Complete EHR or'';
0
i. In paragraph (d)(5), by removing the phrase ``Complete EHRs or'';
0
j. By revising paragraphs (e)(1) introductory text and (f)(1);
0
k. In paragraph (f)(2)(i)(C), by removing the phrase ``Complete EHR
or''; and
0
l. Revising paragraphs (g)(1) introductory text, (g)(1)(i), (g)(2),
(g)(3)(i), (g)(4), (g)(5)(i), and (g)(6)(v).
The revisions and additions read as follows:
Sec. 170.580 ONC review of certified health IT or a health IT
developer's actions.
(a) * * *
(1) Purpose. ONC may directly review certified health IT or a
health IT developer's actions or practices to determine whether either
conform to the requirements of the ONC Health IT Certification Program.
(2) * * *
(i) Certified health IT causing or contributing to unsafe
conditions. * * *
(ii) Impediments to ONC-ACB oversight of certified health IT. * * *
(iii) Noncompliance with a Condition and Maintenance of
Certification requirement. ONC may initiate direct review under this
section if it has a reasonable belief that a health IT developer has
not complied with a Condition or Maintenance of Certification
requirement under subpart D of this part.
(3) * * *
(i) ONC's review of certified health IT or a health IT developer's
actions or practices is independent of, and may be in addition to, any
surveillance of certified health IT conducted by an ONC-ACB.
* * * * *
(iv) An ONC-ACB and ONC-ATL shall provide ONC with any available
information that ONC deems relevant to its review of certified health
IT or a health IT developer's actions or practices.
(v) ONC may end all or any part of its review of certified health
IT or a health IT developer's actions or practices under this section
at any time and refer the applicable part of the review to the relevant
ONC-ACB(s) if ONC determines that doing so would serve the effective
administration or oversight of the ONC Health IT Certification Program.
(4) Coordination with the Office of Inspector General. (i) ONC may
coordinate its review of a claim of information blocking with the
Office of Inspector General or defer to the Office of Inspector General
to lead a review of a claim of information blocking.
(ii) ONC may rely on Office of Inspector General findings to form
the basis of a direct review action.
(b) * * *
(1) * * *
(i) Circumstances that may trigger notice of potential non-
conformity. At any time during its review of certified health IT or a
health IT developer's actions or practices under paragraph (a) of this
section, ONC may send a notice of potential non-conformity if it has a
reasonable belief that certified health IT or a health IT developer's
actions or practices may not conform to the requirements of the ONC
Health IT Certification Program.
* * * * *
(iii) * * *
(D) Issue a notice of proposed termination if the health IT is
under review in accordance with paragraph (a)(2)(i) or (ii) of this
section.
(2) * * *
(i) Circumstances that may trigger notice of non-conformity. At any
time during its review of certified health IT or a health IT
developer's actions or practices under paragraph (a) of this section,
ONC may send a notice of non-conformity to the health IT developer if
it determines that certified health IT or a health IT developer's
actions or practices does not conform to the requirements of the ONC
Health IT Certification Program.
* * * * *
(3) * * *
(i) All records related to the development, testing, certification,
implementation, maintenance and use of its certified health IT;
(ii) Any complaint records related to the certified health IT;
(iii) All records related to the Condition(s) and Maintenance of
Certification requirements, including marketing and distribution
records, communications, and contracts; and
(iv) Any other relevant information.
(c) * * *
(1) Applicability. If ONC determines that certified health IT or a
health IT developer's action or practice does not conform to
requirements of the ONC Health IT Certification Program, ONC shall
notify the health IT developer of its determination and require the
health IT developer to submit a proposed corrective action plan.
* * * * *
(e) * * *
(1) Applicability. Excluding situations of noncompliance with a
Condition or Maintenance of Certification
[[Page 25954]]
requirement under subpart D of this part, ONC may propose to terminate
a certification issued to a Health IT Module if:
* * * * *
(f) * * *
(1) Applicability. The National Coordinator may terminate a
certification if:
(i) A determination is made that termination is appropriate after
considering the information provided by the health IT developer in
response to the proposed termination notice;
(ii) The health IT developer does not respond in writing to a
proposed termination notice within the timeframe specified in paragraph
(e)(3) of this section; or
(iii) A determination is made that the health IT developer is
noncompliant with a Condition or Maintenance of Certification
requirement under subpart D of this part or for the following
circumstances when ONC exercises direct review under paragraph
(a)(2)(iii) of this section:
(A) The health IT developer fails to timely respond to any
communication from ONC, including, but not limited to:
(1) Fact-finding;
(2) A notice of potential non-conformity within the timeframe
established in accordance with paragraph (b)(1)(ii)(A)(3) of this
section; or
(3) A notice of non-conformity within the timeframe established in
accordance with paragraph (b)(2)(ii)(A)(3) of this section.
(B) The information or access provided by the health IT developer
in response to any ONC communication, including, but not limited to:
Fact-finding, a notice of potential non-conformity, or a notice of non-
conformity is insufficient or incomplete;
(C) The health IT developer fails to cooperate with ONC and/or a
third party acting on behalf of ONC;
(D) The health IT developer fails to timely submit in writing a
proposed corrective action plan;
(E) The health IT developer fails to timely submit a corrective
action plan that adequately addresses the elements required by ONC as
described in paragraph (c) of this section;
(F) The health IT developer does not fulfill its obligations under
the corrective action plan developed in accordance with paragraph (c)
of this section; or
(G) ONC concludes that the non-conformity(ies) cannot be cured.
* * * * *
(g) * * *
(1) Basis for appeal. A health IT developer may appeal an ONC
determination to suspend or terminate a certification issued to a
Health IT Module and/or an ONC determination to issue a certification
ban under Sec. 170.581(a)(2) if the health IT developer asserts:
(i) ONC incorrectly applied ONC Health IT Certification Program
requirements for a:
(A) Suspension;
(B) Termination; or
(C) Certification ban under Sec. 170.581(a)(2).
* * * * *
(2) Method and place for filing an appeal. A statement of intent to
appeal followed by a request for appeal must be submitted to ONC in
writing by an authorized representative of the health IT developer
subject to the determination being appealed. The statement of intent to
appeal and request for appeal must be filed in accordance with the
requirements specified in the notice of:
(i) Termination;
(ii) Suspension; or
(iii) Certification ban under Sec. 170.581(a)(2).
(3) * * *
(i) A statement of intent to appeal must be filed within 10 days of
a health IT developer's receipt of the notice of:
(A) Suspension;
(B) Termination; or
(C) Certification ban under Sec. 170.581(a)(2).
* * * * *
(4) Effect of appeal. (i) A request for appeal stays the
termination of a certification issued to a Health IT Module, but the
Health IT Module is prohibited from being marketed, licensed, or sold
as ``certified'' during the stay.
(ii) A request for appeal does not stay the suspension of a Health
IT Module.
(iii) A request for appeal stays a certification ban issued under
Sec. 170.581(a)(2).
(5) * * *
(i) The hearing officer may not review an appeal in which he or she
participated in the initial suspension, termination, or certification
ban determination or has a conflict of interest in the pending matter.
* * * * *
(6) * * *
(v) ONC will have an opportunity to provide the hearing officer
with a written statement and supporting documentation on its behalf
that clarifies, as necessary, its determination to suspend or terminate
the certification or issue a certification ban.
* * * * *
0
32. Revise Sec. 170.581 to read as follows:
Sec. 170.581 Certification ban.
(a) Circumstances that may trigger a certification ban. The
certification of any of a health IT developer's health IT is prohibited
when:
(1) The certification of one or more of the health IT developer's
Health IT Modules is:
(i) Terminated by ONC under the ONC Health IT Certification
Program;
(ii) Withdrawn from the ONC Health IT Certification Program by an
ONC-ACB because the health IT developer requested it to be withdrawn
(for reasons other than to comply with Program requirements) when the
health IT developer's health IT was the subject of a potential non-
conformity or non-conformity as determined by ONC;
(iii) Withdrawn by an ONC-ACB because of a non-conformity with any
of the certification criteria adopted by the Secretary under subpart C
of this part;
(iv) Withdrawn by an ONC-ACB because the health IT developer
requested it to be withdrawn (for reasons other than to comply with
Program requirements) when the health IT developer's health IT was the
subject of surveillance for a certification criterion or criteria
adopted by the Secretary under subpart C of this part, including notice
of pending surveillance; or
(2) ONC determines a certification ban is appropriate per its
review under Sec. 170.580(a)(2)(iii).
(b) Notice of certification ban. When ONC decides to issue a
certification ban to a health IT developer, ONC will notify the health
IT developer of the certification ban through a notice of certification
ban. The notice of certification ban will include, but may not be
limited to:
(1) An explanation of the certification ban;
(2) Information supporting the certification ban;
(3) Instructions for appealing the certification ban if banned in
accordance with paragraph (a)(2) of this section; and
(4) Instructions for requesting reinstatement into the ONC Health
IT Certification Program, which would lift the certification ban.
(c) Effective date of certification ban. (1) A certification ban
will be effective immediately if banned under paragraph (a)(1) of this
section.
(2) For certification bans issued under paragraph (a)(2) of this
section, the ban will be effective immediately after the following
applicable occurrence:
(i) The expiration of the 10-day period for filing a statement of
intent to appeal in Sec. 170.580(g)(3)(i) if the health IT
[[Page 25955]]
developer does not file a statement of intent to appeal.
(ii) The expiration of the 30-day period for filing an appeal in
Sec. 170.580(g)(3)(ii) if the health IT developer files a statement of
intent to appeal, but does not file a timely appeal.
(iii) A final determination to issue a certification ban per Sec.
170.580(g)(7) if a health IT developer files an appeal timely.
(d) Reinstatement. The certification of a health IT developer's
health IT subject to the prohibition in paragraph (a) of this section
may commence once the following conditions are met.
(1) A health IT developer must request ONC's permission in writing
to participate in the ONC Health IT Certification Program.
(2) The request must demonstrate that the customers affected by the
certificate termination, certificate withdrawal, or noncompliance with
a Condition or Maintenance of Certification requirement have been
provided appropriate remediation.
(3) For noncompliance with a Condition or Maintenance of
Certification requirement, the noncompliance must be resolved.
(4) ONC is satisfied with the health IT developer's demonstration
under paragraph (d)(2) of this section that all affected customers have
been provided with appropriate remediation and grants reinstatement
into the ONC Health IT Certification Program.
0
33. Amend Sec. 170.599 by:
0
a. Redesignating paragraph (b)(4) as paragraph (b)(5);
0
b. Adding new paragraph (b)(4); and
0
c. Revising newly redesignated paragraph (b)(5).
The addition and revision read as follows:
Sec. 170.599 Incorporation by Reference
* * * * *
(b) * * *
(4) ISO/IEC 17025:2017(E)--General requirements for the competence
of testing and calibration laboratories (Third Edition), 2017-11,
``ISO/IEC 17025,'' IBR approved for Sec. Sec. 170.520(b), and
170.524(a).
(5) ISO/IEC 17065:2012(E)--Conformity assessment--Requirements for
bodies certifying products, processes and services (First Edition),
2012, ``ISO/IEC 17065,'' IBR approved for Sec. Sec. 170.503 and
170.523(a).
0
34. Add part 171 to read as follows:
PART 171--INFORMATION BLOCKING
Subpart A--General Provisions
Sec.
171.100 Statutory basis and purpose.
171.101 Applicability.
171.102 Definitions.
171.103 Information blocking.
Subpart B--Exceptions That Involve Not Fulfilling Requests to Access,
Exchange, or use Electronic Health Information
171.200 Availability and effect of exceptions.
171.201 Preventing harm exception--when will an actor's practice
that is likely to interfere with the access, exchange, or use of
electronic health information in order to prevent harm not be
considered information blocking?
171.202 Privacy exception--when will an actor's practice of not
fulfilling a request to access, exchange, or use electronic health
information in order to protect an individual's privacy not be
considered information blocking?
171.203 Security exception--when will an actor's practice that is
likely to interfere with the access, exchange, or use of electronic
health information in order to protect the security of electronic
health information not be considered information blocking?
171.204 Infeasibility exception--when will an actor's practice of
not fulfilling a request to access, exchange, or use electronic
health information due to the infeasibility of the request not be
considered information blocking?
171.205 Health IT performance exception--when will an actor's
practice that is implemented to maintain or improve health IT
performance and that is likely to interfere with the access,
exchange, or use of electronic health information not be considered
information blocking?
Subpart C--Exceptions That Involve Procedures for Fulfilling Requests
to Access, Exchange, or use Electronic Health Information
171.300 Availability and effect of exceptions.
171.301 Content and manner exception--when will an actor's practice
of limiting the content of its response to or the manner in which it
fulfills a request to access, exchange, or use electronic health
information not be considered information blocking?
171.302 Fees exception--when will an actor's practice of charging
fees for accessing, exchanging, or using electronic health
information not be considered information blocking?
171.303 Licensing exception--when will an actor's practice to
license interoperability elements in order for electronic health
information to be accessed, exchanged, or used not be considered
information blocking?
Authority: 42 U.S.C. 300jj-52; 5 U.S.C. 552.
Subpart A--General Provisions
Sec. 171.100 Statutory basis and purpose.
(a) Basis. This part implements section 3022 of the Public Health
Service Act, 42 U.S.C. 300jj-52.
(b) Purpose. The purpose of this part is to establish exceptions
for reasonable and necessary activities that do not constitute
information blocking as defined by section 3022(a)(1) of the Public
Health Service Act, 42 U.S.C. 300jj-52.
Sec. 171.101 Applicability.
(a) This part applies to health care providers, health IT
developers of certified health IT, health information exchanges, and
health information networks, as those terms are defined in Sec.
171.102.
(b) Health care providers, health IT developers of certified health
IT, health information exchanges, and health information networks must
comply with this part on and after November 2, 2020.
Sec. 171.102 Definitions.
For purposes of this part:
Access means the ability or means necessary to make electronic
health information available for exchange or use.
Actor means a health care provider, health IT developer of
certified health IT, health information network or health information
exchange.
API Information Source is defined as it is in Sec. 170.404(c).
API User is defined as it is in Sec. 170.404(c).
Certified API Developer is defined as it is in Sec. 170.404(c).
Certified API technology is defined as it is in Sec. 170.404(c).
Electronic health information (EHI) means electronic protected
health information as defined in 45 CFR 160.103 to the extent that it
would be included in a designated record set as defined in 45 CFR
164.501, regardless of whether the group of records are used or
maintained by or for a covered entity as defined in 45 CFR 160.103, but
EHI shall not include:
(1) Psychotherapy notes as defined in 45 CFR 164.501; or
(2) Information compiled in reasonable anticipation of, or for use
in, a civil, criminal, or administrative action or proceeding.
Exchange means the ability for electronic health information to be
transmitted between and among different technologies, systems,
platforms, or networks.
Fee means any present or future obligation to pay money or provide
any other thing of value.
Health care provider has the same meaning as ``health care
provider'' in 42 U.S.C. 300jj.
Health information network or health information exchange means an
individual or entity that determines,
[[Page 25956]]
controls, or has the discretion to administer any requirement, policy,
or agreement that permits, enables, or requires the use of any
technology or services for access, exchange, or use of electronic
health information:
(1) Among more than two unaffiliated individuals or entities (other
than the individual or entity to which this definition might apply)
that are enabled to exchange with each other; and
(2) That is for a treatment, payment, or health care operations
purpose, as such terms are defined in 45 CFR 164.501 regardless of
whether such individuals or entities are subject to the requirements of
45 CFR parts 160 and 164.
Health IT developer of certified health IT means an individual or
entity, other than a health care provider that self-develops health IT
for its own use, that develops or offers health information technology
(as that term is defined in 42 U.S.C. 300jj(5)) and which has, at the
time it engages in a practice that is the subject of an information
blocking claim, one or more Health IT Modules certified under a program
for the voluntary certification of health information technology that
is kept or recognized by the National Coordinator pursuant to 42 U.S.C.
300jj-11(c)(5) (ONC Health IT Certification Program).
Information blocking is defined as it is in Sec. 171.103.
Interfere with or interference means to prevent, materially
discourage, or otherwise inhibit.
Interoperability element means hardware, software, integrated
technologies or related licenses, technical information, privileges,
rights, intellectual property, upgrades, or services that:
(1) May be necessary to access, exchange, or use electronic health
information; and
(2) Is/Are controlled by the actor, which includes the ability to
confer all rights and authorizations necessary to use the element to
enable the access, exchange, or use of electronic health information.
Permissible purpose means a purpose for which a person is
authorized, permitted, or required to access, exchange, or use
electronic health information under applicable law.
Person is defined as it is in 45 CFR 160.103.
Practice means an act or omission by an actor.
Use means the ability for electronic health information, once
accessed or exchanged, to be understood and acted upon.
Sec. 171.103 Information blocking.
(a) Information blocking means a practice that--
(1) Except as required by law or covered by an exception set forth
in subpart B or subpart C of this part, is likely to interfere with
access, exchange, or use of electronic health information; and
(2) If conducted by a health information technology developer,
health information network or health information exchange, such
developer, network or exchange knows, or should know, that such
practice is likely to interfere with, prevent, or materially discourage
access, exchange, or use of electronic health information; or
(3) If conducted by a health care provider, such provider knows
that such practice is unreasonable and is likely to interfere with,
prevent, or materially discourage access, exchange, or use of
electronic health information.
(b) Until May 2, 2022, electronic health information for purposes
of paragraph (a) of this section is limited to the electronic health
information identified by the data elements represented in the USCDI
standard adopted in Sec. 170.213.
Subpart B--Exceptions That Involve Not Fulfilling Requests To
Access, Exchange, or Use Electronic Health Information
Sec. 171.200 Availability and effect of exceptions.
A practice shall not be treated as information blocking if the
actor satisfies an exception to the information blocking provision as
set forth in this subpart B by meeting all applicable requirements and
conditions of the exception at all relevant times.
Sec. 171.201 Preventing harm exception--when will an actor's
practice that is likely to interfere with the access, exchange, or use
of electronic health information in order to prevent harm not be
considered information blocking?
An actor's practice that is likely to interfere with the access,
exchange, or use of electronic health information in order to prevent
harm will not be considered information blocking when the practice
meets the conditions in paragraphs (a) and (b) of this section,
satisfies at least one condition from each of paragraphs (c), (d), and
(f) of this section, and also meets the condition in paragraph (e) of
this section when applicable.
(a) Reasonable belief. The actor engaging in the practice must hold
a reasonable belief that the practice will substantially reduce a risk
of harm to a patient or another natural person that would otherwise
arise from the access, exchange, or use of electronic health
information affected by the practice. For purposes of this section,
``patient'' means a natural person who is the subject of the electronic
health information affected by the practice.
(b) Practice breadth. The practice must be no broader than
necessary to substantially reduce the risk of harm that the practice is
implemented to reduce.
(c) Type of risk. The risk of harm must:
(1) Be determined on an individualized basis in the exercise of
professional judgment by a licensed health care professional who has a
current or prior clinician-patient relationship with the patient whose
electronic health information is affected by the determination; or
(2) Arise from data that is known or reasonably suspected to be
misidentified or mismatched, corrupt due to technical failure, or
erroneous for another reason.
(d) Type of harm. The type of harm must be one that could serve as
grounds for a covered entity (as defined in Sec. 160.103 of this
title) to deny access (as the term ``access'' is used in part 164 of
this title) to an individual's protected health information under:
(1) Section 164.524(a)(3)(iii) of this title where the practice is
likely to, or in fact does, interfere with access, exchange, or use (as
these terms are defined in Sec. 171.102) of the patient's electronic
health information by their legal representative (including but not
limited to personal representatives recognized pursuant to 45 CFR
164.502) and the practice is implemented pursuant to an individualized
determination of risk of harm consistent with paragraph (c)(1) of this
section;
(2) Section 164.524(a)(3)(ii) of this title where the practice is
likely to, or in fact does, interfere with the patient's or their legal
representative's access to, use or exchange (as these terms are defined
in Sec. 171.102) of information that references another natural person
and the practice is implemented pursuant to an individualized
determination of risk of harm consistent with paragraph (c)(1) of this
section;
(3) Section 164.524(a)(3)(i) of this title where the practice is
likely to, or in fact does, interfere with the patient's access,
exchange, or use (as these terms are defined in Sec. 171.102) of their
own electronic health information, regardless of whether the risk of
harm that the practice is implemented to substantially reduce is
consistent with paragraph (c)(1) or (2) of this section; or
[[Page 25957]]
(4) Section 164.524(a)(3)(i) of this title where the practice is
likely to, or in fact does, interfere with a legally permissible
access, exchange, or use (as these terms are defined in Sec. 171.102)
of electronic health information not described in paragraph (d)(1),
(2), or (3) of this section, and regardless of whether the risk of harm
the practice is implemented to substantially reduce is consistent with
paragraph (c)(1) or (2) of this section.
(e) Patient right to request review of individualized determination
of risk of harm. Where the risk of harm is consistent with paragraph
(c)(1) of this section, the actor must implement the practice in a
manner consistent with any rights the individual patient whose
electronic health information is affected may have under Sec.
164.524(a)(4) of this title, or any Federal, State, or tribal law, to
have the determination reviewed and potentially reversed.
(f) Practice implemented based on an organizational policy or a
determination specific to the facts and circumstances. The practice
must be consistent with an organizational policy that meets paragraph
(f)(1) of this section or, in the absence of an organizational policy
applicable to the practice or to its use in particular circumstances,
the practice must be based on a determination that meets paragraph
(f)(2) of this section.
(1) An organizational policy must:
(i) Be in writing;
(ii) Be based on relevant clinical, technical, and other
appropriate expertise;
(iii) Be implemented in a consistent and non-discriminatory manner;
and
(iv) Conform each practice to the conditions in paragraphs (a) and
(b) of this section, as well as the conditions in paragraphs (c)
through (e) of this section that are applicable to the practice and its
use.
(2) A determination must:
(i) Be based on facts and circumstances known or reasonably
believed by the actor at the time the determination was made and while
the practice remains in use; and
(ii) Be based on expertise relevant to implementing the practice
consistent with the conditions in paragraphs (a) and (b) of this
section, as well as the conditions in paragraphs (c) through (e) of
this section that are applicable to the practice and its use in
particular circumstances.
Sec. 171.202 Privacy exception--when will an actor's practice of not
fulfilling a request to access, exchange, or use electronic health
information in order to protect an individual's privacy not be
considered information blocking?
An actor's practice of not fulfilling a request to access,
exchange, or use electronic health information in order to protect an
individual's privacy will not be considered information blocking when
the practice meets all of the requirements of at least one of the sub-
exceptions in paragraphs (b) through (e) of this section.
(a) Definitions in this section. (1) The term HIPAA Privacy Rule as
used in this section means 45 CFR parts 160 and 164.
(2) The term individual as used in this section means one or more
of the following--
(i) An individual as defined by 45 CFR 160.103.
(ii) Any other natural person who is the subject of the electronic
health information being accessed, exchanged, or used.
(iii) A person who legally acts on behalf of a person described in
paragraph (a)(1) or (2) of this section in making decisions related to
health care as a personal representative, in accordance with 45 CFR
164.502(g).
(iv) A person who is a legal representative of and can make health
care decisions on behalf of any person described in paragraph (a)(1) or
(2) of this section.
(v) An executor, administrator, or other person having authority to
act on behalf of a deceased person described in paragraph (a)(1) or (2)
of this section or the individual's estate under State or other law.
(b) Sub-exception--precondition not satisfied. To qualify for the
exception on the basis that State or Federal law requires one or more
preconditions for providing access, exchange, or use of electronic
health information that have not been satisfied, the following
requirements must be met--
(1) The actor's practice is tailored to the applicable precondition
not satisfied, is implemented in a consistent and non-discriminatory
manner, and either:
(i) Conforms to the actor's organizational policies and procedures
that:
(A) Are in writing;
(B) Specify the criteria to be used by the actor to determine when
the precondition would be satisfied and, as applicable, the steps that
the actor will take to satisfy the precondition; and
(C) Are implemented by the actor, including by providing training
on the policies and procedures; or
(ii) Are documented by the actor, on a case-by-case basis,
identifying the criteria used by the actor to determine when the
precondition would be satisfied, any criteria that were not met, and
the reason why the criteria were not met.
(2) If the precondition relies on the provision of a consent or
authorization from an individual and the actor has received a version
of such a consent or authorization that does not satisfy all elements
of the precondition required under applicable law, the actor must:
(i) Use reasonable efforts within its control to provide the
individual with a consent or authorization form that satisfies all
required elements of the precondition or provide other reasonable
assistance to the individual to satisfy all required elements of the
precondition; and
(ii) Not improperly encourage or induce the individual to withhold
the consent or authorization.
(3) For purposes of determining whether the actor's privacy
policies and procedures and actions satisfy the requirements of
paragraphs (b)(1)(i) and (b)(2) above when the actor's operations are
subject to multiple laws which have inconsistent preconditions, they
shall be deemed to satisfy the requirements of the paragraphs if the
actor has adopted uniform privacy policies and procedures to address
the more restrictive preconditions.
(c) Sub-exception--health IT developer of certified health IT not
covered by HIPAA. If the actor is a health IT developer of certified
health IT that is not required to comply with the HIPAA Privacy Rule,
when engaging in a practice that promotes the privacy interests of an
individual, the actor's organizational privacy policies must have been
disclosed to the individuals and entities that use the actor's product
or service before they agreed to use them, and must implement the
practice according to a process described in the organizational privacy
policies. The actor's organizational privacy policies must:
(1) Comply with State and Federal laws, as applicable;
(2) Be tailored to the specific privacy risk or interest being
addressed; and
(3) Be implemented in a consistent and non-discriminatory manner.
(d) Sub-exception--denial of an individual's request for their
electronic health information consistent with 45 CFR 164.524(a)(1) and
(2). If an individual requests electronic health information under the
right of access provision under 45 CFR 164.524(a)(1) from an actor that
must comply with 45 CFR 164.524(a)(1), the actor's practice
[[Page 25958]]
must be consistent with 45 CFR 164.524(a)(2).
(e) Sub-exception--respecting an individual's request not to share
information. Unless otherwise required by law, an actor may elect not
to provide access, exchange, or use of an individual's electronic
health information if the following requirements are met--
(1) The individual requests that the actor not provide such access,
exchange, or use of electronic health information without any improper
encouragement or inducement of the request by the actor;
(2) The actor documents the request within a reasonable time
period;
(3) The actor's practice is implemented in a consistent and non-
discriminatory manner; and
(4) An actor may terminate an individual's request for a
restriction to not provide such access, exchange, or use of the
individual's electronic health information only if:
(i) The individual agrees to the termination in writing or requests
the termination in writing;
(ii) The individual orally agrees to the termination and the oral
agreement is documented by the actor; or
(iii) The actor informs the individual that it is terminating its
agreement to not provide such access, exchange, or use of the
individual's electronic health information except that such termination
is:
(A) Not effective to the extent prohibited by applicable Federal or
State law; and
(B) Only applicable to electronic health information created or
received after the actor has so informed the individual of the
termination.
Sec. 171.203 Security exception--when will an actor's practice that
is likely to interfere with the access, exchange, or use of electronic
health information in order to protect the security of electronic
health information not be considered information blocking?
An actor's practice that is likely to interfere with the access,
exchange, or use of electronic health information in order to protect
the security of electronic health information will not be considered
information blocking when the practice meets the conditions in
paragraphs (a), (b), and (c) of this section, and in addition meets
either the condition in paragraph (d) of this section or the condition
in paragraph (e) of this section.
(a) The practice must be directly related to safeguarding the
confidentiality, integrity, and availability of electronic health
information.
(b) The practice must be tailored to the specific security risk
being addressed.
(c) The practice must be implemented in a consistent and non-
discriminatory manner.
(d) If the practice implements an organizational security policy,
the policy must--
(1) Be in writing;
(2) Have been prepared on the basis of, and be directly responsive
to, security risks identified and assessed by or on behalf of the
actor;
(3) Align with one or more applicable consensus-based standards or
best practice guidance; and
(4) Provide objective timeframes and other parameters for
identifying, responding to, and addressing security incidents.
(e) If the practice does not implement an organizational security
policy, the actor must have made a determination in each case, based on
the particularized facts and circumstances, that:
(1) The practice is necessary to mitigate the security risk to
electronic health information; and
(2) There are no reasonable and appropriate alternatives to the
practice that address the security risk that are less likely to
interfere with, prevent, or materially discourage access, exchange or
use of electronic health information.
Sec. 171.204 Infeasibility exception--when will an actor's practice
of not fulfilling a request to access, exchange, or use electronic
health information due to the infeasibility of the request not be
considered information blocking?
An actor's practice of not fulfilling a request to access,
exchange, or use electronic health information due to the infeasibility
of the request will not be considered information blocking when the
practice meets one of the conditions in paragraph (a) of this section
and meets the requirements in paragraph (b) of this section.
(a) Conditions--(1) Uncontrollable events. The actor cannot fulfill
the request for access, exchange, or use of electronic health
information due to a natural or human-made disaster, public health
emergency, public safety incident, war, terrorist attack, civil
insurrection, strike or other labor unrest, telecommunication or
internet service interruption, or act of military, civil or regulatory
authority.
(2) Segmentation. The actor cannot fulfill the request for access,
exchange, or use of electronic health information because the actor
cannot unambiguously segment the requested electronic health
information from electronic health information that:
(i) Cannot be made available due to an individual's preference or
because the electronic health information cannot be made available by
law; or
(ii) May be withheld in accordance with Sec. 171.201.
(3) Infeasible under the circumstances. (i) The actor demonstrates,
prior to responding to the request pursuant to paragraph (b) of this
section, through a contemporaneous written record or other
documentation its consistent and non-discriminatory consideration of
the following factors that led to its determination that complying with
the request would be infeasible under the circumstances:
(A) The type of electronic health information and the purposes for
which it may be needed;
(B) The cost to the actor of complying with the request in the
manner requested;
(C) The financial and technical resources available to the actor;
(D) Whether the actor's practice is non-discriminatory and the
actor provides the same access, exchange, or use of electronic health
information to its companies or to its customers, suppliers, partners,
and other persons with whom it has a business relationship;
(E) Whether the actor owns or has control over a predominant
technology, platform, health information exchange, or health
information network through which electronic health information is
accessed or exchanged; and
(F) Why the actor was unable to provide access, exchange, or use of
electronic health information consistent with the exception in Sec.
171.301.
(ii) In determining whether the circumstances were infeasible under
paragraph (a)(3)(i) of this section, it shall not be considered whether
the manner requested would have:
(A) Facilitated competition with the actor.
(B) Prevented the actor from charging a fee or resulted in a
reduced fee.
(b) Responding to requests. If an actor does not fulfill a request
for access, exchange, or use of electronic health information for any
of the reasons provided in paragraph (a) of this section, the actor
must, within ten business days of receipt of the request, provide to
the requestor in writing the reason(s) why the request is infeasible.
[[Page 25959]]
Sec. 171.205 Health IT performance exception--when will an actor's
practice that is implemented to maintain or improve health IT
performance and that is likely to interfere with the access, exchange,
or use of electronic health information not be considered information
blocking?
An actor's practice that is implemented to maintain or improve
health IT performance and that is likely to interfere with the access,
exchange, or use of electronic health information will not be
considered information blocking when the practice meets a condition in
paragraph (a), (b), (c), or (d) of this section, as applicable to the
particular practice and the reason for its implementation.
(a) Maintenance and improvements to health IT. When an actor
implements a practice that makes health IT under that actor's control
temporarily unavailable, or temporarily degrades the performance of
health IT, in order to perform maintenance or improvements to the
health IT, the actor's practice must be--
(1) Implemented for a period of time no longer than necessary to
complete the maintenance or improvements for which the health IT was
made unavailable or the health IT's performance degraded;
(2) Implemented in a consistent and non-discriminatory manner; and
(3) If the unavailability or degradation is initiated by a health
IT developer of certified health IT, health information exchange, or
health information network:
(i) Planned. Consistent with existing service level agreements
between the individual or entity to whom the health IT developer of
certified health IT, health information exchange, or health information
network supplied the health IT; or
(ii) Unplanned. Consistent with existing service level agreements
between the individual or entity; or agreed to by the individual or
entity to whom the health IT developer of certified health IT, health
information exchange, or health information network supplied the health
IT.
(b) Assured level of performance. An actor may take action against
a third-party application that is negatively impacting the health IT's
performance, provided that the practice is--
(1) For a period of time no longer than necessary to resolve any
negative impacts;
(2) Implemented in a consistent and non-discriminatory manner; and
(3) Consistent with existing service level agreements, where
applicable.
(c) Practices that prevent harm. If the unavailability of health IT
for maintenance or improvements is initiated by an actor in response to
a risk of harm to a patient or another person, the actor does not need
to satisfy the requirements of this section, but must comply with all
requirements of Sec. 171.201 at all relevant times to qualify for an
exception.
(d) Security-related practices. If the unavailability of health IT
for maintenance or improvements is initiated by an actor in response to
a security risk to electronic health information, the actor does not
need to satisfy the requirements of this section, but must comply with
all requirements of Sec. 171.203 at all relevant times to qualify for
an exception.
Subpart C--Exceptions That Involve Procedures for Fulfilling
Requests To Access, Exchange, or Use Electronic Health Information
Sec. 171.300 Availability and effect of exceptions.
A practice shall not be treated as information blocking if the
actor satisfies an exception to the information blocking provision as
set forth in this subpart C by meeting all applicable requirements and
conditions of the exception at all relevant times.
Sec. 171.301 Content and manner exception--when will an actor's
practice of limiting the content of its response to or the manner in
which it fulfills a request to access, exchange, or use electronic
health information not be considered information blocking?
An actor's practice of limiting the content of its response to or
the manner in which it fulfills a request to access, exchange, or use
electronic health information will not be considered information
blocking when the practice meets all of the following conditions.
(a) Content condition--electronic health information. An actor must
respond to a request to access, exchange, or use electronic health
information with--
(1) USCDI. For up to May 2, 2022, at a minimum, the electronic
health information identified by the data elements represented in the
USCDI standard adopted in Sec. 170.213.
(2) All electronic health information. On and after May 2, 2022,
electronic health information as defined in Sec. 171.102.
(b) Manner condition--(1) Manner requested. (i) An actor must
fulfill a request described in paragraph (a) of this section in any
manner requested, unless the actor is technically unable to fulfill the
request or cannot reach agreeable terms with the requestor to fulfill
the request.
(ii) If an actor fulfills a request described in paragraph (a) of
this section in any manner requested:
(A) Any fees charged by the actor in relation to fulfilling the
response are not required to satisfy the exception in Sec. 171.302;
and
(B) Any license of interoperability elements granted by the actor
in relation to fulfilling the request is not required to satisfy the
exception in Sec. 171.303.
(2) Alternative manner. If an actor does not fulfill a request
described in paragraph (a) of this section in any manner requested
because it is technically unable to fulfill the request or cannot reach
agreeable terms with the requestor to fulfill the request, the actor
must fulfill the request in an alternative manner, as follows:
(i) The actor must fulfill the request without unnecessary delay in
the following order of priority, starting with paragraph (b)(2)(i)(A)
of this section and only proceeding to the next consecutive paragraph
if the actor is technically unable to fulfill the request in the manner
identified in a paragraph.
(A) Using technology certified to standard(s) adopted in part 170
that is specified by the requestor.
(B) Using content and transport standards specified by the
requestor and published by:
(1) The Federal Government; or
(2) A standards developing organization accredited by the American
National Standards Institute.
(C) Using an alternative machine-readable format, including the
means to interpret the electronic health information, agreed upon with
the requestor.
(ii) Any fees charged by the actor in relation to fulfilling the
request are required to satisfy the exception in Sec. 171.302.
(iii) Any license of interoperability elements granted by the actor
in relation to fulfilling the request is required to satisfy the
exception in Sec. 171.303.
Sec. 171.302 Fees exception--when will an actor's practice of
charging fees for accessing, exchanging, or using electronic health
information not be considered information blocking?
An actor's practice of charging fees, including fees that result in
a reasonable profit margin, for accessing, exchanging, or using
electronic health information will not be considered information
blocking when the practice meets the conditions in paragraph (a) of
this section, does not include any of the excluded fees in paragraph
(b) of this section, and, as applicable, meets the condition in
paragraph (c) of this section.
[[Page 25960]]
(a) Basis for fees condition. (1) The fees an actor charges must
be--
(i) Based on objective and verifiable criteria that are uniformly
applied for all similarly situated classes of persons or entities and
requests;
(ii) Reasonably related to the actor's costs of providing the type
of access, exchange, or use of electronic health information to, or at
the request of, the person or entity to whom the fee is charged;
(iii) Reasonably allocated among all similarly situated persons or
entities to whom the technology or service is supplied, or for whom the
technology is supported; and
(iv) Based on costs not otherwise recovered for the same instance
of service to a provider and third party.
(2) The fees an actor charges must not be based on--
(i) Whether the requestor or other person is a competitor,
potential competitor, or will be using the electronic health
information in a way that facilitates competition with the actor;
(ii) Sales, profit, revenue, or other value that the requestor or
other persons derive or may derive from the access, exchange, or use of
the electronic health information;
(iii) Costs the actor incurred due to the health IT being designed
or implemented in a non-standard way, unless the requestor agreed to
the fee associated with the non-standard design or implementation to
access, exchange, or use the electronic health information;
(iv) Costs associated with intangible assets other than the actual
development or acquisition costs of such assets;
(v) Opportunity costs unrelated to the access, exchange, or use of
electronic health information; or
(vi) Any costs that led to the creation of intellectual property,
if the actor charged a royalty for that intellectual property pursuant
to Sec. 171.303 and that royalty included the development costs for
the creation of the intellectual property.
(b) Excluded fees condition. This exception does not apply to--
(1) A fee prohibited by 45 CFR 164.524(c)(4);
(2) A fee based in any part on the electronic access of an
individual's EHI by the individual, their personal representative, or
another person or entity designated by the individual;
(3) A fee to perform an export of electronic health information via
the capability of health IT certified to Sec. 170.315(b)(10) of this
subchapter for the purposes of switching health IT or to provide
patients their electronic health information; and
(4) A fee to export or convert data from an EHR technology that was
not agreed to in writing at the time the technology was acquired.
(c) Compliance with the Conditions of Certification condition.
Notwithstanding any other provision of this exception, if the actor is
a health IT developer subject to the Conditions of Certification in
Sec. 170.402(a)(4), Sec. 170.404, or both of this subchapter, the
actor must comply with all requirements of such conditions for all
practices and at all relevant times.
(d) Definition of Electronic access. The following definition
applies to this section:
Electronic access means an internet-based method that makes
electronic health information available at the time the electronic
health information is requested and where no manual effort is required
to fulfill the request.
Sec. 171.303 Licensing exception--when will an actor's practice to
license interoperability elements in order for electronic health
information to be accessed, exchanged, or used not be considered
information blocking?
An actor's practice to license interoperability elements for
electronic health information to be accessed, exchanged, or used will
not be considered information blocking when the practice meets all of
the following conditions.
(a) Negotiating a license conditions. Upon receiving a request to
license an interoperability element for the access, exchange, or use of
electronic health information, the actor must--
(1) Begin license negotiations with the requestor within 10
business days from receipt of the request; and
(2) Negotiate a license with the requestor, subject to the
licensing conditions in paragraph (b) of this section, within 30
business days from receipt of the request.
(b) Licensing conditions. The license provided for the
interoperability element(s) needed to access, exchange, or use
electronic health information must meet the following conditions:
(1) Scope of rights. The license must provide all rights necessary
to:
(i) Enable the access, exchange, or use of electronic health
information; and
(ii) Achieve the intended access, exchange, or use of electronic
health information via the interoperability element(s).
(2) Reasonable royalty. If the actor charges a royalty for the use
of the interoperability elements described in paragraph (a) of this
section, the royalty must be reasonable and comply with the following
requirements:
(i) The royalty must be non-discriminatory, consistent with
paragraph (c)(3) of this section.
(ii) The royalty must be based solely on the independent value of
the actor's technology to the licensee's products, not on any strategic
value stemming from the actor's control over essential means of
accessing, exchanging, or using electronic health information.
(iii) If the actor has licensed the interoperability element
through a standards developing organization in accordance with such
organization's policies regarding the licensing of standards-essential
technologies on terms consistent with those in this exception, the
actor may charge a royalty that is consistent with such policies.
(iv) An actor may not charge a royalty for intellectual property if
the actor recovered any development costs pursuant to Sec. 171.302
that led to the creation of the intellectual property.
(3) Non-discriminatory terms. The terms (including royalty terms)
on which the actor licenses and otherwise provides the interoperability
elements must be non-discriminatory and comply with the following
requirements:
(i) The terms must be based on objective and verifiable criteria
that are uniformly applied for all similarly situated classes of
persons and requests.
(ii) The terms must not be based in any part on--
(A) Whether the requestor or other person is a competitor,
potential competitor, or will be using electronic health information
obtained via the interoperability elements in a way that facilitates
competition with the actor; or
(B) The revenue or other value the requestor may derive from
access, exchange, or use of electronic health information obtained via
the interoperability elements.
(4) Collateral terms. The actor must not require the licensee or
its agents or contractors to do, or to agree to do, any of the
following--
(i) Not compete with the actor in any product, service, or market.
(ii) Deal exclusively with the actor in any product, service, or
market.
(iii) Obtain additional licenses, products, or services that are
not related to or can be unbundled from the requested interoperability
elements.
(iv) License, grant, assign, or transfer to the actor any
intellectual property of the licensee.
(v) Pay a fee of any kind whatsoever, except as described in
paragraph (b)(2) of this section, unless the practice meets
[[Page 25961]]
the requirements of the exception in Sec. 171.302.
(5) Non-disclosure agreement. The actor may require a reasonable
non-disclosure agreement that is no broader than necessary to prevent
unauthorized disclosure of the actor's trade secrets, provided--
(i) The agreement states with particularity all information the
actor claims as trade secrets; and
(ii) Such information meets the definition of a trade secret under
applicable law.
(c) Additional conditions relating to the provision of
interoperability elements. The actor must not engage in any practice
that has any of the following purposes or effects.
(1) Impeding the efficient use of the interoperability elements to
access, exchange, or use electronic health information for any
permissible purpose.
(2) Impeding the efficient development, distribution, deployment,
or use of an interoperable product or service for which there is actual
or potential demand.
(3) Degrading the performance or interoperability of the licensee's
products or services, unless necessary to improve the actor's
technology and after affording the licensee a reasonable opportunity to
update its technology to maintain interoperability.
Alex M. Azar II,
Secretary, Department of Health and Human Services.
[FR Doc. 2020-07419 Filed 4-21-20; 4:15 pm]
BILLING CODE 4150-45-P