Validation evidence stages
Use these stages to prepare a review-ready validation evidence package before live submission.
| Stage | Purpose | Action | Pass criteria | Evidence |
|---|---|---|---|---|
| 1. Source preflight | Catch structural and mandatory-field issues before FHIR generation. | Run template self-check, confirm required columns, check row counts, and review date/identifier formats. | No missing required columns, no blank mandatory identifiers, and no malformed dates in candidate rows. | Template self-check export, source row count, rejected-row list, and owner notes. |
| 2. Conversion traceability | Prove each source row creates the expected FHIR resources and identifiers. | Run conversion, inspect generated Bundle identifiers, resource counts, and source-to-resource trace fields. | Expected row count matches expected Bundle count, and every generated Bundle can be traced to a source row. | Conversion summary, Bundle JSON, source row identifier, and traceability worksheet. |
| 3. Local PDS requirement validation | Check generated content against the local Ontario MHA PDS requirement rules maintained in the app. | Run validation and classify fatal, error, warning, and information findings. | No unresolved fatal/error findings remain for the production candidate extract. | Validation report, issue triage log, remediation owner, and retest date. |
| 4. FHIR structural validation | Confirm FHIR JSON structure, references, resource types, and Bundle shape are valid. | Run the configured FHIR validator or HAPI/CLI-backed validation where available. | Bundle structure is valid and references resolve within the Bundle or documented external context. | FHIR validator output, OperationOutcome diagnostics, and validator version. |
| 5. Authorized package validation | Validate against the authorized Ontario MHA PDS package when the package is available to the tenant. | Confirm package path/version/checksum, run formal package validation, and retain the exact package metadata. | Validation uses the approved package version and no package-level blocker remains unresolved. | Package metadata, checksum/path, validator command or endpoint, and validation output. |
| 6. Terminology validation | Confirm coded fields use accepted code systems, value sets, or documented local crosswalks. | Run terminology self-check, compare local codes to mapped target codes, and classify unmapped values. | Required coded values are mapped or formally accepted as gaps with remediation plans. | Terminology export, crosswalk file, warning list, and clinical owner decisions. |
| 7. Timeline and clinical consistency | Catch impossible or suspicious service dates, encounter timing, referral windows, status combinations, and discharge logic. | Review validation warnings for dates/statuses and compare source-system timeline rules with generated resources. | No impossible timelines remain and accepted warnings have a documented rationale. | Date/status issue log, corrected source extract, and accepted-warning record. |
| 8. Submission dry run | Prove the interface-engine queue can process candidate payloads without live Ontario Health submission. | Queue a candidate row through Live Feed in mock or dry-run mode and process the job. | Job reaches accepted/mock-accepted status with traceable Bundle ID and OperationOutcome. | Feed job export, attempt history, mock/dry-run response, and Bundle identifier. |
| 9. Go/no-go evidence pack | Bundle validation evidence for governance, privacy, security, data, clinical, and integration approval. | Export mappings, terminology, validation, conversions, audit log, readiness, and transport checklist. | Every readiness gate has an owner, date, status, and retained artifact. | Named evidence package, sign-off record, and go/no-go decision. |