ONC awarded The Sequoia Project its next TEFCA RCE option year with a 15%-plus funding increase, on numbers that look like escape velocity: 11 QHINs, 23,000-plus organizations, 100,000-plus sites, 1.5 billion documents. Payers face a January 1, 2027 deadline for four FHIR APIs under CMS-0057-F. These are different problems with different stacks, and nothing in CMS's rule treats participation in one as compliance with the other.
Two things happened this month that will get conflated in budget meetings, so let us separate them now, with about four months left on the clock.
On August 17, The Sequoia Project announced that ONC awarded it the next option year as Recognized Coordinating Entity for TEFCA, with a more than 15% increase in funding under the existing contract. The accompanying numbers are the kind that make a slide: more than 1.5 billion documents exchanged since go-live in December 2023, more than 100,000 sites nationwide sharing patient data, and-the figure that matters for architecture planning-11 QHINs representing more than 23,000 organizations, with more in onboarding.
Note the distinction between sites and organizations, because the two are being used interchangeably in coverage of this release and they are not the same number. 23,000 organizations. 100,000-plus sites those organizations operate.
The second thing is not news; it is a date. CMS-0057-F compliance dates begin generally on January 1, 2027, and on that date impacted payers-MA organizations, state Medicaid and CHIP FFS programs, Medicaid and CHIP managed care entities, and QHP issuers on the FFEs-owe four things: prior authorization information added to the Patient Access API, a Provider Access API, a Payer-to-Payer API, and a Prior Authorization API.
The question a CIO or integration lead should be asking is how much of that second list the first list absorbs. The honest engineering answer is: close to none of it.
TEFCA is a trust and governance framework with a document-exchange heritage. The 1.5 billion figure is documents, and the operative unit of most TEFCA traffic remains query-and-retrieve against a defined set of exchange purposes: treatment, government benefits determination, public health, healthcare operations, payment, and individual access services. It answers "who has records on this person and can I lawfully get them," and it answers it across organizational boundaries that previously required bilateral agreements.
CMS-0057-F is a payer API mandate with a transactional heritage. The Prior Authorization API is not a records-retrieval problem. It is a workflow problem: determine whether prior authorization is required for a specific item or service, identify the documentation the payer requires, submit the request, and receive the determination-from inside the EHR. That is Da Vinci territory-coverage requirements discovery, documentation templates and rules, and the prior authorization support transaction-running against a specific payer's endpoint with that payer's rules attached.
You cannot satisfy a Prior Authorization API obligation by being a TEFCA participant. There is no CMS language anywhere in the rule or its guidance that treats TEFCA participation as compliance with any -0057 API requirement, and the two obligations do not even attach to the same parties in the same way.
The one place the two tracks genuinely intersect is consumer-directed access, and that intersection got concrete on August 3, 2026, when the updated Individual Access Services Exchange Purpose Implementation SOP v3.0 took effect.
Two things in v3.0 are worth an implementation lead's attention.
First, the FHIR on-ramp. The SOP describes an approach for IAS Providers to retrieve either a FHIR Endpoint or FHIR Resources depending on the capabilities of the Responder-explicitly an incremental-adoption design, meeting responders where they are while pushing toward FHIR as more organizations stand up APIs. That is a pragmatic spec decision and it tells you something about the state of the field: the RCE is not assuming its responders have FHIR APIs, in 2026, four months before payers must have four of them.
Second, the consent architecture changed. Version 3.0 removed references to "TEFCA IAS Consent" workflows and the associated patient matching methodologies, while retaining the Responder's ability to verify third-party requests for access and use of data. The AHA had asked for a delay of the IAS SOP on patient privacy grounds.
If you are running provider-side integration, that responder-verification retention is the operative sentence. It means a third-party app request arriving under IAS is still something your organization gets to check, and that check is a workflow you have to staff or automate. It is also the thing most likely to be conflated with the -0057 Patient Access API, which is a payer obligation with its own identity and authorization stack and no TEFCA governance attached at all. Both put clinical data into a consumer's chosen app. They share almost nothing below that sentence.
Look at what the RCE reported for the contract year, because it describes the maturity stage more honestly than the growth numbers do: two additional QHINs designated, 13 new policies published, more than 100 stakeholders engaged across more than 100 meetings, and a new "TEFCA Topics in Change Management" page where draft policies under consideration can be previewed and commented on concurrently.
That is a governance body doing governance work. Sequoia CEO Mariann Yeager framed the year ahead around "network integrity, advancing new use cases, and supporting continued growth"-in that order, with integrity first. A network that has grown from single-digit thousands of organizations to 23,000 in a year has an integrity problem before it has a scale problem, and the funding increase reads as an acknowledgment of that.
None of which produces a Payer-to-Payer API for you.
For provider-side teams, TEFCA growth is straightforwardly good and mostly free: more responders reachable through one framework, fewer bilateral agreements, an expanding IAS path. Track the IAS verification workflow and otherwise let it accrue.
For payer-side teams, the risk is specific and it is a planning risk, not a technical one. If your -0057 program plan has a line anywhere in it that reads like "leverage existing network participation," find out this week whether that line refers to actual reusable infrastructure-an identity provider, a consent store, a member-matching service, a FHIR facade already in production-or whether it refers to the fact that your organization is in a TEFCA participant list. The first is real leverage. The second is a slide.
Four months out, the difference between those two is the difference between a delivery date and a disclosure.
What, concretely, does your -0057 program plan reuse from your TEFCA footprint-and can the engineer who owns it name the component?
Discover how Addie helps health systems, post-acute providers, and payers improve throughput, reduce avoidable days, and deliver better transitions of care.
Get Started
