Submission stages
Use these stages to operate FHIRBridge as an auditable interface engine from intake through mock, dry-run, or approved live transport.
| Stage | Purpose | Action | Readiness gate | Evidence |
|---|---|---|---|---|
| 1. Define source intake contract | Make every inbound source row predictable before it enters conversion or queue processing. | Document accepted formats, required identifiers, date formats, tenant context, source-system name, and the canonical row fields expected by Live Feed. | Every source interface has a named owner, sample payload, field contract, and rejection rule. | Source intake contract, sample payload, owner list, and rejected-row rules. |
| 2. Validate inbound payload | Stop incomplete or unsafe records before Bundle generation. | Run preflight checks for tenant, organization/site/program identifiers, client identifiers, mandatory PDS fields, dates, and local code values. | Invalid rows produce clear diagnostics and are not queued for submission. | Preflight output, invalid-row diagnostics, and remediation owner. |
| 3. Generate FHIR Bundle | Convert canonical intake into traceable FHIR R4 content. | Generate Patient, Organization, Location, EpisodeOfCare, Encounter, Appointment, Observation, Condition, ServiceRequest, and related resources as applicable. | Each Bundle has stable identifiers, source traceability, and the expected resource count for the source row. | Bundle JSON, conversion summary, resource inventory, and source-row trace. |
| 4. Run validation before queueing | Prevent known-bad Bundles from moving into transport. | Run local requirement validation, terminology checks, FHIR structural validation, and authorized package validation where configured. | No unresolved fatal/error validation issue exists before a job is eligible for submission. | Validation report, OperationOutcome diagnostics, and issue disposition. |
| 5. Queue submission job | Create an auditable unit of work for retry, support, and operations review. | Queue the validated Bundle with tenant, mode, endpoint target, status, attempt count, Bundle ID, and validation summary. | Queued jobs include enough metadata to support retry and audit without opening raw PHI unnecessarily. | Feed job record, queue status, Bundle ID, and validation summary. |
| 6. Process mock or dry-run transport | Prove the engine workflow without sending live production data. | Process the next job in mock or dry-run mode, capture response code, response body, remote/mock ID, and OperationOutcome. | Dry-run jobs reach accepted/mock-accepted or fail with actionable diagnostics. | Attempt history, mock/dry-run response, and job status transition. |
| 7. Configure live transport controls | Prepare endpoint and credential handling for approved live submission. | Configure endpoint URL, token ownership, secret rotation, TLS expectations, timeout, retry policy, and support contacts. | Live mode remains disabled until onboarding approval and go/no-go sign-off are complete. | Transport configuration checklist, credential owner, rotation note, and go/no-go record. |
| 8. Monitor queue operations | Keep production submissions observable and supportable. | Review queued, validating, submitting, accepted, failed, and retrying jobs; investigate stale jobs and repeated failures. | Operations has a daily review process, escalation path, and retained job evidence. | Daily queue review, incident log, retry history, and support handoff notes. |
| 9. Manage failures and replay | Recover safely from validation, endpoint, credential, or remote response failures. | Classify failure root cause, correct the source or configuration, regenerate/validate when needed, and submit a new traceable job. | Replays are deliberate, traceable, and do not silently duplicate accepted submissions. | Failure analysis, corrected payload, replacement job ID, and duplicate-prevention note. |