Governance areas
Use this guide to keep local codes, official package references, crosswalks, and validation evidence aligned.
| Area | Purpose | Action | Decision rule | Evidence |
|---|---|---|---|---|
| Catalogue inventory | Maintain a local view of code systems, value sets, official references, local source codes, and crosswalks. | Load or review terminology references in Terminology, then export the catalogue before each validation cycle. | No coded production field should be accepted without a source, version, owner, and mapped target or gap disposition. | Terminology catalogue export and version register. |
| Local source-code intake | Capture codes from hospital systems exactly as they appear before mapping or normalization. | Collect source values with frequency counts, source-system names, labels, and sample contexts. | High-frequency and mandatory-field codes are mapped first; unknown values require owner review before production. | Source-code inventory with counts, labels, and owners. |
| Crosswalk design | Map local source codes to target controlled values, FHIR code systems, or documented local extensions. | Create crosswalk rows with source code, target system, target code, display, rationale, reviewer, and status. | Approved mappings need clinical/data owner review; provisional mappings can support testing only. | Crosswalk export, approval status, and reviewer comments. |
| Value-set binding review | Separate required bindings, preferred bindings, extensible bindings, and implementation-specific local lists. | Review validation output and mapping notes to classify how strict each coded field must be. | Required bindings block production when unmapped; warnings on less strict bindings need documented disposition. | Binding review notes and validation issue classification. |
| Clinical owner approval | Ensure sensitive or clinically meaningful mappings are not approved by technical teams alone. | Assign clinical owners for diagnosis, clinical concern, substance use/addictions, service modality, and SDOH-coded values. | Clinical mappings are approved only when owner, date, rationale, and local policy implications are recorded. | Clinical approval log and retained crosswalk version. |
| Package and dictionary alignment | Keep terminology aligned to the same Ontario MHA PDS package and data dictionary version used for validation. | Record package version, data dictionary version, import date, and source URL/path for each terminology refresh. | Do not mix terminology from a newer or older package into a production candidate without formal impact review. | Package metadata, import log, and impact assessment. |
| Unknown and not-collected values | Handle missing, unknown, not asked, not applicable, declined, and no-reason values consistently. | Define local rules for nulls and exceptional values before conversion and validate them against PDS requirements. | A missing value is not the same as an explicit unknown/declined value; each requires the correct coded representation. | Null/exception policy and sample validation outputs. |
| Change control | Prevent silent drift when local systems add, retire, or relabel codes. | Schedule recurring source-code extracts, compare to the approved catalogue, and triage new/unmapped values. | New production codes require mapping review before they are accepted into live submissions. | Change log, new-code report, and approval record. |
| Audit and retention | Retain enough history to explain which terminology version was used for a submitted Bundle. | Store terminology exports with validation reports, conversion jobs, and go/no-go evidence packs. | Every production submission batch must be reproducible against a retained terminology snapshot. | Terminology snapshot ID, validation report, and submission batch record. |