Canonical Data Model & Integration Architecture for Senior Housing & Care
Senior housing and care data is integrated into six canonical entities — Resident, Care Plan, Ledger, Shift, Property/Unit and Entity — each with one declared grain, one identity rule and one definition per attribute, however many systems supply it. Those entities sit inside a five-layer architecture: source systems stay unchanged and are read one direction; raw payloads land immutably with lineage attached at the boundary; fields are mapped to canonical entities; totals are reconciled to the general ledger, payroll and the unit inventory and conflicts are resolved by an authority rule that r…
On this page
Read the diagram top to bottom. Each arrow is a boundary where something is added — lineage, canonical meaning, reconciliation, authority — and never a boundary where something is quietly overwritten.
A model is only governable if its grain is stated. The last column is where integration projects actually fail: attributes two systems both believe they own.
One canonical attribute may have many sources and exactly one definition. The authority rule and the reconciliation test travel with it.
Each row states what is read together, on what interface class, on what join key, and what must reconcile before a blended figure is published.
Vendor names are used nominatively; coverage is scope, not a deployment claim.
A canonical model owned by a vendor is a vendor’s opinion about your business. The definitions, authority rules and lineage are the operator’s, and they leave with the operator.
Key points
- A small, fixed set of entities that every source system is mapped into, so a resident, a shift or a ledger posting means the same thing regardless of which system reported it. In senior housing and care those entities are Resident, Care Plan, Ledger, Shift, Property/Unit and Entity. The value is not the schema — it is that one attribute has exactly one definition and one authority rule even when…
- Because the contested numbers in this sector resolve inside those six. Occupancy needs Resident and Property/Unit. Labour needs Shift and Entity. Margin needs Ledger and Entity. Acuity needs Resident and Care Plan. A larger model adds mapping surface without adding governability, and every unnecessary entity is another place where two systems can disagree unobserved.
- Resident is one row per person per stay, not per system record. Care Plan is one row per plan version, versions retained. Ledger is one row per posted transaction in the period it belongs to. Shift is one row per scheduled or worked segment. Property/Unit is one row per unit with status history. Entity is one row per legal or reporting entity with ownership and period history.
- At ingest, not on request. Every admitted field carries its source system, source identifier, interface and extraction timestamp, retained alongside the raw payload as received. That is what allows a published figure to be traced backwards, and what allows a restatement to appear as a restatement instead of quietly replacing history.
- Not by default. Reads are one direction so that source systems remain the operator’s own systems of record and there is never a second competing writer. Where a write-back is genuinely useful, it is scoped to named fields and a named direction and requires written operator authorisation.
- Above the governed record and after reconciliation, never before it. AI can propose; the operator governs. Consequential clinical and regulatory pathways are deliberately not automated, and model outputs read the governed record rather than the raw sources so that a proposal inherits definitions and lineage rather than inventing them.
- No. The connector framework is stated at its published maturity state and has been exercised against synthetic fixtures. No third-party integration runs in operator production, and no operator runs the platform in production. Capability and evidence are kept separate on the Trust Center and the Evidence Record.
Frequently asked questions
- What is a canonical data model in senior housing & care software?
- A small, fixed set of entities that every source system is mapped into, so a resident, a shift or a ledger posting means the same thing regardless of which system reported it. In senior housing and care those entities are Resident, Care Plan, Ledger, Shift, Property/Unit and Entity. The value is not the schema — it is that one attribute has exactly one definition and one authority rule even when four systems supply it.
- Why six entities rather than a full enterprise data model?
- Because the contested numbers in this sector resolve inside those six. Occupancy needs Resident and Property/Unit. Labour needs Shift and Entity. Margin needs Ledger and Entity. Acuity needs Resident and Care Plan. A larger model adds mapping surface without adding governability, and every unnecessary entity is another place where two systems can disagree unobserved.
- What is the grain of each entity?
- Resident is one row per person per stay, not per system record. Care Plan is one row per plan version, versions retained. Ledger is one row per posted transaction in the period it belongs to. Shift is one row per scheduled or worked segment. Property/Unit is one row per unit with status history. Entity is one row per legal or reporting entity with ownership and period history.
- How is data lineage recorded?
- At ingest, not on request. Every admitted field carries its source system, source identifier, interface and extraction timestamp, retained alongside the raw payload as received. That is what allows a published figure to be traced backwards, and what allows a restatement to appear as a restatement instead of quietly replacing history.
- Does the architecture write back into source systems?
- Not by default. Reads are one direction so that source systems remain the operator’s own systems of record and there is never a second competing writer. Where a write-back is genuinely useful, it is scoped to named fields and a named direction and requires written operator authorisation.
- Where does AI sit in this architecture?
- Above the governed record and after reconciliation, never before it. AI can propose; the operator governs. Consequential clinical and regulatory pathways are deliberately not automated, and model outputs read the governed record rather than the raw sources so that a proposal inherits definitions and lineage rather than inventing them.
- Is this architecture running in an operator production environment today?
- No. The connector framework is stated at its published maturity state and has been exercised against synthetic fixtures. No third-party integration runs in operator production, and no operator runs the platform in production. Capability and evidence are kept separate on the Trust Center and the Evidence Record.
https://seniorcre.com/senior-living-data-integration/canonical-data-model