Find out what your FHIR surface is missing, before the CMS deadline does.
The Readiness Layer takes your live FHIR endpoint, probes it across the resource categories the CMS Interoperability and Prior Authorization rule expects (demographics, coverage, conditions, medications, labs, allergies, encounters, procedures, diagnostic reports), and hands back exactly which ones respond and which ones do not, ranked required-first, with a verdict that only reads ready when nothing required is missing. Not a slide that says you're compliant. A worklist.
Book a readiness scan See a sample gap report
THE PROBLEM
Almost everyone impacted by CMS-0057-F has the same shape of problem, a live FHIR endpoint, a compliance date, and no mechanical way to say which of the required resource categories the endpoint actually serves today. The comfortable answer is "our vendor says we're FHIR", and the honest answer is usually "we think so". So the holes stay invisible until the worst possible moment, when an attestation, a partner integration test, or a regulator asks "show me coverage across the required resources" and the true answer turns out to be a shrug. The API compliance date lands January 1, 2027, but the build-and-test window is 2026, which makes this a this-year board problem, not a next-year one.
HOW IT WORKS
The Readiness Layer runs one read-only probe per required resource category, and it fails closed. It asks your FHIR surface for each category the rule leans on (Patient demographics, Coverage, Conditions, Medications, Observations for labs and vitals, Allergies, Encounters, Procedures, DiagnosticReports), and it records which categories answer and which do not. A category that errors, or does not respond, is reported as missing, never quietly counted as present. The readiness verdict is true only when zero required categories are missing, so a partial surface can never read as a finished one. Everything is read-only (we are checking what your endpoint exposes, we are not writing to it, and every probe is de-identified at dispatch).
WHAT YOU GET (the gap report)
- present: the required resource categories your FHIR surface actually answers, confirmed by a live probe, not by a vendor claim, - missing: the ranked worklist, required categories first, so your integration team knows exactly what to wire next, - readiness percentage: how much of the expected set responds today, - and one fail-closed ready verdict, green only when nothing required is missing.
A report your interoperability team can work down and your compliance lead can actually put their name on, not a dashboard you have to take on faith.
WHO IT'S FOR
Payers and their health-IT and interoperability vendors carrying the CMS Interoperability and Prior Authorization Final Rule (Patient Access, Provider Access, Payer-to-Payer). Digital-health and provider-org integration teams who inherited a FHIR endpoint and now have to prove USCDI resource coverage. Anyone whose "we're FHIR-compliant" has to survive a diligence review instead of a friendly nod.
PRICING
Three tiers, and the prices are hypotheses we're validating, not commitments carved in stone.
- Readiness scan: one read-only assessment of your FHIR surface, the ranked gap worklist plus a fail-closed ready verdict against the expected-capability checklist. - Subscription: continuous readiness as your endpoint and the rule evolve, re-run on a cadence, surfacing newly-missing categories ahead of the compliance date. - Platform: the fail-closed readiness gate wired into your interoperability pipeline, so an incomplete FHIR surface can't be attested as ready.
PROOF (the dogfood)
We run this on ourselves before we ask you to trust it. AYA points the same ten FHIR probes at its own test surface, scores the responses against the CMS-0057-F checklist carried in the product manifest, and reads back which categories answer. The deliverable is a real pattern on disk (an L3 span that composes ten real FHIR search-and-read atoms, every reference resolving, scored at PQS grade B), and those atoms route through the execution-wired healthcare adapter. So the assessment you would buy is the assessment we run on our own endpoint, measured the same way, fail-closed.
HONEST NOTE
This product assesses readiness, it does not stand up your endpoints. That distinction matters, so read it plainly. AYA's FHIR capability today is search and read only. There is no live Prior-Authorization submission (no PAS, CRD, or DTR), and the prior-auth pieces you may have seen elsewhere in AYA are demo and sandbox only. So the Readiness Layer tells you, precisely and fail-closed, which required resource categories your surface is missing, and it does not pretend to close those gaps for you or to submit a prior authorization on your behalf. If your need is "tell us exactly where we stand", this is built for that. If your need is "build and run the compliant Prior-Auth endpoint", that is a different, code-heavy piece of work we would scope separately and honestly, not something this deliverable quietly claims. And the live customer run needs your linked FHIR account and a booted mesh, which is why the readiness grade is wired-needs-creds, not shipped.
*This page is a specification. The capability it describes is not built yet, and nothing here is a claim that it runs today.*