Is there a free Epic FHIR sandbox?

Yes. mock.health hosts an Epic-shaped FHIR R4 sandbox at mock.health/v/epic-cluster-A/fhir/r4/ that is readable on the free tier against a 25-patient sample dataset; full canonical scope is Pro. It is not Epic and is not operated by Epic — it is a synthetic endpoint that reproduces Epic's observed wire behavior (CapabilityStatement shape, OAuth and SMART specifics, OperationOutcome bodies, search-param subset, OID dual-coding) over synthetic patients.

How is this different from Epic's own open sandbox?

Epic's open sandbox at fhir.epic.com is built for certification: a fixed roster of thin, uncorrelated test patients, and access to more gated behind a partner agreement. This endpoint reproduces the same Epic wire behavior over synthetic patients that carry longitudinal history, comorbidities, imaging and clinical narrative — so the vendorisms you code against are Epic's, while the data is demo-safe and yours to shape.

Does Epic FHIR R4 follow US Core 6.1?

Mostly, but with deviations. Epic's published CapabilityStatement declares US Core compatibility, but at the wire we observe 189 element-level deviations from US Core 6.1 across 10 probed resource types — including Observation.category and Encounter.class dual-coded with Epic-proprietary OIDs alongside the standard codings.

What OAuth flow does Epic use for FHIR R4 access?

Client credentials with JWT, signing algorithm RS384, JWKS hosting required (not embedded). Scopes use the SMART v1 format. Token endpoint at /oauth2/token, authorize endpoint at /oauth2/authorize.

Why does Epic dual-code Observation.category and Encounter.class with proprietary OIDs?

Epic mirrors standard codings (LOINC, observation-category, v3-ActCode) with Epic-proprietary OIDs alongside them, so clients matching against Epic's OID still find the value. Cerner and MEDITECH do not dual-code — it is a real Epic-vs-not-Epic signal at the wire.

Can I create Patients via the Epic FHIR R4 API?

Epic accepts a narrow demographic subset on POST /Patient: resourceType, active, name, gender, birthDate, address, telecom, identifier. Anything else (extension, modifierExtension, multipleBirth, communication, contact) is dropped before the create reaches Epic. Identifier system for SSN must use the OID urn:oid:2.16.840.1.113883.4.1, not the URI form http://hl7.org/fhir/sid/us-ssn.

How can I test against Epic FHIR without a partner contract?

Build against the Epic overlay at mock.health/v/epic-cluster-A/fhir/r4/ via Pro — same patients across vendors, Epic-flavored CapabilityStatement, OperationOutcomes, search-param subset, and OID dual-coding at the wire.

Epic FHIR sandbox — Epic at the wire

A free Epic-shaped FHIR sandbox you can call today: a live FHIR R4 endpoint that answers with Epic's CapabilityStatement, Epic's OAuth flow, Epic's OperationOutcomes and Epic's OID dual-coding — no Epic partner contract, no App Orchard review, no BAA. It is not Epic, and it is not Epic's own open sandbox at fhir.epic.com; it is a synthetic Epic-flavored endpoint modelled on Epic February 2026's observed behavior, fetched 2026-04-26.

Underneath the endpoint sits the evidence it is built from: 189 element-level deviations from US Core 6.1, 10 resource types probed for search-param subsets, OperationOutcome example responses, OAuth/SMART specifics, pagination behavior, reference resolution sampling, and bulk export kickoff status — every claim source-cited with verbatim quote and verification date.

Auth overlay

Client credentials JWT alg: RS384. JWKS hosting required (hosted, not embedded). Scopes format: SMART v1. Authorize endpoint at /oauth2/authorize, token at /oauth2/token. Phase A finding from the published CapabilityStatement.rest[0].security — declared OAuth + SMART-on-FHIR + Basic.

OperationOutcome examples

Verbatim error response bodies for unknown resource types, not-found resource IDs, and invalid bearer tokens. Vendor-specific extensions and OID-coded errors — what your error-handling code has to actually parse.

Element deviations from US Core 6.1

189 path-level rows with expected vs. observed, multi-patient evidence (matches-everywhere, missing-everywhere, per-patient), and source citations. Filterable by category and substring on the page.

Compatible with Epic's published FHIR R4 CapabilityStatement (Epic February 2026 release). Not affiliated with or endorsed by Epic Systems Corporation. Trademarks used for identification only. Build against this overlay without a partner contract via Pro.

CapStmt-shape clusters in production

Epic's 739 production FHIR endpoints fall into 8 distinct CapabilityStatement-shape clusters. Each cluster is a wire-level deployment archetype your integration may hit:

Epic cluster C — modal, 301 endpoints (41%), 59 resources advertised, 47 US Core 6.1 profiles
Epic cluster A — variant, 232 endpoints (31%), 59 resources advertised, 47 US Core 6.1 profiles
Epic cluster B — variant, 15 endpoints (2%), 59 resources advertised, 47 US Core 6.1 profiles
Epic cluster E — variant, 2 endpoints (0%), 56 resources advertised, 0 US Core 6.1 profiles
Epic cluster F — variant, 2 endpoints (0%), 59 resources advertised, 0 US Core 6.1 profiles
Epic cluster G — variant, 1 endpoints (0%), 53 resources advertised, 0 US Core 6.1 profiles
Epic cluster H — variant, 1 endpoints (0%), 54 resources advertised, 0 US Core 6.1 profiles
Epic cluster I — variant, 1 endpoints (0%), 57 resources advertised, 0 US Core 6.1 profiles