Definition migration
The risk is not just data migration. It is definition migration. Worked example: All Age MH Access moving from case-based Legendary Care to action-based PathwayOne.
What I hope to achieve
Agreed KPI and pathway definitions that still answer the service questions after the source model changes — signed off by service, BI, IM&T and performance colleagues, with reconciliation evidence for mandatory and local reporting months.
My approach to succeed
Test multiple definition options against known patients and old-system outputs while both feeds are available; reconcile monthly; mark reporting confidence; facilitate agreement on what each report must mean before embedding logic in the warehouse or dashboards.
Definition chain: A measure is only safe to use when we can trace it from the real service event, through system capture and data logic, into the final report and the action taken from it.
Service reality
System capture
Source data
Warehouse logic
KPI / report
Validation & sign-off
Management action
Case-based vs action-based
Legendary Care holds one case record per pathway. PathwayOne holds separate access, care, outcome and admin actions. Mandatory and local reporting still need case-like answers.
Old — Legendary Care (case)
One row: referral date, status, contacts, outcome, closure, team, reporting month.
New — PathwayOne (actions)
Many rows: ACCESS_*, CARE_*, OUTCOME_*, ADMIN_* events — no single case object.
B: Parallel Dec–Jan
C: Referral feed ends Feb
D: Definition crunch Mar
Full migration timeline
Layered definition comparison
Each row shows the service question, how it was captured before and after migration, competing data definitions, the recommended reporting definition, and who must sign off.
| Service question |
Old case-based capture |
New action-based capture |
Competing definitions |
Recommended (OPT-C) |
Sign-off needed |
| When referred? | Staff open case; ReferralDate recorded | ACCESS_RECEIVED / ACCEPTED actions | OPT-A case date vs OPT-B accepted only | Hybrid: pre-Feb cases; post-Feb agreed access rules | Service lead + performance + mandatory |
|---|
| Rejected = received? | Rejected case still counts | ACCESS_REJECTED with reason code | Include all vs exclude all rejected | Exclude unless CLINICAL_TRIAGE | Clinical lead + performance |
|---|
| Pathway start? | PathwayStartDate on case | CARE_FIRST_CONTACT after acceptance | Access date vs first contact date | First contact after ACCESS_ACCEPTED | CMHT clinical lead |
|---|
| Reporting month? | ReportingMonth field on case | ActionDate per event | Event month vs facilitated rule | Rule per KPI in register | Performance lead + BI |
|---|
| Activity contacts? | ContactCount on case | CARE_ONGOING / CARE_FIRST_CONTACT | All actions vs clinical only | Exclude ADMIN_CANCEL and duplicates | CSDS owner + service manager |
|---|
Full layered KPI register
Anchor patient: DRH-PAT-002896
Rejected referral in December 2025 — old case counts as received; new default excludes unless triage reason applies.
Legendary Care case
| CaseId | Case LC-10001 |
|---|
| ReferralDate | 2025-12-08 |
|---|
| PathwayStatus | Rejected |
|---|
| OutcomeText | Wrong service |
|---|
| ReportingMonth | 2025-12 |
|---|
| Counts as referral (old) | Yes |
|---|
PathwayOne actions
| Action | Date | Include default |
|---|
| ACCESS_REJECTED | 2025-12-08 | No (CLINICAL_TRIAGE) |
Counts as referral (new default): No
legendary_cmht_cases.csv · pathwayone_actions.csv
Three definition options tested
I would not treat a new data model as automatically meaning the same thing in a different format. I would test whether it still answers the service question.
| Option | Mar 2026 referrals | Rule |
|---|
| OPT-A Old case | 151 | ReferralDate in month |
|---|
| OPT-B New actions | 168 | ACCESS_ACCEPTED in month |
|---|
| OPT-C Agreed hybrid | 134 | Pre-Feb old; post-Feb action rules with exclusions |
|---|
| Dashboard (legacy) | 154 | Blended pipeline — not reconciled |
|---|
Reconciliation reveal — March 2026
The dangerous point in migration is when the dashboard still refreshes, but the measure no longer means what people think it means.
| Source | Referral count | vs agreed |
|---|
| Agreed definition (OPT-C) | 134 | Baseline |
|---|
| Dashboard displayed | 154 | +15% (~+2% headline narrative) |
|---|
| Old case logic | 151 | +13% |
|---|
| New action default | 168 | +25% |
|---|
Executive dashboard — Low confidence Mar 2026
MHSDS-like — Medium
After reconciliation — High
reconciliation_monthly.csv ·
mhsds_like_reconciliation_summary.csv ·
fact_mh_referral_episode.csv ·
MHSDS-like Mar 2026 submission
Management action (Mar 2026): Withhold dashboard referral figure from Board; schedule directorate definition workshop; publish agreed 134 with reconciliation note only after sign-off.
Business & Performance facilitation
I would not just ask BI to fix the report. I would help the service, BI, IM&T and performance colleagues agree what the report now needs to mean.
Sign-off involves: service manager (operational reality), BI lead (implementation), IM&T (feeds and cutover), mandatory reporting owner (national returns), performance lead (local products), finance/workforce where capacity or cost narratives depend on the same definitions.
Evidence and reports ·
Data dictionary ·
Source-to-report map (referral preset)