A free, always-on payer to test your CRD, DTR, and PAS integration against
CMS-0057-F requires payers to expose prior-authorization APIs by January 2027.
If you're building the other side of that conversation — a CDS Hooks CRD check, a DTR
questionnaire flow, or a PAS $submit — you need a real counterparty to test
against, and no live payer will let untrusted code near their production endpoint. This is one,
and it's free.
1. CRD
order-sign hook
“does this need prior auth?”
2. DTR
questionnaire package
fetch the required docs
3. PAS
Claim/$submit
approve / deny / pend
Who this is for
Built for the provider side of prior authorization — the teams whose software has to call these APIs, not the payers who host them.
- RCM (revenue cycle management) platforms
- DME suppliers — oxygen, wheelchairs, prosthetics
- Imaging centers and radiology platforms
- Home health and hospice software
- Specialty clinics — oncology, orthopedics
- Telehealth platforms with e-prescribing
- Second-tier EHR vendors
The concrete person: a tech lead who just got told “add CRD support by January” and is about to search for a test server to point their client at.
What you get
Full round trip
CRD → DTR → PAS against a real Da Vinci reference implementation, not a hand-rolled stub.
Controlled outcomes
Trigger an approval, a denial with review-action codes, or a pended request with a document ask — on demand, not at random.
Your own tenant
Sign up with just an email and get an isolated bearer token plus a synthetic patient. No password, just a magic link.
Request inspector
Every call you make is logged, newest first, with a shareable permanent link to any request/response pair.
What it looks like after you sign up
The scenario catalog and the request inspector, list and detail view of each. Click any of these to zoom in.
Free, with sensible limits
This sandbox is free — no credit card, no sales call, no trial period. Sign up and you're sending requests within a minute. It runs on modest, shared infrastructure, so request volume is rate-limited per token to keep it available for everyone; that's the trade-off for it costing nothing.
What this isn't
- Not a conformance checker. Use the official Inferno test kits for that — this is a live counterparty to test against, not a certifier of your client.
- Not a real payer. Every patient, coverage, and claim here is a synthetic test fixture. Don't send real patient data (PHI) — there's nothing on the other end to protect it.
- Not a private environment. Everyone shares the same hosted instance and scenario library; there's no way yet to load your own custom scenarios.
- Not a production SLA. It's a free developer tool on shared infrastructure — expect occasional maintenance, not guaranteed uptime.
Try it in under 10 minutes
Sign up with your email first — under a minute, no password, just a magic link — to get the bearer token these commands need. Then it's three requests, one flow: CRD hook → DTR questionnaire package → PAS submit. Each feeds the next.
export TOKEN=<your token, from the dashboard>
export BASE=https://fhir-sandbox.greenice.net
# 1) CRD: ask "does this order need prior auth?" -- fetch a fixture hook call, then send it
curl -s "$BASE/api/crd/scenarios/prior-auth-required/hooks/order-sign" \
-H "Authorization: Bearer $TOKEN" -o hook-request.json
curl -s -X POST "$BASE/cds-services/order-sign-crd" \
-H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
-d @hook-request.json | tee crd-response.json
# 2) DTR: fetch the questionnaire package the CRD response pointed at
curl -s "$BASE/api/dtr/scenarios/prior-auth-required/variants/prior-auth-required-canonical" \
-H "Authorization: Bearer $TOKEN" -o dtr-request.json
curl -s -X POST "$BASE/fhir/Questionnaire/\$questionnaire-package" \
-H "Authorization: Bearer $TOKEN" -H "Content-Type: application/fhir+json" \
-d @dtr-request.json | tee dtr-response.json
# 3) PAS: submit the prior-auth request, see the (corrected) decision code
curl -s "$BASE/api/pas/scenarios/prior-auth-required/variants/prior-auth-required-initial" \
-H "Authorization: Bearer $TOKEN" -o pas-request.json
curl -s -X POST "$BASE/fhir/Claim/\$submit" \
-H "Authorization: Bearer $TOKEN" -H "Content-Type: application/fhir+json" \
-d @pas-request.json | tee pas-response.json
Prefer to browse instead of copy-pasting exact ids? The scenario catalog lists every clinical module with a flow diagram, ready-made commands, and a run-in-browser button; every request shows up in the inspector.
Technical details: what this sandbox changes vs. the upstream engine
| Behavior | Detail |
|---|---|
| Namespace | Canonical URIs use https://fhir-sandbox.greenice.net, not the
upstream engine's internal example.org placeholder (which live FHIR validators reject). |
| Denial code | Prior-auth denials return review action A3 by
default (matches the IG's own official example) instead of the upstream engine's native
A2. Configurable per token — see PATCH /api/tenant/config. |
| Data cleanup | Self-referencing Patient.link entries and the broken
subscription seed resource are fixed at this layer. |
| Auth | Bearer token required (the upstream engine itself has none). |
Who built this
Greenice is a software development company that builds FHIR and prior-authorization integrations — CRD hooks, DTR questionnaire flows, PAS submissions — for provider-side platforms. We run this sandbox as a free tool for the developer community. If you're building a CRD/DTR/PAS client and want a hand getting it production-ready, get in touch.