Sovereignty is not residency
Diligence questionnaires still ask where the data sits. That is a hosting question, and it is the easier one. Sovereignty is a control question: who decides what the record says, who may read it, who may change it, and who may take it somewhere else. A record hosted in the operator's preferred region and still governed by a vendor's definitions is not sovereign. A record the operator can export, audit, and redefine is sovereign wherever it is hosted.
- Residency (hosting)
- Which region, cloud, and tenancy model the data physically occupies. Answered by architecture and contract.
- Sovereignty (control)
- Who governs definitions, access, retention, and departure. Answered by the operator, or by default by the vendor.
The same distinction, applied to AI and interface vendors: hosting versus governing.
Four tests an owner can apply to any vendor
1. Accessibility
Can the operator read every field it is accountable for — including derived and calculated fields — without a support ticket or a professional-services engagement?
2. Exportability
Can the operator take the full data set, in standard formats, on its own schedule, at no charge, without asking permission and without a termination event?
3. Auditability
Can the operator show a surveyor, an owner, or a lender who read what, who changed what, and which definition produced a number, without depending on the vendor to reconstruct it?
4. Governability
Can the operator change a definition — how occupancy, agency exposure, or acuity is counted — and have every downstream report and AI answer follow that change?
Most vendors can answer the first two. The fourth is where suite architecture and operator control genuinely diverge: if definitions live in the vendor's model, the operator can read its data but cannot govern its truth.
Questions institutional owners should ask before signing
- Is operator ownership of resident, clinical, employee, and financial data stated in the master agreement, or only in marketing material?
- Is export priced? Is it available outside a termination event, and on the operator’s schedule?
- Which fields are excluded from export — derived scores, model outputs, audit history, attachments?
- Can the audit record be altered by anyone, including vendor staff, and how is that demonstrated?
- If a definition changes, does every report, board pack, and AI answer inherit the change?
- On termination, what is the retention and deletion sequence, and what evidence of deletion is provided?
- Which subprocessors touch PHI, and does the operator get notice before that list changes?
- Does the vendor claim any right to use operator data for model training or benchmarking?
Vendor lock-in checklist
Lock-in is rarely written into a contract. It accumulates as small dependencies, each reasonable on its own. Score a vendor on the eight below; every item the operator cannot do unaided is a dependency that will be priced at renewal.
- Export the full data set unaided, on demand
- Reproduce a reported number from raw fields
- Change a metric definition without vendor work
- Add or remove an integration without renegotiation
- Read the audit record directly
- Run a migration rehearsal before committing
- Keep the operator’s own brand and identity on the resident- and family-facing surface
- Leave without losing history, attachments, or derived fields
Companion reading: what sovereignty means in senior care operations · why it matters for multi-location operators · open data governance.