Each organization sees its residents.
Every table carries row-level security, and the account the application connects with cannot bypass it. A request carrying the wrong facility returns nothing at all — not a filtered list, nothing.
Security and record trust
Resident information stays protected.
Facility data is separated in the database, staff access follows the role, and a signed record cannot be silently changed. Those boundaries are enforced below the application, not promised by it.
Who can see information
Access follows the facility and the staff role.
These boundaries hold even if the application above them has a bug, because they are enforced by the database rather than by screen logic.
Staff see what their job requires.
Facility administrators, clinical staff, direct-care staff, and oversight users hold different permissions. Anything a facility can configure starts denied and has to be granted deliberately.
Access can be removed promptly.
Deactivation takes effect on the next request. Higher-risk access is scoped, time-bound where needed, and written to the audit trail.
After a record is signed
A correction does not erase the original.
Authorship, signature, time, and every later change stay legible. The database refuses the edit — there is no administrator override and no development bypass.
- No silent defaultsAn unanswered clinical question stays unanswered. Nothing is preselected that would imply work a person did not do.
- Signed means closedNo one edits a completed record in place. Not a supervisor, not an administrator, not support.
- Corrections stay linkedA correction is a new record pointing at the original, carrying its own author, time, and reason. The original is never rewritten.
- Times stay distinctWhen care happened, when it was entered, when it was signed, and when it was corrected are four separate timestamps.
- Sources stay visibleImported, staff-entered, and system-created information keeps its source.
- The trail only growsSecurity and access events can be added and read, never edited or deleted — including by us.
Before resident data
No facility goes live until these checks pass.
Each one closes on evidence, not on an assurance. The tag says what finishing it actually looks like.
- Security risk reviewDocumentedRisks, safeguards, owners, and remaining decisions written down.
- Vendor agreementsSignedAgreements in place with every service that may handle protected information.
- Access testingTestedFacility separation, staff roles, deactivation, and privileged access exercised against the running system.
- Backup recoveryRestoredA real restoration completed, not only a backup configured.
- Clinical reviewReviewedForms, signatures, exceptions, corrections, and print records read by qualified Arizona advisers.
- Migration checkVerified with youActive residents and medications confirmed by your administrator before go-live.
Where the line is today
The limits, in the same plain terms.
A security page that only lists strengths is not much use for diligence. Here is what is deliberately not true yet.
Synthetic residents only.
No real resident information exists in Everstead today. Development and testing run on invented data, and this marketing site collects business contact details only.
Nothing here has been audited.
No certification, no third-party assessment, no independent verification. The controls described above are ours to demonstrate, and we will walk you through them rather than point at a badge.
Not yet automated.
There is no automatic deletion schedule and no disclosure-accounting workflow. Both are facility decisions, agreed and configured with you before go-live rather than assumed on your behalf.
Ask directly
Have a security or record-integrity question?
Send it to a real person, or walk through the checks required before your facility goes live.