Multi-state data governance
Governing one operating record across many states
Do not fork the record. A multi-state portfolio has one Operator-Controlled Operating Record with one authoritative source per field; state variation is carried as parameters and attributes of that field, applied when a report is produced, not as duplicate fields created at ingest. In practice that means three commitments: one portfolio definition per contested metric, with each state’s counting rule mapped into it and the raw source value retained; field-level lineage on every admitted value, so a state figure and a board figure can both be traced to the same origin; and a property-to-entity mapping held per effective date so a reorganisation never quietly restates history. Operators who instead let each state create its own field end up with several defensible numbers and no governed one.
- Rule
- One authoritative source per field, portfolio-wide
- State variation
- Carried as parameters at report time, not duplicate fields
- Lineage
- Source system, source identifier, interface, timestamp — field level
- Entity history
- Property → operating entity per effective date, retained
Evidence posture. Connector coverage below is stated at its Product Record state — the third-party source-system connector framework is BUILT as a framework and exercised against vendor-documented interfaces and synthetic fixtures. No third-party integration runs in an operator production environment. Read every connector row as scope, not as a deployment. Last reviewed August 30, 2026.
Architecture
Many jurisdictions, one record
Reads happen per system and per region. Governance happens once, above all of them, which is what keeps a portfolio figure and a state figure from becoming two unrelated truths.
Layer 1 — Source systems (unchanged)
Layer 2 — Immutable landing and lineage
Raw payloads retained as received, each field tagged with source system, source identifier, interface and extraction timestamp.
Layer 3 — Canonical entities
Layer 4 — operator-controlled operating record
Accepted value, rejected value, basis of acceptance and restatement history. When systems disagree, the operator governs.
Layer 5 — Consumers
Board and lender reporting, operating reviews, BI tools, and AI workflows that read the governed record rather than the raw sources. Govern the truth before you automate the decision.
Where states diverge
The six fields that break multi-state reporting
Each of these is a definition problem wearing a technical disguise. The governing rule in the right-hand column is what keeps one field from becoming several.
| Field | How states diverge | Governing rule |
|---|---|---|
| Census / occupancy | States and payers count differently around hospital leaves, respite stays, bed holds and licensed-but-unavailable units. | One census field, one operator definition, with state-specific counting held as attributes of that field — never as a second competing census field. |
| Level of care / acuity | Assessment instruments, scoring bands and the vocabulary used for the same clinical reality differ by state and by setting. | The operator declares a portfolio acuity scale; each state instrument maps into it with the raw source score retained alongside the mapped value. |
| Staffing hours and ratios | Which roles count toward a required ratio, and whether hours are measured per resident day or per shift, varies by jurisdiction. | Worked hours stay a single reconciled quantity; the inclusion rule is a state parameter applied at report time, not at ingest. |
| Incidents and reportable events | Reportability thresholds, categories and clocks differ, so the same event is reportable in one state and logged-only in another. | One incident record with the state reportability determination attached, including who made it and when. |
| Rate and revenue capture | Private-pay, Medicaid waiver and managed-care rate structures coexist across a multi-state portfolio. | Posted revenue stays authoritative in the general ledger; payer mix is an attribute of the Ledger entity, not a separate ledger. |
| Legal entity and licensure | Properties sit under different operating entities, license holders and management agreements, and those relationships change. | Every property maps to exactly one operating entity per effective date, with history retained so prior-period figures stay reproducible. |
Implementation
The phased sequence, applied across states
The same five phases as the pillar, with Phase 1 carrying the state-divergence inventory and Phase 3 reconciling per property and per state before any portfolio roll-up is published.
1.Phase 1 — Definitions
Goal. Settle what each number means before anything is connected.
- Write one definition per contested metric: occupancy, census, level of care, worked hours, agency hours, NOI.
- Name an accountable owner for each definition.
- Record which system the operator expects to be authoritative for each field.
- Capture the questions the board asks and the report each answer currently comes from.
Exit test. A written definition set with named owners, signed off by the operator — not by the vendor.
2.Phase 2 — Read-only connection
Goal. Read the source systems without touching them.
- Stand up read-only credentials or scoped extracts per source system.
- Map each source field to a canonical entity and attribute.
- Land raw source payloads immutably, with lineage metadata attached at ingest.
- Leave every source system as the operator’s own system of record for now.
Exit test. Source data lands with full lineage and no write path back into any source system.
3.Phase 3 — Reconciliation
Goal. Make disagreement visible instead of averaging it away.
- Reconcile period totals to the general ledger and to payroll worked hours within a written tolerance.
- Reconcile occupancy against the unit inventory and the billed roster.
- Route every unmatched or out-of-tolerance item to a named owner as an exception.
- Freeze a dated baseline before any derived metric is published.
Exit test. A reconciliation report the operator would hand to an auditor, with open exceptions listed rather than suppressed.
4.Phase 4 — Authority
Goal. Declare who governs each field when systems disagree.
- Set the authority rule per canonical attribute.
- Record the accepted value, the rejected value and the basis of acceptance.
- Publish the governed views the board and lenders read.
- Retain restatement history so a corrected number never silently replaces the number a decision was made on.
Exit test. One Operator-Controlled Operating Record the operator controls, with conflicts resolved by rule and by name.
5.Phase 5 — Coexistence or replacement, by choice
Goal. Decide the future of each source system on the operator’s timetable.
- Keep the incumbent system and continue reading one direction only, or
- Adopt the SeniorCRE clinical record — its own EHR and eMAR — as the clinical system of record,
- Maintain exactly one authoritative MAR at all times during any transition.
- Re-run reconciliation across the change so history stays comparable.
Exit test. A documented decision per system. Govern first; replace only by choice.
Decision
Keep or replace, per system class
A multi-state portfolio usually inherits duplicate systems by acquisition. Governing the record first means the consolidation decision can be made deliberately rather than under reporting pressure. See also integration without replacing your EHR.
| System class | Keep it when | Replace it when | True either way |
|---|---|---|---|
| EHR / eMAR | Clinical staff are fluent in it, survey history lives in it, and the interface exposes census, acuity and documentation reliably. | The operator chooses the SeniorCRE clinical record — its own EHR and eMAR — as the clinical system of record, typically to remove a documentation seam it is tired of reconciling. | Exactly one authoritative MAR at all times, before, during and after any transition. |
| CRM / sales | Pipeline discipline is already good and the sales team will not adopt a second surface. | Prospect records cannot be tied to the unit that was actually sold, so move-in forecasting is guesswork. | Prospect identity resolves to the same Resident entity as the admitted resident. |
| Payroll and time | It is the system of record for hours paid and the operator has no appetite to move payroll. | Rarely. Payroll replacement is a finance decision, not an integration one. | Payroll is authoritative for hours paid; the schedule is authoritative for intent. Both reconcile to one period. |
| Accounting / ERP general ledger | Almost always. The GL is the audited record and should stay where the auditors expect it. | Only on a finance-led ERP program with its own governance. | The GL stays authoritative for posted amounts; no derived metric publishes before the GL tie passes. |
| Property management | The unit inventory is accurate and licensure detail is maintained there. | Unit counts cannot be separated into physical, licensed and available, so occupancy has no stable denominator. | The property management system stays authoritative for unit inventory until the operator moves it. |
| Reporting spreadsheets | For modelling and scenario work that is explicitly not the record. | When a spreadsheet has become the de facto source of the board number — the one case where replacement is the point. | Nothing published is computed outside the governed record without lineage back to it. |
Lineage
Field-level lineage is what makes a state view defensible
Evidence → Disagreement → Authority → Operator-Controlled Operating Record → Intelligence → Execution, applied per field. Read the Operator Authority Chain™ for the full argument.
DATA
Where did this value come from?
Every field carries its source system, source identifier, extraction timestamp and interface used. A value with no traceable origin is not admitted to the record.
TRUTH
Which value does the operator accept?
When two systems disagree, both values are retained, the conflict is raised, and the governed record shows the accepted value plus the rule or the named person that accepted it.
DECISION
What was decided on this number?
Decisions reference the record version they were made against, so a later restatement does not quietly rewrite the basis of a past decision.
EXECUTION
What happened next, and who confirmed it?
Actions taken from the record are logged with the confirming human. Nothing writes back into a source system without an explicit, scoped, operator-authorised write.
Frequently asked questions
How do I govern senior housing & care data across multiple states?
Keep one Operator-Controlled Operating Record with one authoritative source per field, and carry state variation as parameters of those fields rather than as duplicate fields. Write one portfolio definition per contested metric, map each state’s counting or scoring rule into it while retaining the raw source value, fix the property-to-entity mapping per effective date, reconcile at property and state level, and produce both state and portfolio views from the same governed field.
Should each state have its own version of the number?
Each state needs its own view, not its own field. A state view is the governed field with that state’s inclusion rule applied at report time. The moment a state gets its own stored field, the portfolio has two numbers with equal standing and no rule for choosing between them — which is exactly the condition a governed record exists to prevent.
What happens when a state definition conflicts with the board definition?
Both are produced and both are traceable to the same underlying value. The governed record shows the portfolio figure, the state figure, the parameter that separates them, and who accepted each. When systems or definitions disagree, the operator governs — the disagreement is documented rather than averaged away.
Does multi-state governance require replacing regional systems?
No. Regional systems are read one direction and remain the operator’s systems of record until the operator decides otherwise. Clinical scope is a configuration choice: SeniorCRE has built clinical record surfaces; medication administration and eMAR remain roadmap — not built. Any future clinical system-of-record function must clear its own Production-Entry Gates and receive operator acceptance.
How are entity and license changes handled without restating history?
The property-to-entity mapping is held per effective date with history retained, and decisions reference the record version they were made against. A reorganisation therefore produces a visible restatement with its own basis, rather than silently changing the figures a past decision was made on.
Is this a compliance product?
No. The record makes state-specific reporting reproducible and traceable, and it records who made each determination. It does not render a regulatory opinion, and no compliance outcome is claimed. Operators remain responsible for their filings and should confirm requirements with their own counsel and regulators.
Evidence behind the evaluation
These pages carry the governance and clinical evidence a shortlist cannot: source authority rules, escalation controls, data limits, and survey-ready evidence.
- senior housing & care data governance for multi-state portfolios
How differing state definitions and survey regimes are governed in one record.
- human review and escalation controls for clinical AI
Mandatory human review, escalation paths, and what the system may never do.
- clinical AI data sources and limitations
What the signals are computed from, and where the evidence stops.
- how to evaluate senior housing & care software for 10+ locations
Six-criteria, vendor-neutral evaluation frame for multi-state portfolios.
Continue in this cluster
Data integration for senior housing & care
The pillar: canonical entities, connector coverage, lineage and the phased sequence every page here shares.
Combining PointClickCare® with accounting and payroll data
How clinical census and acuity from an EHR reconcile against the general ledger and worked payroll hours in one governed record.
Connecting EHR, CRM, payroll and general-ledger data
The four-system join: which system is authoritative for which field, and how conflicts are resolved rather than averaged.
Integration with your EHR retained — replacement optional
Read-one-direction coexistence: govern the operating record above the systems you already run, and replace only by choice.
Acquisition-day integration
What has to be connected, reconciled and owned before the first close-day board number is defensible.
Integration implementation checklist
The stage-gated checklist: definitions and entitlement, read-only connection, reconciliation, then authority — each item with an owner and an evidence test.
Data integration platform buyer’s guide
Nine evaluation criteria instead of connector counts, the categories of approach and where each one structurally stops.
Operator-controlled operating record and integration architecture
Six entities with declared grain and identity rules inside a five-layer read-only architecture, from landing and lineage to governed consumers.
- Connector inventory: Integration ecosystem · Integration posture
- Canonical model: One Operator-Controlled Operating Record · The operating record · What is a senior housing & care operating infrastructure?
- Comparisons: SeniorCRE vs PointClickCare® · SeniorCRE vs Yardi® · Hosting versus governing
Bring your own systems to the conversation
The useful version of this discussion is your actual stack, your actual contested numbers, and the reconciliation you cannot currently produce on demand.
PointClickCare® is a registered trademark of PointClickCare Technologies. MatrixCare® is a registered trademark of ResMed. Yardi® is a registered trademark of Yardi Systems, Inc. DocuSign® is a registered trademark of DocuSign, Inc. Salesforce® and Tableau® are registered trademarks of Salesforce, Inc. Power BI® and Microsoft® are registered trademarks of Microsoft Corporation. QuickBooks® is a registered trademark of Intuit Inc. ADP® is a registered trademark of ADP, Inc. Oracle® is a registered trademark of Oracle Corporation. All other product names, logos, and brands are property of their respective owners. SeniorCRE is an independent platform and is not affiliated with, endorsed by, or sponsored by any of the aforementioned companies. Comparisons are based on publicly available information and may not reflect all product capabilities.