Loading...
The operator — not the vendor — owns and controls every record. Five parts: ownership, isolation, access controls, auditability, and export rights.
Data sovereignty in senior care operations is the operator's exclusive ownership and control of every record generated inside the platform — resident PHI, clinical documentation, employee records, and financial data. The operator is the HIPAA Covered Entity, the state-survey licensee, and the fiduciary to residents and families. Sovereignty makes the technical reality match that legal reality.
In practice, sovereignty is five tightly scoped rights: ownership of the underlying records, isolation from other tenants at the database layer, access controls that are granular and auditable, auditability through an immutable append-only log of every PHI read and write, and export rights that let the operator leave any time in standard formats without penalties or vendor approval.
Author: SeniorCRE Platform Standards. See related documentation: canonical data-sovereignty standard, tenant-level isolation, Trust Center (HIPAA, FHIR, export policy).
Status as of October 16, 2026 (last modified 2026-10-16)
| Claim | Evidence step | What is true today | Proof to inspect |
|---|---|---|---|
| Operator and portfolio workspace foundation built (roles, hierarchy, entity tree). | Validation-exercised | 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. | 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. | 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®. | Built | Built in a SeniorCRE test environment and demonstrable with synthetic extracts only. No named connector is live, and none runs in operator production. | Test-environment demonstration on request; demonstration data only; no operator data. |
| Operator-Controlled Operating Record: source authority, reconciliation, field-level lineage. | 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. | 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. | 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. | 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. | 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 October 16, 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 operating, compliance, and asset-management layer for REITs, family offices, and institutional capital allocators in senior housing & care.
Start at Data Sovereignty in Senior Care — this page adds: Definition and the tests a claim of sovereignty has to pass.
The full argument for operator ownership of the record.
Why ownership became a governance question in the AI era.
The policy commitments — portability and API equivalence.
Where every field comes from, and who may write to it.