Go-live gates
Use these gates before enabling approved live submission operations or a production pilot.
| Gate | Owner | Requirement | Blocker criteria | Evidence |
|---|---|---|---|---|
| 1. Authorized standards confirmed | FHIR lead and standards owner | The Ontario MHA PDS data dictionary, implementation guide, package, and terminology references are version-pinned for the release. | Package version, source, or validation configuration is unknown or differs from the approved implementation baseline. | Standards register, package metadata, Settings export, and validation configuration record. |
| 2. Tenant and access controls approved | Security lead, privacy officer, administrator | Production tenant, memberships, RLS policies, role checks, export protection, and audit logging are verified. | Any cross-tenant read/write succeeds or users can access restricted exports/actions without the required role. | RLS tests, role matrix, audit export, and access review sign-off. |
| 3. Data quality blockers resolved | Data owner and quality lead | Mandatory fields, dates, identifiers, terminology crosswalks, and timeline consistency pass for the production candidate extract. | Unresolved fatal/error validation issue or unowned mandatory-field gap remains. | Data quality remediation tracker, source preflight report, and final validation report. |
| 4. Mappings approved | Clinical owner, data owner, FHIR lead | Source-to-FHIR mappings for required and conditional fields are reviewed, approved, or formally deferred. | Required field mappings remain draft or clinical mappings lack owner approval. | Mapping workbook export, approval status, and decision notes. |
| 5. Terminology governance complete | Terminology lead and clinical owner | Local source codes are inventoried, mapped, approved, and retained with a package-aligned terminology snapshot. | Required coded fields have unmapped production values without accepted remediation. | Terminology catalogue export, crosswalk, self-check result, and approval log. |
| 6. Validation evidence accepted | QA lead and FHIR lead | Source preflight, conversion traceability, local requirement validation, structural validation, package validation, and terminology validation are retained. | Validation reports cannot be reproduced or show unresolved fatal/error items. | Validation evidence package, OperationOutcome diagnostics, and issue disposition log. |
| 7. Interface-engine dry run accepted | Integration lead and operations lead | Live Feed can queue, process, and record mock/dry-run jobs with traceable Bundle IDs, attempts, statuses, and diagnostics. | Jobs fail without actionable diagnostics or accepted jobs cannot be traced to source rows and Bundles. | Feed job export, attempt history, dry-run response, and support notes. |
| 8. Transport and credentials approved | Integration lead and security lead | Endpoint, token ownership, rotation, timeout, retry, support contacts, and live-mode enablement procedure are approved. | Credentials are unmanaged, endpoint is not approved, or live mode can be enabled without go/no-go approval. | Transport checklist, credential owner register, and endpoint approval notes. |
| 9. Operations and hypercare ready | Operations lead and support lead | Daily queue review, incident triage, retry/replay procedure, escalation path, and release notes are prepared. | No named support owner, no incident procedure, or no monitoring process exists for failed/retrying jobs. | Hypercare plan, support roster, incident playbook, and queue review schedule. |
| 10. Final go/no-go recorded | Executive sponsor | Business, clinical, data, privacy, security, FHIR, integration, and operations owners record final readiness decision. | Any required owner has not signed off or has open blocker conditions. | Go/no-go record, owner sign-offs, final evidence pack, and launch decision. |