FHIR implementation guide
The EDFlow ED Visit Workflow FHIR implementation guide: base profiles on CA Baseline, must-support and prohibited elements, terminology and canonical URLs, the $ingest operation, examples, and validating with the HL7 FHIR validator.
The FHIR routes are backed by a small implementation guide (IG), built with the HL7 IG Publisher and published with the API. This page summarizes it; the IG is the normative reference.
Base
Profiles derive from CA Baseline (the pan-Canadian baseline), with CA Core+ where the pilot EHRs already conform.
| Profile | Used for |
|---|---|
Encounter | Arrival, triage history, location, participants, departure |
ServiceRequest | Orders: category, priority, status |
DiagnosticReport | Result status only |
Observation | Triage acuity only |
Task | Fulfilment hints |
PractitionerRole, Location | Enrichment and mapping |
| Subscription notification Bundle | Subscriptions Backport rest-hooks |
Each profile lists its must-support elements and says which elements EDFlow reads, which it ignores, and which are prohibited (result values, conclusions, presented forms, narrative, notes). Prohibited elements are dropped unread by the adapter.
Terminology
- Bindings for encounter class, order and report status (
request-status,diagnostic-report-status), practitioner roles and locations. - CTAS: until a pan-Canadian FHIR code system for CTAS is confirmed, the IG publishes its own CTAS code system with a concept map to what each EHR sends, and records the decision.
Canonical URLs
Every code system, value set, profile and operation has a canonical URL on the API's domain (for example …/fhir/CodeSystem/service, …/fhir/CodeSystem/api-error, …/fhir/NamingSystem/site-orderable), and site-local order codes use …/fhir/CodeSystem/site/{siteCode}/orderable. These don't change with branding.
Operations
| Operation | Definition |
|---|---|
$ingest | GET /v1/fhir/OperationDefinition/ingest. Input resource (a Bundle); output a batch-response-shaped Bundle or an OperationOutcome |
$process-message | Standard FHIR messaging |
The CapabilityStatement at GET /v1/fhir/metadata comes from the same build.
Examples and validation
Examples for every profile are generated from the synthetic fixtures and checked with the HL7 FHIR validator in CI. Validate your own resources the same way:
java -jar validator_cli.jar your-bundle.json -version 4.0.1 -ig <the IG package from the API's FHIR base>Then dry-run them against the sandbox with POST /v1/events/validate and Content-Type: application/fhir+json.
Related
Last updated on