How Operators Govern Data Across Multiple Systems: A Practical Playbook for Senior Housing & Care

A typical operator runs separate systems for clinical records, billing, payroll, scheduling, accounting and sales. Each was chosen for good reasons, and each keeps its own version of residents, units and employees. Senior care data governance is the discipline of deciding which version governs, who decides, and how anyone can check. Six problems show up again and again.

1. 1. Conflicting records across clinical, financial, and workforce systems

   The same resident, unit or shift appears differently in each system, so leadership debates which number is right instead of acting on it.

2. 2. Unclear accountability for correcting errors

   When no one owns a field, errors are noticed repeatedly and fixed rarely, and the same discrepancy returns every month.

3. 3. Inconsistent definitions across communities and platforms

   Portfolio roll-ups combine figures computed different ways, so comparisons between communities look precise but are not comparable.

4. 4. Manual reconciliation that delays portfolio reporting

   Analysts spend the first part of every month rebuilding spreadsheets, and owners and lenders receive reports late and with caveats.

5. 5. Limited visibility into data access and changes

   When a figure changes after the fact, no one can show who changed it, when, or why, which weakens audit and survey readiness.

6. 6. Vendor restrictions on data access and portability

   Fees, closed formats or missing APIs keep the operator from using its own data, and switching systems becomes a data-loss risk.

The steps below build on one another. Ownership comes first because every later decision needs someone with the authority to make it. Each step links to a supporting guide with a more detailed how-to.

Start by identifying the business decision the governed field must support. A staffing review, a billing close and a portfolio occupancy report can require different populations and time boundaries. Ask whether competing records actually describe the same measure before treating the difference as an error. Separate a definition dispute from a late update, an unmatched identifier and a missing connection. Each needs a different response: an owner ruling, an agreed timing window, a steward’s mapping review or an integration task. The six steps provide the controls around that work; they are not a reason to hold recurring governance meetings when a documented policy already decides.

1. Step 1

   Assign data ownership and stewardship by domain

   Divide the operating data into domains — clinical, payroll and workforce, financial, census and occupancy, and CRM — and name one accountable owner for each. The owner decides what the domain's figures mean and approves changes to them. A steward, usually closer to daily work, maintains quality, answers questions and routes corrections. Ownership is a decision right, not a job title: a regional director of operations may own census while a payroll manager stewards it.

   Who owns it

   The executive team assigns owners; each owner names stewards.

   What done looks like

   Every domain has one named owner and at least one steward, published where every analyst and community leader can see it.

   Common failure

   Naming a committee as the owner. When everyone owns a domain, no one has the authority to settle a disagreement.

   Read the guide to data ownership & stewardship

2. Step 2

   Publish a portfolio data dictionary with consistent definitions

   List the terms that appear in portfolio reporting — occupancy, move-in, move-out, length of stay, agency hours, care-level revenue — and publish one governing definition for each, with its formula, source system, timing and exceptions. Pair the dictionary with master identifiers for residents, units, employees and communities so the same entity carries the same key everywhere. The dictionary is the reference every report must cite.

   Who owns it

   Domain owners approve definitions; a data governance lead maintains the dictionary.

   What done looks like

   Each reported term links to one published definition with an owner, an effective date and a change history.

   Common failure

   Writing definitions that describe what each system already does instead of choosing which one governs.

   Read the guide to master data management

3. Step 3

   Set role-based access controls and review them quarterly

   Define roles by the work people do — community nurse, business office manager, regional finance, executive — and grant each role the least access that work requires. Map roles to permissions in every system so the same person does not hold broader access in one platform than another. Review access every quarter and remove it promptly when people change roles or leave.

   Who owns it

   Domain owners approve access for their data; IT or security administers it.

   What done looks like

   A current role matrix exists for each system, and the last quarterly review is signed off with exceptions recorded.

   Common failure

   Granting access person by person, so permissions accumulate and no one can explain why a user can see payroll.

   Read the guide to access controls

4. Step 4

   Establish cross-system reconciliation rules and a close calendar

   For each governed field, state which system is the system of record and which other systems must agree with it, within what tolerance. Put the comparisons on a fixed calendar — daily for census, per pay period for labor, monthly for revenue — and route every break to the field's steward with a due date. Reconcile once under governed rules, then stop re-reconciling the same figure downstream.

   Who owns it

   Stewards run the reconciliation; owners approve tolerances and resolve escalations.

   What done looks like

   Breaks are logged, assigned and closed on schedule, and the close calendar is met for [number] consecutive periods.

   Common failure

   Correcting the report instead of the source record, so the same break reappears next period.

   Read the guide to data quality & reconciliation

