Loading...
SeniorCRE is the operator-controlled operating infrastructure for senior housing & care.
Fragmentation is the antagonist; the operator governs what counts as truth.
In a triple-net portfolio the ledger is the input. In a RIDEA/SHOP portfolio the operating event is the input, and the ledger is the consequence.
When systems disagree, the operator governs.
The REIT discloses a segment. The operator produces the events behind it. Governance decides which definition the disclosure is built on.
A SHOP-segment disclosure is assembled from things that happen in a building: a move-in, a level-of-care change, a shift filled with agency labor, an ancillary service billed. Those events set the revenue mix, and the revenue mix — not the ledger mapping — is what the IRC §856 income tests read.
That is why RIDEA/SHOP reporting fails in the definitional layer rather than the arithmetic layer. The REIT and the operator can both be right and still publish different numbers, because each is using its own same-store population, its own occupancy basis, and its own treatment of reimbursed cost. Until definition authority is named and reconciliation happens once, every quarter reopens the same argument.
Status as of September 29, 2026 (last modified 2026-09-29)
| Claim | Evidence step | What is true today | Proof to inspect |
|---|---|---|---|
| Operator and portfolio workspace foundation built (roles, hierarchy, entity tree). | Validated | Provisioning controls have been exercised repeatedly in controlled SeniorCRE conditions, including the operator onboarding wizard. Not yet performed for an operator in production; no standard duration is published. | Control test record; synthetic or de-identified data; no operator PHI. |
| Single-community acceptance boundary. | Architecture designed | A gate sequence derived from the migration and acceptance model. No community has gone live for an operator, so no observed duration exists. | Written deployment plan and acceptance-gate model. No execution record exists. |
| Portfolio-wide rollout acceptance across multi-community scope. | Architecture designed | A wave-cadence model from the deployment plan. Sequencing depends on community count, system count, data condition, source access, and operator authority decisions. Not a completed rollout. | Written deployment plan and acceptance-gate model. No execution record exists. |
| Connectors to PointClickCare®, MatrixCare®, Yardi®, and QuickBooks®. | Validated | Ingestion and normalization exercised against synthetic and de-identified extracts in controlled SeniorCRE conditions. No third-party integration is live in operator production. | Control test record; synthetic or de-identified data; no operator PHI. |
| Operator-Controlled Operating Record: source authority, reconciliation, field-level lineage. | Architecture designed | The Operator-Controlled Operating Record is designed and not yet implemented in any community. Authority rules, reconciliation, and field-level lineage are design intent; synthetic examples do not establish working governance. | Written deployment plan and acceptance-gate model. No execution record exists. |
| Clinical configuration: SeniorCRE as clinical system of record, or alongside an incumbent eMAR read one direction only. | Architecture designed | Designed, not built for operator use. SeniorCRE's native medication administration and eMAR are roadmap and not built; the read-only configuration alongside an incumbent eMAR depends on the Operator-Controlled Operating Record, which is designed and not yet implemented in any community. One authoritative medication record at all times is a design rule. | Written deployment plan and acceptance-gate model. No execution record exists. |
| Barcode-verified administration with an automated five-rights check at the point of medication pass. | Architecture designed | Not built. Corrected September 7, 2026: earlier pages, operator training guides, and generated answers described this control as running, which was false. Implementation boundary: four of the five medication scan surfaces open a camera preview with no decoder and match only a manually typed NDC; one mobile surface decodes frames through the browser-native BarcodeDetector API where the browser supports it (Chromium/Android; not iOS Safari, not most desktops) and compares the NDC alone. No decoding library is bundled, no surface verifies resident, dose, route, or time, and no scan result blocks an administration. The five rights are verified by the administering clinician, not by SeniorCRE. | Build-queue entry with scope and dependencies. No implementation exists. |
| Live write-back into operator payroll and scheduling systems. | Architecture designed | Specified and in the build queue. Read-side ingestion only today. | Build-queue entry with scope and dependencies. No implementation exists. |
| Implementation effort required from the operator. | Architecture designed | Deployment is staged, not effortless: platform access, source access, authority rules, reconciliation, security review, and any history migration are scoped work with operator-side effort. Any claim of zero implementation would be false. | Written deployment plan and acceptance-gate model. No execution record exists. |
Status and evidence class as of September 29, 2026. SeniorCRE has no operator-production deployment. Public timing is gate-based and operator-specific; no standard go-live duration is published. Maintained and reviewed by John Hauber, Founder, SeniorCRE, LLC. A medication-safety control was described on earlier pages as running when it was not; that correction is published in full at /medication-safety-claim.
| Capability | SeniorCRE | Property-accounting-first platform | Operator workbooks + BI |
|---|---|---|---|
| Primary input for the SHOP segment | Operator operating events — census, acuity, service bundling, labor, ancillary revenue — carried with lineage into the segment view. | The REIT ledger and management-agreement reporting packets, assembled at close. | Operator-supplied workbooks, re-keyed each period. |
| Resident revenue classification | Classified at the revenue line, with the rule set versioned and owner named. | Line-level classification of bundled senior housing revenue is not advertised as a native capability in publicly available product materials as of October 9, 2026. | Analyst judgment, recorded in a cell comment. |
| Same-store definition | One governed definition with version history and an approval record. | Configurable report grouping; definition authority left to the REIT team. | Redefined whenever the population changes. |
| Operator disagreement handling | Reconciled once under governed rules; the resolution persists into every downstream report. | Variance explained in the reporting package for that period. | Re-argued each quarter by email. |
| Reproducing a prior disclosure | Append-only history designed so a prior segment disclosure reproduces with the definitions then in force; built, not operator production. | Report history exportable; definition-state reproduction is not advertised as a native capability in publicly available product materials as of October 9, 2026. | Whatever the saved file contains. |
Before any number moves, record who owns each definition — the REIT, the operator, or neither — and the version in force.
Housing, care, and ancillary revenue are separated where they are earned, so the §856 income tests read the correct basis.
The difference is resolved under a governed rule, with the approver recorded, and the resolution is inherited by every downstream report.
Each disclosed figure traces in one hop to the operating rows and the definition version that produced it.
SeniorCRE is the operating, compliance, and asset-management layer for REITs, family offices, and institutional capital allocators in senior housing & care.