Flexpa's response to CMS-0042-NC

The following is Flexpa's response to CMS-0042-NC, CMS and ASTP/ONC's request for information on digital health products for Medicare beneficiaries and the state of data interoperability. Drawing from our experience operating the nation's largest payer API network, we provide concrete recommendations for improving Blue Button 2.0, addressing USCDI implementation gaps, standardizing digital identity, and building sustainable network infrastructure.

Background and Context

Flexpa is the leading consent management system that connects patient-consented claims data from every health plan, operating the largest network of Payer FHIR endpoints in the United States with connectivity to 350+ health plans. Through our extensive experience implementing and troubleshooting Patient Access APIs mandated by CMS-9115-F, we have unique insights into the current state of healthcare data interoperability and the path forward for meaningful digital health innovation.

Our response focuses on areas where we have direct operational experience and can provide concrete recommendations to improve patient access to health data, enhance API implementation quality, and build sustainable network infrastructure that serves patients, providers, and payers effectively. We believe these recommendations will help CMS achieve its vision of a truly interoperable healthcare ecosystem that empowers patients and enables innovative digital health solutions.

PC-9: Enhancing the Blue Button 2.0 API for Comprehensive Patient Access

In response to 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?

CMS's Blue Button 2.0 API represented an important milestone in patient data access, but it now significantly lags behind the capabilities required by CMS-9115-F for Medicare Advantage plans. This disparity creates an uneven playing field where Traditional Medicare beneficiaries have access to less comprehensive data than their MA counterparts, undermining the principle of equitable access to health information.

The current Coverage resource in Blue Button 2.0 lacks the detailed plan information that patients need to make informed healthcare decisions. We recommend expanding the Coverage resource to include:

• Copays, deductibles, and coverage limits
• Network provider directories
• Formulary information for Part D coverage
• Prior authorization requirements by service type

Unlike CMS-9115-F implementations that include clinical data, Blue Button 2.0 remains focused solely on claims data. CMS should leverage its clinical data aggregation capabilities to include laboratory results maintained by CMS and clinical data extrapolated from claims where appropriate. This enhancement would provide patients with a more complete picture of their health status and enable more sophisticated care management applications.

To maintain consistency with the upcoming CMS-0057 requirements, Blue Button 2.0 should include prior authorization decisions, even for the limited services requiring prior authorization in Traditional Medicare. This alignment would ensure that patients have consistent access to authorization information regardless of their coverage type and prepare the infrastructure for broader prior authorization transparency initiatives.

We are very excited that CMS has committed to enabling Medicare beneficiaries to access Blue Button 2.0 data using federated identity credentials such as Login.gov, ID.me, or TEFCA Identity Assurance Services rather than requiring separate Medicare.gov accounts. This approach will reduce authentication friction for patients, align with broader federal digital identity initiatives, and enable more seamless integration with third-party applications. It will also lead the charge for other payers, especially those with Medicare Advantage plans to also begin adopting digital identity for an overall smoother membership experience.

TD-7: USCDI Implementation Gaps in Payer APIs

In response to 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?

USCDI represents a critical standardization effort that should theoretically improve interoperability and data exchange consistency across healthcare systems. However, our operational experience connecting to over 350 payer endpoints reveals significant gaps between USCDI's intended benefits and actual implementation reality.

Many payers have implemented Patient Access APIs that claim USCDI compliance while omitting core data elements or implementing them in non-standard ways. This selective implementation creates the illusion of standardization while perpetuating the data fragmentation that USCDI was designed to address. From our May 2025 State of the Payer Patient Access API Report^1, we note:

• 49% of payers fail to provide or have a working Coverage resource endpoint.
• 54% fail to provide or have a working Explanation of Benefits resource; 7 payers do not support it at all.
• Only 64% support resolving references to the Practitioner resource, and only 61% of those have ever succeeded.
• 82% support Organization references, with 60% successful resolution.
• Procedure and Condition resources are each supported by just 43% of payers.

