90 FR 94 pgs. 21034-21041 - Request for Information; Health Technology Ecosystem

Type: NOTICEVolume: 90Number: 94Pages: 21034 - 21041
Docket number: [CMS-0042-NC]
FR document: [FR Doc. 2025-08701 Filed 5-13-25; 11:15 am]
Agency: Health and Human Services Department
Sub Agency: Centers for Medicare & Medicaid Services
Official PDF Version:  PDF Version
Pages: 21034, 21035, 21036, 21037, 21038, 21039, 21040, 21041

[top] page 21034

DEPARTMENT OF HEALTH AND HUMAN SERVICES

Centers for Medicare & Medicaid 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.


[top] 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:

HealthTechRFI@cms.hhs.gov .

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.

Footnotes:

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®)-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®) 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).

Footnotes:

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.


[top] 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?


[top] 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 Agreement TM (TEFCA TM ) 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


[top] 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?

Footnotes:

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?


[top] 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?


[top] 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?


[top] 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