Most payers built a Patient Access API years ago under CMS-9115. It is live, it returns valid FHIR, and it passes a smoke test. The uncomfortable finding, repeatedly, is that it returns very little of what the rule expects — and CMS-0057 both extends the requirement and raises the attention it will get.
The pattern
Independent analysis of production Patient Access endpoints has repeatedly found the same shape: a large number of authorisations retrievable in principle, and a very small number of members for whom a genuinely complete history comes back. The endpoint works. The data behind it is thin.
This happens for an understandable reason. The original build was scoped as an API project against a compliance date, and the API was delivered. What was not delivered was the harder half — assembling adjudicated claims, encounters, clinical data and authorisations from systems that were never designed to hand them over on demand for an individual member.
Four gaps worth checking this quarter
1. Claims history that stops short
The requirement is adjudicated claims and encounter data going back years, not a recent window. Many implementations quietly return whatever the operational claims store holds online — often a rolling period — because that is what was reachable without touching the data warehouse. The fix is unglamorous: an extract path to archived adjudicated claims, which is a data-engineering task rather than an API one.
2. Prior authorization data that is absent or empty
CMS-0057 extends Patient Access to include prior authorization information — active authorisations and recent history, excluding drugs. If your authorisations live in a utilization-management system operated by someone else, an empty array is what your API will return unless you have built the path to retrieve them. That is the delegated-entity problem, and it is the most commonly reported blocker in the whole programme.
3. Clinical data that was never connected
Where you hold clinical data, it belongs in the response as USCDI content. Payers hold more of this than they assume — lab results from care management, assessments, risk-adjustment source documents. It is frequently absent simply because nobody mapped it.
4. Authentication and app onboarding that discourages use
The rule anticipates third-party applications connecting on a member's behalf. Registration processes that take weeks, are undocumented, or are practically manual are a compliance concern rather than a security posture — and they are visible to anyone who tries.
How to find out where you stand
The fastest honest assessment is not a document review. Take twenty real members with known histories — a chronic condition, a recent admission, a completed prior authorisation — and pull each one through your own API as a third-party app would. Compare what comes back against what you know exists.
That exercise takes a couple of days and tends to end the debate. It also produces exactly the artefact you want in an evidence pack: a dated, reproducible test with findings and a remediation plan.
Why this matters more under CMS-0057
Three reasons. The scope grew, so an implementation that was arguably adequate before now has a new category of data it must serve. Attention grew, because prior authorization metrics are reported publicly and invite comparison. And there is no certification to hide behind — the duty is to test and monitor, so a thin API that was never re-examined is a weak position.
Sequencing the remediation
- Measure first with the twenty-member exercise. Assumptions about your own data are usually generous.
- Close the claims history gap next. It is the largest volume of missing data and the most mechanical to fix.
- Then the authorisation path, which usually means contracts and connectivity with delegated entities and therefore has the longest lead time.
- Clinical data last, since it is genuinely optional in scope but improves the response meaningfully where you hold it.
None of this is exciting work. It is, however, the difference between an API that exists and an API that complies.
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.
