Sandbox
Create a sandbox app and develop against the EDFlow sandbox: synthetic-only enforcement, fictional hospitals, simulator scenarios, dry-run validation, fault injection, conformance profiles including outage_recovery, and resetting, plus how customer test differs.
The sandbox is where you build and test your integration against fictional hospitals. It is a separate deployment from customer test and live, so sandbox credentials can never reach real data.
Create a sandbox app
In the developer portal: Apps → New app, environment Sandbox. Sandbox apps are active immediately, with no approval. Then follow the quickstart.
Your sandbox organization
When your organization is onboarded, it gets a sandbox organization with:
- one fictional site per real site, with the same time zone and languages and a code ending in
-sbx; - 20 active visits and 10 weeks of history, so estimates and analytics work;
- a simulator source and sandbox staff accounts, so you can watch your events arrive on the staff board.
Synthetic data only, enforced
The sandbox runs in the US and must never receive real patient data. It checks every ingest path:
| Check | Rule |
|---|---|
| Processing id | HL7 MSH-11 must be T or D; FHIR Bundles must carry the HTEST tag |
| Identifiers | Patient identifiers must start with SYN. A valid-checksum Ontario health card number, a site record-number pattern or a Canadian postal code is refused |
| Names | Must come from the synthetic-name dictionary or start with SYN or ZZTEST |
A refusal is phi_suspected (HL7: AR with ERR-3 202). Nothing is stored. Your app's contacts are alerted, and after 3 hits in 24 hours the app is disabled until reviewed. Hospital test-domain feeds go to customer test, never to the sandbox, because test domains are often copied from production.
The test console
The portal's console sends events, HL7 or FHIR to the sandbox and shows the response, the derived events, a field trace and the event log entry.
Dry-run anything with POST /v1/events/validate: nothing is stored or notified.
curl -sS -X POST 'https://api.sandbox.edflow.space/v1/events/validate' \ -H "Authorization: Bearer $EDFLOW_ACCESS_TOKEN"Simulator scenarios
Run a scripted visit at up to 60× speed, delivered directly, signed, as HL7 v2 or as FHIR:
printf '%s' '{"transport":"direct"}' > body.jsoncurl -sS -X POST 'https://api.sandbox.edflow.space/v1/sandbox/scenarios/%7BscenarioKey%7D/run' \ -H 'Content-Type: application/json' \ -H "Authorization: Bearer $EDFLOW_ACCESS_TOKEN" \ --data-binary @body.jsonScenarios include walk-in discharge, chest pain admitted, CT with contrast, a child's fever with a urine sample, left without being seen, serial troponin, observation after anaphylaxis, codes, a feed outage with backfill and surge. See Simulator.
Test webhooks and write-back
POST /v1/sandbox/requests creates a patient request on a synthetic visit, so you can receive request.created and try acknowledge and resolve.
Fault injection
Make your own app's requests fail or slow down, to test retries, queues and circuit breakers. Other apps are unaffected.
| Fault | Effect |
|---|---|
unavailable | 503 with Retry-After |
rate_limited | 429 |
latency | Added delay, up to 20 s |
token_endpoint_down | 503 from /oauth/token |
slow_ack | Slow HL7 acknowledgements |
printf '%s' '{"faults":[]}' > body.jsoncurl -sS -X POST 'https://api.sandbox.edflow.space/v1/sandbox/faults' \ -H 'Content-Type: application/json' \ -H "Authorization: Bearer $EDFLOW_ACCESS_TOKEN" \ --data-binary @body.jsonConformance profiles
| Profile | Proves |
|---|---|
ingest | Your declared event types, idempotent retries, out-of-order delivery, a prohibited-field rejection, heartbeat and roster |
webhooks | Your receiver verifies signatures, deduplicates a redelivery and drops an expired event |
writeback | Acknowledge and resolve with idempotency keys |
outage_recovery | EDFlow unavailable for 30 minutes: every message your engine queued lands afterwards with no 401, no idempotency_conflict and no gap |
clock_skew | Timestamps judged against ±90 s |
backfill_10k | 10,000 events at the rate limit |
printf '%s' '{"profile":"ingest"}' > body.jsoncurl -sS -X POST 'https://api.sandbox.edflow.space/v1/sandbox/conformance' \ -H 'Content-Type: application/json' \ -H "Authorization: Bearer $EDFLOW_ACCESS_TOKEN" \ --data-binary @body.jsonReset
POST /v1/sandbox/reset resets your organization's sandbox sites to the seed, deleting ledger rows and webhook history for them.
Customer test
| Sandbox | Customer test | |
|---|---|---|
| Data | Synthetic only | Your hospital's test-domain feeds, treated as real |
| Location | US East | Canada |
| Simulator, faults, reset | Available | Not available (reset only on the hospital's written request) |
| Approval | None | Four eyes, like live |
Related
Dernière mise à jour le
Cette page vous a-t-elle été utile?
Mapping profiles
The versioned EDFlow site mapping profile: encounter filters and identifiers, locations and beds, CTAS codes, roles and practitioner ids, dispositions, order and consult codes, NPO diet codes, result thresholds, privacy options, and unmapped-code governance.
SDKs and snippets
Code snippets in cURL, TypeScript and Python for every EDFlow API operation, signing helpers for the signed ingest profile with the conformance test vector, the OpenAPI document, Postman collection and typed clients.