5. Step 5

   Capture lineage and audit trails so every figure traces to its source record

   Record where each reported figure came from: the source system, the record, the definition applied, the reconciliation it passed and who approved it. Keep an audit trail of every change to governed values — previous value, new value, user, time and reason. When a lender, surveyor or board member asks how a number was produced, the answer should be a lookup, not a reconstruction.

   Who owns it

   The data governance lead designs lineage; stewards attach evidence; owners approve.

   What done looks like

   Any figure in a portfolio report can be traced to its source records and its change history within [time placeholder].

   Common failure

   Keeping lineage in an analyst's spreadsheet, so it disappears when that person leaves.

   Read the guide to audit trails & lineage

6. Step 6

   Enforce portfolio-wide policy and hold vendors to data rights

   Write the rules above into a portfolio data policy that applies to every community and every vendor. Contracts should confirm that the operator owns its data, can export it in open formats, can reach it through documented APIs and can see the audit trail. Require notice before vendors change data structures, and require full data return at termination. Review compliance at renewal.

   Who owns it

   The executive team adopts the policy; legal and procurement enforce it in contracts.

   What done looks like

   Every system that holds governed data has a contract that meets the vendor requirements checklist, or a recorded exception with an end date.

   Common failure

   Negotiating data rights only at renewal, after the operator has lost leverage.

   Read the guide to vendor accountability

Rehearse the first governed field

Use fictional records for a tabletop exercise before handling sensitive operational data. Present two assertions for the same entity and period, together with their extraction times and definitions. Ask the steward to locate the rule, the owner to resolve any unaddressed question and the authorized custodian to describe the correction procedure. Retain both original assertions, the accepted representation and the reason it governs. An unresolved exception remains visible and the affected value stays provisional; it should not be converted to zero or marked accepted simply because a reporting deadline has arrived.

The acceptance packet should include the approved definition, source-authority assignment, identifier crosswalk, access review, comparison record, exception resolution and report reference. Have someone who did not prepare the result explain it using that packet. Record any missing evidence and assign the next action. Keep response times, tolerances and required consecutive periods as labeled approval blanks. Completing a template is not the same as completing the exercise, and completing an exercise is not evidence of production deployment. Expand scope only after the accountable owners can show what was actually accepted and what remains unresolved.

Three working templates support the playbook. Exhibit 1 assigns accountability by domain. Exhibit 2 lists terms that are commonly computed more than one way. Exhibit 3 shows how a reconciliation matrix names a system of record for each field. Bracketed values are for your organization to decide.

Use the templates as one connected register

Give the definition entry a stable reference and link that reference to the accountable owner and reconciliation rule. Include a version and effective period so an earlier report can be explained after the definition changes. The owner column identifies a decision right; the approver column identifies any separate review required by the organization. It does not transfer clinical authority to finance or grant report consumers permission to edit source records. The sample job titles are illustrative roles, not appointments or an organization chart that every operator must adopt. Record the actual assignments only after the executive team approves them.

Treat the system-of-record column as field-specific source authority, not a declaration that one database is right about everything. Preserve physical census, billed days and signed agreements as distinct assertions when their purposes differ. Confirm that cross-system comparisons use matching identifiers and periods. Retain the source extract or an authorized reference, the filters applied and the result of the comparison. If a later adjustment changes a closed period, link it to the earlier accepted report and retain its approver and reason. The register should explain a determination without silently rewriting its history.

Many governance programs stall because they begin with a replacement project. The thinking is that data will be consistent once everything runs on one platform. In practice, replacement takes years, and the old disagreements often move into the new system.

The alternative is a governance layer over the systems already in place. It pulls records from each system, applies the published definitions, reconciles fields against the named system of record and attaches evidence to each resulting figure: its sources, the definition applied, the reconciliation it passed and who approved it. The Operational Evidence Layer and Evidence Card describe supporting evidence concepts, not another product name or a claim of a live automated integration.

