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 is a single governed record per object: exactly one resident row, one ledger, one bed, one shift, and one entity hierarchy (Holding Co → Operator → Region → Property → Unit). Every surface reads the same row it would write to, rather than a copy assembled by a nightly job.
The record is operator-owned and exportable with documented schema. SeniorCRE is the system of record for the reconciled operating record, not a replacement for the systems that capture the underlying events.
- 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 rows 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.
- Not a rip-and-replace — operators keep the systems they already run.
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?
- A single governed record per operational object — one resident, one ledger, one bed, one shift, one entity hierarchy — read by operators, owners, investors, brokers, vendors, and lenders instead of each reading a separate system’s copy.
- Does SeniorCRE replace the EHR, PMS, payroll, or GL?
- No. Operators keep the systems they already run. SeniorCRE governs the reconciled operating record above them and does not write back into those systems as part of establishing the record.
- 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