· ReadyStack
Worked example
Real numbers from this tool, line by line.
A Medicare Advantage payer's FHIR CapabilityStatement - the file the CMS Interoperability and Prior Authorization rule (CMS-0057-F) is read against - returned 6 blocking gaps and 107 days left when checked on 16 September 2026. The file was valid, and had been since 2021, which is the problem.
The four APIs, and the date
CMS-0057-F applies to Medicare Advantage organizations, state Medicaid and CHIP programs, and QHP issuers on the federal exchanges. By 1 January 2027 they must run four HL7 FHIR R4 APIs:
- Patient Access API, expanded to include prior authorization requests and decisions, drugs excluded
- Provider Access API, sharing member data with in-network providers
- Payer-to-Payer API, handing a member's history to their new plan
- Prior Authorization API, answering with an approval, a denial with a specific reason, or a request for more detail
From 1 January 2026 the same rule requires prior authorization decisions within 72 hours for expedited requests and 7 calendar days for standard ones.
The CapabilityStatement your server publishes at /metadata is the machine-readable claim that those four APIs exist.
What a 2021 statement looks like now
The shape most payer servers are still in, built for the 2021 rule (CMS-9115-F) and never revisited:
{"resourceType":"CapabilityStatement","date":"2021-07-01","fhirVersion":"4.0.1",
"rest":[{"mode":"server","resource":[
{"type":"Patient"},{"type":"Coverage"},{"type":"ExplanationOfBenefit"}]}]}Run the 14 rules over it: 10 findings, 6 of them blocking:
ERROR us_core_profiles No US Core profile is referenced anywhere
ERROR tls_endpoints A plaintext http:// endpoint is declared
ERROR patient_access_prior_auth No ClaimResponse resource is declared
ERROR prior_auth_submit No Claim $submit operation is declared
ERROR provider_access_export No bulk $export operation is declared
ERROR payer_to_payer_match No $member-match operation is declared
INFO deadline_clock 107 days left until 1 January 2027Three of the four required APIs have no surface in this file, and the fourth cannot show a member their prior authorizations.
Why the validator said yes
A generic FHIR validator calls that file valid, and it is right to: a validator reads the FHIR R4 schema, not the Federal Register. Schema-valid is the normal state of a payer server missing Claim $submit, Group $export and $member-match: nothing in the schema knows what 1 January 2027 is.
The 14 rules
fhirVersion 4.0.1. US Core R4 profiles. SMART App Launch and OAuth 2.0 security. TLS-only endpoints. ExplanationOfBenefit and ClaimResponse inside Patient Access. Claim $submit and $inquire. $questionnaire-package. Group $export for Provider Access. $member-match for Payer-to-Payer. A statement date that is not stale - the sample one is 1903 days old. And a clock that stays quiet until a blocking gap is open.
Change the date and the answer changes. The same file on 15 January 2027 reports the compliance date passed 14 days ago; a statement halfway through the work reports 2 blocking gaps on 31 December 2026, with 1 day left.
Where it runs
The same engine runs as a VS Code extension over any CapabilityStatement in your workspace, and as one page in the browser. Every check is free and needs no key - all 14 rules, every finding, every file. The full version exports the audit as a dated Markdown and CSV gap report for the compliance file.
A payer interoperability readiness review is commonly quoted as a five-figure engagement. This clears the mechanical gaps first.
15 seconds — what it actually does
Questions people ask
What does CMS-0057 API Gate actually do?
It reads a FHIR CapabilityStatement as you edit it and reports, line by line, which of the four CMS-0057-F APIs it cannot yet stand as evidence for: Patient Access, Provider Access, Payer-to-Payer and Prior Authorization. 14 rules run, and a clock shows the days left to 1 January 2027.
Who is it for?
Health IT engineers at Medicare Advantage organizations, state Medicaid and CHIP programs, and QHP issuers on the federal exchanges, plus the FHIR vendors building those servers. If your team owns the /metadata endpoint that CMS-0057-F will be judged on, this is your file.
Why is a free FHIR validator not enough?
A generic FHIR validator calls this file valid, because it checks the statement against the FHIR R4 schema, not against a federal rule. Schema-valid is the normal state of a payer server that is still missing Claim $submit, Group $export and $member-match. The rule, not the schema, is what CMS reads.
What is free and what costs money?
Every check is free and needs no licence key: all 14 rules, every finding, every file, no limit. The paid tier changes who holds the result, not how much you can see. $29 once exports the same audit as a dated Markdown and CSV gap report with one row per gap and its CMS-0057-F citation.
What would this cost otherwise?
A payer interoperability readiness review from an interop consultancy is commonly quoted as a five-figure engagement. This extension does not replace that review; it removes the mechanical gaps before you pay for one, so the consultant reads the hard questions instead of your missing operations.
Why not just ask ChatGPT or another AI chat?
A general AI chat answers from training data with a cutoff date, cannot read your repository and names no rule version. FHIR API Gate - CMS-0057 prior authorization (Da Vinci) checks the file you open against 14 rules from a rule set dated 2026-09-20, and points at the exact line. For a filing, an audit or a client you need that dated result on your own files.
Ask about this tool
One question, answered by the person who built it. Your email only if you want the answer sent.