Coherence before Intelligence. Replacing a system is always the operator's decision, made on its own merits. It is never a precondition for governing the data. Operators can keep the systems they run today and govern what those systems produce, or, where it makes sense, choose to run SeniorCRE itself as the system of record. Either way, reconcile once under governed rules and stop re-reconciling downstream.

Deployment choice does not remove acceptance gates. For the keep-your-systems path, identify how each source becomes available, who authorizes its use and which fields are included. Do not assume a named connector exists because a system appears in a diagram; connectors remain roadmap unless separately supported by current evidence. For the run-on-SeniorCRE path, define the function, migration boundary and required operational approvals before relying on it as the system of record. SeniorCRE includes its own EHR and eMAR in that configuration choice; medication work still requires build and clinical sign-off, and only one medication administration record may be authoritative. Neither path is a promise of an accepted clinical deployment.

Every system holding governed data should meet these six requirements, written into the master agreement.

• Data ownership clause. The contract states that the operator owns all data it and its residents generate in the system.
• Export rights in open formats. Full exports in documented, non-proprietary formats (such as CSV or JSON), on request, without punitive fees.
• API access. Documented APIs for reading governed data, with stated rate limits and no unreasonable access charges.
• Audit-trail access. The operator can read who viewed and changed records, when, and what changed.
• Change notification. Advance written notice before changes to data structures, field meanings or API behavior.
• Termination data return. Complete data return in an open format within a defined period after termination, then certified deletion.

For contract scoring and portability tests, see the vendor accountability guide.

Verify the rights with a usable export

Ask for a synthetic export that includes identifiers, relationships, corrections and the history needed to reconstruct the agreed reporting measure. Open it outside the vendor’s application and compare the returned records with the test inventory. Check whether field meanings, timestamps, attachments and deleted-record states are documented. A file that downloads successfully can still be incomplete for the intended purpose. Record limitations, additional permissions and any dependency on proprietary software. Keep demonstrations of current capability separate from promised roadmap work, and obtain legal and security review before accepting a gap.

The checklist is an educational review worksheet, not counsel-approved contract language. Operators must review their agreements and applicable resident, employee and third-party rights. Cross-operator sharing requires each operator’s consent; an export clause does not grant that consent. Leave return periods, retention requirements and approved recipients as explicit blanks until decided. Before a real transition, test a fictional termination package for completeness and readability, retain the findings and assign any remedial action. A contractual right and evidence that the configured delivery works are different artifacts, and both matter.

No two programs cost the same, and any estimate offered before an inventory of your systems and reports is a guess. Five factors drive the scope.

• Number of systems. Each system that holds governed data needs a connection, a field map and reconciliation rules.
• Number of communities. More communities mean more local variation in definitions and more stewards to coordinate.
• Current data quality. Long-standing breaks and duplicate identifiers must be cleaned before governed figures can be trusted.
• Integration depth. Reading summary reports costs less than reading source records with full lineage and change history.
• Internal stewardship capacity. Programs move faster when owners and stewards have time set aside; outside help fills the gap at extra cost.

Most operators begin with a bounded first phase covering a few high-value fields, such as census and agency hours, and expand once owners, stewards and the close calendar are working.

• Data Ownership and Stewardship: Assigning Accountability by Domain

  How senior housing & care operators assign data owners and stewards by domain so every reported figure has someone accountable for it.

• Access Controls for Operators: Role-Based Access, Least Privilege and Quarterly Reviews

  How senior housing & care operators set data ownership and access controls across systems: role-based access, least privilege and quarterly reviews.

• Data Quality and Reconciliation: Getting Systems to Agree on a Fixed Calendar

  How operators improve data quality and reconciliation across census, billing, payroll and accounting with a system of record and a close calendar.

• Master Data Management: Resident, Unit, Employee and Community Identifiers

  How operators manage master data — resident, unit, employee and community identifiers — and a portfolio data dictionary that keeps definitions consistent.

• Audit Trails and Lineage: Tracing Every Figure to Its Source Record

  How operators capture data lineage and audit trails across multiple platforms so every reported figure traces to its source records and approvals.

• Vendor Accountability: Contract Clauses, Data Portability and Integration Compatibility

  What senior housing & care operators should require from vendors: data ownership, open-format exports, API and audit-log access, and data return.

Related: cross-system data governance runbook and the definition and authority register.