Proposed Rule2024-14975
Health Data, Technology, and Interoperability: Patient Engagement, Information Sharing, and Public Health Interoperability
Primary source
Metadata and text below are from the Federal Register, a public-domain U.S. government work. Always verify the official published version before relying on it for any legal matter.
Published
August 5, 2024
Issuing agencies
Health and Human Services Department
Abstract
This proposed rule seeks to advance interoperability, improve transparency, and support the access, exchange, and use of electronic health information through proposals for: standards adoption; adoption of certification criteria to advance public health data exchange; expanded uses of certified application programming interfaces, such as for electronic prior authorization, patient access, care management, and care coordination; and information sharing under the information blocking regulations. It proposes to establish a new baseline version of the United States Core Data for Interoperability. The proposed rule would update the ONC Health IT Certification Program to enhance interoperability and optimize certification processes to reduce burden and costs. The proposed rule would also implement certain provisions related to the Trusted Exchange Framework and Common Agreement (TEFCA), which would support the reliability, privacy, security, and trust within TEFCA.
Full Text
<html>
<head>
<title>Federal Register, Volume 89 Issue 150 (Monday, August 5, 2024)</title>
</head>
<body><pre>
[Federal Register Volume 89, Number 150 (Monday, August 5, 2024)]
[Proposed Rules]
[Pages 63498-63811]
From the Federal Register Online via the Government Publishing Office [<a href="http://www.gpo.gov">www.gpo.gov</a>]
[FR Doc No: 2024-14975]
[[Page 63497]]
Vol. 89
Monday,
No. 150
August 5, 2024
Part II
Department of Health and Human Services
-----------------------------------------------------------------------
45 CFR Parts 170, 171, and 172
Health Data, Technology, and Interoperability: Patient Engagement,
Information Sharing, and Public Health Interoperability; Proposed Rule
Federal Register / Vol. 89 , No. 150 / Monday, August 5, 2024 /
Proposed Rules
[[Page 63498]]
-----------------------------------------------------------------------
DEPARTMENT OF HEALTH AND HUMAN SERVICES
Office of the Secretary
45 CFR Parts 170, 171, and 172
RIN 0955-AA06
Health Data, Technology, and Interoperability: Patient
Engagement, Information Sharing, and Public Health Interoperability
AGENCY: Office of the National Coordinator for Health Information
Technology (ONC), Department of Health and Human Services (HHS).
ACTION: Proposed rule.
-----------------------------------------------------------------------
SUMMARY: This proposed rule seeks to advance interoperability, improve
transparency, and support the access, exchange, and use of electronic
health information through proposals for: standards adoption; adoption
of certification criteria to advance public health data exchange;
expanded uses of certified application programming interfaces, such as
for electronic prior authorization, patient access, care management,
and care coordination; and information sharing under the information
blocking regulations. It proposes to establish a new baseline version
of the United States Core Data for Interoperability. The proposed rule
would update the ONC Health IT Certification Program to enhance
interoperability and optimize certification processes to reduce burden
and costs. The proposed rule would also implement certain provisions
related to the Trusted Exchange Framework and Common Agreement (TEFCA),
which would support the reliability, privacy, security, and trust
within TEFCA.
DATES: To be assured consideration, written or electronic comments must
be received at one of the addresses provided below, no later than 5
p.m. Eastern Time on October 4, 2024.
ADDRESSES: You may submit comments, identified by RIN 0955-AA06, by any
of the following methods (please do not submit duplicate comments).
Because of staff and resource limitations, we cannot accept comments by
facsimile (FAX) transmission.
<bullet> Federal eRulemaking Portal: Follow the instructions for
submitting comments. Attachments should be in Microsoft Word, Microsoft
Excel, or Adobe PDF; however, we prefer Microsoft Word. <a href="http://www.regulations.gov">http://www.regulations.gov</a>.
<bullet> Regular, Express, or Overnight Mail: Department of Health
and Human Services, Office of the National Coordinator for Health
Information Technology, Attention: Health Data, Technology, and
Interoperability: Patient Engagement, Information Sharing, and Public
Health Interoperability Proposed Rule, Mary E. Switzer Building, Mail
Stop: 7033A, 330 C Street SW, Washington, DC 20201. Please submit one
original and two copies.
<bullet> Hand Delivery or Courier: Office of the National
Coordinator for Health Information Technology, Attention: Health Data,
Technology, and Interoperability: Patient Engagement, Information
Sharing, and Public Health Interoperability Proposed Rule, Mary E.
Switzer Building, Mail Stop: 7033A, 330 C Street SW, Washington, DC
20201. Please submit one original and two copies. (Because access to
the interior of the Mary E. Switzer Building is not readily available
to persons without Federal government identification, commenters are
encouraged to leave their comments in the mail drop slots located in
the main lobby of the building.)
Inspection of Public Comments: All comments received before the
close of the comment period will be available for public inspection,
including any personally identifiable or confidential business
information that is included in a comment. Please do not include
anything in your comment submission that you do not wish to share with
the general public. Such information includes, but is not limited to,
the following: a person's social security number; date of birth;
driver's license number; state identification number or foreign country
equivalent; passport number; financial account number; credit or debit
card number; any personal health information; or any business
information that could be considered proprietary. We will post all
comments that are received before the close of the comment period at
<a href="http://www.regulations.gov">http://www.regulations.gov</a>.
Docket: For access to the docket to read background documents,
comments received, or the plain-language summary of the proposed rule
of not more than 100 words in length required by the Providing
Accountability Through Transparency Act of 2023, go to <a href="http://www.regulations.gov">http://www.regulations.gov</a> or the Department of Health and Human Services,
Office of the National Coordinator for Health Information Technology,
Mary E. Switzer Building, Mail Stop: 7033A, 330 C Street SW,
Washington, DC 20201 (call ahead to the contact listed below to arrange
for inspection).
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
1. ONC Health IT Certification Program Updates
a. New and Revised Standards and Certification Criteria
i. The United States Core Data for Interoperability Version 4
(USCDI v4)
ii. SMART App Launch 2.2
iii. User-Access Brands and Endpoints
iv. Standards for Encryption and Decryption of Electronic Health
Information
v. Minimum Standards Code Sets Updates
vi. New Imaging Requirements for Health IT Modules
vii. Revised Clinical Information Reconciliation and
Incorporation Criterion
viii. Revised Electronic Prescribing Certification Criterion
ix. New Real-Time Prescription Benefit Criterion
x. Electronic Health Information (EHI) Export--Single Patient
EHI Export Exemption
xi. Revised End-User Device Encryption Criterion
xii. Revised Criterion for Encrypt Authentication Credentials
xiii. Health IT Modules Supporting Public Health Data Exchange
xiv. Bulk Data Enhancements
xv. New Requirements to Support Dynamic Client Registration
Protocol in the Program
xvi. New Certification Criteria for Modular API Capabilities
xvii. Multi-factor Authentication Criterion
xviii. Revised Computerized Provider Order Entry--Laboratory
Criterion
xix. Revised Standardized API for Patient and Population
Services Criterion to Align with Modular API Capabilities
xx. Patient, Provider, and Payer APIs
2. Conditions and Maintenance of Certification Requirements--
Insights and Attestations
a. Insights Condition and Maintenance of Certification
Requirements
b. Attestations Condition and Maintenance of Certification
Requirements
3. Administrative Updates
4. Correction--Privacy and Security Certification Framework
5. Information Blocking Enhancements
6. Trusted Exchange Framework and Common Agreement<SUP>TM</SUP>
C. Severability
D. Costs and Benefits
II. Background
A. Statutory Basis
1. Standards, Implementation Specifications, and Certification
Criteria
2. ONC Health IT Certification Program Rules
[[Page 63499]]
B. Regulatory History
III. ONC Health IT Certification Program Updates
A. Standards and Implementations Specifications
1. National Technology Transfer and Advancement Act
2. Compliance with Adopted Standards and Implementation
Specifications
3. ``Reasonably Available'' to Interested Parties
B. New and Revised Standards and Certification Criteria
1. The United States Core Data for Interoperability Version 4
(USCDI v4)
a. Background and USCDI v4 Update
b. Certification Criteria that Reference USCDI
2. SMART App Launch 2.2
3. User-Access Brands and Endpoints
4. Standards for Encryption and Decryption of Electronic Health
Information
a. Background
b. Proposal
5. Minimum Standards Code Sets Updates
6. New Imaging Requirements for Health IT Modules
7. Revised Clinical Information Reconciliation and Incorporation
Criterion
8. Revised Electronic Prescribing Certification Criterion
a. Electronic Prescribing Standard
b. Proposed Transactions c. Additional Proposals
9. New Real-Time Prescription Benefit Criterion
a. Background
b. Revision to the Base EHR Definition and Health IT Module
Dependent Criteria Requirements
c. Real-Time Prescription Benefit Standard
d. Sending and Receiving Real-Time Prescription Benefit
Information
e. Additional Topics
10. Electronic Health Information (EHI) Export--Single Patient
EHI Export Exemption
a. Background
b. Proposal for EHI Export
c. Proposal for Associated Assurances Requirements for Single
Patient EHI Export Exemption
11. Revised End-User Device Encryption Criterion
a. Background
b. Proposal
12. Revised Criterion for Encrypt Authentication Credentials
a. Background
b. Proposal
13. Health IT Modules Supporting Public Health Data Exchange
a. Background
b. Regulatory History
c. Proposal Overview
d. Revised Certification Criteria for Health IT Modules
Supporting Public Health Data Exchange
e. New Certification Criteria for Health IT Modules Supporting
Public Health Data Exchange
f. New Standardized API for Public Health Data Exchange
14. Bulk Data Enhancements
a. Background
b. Proposal
15. New Requirements to Support Dynamic Client Registration
Protocol in the Program
a. Background to Dynamic Client Registration
b. Adoption of HL7 UDAP Security IG v1
c. Revision of Standardized API for Patient and Population
Services to Support Dynamic Client Registration
d. Removal of Reference to OpenID Connect Core Specification
e. API Conditions and Maintenance Updates to Support Dynamic
Client Registration
16. New Certification Criteria for Modular API Capabilities
a. Proposal Background
b. Modular API Capabilities Certification Criteria
17. Multi-Factor Authentication Criterion
a. Background
b. Proposal
18. Revised Computerized Provider Order Entry--Laboratory
Criterion
19. Revised Standardized API for Patient and Population Services
Criterion to Align with Modular API Capabilities
a. Proposed Revisions for Registration
b. Proposed Revisions for Patient and User Access
c. Proposed Revisions for System Access
d. Other Restructured Requirements
e. Proposed Requirements for System Read and Search API,
Subscriptions, and Workflow Triggers for Decision Support
Interventions
20. Patient, Provider, and Payer APIs
a. Background on CMS Interoperability Rulemaking
b. Proposal Overview
c. Proposed Certification Criteria
d. Revision and Addition of API Condition and Maintenance of
Certification Requirements
e. Revisions to Real World Testing Requirements
f. Addition of Criteria to the Base EHR Definition
C. Conditions and Maintenance of Certification Requirements--
Insights and Attestations
1. Insights Condition and Maintenance of Certification
Requirements
a. Background
b. Process for Reporting Updates
c. Minimum Reporting Qualifications
d. Measure Updates
2. Attestations Condition and Maintenance of Certification
Requirements
D. Administrative Updates
1. Program Correspondence
2. ONC-Authorized Certification Bodies (ACB) Surveillance of
Certain Maintenance of Certification Requirements
a. Background and Proposal Summary
b. Updates to Principles of Proper Conduct for Maintenance of
Certification Requirements
c. Updates to Surveillance for Maintenance of Certification
Requirements
3. Updates to Principles of Proper Conduct for API Discovery
Details
4. New ONC-ACB Principles of Proper Conduct for Notice of
Program Withdrawal
5. Updates to ONC Direct Review Procedures
a. Health IT Developers' Response to Notices of Non-conformity
and Corrective Action Plan Requirements
b. Suspension, Termination, and Appeals
c. Appeals
6. Certification Ban
7. Updates Pursuant to 2014 Edition Removal
a. Removal of ``Complete EHR'' References
b. Removal of ``EHR Modules'' References
8. Definition of Serious Risk to Public Health or Safety
9. Removal of Time-limited Criteria
10. Privacy and Security Framework Incorporation of DSI
Criterion
E. Correction--Privacy and Security Certification Framework
IV. Information Blocking Enhancements
A. Defined Terms
1. Health Care Provider
2. Health Information Technology or Health IT
3. ``Interfere With'' or ``Interference''
a. Application of ``Interference'' to TEFCA\TM\ Requirements
B. Exceptions
1. Privacy Exception
a. Privacy Exception--Definition of Individual
b. Privacy Sub-exception--Interfering with Individual Access
Based on Unreviewable Grounds
c. Privacy Sub-exception--Individual's Request Not to Share EHI
2. Infeasibility Exception
a. Segmentation Condition Modifications
b. Third Party Seeking Modification Use Condition Modifications
c. Responding to Requests Condition Modifications
3. Protecting Care Access Exception
a. Background and Purpose
b. Threshold Condition and Structure of Exception
c. Patient Protection Condition
d. Care Access Condition
e. Clarifying Provisions: Presumption and Definition of ``Legal
Action''
4. Requestor Preferences Exception
5. Exceptions That Involve Practices Related to Actors'
Participation in The Trusted Exchange Framework and Common
Agreement\TM\ (TEFCA\TM\)
a. Definitions
b. TEFCA<SUP>TM</SUP> Manner Exception
V. Trusted Exchange Framework and Common Agreement\TM\
A. Subpart A--General Provisions
B. Subpart B--Qualifications for Designation
C. Subpart C--QHIN\TM\ Onboarding and Designation Processes
D. Subpart D--Suspension
E. Subpart E--Termination
F. Subpart F--Review of RCE[supreg] or ONC Decisions
G. Subpart G--QHIN<SUP>TM</SUP> Attestation for the Adoption of
the Trusted Exchange Framework and Common Agreement<SUP>TM</SUP>
VI. Incorporation by Reference
VII. Response to Comments
[[Page 63500]]
VIII. Collection of Information Requirements
A. Qualified Health Information Networks\TM\
B. ONC-ACBs
IX. Regulatory Impact Analysis
A. Statement of Need
B. Alternatives Considered
C. Overall Impact
1. Executive Orders 12866 and 13563--Regulatory Planning and
Review Analysis
a. Costs and Benefits
b. Accounting Statement and Table
D. Regulatory Flexibility Act
E. Executive Order 13132--Federalism
F. Unfunded Mandates Reform Act of 1995
Regulation Text
I. Executive Summary
A. Purpose of Regulatory Action
The Secretary of Health and Human Services has delegated
responsibilities to the Office of the National Coordinator for Health
Information Technology (ONC) for the implementation of certain
provisions in Title IV of the 21st Century Cures Act (Pub. L. 114-255,
Dec. 13, 2016) (Cures Act) that are designed to: advance
interoperability; support the access, exchange, and use of electronic
health information (EHI); and identify reasonable and necessary
activities that do not constitute information blocking.\1\ ONC is
responsible for implementation of certain provisions of the Health
Information Technology for Economic and Clinical Health Act (Pub. L.
111-5, Feb. 17. 2009) (HITECH Act) including: requirements that the
National Coordinator perform duties consistent with the development of
a nationwide health information technology infrastructure that allows
for the electronic use and exchange of information and that promotes a
more effective marketplace, greater competition, and increased consumer
choice, among other goals; and requirements to keep or recognize a
program or programs for the voluntary certification of health
information technology. This proposed rule seeks to fulfill statutory
requirements; provide transparency; advance equity, innovation, and
interoperability; and support the access to, and exchange and use of,
EHI. Transparency regarding healthcare information and activities--as
well as the interoperability and electronic exchange of health
information--are all in the best interest of the patient and are
central to the efforts of the Department of Health and Human Services
to enhance and protect the health and well-being of all Americans.
---------------------------------------------------------------------------
\1\ Reasonable and necessary activities that do not constitute
information blocking, also known as information blocking exceptions,
are identified in 45 CFR part 171 subparts B, C and D. ONC's
official website, <a href="http://HealthIT.gov">HealthIT.gov</a>, offers a variety of resources on the
topic of Information Blocking, including fact sheets, recorded
webinars, and frequently asked questions. To learn more, please
visit: <a href="https://www.healthit.gov/topic/information-blocking/">https://www.healthit.gov/topic/information-blocking/</a>.
---------------------------------------------------------------------------
In addition to addressing the HITECH Act's and Cures Act's
requirements described above and advancing interoperability, the
proposed rule aligns with and supports Executive Orders (E.O.) 13994,
13985, 14036, and 14058. The President issued E.O. 13994 on January 21,
2021, to ensure a data-driven response to COVID-19 and future high-
consequence public health threats. The Cures Act and the information
blocking provisions in the 21st Century Cures Act: Interoperability,
Information Blocking, and the ONC Health IT Certification Program (85
FR 25642) (ONC Cures Act Final Rule) have enabled critical steps to
making data available across the healthcare system. The proposed rule
proposes to adopt certification criteria to advance interoperability
and support public health reporting and exchange. Because we recognize
the need for greater interoperability of public health technology and
access to more actionable data by public health authorities (PHA) and
their partners, the proposed rule lays out a multi-pronged approach
that takes advantage of, and builds upon, the various previous efforts
to advance public health reporting, including advancements in
HL7[supreg] Fast Healthcare Interoperability Resources-based
(FHIR[supreg]) solutions and evolving standards related to public
health interoperability. We have proposed this approach to allow for
systems to mature and advance in an aligned fashion, reduce the need
for manual workarounds and intervention, and lead to wider adoption of
advanced standards-based capabilities.
The proposed adoption of the United States Core Data for
Interoperability Standard Version 4 (USCDI v4) would promote the
establishment and use of interoperable data sets of EHI for
interoperable health data exchange. As discussed in section III.B.1,
USCDI v4 would facilitate the collection, access and exchange of data
for use in public health and emergency response (e.g., the COVID-19
pandemic) by capturing and promoting the sharing of key data elements
related to public health. The proposal to adopt a new certification
criterion for standardized FHIR-based application programming
interfaces (APIs) for public health reporting, as discussed in section
III.B.13.f, reflects ONC's continued efforts to develop and standardize
APIs and facilitate exchange of public health data between health care
providers and public health agencies, to securely access EHI through
the broader adoption of standardized APIs.\2\ \3\As discussed in
section III.B, adopting USCDI v4 and the proposals in Sec.
170.315(g)(20) are intended to facilitate core public health missions
including detecting and monitoring, investigating and responding,
informing and disseminating, and being response-ready. We also expect
our proposed changes to improve patient access to more complete,
standardized, immunization information stored in certified health IT
products.
---------------------------------------------------------------------------
\2\ ONC. (2022, October 18). API Resource Guide. ONC Health IT
Certification Program API Resource Guide. Retrieved March 16, 2023,
from <a href="https://onc-healthit.github.io/api-resource-guide/">https://onc-healthit.github.io/api-resource-guide/</a>.
\3\ Section 4002 of the 21st Century Cures Act (Cures Act)
established a condition of certification that requires health IT
developers to publish application programming interfaces (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 API Conditions and Maintenance of Certification
requirements and certification criteria are identified in 45 CFR
part 170.
---------------------------------------------------------------------------
We are committed to advancing health equity, and this proposed rule
is consistent with E.O. 13985 of January 20, 2021, Advancing Racial
Equity and Support for Underserved Communities Through the Federal
Government.\4\ Section 1 of E.O. 13985 states that ``the Federal
Government should pursue a comprehensive approach to advancing equity
for all, including people of color and others who have been
historically underserved, marginalized, and adversely affected by
persistent poverty and inequality.'' Section 1 of E.O. 13985 also
states that because ``advancing equity requires a systematic approach
to embedding fairness in decision-making processes, executive
departments and agencies must recognize and work to redress inequities
in any policies and programs that serve as barriers to equal
opportunity.'' We believe USCDI v4 and proposals in Sec. 170.315(f)
and Sec. 170.315(g)(20) would not only support identifying and
responding to public health threats, but also support advancing equity.
As noted above, we propose to modify current certification
[[Page 63501]]
criteria in Sec. 170.315(f) and adopt new criteria in Sec. 170.315(f)
for Health IT Modules supporting public health data exchange that would
help increase the data shared between health care providers,
laboratories, and PHAs, and would increase interoperability among the
different systems in place at each entity. Our proposed changes focus
on providing more complete patient-level information for contact
tracing and further case investigation, patient outreach, direct care,
and other clinical and public health activities. For example, some of
the proposed standards would require the exchange of available patient
demographic information, including race, ethnicity, sex, and contact
information; and may allow PHAs to get more complete data when
providers and laboratories have these data elements and can
appropriately fill the fields. Additionally, if finalized as proposed,
the adoption of USCDI v4 would update the USCDI standard to include new
data elements under the Health Status Assessments, Medications,
Allergies and Intolerances, Goals and Preferences, Encounter
Information, Vital Signs, and Laboratory data classes, and a new data
class, Facility Information, as discussed in section III.B.1 of this
proposed rule. Expanding the data elements included in USCDI would
increase the amount and type of data available to be used and exchanged
through certified health IT. Our proposed standards update for public
health and USCDI v4 could help capture more accurate and complete
patient characteristics that are reflective of patient diversity and
could potentially help data users address disparities in health
outcomes for all patients, including those who may be marginalized and
underrepresented. This could also support data users' abilities to
identify, assess, and analyze gaps in care, which could in turn be used
to inform and address the quality of healthcare through interventions
and strategies. This could lead to better patient care, experiences,
and health outcomes.
---------------------------------------------------------------------------
\4\ United States, Executive Office of the President [Joseph
Biden]. Executive Order 13985: Advancing Racial Equity and Support
for Underserved Communities Through the Federal Government. Jan 20,
2021. 86 FR 7009 through 7013, <a href="https://www.federalregister.gov/documents/2021/01/25/2021-01753/advancing-racial-equity-and-support-for-underserved-communities-through-the-federal-government">https://www.federalregister.gov/documents/2021/01/25/2021-01753/advancing-racial-equity-and-support-for-underserved-communities-through-the-federal-government</a>.
---------------------------------------------------------------------------
As discussed in section III.B.1, the proposal to adopt USCDI v4
also supports the concept of ``health equity by design,'' where health
equity considerations are identified and incorporated from the
beginning and throughout the technology design, build, and
implementation processes, and health equity strategies, tactics, and
patterns are guiding principles for developers, enforced by technical
architecture, and built into the technology at every layer. With every
successive USCDI version supported by certified health IT, the
capabilities and workflows included will help support equity and
efforts to reduce disparities.
President Biden's E.O. 14036, Promoting Competition in the American
Economy,\5\ issued on July 9, 2021, established a whole-of-government
effort to promote competition in the American economy and reaffirmed
the policy stated in E.O. 13725 of April 15, 2016 (Steps to Increase
Competition and Better Inform Consumers and Workers to Support
Continued Growth of the American Economy).\6\ This proposed rule would
foster competition by advancing foundational standards for certified
API technology, which enable--through applications (apps) and without
special effort--improved legally permissible sharing of EHI among
clinicians, patients, researchers, and others. As described throughout
the proposed rule, competition would be advanced through these improved
API standards that can help individuals connect to their information
and can help health care providers involved in the patient's care to
securely access information. For example, these standards are designed
to foster an ecosystem of new applications that can connect through the
API technology to provide patients with improved electronic access to
EHI and more choices in their health care providers. This is similar to
how APIs have impacted other sectors of the economy, such as travel,
banking, and commerce.
---------------------------------------------------------------------------
\5\ United States, Executive Office of the President [Joseph
Biden]. Executive Order 14036: Promoting Competition in the American
Economy. Jul 9, 2021. 86 FR 36987 through36999, <a href="https://www.federalregister.gov/documents/2021/07/14/2021-15069/promoting-competition-in-the-american-economy">https://www.federalregister.gov/documents/2021/07/14/2021-15069/promoting-competition-in-the-american-economy</a>.
\6\ Federal Register: Steps to Increase Competition and Better
Inform Consumers and Workers to Support Continued Growth of the
American Economy.
---------------------------------------------------------------------------
Further, as described in section IV of this proposed rule, we
propose enhancements to support information sharing under the
information blocking regulations and promote innovation and
competition, while ensuring patients' privacy and access to care remain
protected. As we have noted, addressing information blocking is
critical for promoting innovation and competition in health IT and for
the delivery of healthcare services to individuals, as discussed in
both the ONC Cures Act Proposed (84 FR 7508) and Final (85 FR 25790
through 25791) Rules, and reiterated in the Health Data, Technology,
and Interoperability: Certification Program Updates, Algorithm
Transparency, and Information Sharing (HTI-1) Final Rule (89 FR 1192).
Specifically, we described how the information blocking provisions
provide a comprehensive response to the issues identified by empirical
and economic research that suggested that information blocking may
weaken competition, encourage consolidation, and create barriers to
entry for developers of new and innovative applications and
technologies that enable more effective uses of EHI to improve
population health and the patient experience.\7\ We explained that the
information blocking provision of the Public Health Service Act (PHSA)
itself expressly addresses practices that impede innovation and
advancements in EHI access, exchange, and use, including care delivery
enabled by health IT (89 FR 1195, citing section 3022(a)(2) of the
PHSA). Actors subject to the information blocking provisions may, among
other practices, attempt to 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 (85 FR 25820).\8\ Information blocking may
also harm competition not just in health IT markets, but also in
markets for healthcare services (85 FR 25820). In the ONC Cures Act
Final Rule, we described practices that dominant market providers may
leverage and use to control access and use of their technology,
resulting in technical dependence and possibly leading to barriers to
entry by would-be competitors, as well as making some market providers
vulnerable to acquisition or inducement into arrangements that enhance
the market power of incumbent providers to the detriment of consumers
and purchasers
[[Page 63502]]
of healthcare services (85 FR 25820). The implementation of the new
information blocking provisions proposed and discussed in section IV of
this proposed rule would continue to promote innovation and support the
lawful access, exchange, and use of EHI, while strengthening support
for individuals' privacy and EHI sharing preferences.
---------------------------------------------------------------------------
\7\ 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 <a href="http://heinz.cmu.edu/news/news-detail/index.aspx?nid=3930">http://heinz.cmu.edu/news/news-detail/index.aspx?nid=3930</a>; 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 <a href="http://www.brookings.edu/research/papers/2015/01/30-sustainable-business-model-health-information-exchange-yaraghi">http://www.brookings.edu/research/papers/2015/01/30-sustainable-business-model-health-information-exchange-yaraghi</a>;
Thomas C. Tsai Ashish K. Jha, Hospital Consolidation, Competition,
and Quality: Is Bigger Necessarily Better? 312 J. AM. MED. ASSOC.
29, 29 (2014).
\8\ 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 <a href="http://heinz.cmu.edu/news/news-detail/index.aspx?nid=3930">http://heinz.cmu.edu/news/news-detail/index.aspx?nid=3930</a>.
---------------------------------------------------------------------------
Lastly, in support of E.O. 14058, Transforming Federal Customer
Experience and Service Delivery to Rebuild Trust in Government, issued
on December 16, 2021, we are committed to advancing the equitable and
effective delivery of services with a focus on the experience of
individuals, health IT developers, and health care providers.\9\ The
proposed rule supports the Department of Health and Human Services'
agency-wide approach to electronic prior authorization that meets the
Department's interoperability and burden reduction goals, such as
reducing documentation requirements associated with completing prior
authorization requests for payers.\10\ Proposed certification criteria
would make available certified health IT that can enable payers
contracting with the Federal government, such as Medicare Advantage
plans, to meet Centers for Medicare & Medicaid Services (CMS)
requirements for sharing information. Additionally, improving the
equitable access, exchange, and use of EHI would help enable patient-
centric care, which is expected to improve equity in health outcomes.
This proposed rule further recognizes patient feedback and preferences
in their care and how patients and their representatives may want to
monitor and share EHI with relevant health care providers and entities.
The health IT certification provisions of the proposed rule aim to
reduce the burden associated with prior authorization processes, which
can ensure that patients receive the care they need in a timely manner,
lower administrative cost, and reduce the complexity of obtaining a
prior authorization for health care providers and patients.
Collectively, these provisions of the proposed rule help advance the
equitable and effective delivery of services with a focus on the
experience of individuals, health IT developers, and health care
providers.
---------------------------------------------------------------------------
\9\ United States, Executive Office of the President [Joseph
Biden]. Executive Order 14058: Transforming Federal Customer
Experience and Service Delivery To Rebuild Trust in Government. Dec
13, 2021. 86 FR 71357 through71366, <a href="https://www.federalregister.gov/documents/2021/12/16/2021-27380/transforming-federal-customer-experience-and-service-delivery-to-rebuild-trust-in-government">https://www.federalregister.gov/documents/2021/12/16/2021-27380/transforming-federal-customer-experience-and-service-delivery-to-rebuild-trust-in-government</a>.
\10\ Strategy on Reducing Regulatory and Administrative Burden
Relating to the Use of Health IT and EHRs (Burden Reduction Report),
February 2020, pages 26-28, <a href="https://www.healthit.gov/sites/default/files/page/2020-02/BurdenReport_0.pdf">https://www.healthit.gov/sites/default/files/page/2020-02/BurdenReport_0.pdf</a>.
---------------------------------------------------------------------------
We also strive to further advance Federal agency coordination. ONC
works with CMS to ensure that our certification criteria and standards
support and complement CMS programs that reference ONC regulations,
such as the Medicare Promoting Interoperability Program and the
Promoting Interoperability performance category of the Merit-based
Incentive Payment System (MIPS). In addition, a final rule titled
``Medicare and Medicaid Programs; Patient Protection and Affordable
Care Act; Advancing Interoperability and Improving Prior Authorization
Processes for Medicare Advantage Organizations, Medicaid Managed Care
Plans, State Medicaid Agencies, Children's Health Insurance Program
(CHIP) Agencies and CHIP Managed Care Entities, Issuers of Qualified
Health Plans on the Federally-Facilitated Exchanges, Merit-Based
Incentive Payment System (MIPS) Eligible Clinicians, and Eligible
Hospitals and Critical Access Hospitals in the Medicare Promoting
Interoperability Program'' (CMS Interoperability and Prior
Authorization final rule, 89 FR 8758) appeared in the Federal Register
on February 8, 2024, and included requirements for certain payers
regulated by CMS to establish APIs that can facilitate electronic prior
authorization processes by 2027 (89 FR 8919). CMS also finalized
electronic prior authorization measures for eligible clinicians who
participate in the Promoting Interoperability performance category of
the MIPS; and eligible hospitals and critical access hospitals that
participate in the Medicare Promoting Interoperability Program,
beginning in the CY 2027 performance period and the EHR reporting
period in CY 2027, respectively (89 FR 8760). In this proposed rule, we
propose to adopt standards and establish certification criteria to
facilitate electronic prior authorization using certified health IT,
which providers can use to complete the required actions under the
finalized measures. Lastly, we are committed to our continued,
collaborative work with the Centers for Disease Control and Prevention
(CDC) on improving public health data systems. The proposed updates to
the ONC Health IT Certification Program's public health criteria and
complementary public health criteria for PHA systems would support
CDC's Data Modernization Initiative and Public Health Data
Strategy.\11\ We believe these approaches would increase efficiency for
delivery of services and programs, reduce confusion for participants in
these programs, and better serve the public interest.
---------------------------------------------------------------------------
\11\ Public_Health_Data_Strategy-final-P.pdf (<a href="http://cdc.gov">cdc.gov</a>).
---------------------------------------------------------------------------
While this rulemaking does not propose to require entities to adopt
any specific standards to ensure that their information and
communication technology (ICT), including software, applications,
websites, and electronic documents, is accessible for people with
disabilities, entities covered by this rule may also be subject to
applicable requirements of Federal nondiscrimination laws. For example,
Section 504 of the Rehabilitation Act of 1973 (Section 504) prohibits
recipients of Federal financial assistance from discriminating on the
basis of disability by excluding people with disabilities from
participation in, denying them the benefits of, or subjecting them to
discrimination in their programs or activities. 29 U.S.C. 794. Section
1557 of the Patient Protection and Affordable Care Act (Section 1557)
prohibits certain health programs and activities, including those
receiving Federal financial assistance from HHS, from discriminating on
the basis of race, color, national origin, sex, age, or disability by
excluding them from participation in, denying them the benefits of, or
subjecting them to discrimination in their health programs or
activities. 42 U.S.C. 18116(a). Newly issued Section 504 regulations
require recipients to ensure that web content and mobile apps that a
recipient provides or makes available, directly or through contractual,
licensing, or other arrangements, be readily accessible to and usable
by individuals with disabilities, with some exceptions. See 89 FR 40066
and 45 CFR Secs. 84.82-.89(a). The rule requires technical
accessibility standards that must be met on May 11, 2026, for entities
with fifteen or more employees and May 10, 2027, for entities with
fewer than fifteen employees unless the recipient can demonstrate that
compliance with this section would result in a fundamental alteration
in the nature of a program or activity or in undue financial and
administrative burdens or unless an exception applies. 45 CFR Sec.
84.84(b); 84.85. Title III of the Americans with Disabilities Act (ADA)
prohibits discrimination on the basis of disability in the full and
equal enjoyment of places of public accommodation. 42 U.S.C. 12182.
Title II of the ADA prohibits state and local government
[[Page 63503]]
entities from discriminating on the basis of disability by excluding
people with disabilities from participation in, denying them the
benefits of, or subjecting them to discrimination in their services,
programs, or activities. 42 U.S.C. 12132. On April 24, 2024, the
Department of Justice published regulations establishing specific
requirements, including the adoption of specific technical standards,
for making accessible the services, programs, and activities offered by
State and local government entities through the web and mobile
applications. 89 FR 31320. More generally, these statutes and their
implementing regulations apply to programs, services and activities
implemented through or with information and communications technology
(ICT). In addition, the Section 1557 implementing regulation addresses
ICT specifically, providing that covered entities, including health
programs and activities that receive Federal financial assistance from
HHS, shall ensure that their health programs or activities provided
through ICT are accessible to individuals with disabilities, unless
doing so would result in undue financial and administrative burdens or
a fundamental alteration in the nature of the health programs or
activities. 89 FR 37522 (May 6, 2024) (45 CFR 92.204).
B. Summary of Major Provisions
1. ONC Health IT Certification Program Updates
a. New and Revised Standards and Certification Criteria
i. The United States Core Data for Interoperability Version 4 (USCDI
v4)
The USCDI standard in Sec. 170.213 is a baseline set of data that
can be commonly exchanged across care settings for a wide range of
uses. Certain certification criteria in the ONC Health IT Certification
Program (Program) currently require the use of one of the versions of
the USCDI standard by in Sec. 170.213. We propose to update the USCDI
standard in Sec. 170.213 by adding USCDI v4 and by establishing an
expiration date of January 1, 2028, for USCDI v3 for purposes of the
Program. We propose to add USCDI v4 in Sec. 170.213(c) and incorporate
it by reference in Sec. 170.299. We propose that up to and including
December 31, 2027, a Health IT Module certified to certification
criteria referencing Sec. 170.213 may use either version of the
standard. We propose that by January 1, 2028, a health IT developer of
a Health IT Module certified to certification criteria referencing
Sec. 170.213 must update its Health IT Module to USCDI v4 and provide
the updated version to their customers in order to maintain
certification of that Health IT Module. We propose that any Health IT
Modules seeking certification to certification criteria referencing
Sec. 170.213 on or after January 1, 2028, would need to be capable of
exchanging the data elements that the USCDI v4 comprises.
ii. SMART App Launch 2.2
As discussed in section III.B.2, we propose to adopt the
HL7[supreg] FHIR[supreg] SMART Application Launch Framework
Implementation Guide release 2.2.0 (SMART v2.2 Guide) in Sec.
170.215(c)(3). We propose that the adoption of the SMART v2 Guide in
Sec. 170.215(c)(2) expires on January 1, 2028. We propose that a
Health IT Module certified to criteria referencing the implementation
specifications in Sec. 170.215(c) may use the SMART v1, SMART v2, or
SMART v2.2 guides for the time period up to and including December 31,
2025. Then, by January 1, 2026, when the adoption of SMART v1 expires,
a health IT developer of a Health IT Module certified to certification
criteria referencing the implementation specifications in Sec.
170.215(c) must update its Health IT Module to either the SMART v2 or
SMART v2.2 Guides and provide the updated version to its customers in
order to maintain certification of that Health IT Module. Then, by
January 1, 2028, when the adoption of the SMART v2 Guide expires, a
health IT developer of a Health IT Module certified to certification
criteria referencing the implementation specifications in Sec.
170.215(c) must update its Health IT Module to the SMART v2.2 Guide and
provide the updated version to its customers in order to maintain
certification of that Health IT Module. On and after January 1, 2028,
we propose that any Health IT Modules seeking certification to
certification criteria referencing the implementation specifications in
Sec. 170.215(c), would need to be capable of supporting SMART v2.2
Guide functionality.
iii. User-Access Brands and Endpoints
We propose to adopt the User-access Brands and Endpoints (Brands)
specification for our service base URL publication requirements, as
explained in section III.B.3. This applies to our current service base
URL publication requirements in Sec. 170.404(b)(2), where we propose
to reorganize the criterion's paragraphs in a way that places existing
service base URL requirements into Sec. 170.404(b)(2)(i) and (ii) and
adds the new Brands requirement in Sec. 170.404(b)(2)(iii). We propose
in our updated Sec. 170.404(b)(2)(iii) to require that, by January 1,
2028, service base URLs and related API Information Source details,
including each organization's name, location, and facility identifier,
must be published in an aggregate vendor-consolidated ``FHIR Bundle''
according to the Brands specification. Additionally, in our proposal to
revise Sec. 170.404(b)(3) where we propose new requirements for the
publication of API discovery details for payer network information,
including service base URLs and API Information Source details, we
propose to adopt Brands specification.
iv. Standards for Encryption and Decryption of Electronic Health
Information
As discussed in section III.B.4, we propose to adopt the updated
version of Annex A of the Federal Information Processing Standards
(FIPS) 140-2 (Draft, October 12, 2021) in Sec. 170.210(a)(3) and
incorporate it by reference in Sec. 170.299. We propose to add an
expiration date of January 1, 2026, to the FIPS 140-2 (October 8, 2014)
version of the standard presently adopted in Sec. 170.210(a)(2). We
also propose to remove the standard found in Sec. 170.210(f), which is
no longer referenced in any active certification criteria. Revising
Sec. 170.210(a) by adding an expiration date in Sec. 170.210(a)(2)
and a new version of the FIPS standard in Sec. 170.210(a)(3) would
impact three certification criteria that currently reference the
standard in Sec. 170.210(a)(2), including Sec. 170.315(d)(7) ``end-
user device encryption;'' (d)(9) ``trusted connection;'' and (d)(12)
``encrypt authentication credentials.'' Note that we also propose to
change the names of the certification criteria in Sec. 170.315(d)(7)
and (d)(12) to ``health IT encryption'' and ``protect stored
authentication credentials'' respectively, as discussed in sections
III.B.11 and III.B.12 of this preamble.
v. Minimum Standards Code Sets Updates
Early in ONC's standards and certification rulemakings, we
established a policy of adopting newer versions of ``minimum
standards'' code sets that update frequently (e.g., 77 FR 54170 and 80
FR 62612). Adopting newer versions of these code sets enables improved
interoperability and implementation of health IT with minimal
additional burden. If adopted, newer versions of these minimum
standards code sets would serve as the baseline for certification, and
[[Page 63504]]
developers of certified health IT would be able to use newer versions
of these adopted standards on a voluntary basis. Because these code
sets are updated frequently, we will consider whether it may be more
appropriate to adopt a version of a minimum standards code set issued
after publication of this proposed rule, but before publication of a
final rule. In section III.B.5, we discuss our proposals to adopt newer
versions of the following minimum standards code sets:
<bullet> Sec. 170.207(a)--Problems
<bullet> Sec. 170.207(c)--Laboratory tests
<bullet> Sec. 170.207(d)--Medications
<bullet> Sec. 170.207(e)--Immunizations
<bullet> Sec. 170.207(f)--Race and Ethnicity
<bullet> Sec. 170.207(n)--Sex
<bullet> Sec. 170.207(o)--Sexual orientation and gender information
<bullet> Sec. 170.207(p)--Social, psychological, and behavioral data
vi. New Imaging Requirements for Health IT Modules
We propose, as explained in section III.B.6, to revise the
certification criteria adopted in Sec. 170.315(b)(1), (e)(1), (g)(9),
and (g)(10) to include new certification requirements to support
access, exchange, and use of diagnostic images via imaging links.
However, we are not proposing a specific standard associated with the
support of this functionality, and we note that this requirement can be
met with a context-sensitive link to an external application which
provides access to images and their associated narrative. We believe
that this proposal, if finalized as proposed, will promote more
consistent access to images for providers and patients. We propose that
by January 1, 2028, a health IT developer of a Health IT Module
certified to the certification criteria related to ``transitions of
care'' in Sec. 170.315(b)(1), ``view, download, and transmit'' in
Sec. 170.315(e)(1), ``application access--all data request,'' in Sec.
170.315(g)(9), and ``standardized API for patient and population
services,'' in Sec. 170.315(g)(10) must update their Health IT Module
and provide the updated version to their customers to maintain
certification of that Health IT Module.
vii. Revised Clinical Information Reconciliation and Incorporation
Criterion
We propose, as described in section III.B.7, a primary proposal and
an alternative proposal for revising the ``clinical information
reconciliation and incorporation'' certification criterion in Sec.
170.315(b)(2) to expand the number and types of data elements that
Health IT Modules certified to this criterion would be required to
reconcile and incorporate. Our primary proposal would require Health IT
Modules certified to Sec. 170.315(b)(2) to be capable of reconciling
and incorporating all USCDI data elements according to at least one of
the versions of the USCDI standard specified in Sec. 170.213. Our
alternative proposal would require Health IT Modules to reconcile and
incorporate data elements from six additional USCDI data classes beyond
the existing three data classes required as part of the current
certification criterion's functionality. We also propose new functional
requirements to enable user-driven automatic reconciliation and
incorporation. We propose that by January 1, 2028, a health IT
developer of a Health IT Module certified to the criterion in Sec.
170.315(b)(2) must update their Health IT Module and provide the
updated version to their customers in order to maintain certification
of that Health IT Module. We also propose that any Health IT Modules
seeking certification for the criterion in Sec. 170.315(b)(2) on or
after January 1, 2028, would need to be capable of supporting this
functionality.
viii. Revised Electronic Prescribing Certification Criterion
We propose to incorporate the National Council for Prescription
Drug Programs (NCPDP) SCRIPT standard \12\ version 2023011 in an
updated version of the electronic prescribing certification criterion
in Sec. 170.315(b)(3)(ii). Under this proposal, as described in
section III.B.8 of this proposed rule, health IT developers may
maintain health IT certification conformance with the current version
of the criterion using NCPDP SCRIPT standard version 2017071 for the
time period up to and including December 31, 2027. We propose that by
January 1, 2028, a health IT developer of a Health IT Module certified
to the criterion in Sec. 170.315(b)(3) must update the Health IT
Module to use the NCPDP SCRIPT standard version 2023011 and provide
that update to their customers in order to maintain certification of
the Health IT Module. We propose that any Health IT Modules for which a
health IT developer seeks certification to the criterion in Sec.
170.315(b)(3) on or after January 1, 2028, would need to be able to
perform the required prescription-related electronic transaction in
accordance with the NCPDP SCRIPT standard version 2023011. We also
propose a series of updates to the transactions included in Sec.
170.315(b)(3)(ii) including removing transactions currently identified
as optional for the certification criterion.
---------------------------------------------------------------------------
\12\ See <a href="https://standards.ncpdp.org/">https://standards.ncpdp.org/</a>.
---------------------------------------------------------------------------
ix. New Real-Time Prescription Benefit Criterion
Real-time prescription benefit tools empower providers and their
patients to compare the patient-specific cost of a drug to the cost of
a suitable alternative, compare prescription costs at different
pharmacies, view information about out-of-pocket costs, and learn
whether prior authorization for a specific drug is required. In order
to implement section 119(b)(3) of the Consolidated Appropriations Act,
2021 (Pub. L. 116-260), as discussed in section III.B.9, we propose to
establish a real-time prescription benefit certification criterion in
Sec. 170.315(b)(4) based on the National Council for Prescription Drug
Programs (NCPDP) Real-Time Prescription Benefit (RTPB) standard version
13. We also propose to include this certification criterion in the Base
EHR definition in Sec. 170.102.
x. Electronic Health Information (EHI) Export--Single Patient EHI
Export Exemption
As explained in section III.B.10, we propose to exempt Health IT
Modules that act primarily as intermediaries between systems and,
through integration, function without any direct human interaction from
the requirement in Sec. 170.315(b)(10)(i)(B) to provide functionality
without subsequent developer assistance to operate. We propose that
this exemption proposed in Sec. 170.315(b)(10)(i)(F) would be
available if the developer of such a Health IT Module receives fewer
than ten requests in the immediately preceding calendar year for a
single patient EHI export. Relatedly, we propose in Sec.
170.402(b)(2)(iii) that developers of certified health IT with Health
IT Modules certified to Sec. 170.315(b)(10) that claim the exemption
proposed in Sec. 170.315(b)(10)(i)(F) would need to report the number
of requests for single patient EHI export on an annual basis to their
ONC-Authorized Certification Bodies (ACBs) by March 1 of each calendar
year beginning in 2028.
xi. Revised End-User Device Encryption Criterion
As discussed in section III.B.11, we propose to revise Sec.
170.315(d)(7) to include a new requirement that Health IT Modules
certified to this criterion encrypt EHI stored server-side on and after
January 1, 2026. To include this new requirement, we propose
reorganizing the certification criterion's paragraphs in a way that
places existing
[[Page 63505]]
end-user device encryption requirements into Sec. 170.315(d)(7)(i) and
(d)(7)(ii) and adds the new server encryption requirement in Sec.
170.315(d)(7)(iii). Then, we propose placing the applicable proposed
encryption standard and default settings requirements to both the end-
user device and server encryption requirements into Sec.
170.315(d)(7)(iii) and (iv) respectively. We also propose to require
that personally identifiable information must be encrypted in Health IT
Modules certified to this revised certification criterion. Finally, we
propose to change Sec. 170.315(d)(7) by renaming it to ``health IT
encryption,'' to better describe the end-user and proposed server-side
requirements together.
xii. Revised Criterion for Encrypt Authentication Credentials
As explained in section III.B.12, we propose to revise the
``encrypt authentication credentials'' certification criterion in Sec.
170.315(d)(12). We propose to revise the certification criterion by
expiring our current ``yes'' or ``no'' attestation requirement and
replacing it with a new requirement that Health IT Modules that store
authentication credentials protect the confidentiality and integrity of
its stored authentication credentials according to the Federal
Information Processing Standards (FIPS) 140-2 (October 12, 2021)
industry standard. We also propose to change the name of this
certification criterion to ``protect stored authentication
credentials,'' to better describe how we propose to revise the
criterion.
xiii. Health IT Modules Supporting Public Health Data Exchange
Public health promotes and protects the health of all people and
their communities. To accomplish this mission, public health
authorities (PHAs) rely in part on public health information exchange,
including data from healthcare facilities and providers, laboratories,
schools, social and community service providers, and other data
partners to acquire the information they need. However, PHAs often do
not have access to--or, often, the ability to share--the data required
to optimally address public health needs (emergent or otherwise) due to
the lack of common standards utilized in the reported data, variable
reporting requirements, limited interoperability of systems, or
inadequate public health data infrastructure and technology.
Considering the need for greater interoperability of public health
technology and access to more actionable data by PHAs and their
partners,\13\ as discussed in section III.B.13, we propose: to revise
the Program's current certification criteria related to public health
in Sec. 170.315(f), including referencing newer versions of respective
exchange and vocabulary standards in the current Sec. 170.315(f)
certification criteria (Sec. 170.315(f)(1)-(f)(7)); proposing two
additional certification criteria for birth reporting (Sec.
170.315(f)(8)) and bi-directional exchange with a prescription drug
monitoring program (PDMP) (Sec. 170.315(f)(9)); proposing new
certification criteria for Health IT Modules supporting public health
data exchange in Sec. 170.315(f)(21)-(25), (28) and (29); and,
proposing a new certification criterion for a standardized
FHIR[supreg]-based API for public health data exchange in Sec.
170.315(g)(20). The new certification criterion in Sec. 170.315(g)(20)
would support ongoing and future development of public health FHIR IGs
leveraging a core set of existing, modular, and extensible capabilities
and standards. The standards referenced in the proposed Sec.
170.315(g)(20) certification criterion support FHIR capabilities such
as API-based event notifications (i.e., FHIR Subscriptions), SMART App
Launch, Bulk Data Export, and requirements for authorization and
authentication, drawing on the Program's requirements for Health IT
Modules certified to Sec. 170.315(g)(10).
---------------------------------------------------------------------------
\13\ <a href="https://www.gao.gov/products/gao-22-106175">https://www.gao.gov/products/gao-22-106175</a>.
---------------------------------------------------------------------------
xiv. Bulk Data Enhancements
We propose, as discussed in section III.B.14, to adopt the
HL7[supreg] FHIR[supreg] Bulk Data Access v2.0.0: STU 2 implementation
specification (Bulk v2 IG) in Sec. 170.215(d)(2). We also propose to
require, in many of our proposed certification criteria that reference
Sec. 170.215(d)(2), server support for the ``group export'' operation
and a ``_type'' query parameter for performance improvement. We believe
this proposal would better support interoperability with Health IT
Modules certified to support FHIR Bulk Data Access and better enable
performant exporting of complete sets of FHIR resources for pre-defined
cohorts of patients. This would raise the floor from our current Bulk
v1 IG requirements for certification, where we require support for the
group export operation but do not require support for any of the
optional query parameters in the IG. We believe that these new
certification requirements, based on additional implementer
clarifications included in the Bulk v2 IG, would provide meaningful
improvements in the performance of Bulk APIs. Additionally, we welcome
comment on the issues hindering the effective exchange of population
data using Bulk FHIR APIs and additional steps ONC can take to help
address those issues.
xv. New Requirements To Support Dynamic Client Registration Protocol in
the Program
We propose, as explained in section III.B.15, to add requirements
in the Program to support dynamic client registration and subsequent
authentication and authorization for dynamically registered apps for
patient-facing, user-facing, and system confidential applications. This
includes adding requirements to the following in the Program:
<bullet> Sec. 170.315(g)(10) certification criterion
<bullet> Sec. 170.315(g)(20), (30), and (32)-(35) proposed
certification criteria
<bullet> Sec. 170.315(j)(2), (5), (8), (11) proposed certification
criteria
<bullet> API Conditions and Maintenance of Certification requirements
in Sec. 170.404
We propose to adopt the HL7[supreg] Unified Data Access Profiles
(UDAP<SUP>TM</SUP>) Security for Scalable Registration, Authentication,
and Authorization Implementation Guide Release 1.0.0 implementation
guide (UDAP Security IG v1), and we propose to require several specific
sections of it to support requirements in the Program criteria listed
above. This proposal would facilitate timelier patient, provider, and
system access to health information using applications by providing a
more uniform, standardized, and automated application registration
pathway.
xvi. New Certification Criteria for Modular API Capabilities
We propose, as discussed in section III.B.16, to add a new category
of certification criteria to Sec. 170.315 titled ``modular API
capabilities'' in Sec. 170.315(j). Several proposals across this
proposed rulemaking would establish capabilities necessary to support
standardized APIs across clinical, public health, administrative, and
other use cases. We propose that the certification criteria in Sec.
170.315(j) would represent API capabilities that are standards-based,
including through new standards, such as HL7[supreg] Clinical Decision
Support (CDS) Hooks, SMART Health Cards, and HL7 FHIR[supreg]
Subscriptions, as well as standards and functionalities historically
referenced in Sec. 170.315(g)(10). These modular API capabilities
would be referenced and incorporated into Health IT Modules to support
standardized APIs for clinical use cases in Sec. 170.315(g)(10),
public
[[Page 63506]]
health use cases in Sec. 170.315(g)(20), and health insurance and
coverage use cases in Sec. 170.315(g)(30)-(36), as well as other
future use cases across the health IT landscape.
xvii. Multi-Factor Authentication Criterion
As explained in section III.B.17, we propose to revise the ``multi-
factor authentication'' (MFA) certification criterion in Sec.
170.315(d)(13) and accordingly update the privacy and security (P&S)
certification framework in Sec. 170.550(h). The proposed update would
revise our MFA certification criterion by replacing our current ``yes''
or ``no'' attestation requirement with a specific requirement to
support multi-factor authentication and configuration for three
certification criteria on and after January 1, 2028. We propose to
apply the updated MFA requirements by revising each of the
certification criteria in Sec. 170.315(b)(3), (e)(1), (g)(10), and
(g)(30) to require that a Health IT Module certified to these criteria
also be certified to Sec. 170.315(d)(13)(ii) on and after January 1,
2028. Given our proposal to embed Sec. 170.315(d)(13) references into
each applicable certification criterion, Sec. 170.315(d)(13) does not
need to be referenced again in Sec. 170.550(h)(3), therefore, we
propose to expire all the references to Sec. 170.315(d)(13) in Sec.
170.550(h)(3) by December 31, 2027. We believe these updates would
match industry best practices for information security, particularly
for important authentication use cases in certified health IT.
xviii. Revised Computerized Provider Order Entry--Laboratory Criterion
We propose, as discussed in section III.B.18, to update the
``computerized provider order entry--laboratory'' certification
criterion in Sec. 170.315(a)(2) to require enabling a user to create
and transmit laboratory orders electronically according to the standard
proposed in Sec. 170.205(g)(2), the HL7[supreg] Laboratory Order
Interface (LOI) Implementation Guide (IG). We further propose to update
Sec. 170.315(a)(2) to require technology to receive and validate
laboratory results according to the standard proposed in Sec.
170.205(g)(3), the HL7[supreg] Laboratory Results Interface (LRI) IG.
Ensuring that systems creating laboratory orders can transmit orders
and receive associated results and values electronically, according to
national standards, would create more complete patient information
available to clinicians throughout the laboratory workflow. We propose
that by January 1, 2028, a health IT developer of a Health IT Module
certified to the criterion in Sec. 170.315(a)(2) must update its
Health IT Module and provide the updated version to its customers in
order to maintain certification of that Health IT Module. We propose
that any Health IT Modules seeking certification for the criterion in
Sec. 170.315(a)(2) on or after January 1, 2028, would need to be
capable of supporting this functionality.
xix. Revised Standardized API for Patient and Population Services
Criterion To Align With Modular API Capabilities
As discussed in section III.B.19, we propose to revise the
certification criterion in Sec. 170.315(g)(10) to reorganize
requirements to improve clarity and align with new proposals in this
rule, including proposed:
<bullet> restructuring of existing requirements to reference the
``modular API capabilities'' certification criteria proposed in Sec.
170.315(j)
<bullet> support for dynamic registration and subsequent authentication
and authorization of patient-facing, user-facing, and system
confidential apps
<bullet> support for multi-factor authentication for patient-facing
authentication according to requirements proposed in Sec.
170.315(d)(13)(ii)
<bullet> support for imaging links in data response requirements
<bullet> support for a read and search API for system apps
<bullet> support for ``_type'' query parameter for Bulk FHIR API
<bullet> support for the issuance of verifiable health records as
specified by the requirements proposed in Sec. 170.315(j)(22)
<bullet> support for subscriptions as a server according to the
requirements specified in proposed Sec. 170.315(j)(23)
<bullet> support for workflow triggers for decision support
interventions according to the requirements specified in proposed Sec.
170.315(j)(20)
<bullet> support for authorization revocation for users (e.g.,
clinicians)
<bullet> moving of the API documentation requirements in Sec.
170.315(g)(10) to the API Conditions and Maintenance of Certification
requirements in Sec. 170.404
We propose that by January 1, 2028, a health IT developer of a
Health IT Module certified to the criterion in Sec. 170.315(g)(10)
must update its Health IT Module and provide the updated version to its
customers in order to maintain certification of that Health IT Module.
We propose that any Health IT Modules seeking certification for the
criterion in Sec. 170.315(g)(10) on or after January 1, 2028, would be
to the updated version of the certification criterion.
xx. Patient, Provider, and Payer APIs
The combined exchange of clinical and administrative data among
healthcare payers, patients, and providers is a complex challenge that
can prevent participants in the healthcare system from gaining insights
into the full picture of an individual's care. In order to realize the
benefits of a more unified stream of clinical and administrative data,
patients and health care providers must be able to more efficiently
access and exchange EHI with the entities that steward this
information, especially healthcare payers. In the CMS Interoperability
and Patient Access Final Rule (85 FR 25510), which appeared in the
Federal Register on May 1, 2020, and the CMS Interoperability and Prior
Authorization Final Rule (89 FR 8758), which appeared in the Federal
Register on February 8, 2024, CMS finalized policies for certain
healthcare payers that it regulates \14\ to facilitate patient access
to clinical and administrative data held by payers; availability of
information about provider networks; exchange of information between
payers when beneficiaries patients change coverage; provider access to
data held by payers; and electronic prior authorization.
---------------------------------------------------------------------------
\14\ The ``impacted payers'' under the CMS Interoperability and
Patient Access Final Rule (85 FR 25510) and the CMS Interoperability
and Prior Authorization Final Rule (89 FR 8758) are Medicare
Advantage (MA) organizations, state Medicaid fee-for-service (FFS)
programs, state Children's Health Insurance Program (CHIP) FFS
programs, Medicaid managed care plans, CHIP managed care entities,
and Qualified Health Plan (QHP) issuers on the Federally-facilitated
Exchanges (FFEs).
---------------------------------------------------------------------------
As explained in section III.B.20, we propose a set of certification
criteria in Sec. 170.315(g)(30) through (36) that aim to complement
and advance the policies that CMS has developed to increase patient,
provider, and payer access to information. Health IT developers,
including those that support payers, would be able to ensure that
Health IT Modules certified to these proposed criteria, when used to
satisfy the CMS requirements, have been tested for conformance with
widely available industry standards designed to support
interoperability for each use case. We propose to adopt a set of
HL7[supreg] FHIR[supreg] IGs in Sec. 170.215 to support these
certification criteria, and to incorporate these specifications by
reference in Sec. 170.299.
[[Page 63507]]
2. Conditions and Maintenance of Certification Requirements--Insights
and Attestations
a. Insights Condition and Maintenance of Certification Requirements
As discussed in section III.C.1, we propose to update the Insights
Condition by requiring health IT developers to include health care
provider identifiers, for providers included in the data submitted in
response for the measures specified in Sec. 170.407, to allow us to
better interpret the results of the data received. We also propose
updates to the overall process for reporting and newer versions of
certified health IT for responses submitted under the Insights
Condition in Sec. 170.407(b).
We also propose to update two measures under the Insights
Condition. We propose to revise the ``individuals' access to electronic
health information through certified health IT'' measure in Sec.
170.407(a)(3)(i) to include both individuals and individuals'
authorized representatives accessing their EHI. Additionally, we
propose to revise the name of the measure in Sec. 170.407(a)(3)(ii) to
``C-CDA reconciliation and incorporation through certified health IT''
and propose to require developers to submit responses on specific data
classes and elements from C-CDA documents reconciled and incorporated
both through manual and automated processes in Sec.
170.407(a)(3)(ii)(E). We also intend to make various technical updates
to the measure specification sheets accompanying the Insights
Condition, including the clarification of certain definitions and
terms, as well as adding new metrics.
b. Attestations Condition and Maintenance of Certification Requirements
As discussed in section III.C.2, we propose to revise the
Attestations Condition and Maintenance of Certification requirements by
adding the requirement in Sec. 170.406(a)(2) that a health IT
developer, as a Condition of Certification, attest to compliance with
Sec. 170.402(b)(4), if the health IT developer certified a Health IT
Module(s) to the ``decision support interventions'' certification
criteria in Sec. 170.315(b)(11).
3. Administrative Updates
As discussed in section III.D.1, we propose to revise the Program
correspondence provision (Sec. 170.505) to explicitly specify when
applicants for ONC-Authorized Testing Laboratory (ATL) status,
applicants for ONC-ACB status, ONC-ACBs, ONC-ATLs, health IT developers
or any other party to a proceeding under subpart E of 45 CFR part 170
will be considered to have received correspondence or other written
communication from ONC or the National Coordinator.
As discussed in section III.D.2, we propose to expand ONC-ACBs
responsibilities under Sec. 170.556 for conducting surveillance of
developers' satisfaction of certain Maintenance of Certification
requirements under the Program. We also propose new and revised
principles of proper conduct (PoPCs) in Sec. 170.523 to support the
proposed expanded surveillance responsibilities. Specifically, an ONC-
ACB would be required to monitor Program-participating developers'
satisfaction of specific requirements applicable to the developers
under subpart D of 45 CFR part 170, report results of these
surveillance activities to ONC, and engage with developers where
applicable to encourage corrective action for identified non-
conformities. A new proposed PoPC in Sec. 170.523(x), pursuant to a
new proposed requirement in Sec. 170.556(d)(7)(ii), would require ONC-
ACBs to report to ONC when a developer fails to establish or to
successfully complete an appropriate corrective action plan (CAP) for a
Maintenance of Certification non-conformity identified by an ONC-ACB.
To increase efficiency for developers' documentation of their CAPs,
and ONC-ACBs' review and monitoring of these plans, we propose in Sec.
170.556(d)(3) to tailor the minimum required CAP elements based on the
non-conformities addressed by the CAP. For example, certain CAP
elements designed for non-conformities with certification criteria in
45 CFR subpart C would not be required by regulation in a CAP specific
to a developer having missed a deadline in subpart D, such as for
submission of real world testing documents (Sec. 170.405) or
submission of attestations (Sec. 170.406).
As discussed in section III.D.3, we propose a requirement in Sec.
170.523(m)(6) for ONC-ACBs, beginning January 1, 2027, to obtain a
regular reporting of API discovery details, including service base URLs
and related organization details, that are required by Sec.
170.404(b)(2) and (b)(3). In section III.D.4, we propose a new PoPC for
ONC-ACBs in Sec. 170.523(y) requiring an ONC-ACB to give the National
Coordinator sufficient notice of its intent to withdraw its
authorization under the Program.
In section III.D.5, we discuss our proposal to update the ONC
direct review regulatory framework in 45 CFR 170.580 to align with the
proposed enhancements to the ONC-ACBs' role in surveillance of Program-
participating developers' satisfaction of certain Maintenance of
Certification requirements. To enhance efficiency for developers and
ONC, we propose to revise direct review CAP regulatory requirements to
add flexibility to tailor the minimum elements the developer must
address in such a plan for a non-conformity substantiated through an
ONC direct review. We also propose procedural revisions to Sec.
170.581, suspension and termination of certification procedures in
Sec. 170.580(d) and (f), and hearing officer and appeals provisions in
Sec. 170.580(g)(5) and (7)(ii), to clarify that certain ``ONC''
decisions are in fact made by the National Coordinator, and explicitly
provide for the Secretary to choose to exercise direct oversight of
certain National Coordinator and hearing officer decisions before the
decisions become final. We also propose to revise wording throughout 45
CFR 170.580 and 45 CFR 170.581 to clarify that certain determinations
are made by the National Coordinator (who is appointed by the
Secretary) rather than more generally by or within the Office of the
National Coordinator (the organizational unit headed by the National
Coordinator).
As discussed in section III.D.6, we propose to update paragraphs
(a) and (b) of the certification ban provisions in Sec. 170.581 to
explicitly provide for the Secretary to review, at the Secretary's
discretion, the National Coordinator's determination to impose a
certification ban before the ban becomes effective. In section III.D.7,
we propose to remove the ``Complete EHR'' and ``EHR Module'' terms from
certain sections within subpart E of 45 CFR part 170.
As discussed in section III.D.8, we propose to codify a definition
of serious risk to public health or safety for purposes of Program
regulations in 45 CFR part 170. This definition would enhance
understanding among developers and users of certified health IT of the
types of conditions, events, or phenomena that would constitute a
dangerous non-conformity to Program requirements if caused (or
contributed to) by a product certified under the Program, even if the
Health IT Modules within such product continued to pass lab testing
procedures, in-the-field surveillance testing, or both with respect to
the technical standards and certification criteria adopted in subparts
B and C of part 170. As discussed in section III.D.9, we propose to
remove Sec. 170.550(m) ``time-limited certification and certification
status for certain 2015 Edition certification criteria'' and to
[[Page 63508]]
remove certification criteria with time-limited certification and
certification status, including Sec. 170.315(a)(10), (a)(13), (b)(6),
(e)(2), and (g)(8). Additionally, as discussed in section III.D.9, we
propose to revise Sec. 170.315(b)(7) and (b)(8) to remove Sec.
170.315(b)(7)(ii) and (b)(8)(i)(B), which were time-limited provisions
(now expired) that permitted health IT to demonstrate security tagging
of Consolidated-Clinical Document Architecture (C-CDA) documents at the
document level. In section III.D.10, we propose to revise Sec.
170.550(h), the Privacy and Security Certification Framework
requirements by adding the certification criterion ``decision support
interventions'' in Sec. 170.315(b)(11) to the list of certification
criteria in Sec. 170.550(h)(3)(ii).
4. Correction--Privacy and Security Certification Framework
We propose to make a correction to the Privacy and Security
Certification Framework in Sec. 170.550(h), as discussed in section
III.E. We revised Sec. 170.550(h) in the ONC Cures Act Final Rule but
intended for Sec. 170.550(h)(4) to remain unchanged. However, when we
drafted the amendatory instructions, we erroneously included the
instruction to revise all of paragraph (h) (85 FR 25952). Therefore,
when the Code of Federal Regulations was updated, Sec. 170.550(h)(4)
was removed. We now propose to add the Sec. 170.550(h)(4) that existed
prior to the ONC Cures Act Final Rule being finalized.
5. Information Blocking Enhancements
In this rule, we propose revisions to defined terms for purposes of
the information blocking regulations, which appear in 45 CFR 171.102.
We propose to revise three existing exceptions in subpart B of 45 CFR
part 171 and solicit comment on potential revisions to one exception in
subpart D. We propose two new exceptions, one in each in subparts B and
C of part 171. We propose to codify in Sec. 171.401 definitions of
certain terms relevant to the Trusted Exchange Framework and Common
Agreement\TM\ (TEFCA\TM\) and in Sec. 171.104 descriptions of certain
practices that constitute interference with the access, exchange, and
use of electronic health information (EHI).
As discussed in section IV.A.1, we propose to amend the definition
of ``health care provider,'' codified in 45 CFR 171.10,2 so that it is
explicitly clear that it references 42 U.S.C. 300jj(3) and that for
purposes of this definition the terms ``laboratory'' and ``pharmacist''
have the meanings established for these terms in 42 U.S.C. 300jj(10)
and (12), respectively. In IV.A.2, we propose that for purposes of the
information blocking regulations in 45 CFR part 171 both ``health
information technology'' and its shorter form, ``health IT,'' have the
same meaning as ``health information technology'' in 42 U.S.C.
300jj(5).
For purposes of the information blocking definition (Sec.
171.103), the term ``interfere with or interference'' is currently
defined in Sec. 171.102. Informed by the concerns and questions that
interested parties have brought to our attention, we propose in section
IV.A.3 to add a section (Sec. 171.104) to the information blocking
regulations that would codify certain practices (acts and omissions)
that constitute interferences for purposes of the information blocking
definition (codified in Sec. 171.103). The proposed codified practices
are not an exhaustive list; additional practices not described in the
proposed Sec. 171.104 that are likely to interfere with, prevent, or
materially discourage access, exchange, or use of EHI may also be
considered to rise to the level of an interference. The proposed
codification of these specific practices is intended to provide actors,
and those who seek to engage in EHI access, exchange, or use with
actors, certainty that these specific practices constitute
interference. The codification of these practices may also help
regulated entities and other interested parties to consider the
likelihood that any practice an actor might contemplate or engage in
may also meet the definition of ``interference'' and ``interfere with''
(as defined in Sec. 171.102) for purposes of the information blocking
regulations (45 CFR part 171).
For purposes of the information blocking Privacy Exception, the
term ``individual'' is defined in Sec. 171.202(a)(2). As currently
worded, this text includes cross-references to incorrect citations
within Sec. 171.202(a)(2). The text also includes one unnecessary
cross-reference citation within Sec. 171.202(a)(2). We do not propose
to change the substance of the definition, but in section IV.B.1.a, we
propose technical corrections to the cross-reference citations within
Sec. 171.202(a)(2)(iii), (iv), and (v).
In section IV.B.1.b, to clearly establish coverage of the Sec.
171.202(d) sub-exception for all actors' practices under the same
requirements, we propose to change the name of the sub-exception to:
``interfering with individual access based on unreviewable grounds.''
This proposed change to the header text is intended to express the
expansion of its availability to actors who are not Health Insurance
Portability and Accountability Act of 1996 (HIPAA) covered entities or
business associates (as defined in 45 CFR 160.103). As explained in
section IV.B.1.c, we propose to slightly modify the header of Sec.
171.202(e) for ease of reference to ``Individual's request not to share
EHI.'' More importantly, we propose to revise the Sec. 171.202(e) sub-
exception to remove the existing limitation that allows the exception
to be used only for individual-requested restrictions on EHI sharing
that are permitted by other applicable law. The proposal would extend
the availability of the Sec. 171.202(e) sub-exception to an actor's
practice of applying restrictions the individual has requested on the
access, exchange, or use of an individual's EHI even when the actor may
have concern that another law applicable to some or all of the actor's
operations could compel the actor to provide access, exchange, or use
of EHI contrary to the individual's expressed wishes.
We propose, as discussed in section IV.B.2, revisions to three
conditions of the Infeasibility Exception (45 CFR 171.204).
Specifically, we propose to modify the Sec. 171.204(a)(2) segmentation
condition to enhance clarity and certainty, and to provide for its
application to additional specific situations. We propose to revise the
condition to specifically cross-reference additional information
blocking exceptions under which an actor may choose to withhold EHI
that the actor could, under applicable law, make available.
We propose to modify the Sec. 171.204(a)(3) third party seeking
modification use condition by changing the words ``health care
provider'' to ``covered entity as defined in 45 CFR 160.103'' in the
exclusion from applicability of this condition. We also propose in
Sec. 171.204(a)(3)(ii) to extend the exclusion from applicability of
the third party seeking modification use condition requests for
modification use from health care providers, as defined in Sec.
171.102 and who are not covered entities, requesting such use from
actors whose activities would make them a business associate of that
same health care provider if the healthcare provider (actor) was
covered by HIPAA.
We propose to modify the Sec. 171.204(b) responding to requests
condition by establishing different timeframes for sending written
responses to the requestor based on the Sec. 171.204(a) condition
under which fulfilling the requested access, exchange, or use of EHI is
infeasible. The proposed revision would retain the requirement that
actors communicate to requestors ``in writing the reason(s) why the
request is infeasible'' that we
[[Page 63509]]
finalized in the ONC Cures Act Final Rule. We discuss these proposals
further in sections IV.B.2.a through c of this proposed rule.
In section IV.B.3, we propose a new Protecting Care Access
Exception that would, under specified conditions (see sections IV.B.3.b
through d and the draft regulatory text of proposed Sec. 171.206),
apply to acts or omissions likely to interfere with access, exchange,
or use of particular EHI that an actor believes could create a risk of
exposing patients, care providers, and other persons who assist in
access or delivery of health care to potential administrative, civil,
or criminal investigations or other actions on certain bases. A summary
of these bases follows below in this section. (Please see section
IV.B.3 of this proposed rule for detailed discussion.)
The proposed Protecting Care Access Exception (Sec. 171.206) would
be a new exception in addition to the other information blocking
exceptions. The proposed new exception is designed to create certainty
for actors that certain practices for which no other exception would
apply will not be considered ``information blocking'' under the
information blocking statute (PHSA section 3022) and regulations (45
CFR part 171). Like any existing or proposed information blocking
exception in 45 CFR part 171, the proposed Protecting Care Access
Exception (Sec. 171.206) is not intended to override any provision of
another law that is independently applicable to the actor.
The practices that the proposed Protecting Care Access Exception
(Sec. 171.206) would except from the information blocking definition
would be those implemented based on the actor's good faith belief that
sharing EHI indicating that any person(s) sought, received, provided,
or facilitated the provision or receipt of reproductive health care
that was lawful under the circumstances in which it was provided could
result in a risk of potential exposure to legal action for those
persons and that the risk could be reduced by practices likely to
interfere with particular access, exchange, or use of specific EHI. For
purposes of the Protecting Care Access Exception, we propose to rely on
the same definition of ``reproductive health care'' (which can be found
in 45 CFR 160.103) that is used for purposes of the HIPAA regulations.
In addition, we discuss in section IV.B.3.b how we would interpret
whether care is ``lawful under the circumstances in which it is
provided.''
To satisfy the proposed new Protecting Care Access (Sec. 171.206)
Exception, an actor's practice would need to satisfy the threshold
condition (Sec. 171.206(a)), and at least one of the other two
conditions in the exception: the patient protection condition (Sec.
171.206(b)) or the care access condition (Sec. 171.206(c)). The
combination of conditions required to satisfy the proposed new
Protecting Care Access Exception and the definition of ``legal action''
(in Sec. 171.206(d)) for purposes of the exception would, together,
ensure that the exception would not apply to an actor's attempts to
shield any person from legal action based on allegations that health
care items or services the person provided are substandard.
These provisions together would also ensure that the exception
focuses on the specific situation where an actor limits the sharing of
EHI because the actor believes it could result in a risk of potentially
exposing the patient or another person to an investigation or other
civil, criminal, or administrative action based on the mere fact that
the person sought, obtained, provided, or facilitated reproductive
health care that was lawful under the circumstances in which it was
provided. For instance, the exception would not apply to an actor's
attempt to interfere with EHI sharing in order to reduce a patient's or
other person's risk of exposure to a criminal investigation or charges
not related to the act of seeking, obtaining, providing, or
facilitating reproductive health care. For example, the act of not
sharing information because of the risk of a criminal investigation
related to operating a vehicle while intoxicated or committing fraud
would not be covered under this exception.
The Protecting Care Access Exception's threshold condition (Sec.
171.206(a)), proposed in section IV.B.3.b, includes requirements that
the practice be: undertaken based on the actor's belief as specified in
Sec. 171.206(a)(1), no broader than necessary as specified in Sec.
171.206(a)(2), and be implemented consistent with a written
organizational policy or case-by-case determination contemporaneously
documented in writing as specified in Sec. 171.206(a)(3). Meeting the
threshold condition would be necessary, but not alone sufficient, for
an actor's practice to be covered by the proposed Protecting Care
Access (Sec. 171.206) exception. To satisfy the exception, any actor's
practice likely to interfere with access, exchange, or use of EHI would
also need to satisfy at least one of the other two conditions (in
paragraphs (b) and (c)) of the proposed exception.
In section IV.B.3.c, we propose a patient protection condition
(Sec. 171.206(b)), that can be met by practices implemented by the
actor for the purpose of reducing a risk of potential legal action that
the actor believes a patient could otherwise face because the EHI shows
or invites a reasonable inference that the patient has or has done any
of the following (see proposed Sec. 171.206(b)(1)):
(i) obtained reproductive health care that was lawful under the
circumstances in which it was provided;
(ii) Inquired about or expressed an interest in seeking
reproductive health care; or
(iii) Particular demographic characteristics or any health
condition(s) or history for which reproductive health care is often
sought, obtained, or medically indicated.
The proposed patient protection condition would specify (Sec.
171.206(b)(2)) that to meet the condition the actor's practice must be
subject to nullification by explicit request or directive from the
patient. We also clarify (in proposed Sec. 171.206(b)(3)) that for
purposes of the patient protection condition's other paragraphs that
``patient'' means the natural person who is the subject of the EHI or
another natural person referenced in, or identifiable from, the EHI as
having sought or received reproductive health care.\15\
---------------------------------------------------------------------------
\15\ The definition of ``person'' for purposes of 45 CFR part
171 is codified in Sec. 171.102 and is, by cross-reference to 45
CFR 160.103, the same definition used for purposes of the HIPAA
Privacy Rule (45 CFR part 160 and subpart E of 45 CFR part 164). The
Sec. 160.103 definition of ``person'' clarifies the meaning of
``natural person'' within it. We use ``natural person'' in this
proposed rule with that same meaning.
---------------------------------------------------------------------------
In section IV.B.3.d, we propose a care access condition (Sec.
171.206(c)) that can be met by practices an actor might choose to
implement for the purpose of reducing a risk of potential exposure to
legal action for licensed health care professionals, other health care
providers, or persons involved in providing or in facilitating the
provision or receipt of reproductive health care that is lawful under
the circumstances in which such health care is provided. We request
comment on multiple, potentially non-exclusive, alternative proposals
for additional requirements under the care access condition that would
function to restrict the exception's coverage of practices that
interfere with access, exchange, or use in scenarios that also
implicate the HIPAA Privacy Rule's individual right of access
provisions (45 CFR 164.524). In order to satisfy this proposed
condition, if finalized, the practice would need to meet the
requirements finalized in Sec. 171.206(c).
We propose clarifying provisions in Sec. 171.206(d) (discussed in
section
[[Page 63510]]
IV.B.3.b of this proposed rule) and Sec. 171.206(e) (discussed in
section IV.B.3.e of this proposed rule). Proposed Sec. 171.206(d)
would clarify when reproductive health care sought, obtained, provided,
or facilitated by someone other than the actor will be presumed to have
been lawful for purposes of assessing whether an actor's practice meets
the exception's patient protection or care access condition. In Sec.
171.206(e) we propose to define ``legal action'' for purposes of Sec.
171.206. We propose in section IV.B.4, a new information blocking
exception: ``Requestor Preferences'' in 45 CFR 171.304. This exception
would stand separate from and independent of other exceptions and would
apply where an actor honors or adheres to a requestor's preference(s)
expressed or confirmed in writing for: (1) limitations on the amount of
EHI made available to the requestor; (2) the conditions under which EHI
is made available to the requestor; and (3) when EHI is made available
to the requestor for access, exchange, or use. The exception would
offer an actor certainty that, so long as the actor's practices meet
the conditions of the exception, the actor can honor or adhere to a
requestor's preferences related to these specific preferences without
concern that the actor may be engaging in ``information blocking'' as
defined in 45 CFR 171.103.
We propose to add a new definitions section in Sec. 171.401 for
certain terms used in Subpart D, which we propose to align with the
definitions used in the proposed 45 CFR 172. We seek comment on some
aspects of the TEFCA Manner Exception in 45 CFR 171.403, including the
limitation on its use for requests made via a FHIR API and the
application of the Fees and Licensing Exceptions to practices that
satisfy the exception.
6. Trusted Exchange Framework and Common Agreement\TM\
Section 3001(c)(9) of PHSA, as added by the 21st Century Cures Act
(Pub. L. 114-255, Dec. 13, 2016) (Cures Act), calls for the development
or support of a ``trusted exchange framework, including a common
agreement among health information networks nationally.'' On January
19, 2022, ONC published in the Federal Register the Notice of
Publication of the Trusted Exchange Framework and Common Agreement (87
FR 2800), in which ONC published the Trusted Exchange Framework (TEF):
Principles for Trusted Exchange and the Common Agreement for Nationwide
Health Information Interoperability Version 1. ONC published in the
Federal Register a notice titled Trusted Exchange Framework and Common
Agreement Version 1.1 on November 7, 2023 (88 FR 76773), in which ONC
published the Common Agreement for Nationwide Health Information
Interoperability Version 1.1 (November 2023), and published version 2.0
implementing the latest industry standards among other changes on May
1, 2024 (89 FR 35107). Section 3001(c)(9)(A) of the PHSA states that
the overall goal for TEFCA\TM\ is to ensure full network-to-network
exchange of health information. ONC intends to accomplish this by
establishing a floor for interoperability under TEFCA across the
country. The Common Agreement \16\ is authorized by section
3001(c)(9)(B)(i) of the statute, which addresses: baseline legal and
technical requirements for the Common Agreement, organizational and
operational policies to enable exchange, minimum conditions for
exchange, and a process for filing and adjudicating noncompliance with
its terms. The Common Agreement addresses all of these to enable users
in different health information networks (HINs) to securely share
information with each other--all under commonly agreed-to expectations
and terms. The Trusted Exchange Framework,\17\ authorized under the
same provision of the PHSA, describes a common set of principles for
policies and practices to facilitate data-sharing.
---------------------------------------------------------------------------
\16\ Common Agreement for Nationwide Health Information
Interoperability, Version 1.1 (November 2023), available at Federal
Register:: Trusted Exchange Framework and Common Agreement Version
1.1.
\17\ The Trusted Exchange Framework (TEF): Principles for
Trusted Exchange (January 2022), available at <a href="https://www.healthit.gov/sites/default/files/page/2022-01/Trusted_Exchange_Framework_0122.pdf">https://www.healthit.gov/sites/default/files/page/2022-01/Trusted_Exchange_Framework_0122.pdf</a>.
---------------------------------------------------------------------------
The Recognized Coordinating Entity[supreg] (RCE\TM\) is an ONC
contractor that is charged with helping ONC to develop, operationalize,
and update the Common Agreement, as well as assist ONC in stewarding
the Qualified Health Information Network\TM\ (QHIN\TM\) Technical
Framework (QTF),\18\ which provides the technical specifications for
how QHINs connect to one another. The RCE also helps ONC to oversee
QHIN-facilitated network operations and QHIN compliance with the Common
Agreement.
---------------------------------------------------------------------------
\18\ Qualified Health Information Network (QHIN) Technical
Framework, Version 1.0 (January 2022), available at <a href="https://rce.sequoiaproject.org/wp-content/uploads/2022/01/QTF_0122.pdf">https://rce.sequoiaproject.org/wp-content/uploads/2022/01/QTF_0122.pdf</a>.
---------------------------------------------------------------------------
As explained in the proposed part 172 of subchapter D of title 45
of the Code of Federal Regulations, by standardizing health information
exchange across many different networks, TEFCA will help to ensure full
network-to-network exchange of health information. Doing so will
simplify exchange by significantly reducing the number of connections
(e.g., portals) that individuals, health care providers, and other
interested parties need to make to get the health information they
seek. It does so by creating baseline governance, legal, and technical
requirements that will enable secure information sharing across
different networks nationwide, including: a common method for
authenticating trusted network participants, a common set of rules for
trusted exchange, organizational and operational policies to enable the
exchange of health information among networks, and a process for filing
and adjudicating noncompliance with the terms of the Common Agreement.
As explained in proposed part 172, we believe that TEFCA will help
lower the cost and expand the nationwide availability of secure health
information exchange capabilities. The availability of TEFCA-based
services, such as electronic address directories and patient record
location, will also help scale health information exchange nationwide
and usher in new support for FHIR API usage and adoption. FHIR API
usage and adoption has become a centerpiece of the interoperability
initiatives of ONC and other U.S. government agencies such as CDC,\19\
CMS,\20\ Health Resources and Services Administration (HRSA),\21\ and
the Veteran's Administration (VA).\22\
---------------------------------------------------------------------------
\19\ See CDC, Public Health Informatics Office (PHIO), <a href="https://www.cdc.gov/csels/phio/it_takes_practice.html">https://www.cdc.gov/csels/phio/it_takes_practice.html</a>.
\20\ See CMS, Policies and Technology for Interoperability and
Burden Reduction, <a href="https://www.cms.gov/policies-and-technology-interoperability-and-burden-reduction">https://www.cms.gov/policies-and-technology-interoperability-and-burden-reduction</a>.
\21\ See HRSA, Uniform Data System (UDS) Modernization
Initiative, <a href="https://bphc.hrsa.gov/data-reporting/uds-training-and-technical-assistance/uniform-data-system-uds-modernization-initiative">https://bphc.hrsa.gov/data-reporting/uds-training-and-technical-assistance/uniform-data-system-uds-modernization-initiative</a>.
\22\ See VA, VA Technical Reference Model v 23.12, <a href="https://www.oit.va.gov/Services/TRM/StandardPage.aspx?tid=8233">https://www.oit.va.gov/Services/TRM/StandardPage.aspx?tid=8233</a>.
---------------------------------------------------------------------------
In section V of this proposed rule, we propose to implement certain
provisions related to TEFCA in order to provide greater process
transparency and further implement section 3001(c)(9) of the PHSA, as
added by the Cures Act. We propose to add a new part, part 172, to
subchapter D of title 45 of the Code of Federal Regulations to
implement certain provisions related to the TEFCA. These proposed
provisions would establish the processes associated with the
qualifications necessary for an entity to receive and maintain
Designation (as we propose to define that term in Sec. 172.102) as a
QHIN capable of trusted exchange under the Common
[[Page 63511]]
Agreement. The proposals would also establish the procedures governing
Onboarding (as we propose to define that term in Sec. 172.102) of
QHINs and Designation of QHINs, suspension, termination, and
administrative appeals to ONC, as described in the sections below. We
believe establishing these provisions in regulation would support
reliability, privacy, security, and trust within TEFCA, which would
further TEFCA's ultimate success.
In subpart A, we propose the statutory basis, purpose, and scope of
the TEFCA provisions in part 172; the applicability of the TEFCA
provisions in part 172; and relevant definitions. In subpart B, we
propose requirements related to the qualifications needed to be
Designated, as proposed to be defined in Sec. 172.102. In subpart C,
we describe the proposed QHIN Onboarding and Designation processes. In
subpart D, we propose RCE and QHIN suspension rights, notice
requirements for suspension, and the requirements related to the effect
of suspension. In subpart E, we propose RCE and QHIN termination
rights, notice requirements for termination, and requirements related
to the effect of termination. In subpart F, we propose to establish
QHIN appeal rights and the process for filing an appeal to ONC. These
appeal rights would ensure that a QHIN, or Applicant QHIN, that (1)
disagrees with certain RCE determinations or (2) believes an action or
inaction by a QHIN or the RCE could threaten TEFCA's integrity will
have recourse to appeal such determination, action, or inaction to ONC.
In subpart G, we propose requirements related to QHIN attestation
for the Adoption of TEFCA. This subpart implements section
3001(c)(9)(D) of the PHSA. Section 3001(c)(9)(D)(i) requires the
publication on ONC's website of those HINs that have adopted the Common
Agreement and are capable of trusted exchange pursuant to the Common
Agreement. Section 3001(c)(9)(D)(ii) requires HHS to establish, through
notice and comment rulemaking, a process for HINs that voluntarily
elect to adopt TEFCA to attest to such adoption.
C. Severability
It is our intent that if any provision of this rule were, if or
when finalized, held to be invalid or unenforceable facially, or as
applied to any person, plaintiff, or stayed pending further judicial or
agency action, such provision shall be severable from other provisions
of this rule, and from rules and regulations currently in effect, and
not affect the remainder of this rule. It is also our intent that,
unless such provision shall be held to be utterly invalid or
unenforceable, it be construed to give the provision maximum effect
permitted by law including in the application of the provision to other
persons not similarly situated or to other, dissimilar circumstances
from those where the provision may be held to be invalid or
unenforceable.
In this rule, we propose provisions that are intended to and will
operate independently of each other, even if multiple of them serve the
same or similar general purpose(s) or policy goal(s). Where a provision
is necessarily dependent on another, the context generally makes that
clear (such as by cross-reference to a particular standard,
requirement, condition, or pre-requisite). Where a provision that is
dependent on one that is stayed or held invalid or unenforceable (as
described in the preceding paragraph) is included in a subparagraph,
paragraph, or section within part 170, 171, or 172 of 45 CFR, we intend
that other provisions of such subparagraph(s), paragraph(s), or
section(s) that operate independently of said provision would remain in
effect.
To ensure our intent for severability of provisions is clear in the
CFR, we propose to add to existing Sec. 170.101 and Sec. 171.101, and
to include in the proposed new Sec. 172.101 a paragraph stating our
intent that if any provision is held to be invalid or unenforceable it
shall be construed to give maximum effect to the provision permitted by
law, unless such holding shall be one of utter invalidity or
unenforceability, in which case the provision shall be severable from
this part and shall not affect the remainder thereof or the application
of the provision to other persons not similarly situated or to other
dissimilar circumstances.
D. Costs and Benefits
Executive Orders 12866 and 13563 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). Executive
Order 14094 entitled ``Modernizing Regulatory Review'' (hereinafter,
the Modernizing E.O.) amends section 3(f) of Executive Order 12866
(Regulatory Planning and Review). The amended section 3(f) of Executive
Order 12866 defines a ``significant regulatory action'' as an action
that is likely to result in a rule that may: (1) have an annual effect
on the economy of $200 million or more (adjusted every 3 years by the
Administrator of the Office of Information and Regulatory Affairs
(OIRA) for changes in gross domestic product); or adversely affect in a
material way the economy, a sector of the economy, productivity,
competition, jobs, the environment, public health or safety, or State,
local, territorial, or Tribal governments or communities; (2) create a
serious inconsistency or otherwise interfere with an action taken or
planned by another agency; (3) materially alter the budgetary impacts
of entitlement grants, user fees, or loan programs or the rights and
obligations of recipients thereof; or (4) raise legal or policy issues
for which centralized review would meaningfully further the President's
priorities or the principles set forth in this Executive Order, as
specifically authorized in a timely manner by the Administrator of OIRA
in each case. OMB has determined that this proposed rule is a
significant regulatory action, as the potential economic impacts
associated with this proposed rule could be greater than $200 million
per year. Accordingly, we have prepared a Regulatory Impact Analysis
(RIA) that, to the best of our ability, presents the costs and benefits
of this proposed rule. We have estimated the potential monetary costs
and benefits of this proposed rule for the health IT community,
including costs and benefits as they relate to health IT developers,
health care providers, patients, and the Federal Government (i.e.,
ONC), and have broken those costs and benefits out by section. In
accordance with E.O. 12866, we have included the RIA summary table as
Table 82.
We note that we have rounded all estimates to the nearest dollar
and that all estimates are expressed in 2022 dollars as it is the most
recent data available to address all cost and benefit estimates
consistently. The wages used to derive the cost estimates are from the
May 2022 National Occupational Employment and Wage Estimates reported
by the U.S. Bureau of Labor Statistics.\23\ We also note that estimates
presented in sections titled ``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
Proposed Regulations'' are used throughout this RIA.
---------------------------------------------------------------------------
\23\ May 2022 National Occupational Employment and Wage
Estimates, United States. U.S. Bureau of Labor Statistics. <a href="https://www.bls.gov/oes/current/oes_nat.htm">https://www.bls.gov/oes/current/oes_nat.htm</a>.
---------------------------------------------------------------------------
We estimate that the total annual cost for this proposed rule for
the first year
[[Page 63512]]
after it is finalized (including one-time costs), based on the cost
estimates outlined above and throughout this RIA, would result in
$431.1 million. The total undiscounted perpetual cost over a 10-year
period for this proposed rule (starting in year two), based on the cost
estimates outlined above, would result in $398.1 million. We estimate
the total costs to health IT developers to be $829.2 million.
We estimate the total annual benefit across all entities for this
proposed rule beginning in Year 3, when the associated policies are
required to be implemented and expected benefits to be realized, would
be on average $22.2 million. We estimate the total benefits across all
entities to be $177.6 million. We estimate the total undiscounted
perpetual annual net benefit for this proposed rule (starting in year
three), based on the estimates outlined above, would result in a net
benefit of $75.4 million.
II. Background
A. Statutory Basis
The Health Information Technology for Economic and Clinical Health
Act (HITECH Act), Title XIII of Division A and Title IV of Division B
of the American Recovery and Reinvestment Act of 2009 (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 healthcare quality,
safety, and efficiency through the promotion of health IT and EHI
exchange.
The 21st Century Cures Act (Pub. L. 114-255) (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, through Title IV--Delivery, amended the HITECH Act by modifying or
adding certain provisions to the PHSA relating to health IT.
Section 119 of Title I, Division CC of the Consolidated
Appropriations Act, 2021, Public Law 116-260 (CAA), enacted on December
27, 2020, requires sponsors of prescription drug plans to implement one
or more real-time benefit tools (RTBTs) that meet the requirements
described in the statute, after the Secretary has adopted a standard
for RTBTs and at a time determined appropriate by the Secretary. For
purposes of the requirement to implement a real-time benefit tool in
section 1860D-4(o)(1) of the Social Security Act, described above, the
CAA provides that one of the requirements for an RTBT is that it can
integrate with electronic prescribing and EHR systems of prescribing
healthcare professionals for the transmission of formulary and benefit
information in real time to such professionals. The statute requires
incorporation of RTBTs within both the Medicare Part D prescription
drug program and the ONC Health IT Certification Program (Program).
Specifically, the law amends the definition of a ``qualified electronic
health record'' (qualified EHR) in section 3000(13) of the PHSA to
require that a qualified EHR must include (or be capable of including)
an RTBT.
1. Standards, Implementation Specifications, and Certification Criteria
The HITECH Act established two Federal advisory committees, the
Health IT Policy Committee (HITPC) and the Health IT 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 4003(e) of the Cures Act amended sections 3002 and 3003 of
the PHSA by replacing, in an amended section 3002, the HITPC and HITSC
with one committee named the Health Information Technology Advisory
Committee (Health IT Advisory Committee or HITAC). Section 3002(a) of
the PHSA, as added by the Cures Act, establishes that the HITAC
recommends to the National Coordinator policies and standards,
implementation specifications, and certification criteria, relating to
the implementation of a health information technology infrastructure,
nationally and locally, that advances the electronic access, exchange,
and use of health information. Further described in section 3002(b)(1)
of the PHSA, this includes recommending to the National Coordinator a
policy framework to advance interoperable health information technology
infrastructure, updating recommendations to the policy framework, and
making new recommendations, as appropriate. Section 3002(b)(2)(A) of
the PHSA specifies that in general, the HITAC shall recommend to the
National Coordinator for purposes of adoption under section 3004,
standards, implementation specifications, and certification criteria
and an order of priority for the development, harmonization, and
recognition of such standards, specifications, and certification
criteria. Like the process previously required of the former HITPC and
HITSC, section 3002(b)(5) of the PHSA requires the HITAC to develop a
schedule, updated annually, for the assessment of policy
recommendations, which the Secretary publishes in the Federal Register.
Section 3004 of the PHSA establishes 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 such
standards, implementation specifications, or certification criteria.
Section 3004(a)(3) requires the Secretary to publish all such
determinations in the Federal Register.
Section 3004(b)(3) of the PHSA, 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 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. ONC Health IT Certification Program Rules
Section 3001(c)(5) of the PHSA provides the National Coordinator
with the authority to establish a certification program or programs for
the voluntary certification of health IT. 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 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.
Section 13201(b) of the HITECH Act requires that, with respect to the
development of
[[Page 63513]]
standards and implementation specifications, the Director of NIST shall
support the establishment of a conformance testing infrastructure,
including the development of technical test beds. 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 4003(b) of the Cures Act added section 3001(c)(9)(B)(i) to
the PHSA, which requires the National Coordinator ``to convene
appropriate public and private stakeholders'' with the goal of
developing or supporting a Trusted Exchange Framework and a Common
Agreement (collectively, ``TEFCA'') for the purpose of ensuring full
network-to-network exchange of health information. Section
3001(c)(9)(B) outlines provisions related to the establishment of a
Trusted Exchange Framework for trust policies and practices and a
Common Agreement for exchange between health information networks
(HINs)--including provisions for the National Coordinator, in
collaboration with the NIST, to provide technical assistance on
implementation and pilot testing of TEFCA. Section 3001(c)(9)(C)
requires the National Coordinator to publish TEFCA on its website and
in the Federal Register. Section 3001(c)(9)(D)(i) requires the National
Coordinator to publish a list of HINs that have adopted TEFCA. Section
3001(c)(9)(D)(ii) requires the Secretary to establish a process for
HINs to attest that they have adopted TEFCA.
Section 4002(a) of the Cures Act amended section 3001(c)(5) of the
PHSA by adding section 3001(c)(5)(D), which requires the Secretary,
through notice and comment rulemaking, to require conditions of
certification and maintenance of certification for the Program.
Specifically, the health IT developers or entities with technology
certified under the Program must, in order to maintain such
certification status, adhere to certain conditions and maintenance of
certification requirements concerning information blocking; assurances
regarding 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 in accordance with section 3009A(b) of the PHSA.
B. Regulatory History
The Secretary issued an interim final rule with request for
comments on January 13, 2010, ``Health Information Technology: Initial
Set of Standards, Implementation Specifications, and Certification
Criteria for Electronic Health Record Technology'' (75 FR 2014), which
adopted an initial set of standards, implementation specifications, and
certification criteria. On March 10, 2010, the Secretary issued a
proposed rule, ``Proposed Establishment of Certification Programs for
Health Information Technology'' (75 FR 11328), that proposed both
temporary and permanent certification programs for the purposes of
testing and certifying health IT. A final rule establishing the
temporary certification program was published on June 24, 2010,
``Establishment of the Temporary Certification Program for Health
Information Technology'' (75 FR 36158), and a final rule establishing
the permanent certification program was published on January 7, 2011,
``Establishment of the Permanent Certification Program for Health
Information Technology'' (76 FR 1262).
We have engaged in multiple rulemakings to update standards,
implementation specifications, certification criteria, and the Program,
a history of which can be found in the October 16, 2015 final rule
``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). The history can be found at 80 FR 62606. A final
rule making corrections and clarifications 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 minimum capabilities and
specified the related minimum standards and implementation
specifications that Certified EHR Technology (CEHRT) would need to
include to 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 Programs and the
Promoting Interoperability performance category under MIPS) when the
2015 Edition is required for use under these and other programs
referencing the CEHRT definition. The final rule also 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 Principles of Proper Conduct (PoPC) for ONC-
ACBs.
After issuing a proposed rule on March 2, 2016, ``ONC Health IT
Certification Program: Enhanced Oversight and Accountability'' (81 FR
11056), we published a final rule by the same title (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 set forth processes for us to
authorize and oversee accredited testing laboratories under the
Program. In addition, it included 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) (ONC Cures Act
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.
We also requested comment in the ONC Cures Act Proposed Rule (84 FR
7467) as to whether certain health IT developers should be required to
participate in 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, with the goal of
developing or
[[Page 63514]]
supporting TEFCA for the purpose of ensuring full network-to-network
exchange of health information.
On May 1, 2020, a final rule was published titled, ``21st Century
Cures Act: Interoperability, Information Blocking, and the ONC Health
IT Certification Program'' (85 FR 25642) (ONC Cures Act Final Rule).
The final rule implemented certain provisions of the Cures Act,
including Conditions and Maintenance of Certification requirements for
health IT 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
implemented certain parts of the Cures Act to support patients' access
to their EHI, and the implementation of information blocking policies
that support patient electronic access. Additionally, the final rule
modified the 2015 Edition health IT certification criteria and Program
in other ways to advance interoperability, enhance health IT
certification, and reduce burden and costs, as well as improving
patient and health care provider access to EHI and promoting
competition. On November 4, 2020, the Secretary published an interim
final rule with comment period titled, ``Information Blocking and the
ONC Health IT Certification Program: Extension of Compliance Dates and
Timeframes in Response to the COVID-19 Public Health Emergency'' (85 FR
70064) (Cures Act Interim Final Rule). The interim final rule extended
certain compliance dates and timeframes adopted in the ONC Cures Act
Final Rule to offer the healthcare system additional flexibilities in
furnishing services to combat the COVID-19 pandemic, including
extending the applicability date for information blocking provisions to
April 5, 2021.
On April 18, 2023, the Secretary published a proposed rule titled,
``Health Data, Technology, and Interoperability: Certification Program
Updates, Algorithm Transparency, and Information Sharing'' (88 FR
23746) (HTI-1 Proposed Rule). The HTI-1 Proposed Rule proposed to
implement the Electronic Health Record (EHR) Reporting Program
provision of the Cures Act by establishing new Conditions and
Maintenance of Certification requirements for health IT developers
under the Program. The HTI-1 Proposed Rule also proposed to make
several updates to certification criteria and implementation
specifications recognized by the Program, including revised
certification criterion for: ``clinical decision support'' (CDS),
``patient demographics and observations'', and ``electronic case
reporting.'' The HTI-1 Proposed Rule also proposed to establish a new
baseline version of the United States Core Data for Interoperability
(USCDI). Additionally, the HTI-1 Proposed Rule proposed enhancements to
support information sharing under the information blocking regulations.
On January 9, 2024, the Secretary issued the ``Health Data,
Technology, and Interoperability: Certification Program Updates,
Algorithm Transparency, and Information Sharing'' final rule (HTI-1
Final Rule), which implemented the EHR Reporting Program provision of
the 21st Century Cures Act and established new Conditions and
Maintenance of Certification requirements for health IT developers
under the Program (89 FR 1192). The HTI-1 Final Rule also made several
updates to certification criteria and standards recognized by the
Program. The Program updates included revised certification criteria
for ``decision support interventions,'' ``patient demographics and
observations,'' and ``electronic case reporting,'' as well as adopted a
new baseline version of the USCDI standard, USCDI Version 3.
Additionally, the HTI-1 Final Rule provided enhancements to support
information sharing under the information blocking regulations. Through
these provisions, we sought to advance interoperability, improve
algorithm transparency, and support the access, exchange, and use of
EHI. The HTI-1 Final Rule also updated numerous technical standards in
the Program in additional ways to advance interoperability, enhance
health IT certification, and reduce burden and costs for health IT
developers and users of health IT.
On November 15, 2023, the Secretary issued a proposed rule titled,
``Medicare Program; Contract Year 2025 Policy and Technical Changes to
the Medicare Advantage Program, Medicare Prescription Drug Benefit
Program, Medicare Cost Plan Program, and Programs of All-Inclusive Care
for the Elderly; Health Information Technology Standards and
Implementation Specifications'' (88 FR 78476). This proposed rule
proposed to adopt the National Council for Prescription Drug Programs
(NCPDP) Real-Time Prescription Benefit standard version 13.
On June 17, 2024, the Secretary issued the Part D and Health IT
Standards final rule (89 FR 51238 through 51265). This final rule
adopted the NCPDP Real-Time Prescription Benefit standard version 13 in
45 CFR 170.205(c)(1) and to incorporate this standard by reference in
45 CFR 170.299. In this final rule, CMS also adopted requirements for
Part D sponsors to use the standard in in 45 CFR 170.205(c)(1) when
implementing an RTBT.
III. ONC Health IT Certification Program Updates
A. Standards and Implementations 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 \24\ 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 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 it is 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. In this proposed rule, we use
voluntary consensus standards except for:
---------------------------------------------------------------------------
\24\ <a href="https://www.whitehouse.gov/wp-content/uploads/2020/07/revised_circular_a-119_as_of_1_22.pdf">https://www.whitehouse.gov/wp-content/uploads/2020/07/revised_circular_a-119_as_of_1_22.pdf</a>.
---------------------------------------------------------------------------
<bullet> The USCDI v4 standard. We propose to adopt USCDI v4 in
Sec. 170.213. This standard is a hybrid of government 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);
<bullet> The Federal Information Processing Standard (140-2)
related to the
[[Page 63515]]
protection of electronic health information adopted in Sec. 170.210;
<bullet> The CMS standards for QRDA I and III respectively adopted
in Sec. 170.205(h)(2) and (k)(3).
We are not aware of any voluntary consensus standards that could
serve as an alternative for the purposes we describe in further detail
throughout this proposed rule, including for establishing a baseline
set of data that can be commonly exchanged across care settings for a
wide range of uses. We refer readers to section III.B.1 of this
preamble for a discussion of the USCDI.
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 implementation
specifications in any subsequent 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 implementation specification includes
the entire document unless we specify otherwise. For example, if we
adopted the SMART Application Launch Framework Implementation Guide
Release 2.2 (SMART v2.2) proposed in this proposed rule (see section
III.B.2), 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 supersede 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(a)). To comply with these
requirements, in section VI (``Incorporation by Reference'') of this
preamble, we provide summaries of, and uniform resource locators (URLs)
to, the standards and implementation specifications we propose to adopt
and subsequently incorporate by reference in the Code of Federal
Regulations. To note, we also provide relevant information about these
standards and implementation specifications throughout the relevant
sections of the proposed rule.
B. New and Revised Standards and Certification Criteria
1. The United States Core Data for Interoperability Version 4 (USCDI
v4)
a. Background and USCDI v4 Update
The United States Core Data for Interoperability (USCDI) is a
standardized set of health data classes and data elements for the
sharing of electronic health information.\25\ We established USCDI as a
standard in the ONC Cures Act Final Rule (85 FR 25670), adopting USCDI
Version 1 (USCDI v1) in Sec. 170.213 and incorporating it by reference
in Sec. 170.299.\26\ In a final rule titled ``Health Data, Technology,
and Interoperability: Certification Program Updates, Algorithm
Transparency, and Information Sharing'' (HTI-1 Final Rule) and
published on January 9, 2024, we adopted USCDI Version 3 (USCDI v3) in
Sec. 170.213 and incorporated it by reference in Sec. 170.299 (89 FR
1210 through 1223).
---------------------------------------------------------------------------
\25\ <a href="https://www.healthit.gov/isa/united-states-core-data-interoperability-uscdi">https://www.healthit.gov/isa/united-states-core-data-interoperability-uscdi</a>.
\26\ <a href="https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-D/part-170#p-170.213">https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-D/part-170#p-170.213</a>.
---------------------------------------------------------------------------
The USCDI standard in Sec. 170.213 is a baseline set of data that
can be commonly exchanged across care settings for a wide range of
uses. Certain certification criteria in Sec. 170.315 currently require
the use of one of the versions of the USCDI standard in Sec. 170.213.
USCDI is also referenced by HHS programs and used by the healthcare
community to align interoperability requirements and national
priorities for health IT across industry initiatives. For the overall
structure and organization of USCDI, including data classes and data
elements, please see <a href="http://www.healthIT.gov/USCDI">www.healthIT.gov/USCDI</a>.
As described in the ONC Cures Act Final Rule, we use a predictable,
transparent, and collaborative process to expand the USCDI standard,
including providing the opportunity for public comment (85 FR 25670).
Additionally, as described in the ONC Cures Act Final Rule, health IT
developers can use the Standards Version Advancement Process (SVAP) to
voluntarily implement and use the most recent National Coordinator-
approved version of USCDI without waiting for ONC to require that newer
version via rulemaking (85 FR 25669). ONC uses a public comment process
to identify newer versions of standards for approval by the National
Coordinator as part of SVAP.\27\ USCDI v3 was available for voluntary
implementation through SVAP as of September 2023.
---------------------------------------------------------------------------
\27\ <a href="https://www.healthit.gov/isa/standards-version-advancement-process">https://www.healthit.gov/isa/standards-version-advancement-process</a>.
---------------------------------------------------------------------------
Based on feedback ONC received through the ONC New Data Element and
Class submission system, ONC identified a set of data elements and data
classes for a draft version of USCDI v4, which was released in January
2023. The draft version of USCDI v4 included 20 new data elements and
one new data class as well as updates to minimum standard code set
versions. ONC then finalized and released USCDI v4 in July 2023.
We propose to update the USCDI standard in Sec. 170.213 by adding
USCDI v4. We propose that for purposes of the Program, the adoption of
USCDI v3 expires on January 1, 2028. We propose to add USCDI v4 in
Sec. 170.213(c) and incorporate it by reference in Sec. 170.299. We
propose that as of January 1, 2028, any Health IT Modules seeking
certification to criteria referencing Sec. 170.213 would need to be
capable of exchanging the data elements that the USCDI v4 comprises.
The additional data elements in USCDI v4 reflect many of the
recommendations expressed by the Health IT Advisory Committee in their
report to the National Coordinator.\28\ As finalized in the HTI-1 Final
Rule, beginning on January 1, 2026, only USCDI v3 will be available in
Sec. 170.213 as the USCDI standard for use by developers of certified
health IT (89 FR 1215). This proposed rule would advance the USCDI
standard to USCDI v4, continuing ONC's commitment to a transparent and
predictable schedule for health IT developers with respect to updates
to the USCDI's regulatory baseline. If finalized, this proposal would
provide significant clarity and certainty to health IT developers who
would have substantial time to update certified health IT to support
USCDI v4.
---------------------------------------------------------------------------
\28\ <a href="https://www.healthit.gov/sites/default/files/page/2023-05/2023-04-12_IS_WG_USCDI_v4_Transmittal_Letter_508.pdf">https://www.healthit.gov/sites/default/files/page/2023-05/2023-04-12_IS_WG_USCDI_v4_Transmittal_Letter_508.pdf</a>.
---------------------------------------------------------------------------
For certification to a criterion in Sec. 170.315 that references
the USCDI standard adopted in Sec. 170.213, we propose that a Health
IT Module must use at least one of the versions of the USCDI standard
that is (1) adopted in Sec. 170.213 or approved by SVAP at the time
the Health IT Module seeks certification and (2) not expired at the
time of use. When a Health IT Module certified to a criterion in Sec.
170.315 that references the USCDI standard adopted in Sec. 170.213 is
using a version with an
[[Page 63516]]
upcoming expiration date or is using an interim version approved by
SVAP, we propose that the health IT developer must update the Module to
either a new version of the standard adopted in Sec. 170.213 or a
subsequent version approved by SVAP prior to the expiration date or
dates defined in order to maintain certification of that Health IT
Module as described in Sec. 170.315. Consistent with the health IT
developer must provide the updated Health IT Module to their customers
by the expiration date or dates defined in order to maintain
certification of that Health IT Module as described in Sec. 170.315.
We describe these proposals further in section III.B.1.b below.
b. Certification Criteria That Reference USCDI
The USCDI standard is currently cross-referenced in certain
certification criteria (see Sec. 170.213). A Health IT Module can be
certified to any of these criteria by ensuring that it complies with
any unexpired version of the USCDI included in Sec. 170.213 or a
version of the USCDI standard that is approved through SVAP at the time
the Health IT Module seeks certification. The certification criteria
that currently cross-reference to USCDI via Sec. 170.213 are as
follows:
<bullet> ``Care coordination--Transitions of care--Create'' (Sec.
170.315(b)(1)(iii)(A)(1) and (2));
<bullet> ``Care coordination--Clinical information reconciliation
and incorporation--Reconciliation'' (Sec. 170.315(b)(2)(iii)(D)(1)-
(3));
<bullet> ``Decision support interventions--Decision support
configuration'' (Sec. 170.315(b)(11)(ii)(A) and (B), and (iv)(A)(5)-
(13)));
<bullet> ``Patient engagement--View, download, and transmit to 3rd
party--View'' (Sec. 170.315(e)(1)(i)(A)(1) and (2), and (iii));
<bullet> ``Transmission to public health agencies--electronic case
reporting'' (Sec. 170.315(f)(5)(i)(C)(2)(i));
<bullet> ``Design and performance--Consolidated CDA creation
performance'' (Sec. 170.315(g)(6)(i)(A) and (B));
<bullet> ``Design and performance--Application access--all data
request--Functional requirements'' (Sec. 170.315(g)(9)(i)(A)(1) and
(2)); and
<bullet> ``Design and performance--Standardized API for patient and
population services--Data response'' (Sec. 170.315(g)(10)(i)(A) and
(B)).
We propose that up to and including December 31, 2027, a Health IT
Module certified to criteria referencing Sec. 170.213 may use either
USCDI v3 or USCDI v4. We propose that by January 1, 2028, a health IT
developer of a Health IT Module certified to criteria referencing Sec.
170.213 must update to USCDI v4 and provide the updated version to
their customers in order to maintain certification of that Health IT
Module. We also note that if these proposals are finalized, for any
time before January 1, 2026, USCDI v1 could still be used to meet the
applicable certification criteria as well (see 89 FR 1211 through
1223).
Further, we propose that Health IT Modules certified to
certification criteria that reference Sec. 170.213 would need to
update their Health IT Modules to accommodate USCDI v4 data elements
using the FHIR[supreg] US Core Implementation Guide Version 7.0.0
proposed in Sec. 170.215(b)(1)(iii) and the HL7 CDA R2 Implementation
Guide: Consolidated CDA Templates for Clinical Notes, Edition 3--US
Realm, proposed in Sec. 170.205(a)(1). We also propose that adoption
of the standards in Sec. 170.205(a)(6) and Sec. 170.215(b)(1)(ii)
expire on January 1, 2028. As stated in the HTI-1 Final Rule, our
intent would be to adopt the version of these standards necessary for
developers of certified health IT to have appropriate implementation
guidance to meet the certification criteria that reference USCDI v4,
and these updated implementation guides best align with and support
effective implementation of USCDI v4. Based on public comments on HTI-1
and prior rulemakings, we believe that the health IT industry,
healthcare standards developers, and health care providers expect and
support ONC making such determinations so that the adopted version of
standards are the most up-to-date available and are feasible for real-
world implementation (see 89 FR 1215).
2. SMART App Launch 2.2
In the ONC HTI-1 Final Rule, we adopted the HL7[supreg]
FHIR[supreg] SMART Application Launch Framework Implementation Guide
Release 2.0.0 (SMART v2 Guide), a profile of the OAuth 2.0
specification, in Sec. 170.215(c)(2) (89 FR 1291 through 1295). Public
comments received during the HTI-1 rulemaking process indicated near
universal support for the adoption of the SMART v2 Guide, with the
caveat that several of these commenters suggested we adopt the newest
balloted version of the SMART App Launch IG, which at the time of the
HTI-1 public comment period was version 2.1. We declined to adopt the
newest balloted version of the SMART App Launch IG in the HTI-1 Final
Rule, noting that the SMART v2 Guide had ``already been an established
part of the Program via SVAP and rigorously tested . . .'' (89 FR
1292). However, we also noted that ``[w]e will consider potential ways
the SMART v2.1 IG could be included in the Program in the future . .
.'' (89 FR 1292).
We note that current ONC policy as established in the ONC Cures Act
Final Rule (85 FR 25741) and reiterated in the HTI-1 Final Rule (89 FR
1293) is that as part of supporting the SMART App Launch ``permission-
patient'' capability, 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.
Furthermore, we finalized in the HTI-1 Final Rule (89 FR 1294) that as
part of supporting the SMART App Launch ``permission-v2'' capability
Health IT Modules must support certain sub-resource scopes for the
Condition and Observation resources. Specifically, we established
minimal conformance requirements at the category level for the
Condition and Observation resources using specifications and guidance
from the SMART v2 Guide and FHIR US Core 6.1.0 implementation guides to
ensure that Health IT Modules required to support the SMART v2 Guide
are capable of supporting the finer-grained resource constraints
capability without being overly prescriptive in setting expectations
for how the Health IT Module implements such capabilities.
In this proposed rule, we clarify the existing Program requirements
to support patient authorization using SMART App Launch capabilities.
Specifically, we clarify that if both the ``permission-patient'' and
``permission-v2'' capabilities are required in support of patient
authorization for certification to a criterion in the Program, then a
Health IT Module must support the following:
<bullet> Support for the ability for patients to authorize an
application to receive their EHI based on individual FHIR resource-
level and individual sub-resource-level scopes.
<bullet> Support for the ability for patients to authorize an
application to receive their EHI based on individual sub-resource-level
scopes when corresponding resource-level scopes are requested.
These requirements enable patients to have the ability to authorize
access to their EHI at a more granular level in alignment with required
SMART App Launch authorization capabilities. The capabilities enabled
by these requirements empower patients with authorization ability at
the individual sub-resource level, and the ability to provide granular
authorization at the
[[Page 63517]]
individual sub-resource level even if the authorization request from
the app is made at the resource level. We note that both the
``permission-patient'' and ``permission-v2'' capabilities are required
as part of the ``Permissions'' subsection of the SMART App Launch IGs
proposed in Sec. 170.215(c)(2) and Sec. 170.215(c)(3). We propose
``Permissions'' in Sec. 170.315(j)(9), which is cross-referenced in
Sec. 170.315(g)(10) and Sec. 170.315(g)(30) in this proposed rule. We
anticipate that future certification criteria will also include
``permission-patient'' and ``permission-v2'' support requirements to
support of patient authorization and we intend for this clarification
to support patient authorization of individual sub-resource level
scopes to also apply.
Specific guidance and requirements regarding the implementation of
resource and sub-resource scopes are included in the US Core 7.0.0
implementation guide. We clarify for the purposes of certification
under the Program, support for the US Core IG includes supporting all
SMART App Launch scope requirements included in the US Core IG,
including requirements to support resource and sub-resource scopes.
We note throughout this rule we propose revisions to existing API
certification criteria and propose new API certification criteria
wherein specificity in the requirements regarding the properties of
applications is important. To provide a consistent and industry
standard definition of app types referenced in Program API
certification criteria, we clarify that ``confidential app,'' ``public
app,'' and ``native app'' as referenced in this rule and in Program API
requirements refers to ``confidential client,'' ``public client,'' and
``native application'' respectively as defined in internet Engineering
Task Force (IETF) Request for Comments (RFC) 6749 ``The OAuth 2.0
Authorization Framework.'' \29\
---------------------------------------------------------------------------
\29\ IETF RFC 6749 ``The OAuth 2.0 Authorization Framework''
available here: <a href="https://datatracker.ietf.org/doc/rfc6749/">https://datatracker.ietf.org/doc/rfc6749/</a>.
---------------------------------------------------------------------------
The SMART Application Launch Framework Implementation Guide,
Release 2.2 (SMART v2.2 Guide), published at the end of April 2024, is
the most recent version available at the time of this proposed rule.
The SMART v2.2 Guide includes features that iterate on the features of
the SMART v2 Guide, including the enhancements from the SMART v2.1
Guide and the latest industry consensus updates.
Notable enhancements in the SMART v2.2 Guide include a more
detailed and standardized ``fhirContext'' parameter, including the
ability for servers to include optional ``roles'' for offering a
detailed description of included resource references in the
``fhirContext'' parameter; updates to the ``fhirUser'' context
parameter to allow the use of the ``PractitionerRole'' resource for
representing the current user authorizing the launch; and clarification
regarding the ``exp'' field in the token introspection response,
ensuring consistency between the ``exp'' field in the token
introspection response and the ``expires_in'' interval in the original
access token response. Additionally, to eliminate ambiguity in URL
resolution, the SMART v2.2 Guide mandates the use of absolute URLs in
the Well-Known configuration file, disallowing relative URLs. The SMART
v2.2 Guide also introduces a new Cross-Origin Resource Sharing (CORS)
security requirement applicable to servers supporting purely browser-
based apps. Finally, an important new addition to the SMART v2.2 Guide
is the User-Access Brands and Endpoints (Brands) specification, which
allows API providers to publish Brands associated with their FHIR
Endpoints to enable apps to collect and present these Brands to users
(e.g., patients).
Overall, these enhancements to the SMART v2.2 Guide improve
standardization and provide clarity to help support consistent
implementation and improve interoperability. We welcome comment on our
assessment of these SMART v2.2 Guide changes.
Based on HTI-1 public comment feedback and to make use of the new
Brands specification in the Program, we propose to adopt the SMART v2.2
Guide in Sec. 170.215(c)(3) and incorporate it by reference as a
subparagraph in Sec. 170.299. Additionally, we propose that the
adoption of the SMART v2 Guide in Sec. 170.215(c)(2) would expire on
January 1, 2028. If we finalize these proposals, developers of
certified health IT with Health IT Modules certified to criteria
referencing the implementation specifications in Sec. 170.215(c) may
use the SMART v1, SMART v2, or SMART v2.2 Guides for the time period up
to and including December 31, 2025. Then by January 1, 2026, when the
adoption of SMART v1 expires, developers of certified health IT with
Health IT Modules certified to criteria referencing the implementation
specifications in Sec. 170.215(c) must update to the SMART v2 or SMART
v2.2 Guides and provide the updated version to their customers in order
to maintain certification of that Health IT Module. Finally, by January
1, 2028, when the adoption of the SMART v2 Guide expires, developers of
certified health IT with Health IT Modules certified to criteria
referencing the implementation specifications in Sec. 170.215(c) must
update to the SMART v2.2 Guide and provide the updated health IT module
to their customers in order to maintain certification of that Health IT
Module. We propose that any Health IT Modules seeking certification to
criteria referencing the implementation specifications in Sec.
170.215(c) on or after January 1, 2028, would need to be capable of
supporting the SMART v2.2 Guide.
Our proposal to require health IT developers participating in the
program to update and provide to customers Health IT Modules updated to
according to the timelines for the implementation specifications in
Sec. 170.215(c) includes all certification criteria that reference the
implementation specifications in Sec. 170.215(c) directly, or via
reference to our proposed modular API capabilities certification
criteria in Sec. 170.315(j)(6), (j)(7), (j)(8), (j)(9), and (j)(10)
that also reference the implementation specifications in Sec.
170.215(c). In this proposed rule these certification criteria are:
Sec. 170.315(g)(10), (g)(20), (g)(30), (g)(32), (g)(33), (g)(34), and
(g)(35). We note that Sec. 170.315(g)(20), (g)(30), (g)(32), (g)(33),
(g)(34), and (g)(35) are new Program certification criteria proposed in
this rule and the only currently finalized certification criterion in
the Program that includes a reference to Sec. 170.215(c) is Sec.
170.315(g)(10).
To reference the SMART Guide across these proposed new and revised
certification criteria, we propose to move the SMART Guide component
references (e.g., specific capabilities and sections) out of the
subparagraphs in Sec. 170.215(c), so that only entire SMART Guide
references are listed under Sec. 170.215(c). This will enable the
SMART Guides to be referenced across Program certification criteria,
whilst also enabling references to specific SMART Guide components
tailored to the requirements of a specific certification criterion. For
example, the proposed Sec. 170.315(j)(9) certification criterion as
proposed in the section titled ``New Certification Criteria for Modular
API Capabilities'' would reference Sec. 170.215(c) along with a list
of applicable SMART Guide components tailored specifically to describe
SMART Guide requirements for patient authorization for standalone apps.
We note that later versions of the SMART Guide may be finalized by
the time of our final rule. During the time between our proposed rule
and our final rule, the FHIR community may, for example, issue
technical corrections in a SMART v2.2.x Guide or release a
[[Page 63518]]
newer SMART v2.x Guide minor release. We intend to evaluate and
potentially adopt in the final rule the most recent available version
of the SMART Guide that aligns with the SMART v2.2 Guide changes
outlined in this proposed rule. We encourage interested parties to
monitor the SMART App Launch IG directory of published versions
(<a href="https://hl7.org/fhir/smart-app-launch/history.html">https://hl7.org/fhir/smart-app-launch/history.html</a>) for all IG
iterations, technical corrections, and releases. We welcome comment on
this proposal.
3. User-Access Brands and Endpoints
In the ONC HTI-1 Final Rule, we finalized requirements in Sec.
170.404(b)(2) for Certified API Developers to publish certain service
base URLs and related organization (i.e., API Information Source)
details in a standardized FHIR[supreg] format (89 FR 1285 through
1290). Public comments received during the HTI-1 rulemaking process
indicated strong support for the ``continued development and
standardization of publication formats for FHIR `service base URLs' ''
(89 FR 1286). Many of these commenters suggested we adopt a FHIR
implementation guide, with a particular emphasis on the Patient-access
Brands (PAB) specification. We declined to adopt PAB or any other FHIR
implementation guides for Sec. 170.404(b)(2) at the time, and instead
finalized more generalized base FHIR requirements to best ensure
compatibility with the emerging industry FHIR implementation guides.
Given the particular interest in the PAB specification we noted in HTI-
1 that ``[w]e will consider the Patient-access Brands specification for
adoption in future rulemaking as it develops'' (89 FR 1288).
Currently, the PAB specification, now referred to as ``User-access
Brands and Endpoints,'' (and referred to as Brands herein) is set for
publication as a sub-specification in the SMART v2.2 Guide. The Brands
specification ``defines FHIR profiles for Endpoint, Organization and
Bundle resources that help users connect their apps to health data
providers.'' \30\ It provides guidelines for API providers to publish
Brands associated with their FHIR endpoints that apps can collect and
present to users. Each Brand can include information like organization
name, location, identifiers, patient portal details, FHIR API
Endpoints, and more. These Brands are assembled in FHIR ``Bundle''
format, and these Bundles can made available in two ways: by FHIR
servers including a link in their SMART ``.well-known/smart-
configuration'' \31\ metadata file, or through vendor-consolidated
Brand Bundles that are openly published.
---------------------------------------------------------------------------
\30\ <a href="https://hl7.org/fhir/smart-app-launch/STU2.2/brands.html">https://hl7.org/fhir/smart-app-launch/STU2.2/brands.html</a>.
\31\ <a href="https://hl7.org/fhir/smart-app-launch/STU2.2/brands.html#metadata-in-well-knownsmart-configuration">https://hl7.org/fhir/smart-app-launch/STU2.2/brands.html#metadata-in-well-knownsmart-configuration</a>.
---------------------------------------------------------------------------
We propose to update our current maintenance of certification (MoC)
requirements in Sec. 170.404(b)(2) that reference FHIR resources and
elements directly and adopt Brands in Sec. 170.404(b)(2)(iii) as a
replacement. Specifically, we propose to reorganize the regulation text
paragraphs in a way that places existing service base URL requirements
into Sec. 170.404(b)(2)(ii) that expire on December 31, 2027. We
propose in our updated Sec. 170.404(b)(2)(iii) to require that, by
January 1, 2028, service base URLs and related API Information Source
details, including each organization's name, location, and facility
identifier, must be published in an aggregate vendor-consolidated
``FHIR Bundle'' according to the Brands specification. Additionally, we
propose to move our existing publication terms and quarterly review and
update requirements, that we have currently finalized in Sec.
170.404(b)(2) and (b)(2)(iii)(B), to subparagraphs under Sec.
170.404(b)(2)(i) that apply broadly to other sub-paragraphs under Sec.
170.404(b)(2), including our new proposed Brands requirements in Sec.
170.404(b)(2)(iii). Finally, we propose that a health IT developer may
meet the proposed revised MoC requirements by satisfying the new
conformance requirements proposed in Sec. 170.404(b)(2)(i), (iii), and
(iv) in lieu of Sec. 170.404(b)(2)(i) and (ii) prior to December 31,
2027.
We believe that our proposed changes to Sec. 170.404(b)(2)
logically build on our existing MoC requirements in Sec. 170.404(b)(2)
because the Brands specification uses profiles of the same base FHIR
resources (i.e., ``Endpoint,'' ``Organization,'' and ``Bundle'') we
have finalized in Sec. 170.404(b)(2). Requiring the use of the more
standardized FHIR profiles in Brands that are designed specifically for
the endpoint publication use case reduces inconsistent and varied
implementations leading to increased interoperability. We also believe
that our proposed changes to Sec. 170.404(b)(2) align with much of the
public feedback we received during the HTI-1 rulemaking process where
the Brands precursor PAB specification was cited numerous times (89 FR
1286 through 1289). We welcome comment on this proposal to reference
Brands for publication of service base URLs and related organization
details in Sec. 170.404(b)(2).
Additionally, in our revised Sec. 170.404(b)(3) where we propose
new requirements for the publication of API discovery details for payer
network information, including service base URLs and API Information
source details, we propose to adopt Brands specification. Please see
section III.B.20.d for further details on proposed Sec. 170.404
updates.
We note that the Brands specification is a sub-specification in the
SMART v2.2 Guide and we anticipate that subsequent versions of Brands
will be included in subsequent versions of the SMART Guide. We also
note that our proposed January 1, 2028 date for the SMART v2.2 Guide to
be the minimum version in Sec. 170.215(c) (see section III.B.2 for our
proposal to adopt the SMART v.2.2 Guide in Sec. 170.215(c)) matches
the date that health IT developers subject to the requirements in Sec.
170.404(b)(2) must support Brands for publication of API discovery
details for patient access.
As we noted in section III.B.2, later versions of the SMART Guide
may be finalized by the time of our final rule. This includes changes
to the Brands specification, or potential corrections if identified,
and we intend to evaluate and potentially adopt in the final rule the
most recent available version of the SMART Guide if doing so would best
support interoperability and effective program implementation. We
encourage interested parties to monitor the SMART App Launch IG
directory of published versions (<a href="https://hl7.org/fhir/smart-app-launch/history.html">https://hl7.org/fhir/smart-app-launch/history.html</a>) for all IG iterations, technical corrections, and
releases. We welcome comment on this proposal.
4. Standards for Encryption and Decryption of Electronic Health
Information
a. Background
In the 2015 Edition Final Rule, ONC adopted the October 8, 2014,
version of Annex A: Approved Security Functions for Federal Information
Processing Standards (FIPS) Publication 140-2. This October 8, 2014,
version was the most recent version published by the National Institute
of Standards and Technology (NIST) when the 2015 Edition Final Rule
published (80 FR 62707).
b. Proposal
Since finalizing the October 8, 2014, version of Annex A: Approved
Security Functions for FIPS Publication 140-2 standard in the 2015
Edition Final Rule,
[[Page 63519]]
encryption techniques and security best practices have continued to
advance, and NIST has published several updated versions of Annex A:
Approved Security Functions for FIPS Publication 140-2.\32\ The most
recent version of Annex A for FIPS Publication 140-2 is Draft, October
12, 2021. We propose to adopt the Draft, October 12, 2021, version of
Annex A for FIPS Publication 140-2 in Sec. 170.210(a)(3) and
incorporate it by reference as a subparagraph in Sec. 170.299. We also
propose that the adoption of the FIPS 140-2 October 8, 2014, version in
Sec. 170.210(a)(2) expire on January 1, 2026. We note that the FIPS
140-2 October 8, 2014, version was inadvertently removed from Sec.
170.299, therefore we propose to incorporate by reference the standard
in Sec. 170.299(m)(3). We welcome comment on these proposals.
---------------------------------------------------------------------------
\32\ See pages 4-6 of the October 12, 2021 version of Annex A
for a revision history of the standard. Available at: <a href="https://csrc.nist.gov/csrc/media/publications/fips/140/2/final/documents/fips1402annexa.pdf">https://csrc.nist.gov/csrc/media/publications/fips/140/2/final/documents/fips1402annexa.pdf</a>.
---------------------------------------------------------------------------
We note that revising Sec. 170.210(a) would implicate three
certification criteria that reference standards in Sec. 170.210(a):
<bullet> Sec. 170.315(d)(7) End-user device encryption, which we
propose to revise and rename as ``Health IT encryption'' elsewhere in
this preamble;
<bullet> Sec. 170.315(d)(9) Trusted connection; and
<bullet> Sec. 170.315(d)(12) Encrypt authentication credentials,
which we propose to further revise and rename as ``Protect stored
authentication credentials'' elsewhere in this preamble.
Given the cross reference to Sec. 170.210(a)(2) in these
certification criteria, we propose to revise each certification
criterion in Sec. 170.315(d)(7), (d)(9), and (d)(12) to replace
``standard'' with ``at least one version of the standard'' and ``Sec.
170.210(a)(2)'' with ``Sec. 170.210(a)'' where appropriate in each
certification criterion. At revised Sec. 170.315(d)(7)(iv) we propose
to revise both ``standard'' and ``Sec. 170.210(a)(2)'' in this manner.
In Sec. 170.315(d)(9)(i) and (ii); and at revised Sec.
170.315(d)(12)(i)(A), we also propose to revise ``standard'' and
``Sec. 170.210(a)(2)'' in this manner. As noted, we describe our
remaining proposed revisions to Sec. 170.315(d)(7) and Sec.
170.315(d)(12) elsewhere in this preamble at III.B.11 and III.B.12 and
we invite readers to review those sections.
Additionally, we propose to remove the standard found in Sec.
170.210(f) that is no longer referenced in any active certification
criteria. We welcome comments on our proposals.
Finally, we solicit comment on the transition to the next FIPS
standard, FIPS 140-3, that is currently underway.\33\ We are monitoring
development in this area, and we welcome comment on FIPS 140-3 and any
potential impacts to our Program requirements. We note that Annex A for
FIPS 140-2 is compatible with current FIPS 140-3 guidance as an
``Approved Security Function,'' and we intend to re-evaluate the latest
FIPS 140-3 guidance at the time of the final rule to ensure continued
capability with FIPS 140-3.\34\ We recognize the potential for changes
in FIPS 140-2 and 140-3 by the time of our final rule. Therefore, we
intend to consider and potentially finalize the most recent Approved
Security Functions that align with current FIPS guidance at the time
and that are compatible with the Annex A for FIPS 140-2 update we are
proposing in this proposed rule. We welcome comment on this proposal.
---------------------------------------------------------------------------
\33\ See FIPS 140-3 Transition Effort page--<a href="https://csrc.nist.gov/projects/fips-140-3-transition-effort">https://csrc.nist.gov/projects/fips-140-3-transition-effort</a>.
\34\ The ``10. Approved Security Functions'' requirements in
FIPS 140-3 (March 22, 2019 version) state that ``Approved security
functions include those that are . . . adopted in a FIPS and
specified either in an appendix to the FIPS or in a document
referenced by the FIPS.'' The October 12, 2021 draft version of
Annex A for FIPS 140-2 meets that criterion to contain ``Approved
Security Functions'' according to FIPS 140-3. See <a href="https://csrc.nist.gov/pubs/fips/140-3/final">https://csrc.nist.gov/pubs/fips/140-3/final</a>.
---------------------------------------------------------------------------
5. Minimum Standards Code Sets Updates
We established a policy in the 2015 Edition Final Rule for minimum
standards code sets that update frequently (80 FR 62612). In the final
rule entitled ``Health Information Technology: Standards,
Implementation Specifications, and Certification Criteria for
Electronic Health Record Technology, 2014 Edition; Revisions to the
Permanent Certification Program for Health Information Technology'' (77
FR 54163) we discussed the benefits of adopting newer versions of
minimum standards code sets, including the improved interoperability
and implementation of health IT with minimal additional burden (77 FR
54170). As we stated in the HTI-1 Final Rule, when determining whether
to propose newer versions of minimum standards code sets, we consider
the impact on interoperability and whether a newer version would
require substantive effort for developers of certified health IT to
implement (89 FR 1224). If adopted, newer versions of minimum standards
code sets would serve as the baseline for certification and developers
of certified health IT would be able to use newer versions of these
adopted standards on a voluntary basis. We reiterate that while minimum
standard code sets update frequently, perhaps several times in a single
year, these updates are confined to concepts within the code system,
not substantive changes to the standards themselves.
For certification to a criterion in Sec. 170.315 that references
the standard adopted in Sec. 170.207, we propose that a Health IT
Module must use at least one of the versions of the standard that is
(1) adopted in Sec. 170.207 or approved by SVAP at the time the Health
IT Module seeks certification and (2) not expired at the time of use.
We also propose that when a Health IT Module certified to a criterion
in Sec. 170.315 that references the standard adopted in Sec. 170.207
is using a version with an upcoming expiration date or is using an
interim version approved by SVAP, the health IT developer must update
the Module to either a new version of the standard adopted in Sec.
170.207, or a subsequent version approved by SVAP, prior to the
expiration date or dates defined in order to maintain certification of
that Health IT Module as described in Sec. 170.207. In addition, the
health IT developer must provide the updated Health IT Module to their
customers by the expiration date or dates defined in Sec. 170.207 in
order to maintain certification of that Health IT Module as described
in Sec. 170.315.
<bullet> Sec. 170.207(a)--Problems
We propose to revise Sec. 170.207(a)(2), which is currently
reserved, to reference SNOMED CT[supreg], U.S. Edition, September 2023
Release and incorporate it by reference in Sec. 170.299. We also
propose that the adoption of the standard in Sec. 170.207(a)(1),
SNOMED CT, U.S. Edition, March 2022 Release, would expire on January 1,
2028, and that the adoption of the standard in Sec. 170.207(a)(4),
IHTSDO SNOMED CT, U.S. Edition, September 2015 Release, would expire on
January 1, 2026.
<bullet> Sec. 170.207(c)--Laboratory tests
We propose to revise Sec. 170.207(c)(2) to reference Logical
Observation Identifiers Names and Codes (LOINC[supreg]) Database
version 2.76, a universal code system for identifying laboratory and
clinical observations produced by the Regenstrief Institute, Inc. and
incorporate it by reference in Sec. 170.299. We also propose that the
adoption of the standard in Sec. 170.207(c)(1), LOINC Database Version
2.72, would expire on January 1, 2028, and that the adoption of the
standard in Sec. 170.207(c)(3), LOINC Database version 2.52, would
expire on January 1, 2026.
<bullet> Sec. 170.207(d)--Medications
We propose to revise the citations in Sec. 170.207(d) to improve
organization of
[[Page 63520]]
this section. Specifically, we propose to revise Sec. 170.207(d)(1) to
list standards for clinical drugs and to reference multiple releases of
RxNorm, a standardized nomenclature for clinical drugs produced by the
United States National Library of Medicine. We propose in Sec.
170.207(d)(1)(ii) to reference RxNorm, December 4, 2023 Full Monthly
Release and incorporate it by reference in Sec. 170.299. We propose to
move the standard adopted in Sec. 170.207(d)(1), RxNorm, July 5, 2022
Release, to Sec. 170.207(d)(1)(i), and that the adoption of this
standard would expire on January 1, 2028. We propose to move the
standard adopted in Sec. 170.207(d)(3), RxNorm, September 8, 2015
Release, to Sec. 170.207(d)(1)(iii) and that the adoption of this
standard would expire on January 1, 2026. Finally, we propose to move
National Drug Codes, currently included via cross-reference in Sec.
170.207(d)(4), to Sec. 170.207(d)(2). We note that Sec. 170.207(d)(2)
is currently reserved. We also propose to reserve Sec. 170.207(d)(3)
and remove Sec. 170.207(d)(4).
<bullet> Sec. 170.207(e)--Immunizations
We propose to reference in Sec. 170.207(e)(5) the CDC National
Center of Immunization and Respiratory Diseases (NCIRD) Code Set
(CVX)--Vaccines Administered, updates through September 29, 2023, and
incorporate it by reference in Sec. 170.299. We also propose to
reference in Sec. 170.207(e)(6) the National Drug Code (NDC)--Vaccine
NDC Linker, updates through November 6, 2023, and incorporate it by
reference in Sec. 170.299. We propose that adoption of the standards
in Sec. 170.207(e)(1), the HL7[supreg] Standard Code Set CVX--Vaccines
Administered, dated through June 15, 2022, and Sec. 170.207 (e)(2),
NDC--Vaccine NDC Linker, dated July 19, 2022, would expire on January
1, 2028. We also propose that adoption of the standards in Sec.
170.207(e)(3), HL7 Standard Code Set CVX--Vaccines Administered,
updates through August 17, 2015, and Sec. 170.207(e)(4), NDC--Vaccine
NDC Linker, updates through August 17, 2015, would expire on January 1,
2026.
<bullet> Sec. 170.207(f)--Race and Ethnicity
We propose to revise Sec. 170.207(f)(1) to include recent updates
to the U.S. Office of Management and Budget's Statistical Policy
Directive No. 15: Standards for Maintaining, Collecting, and Presenting
Federal Data on Race and Ethnicity (SPD 15). In Sec. 170.207(f)(1)(i)
we propose to include The Office of Management and Budget Standards for
Maintaining, Collecting, and Presenting Federal Data on Race and
Ethnicity, Statistical Policy Directive No. 15, as revised, October 30,
1997 with an expiration date of January 1, 2026 for adoption of that
standard. In Sec. 170.207(f)(1)(ii) we propose to include the U.S.
Office of Management and Budget's Statistical Policy Directive No. 15:
Standards for Maintaining, Collecting, and Presenting Federal Data on
Race and Ethnicity (SPD 15), as revised, March 29, 2024.
We propose to revise Sec. 170.207(f)(2) to include CDC Race and
Ethnicity Code Set standards. In Sec. 170.207(f)(2)(i) we propose to
include CDC Race and Ethnicity Code Set Version 1.0 (March 2000) with
an expiration of January 1, 2026, for adoption of that standard. In
Sec. 170.207(f)(2)(ii) we propose to include CDC Race and Ethnicity
Code Set Version 1.2 (July 08, 2021) and incorporate it by reference in
Sec. 170.299. We propose to remove and reserve Sec. 170.207(f)(3).
<bullet> Sec. 170.207(m)--Numerical references
We propose that adoption of the standard in Sec. 170.207(m)(1),
The Unified Code of Units of Measure, Revision 1.9, would expire on
January 1, 2026.
<bullet> Sec. 170.207(n)--Sex
We propose that adoption of the standard in Sec. 170.207(n)(1),
HL7 Version 3 Standard, Value Sets for AdministrativeGender and
NullFlavor, would expire on January 1, 2026. We propose to revise Sec.
170.207(n)(2) to reference use of at least one of the versions of
SNOMED CT U.S. Edition specified in Sec. 170.207(a). We also propose
to revise Sec. 170.207(n)(3) to reference use of at least one of the
versions of LOINC specified in Sec. 170.207(c).
<bullet> Sec. 170.207(o)--Sexual orientation and gender information
We propose to revise Sec. 170.207(o)(1)-(3) to reference use of at
least one of the versions of SNOMED CT U.S. Edition specified in Sec.
170.207(a) instead of Sec. 170.207(a)(4). We also propose to revise
Sec. 170.207(o)(4) to reference use of at least one of the versions of
LOINC specified in Sec. 170.207(c).
<bullet> Sec. 170.207(p)--Social, psychological, and behavioral data
We propose to revise Sec. 170.207(p)(1) through (8) to reference
use of at least one of the versions of LOINC specified in Sec.
170.207(c).
We propose to revise Sec. 170.207(p)(4), (5), (6), (7), and (8) to
reference use of at least one of the versions of the standard specified
in Sec. 170.207(m).
<bullet> Sec. 170.207(r)--Provider type
We propose that adoption of the standard in Sec. 170.207(r)(1)
would expire on January 1, 2026.
<bullet> Sec. 170.207(s)--Patient insurance
We propose that adoption of the standard in Sec. 170.207(s)(1),
Public Health Data Standards Consortium Source of Payment Typology Code
Set Version 5.0 (October 2011), would expire on January 1, 2026.
In addition to updating the minimum standards code sets listed
above, we propose to update the certification criteria that reference
those minimum standards. These certification criteria include
Sec. Sec. 170.315(a)(12), 170.315(b)(1)(iii)(B)(2) and (G)(3),
170.315(c)(4)(iii)(C), (E), (G), (H), and (I), 170.315(f)(1)(i)(B)-(C),
170.315(f)(3)(ii) and (f)(4)(ii).
6. New Imaging Requirements for Health IT Modules
Diagnostic images are critical to supporting care in a variety of
healthcare settings. Clinicians routinely use diagnostic images to
support patient care and patients can better facilitate and coordinate
care when they have access to their own images. Diagnostic images are
often stored in systems external to an EHR, such as picture archiving
and communication systems (PACS), vendor neutral archives (VNA), or
other imaging platforms. While radiologists, ophthalmologists,
dermatologists, pathologists, and other imaging specialists generally
have direct access to full diagnostic quality images on these systems,
access to both diagnostic quality and lesser quality images for
referring providers can be inconsistent, depending on how broadly the
hospitals or provider practice deploys access to their imaging
infrastructure.
While certain images may be exchanged electronically in an
automated manner, patients are often provided their diagnostic quality
images on physical media (e.g., compact disc read-only memory (CD-ROM))
to physically transport to their next clinical visit. Some PACS and VNA
systems provide access to images through a web-based viewer, but those
web-based viewers are often not accessible outside of the hospital or
practice's immediate network.
In the Health Information Technology: Standards, Implementation
Specifications, and Certification Criteria for Electronic Health Record
Technology, 2014 Edition; Revisions to the Permanent Certification
Program for Health Information Technology (2014 Edition Final Rule),
ONC adopted an ``Image Results'' certification criterion to
[[Page 63521]]
support the CMS EHR Incentive Program requirement, also known as the
Meaningful Use or ``MU Stage 2 Objective'' requirement, that required
eligible clinicians, eligible hospitals, and critical access hospitals
to have access to imaging results and information through Certified EHR
Technology (77 FR 54172).\35\ The certification criterion required a
Health IT Module to indicate the availability of a patient's images and
narrative interpretations and enable access to those images and
narrative interpretations. ONC stated that the requirements of this
certification criterion could be met via the capability to directly
link to images stored in the EHR system or providing a context-
sensitive link to an external application which provides access to
images and their associated narrative. We also stated in the 2014
Edition Final Rule that the use of the Digital Imaging and
Communications in Medicine (DICOM) standard (or any other imaging
standards) was unnecessary to meet the functional requirement expressed
in the imaging results certification criterion (77 FR 54173). Instead,
we reiterated our understanding stated in the 2014 Edition Proposed
Rule that the adoption of standards was unnecessary to enable users to
electronically access images and their narrative interpretations, as
required by this certification criterion (77 FR 13838).
---------------------------------------------------------------------------
\35\ For more discussion regarding ONC's support of the CMS EHR
Incentive Program, Stage 2 Meaningful Use, please see: <a href="https://www.cms.gov/newsroom/fact-sheets/cms-proposes-definition-stage-2-meaningful-use-certified-electronic-health-records-ehr-technology">https://www.cms.gov/newsroom/fact-sheets/cms-proposes-definition-stage-2-meaningful-use-certified-electronic-health-records-ehr-technology</a>.
---------------------------------------------------------------------------
In the 2015 Edition Proposed Rule, ONC proposed to maintain the
``Imaging Results'' certification criterion (80 FR 16822) and while
some commenters supported this proposal, ONC ultimately removed the
``Imaging Results'' certification criterion in the 2015 Edition Final
Rule because the associated CMS EHR Incentive Programs objective (now
referred to as Promoting Interoperability objectives) was removed and
no longer required technological support (80 FR 62683). Instead, we
finalized a certification criterion related to imaging in Sec.
170.315(a)(3) ``Computerized provider order entry--diagnostic
imaging,'' which is currently available for certification in the
Program and requires that a Health IT Module enable a user to record,
change, and access diagnostic imaging orders.
We acknowledge there are certain use cases and circumstances where
image access via physical media may be more appropriate than network
access (e.g., locations without adequate network capabilities).
However, we believe the prevalence of CD-ROMs and other physical media
to share diagnostic quality images across healthcare settings indicates
a lack of interoperability and access to imaging results that
represents a continued burden for patients and clinicians. The
widespread use of CD-ROMs and other physical media to share diagnostic
quality images persists despite the adoption of PACS and VNA systems,
the implementation of web-based viewers for diagnostic imaging, and the
emergence of electronic standards and profiles meant to facilitate
medical image access and exchange. For instance, the DICOM standard
establishes a service-based process for web-based medical imaging,
DICOMweb<SUP>TM</SUP>. The Integrating the Healthcare Enterprise (IHE)
XCPD, XCA, and XCA-I profiles support electronic transactions that can
be used to facilitate medical imaging access. While these standards and
others currently exist, there is not yet a clear consensus or full
adoption of these pathways in health IT.
ONC believes that promoting access to and the exchange of images
via Program requirements may encourage more widespread adoption and
integration of these already existing pathways and reduce burdens
caused by physical media exchange. Therefore, we propose to revise
three certification criteria by adding new provisions to include
support of a link to diagnostic imaging: ``transitions of care'' in
Sec. 170.315(b)(1); ``application access--all data request'' in Sec.
170.315(g)(9); and ``standardized API for patient and population
services'' in Sec. 170.315(g)(10). We describe in subsequent
paragraphs the criterion-specific details of the proposals to require
support for imaging links in the Program. We believe that support for
imaging links in these certification criteria will promote the
availability of electronic image access for patients and providers. To
enable a consistent understanding of ``imaging link'' across
certification criteria requirements in the Program, we propose to
define ``imaging link'' in Sec. 170.102 to be ``technical details
which enable the electronic viewing or retrieval of one or more images
over a network.'' The proposed definition of ``imaging link'' is
intended to be sufficiently broad to include the technical details used
by the protocols and technologies implemented by industry to view and
retrieve images. We also note that there is no specific standard
associated with the support of this link, and that the functionality of
this requirement can be met with a context-sensitive link to an
external application which provides access to images and their
associated narrative. The DICOMweb standard (e.g., DICOM PS3.18 2023d--
Web Services) \36\ is likely to be among the standards widely used by
hospitals and providers to support imaging links, but the Health IT
Module certified to these certification criteria is not required to
support a specific standard. We also clarify that although this
proposal does not include specific security standards, we expect the
appropriate authentication and authorization processes to be supported
to prevent unauthorized access via the imaging links required in this
proposal. For example, health IT developers may consider SMART Health
Links as one possible standard by which to generate secure links to
patient images.
---------------------------------------------------------------------------
\36\ <a href="https://dicom.nema.org/medical/dicom/2023d/">https://dicom.nema.org/medical/dicom/2023d/</a> 2023d/.
---------------------------------------------------------------------------
We propose to revise the Sec. 170.315(b)(1) ``Transitions of
care'' certification criterion to support imaging links by adding
imaging links to the data required to be supported in the ``Create''
functionality in Sec. 170.315(b)(1)(iii) by adding a new paragraph in
Sec. 170.315(b)(1)(iii)(H). The ``Create'' functionality in Sec.
170.315(b)(1)(iii) specifies the requirement to enable a user to create
a transition of care/referral summary formatted in accordance with the
standard specified in Sec. 170.205(a)(3), (4), and (5) using the
Continuity of Care Document, Referral Note, and (inpatient setting
only) Discharge Summary document templates including at a minimum the
data described under Sec. 170.315(b)(1)(iii)(A)--(G). We propose
specifically to add a paragraph in Sec. 170.315(b)(1)(iii)(H) to
indicate on and after January 1, 2028 imaging links are a part of the
minimum ``Create'' requirements in Sec. 170.315(b)(1)(iii).
We propose to revise the Sec. 170.315(g)(9) ``Application access--
all data request'' certification criterion to support imaging links by
adding imaging links to the data required to be supported in responses
to requests for patient data in a summary record formatted according to
the data response requirements at paragraphs in Sec.
170.315(g)(9)(i)(A)(1) and (2). Specifically, we propose to add a
paragraph Sec. 170.315(g)(9)(i)(A)(3)(v) that indicates on and after
January 1, 2028 imaging links are required to be supported as part of
the data response requirements in Sec. 170.315(g)(9)(i)(A)(1) and (2).
We also propose to revise the data response requirements in paragraphs
Sec. 170.315(g)(9)(i)(A)(1) and (2) to reference the data requirements
proposed in Sec. 170.315(g)(9)(i)(A)(3)(v).
[[Page 63522]]
We propose to revise the Sec. 170.315(g)(10) ``Standardized API
for patient and population services'' certification criterion to
support imaging links by adding imaging links to the data required to
be supported for data response for patients and users and for data
response for systems. Specifically, we propose to add imaging links as
data required to be supported on and after January 1, 2028 in data
response for patients and users consistent with FHIR and US Core
requirements at the paragraph proposed in Sec.
170.315(g)(10)(ii)(B)(1). Additionally, we propose to add imaging links
as data required to be supported on and after January 1, 2028 in data
response for systems consistent with FHIR and US Core requirements
proposed in Sec. 170.315(g)(10)(iii)(B)(1), and the Bulk FHIR API data
response for systems in accordance with FHIR, US Core, and Bulk Data
Access, including the ``_type'' query parameter, requirements proposed
in Sec. 170.315(g)(10)(iii)(B)(2) and Sec.
170.315(g)(10)(iii)(B)(2)(ii).
We also propose to revise the ``view, download, and transmit to 3rd
party'' certification criterion in Sec. 170.315(e)(1) to add
functional support for viewing and download of diagnostic quality and
lower quality images as well as inclusion of an imaging link to those
diagnostic images in either a downloaded or transmitted Continuity of
Care Document (CCD). We propose that Health IT Modules support this
functionality on and after January 1, 2028. Specifically, we propose to
add both diagnostic quality images and reduced quality images to the
data that must be supported for viewing by patients (and their
authorized representatives) according to paragraph (e)(1)(i)(A) by
including support for diagnostic quality images and reduced quality
images at the proposed paragraph (e)(1)(i)(A)(8). Furthermore, we
propose to include imaging links in the requirements in Sec.
170.315(e)(1)(i)(B)(2)(i) and (ii) specifying the data required to be
included at a minimum in ambulatory summaries and inpatient summaries
respectively be downloadable in accordance with the requirements
specified at paragraph (e)(1)(i)(B)(2), which details the download
requirements for ambulatory summaries and inpatient summaries
downloaded according to the standard specified in Sec. 170.205(a)(4)
through (6) following the CCD document template. Finally, we propose
that patients (and their authorized representatives) must be able to
use technology to download both diagnostic quality and reduced quality
images at the proposed Sec. 170.315(e)(1)(i)(B)(4). Like broad
requirements proposed in Sec. 170.315(e)(1)(i)(A)(8), we propose that
Health IT Modules certified to Sec. 170.315(e)(1) support these
specific scenarios on and after January 1, 2028. Again, there is no
standard specified for either the images or the imaging links in the
proposed requirements, though we anticipate that DICOM and the DICOMweb
standard (such a--DICOM PS3.18 2023d--Web Services) are likely to be
among standards widely used by hospitals and providers to support
images and imaging links respectively.
We believe it is important to support the ability to view and
download both diagnostic and lower quality images. While it is critical
for patients to have access to diagnostic imaging, lower quality images
are also important and, for example, a patient may decide that it is
useful to have the lower quality images for quick reference. This
revised certification criterion requires that both types of imaging be
supported for viewing and for direct downloading by patients.
The view and download requirements of this certification criterion
could be met via the capability to directly link to images stored in
the Health IT Module or providing a context-sensitive connection to an
external application which provides access to images and their
associated narrative. In either case, however, the view and download
functionalities must be accessible to the patient through the same
internet-based technology as the other functionalities of Sec.
170.315(e)(1). Electronic exchange of the image itself does not need to
be included as part of the Sec. 170.315(e)(1)(C) ``Transmit to third
party'' functionality. However, similar to the proposals for the other
certification criteria discussed above, an imaging link to the images
accessible to the patient must be provided.
We propose that on and after January 1, 2028, a Health IT Module
seeking certification to any of the certification criteria in Sec.
170.315(b)(1), (e)(1), (g)(9), and (10), must meet the proposed
requirements for imaging links. We note that health IT developers are
also required to meet the Assurances Condition of Certification
maintenance requirement in Sec. 170.402(b)(3) that any health IT
developer with a Health IT Module certified to these certification
criteria would need to update their Health IT Modules and provide the
updated version to their customers, including the most recently adopted
capabilities and standards included in the revised certification
criteria order to maintain certification of that Health IT Module. We
welcome comments on these proposals.
7. Revised Clinical Information Reconciliation and Incorporation
Criterion
We propose to revise the ``Clinical information reconciliation and
incorporation'' (CIRI) certification criterion in Sec. 170.315(b)(2).
These proposed revisions are intended to expand our existing CIRI
certification requirements to additional data elements and promote new
capabilities that would benefit providers by reducing the burden of
reconciliation and incorporation in clinical workflows.
Our requirements for CIRI in the Program were first established in
the ``Health Information Technology: Initial Set of Standards,
Implementation Specifications, and Certification Criteria for
Electronic Health Record Technology'' Jan. 13, 2010, interim final rule
to enable a user to electronically compare two or more medication lists
(75 FR 2014). We subsequently expanded these requirements in the 2014
Edition Final Rule to require clinical information reconciliation and
incorporation for three data types: problems, medications, and
medication allergies (77 FR 54222). We noted in the 2010 interim final
rule that there was, ``. . . great promise in making this
[reconciliation] capability more comprehensive'' and that we
``anticipate exploring ways to improve the [reconciliation] utility of
this capability. . .'' (75 FR 44613). In the 2014 Edition Final Rule we
also noted our agreement with public comments that said providers
``should have some control over how exactly they want to be able to
incorporate data into their EHR technology as part of their practice/
organization'' (77 FR 54219).
Building on our CIRI strategy and in response to public feedback,
we propose to revise Sec. 170.315(b)(2) to require Health IT Modules
to support reconciliation and incorporation of all USCDI data elements.
In the context of the CIRI workflow in Sec. 170.315(b)(2), we propose
that upon receipt of a transition of care/referral summary all USCDI
data elements must be supported, at a minimum, for reconciliation and
incorporation by a user in Sec. 170.315(b)(2)(v). We also propose in
Sec. 170.315(b)(2)(vi) user configuration functionality to enable a
user to set individual or organizational rules that allow automatic
reconciliation and incorporation for each data class included in at
least one of the versions of the USCDI standard in Sec. 170.213,
including functionality that allows the
[[Page 63523]]
user to select trusted data and trusted data sources for automatic
reconciliation and incorporation. Finally, as part of our proposed
revision to the CIRI certification criterion in Sec. 170.315(b)(2), we
propose system verification functionality in Sec. 170.315(b)(2)(vii)
that requires Health IT Modules to be able to create a file formatted
according to the Continuity of Care Document template.
We propose to implement this by requiring Health IT Modules
certified to Sec. 170.315(b)(2) to meet the requirements inSec.
170.315(b)(2)(i), (ii), (iii), and (vii), or the requirements in (iv),
(v), (vi) and (vii) for the time period up to and including December
31, 2027. On and after January 1, 2028, we propose that Health IT
Modules certified to Sec. 170.315(b)(2) must meet the requirements in
Sec. 170.315(b)(2)(iv), (v), (vi), and (vii).
Our proposed revised CIRI requirements in Sec. 170.315(b)(2)(iv),
(v), and (vi) include reorganizing and generalizing the CIRI workflow
requirements currently in the certification criterion in Sec.
170.315(b)(2)(i), (ii), and (iii). Specifically, we have generalized
and combined requirements currently in Sec. 170.315(b)(2)(i) and (ii)
in proposed Sec. 170.315(b)(iv) and we have replicated requirements
currently in Sec. 170.315(b)(2)(iii) in proposed Sec. 170.315(b)(v)
under ``user reconciliation,'' with the aforementioned proposal to
reference all data classes and data elements in the USCDI standard in
Sec. 170.213 instead of the currently referenced ``medications,''
``allergies and intolerance,'' and ``problems'' data elements.
Additionally, we propose to move our system verificat
[…truncated; see source link]Indexed from Federal Register on August 5, 2024.
This is legal information, not legal advice. Laws vary by jurisdiction and change frequently. Always verify current law with official sources and consult a licensed attorney in your jurisdiction for advice on your specific situation.