A complete audit trail
Every write is an event with an author and a time. In FHIR apps, every read, search and export of patient data is recorded too.
App AApp BApp C
Row level security per appSecurity and trust
Built for patient data from the foundation up.
The protections that are hardest to add later are part of the engine: isolation, audit, permissions and logging rules that hold for every app built on HealthTable.
Event logappend only
R. Chenupdated Task tsk91status: Open → Done
Builder agentproposed Table Callbacksconfirmed by A. Ruiz
J. Patelread Patient pt482via Patient detail
Automationcreated Task tsk91Remind on call nurse
API key opscreated Observation obs82via FHIR R4
Isolation
Your data lives in a cell, and you can have your own.
Applications run in hosting cells. Shared cells separate apps with Postgres row level security under the application layer. A dedicated cell gives one customer its own database and network, pinned to the region you choose, and apps can move between cells.
- An edge router resolves every request to the right cell
- Every row carries its application, enforced by the database
- Dedicated cells for customers who need physical separation
Edge router routes each app to its cell
Shared HIPAA cell
Dedicated cell
Your apps
Own database and network, region you choose Encrypted in transit and at rest Event log per cell
Controls
What protects patient data on HealthTable.
Each control below is built into the platform, not left to configuration.
Permissions down to the field
Roles, table rules, row and field rules, and interface grants for people who only need one screen.
No patient data in logs
Record contents never reach application logs. Redaction by field is built into the logger.
Encryption
Encryption at rest and TLS in transit on BAA capable cloud infrastructure.
Recoverable deletes
Deletes are soft. The record and its full history are kept, so a deletion can be audited and reversed.
Scoped API keys
Keys limited to one application and the actions it needs, and every call attributed to its key.
AI governance
AI follows the same rules, enforced in one place.
Every model call goes through the HealthTable model gateway. The gateway decides which providers an app may use, how much it may spend and what gets logged.
- Apps that hold patient data only reach model providers under a BAA
- Model calls are logged with metadata and token counts, never prompt content
- The analyst agent is read only and sees only what the user can see
- Builder changes that touch patient data need a person to confirm
HIPAA design checklistPlatform controls
BAA capable cloudHosting on cloud providers that sign BAAs.
EncryptionEncrypted at rest, TLS in transit, verified for each cell at deploy.
Audit trailAppend only event log for every change.
Read auditingReads, searches and exports of patient data recorded with the actor.
Field level permissionsRole, row and field rules enforced in the query compiler.
No PHI in logsRedaction by field from day one.
Region pinningEach application mapped to a cell and region on every request.
BAA rules for AIThe model gateway refuses providers without a BAA for patient data apps.
Assurance
Where things stand today.
We would rather tell you exactly what exists than put a badge on the page.
HealthTable
HealthTable does not hold its own security certifications yet. Independent testing and formal certification are planned. Ask us for the current controls document and the status of each item.
Selah Digital
Selah Digital, the company that builds and operates HealthTable, completed a SOC 2 Type 2 report in 2025. Ask us about access to the report.
Business associate agreements
HealthTable is designed for HIPAA workloads. We sign a BAA with customers before any patient data reaches the platform, and use BAA capable subprocessors.
Questions for your security review? Contact us and we will route them to the right person.
Bring your security questionnaire.
We will walk through the architecture, the controls and what is still on the roadmap, in as much detail as your team needs.