The operating record.
Epic organized healthcare around the patient record. SeniorCRE® organizes senior housing & care around the operating record — one governed record above the clinical, financial, workforce, and occupancy systems an operator already runs, with lineage from every reported figure back to entity, period, and source rows.
What the operating record is
The operating record holds one canonical representation of each governed enterprise object: one reconciled resident, one care plan, one ledger, one unit (a child of Property), one shift, and one entity hierarchy (Holding Co → Operator → Region → Property → Unit) — six entities in all. The authoritative source of each field may remain an incumbent system; the canonical representation is what the enterprise accepts as true, with lineage back to the originating rows.
The record is operator-owned and exportable with documented schema. In the authority model, SeniorCRE holds system-of-record authority for the reconciled representation — that is a governance role the operator grants, not a claim that any operator production deployment is running today. Whether the systems that capture the underlying events are retained or replaced is an operator decision: govern first, replace only by choice.
- Resident — identity, demographics, payer, acuity, consent
- Care plan — MDS, ADL, IDT goals, PRN reassessments, QAPI flags
- Ledger — GL, AR, AP, period close, payer postings, accruals
- Shift — schedule, clock, acuity-weighted workload, med-pass events
- Property / Unit — bed board, licensure, capacity, capex, occupancy
- Entity — the hierarchy permissions, rollups, and tenant isolation are scoped to
Who reads the record
Six constituencies reading one record.| Constituency | What they read |
|---|
| Operators | Live census, eMAR, shift workload, payer mix, and period close read at request time. |
|---|
| Owners & sponsors | Property-level NOI, occupancy, and covenant rollups assembled from the same governed records operators write. |
|---|
| Investors & REITs | Portfolio rollups, ESG metrics, and threshold alerts without a BI overlay in between. |
|---|
| Brokers | Deal-to-ops handoff with audited operating history attached to the transaction. |
|---|
| Vendors | Scoped, approval-gated access to the entities they touch — never the whole record. |
|---|
| Lenders | Covenant visibility, DSCR, and operating evidence on the operator’s own record. |
|---|
How data reaches the record — five ingestion modes
Ingestion mode is chosen per source system and per property, ordered by how much the source system has to change. Mapping is declared in a versioned contract rather than inferred, identity is resolved before storage, and every ingested row carries its source system, source period, load timestamp, mapping version, and batch — which is what makes a portfolio figure walkable back to a source row.
| Ingestion mode | How it works | Status |
|---|
| Mode A — Operator-exported files | Census, payroll, GL trial balance, and staffing exports the operator already produces, mapped into canonical entities at load time. | Exercised in validation environments |
|---|
| Mode B — Scheduled report drop | Recurring drop to a governed SFTP or object-storage location under a fixed file contract. | Exercised in validation environments |
|---|
| Mode C — Read-only database or replica view | Read-only access to a reporting replica or vendor-provided views on a defined pull window, with no write path back. | Design intent — not live in operator production |
|---|
| Mode D — Clinical event feeds (HL7 / FHIR) | ADT, order, and observation events resolved to the canonical resident and care plan, with PHI classification applied before storage. | Design intent — outbound clinical transmission not enabled |
|---|
| Mode E — Vendor API connectors | Direct system-to-system connectors to EHR, PMS, payroll, and scheduling vendors under executed agreements. | Roadmap — no vendor integration is live in operator production today |
|---|
How trust in the record is measured
The trust score is reported alongside a figure rather than behind it, and it decomposes into four inspectable sub-scores per period, per property, per source. A figure with a degraded sub-score is labeled, not hidden.
| Sub-score | What it measures | What degrades it |
|---|
| Freshness | Age of the most recent accepted load per source and property against that source’s expected cadence. | A late or missed drop, a stalled pull window, or a source that silently stopped producing. |
|---|
| Completeness | Share of expected entities and required fields present for the period — properties reporting, beds accounted for, shifts with hours, accounts with balances. | Missing properties, partial payroll periods, unmapped cost centers, bed-board gaps. |
|---|
| Reconciliation | Agreement between sources describing the same fact — census vs. billing days, scheduled vs. paid hours, ledger vs. subledger. | Cross-system variance beyond a declared tolerance for the period. |
|---|
| Lineage | Share of reported figures resolving to source rows with intact sync metadata (source, period, batch, mapping version). | Manual adjustments, unattributed overrides, or figures assembled outside the record. |
|---|
What the operating record is not
- Not a data warehouse — a warehouse copies operational data on a schedule; the record governs the data where it lives.
- Not a BI overlay — an overlay displays disagreement between systems; the record resolves it.
- Not integration plumbing — integrations synchronize two sources of truth; the record governs one.
- Replacement is not required. Govern first. Replace only by choice — operators can keep the systems that work unless they choose otherwise.
Claims note
Capabilities described here are exercised in validation environments rather than operator production. No vendor or payor integration is live in operator production today, and outbound clinical transmission is not enabled. Trust-score thresholds and reconciliation tolerances are set per operator during a pilot rather than published as universal defaults.
Frequently asked questions
- What is an operating record in senior housing & care?
- One governed representation of each enterprise object — resident, ledger, unit, shift, entity hierarchy — while authority and lineage are preserved to the source systems that originate the underlying events. Operators, owners, investors, brokers, vendors, and lenders read the same governed value instead of each reading a separate system’s copy.
- Does SeniorCRE replace the EHR, PMS, payroll, or GL?
- Not by requirement. SeniorCRE can govern above retained systems or assume selected system-of-record functions where the operator deliberately chooses replacement. The authority model is set domain by domain.
- How does data get into the operating record?
- Through one of five ingestion modes chosen per source system: operator-exported files, a scheduled report drop, a read-only replica or view, HL7/FHIR clinical event feeds, or vendor API connectors. File- and drop-based modes are exercised in validation environments; direct vendor connectors are roadmap.
- How is the trust score calculated?
- It decomposes into freshness, completeness, reconciliation, and lineage sub-scores, evaluated per period, per property, and per source, and reported next to the figure it qualifies.
- Can the operator export the record?
- Yes. The record is operator-owned and exportable with documented schema, without a services engagement.
https://seniorcre.com/operating-record