Trust Server Sovereignty: Who Holds the Keys to Your Health Record

Part 3 of the Sovereignty series.

In my last post I argued that sovereignty takes a village. This post covers the server at the center of that village: the trust server we are designing at EverBetter. It answers the question every clinic leader and patient should ask first. Who holds the keys?

Start with the problem. Every hospital or clinic that shares records builds a link to every other one. The count follows n(n-1)/2, so twenty organizations need 190 links [1]. The patient holds her record in pieces at every place she has visited. U.S. law gives her the right to a copy [2]. A copy gives her portability. She still cannot decide who reads the original.

The trust server inverts that model. Each patient keeps her record in a personal data pod built on the open Solid protocol [3], [4]. Clinics, clinicians, and software reach the record through her recorded consent. I call this the data inversion: in a normal cloud app your data goes to the app; with a pod, the app comes to your data. Each clinic needs one link, to the patient.

I read the architecture north to south. Patients, clinicians, clinics, and AI agents sit on top. The EverBetter platform sits below them and adds what healthcare requires: a tested release, a HIPAA profile, a gateway to existing clinic systems, and trust certificates so organizations can rely on each other. Below the platform, an open core sets the rules every pod follows: identity, consent, and keys. The Solid protocol sits at the bottom. We keep the core neutral so other industries can build on the same base.

Sharing starts with a request. A clinician who needs the record asks the patient through the system. The request names what she wants, why, and for how long. The patient answers on her phone. A yes creates a signed consent that serves as both a permission and a legal record. An unanswered request waits; a limited emergency path exists, and the system records every use of it. A revoke stops future access.

One rule governs every role in the trust server: no admin, operator, or delegate can gain, override, or hand off rights greater than the pod owner holds. The rule comes from an old legal maxim, nemo dat quod non habet: no one gives what he does not have.

That rule protects the patient only when she holds the keys. Hosting choices fall along a spectrum. When the operator stores the data and holds the keys, the host can read the record and the patient’s control rests on a contract. When the patient holds the keys, the host cannot read the record and control is built into the system. When the patient picks her own host, she can move the pod. Operator-held keys are the cheapest and most common setup. I name it so buyers ask the question.

Sovereignty also has layers. The patient is sovereign over her pod. The government is sovereign over the rules. Take a driver’s license. A local government issues it. You can keep a copy in your pod and share it with anyone. You cannot revoke it. Health records work the same way under HIPAA. A patient can revoke an authorization in writing, and the revocation does not undo what a provider already did in reliance on it [5]. Providers may disclose without authorization when the law requires it, such as for public health [6]. A revoke through the pod stops future access. It cannot erase what a provider must keep or report.

The inversion also changes the business model. In traditional SaaS the vendor keeps the data, and customers stay because leaving means migration. In the pod model the pod keeps the data, and the vendor supplies business logic and user experience. Switching apps means granting a new app access. Customers stay because the app serves them better. EverBetter competes on service. The patient keeps the data.

EverBetter runs this loop today. Clinic data flows into the patient’s pod and appears in a mobile app. Wearable data feeds the clinician’s pre-visit note, and the care plan returns to the patient with no re-entry.

Three limits remain. When the operator holds the keys, protection rests on a contract. No architecture can recall copies made before a revocation. Some shared services the design needs, such as public registries, do not exist yet; my last post covers that gap.

The patient holds the record. Organizations connect to her through consent. No role outranks her, and the law sets the outer limits. Ask every vendor who holds the keys.

References
[1] EverBetter LLC, “EBSS Architecture Documentation: Requirements, Executive (E) and Steward (M) Tier Specifications,” internal, Sept. 2026.
[2] Access of individuals to protected health information, 45 C.F.R. § 164.524. [Online]. Available: https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-E/section-164.524
[3] Solid Project, “Solid: Your data, your choice.” [Online]. Available: https://solidproject.org/
[4] W3C Solid Community Group, “Solid Protocol, Version 0.11.0,” Draft Community Group Report, May 2024. [Online]. Available: https://solidproject.org/TR/protocol
[5] Uses and disclosures for which an authorization is required, 45 C.F.R. § 164.508(b)(5). [Online]. Available: https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-E/section-164.508
[6] Uses and disclosures for which an authorization or opportunity to agree or object is not required, 45 C.F.R. § 164.512. [Online]. Available: https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-E/section-164.512