Readying your health plan for CMS-0057 compliance is a real technical and operational lift. Whether your team built the required FHIR infrastructure in-house or partnered with a vendor to get there, achieving compliance has been framed as the goal. The thing you were working toward.
But there’s a question that doesn’t get asked enough at build time: what happens the moment your CMS-0057 APIs go live?
Going Live Is the Starting Line, Not the Finish Line.
Once your endpoints are open, a new set of operational demands kicks in. The work doesn’t go away. It compounds.
Here’s what your team inherits the moment your CMS-0057 APIs go live:
Third-party vetting and onboarding. Every payer, provider, third-party application, and vendor that wants to connect to your APIs needs a way to register and request access, and someone needs to vet and approve them before they’re in. Who owns that process? Who manages the process when something changes on their end? This is the operational reality behind all of the CMS-0057 APIs.
Network development and connectivity. Vetting the parties who show up to register is only half the problem. Someone also has to proactively find and connect to the parties who haven’t registered yet, not just stand up a portal and wait. This applies across all four APIs, but it’s most pronounced for Payer-to-Payer Data Exchange: payers must respond to a member’s request within seven days of enrollment, which isn’t enough time to build a connection from scratch. The connection has to exist before the member enrolls, not after. This requires an active, managed network to function at compliance scale.
Regulatory workflow management. Each CMS-0057-F workflow has its own multi-step logic that has to run correctly, end to end. Payer-to-Payer Data Exchange, for example, has to confirm member consent, identify the member’s prior payer, then pull in and consolidate that member’s data. Provider Access has to confirm which providers are authorized to see a given member’s data, give members a way to opt out of having their data shared, and the ability to filter cost and remittance data. None of this logic is static. It has to be maintained as the ecosystem evolves.
Compliance reporting. CMS reporting requirements vary by API. Patient Access has annual API usage reporting requirements. Prior Authorization requires publicly reporting approval and denial rates, appeal outcomes, and average decision times across all covered items and services. Provider Access and Payer-to-Payer Data Exchange don’t have CMS reporting requirements yet — though that will likely change with future regulations. Either way, this work falls to someone internally unless it’s explicitly outsourced.
Regulatory change absorption. CMS-0057 is a finalized rule, but the regulations governing these workflows keep evolving. CMS-0057 itself changed Patient Access requirements that were originally set under CMS-9115. CMS-4208 changed Provider Directory requirements, also amending CMS-9115. And the proposed CMS-0062 rule would change Prior Authorization requirements under CMS-0057 once finalized. Tracking which rule governs which workflow — and adapting as new rules land — is an ongoing program, not a one-time project.
None of this is a knock on what you’ve built. These demands exist regardless of whether your FHIR infrastructure was built in-house or by a vendor. They’re the compliance layer, and they live above the infrastructure layer. They’re fundamentally a different kind of work.
Technical Compliance vs. Operational Readiness
There’s a meaningful gap between being technically compliant (CMS-0057 APIs live, endpoints accessible) and being operationally ready to exchange data at scale.
Most plans underestimate the network piece. Having an API that can receive connections isn’t the same as having an active, maintained network of payers, providers, third-party apps, and vendors who can actually exchange data with you. Building and sustaining that network, including point-to-point integrations, EHR connectivity, UM vendors and clinical tool integrations, is its own ongoing effort. It’s what separates plans that are technically compliant from plans that are truly ready.
The plans that are furthest ahead on CMS-0057 aren’t the ones whose APIs went live first. They’re the ones answered the harder question early: who owns the operational program that runs on top of the infrastructure?
Closing the Gap Without Rebuilding
A managed compliance layer doesn’t replace what you’ve already built. It extends it. Instead of your team absorbing third-party vetting, regulatory workflow logic, and compliance reporting internally, an outside partner runs that operational program on your behalf, including keeping pace with CMS as requirements evolve. The result is that your CMS-0057 APIs run as a sustainable compliance program, not a one-time build, with infrastructure to support them long past go-live.
The CMS-0057 January 1, 2027 Deadline Is Fixed
The enforcement deadline isn’t moving, so this question isn’t theoretical. If your in-house build or your vendor stops at standing up the APIs, everything else will all fall on your team and the runway to staff up for that is shrinking.
The plans that will come out ahead are the ones who decided early that the compliance layer wasn’t something their team should own and found a partner to run it instead.
1upHealth’s CMS-0057 suite, powered by the 1up Gateway, is that managed compliance layer for health plans with existing FHIR infrastructure. It connects to what you’ve already built, so your team doesn’t have to own the operational load of compliance. Learn more →
