[Federal Register Volume 90, Number 94 (Friday, May 16, 2025)]
[Notices]
[Pages 21034-21041]
From the Federal Register Online via the Government Publishing Office [www.gpo.gov]
[FR Doc No: 2025-08701]
=======================================================================
-----------------------------------------------------------------------
DEPARTMENT OF HEALTH AND HUMAN SERVICES
Centers for Medicare & Medicaid Services
[CMS-0042-NC]
RIN 0938-AV68
Request for Information; Health Technology Ecosystem
AGENCY: Centers for Medicare & Medicaid Services (CMS), Assistant
Secretary for Technology Policy (ASTP)/Office of the National
Coordinator for Health Information Technology (ONC) (collectively,
ASTP/ONC), Department of Health and Human Services (HHS).
ACTION: Request for information.
-----------------------------------------------------------------------
SUMMARY: Effective and responsible adoption of technology can empower
patients to make better decisions for their health and well-being. This
request for information (RFI) seeks input from the public regarding the
market of digital health products for Medicare beneficiaries as well as
the state of data interoperability and broader health technology
infrastructure. Responses to this RFI may be used to inform CMS and
ASTP/ONC efforts to lead infrastructure progress to cultivate this
market, increasing beneficiary access to effective digital capabilities
needed to make informed health decisions, and increasing data
availability for all stakeholders contributing to health outcomes.
DATES: To be assured consideration, comments must be received at one of
the addresses provided below, by June 16, 2025.
ADDRESSES: In commenting, refer to file code CMS-0042-NC.
Comments, including mass comment submissions, must be submitted in
one of the following three ways (please choose only one of the ways
listed):
1. Electronically. You may submit electronic comments on this
regulation to https://www.regulations.gov. Follow the ``Submit a
comment'' instructions.
2. By regular mail. You may mail written comments to the following
address ONLY: Centers for Medicare & Medicaid Services, Department of
Health and Human Services, Attention: CMS-0042-NC, P.O. Box 8013,
Baltimore, MD 21244-8013.
Please allow sufficient time for mailed comments to be received
before the close of the comment period.
3. By express or overnight mail. You may send written comments to
the following address ONLY: Centers for Medicare & Medicaid Services,
Department of Health and Human
[[Page 21035]]
Services, Attention: CMS-0042-NC, Mail Stop C4-26-05, 7500 Security
Boulevard, Baltimore, MD 21244-1850.
For information on viewing public comments, see the beginning of
the SUPPLEMENTARY INFORMATION section.
FOR FURTHER INFORMATION CONTACT: [email protected].
SUPPLEMENTARY INFORMATION:
Inspection of Public Comments: All comments received before the
close of the comment period are available for viewing by the public,
including any personally identifiable or confidential business
information that is included in a comment. We post all comments
received before the close of the comment period on the following
website as soon as possible after they have been received: https://www.regulations.gov. Follow the search instructions on that website to
view public comments. CMS will not post on Regulations.gov public
comments that make threats to individuals or institutions or suggest
that the commenter will take actions to harm an individual. CMS
continues to encourage individuals not to submit duplicative comments.
We will post acceptable comments from multiple unique commenters even
if the content is identical or nearly identical to other comments.
I. Background
The enactment of the 21st Century Cures Act (Pub. L. 114-255) in
2016 authorized the Centers for Medicare & Medicaid Services (CMS), the
Assistant Secretary for Technology Policy/Office of the National
Coordinator for Health Information Technology (ASTP/ONC),\1\ and the
National Institute of Standards and Technology (NIST), to implement
certain policies to enhance the amount of health data available through
digital channels and give patients secure, electronic access to their
personal health information. These policies are the building blocks of
a digital ecosystem in which patients can view, manage, utilize, and
share their health information through digital applications (apps) and
other modern solutions. This digital ecosystem could ultimately expand
access to personalized health guidance for patients to improve
prevention and chronic disease management.
---------------------------------------------------------------------------
\1\ On July 29, 2024, notice was posted in the Federal Register
that ONC would be dually titled to the Assistant Secretary for
Technology Policy and Office of the National Coordinator for Health
Information Technology (89 FR 60903).
---------------------------------------------------------------------------
On January 12, 2017, President Trump issued Executive Order 13813,
``Promoting Healthcare Choice and Competition Across the United
States'' (82 FR 48385), which directed Federal agencies to implement
policies that enhance patient access to healthcare data and empower
individuals to make informed decisions about their care.
In 2018, CMS led payers by example and released Blue Button 2.0,
its own Fast Healthcare Interoperability Resources (FHIR[supreg])-based
Patient Access application programming interface (API) with the goal of
increasing beneficiary access to their data and improving patient
outcomes. This project initiated an ecosystem of patient-facing
applications that allowed beneficiaries to authenticate using their
Medicare.gov credentials and then to authorize applications to receive
their Medicare claims and benefit information. At this time, 75 third-
party apps are connected to the Blue Button 2.0 API, giving
beneficiaries a variety of services for viewing their health data,
sharing their data with digital services, providers, pharmacies, and
caregivers, and making decisions related to their healthcare.
Currently, Blue Button 2.0 includes Medicare Part A, B, and D claims
information, patient demographics, and coverage information.
Additionally, in 2019, CMS launched the Data at the Point of Care API
pilot to give providers access to claims data for Medicare Fee-For-
Service (FFS) beneficiaries they treat.
On May 1, 2020, CMS published the ``Medicare and Medicaid Programs;
Patient Protection and Affordable Care Act; Interoperability and
Patient Access for MA Organization and Medicaid Managed Care Plans,
State Medicaid Agencies, CHIP Agencies and CHIP Managed Care Entities,
Issuers of Qualified Health Plans on the Federally-Facilitated
Exchanges, and Healthcare Providers'' final rule (CMS Interoperability
and Patient Access final rule) (CMS-9115-F) (85 FR 25510). The rule
established standards and requirements for payers regulated by CMS to
advance interoperability and data exchange throughout the health system
and to signal our commitment to the vision set out in the 21st Century
Cures Act and Executive Order 13813 to improve quality and
accessibility of information that Americans need to make informed
healthcare decisions, including data about healthcare prices and
outcomes, while minimizing reporting burdens on affected healthcare
providers and payers.
The CMS Interoperability and Patient Access final rule built on the
Health Insurance Portability and Accountability Act (HIPAA) Privacy
Rule, which established the patient's right of access to their
protected health information (PHI), including a right to inspect and/or
receive a copy of PHI held in designated record sets by covered
entities and their business associates as detailed at 45 CFR 164.524.
Among other provisions, the 2020 CMS Interoperability and Patient
Access final rule required impacted payers to implement and maintain
(Health Level Seven (HL7[supreg]) FHIR-based APIs that would allow
patients to use an app of their choosing to access PHI held by or on
behalf of a HIPAA covered entity.
On May 1, 2020, ASTP ONC published the ``21st Century Cures Act:
Interoperability, Information Blocking, and the ONC Health Information
Technology (IT) Certification Program'' final rule (ONC Cures Act final
rule) (85 FR 25642). This final rule strengthened patients' electronic
access (including via a third-party app) to their health information at
no cost and added a certification criterion under the ONC Health IT
Certification Program to support the availability of FHIR-based APIs in
electronic health records and other certified health IT to enable
patients and providers to view electronic health information using
smartphone applications.
Subsequent ASTP/ONC regulations finalized provisions to advance
interoperability, enhance health IT certification, and support the
access, exchange, and use of electronic health information.
Specifically, the ASTP/ONC ``Health Data, Technology, and
Interoperability: Certification Program Updates, Algorithm
Transparency, and Information Sharing'' final rule (HTI-1 final rule),
which adopted version 3 of the United States Core Data for
Interoperability (USCDI) standard \2\ and expanded access to more data
via FHIR APIs that meet standards adopted by ASTP/ONC (89 FR 1192); and
the ``Health Data, Technology, and Interoperability: Trusted Exchange
Framework and Common Agreement'' final rule (HTI-2 final rule), which
implemented provisions related to the Trusted Exchange Framework and
Common Agreement\TM\ (TEFCA\TM\) that support information sharing as
well as network reliability, privacy, security, and trust (89 FR
101772).
---------------------------------------------------------------------------
\2\ https://www.healthit.gov/isp/united-states-core-data-interoperability-uscdi. The United States Core Data for
Interoperability (USCDI) is a standardized set of health data
classes and constituent data elements for nationwide, interoperable
health information exchange.
---------------------------------------------------------------------------
In 2024, CMS published the ``Interoperability and Prior
Authorization'' final rule, which required impacted payers to implement
and maintain a Provider Access API, similar to CMS' Data at the Point
of Care
[[Page 21036]]
API, to make current patients' claims and encounter data available to
in-network or enrolled providers with whom the patient has a verified
treatment relationship, at the provider's request (89 FR 8758). The
final rule requires impacted payers to be in compliance by January 1,
2027.
The policy framework established by CMS and ASTP/ONC rulemakings
are intended to promote the seamless and secure flow of health
information between patients, providers, and payers, enabling digital
workflows supported by smartphone applications and other modern tools.
II. Solicitation of Public Comments
As the breadth, depth, quality, and timeliness of health data
available to patients through standards-based APIs increase, evolving
digital health products will gain greater functionality and potential
for enhancing the healthcare experience, reducing costs, increasing
access to care, enabling chronic disease prevention, and improving
healthcare outcomes. Although the building blocks for a patient-centric
digital health ecosystem are in place, the experience of most patients,
caregivers, and providers is neither seamless nor simple. To get access
to their data, patients have to track which providers they have seen
and set up separate accounts and credentials with each portal. Even for
patients who are able to set this up, digital products for health
management or care navigation that can leverage patient health records
are still rare; appointment scheduling often still entails lengthy
phone calls and provider intake still involves clipboards of multiple
forms.
CMS and ASTP/ONC would like to continue to build on the existing
policy framework to drive large-scale adoption of health management and
care navigation applications, reduce barriers to data access and
exchange, realize the potential of recent innovations in healthcare
that promote better health outcomes, and accelerate progress towards a
patient-centric learning health system.
CMS and ASTP/ONC seek feedback from stakeholders, including but not
limited to: patients and caregivers, providers, payers, health IT
companies, health information exchanges, health information networks,
clearinghouses, researchers, and developers of digital health products
regarding how we can help achieve the potential of digital health
technology. CMS and ASTP/ONC also seek feedback on which elements of
today's digital health ecosystem are working, which are working
inconsistently and need improvement, and which are impeding rapid
progress. CMS and ASTP/ONC also seek input for possible consideration
in future rulemaking on policies to ease health data exchange and
promote innovation in consumer digital health products, and how HHS can
encourage patient, caregiver, and provider engagement with digital
health products.
Furthermore, the transition to value-based care (VBC) represents a
cornerstone of CMS' strategy to incentivize improvements in health
outcomes rather than increases in service volume. The role of
technology is critical to this transformation. While significant
progress has been made in health IT adoption, opportunities remain to
better align technology requirements with the needs of providers
participating in Alternative Payment Models (APMs) and other value-
based care programs. Among other topics, CMS and ASTP/ONC seek feedback
on current HHS requirements around the use of technology, including the
use of health IT certified under the ONC Health IT Certification
Program, by healthcare providers participating in VBC initiatives.
Among other areas of inquiry, CMS and ASTP/ONC request input on
requirements for the use of certified electronic health record (EHR)
technology (CEHRT), and how such requirements can enable value-based
care and meet statutory requirements while meeting other program
objectives, such as reducing provider burden, to better support value-
based care adoption among providers, and subsequently improve patient
choice and competition in the healthcare marketplace.
The questions that follow are grouped by use cases corresponding to
patients and caregivers, providers, payers, technology vendors and data
providers, and VBC organizations. We encourage patient advocates and
healthcare stakeholders to share their feedback for as many of these
use cases as possible. The questions are not meant to be directed to a
specific audience but are meant to solicit feedback from multiple types
of stakeholders for each use case as appropriate. To aid understanding
of submitted responses, please prioritize clarity and conciseness and
annotate your responses with question label(s) (for example, PC-1).
Because we expect some responses to relate to software workflows
that may be difficult to fully articulate in written responses, we
welcome links to screenshots or brief video demonstrations as part of
submitted feedback. Please keep videos to a maximum of 15 minutes total
to highlight real-world challenges, workflow examples, or functional
capabilities and keep introduction of the presenters and company to no
more than 2 minutes.
A. Definitions for Terms Used in This RFI
Digital tools: web, mobile or other software applications,
potentially leveraging sensors, wearables or other hardware.
Digital health products: defined as digital tools that
support individual health needs.
Health management applications: Digital tools that
leverage patients' data and other information to support patients with
health decision-making.
Care navigation applications: Digital tools that help
patients identify, select, and access providers or auxiliary care
services.
Personal health record apps: Software applications that
collect and organize an individual's health records and provider
encounter data for viewing, sharing, and usage in digital health
products.
B. Patients and Caregivers
This section is intended for all stakeholders to provide input on
questions as they relate to use cases and workflows that involve
patients and caregivers. While we certainly want patients and
caregivers to answer questions in this section (and in other sections)
from the patient/caregiver point of view, we also invite all
stakeholders to provide their viewpoints on the patient/caregiver
workflows.
1. Patient Needs
PC-1. What health management or care navigation apps would help you
understand and manage your (or your loved ones) health needs, as well
as the actions you should take?
a. What are the top things you would like to be able to do for your
or your loved ones' health that can be enabled by digital health
products?
b. If you had a personal assistant to support your health needs,
what are the top things you would ask them to help with? In your
response, please consider tasks that could be supported or facilitated
by software solutions in the future.
PC-2. Do you have easy access to your own and all your loved ones'
health information in one location (for example, in a single patient
portal or another software system)?
a. If so, what are some examples of benefits it has provided?
b. If not, in what contexts or for what workflows would it be most
valuable to
[[Page 21037]]
use one portal or system to access all such health information?
c. Were there particular data types, such as x-rays or specific
test results, that were unavailable? What are the obstacles to
accessing your own or your loved ones' complete health information
electronically and using it for managing health conditions or finding
the best care (for example, limitations in functionality, user
friendliness, or access to basic technology infrastructure)?
PC-3. Are you aware of health management, care navigation, or
personal health record apps that would be useful to Medicare
beneficiaries and their caregivers?
PC-4. What features are missing from apps you use or that you are
aware of today?
a. What apps should exist but do not yet? Why do you believe they
do not exist yet?
b. What set of workflows do you believe CMS is uniquely positioned
to offer?
PC-5. What can CMS and its partners do to encourage patient and
caregiver interest in these digital health products?
a. What role, if any, should CMS have in reviewing or approving
digital health products on the basis of their efficacy, quality or
impact or both on health outcomes (not approving in the sense of a
coverage determination)? What criteria should be used if there is a
review process? What technology solutions, policy changes, or program
design changes can increase patient and caregiver adoption of digital
health products (for example, enhancements to data access,
reimbursement adjustments, or new beneficiary communications)?
b. What changes would enable timely access to high quality CMS and
provider generated data on patients?
PC-6. What features are most important to make digital health
products accessible and easy to use for Medicare beneficiaries and
caregivers, particularly those with limited prior experience using
digital tools and services?
PC-7. If CMS were to collect real-world data on digital health
products' impact on health outcomes and related costs once they are
released into the market, what would be the best means of doing so?
2. Data Access and Integration
PC-8. In your experience, what health data is readily available and
valuable to patients or their caregivers or both?
a. What data is valuable, but hard for patients and caregivers, or
app developers and other technical vendors, to access for appropriate
and valuable use (for example, claims data, clinical data, encounter
notes, operative reports, appointment schedules, prices)?
b. What are specific sources, other than claims and clinical data,
that would be of highest value, and why?
c. What specific opportunities and challenges exist to improve
accessibility, interoperability and integration of clinical data from
different sources to enable more meaningful clinical research and
generation of actionable evidence?
PC-9. Given that the Blue Button 2.0 API only includes basic
patient demographic, Medicare coverage, and claims data (Part A, B, D),
what additional CMS data sources do developers view as most valuable
for inclusion in the API to enable more useful digital products for
patients and caretakers?
a. What difficulties are there in accessing or utilizing these data
sources today?
b. What suggestions do you have to improve the Blue Button 2.0 API
experience?
c. Is there non-CMS data that should be included in the API?
PC-10. How is the Trusted Exchange Framework and Common
AgreementTM (TEFCATM) currently helping to
advance patient access to health information in the real world?
a. Please provide specific examples.
b. What changes would you suggest?
c. What use cases could have a significant impact if implemented
through TEFCA?
d. What standards are you aware of that are currently working well
to advance access and existing exchange purposes?
e. What standards are you aware of that are not currently in wide
use, but could improve data access and integration?
f. Are there redundant standards, protocols, or channels that
should be consolidated?
g. Are there adequate alternatives outside of TEFCA for achieving
widespread patient access to their health information?
PC-11. How are health information exchanges (HIEs) currently
helping to advance patient access to health information in the real
world?
a. How valuable, available, and accurate do you find the data they
share to be?
b. What changes would you suggest?
c. Are there particular examples of high-performing HIE models that
you believe should be propagated across markets?
d. What is the ongoing role of HIEs amidst other entities
facilitating data exchange and broader frameworks for data exchange
(for example, vendor health information networks, TEFCA, private
exchange networks, etc.)?
PC-12. What are the most valuable operational health data use cases
for patients and caregivers that, if addressed, would create more
efficient care navigation or eliminate barriers to competition among
providers or both?
a. Examples may include the following:
(1) Binding cost estimates for pre-defined periods.
(2) Viewing provider schedule availability.
(3) Using third-party apps for appointment management.
(4) Accessing patient-facing quality metrics.
(5) Finding the right provider for specific healthcare needs.
b. What use cases are possible today?
c. What should be possible in the near future?
d. What would be very valuable but may be very hard to achieve?
3. Information Blocking and Digital Identity
PC-13. How can CMS encourage patients and caregivers to submit
information blocking complaints to ASTP/ONC's Information Blocking
Portal? What would be the impact? Would increasing reporting of
complaints advance or negatively impact data exchange?
PC-14. Regarding digital identity credentials (for example, CLEAR,
Login.gov, ID.me, other NIST 800-63-3 IAL2/AAL2 credentialing service
providers (CSP)):
a. What are the challenges today in getting patients/caregivers to
sign up and use digital identity credentials?
b. What could be the benefits to patients/caregivers if digital
identity credentials were more widely used?
c. What are the potential downsides?
d. How would encouraging the use of CSPs improve access to health
information?
e. What role should CMS/payers, providers, and app developers have
in driving adoption?
f. How can CMS encourage patients to get digital identity
credentials?
C. Providers
This section is intended for all stakeholders to provide input on
questions as they relate to use cases and workflows that involve
providers. While we certainly want providers to answer questions in
this section (and in other sections) from the provider point of view,
we also invite all stakeholders to provide their viewpoints on the
provider workflows as appropriate.
[[Page 21038]]
1. Digital Health Apps
PR-1. What can CMS and its partners do to encourage providers,
including those in rural areas, to leverage approved (see description
in PC-5) digital health products for their patients?
a. What are the current obstacles?
b. What information should providers share with patients when using
digital products in the provision of their care?
c. What responsibilities do providers have when recommending use of
a digital product by a patient?
PR-2. What are obstacles that prevent development, deployment, or
effective utilization of the most useful and innovative applications
for physician workflows, such as quality measurement reporting,
clinical documentation, and billing tasks? How could these obstacles be
mitigated?
PR-3. How important is it for healthcare delivery and
interoperability in urban and rural areas that all data in an EHR
system be accessible for exchange, regardless of storage format (for
example, scanned documents, faxed records, lab results, free text
notes, structured data fields)? Please address all of the following:
a. Current challenges in accessing different data formats.
b. Impact on patient care quality.
c. Technical barriers to full data accessibility.
d. Cost or privacy implications of making all data formats
interoperable.
e. Priority level compared to other interoperability needs.
PR-4. What changes or improvements to standards or policies might
be needed for patients' third-party digital products to have access to
administrative workflows, such as auto-populating intake forms, viewing
provider information and schedules, and making and modifying an
appointment?
2. Data Exchange
PR-5. Which of the following FHIR APIs and capabilities do you
already support or utilize in your provider organization's systems,
directly or through an intermediary? For each, describe the transaction
model, use case, whether you use individual queries or bulk
transactions, and any constraints:
a. Patient Access API.
b. Standardized API for Patient and Population Services.
c. Provider Directory API.
d. Provider Access API.
e. Payer-to-Payer API.
f. Prior Authorization API.
g. Bulk FHIR--Do you support Group ID-based access filtering for
population-specific queries?
h. SMART on FHIR--Do you support both EHR-launched and standalone
app access? What does the process for application deployment entail?
i. CDS Hooks (for clinical decision support integrations).
PR-6. Is TEFCA currently helping to advance provider access to
health information?
a. Please provide specific examples.
b. What changes would you suggest?
c. What other options are available outside of TEFCA?
d. Are there redundant standards, protocols or channels or both
that could be consolidated?
PR-7. What strategies can CMS implement to support providers in
making high-quality, timely, and comprehensive healthcare data
available for interoperability in the digital product ecosystem? How
can the burden of increasing data availability and sharing be mitigated
for providers? Are there ways that workflows or metrics that providers
are already motivated to optimize for that could be reused for, or
combined with, efforts needed to support interoperability?
PR-8. What are ways CMS or partners can help with simplifying
clinical quality data responsibilities of providers?
a. What would be the benefits and downsides of using Bulk FHIR data
exports from EHRs to CMS to simplify clinical quality data submissions?
Can CMS reduce the burden on providers by performing quality metrics
calculations leveraging Bulk FHIR data exports?
b. In what ways can the interoperability and quality reporting
responsibilities of providers be consolidated so investments can be
dually purposed?
c. Are there requirements CMS should consider for data registries
to support digital quality measurement in a more efficient manner? Are
there requirements CMS should consider for data registries that would
support access to real-time quality data for healthcare providers to
inform clinical care in addition to simplifying reporting processes?
3. Digital Identity
PR-9. How might CMS encourage providers to accept digital identity
credentials (for example, CLEAR, ID.me, Login.gov) from patients and
their partners instead of proprietary logins that need to be tracked
for each provider relationship?
a. What would providers need help with to accelerate the transition
to a single set of trusted digital identity credentials for the patient
to keep track of, instead of one for each provider?
b. How might CMS balance patient privacy with convenience and
access to digital health products and services that may lead to
significant improvements in health?
PR-10. Regarding digital identity credentials (for example, CLEAR,
Login.gov, ID.me, other NIST 800-63-3 IAL2/AAL2 CSPs):
a. What are the challenges and benefits for providers?
b. How would requiring their use improve access to health
information?
c. What are the potential downsides?
d. What impact would mandatory credentials have on a nationwide
provider directory?
e. How could digital identity implementation improve provider data
flow?
f. Would combining FHIR addresses and identity improve data flow?
PR-11. How could members of trust communities \3\ (for example,
QHINs, participants and subparticipants in TEFCA, which requires
Identity Assurance Level 2 (IAL2) via Credential Service Providers
(CSPs)) better support the goals of reduced provider and patient burden
while also enhancing identity management and security?
---------------------------------------------------------------------------
\3\ A trust community is an ecosystem of health networks that
operate under a common set of rules and technical requirements to
securely exchange electronic health information.
---------------------------------------------------------------------------
4. Information Blocking
PR-12. Should ASTP/ONC consider removing or revising any of the
information blocking exceptions or conditions within the exceptions (45
CFR part 171, subparts B through D) to further the access, exchange,
and use of electronic health information (EHI) and to promote market
competition?
PR-13. For any category of healthcare provider (as defined in 42
U.S.C. 300jj(3)), without a current information blocking disincentive
established by CMS, what would be the most effective disincentive for
that category of provider?
PR-14. How can CMS encourage providers to submit information
blocking complaints to ASTP/ONC's Information Blocking Portal? What
would be the impact? Would it advance or negatively impact data
exchange?
D. Payers
PA-1. What policy or technical limitations do you see in TEFCA?
What changes would you suggest to address those limitations? To what
degree do you expect these limitations to hinder participation in
TEFCA?
PA-2. How can CMS encourage payers to accelerate the implementation
and utilization of APIs for patients,
[[Page 21039]]
providers, and other payers, similar to the Blue Button 2.0 and Data at
the Point of Care APIs released by CMS?
PA-3. How can CMS encourage payers to accept digital identity
credentials (for example, CLEAR, ID.me, Login.gov) from patients and
their partners instead of proprietary logins?
PA-4. What would be the value to payers of a nationwide provider
directory that included FHIR end points and used digital identity
credentials?
PA-5. What are ways payers can help with simplifying clinical
quality data responsibilities of providers?
a. How interested are payers and providers in EHR technology
advances that enable bulk extraction of clinical quality data from EHRs
to payers to allow them to do the calculations instead of the provider-
side technology?
b. In what ways can the interoperability and quality reporting
responsibilities of providers to both CMS and other payers be
consolidated so investments can be dually purposed? Are there
technologies payers might leverage that would support access to real
time quality data for healthcare providers to inform clinical care in
addition to simplifying reporting processes?
PA-7. How can CMS encourage payers to submit information blocking
complaints to ASTP/ONC's Information Blocking Portal? What would be the
impact? Would it advance or negatively impact data exchange?
E. Technology Vendors, Data Providers, and Networks
This section is intended for all stakeholders to provide input on
questions as they relate to use cases and workflows that involve
technology vendors, data providers, and networks. While we certainly
want technology vendors, data providers, and networks to answer
questions in this section (and in other sections) from their point of
view, we also invite all stakeholders to provide their viewpoints on
the technology vendor, data provider, and network use cases as
appropriate.
1. Ecosystem
TD-1. What short term (in the next 2 years) and longer-term steps
can CMS take to stimulate developer interest in building digital health
products for Medicare beneficiaries and caregivers?
TD-2. Regarding CMS Data, to stimulate developer interest--
a. What additional data would be most valuable if made available
through CMS APIs?
b. What data sources are most valuable alongside the data available
through the Blue Button 2.0 API?
c. What obstacles prevent accessing these data sources today?
d. What other APIs should CMS and ASTP/ONC consider including in
program policies to unleash innovation and support patients and
providers?
2. Digital Identity
TD-3. Regarding digital identity implementation:
a. What are the challenges and benefits?
b. How would requiring digital identity credentials (for example,
CLEAR, Login.gov, ID.me, other NIST 800-63-3 IAL2/AAL2 CSPs) impact
cybersecurity and data exchange?
c. What impact would mandatory use of the OpenID Connect identity
protocol have?
3. Technical Standards and Certification
TD-4. How can CMS better encourage use of open, standards-based,
publicly available APIs over proprietary APIs?
TD-5. How could a nationwide provider directory of FHIR endpoints
improve access to health information for patients, providers, and
payers? Who should publish such a directory, and should users bear a
cost?
TD-6. What unique interoperability functions does TEFCA perform?
a. What existing alternatives should be considered?
b. Are there redundant standards, protocols or channels or both
that should be consolidated?
TD-7. To what degree has USCDI improved interoperability and
exchange and what are its limitations?
a. Does it contain the full extent of data elements you need?
b. If not, is it because of limitations in the definition of the
USCDI format or the way it is utilized?
c. If so, would adding more data elements to USCDI add value or
create scoping challenges? How could such challenges be addressed?
d. Given improvements in language models, would you prefer a non-
proprietary but less structured format that might improve data coverage
even if it requires more processing by the receiver?
TD-8. What are the most effective certification criteria and
standards under the ONC Health IT Certification Program?
TD-9. Regarding certification of health IT:
a. What are the benefits of redefining certification to prioritize
API-enabled capabilities over software functionality?
b. What would be the drawbacks?
c. How could ASTP/ONC revise health IT certification criteria to
require APIs to consistently support exchanging data from all aspects
of the patient's chart (for example, faxed records, free text, discrete
data)?
d. What policy changes could CMS make so providers are motivated to
respond to API-based data requests with best possible coverage and
quality of data?
e. How could EHRs capable of bulk data transfer be used to reduce
the burden on providers for reporting quality performance data to CMS?
What capabilities are needed to show benefit? What concerns are there
with this approach?
TD-10. For EHR and other developers subject to the ONC Health IT
Certification Program, what further steps should ASTP/ONC consider to
implement the 21st Century Cures Act's API condition of certification
(42 U.S.C. 300jj-11(c)(5)(D)(iv)) that requires a developer's APIs to
allow health information to be accessed, exchanged, and used without
special effort, including providing access to all data elements of a
patient's electronic health record to the extent permissible under
applicable privacy laws?
TD-11. As of January 1, 2024, many health IT developers with
products certified through the ONC Health IT Certification Program are
required to include the capability to perform an electronic health
information export or ``EHI export'' for a single patient as well as
for patient populations (45 CFR 170.315(b)(10)). Such health IT
developers are also required to publicly describe the format of the EHI
export. Notably, how EHI export was accomplished was left entirely to
the health IT developer. Now that this capability has been in
production for over a year, CMS and ASTP/ONC seek input on the
following:
a. Should this capability be revised to specify standardized API
requirements for EHI export?
b. Are there specific workflow aspects that could be improved?
c. Should CMS consider policy changes to support this capability's
use?
4. Data Exchange
TD-12. Should CMS endorse non-CMS data sources and networks, and if
so, what criteria or metrics should CMS consider?
TD-13. What new opportunities and advancements could emerge with
APIs providing access to the entirety of a patient's electronic health
information (EHI)?
a. What are the primary obstacles to this?
b. What are the primary tradeoffs between USCDI and full EHI,
especially
[[Page 21040]]
given more flexible data processing capabilities today?
TD-14. Regarding networks' use of FHIR APIs:
a. How many endpoints is your network connected to for patient data
sharing? What types, categories, geographies of endpoints do you cover?
Are they searchable by National Provider Identifier (NPI) or
organizational ID?
b. How are these connections established (for example, FHIR (g)(10)
endpoints, TEFCA/Integrating the Health Enterprise (IHE) XCA, or
proprietary APIs)?
c. Do you interconnect with other networks? Under what frameworks
(for example, TEFCA, private agreements)?
TD-15. Regarding bulk FHIR APIs:
a. How would increased use of bulk FHIR improve use cases and data
flow?
b. What are the potential disadvantages of their use?
TD-16. What are the tradeoffs of maintaining point-to-point models
vs. shared network infrastructure?
a. Do current rules encourage scalable network participation?
b. What changes would improve alignment (for example, API
unification, reciprocal access)?
TD-17. Given operational costs, what role should CMS or ASTP/ONC or
both have in ensuring viability of healthcare data sharing networks,
including enough supply and demand, that results in usage and outcomes?
5. Compliance
TD-18. Information blocking:
a. Could you, as a technology vendor, provide examples for the
types of practices you have experienced that may constitute information
blocking. Please include both situations of non-responsiveness as well
as situations that may cause a failure or unusable response?
b. What additional policies could ASTP/ONC and CMS implement to
further discourage healthcare providers from engaging in information
blocking practices?
c. Are there specific categories of healthcare actors covered under
the definition of information blocking in section 3022(a)(1) of the
Public Health Service Act (PHSA) that lack information blocking
disincentives?
TD-19. Regarding price transparency implementation:
a. What are current shortcomings in content, format, delivery, and
timeliness?
b. Which workflows would benefit most from functional price
transparency?
c. What improvements would be most valuable for patients,
providers, or payers, including CMS?
d. What would further motivate solution development?
F. Value-Based Care Organizations
This section is intended for all stakeholders to provide input on
questions as they relate to use cases and workflows that involve value-
based care organizations. While we certainly want value-based care
organizations to answer questions in this section (and in other
sections) from the value-based care provider point of view, we also
invite all stakeholders to provide their viewpoints on the value-based
care workflows as appropriate.
1. Digital Health Adoption
VB-1. What incentives could encourage APMs such as accountable care
organizations (ACOs) or participants in Medicare Shared Savings Program
(MSSP) to leverage digital health management and care navigation
products more often and more effectively with their patients? What are
the current obstacles preventing broader digital product adoption for
patients in ACOs?
VB-2. How can key themes and technologies such as artificial
intelligence, population health analytics, risk stratification, care
coordination, usability, quality measurement, and patient engagement be
better integrated into APM requirements?
VB-3. What are essential health IT capabilities for value-based
care arrangements?
a. Examples (not comprehensive) may include: care planning, patient
event notification, data extraction/normalization, quality performance
measurement, access to claims data, attribution and patient ID
matching, remote device interoperability, or other patient empowerment
tools.
b. What other health IT capabilities have proven valuable to
succeeding in value-based care arrangements?
VB-4. What are the essential data types needed for successful
participation in value-based care arrangements?
2. Compliance and Certification
VB-5. In your experience, how do current certification criteria and
standards incorporated into the ONC Health IT Certification Program
support value-based care delivery?
VB-6. What specific health information technology capabilities that
could benefit APMs are not currently addressed by existing
certification criteria and standards that should be included under the
ONC Health IT Certification Program?
VB-7. How can technology requirements for APMs, established through
CEHRT or other pathways, reduce complexity while preserving necessary
flexibility?
VB-8. How can other HHS policies supplement CEHRT requirements to
better optimize the use of digital health products in APMs? As an
example, requirements under the Conditions of Participation for
hospitals (42 CFR 482.24(d)) require hospitals to transmit electronic
patient event notifications to community providers. What barriers are
in place preventing APM participants from receiving the same
notifications?
VB-9. What technology requirements should be different for APM
organizations when comparing to non-APM organizations (for example,
quality reporting, and interoperability)?
VB-10. In the Calendar Year (CY) 2024 Physician Fee Schedule final
rule (88 FR 79413), CMS established that CEHRT requirements for
Advanced APMs beyond those in the ``Base EHR'' definition should be
flexible based on what is applicable to the APM that year based on the
area of clinical practice. What certification criteria should CMS
identify under this flexibility for specific Advanced APMs, or for
Advanced APMs in general? Are there specific flexibilities or
alternatives to consider for smaller or resource-constrained (such as
rural) providers in meeting CEHRT requirements without compromising
quality of care or availability of performance data?
3. Technical Standards
VB-11. What specific interoperability challenges have you
encountered in implementing value-based care programs?
VB-12. What technology standardization would preserve program-
specific flexibility while promoting innovation in APM technology
implementation?
VB-13. What improvements to existing criteria and standards would
better support value-based care capabilities while reducing provider
burden?
VB-14. How could implementing digital identity credentials improve
value-based care delivery and outcomes?
VB-15. How could a nationwide provider directory of FHIR endpoints
help improve access to patient data and understanding of claims data
sources? What key data elements would be necessary in a nationwide FHIR
[[Page 21041]]
endpoints directory to maximize its effectiveness?
III. Collection of Information Requirements
Please note, this is a request for information (RFI) only. In
accordance with the implementing regulations of the Paperwork Reduction
Act of 1995 (PRA), specifically 5 CFR 1320.3(h)(4), this general
solicitation is exempt from the PRA. Facts or opinions submitted in
response to general solicitations of comments from the public,
published in the Federal Register or other publications, regardless of
the form or format thereof, provided that no person is required to
supply specific information pertaining to the commenter, other than
that necessary for self-identification, as a condition of the agency's
full consideration, are not generally considered information
collections and therefore not subject to the PRA.
This RFI is issued solely for information and planning purposes; it
does not constitute a Request for Proposal (RFP), applications,
proposal abstracts, or quotations. This RFI does not commit the U.S.
Government to contract for any supplies or services or make a grant
award. Further, CMS and ASTP/ONC are not seeking proposals through this
RFI and will not accept unsolicited proposals. Responders are advised
that the U.S. Government will not pay for any information or
administrative costs incurred in response to this RFI; all costs
associated with responding to this RFI will be solely at the interested
party's expense. CMS and ASTP/ONC note that not responding to this RFI
does not preclude participation in any future procurement, if
conducted. It is the responsibility of the potential responders to
monitor this RFI announcement for additional information pertaining to
this request. In addition, CMS and ASTP/ONC note that we will not
respond to questions about potential policy issues raised in this RFI.
CMS and ASTP/ONC will actively consider input as we develop future
regulatory proposals or future subregulatory policy guidance. We may or
may not choose to contact individual responders. Such communications
would be for the sole purpose of clarifying statements in the
responders' written responses. Contractor support personnel may be used
to review responses to this RFI. Responses to this notice are not
offers and cannot be accepted by the Government to form a binding
contract or issue a grant. Information obtained as a result of this RFI
may be used by the Government for program planning on a non-attribution
basis. Respondents should not include any information that might be
considered proprietary or confidential. This RFI should not be
construed as a commitment or authorization to incur cost for which
reimbursement would be required or sought. All submissions become U.S.
Government property and will not be returned. In addition, we may
publicly post the public comments received or a summary of those public
comments.
Stephanie Carlton, Deputy Administrator of the Centers for Medicare
& Medicaid Services, approved this document on May 9, 2025.
Steven Posnack, Acting Assistant Secretary for Technology Policy,
Acting National Coordinator for Health Information Technology, approved
this document on May 6, 2025.
Robert F. Kennedy, Jr.,
Secretary, Department of Health and Human Services.
[FR Doc. 2025-08701 Filed 5-13-25; 11:15 am]
BILLING CODE 4120-01-P