EHR sandboxes: what vendors publish and what they lack

Your first customer signs on a Friday and wants data on Monday. You have never sent a request to their EHR. The vendor sandbox is where you find out what breaks before the customer does. This post lists which vendors publish a sandbox according to their own documentation, what a sandbox leaves out, and how to test an integration before the first production connection.

Which vendors publish a sandbox

Vendor	What the public documentation says
Epic	The developer guidelines state that the sandbox simulates an EHR environment for testing only, must contain only sample or synthetic data, and may be wiped by Epic at any time. It is not for performance, scalability or security testing.
athenahealth	The environment guide gives a Preview base URL of https://api.preview.platform.athenahealth.com and a production base URL of https://api.platform.athenahealth.com. Credentials work in one environment only. The onboarding guide grants Preview credentials sandbox access on app creation, and provides a dummy patient record for patient-facing testing. Provider-facing apps need a Preview tablespace through a client agreement or the Marketplace Partner Program.
Oracle Health	The service root URL page lists an open sandbox at https://fhir-open.cerner.com/r4/ec2458f2-1e24-41c8-b71b-0e701af7583d/, a secure sandbox at https://fhir-ehr-code.cerner.com/r4/ and a patient-facing sandbox at https://fhir-myrecord.cerner.com/r4/ on the same tenant. The SMART guide says the open endpoint needs no authentication and is read-only; writes require the secure endpoint and registration in code Console.
eClinicalWorks	The developer portal lists the steps: sign up, register the application, test in the sandbox, publish to production. It does not publish sandbox URLs on the public page.
NextGen Healthcare	The regulatory API page says Developer Portal registration is required for production credentials and optional for sandbox access, and the partner page says there is no charge to use the platform, which includes API sandboxes.
Availity	The getting started guide describes a Demo plan as a sandbox that returns canned responses rather than live data, with automatic approval. The Standard plan gives production data after contracting.

What a sandbox lacks

Real payer responses

Availity's Demo plan returns canned responses. A canned 271 shows you the shape of an eligibility response. It does not show you the payer that returns a benefit with no copay amount, or the payer that returns a 999 rejection for a subscriber ID with a leading zero. Those appear in production only.

Real volume

Epic states its sandbox is not for performance or scalability testing. Oracle Health says rate limits vary between customers based on agreed usage levels and returns HTTP 429 when you exceed them. The limit you hit at a customer is not the limit you hit in the sandbox.

Real second factors

A sandbox issues you client credentials. A production portal issues a person a login. Availity requires an authenticator app or hard token for multi-factor authentication. Alabama Medicaid requires a time-based one-time password app. Neither has a sandbox for that flow.

Real data

athenahealth describes the Preview tablespace as a place with non-sensitive dummy data. Oracle Health's FAQ says code mappings differ by site and that sensitive data is filtered for some personas. A sandbox patient has clean codes and complete fields. A production patient has a free-text allergy, a merged chart, a duplicate guarantor and an insurance record with the payer name misspelled.

Real release timing

athenahealth's release schedule puts production releases on Fridays and Preview releases on Saturdays. For that vendor the sandbox receives a change after production does, so the sandbox cannot warn you.

How to test before the first customer

Start in the open sandbox where one exists. Oracle Health's open endpoint needs no credentials, so your first request runs before any registration is approved. Use it to build the resource mapping and the paging logic.

GET https://fhir-open.cerner.com/r4/ec2458f2-1e24-41c8-b71b-0e701af7583d/metadata
Accept: application/fhir+json

Move to the secure sandbox to test the authorization flow end to end: registration, scopes, token exchange, refresh. The certification rule at 45 CFR 170.315(g)(10) requires a refresh token valid for no less than three months for confidential apps. Test that your connector uses the refresh token and does not force a new authorization on each run.

Record every sandbox response and replay it in your test suite. The vendor can wipe the sandbox, as Epic states, so your tests must not depend on the sandbox being up. A recorded response is also the place to inject the failures the sandbox never sends: a 429, a 401 on an expired token, a resource with an unknown modifier extension.

Then test what the sandbox cannot give you. Build a fault list for each connector: empty pages, missing must-support fields, a code outside the value set, a payer response with no benefit segments. Run the connector against each fault and confirm it marks the field unavailable instead of writing a wrong value.

Finally, plan the first production connection as a test. Ask the customer to create one test patient in their production system with their own synthetic data, read that patient first, and compare the output with the sandbox result field by field. Only then open the full patient list.

TheFhirStorm's open-source connectors for eClinicalWorks in Python and TypeScript include the authentication and paging code that a sandbox test exercises first. Run them against the vendor sandbox before you write your own.