Even when resources are technically available, non-standard implementations require custom logic per payer. 40% of claim adjudication categories do not use the correct binding system, and 35% of Patient identifiers use proprietary codes. Patient demographic data varies widely, affecting attribution and matching.

Rather than expanding USCDI, CMS should focus on ensuring robust implementation of current standards via:

• Conformance testing (e.g., ONC's Inferno framework)
• Machine-readable validation
• Enforcement mechanisms and penalties for misleading claims

TD-11: Standardizing EHI Export Through API Requirements

In response to 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?

While the current EHI export mandate under [45 CFR 170.315(b)(10)] represents progress, in practice, these capabilities are hard to use. Exports are buried within EHR interfaces not normally used by patients. Buttons vanish inexplicably. Requests often disappear without acknowledgment. Wait times range from days to weeks, and status is rarely visible.

API-enabled access eliminates these issues. Patients can authorize third-party apps for real-time data access. Developers can offer smoother workflows without relying on obscure EHR UI. Providers reduce support overhead.

CMS should revise the export requirement using the Argonaut EHI Export API Guide^2 to require:

• FHIR R4 and SMART on FHIR flows
• Support for both individual and system-level export
• Async bulk export capabilities
• Documentation of proprietary fields

To encourage adoption, CMS should tie implementation quality to incentives like reimbursements or quality scores.

TD-3: Digital Identity Implementation for Healthcare Interoperability

In response to 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?

A robust, high‑assurance digital identity layer is the linchpin of patient‑centered data exchange. Flexpa operates the nation's largest network of FHIR‑based payer APIs and sees first‑hand how fragmented identity experiences impede adoption. We strongly support CMS and ASTP/ONC efforts to advance consistent, standards‑based identity proofing grounded in IAL2 and OpenID Connect (OIDC).

The lack of a high assurance, portable identity credential is the single biggest barrier to adoption in our view.

We recommend a phased requirement for payers to accept at least one government‑operated credential (ie. Login.gov) and to expose an OIDC‑conformant authorization server, with technical assistance for small payers and equity safeguards for underserved populations.

TD‑3(a): Challenges and Benefits of Digital Identity Implementation

Challenges:

• Credential Fragmentation: Patients juggle more than 1,000 unique payer and provider portals, each with proprietary credentials.

• Inconsistent Assurance Levels: Many portals rely solely on username/password, lacking NIST IAL2/AAL2 proofing and MFA, increasing impersonation risk.

• Operational Overhead for Payers: Each portal must independently manage breach monitoring, password resets, and account recovery.

Benefits:

• Frictionless Access & Consent: A ubiquitous, high‑assurance credential lets patients authorize data‑sharing in seconds, boosting API utilization and care coordination.

• Improved Cybersecurity: Centralized credential providers achieve economies of scale in fraud analytics, MFA, and FedRAMP compliance, reducing the overall attack surface.

• Portability Across Payers: A single subject identifier enables deterministic patient matching and reduces costly record‑linking errors.

TD‑3(b): Impact of Requiring Certified Digital Identity

The impact of requiring certified digital identity would profoundly impact the adoption and utilization of patient access.

From our experience managing consent across 350+ payers, we consistently see patients struggle with identity systems. Each payer has its own credentialing process, often based solely on passwords. The result:

• High abandonment rates
• Support volume for login issues
• Credential-stuffing vulnerabilities

Worse, inconsistency leaves gaps for fraud while hindering legitimate patient access. Requiring IAL2/AAL2 credentials from certified Credential Service Providers (CSPs) (e.g., Login.gov, CLEAR, ID.me) would allow:

• One secure login across all payers
• Reduced login friction and abandonment
• Consistent audit and fraud monitoring

TD-14: Network Infrastructure for FHIR API Ecosystem Development

In response to 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)?

CMS currently relies on payer goodwill for compliance with CMS-9115-F. This has led to fragmented results:

