Loading...
SeniorCRE is the operator-controlled operating infrastructure for senior housing & care.
Fragmentation is the antagonist; the operator governs what counts as truth.
Across a multi-operator portfolio, most disputes are definitional rather than arithmetic. Governance is what makes the numbers comparable without forcing every operator onto one system.
When systems disagree, the operator governs.
Definition. Authority. Reconciliation. Lineage. The four that make data governable.
Every operator in a portfolio can report accurately and the portfolio can still disagree with itself. One counts a unit occupied at move-in, another at first billed night. One holds turnover cost above the NOI line, another below it. Rolling those up produces a number that is arithmetically correct and institutionally unusable.
The fix is not a new dashboard. It is a definition register with named owners, declared source authority per metric per operator, reconciliation performed once under governed rules, and lineage kept attached so a prior period reproduces as published. Operators keep the systems they run today; governance sits above them. Where an operator chooses it, SeniorCRE can also be deployed as the system of record itself.
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 | BI layer over operator exports |
|---|---|---|---|
| Whose definition of occupancy governs | Declared in a definition register with an owner and a version; the portfolio view states which definition it used. | Report-level configuration per operator; a governed definition register with approval history is not advertised as a native capability in publicly available product materials as of October 9, 2026. | Whatever the analyst mapped this quarter. |
| Source authority when two systems disagree | Declared per metric per operator, before the disagreement happens. | Resolved by whichever system the report was built from. | Resolved by whoever sends the file last. |
| Reconciliation | Performed once under governed rules; downstream reports inherit the resolution rather than repeating it. | Performed per report, per period. | Performed again every time someone asks. |
| Operator system replacement required | No. Operators keep the systems they run, and governance sits above them — or SeniorCRE can be deployed as the system of record where the operator chooses that road. | Strongest where the same vendor also runs the operator’s systems. | Not applicable; the workbook is the integration. |
| Cross-operator confidentiality | Isolation enforced at the database row level, with a written control description for security review. | Role and permission configuration at the application layer. | Depends on file handling. |
Write one definition per KPI, name its owner, version it, and date it. A metric without an owner cannot be governed.
For each metric and each operator, state which system governs the value before any disagreement occurs.
Apply the reconciliation rule, record the approver, and let downstream reports inherit the result instead of re-deriving it.
Every published KPI traces in one hop to the operating rows and definition version behind it, so a prior period reproduces as published.
SeniorCRE is the operating, compliance, and asset-management layer for REITs, family offices, and institutional capital allocators in senior housing & care.