Ask payers what is holding up CMS-0057 and the answer is rarely FHIR. It is that a large share of the data the rule requires them to serve does not sit in systems they operate.
The structural problem
Utilization management is frequently delegated. Pharmacy sits with a benefit manager. Behavioural health, radiology, dental and vision are often carved out to specialists. Each of those arrangements exists for good operational reasons, and each one means prior authorization decisions are made, and stored, somewhere other than the payer's core platform.
The rule does not care about that arrangement. The payer is accountable for the API regardless of who holds the data.
Why it is harder than an integration ticket
You may not have the contractual right to the data in the form you now need it. Delegation agreements were written around operational reporting, not real-time member-level retrieval by a third-party application. Amending them takes legal time, and legal time is not compressible by engineering capacity.
Your vendors are not all on the same timeline. A large UM vendor serving many payers may have a FHIR roadmap. A regional carve-out serving a handful may have none, and no commercial reason to build one for you alone.
Latency expectations differ. A nightly file was fine for oversight reporting. An API answering a member request in real time is a different engineering commitment, and some vendors will simply not meet it initially.
The number of relationships multiplies. A payer with several lines of business across several states can have dozens of delegated arrangements. This is a programme, not an integration.
Four workable patterns
1. Direct pass-through
Your API calls the vendor's API in real time. Cleanest data freshness, and it makes your compliance dependent on their uptime. Viable only where the vendor is capable and contractually committed to a service level.
2. Aggregation store
Vendors feed authorisation data into a store you operate; your API serves from it. You control availability and latency, at the cost of running a synchronisation pipeline and accepting some data lag. In practice this is the most common answer for payers with many delegated relationships, because it decouples your compliance from each vendor's uptime.
3. Federated query with a cache
Query the vendor live, cache the result, serve from cache when they are unavailable. A middle path that adds real complexity around invalidation — worth it when freshness genuinely matters and vendor reliability varies.
4. Bring the function back in-house
Occasionally the honest answer. If a carve-out is small, unwilling to build, and the delegation is not delivering much beyond the data problem, insourcing may cost less than the integration programme around it.
Start with the contracts, not the architecture
The sequencing mistake is designing the integration before establishing that you are entitled to the data and that the vendor is obliged to provide it. Do these first:
- Inventory every delegated arrangement that touches prior authorization, across all lines of business. Most payers find more than they expected.
- Read each agreement for data rights and any service levels attached to data provision. Note what is missing rather than assuming it is implied.
- Ask each vendor for their roadmap, in writing, with dates. The answers sort your vendors into three groups quickly.
- Amend where needed, and start early — this is the long-lead item in the entire CMS-0057 programme.
Only then choose the pattern per vendor. It will not be the same pattern for all of them, and that is fine.
Why it is worth doing properly
Beyond compliance: a single place where all authorisation activity across every delegated arrangement can be seen is genuinely useful. Most payers do not have that today, and building it for the rule gives you an operational asset — for oversight, for member service, and for automating the next thing.
Bear in mind too that nobody certifies this work. If a delegated relationship is not delivering data, that is your finding, not your vendor's.
Nirmitee builds and tests FHIR APIs for payers and health-tech platforms. Our healthcare interoperability team runs readiness assessments, Implementation Guide builds and conformance-testing engagements; for the platform side see our healthcare software product engineering practice. Talk to our team.
