In brief: CMS does not certify payer APIs; payers attest. Readiness is shown with an evidence pack: Inferno test-kit reports, end-to-end runs on public sandboxes, EHR-side runs, connectathon results, metrics computed from test traffic and security evidence. This post describes each public environment (HL7 Foundry, Inferno, Acentra Health, Epic's template apps), what each proves and does not prove, the access prerequisites, and an illustrative eight-week schedule to assemble the pack.
There is no CMS certification for CMS-0057-F. A payer attests that its APIs meet the rule; ONC certifies the EHR side under HTI-4; nobody stamps the payer. That is a problem for a compliance officer who needs to show a board that the plan is ready, and for a vendor that needs to show a buyer the same thing. The answer is an evidence pack: reproducible results from the public test environments, in a form anyone can re-run.
Our earlier posts on testing a FHIR implementation with Inferno and proving CMS-0057 compliance without a certification program set the scene. This post lists the environments that exist as of September 2026, what each one proves and does not prove, what it takes to get access, and how the results assemble into a pack over eight weeks. It closes the series that began with the rule itself and covered CRD, DTR, PAS and the architecture.
What an evidence pack contains
- Conformance reports. Inferno run reports for each guide and version the plan claims: CRD, DTR, PAS, PDex (Payer-to-Payer and Provider Access), CARIN Blue Button, Plan-Net, plus the SMART App Launch and Bulk Data kits. Each report names the test suite version, the endpoint, the date and every pass and fail.
- End-to-end runs. Recorded flows on a neutral sandbox, showing a CRD hook, a DTR package populating, a PAS submit pended and then decided by subscription, with timings.
- EHR-side runs. The same flows fired from Epic's sandbox through its template apps, and from Oracle Health's or MEDITECH's where the plan's network needs them.
- Connectathon results. Which track, which partners, what passed, what was fixed.
- Metrics from test traffic. The public measures (the percentage and timing metrics the rule defines) computed from the engine's data mart on synthetic requests, proving the mart and the queries before real data arrives.
- Security evidence. Token validation, mutual TLS between payers, consent enforcement at execution, the rule that EHR tokens are never forwarded to delegates.
- Endpoint publication. The public endpoint list in the format CMS-0062-P proposes, ready for the sixty-day filing.
Everything in the pack should be re-runnable by the reader. A screenshot is not evidence; a suite id and a run id are.
The HL7 Foundry Burden Reduction bundle
The Da Vinci program publishes its reference implementations as one Docker Compose bundle on the HL7 Foundry. It runs:
br-payer, the payer reference server for CRD, DTR and PAS;br-providerandtest-ehr, a provider-side FHIR server seeded with synthetic patients;crd-request-generator, a small web app that fires hooks and shows the cards;dtr, the reference SMART DTR app;prior-auth, the PAS reference server with subscriptions;CDS-Library, the CQL and questionnaire content;- Keycloak for identity.
Access: public GitHub under HL7-DaVinci; a free VSAC key from a UMLS account is required because the CQL expands value sets at runtime.
What it proves: that your understanding of the flow is right and that your own facades can replace each reference component one at a time. Point crd-request-generator at your CRD; point the reference DTR app at your $questionnaire-package; send the reference app's bundles to your $submit.
What it does not prove: conformance. It is a working example, not a test oracle, and it lags the guide versions.
The Inferno test kits
ONC's Inferno framework hosts Da Vinci kits for CRD, DTR, PAS and PDex, with suites for the 2.0.1 versions and the current 2.2 versions at the time of writing, alongside the US Core, SMART, Bulk Data, CARIN and Plan-Net kits the access APIs depend on. Check the kit catalog for current suite versions.
Access: hosted at inferno.healthit.gov for endpoints reachable from the internet; self-hosted with setup.sh and run.sh from the GitHub repositories for anything behind a firewall. Client suites test your EHR-side or SMART app; server suites test your payer endpoints.
What it proves: a documented subset of each guide's requirements. Every kit publishes the requirements it covers, and the coverage is not exhaustive, so keep a requirement-to-test matrix and collect manual evidence for the gaps. A passing report is strong public evidence for a payer, but it is not a compliance certification; ONC's certification program for EHRs uses Inferno for the criteria it tests.
What it does not prove: behavior under real EHR context, timing at load, content quality in questionnaires, or that a subscription notification reaches a provider's endpoint. Those need the other environments.
Profile validation checks structure; conformance tests cover their documented requirements; integration tests exercise partner workflows; operational tests examine load and recovery. These are complementary kinds of evidence.
Acentra Health's sandbox
Acentra, a utilization-review contractor for Medicaid programs and Medicare, runs a public sandbox on synthetic data at sandbox.mhbapp.com. As of this writing its documentation lists CDS services for all six CRD hooks under /priorauth/api/v1/cds-services/*-crd, DTR $questionnaire-package, and PAS $submit and $inquire, with a 10 MB request cap and a pended-then-decided flow. Confirm the current list on its documentation before planning around it.
Access: three registration lanes, for vendors, EHRs and payers. Registration is by form; keys arrive by email.
What it proves: that your provider-side or intermediary code works against a payer that is not you, on the real operations with real timing. For a plan, it is the model of what a review contractor expects to receive.
What it does not prove: adaptive DTR ($next-question is not exposed), subscriptions, or anything about the access APIs.
Epic's "CMS Prior Auth" template apps
Epic on FHIR publishes template apps under the use case "CMS Prior Auth." Each template lists the scopes and hooks the app type needs, so registering one gives you a sandbox client that already has the right permissions.
- The payer-side clinician app template lists read, search and update on ServiceRequest and MedicationRequest, read and search on Appointment, Coverage and Patient, and outgoing "CRD Request" and "CDS Hooks Framework."
- The DTR-side template lists Questionnaire and QuestionnaireResponse read, search and create, the clinical resources CQL reads, and SMART launch context.
Access: a free Epic on FHIR developer account; sandbox registration is self-service. A registered client does not by itself prove a runnable CDS Hooks or native DTR workflow: the service still has to be configured in the sandbox, and connecting to a customer's production Epic needs that customer's approval, Epic's review, and their configuration of your service URL and prefetch.
What it proves: that your CRD service is called the way Epic calls it, with Epic's context and prefetch behavior, and that your DTR client or packages work in Epic's sandbox. Epic announced on 17 August 2026 that CRD checks were live with three payers and more in testing, and its release documentation says the February 2026 build does not follow Da Vinci 2.1 exactly; the differences are what this sandbox will show you.
What it does not prove: Oracle Health, MEDITECH or athenahealth behavior. Register for those sandboxes too if your network needs them; the CDS Hooks context handling differs.
Other places to look
- CMS's PCG-FHIR pilot. Medicare fee-for-service review contractors accepting FHIR prior-auth requests over esMD; contact published by the pilot team. Useful for a payer that wants to see a government reviewer consume PAS.
- HL7 connectathons. The Burden Reduction track runs three times a year. At the July 2026 CMS connectathon the failures were unbound SMART launch contexts, null-versus-absent hook keys and CapabilityStatement mismatches. None of them are in a kit; all of them are in a connectathon.
- Flexpa's endpoint monitor and the Da Vinci implementation tracker. Not test environments, but the public record of which payer endpoints are up and which vendors claim which guides. Your endpoint will be on the first list from the day it is published.
- WSO2's reference implementation and the CMS Blue Button, BCDA and DPC APIs. Working examples of the access API patterns, useful for comparison when your Provider Access or Payer-to-Payer design is under review.
Eight weeks to an evidence pack (an illustrative schedule)
This schedule assumes the facades already exist, the licenses are obtainable in the first fortnight, and sandbox registrations are approved on their usual timelines. Adjust it to your scope.
- Weeks 1 and 2. Foundry bundle running; Inferno kits self-hosted; VSAC and X12 licenses; Epic, Oracle Health and Acentra registrations filed. First CRD Inferno run against the facade, expected to fail, to establish the baseline.
- Weeks 3 and 4. CRD and DTR suites passing; first questionnaires populating in the reference DTR app and in Epic's sandbox; PAS
$submitpassing bundle validation. - Weeks 5 and 6. PAS suites passing including subscriptions to your own rest-hook receiver; end-to-end runs on Acentra; PDex Payer-to-Payer sequence against a second sandbox payer; Provider Access bulk export under Inferno's Bulk Data kit.
- Week 7. Connectathon or a bilateral test with one partner payer and one provider organization; metrics computed from all test traffic; security evidence collected.
- Week 8. Pack assembled: reports, run ids, recordings, connectathon notes, metrics, security, endpoint list. Reviewed by compliance; handed to the board or the buyer.
The pack is not a one-off. Re-run it on every release, and re-run the 2.2 suites when the proposed CMS-0062-P versions become mandatory.
Reading an Inferno report
An Inferno run produces a report with a suite, a version, a run id, and a tree of test groups, each pass, fail, skip or omit. For a buyer or a board, three things in it matter.
- The suite version. A report against the 2.0.1 suite proves conformance to an expired version. CMS names 2.1.0 for 2027; the 2.2 suites are what CMS-0062-P would require. Run both current suites and say which.
- Skips and omits. A skipped group usually means an optional capability was not attempted, such as adaptive questionnaires or the what-if hook. List every skip and say whether it is by design.
- Fails with explanations. A failing test with a written reason and a fix date is stronger evidence than a report with fails hidden. Payers that publish their fails and close them are the ones EHRs trust.
Keep every report, not just the last one. The history of runs shows the program's trajectory, which is what a reviewer with no certification to lean on actually wants to see.
Record the guide version, test version, run identifier, environment, result and gaps, and retest history. These fields describe the same evidence record, not a mandatory chronological process.
Common failures and what they mean
Across the kits, the sandboxes and the connectathon notes, the same failures recur. Each one points at a specific fix.
- "Coverage information system action missing" on order-sign. The facade returned cards but no system action; §hook-16 requires the action even when the answer is "more information needed."
- "Prefetch not honored, callback exceeded budget." The service queried the EHR for data it had already been given. Read the prefetch first; call back only for what is missing.
- "400 expected for unknown payer." The facade accepted a Coverage with another payer's identifier and answered anyway. Validate the payer identifier before routing.
- "Questionnaire item has no populated answer" for every patient. The CQL compiled but references a profile or value set the test EHR does not serve. Run the synthetic cohort before publishing.
- "Bundle reference not resolvable." A Claim references a Practitioner not in the bundle. The bundle rules require every referenced resource to be present.
- "Subscription notification not received." The rest-hook endpoint was not reachable, the organization filter excluded the test organization, or the notification carried an id instead of the full resource.
- "Consent not enforced at export." The Payer-to-Payer export returned data for a member whose consent was revoked after registration. Check consent at execution.
- "CapabilityStatement mismatch." The server advertises operations it does not serve, or omits ones it does. Generate the statement from the running configuration, never by hand.
A demo script that works in twenty minutes
Buyers rarely want to watch a test suite. They want to see the loop. The demo we run, on the public environments and with no partner, takes twenty minutes.
- Open the crd-request-generator from the Foundry bundle pointed at the plan's CRD facade. Pick the synthetic patient, order a lumbar MRI, fire order-sign. Show the card and, in the developer view, the coverage-information system action with the assertion id. Elapsed time on screen.
- Launch DTR from the card. Watch the questionnaire package load and six of nine items populate from the test EHR, each marked as populated from the chart. Answer the remaining three.
- Submit through PAS to the plan's
$submit. Show the ClaimResponse approved in the acknowledgement window, with the authorization number. Then repeat with an answer that fails the policy and show pended, the CommunicationRequest, an update with a document, and the subscription notification arriving at a receiver endpoint on screen. - Open Patient Access for the same synthetic member and show the request and decision present with its reason.
- Open the metrics view and show the public measures updated by the requests just made.
- Close with the Inferno reports for the three kits, run ids visible, and the Epic sandbox run of the same CRD hook.
Every step is reproducible by the buyer's own team from public tools, which is the point of a demo when there is no certification to show.
If you need an evidence pack assembled, or a testing plan reviewed before a board or buyer sees it, we run the kits, the sandboxes and the EHR-side registrations described here. See our CMS-0057-F interoperability suite and FHIR integration services pages, or talk to our team.
Explore the CMS-0057-F series
- CMS-0057-F Explained: Requirements and 2027 API Deadlines
- Da Vinci CRD Explained: Coverage Requirements Discovery
- Da Vinci DTR Explained: Questionnaires, CQL and Prior Authorization
- Da Vinci PAS Explained: FHIR Prior Authorization and X12 278
- CMS-0057-F Payer Architecture for Delegated Vendors
- CMS-0057-F API Testing: Inferno, Sandboxes and Evidence (this article)
Sources
- Inferno test kits
- Inferno Da Vinci CRD test kit (GitHub)
- Inferno Da Vinci PDex test kit (GitHub)
- HL7 Foundry
- Burden Reduction reference implementations (HL7 Confluence)
- HL7-DaVinci GitHub: br-payer, br-provider, test-ehr, crd-request-generator, dtr, CDS-Library
- Acentra Health FHIR sandbox
- Epic: payers, providers and Epic launch real-time prior authorization checks (August 2026)
- Epic on FHIR developer documentation
- open.epic playbooks
- Health Samurai: CMS FHIR Connectathon 2026 results
- Flexpa endpoint directory (snapshot taken 2 September 2026)
- CMS-0062-P proposed rule, Federal Register 2026-07205 (14 April 2026)
- WSO2 CMS-0057-F reference implementation
- CMS Data at the Point of Care
- CMS BCDA (GitHub)
- AEGIS Touchstone
- CMS Prior Authorization API FAQs
- Medblocks, CMS-0057-F Explained (Sidharth Ramesh, YouTube)
