Implementation phases
Use these phases to move from tenant setup and standards readiness through conversion, validation, transport, and hypercare.
| Phase | Owner | Work | Acceptance criteria | Evidence |
|---|---|---|---|---|
| 1. Confirm sponsorship and tenant setup | Executive sponsor, implementation lead, administrator | Name the implementation owner, define tenant boundaries, confirm privacy/accountability contacts, and configure the production tenant before PHI or customer files are used. | Tenant record exists, users are assigned to roles, demo-only access is disabled for customer production use, and RLS evidence is captured. | Tenant setup record, role matrix, access approval, and RLS test notes. |
| 2. Pin the authorized standards package | FHIR lead, data standards owner | Confirm the Ontario MHA PDS data dictionary, FHIR implementation guide, terminology package, and validator package version used for the implementation. | Settings show the intended version, local package metadata is recorded, and the team knows which official materials cannot be redistributed publicly. | Package/version register, Settings export, and checksum or source-path notes where available. |
| 3. Complete source-system inventory | Hospital data lead, integration lead | List source systems for organization, client, SDOH, referral, program, clinical summary, substance use/addictions, problem gambling, and encounter domains. | Every required field has a named source, accountable owner, extraction method, and known data-quality limitation. | Source inventory workbook and unresolved gap log. |
| 4. Complete template readiness | Data analyst, quality lead | Download the controlled template, verify mandatory and conditional fields, preserve column names, and run the template self-check before the first conversion. | Template contains the full required field set and a populated test row with no structural errors. | Template workbook, self-check export, and sample-row review notes. |
| 5. Approve mappings | Clinical owner, FHIR lead, data owner | Review each source-to-FHIR mapping, target path, rule, cardinality note, and decision status in the Mappings workbench. | Mandatory fields are approved or explicitly deferred with owner/date, and unresolved mappings are not accepted for production. | Mapping export with approved/review statuses and sign-off notes. |
| 6. Build terminology crosswalks | Terminology lead, clinical owner | Load local code tables, map local values to accepted terminology or controlled PDS values, and document unmapped or local-only values. | Terminology self-check passes for configured local catalogues, and every warning has an owner and disposition. | Terminology export, crosswalk file, and warning triage log. |
| 7. Run a demo conversion | Implementation analyst, QA lead | Use the demo data and then a de-identified customer extract to generate FHIR Bundles from the conversion workflow. | Expected row count becomes expected Bundle count, import issues are explained, and generated resources can be traced to source fields. | Conversion summary, Bundle JSON, import issue report, and traceability notes. |
| 8. Validate and triage findings | FHIR lead, QA lead | Run validation against local requirements and the configured package/validator where available, then classify fatal, error, warning, and information messages. | No unresolved fatal/error items remain for the production candidate extract; warnings are accepted or remediated. | Validation report, issue log, and remediation decisions. |
| 9. Test interface-engine workflow | Integration lead, operations lead | Submit a canonical source row through Live Feed, queue it, process the next job, and review mock or dry-run transport results. | Jobs move through queued, validating, submitting, and accepted/mock-accepted states with traceable identifiers. | Feed activity export, job ID, Bundle ID, OperationOutcome, and retry/attempt history. |
| 10. Complete privacy and security readiness | Privacy officer, security lead, administrator | Confirm tenant isolation, PHI minimization, retention rules, audit logging, access reviews, and incident response expectations. | No production PHI is loaded until access, retention, audit, and operations controls are accepted. | Security checklist, privacy sign-off, audit export, and access review. |
| 11. Prepare Ontario Health transport go/no-go | Executive sponsor, integration lead, FHIR lead | Confirm endpoint, credentials, onboarding expectations, dry-run evidence, support contacts, submission windows, and rollback plan. | A signed go/no-go decision exists before live transmission is enabled. | Transport checklist, dry-run evidence, endpoint/token governance notes, and go/no-go record. |
| 12. Run hypercare and evidence review | Operations lead, quality lead | Monitor submissions, review validation drift, track incidents, refresh terminology/package changes, and schedule evidence review. | Daily review is in place for the first production period and unresolved production defects have owners and due dates. | Hypercare tracker, daily queue review, issue register, and release notes. |