Data Governance
How to build a scalable data governance framework for multi-site senior housing operators?
Clicks …Last reviewed
Direct answer
Build a portfolio-wide definition-and-authority register for the figures executives use. Name an accountable owner and community steward, declare the source for each reporting purpose, document reconciliation and approval rules, and restrict sensitive information by role and community. Preserve source-to-report lineage and version every change. Onboard each new site through approved mappings and recorded exceptions. Scale shared standards—not undocumented local conventions—while leaving communities accountable for their own records.
The executive view
Centralize the meaning of reported figures, not every local workflow. A community can keep its own intake process or software configuration while meeting the same portfolio reporting rules. Executives own definitions and decision rights; community stewards investigate source discrepancies and maintain mappings. The test is whether another qualified person could reproduce an approved report from its retained sources, rules and approvals without relying on the departing controller’s memory. Coherence before Intelligence.
Why this happens
Multi-site operators accumulate local conventions — how hospital leave is counted, which pay codes are labor, when a move-in is recognized. Each site is internally consistent and the portfolio is not.
A policy alone does not resolve an exception. A scalable framework also needs clear ownership, protected access, an escalation path and retained evidence. Start with a small set of decision-critical figures rather than trying to govern every field at once.
A practical portfolio governance playbook
Use this as an operator-led planning sequence for senior housing & care. Start with a disputed occupancy, workforce or financial figure in a representative community, prove the method with historical records, and expand only after the accountable owners accept it. The role assignments below are examples for the operator to approve.
Assign portfolio ownership and community stewardship
Inventory the decisions and reports that depend on occupancy, census, payroll, care-level revenue and the GL. For each domain, name one accountable executive, a community steward who investigates discrepancies, a technical custodian and a backup approver. Write who may propose, approve and escalate a change. System administration is not authority over a business definition.
Accountable owner: Executive sponsor and domain leaders; for example, the CFO for financial reporting, COO for operations and clinical leader for clinical measures.
Acceptance check: Each governed figure has a named owner, local steward, delegate and escalation destination; no unresolved issue is assigned only to “IT” or “the community.”
Publish purpose-specific definitions and source authority
Record each metric’s purpose, numerator, denominator, inclusions, exclusions, reporting cutoff, time zone, source and approver. Distinguish occupied units from physical residents and billable days. Distinguish worked hours, paid hours and agency hours. Map owner-agreement definitions separately where needed; never average incompatible figures into one apparently consistent number.
Accountable owner: Domain owner approves; community stewards explain local conventions and maintain the mappings.
Acceptance check: Two reviewers can calculate the same figure for the same purpose and period from the written definition. Legitimate differences between staffing, billing and owner reporting remain visible.
Protect information before connecting systems
Classify resident, clinical, employee and financial information. Grant only the data and actions needed for an approved role, community and purpose; separately approve portfolio-wide and external access. Document joiner, role-change and leaver reviews, export permissions, retention and incident escalation. Evaluate HIPAA applicability for the actual entity and relationships rather than assuming every senior housing community is a covered entity; address applicable state law and contracts with qualified advisers.
Accountable owner: Privacy/security lead with domain owners and qualified legal advisers.
Acceptance check: Test permitted and denied access, community boundaries, revoked accounts and exports before using identifiable records. Required agreements and retention decisions are documented. A policy or framework is not proof of legal compliance.
Map systems without erasing local accountability
Inventory approved EHR, CRM, scheduling, payroll and accounting sources and record IDs, field meanings, update cadence and extraction permissions. Map each community’s codes and dates to the shared dictionary while preserving its original values. Local workflows may differ, but departures from reporting standards need a documented exception, owner, reason and review date. Connectivity and interoperability standards move information; they do not decide which figure governs.
Accountable owner: Technical custodian and community steward, with approval from the domain owner.
Acceptance check: Each report input has a documented source and mapping; missing or stale feeds are visible. Test on approved historical or synthetic records before permitting live use.
Reconcile by record and route exceptions
Compare resident, unit, pay-period or GL records at the same cutoff. Check completeness, duplicates, stale data and unexpected changes. Classify differences as timing, definition or error; set operator-approved tolerances and escalation priorities. Automate checks only after rules are tested. Assign exceptions to people, retain their decisions, and require approval before a provisional figure becomes an accepted report.
Accountable owner: Community steward investigates; the accountable domain approver accepts the result.
Acceptance check: A test set containing known discrepancies produces the expected exceptions. Material unresolved differences remain flagged or withheld under the approved policy—not silently treated as reconciled.
Retain lineage and control definition changes
Keep the source snapshot, mapping and definition version, reconciliation result, exception resolution, approver and timestamp beside the report version. A proposed rule change needs an impact review, effective date, approval and communication to affected communities. Preserve prior reports and disclose restatements; do not overwrite the history to make periods appear comparable.
Accountable owner: Domain owner approves changes; reporting and technical custodians retain the evidence.
Acceptance check: A reviewer can reproduce a sampled historical figure using the retained inputs and exact rule version, and identify who approved it and why any later version differs.
Accept acquired communities through a repeatable checklist
At acquisition or management transition, inventory sources, confirm lawful access, assign stewards, map definitions and codes, test permissions, and run a parallel reporting cycle. Keep unmapped inputs and transitional figures clearly labelled. Review local exceptions against owner agreements. Do not blend unaccepted ratios into comparable portfolio reporting; preserve required accounting and owner reporting with clear qualifications. A genuinely new requirement may justify a reviewed portfolio rule change.
Accountable owner: Transition lead coordinates; each domain owner signs off its mappings and the executive sponsor accepts the reporting scope.
Acceptance check: Required mappings, access tests, exception handling and source-to-report samples are accepted before the site joins comparable reporting. The checklist—not a promised number of weeks—determines readiness.
Measure the process and review it as the portfolio grows
Baseline the measures below using actual records before extending automation or adding communities. Review overdue exceptions and changed definitions with domain leaders, and re-test after software, ownership or staffing changes. Require vendors to demonstrate mappings, denied access, retained lineage and reproducible reports on authorized data; request evidence for each function instead of accepting a generic platform claim.
Accountable owner: Executive sponsor and domain owners, at an operator-approved review cadence.
Acceptance check: Measures have a consistent definition, accountable owner and baseline. Expansion follows accepted evidence; no reduction in cost, staffing or reporting effort is assumed.
Measures to baseline before expanding
- Approved definition coverage: governed figures with a current definition, source authority and approver divided by all in-scope figures.
- Exception workload: new, recurring and overdue exceptions per community and reporting cycle; track age and priority separately.
- Reproducibility: sampled approved figures that can be rebuilt from retained sources and exact rule versions.
- Change and access discipline: overdue access reviews, unresolved permission-test failures and unapproved definition changes.
- Onboarding acceptance: outstanding mappings and evidence checks by domain; record time to acceptance without turning it into a delivery promise.
This is educational governance guidance, not legal advice, clinical instruction, a compliance certification or evidence of implemented SeniorCRE controls. Software selection, live connectivity and production use require function-specific testing, security/privacy review and operator acceptance. Clinical decisions remain with authorized professionals; reporting reconciliation never authorizes a medication-record change. Benefits must be measured on the operator’s own records.
Hypothetical example: adding site 31 to a written framework
Definition register
12 governed figures
Unchanged by the new site
Site 31 mapping
3 local differences
Hospital leave, agency pay codes, move-in date
Rule changes needed
0
All three differences fit existing rules
Comparable reporting
Held pending acceptance
Mappings, access tests and reconciliation require sign-off
- Evidence
- Disagreement
- Authority
- Operator-Controlled Operating Record
- Intelligence
- Execution
Illustrative figures. Coherence before Intelligence.
Hypothetical scenario, not a measured result or delivery timeline. Site 31’s three local differences fit the existing register, but its figures remain labelled transitional until the relevant domain owners accept the mappings and review evidence. If a new owner agreement requires a different definition, approve and version the change rather than forcing it into an unsuitable rule.
The governance question
Governance answers four questions for every important measure: what it means (definition), which system is authoritative for it (authority), how disagreements are resolved (reconciliation), and how anyone can trace the result back (lineage).
Evidence → Disagreement → Authority → Operator-Controlled Operating Record → SeniorCRE Intelligence → Execution
What good operating infrastructure should do
- A register of approved definitions, owned by named people.
- Explicit source-authority rules per measure and per decision.
- A reconciliation process that records outcomes, not just corrections.
- Lineage from every reported number back to its sources.
- Change control when a definition or authority rule changes.
SeniorCRE perspective
SeniorCRE treats governance as the operator’s function, not the software’s. Its architecture encodes Definition, Authority, Reconciliation and Lineage as first-class records, so integration supplies evidence and the operator decides what governs. Unified data is not the same as governed truth. Status: the Operator-Controlled Operating Record is designed and not yet implemented in any community. Current capability states and production-entry gates are published in the Evidence Record at the Trust Center; nothing here should be read as a production result.
Sources and scope
References support only the scope described below, not independent product validation or endorsement.
- HHS: Covered Entities and Business Associates
HIPAA applies to covered entities and business associates as defined by the rules; a senior housing label alone does not establish applicability.
- NIST Privacy Framework
A voluntary tool for identifying and managing privacy risk, not a certification or guarantee of compliance.