TestingInfernoCMS-0057-FDa Vinci

Prior Authorization API Testing: 25 Scenarios, Inferno Kits and the Evidence Pack

September 5, 202613 min readUpdated Oct 19, 2026

Written by

CTO & Co-Founder

CTO & Co-Founder at Nirmitee.io. Architects healthcare integrations across FHIR, SMART on FHIR, ABDM and NHCX, writing from production experience taking hospital software from sandbox to go-live.

Prior Authorization API Testing: 25 Scenarios, Inferno Kits and the Evidence Pack

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. It also lists 25 end-to-end scenarios to test before go-live, with the expected result and the evidence to keep for each.

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.

25 prior authorization scenarios to test before go-live

A prior authorization API is ready when it handles the whole journey, not only the happy path. Run these 25 scenarios with synthetic members before any customer or partner test, and keep the evidence for each; together they cover the CRD, DTR and PAS steps, the X12 278 bridge, the 2026 decision clocks and the audit trail.

#	Scenario	What to send	Expected result	Evidence to keep
1	No authorization required	CRD order-sign or appointment-book hook for a service the payer does not review	CRD response says prior authorization is not needed (coverage-information pa-needed = no-auth); no PAS request is created	CDS Hooks request and response, card shown to the clinician
2	Authorization required, no documentation	Service that needs authorization but no extra clinical data	pa-needed = auth-needed, doc-needed = no-doc; the EHR can submit straight away	Hook response, coverage-information extension
3	Authorization required with documentation	Service with a payer questionnaire	DTR launches the questionnaire, CQL prepopulates what the chart holds, the clinician completes the rest	Questionnaire version, QuestionnaireResponse, which answers were prepopulated
4	Approved in real time	Complete PAS $submit for a covered service	ClaimResponse approved (X12 278 HCR01 = A1) with an authorization number and validity dates	Request and response bundles, decision timestamp
5	Denied with a specific reason	Request that fails policy	Denied (A3) with a specific reason the provider can act on, as required since 2026	Reason code, provider-facing text, notice sample
6	Pended for review	Request that needs clinical review	Pended (A4); the final decision arrives later	Pend status, review queue entry, 72-hour or 7-day clock start
7	Additional information requested	Reviewer needs more records	Pended with a request; provider sends documents or an updated questionnaire; final decision follows	Request for information, attachment receipt, final ClaimResponse
8	Partially approved or modified	Request for more units or a longer period than policy allows	Certified in part (A2) or modified (A6) with the approved quantity and dates	Requested vs approved values
9	Unknown or inactive member	Member identifier that does not match, or coverage ended	Clear error or denial; no silent failure	OperationOutcome or rejection, member-match log
10	Provider not eligible	Out-of-network or unenrolled rendering provider	Handled per policy: error, pend or denial with reason	Policy rule applied, response
11	Invalid or unsupported code	Unknown CPT/HCPCS or ICD-10-CM code	Validation error before adjudication	Validation message, rejected request
12	Missing required documentation	Submit without the QuestionnaireResponse the payer asked for	Pended or rejected with a request for the missing items	Response and the rule that fired
13	Unsupported attachment	Attachment in a format the payer does not accept	Rejected attachment with a usable error	Error payload
14	Duplicate submission	Same request sent twice, for example after a network retry	One case only; the second call returns the existing result	Idempotency key or identifier match, case count
15	Resubmission after correction	Corrected request after a denial or error	New request linked to the original case	Case history showing both
16	Update to dates or quantities	Provider changes the service date or units	Authorization updated or re-reviewed per policy	Update request and response
17	Cancellation	Provider cancels a pending or approved request	Status cancelled (C)	Cancel request and resulting status
18	Status inquiry	Provider asks for the status of an open request	PAS $inquire returns the current status	Inquiry and response
19	Pended to final via subscription	Pended request later decided	Subscription notification fires; provider retrieves the final decision	Notification, retrieval, elapsed time
20	Payer or delegated vendor timeout	Utilization management vendor unavailable	Request is not lost: pended or retried with a clear status	Retry log, final state
21	FHIR to X12 278 translation failure	Intermediary cannot map a field to the 278	Failure surfaced to the provider and operations team; no silent drop	Translation error, alert
22	Authorization expiry	Service after the authorization end date	New request required; expired authorization not accepted	Validity dates, rejection
23	Appeal after denial	Provider appeals a denial	Appeal tracked and linked to the original case	Appeal record, outcome
24	Metrics reconciliation	Run all cases above	Each case lands in the public metrics with the right timestamps and outcome	Metric query output vs test log
25	Audit reconstruction	Pick any case	Reconstruct who asked, what was decided, when and under which rule and IG version	Audit trail, versioned configuration

Inferno test kits cover many of the conformance checks in scenarios 1 to 8 and 18 to 19; the rest need your own fixtures and partner sandboxes. Claims-side teams should pair this with our EDI testing guide for 837 and 835 integrations. If you send us your endpoint and the workflows you support, our CMS-0057-F implementation team will return a scoped test plan covering conformance and end-to-end scenarios.

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-provider and test-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 $submit passing 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 Implementation: 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

Ready to scale?

Talk to our healthcare engineering team about building, integrating, and shipping faster.

Book a Call Contact Us

Frequently Asked Questions

Is there a CMS certification we can get?

No. Payers attest. ONC certifies EHR software under HTI-4. An Inferno report set is the closest public equivalent for a payer.

Can we test without any EHR partner?

Yes. Foundry, Inferno and Acentra need no partner. Epic's sandbox needs only a developer account.

Which environment matters most to a buyer?

Inferno reports for conformance; Epic sandbox runs for credibility with provider organizations; Acentra runs for anyone selling to review contractors or Medicaid programs.

Do we need the X12 license to test?

For PAS, yes, because the Claim profile binds to X12-licensed code systems and the intermediary path uses the 278 and 275.

What breaks most often outside the kits?

Prefetch that is not honored, callbacks that blow the five-second budget, CQL that returns null on real patients, subscription notifications that never arrive, and bundle references that point outside the bundle.

What should a prior authorization API test cover?

At minimum: requests that need no authorization, need authorization with and without documentation, approvals, denials with a specific reason, pends and requests for more information, partial approvals, errors for unknown members and invalid codes, duplicates, cancellations, status inquiries, timeouts, X12 278 translation failures, expiry, appeals, metrics reconciliation and audit reconstruction. The 25-scenario table above lists each with the expected result and the evidence to keep.

Healthcare Interoperability