• Only 41% of payers achieved >95% auth success
• Over 10 million Medicaid members lack access due to non-compliance
• 19 Medicaid FFS programs have no Patient Access API, and when we do cold outreach, have been met with responses like the below direct quotes:

We did meet with state representatives over a year ago and they were adamant that they were not ready to engage.

— From a vendor of a state implementing this April 2025

The Interoperability and Patient Access solution continues in development. The current go-live date is now September 2025.

We have had it turned off while not having any traffic on it.

— From a Medicaid Agency employee earlier in 2025

In some cases, payers that implemented CMS-9115-F have since switched vendors, restarting implementation entirely from scratch. This cycle adds delay, cost, and complexity.

CMS must move from voluntary reporting to structured enforcement:

• Regular public audits and scorecards
• Financial consequences for non-compliance
• CMS-led reference implementations (e.g., Medicare-MA data sharing)
• Required use of standardized test suites (e.g., Inferno)

TD-16: Network Infrastructure vs. Point-to-Point Connectivity

In response to 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)?

Flexpa's direct integrations with plans covering over 90% of U.S. lives demonstrate the cost of point-to-point connectivity. Each integration took extensive custom work due to:

• Payer-specific OAuth implementations
• Unique FHIR guide interpretations
• Custom data formatting and error handling
• Ongoing support and monitoring requirements

This model favors large players who can absorb these costs. Smaller innovators cannot compete. Shared infrastructure reduces:

• Implementation and maintenance cost
• Developer onboarding time
• Data inconsistency across payers

We recommend CMS encourage hybrid models that permit both direct and shared-network access. Certified network operators should be subject to quality standards and eligible for streamlined compliance.

TD-18: Addressing Information Blocking for Payers

In response to 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?

Today, payers are not covered under 45 CFR Part 171, even though they play a crucial role in data access. We routinely see behaviors that would be penalized if performed by providers:

• Opaque connection approval policies
• Developer registration loops without resolution
• Non-responsiveness to support tickets
• Arbitrary rate limits and short token refresh periods
• Data omissions without notification

Some payers never launch required APIs. Others implement them but break functionality with no developer notice. Troubleshooting support is often nonexistent.

CMS should extend information blocking provisions to payers under CMS-9115-F and CMS-0057.

We also observe widespread confusion and lack of payer education:

• In one March 2025 case, a payer representative accused our team of malicious activity and questioned how we contacted a member. When we showed the member request and provided contact information, the payer claimed the member "had no idea who Flexpa was." While this may be true as members may not be aware our application name, we are unsure how the payer may have represented the situation given their approach towards us in the first place.

• Customer support staff often refer patients back to the member portal, having never heard of the Patient Access API. Members lack shared terminology to describe their experience and can't advocate for themselves without shared language.

• We hear recurring questions: "Why can't they just use the portal?", "Who uses this?", "What is a refresh token?"

• When troubleshooting, payers are unsure how the rest of the workflow looks and ask us: "What else could block login besides password?" These illustrate a deeper need for education among those tasked with implementation.

CMS should provide payer education incentives and tie implementation success to tangible performance metrics.

Conclusion

The path from CMS-9115-F through CMS-0057 and beyond requires sustained focus on implementation quality, meaningful enforcement, and patient-centered design. Current challenges in API implementation quality, compliance gaps, and information blocking practices threaten to undermine the transformative potential of healthcare interoperability initiatives.

As the leading network for patient-consented health data access, Flexpa is committed to working with CMS, payers, and the broader healthcare ecosystem to realize the full potential of interoperable health data. We believe that addressing the implementation quality issues we have identified, expanding enforcement mechanisms to include payers, and investing in shared network infrastructure will accelerate progress toward a truly patient-centered digital health ecosystem.

We appreciate the opportunity to provide input on this critical initiative and look forward to continued collaboration in advancing patient access to health information.

---

Sincerely,

Andrew Arruda – CEO, Flexpa
Angela Liu – Head of Design, Flexpa