Loading...
SeniorCRE is the operator-controlled operating infrastructure for senior housing & care. Most operators start by governing the systems they already run. Some choose to run on SeniorCRE itself — an existing community moving off paper, a new community establishing its operating records from the outset, or a community replacing specific systems it runs today while the rest stay in place. Either way, that choice starts with one bounded pilot, agreed in writing before any work begins.
Institutional trust markers
Multi-community operators, REITs, private equity, lenders, and multi-state portfolios evaluate the same nine markers before they sign. Each one is documented, enforced in the platform, and reviewable in the Trust-by-Design procurement package.
HIPAA-safeguarded controls; no SOC 2 certification or report claimed. No completed independent penetration-test report claimed.
HIPAA-safeguarded controls today: encryption at rest and in transit, BAA execution, PHI segregation, and signed-URL access to PHI buckets.
Operator-controlled definitions, source authority, reconciliation, and lineage across clinical, financial, workforce, compliance, and capital surfaces. Multi-tenant with database-enforced isolation.
A documented ingestion path for operator-supplied clinical, property, and accounting exports. Named-vendor connectors are ROADMAP; no third-party integration is live in operator production today. AI reads only the fields the operator declared readable.
SOC 2 in progress (underlying AWS infrastructure maintains its own SOC 2 reports), MFA required, session timeout, concurrent-session limits, continuous automated vulnerability scanning.
Immutable, append-only logs with UTC-millisecond timestamps, full user/session context, and 7-year retention.
33-role RBAC hierarchy. Property-level tenant and role gates enforced at the API layer (Fastify + tRPC on AWS) with WorkOS-authenticated sessions and defense-in-depth checks in PostgreSQL.
Holding Co → Operator → Region → Property → Unit hierarchy. Portfolio rollups computed from the Operator-Controlled Operating Record at request time. Designed for multi-state, multi-payer, multi-entity ownership.
Full detail on each marker, evidence inventory, and the Trust-by-Design procurement package live on the Trust Center.
Status, stated plainly
Road 2 describes design intent and target capability. It is not in operator production today, and the functions on this page have not yet been validated in an operator workflow.
What this proposed pilot would seek to demonstrate: SeniorCRE holding the agreed functions as the community’s system of record, in daily use, under written authority. Road 1 requires different evidence: one real disagreement between retained systems, carried through the governing chain.
Whether replacing paper records, opening a new facility, or replacing specific systems a community already runs, the operator chooses which functions SeniorCRE will hold as the system of record. Scope, authority, readiness, and acceptance are agreed before operational use.
Paper records already carry definitions, responsibility, and authority. The work is making those controls explicit and traceable as information enters SeniorCRE. The paper record runs alongside until the operator approves the transition.
There is no legacy record to carry over. Definitions, permissions, authoritative records, and continuity arrangements are established before the community relies on SeniorCRE in operation.
The operator selects which systems of record SeniorCRE will replace and which will stay. For each function SeniorCRE takes over, the outgoing system remains the record of its history, definitions and authority are agreed before cutover, and both run in parallel until the operator approves the transition. Systems that stay remain connected under Road 1 governance.
Road 2 makes SeniorCRE the system of record for functions the operator selects — in an existing paper-based community, a new one, or a community replacing specific systems it already runs. This pilot's proposed starting scope: direct entry of resident and operating information, tablet charting by care staff, recorded incident notices, and staff records with retention scoring. It excludes medication, money movement, and any replacement of accounting, workforce, or CRM systems. A written platform pilot agreement sets scope, success criteria, and exit terms before work begins, and the pilot is judged after thirty days of use — by the operator.
The two roads in: govern what you have, or run on SeniorCRE.
Where both roads end.
How data becomes truth, decision, and authorized execution.
DALLAS, TX · PILOT SCOPE
Road 2 is the road where SeniorCRE becomes the system, not the layer above it. Whether a community is still running on paper, opening new, or replacing specific systems it already runs, that road starts small: four functions, bounded in writing, with everything else explicitly out of scope. The exclusions are not fine print — they are the design. Medication, money, and the systems the community already relies on are untouched.
In scope
Resident and operating information entered directly into SeniorCRE.
Design intentCare staff chart on tablets at the point of care, after the care-documentation workflow receives appropriate clinical safety approval.
Design intentIncident notices captured and traceable, with their source kept.
Design intentStaff records, and scoring of which staff may be at risk of leaving, from the platform's own scheduling, attendance and training data. Scores are about staff, never residents' care. Only authorized managers see them; a score prompts a conversation and never triggers an employment action automatically.
Design intentOut of scope
A platform pilot agreement sets scope, success criteria, and exit terms before any work begins.
Any care-documentation workflow in this pilot is used only after a named licensed clinical owner approves it in writing. Medication and eMAR stay out of this pilot and require their own later validation.
Functions switch on one at a time.
In an existing paper-based community, the paper record runs alongside this pilot until the operator approves the transition. In a new community, definitions, permissions, authoritative records, and continuity arrangements are set before operational reliance. In a community replacing existing systems, the outgoing system remains the record of its history and runs in parallel until the operator approves the cutover. In each, when records disagree, an authorized person at the operator decides what governs — and that decision is recorded with its lineage.
Govern first. Replace only by choice.
This pilot is judged after thirty days of use, not on launch day, against criteria agreed in writing before work begins:
Both roads end in the same place: an Operator-Controlled Operating Record. A community that starts on Road 2 can later make SeniorCRE its system of record for clinical and medication facts — after the applicable gates clear and a named licensed clinical owner validates them in writing — while keeping and governing its other systems. That choice stays with the operator.
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.
SeniorCRE is the operator-controlled operating infrastructure for senior housing & care. The operator chooses the road.