Protecting clinical data

Encryption in transit

All traffic between clients and services is encrypted.

• TLS/HTTPS protects the REST API; realtime connections use WSS.
• Session tokens travel in request headers, not in URLs.

Encryption at rest

Stored clinical data is encrypted by the managed data layer.

• At-rest encryption is provided by the managed database layer.
• Encryption keys are managed with KMS.

Secrets management

Credentials are centralized and never checked in.

• Application secrets are stored in AWS Secrets Manager and encrypted with a dedicated KMS key.
• Secrets are never embedded in code, container images, or logs.

Access controls

Access is scoped to the caller's role and facility on every request.

• Database-backed role-based access control with granular, per-role permissions.
• Per-facility data isolation derived from the verified session, not from client-supplied input.

Data minimization

We keep clinical detail out of surfaces where it isn't needed.

• We minimize clinical data in push notifications, logs, and event payloads.
• Notification content is generic and read in-app after unlock.
• Room and location display is configurable per facility.

Audit logging

Critical state changes are recorded in a durable, append-only log.

• A durable, append-only event log records critical incident state changes.
• Authentication events are logged with source IP and device.

Retention

Retention follows clinical and legal needs; automated tooling is maturing.

• Retention is aligned to clinical and legal needs.
• Automated retention and purge tooling is on our roadmap (planned).

Privacy by design

Access is minimum-necessary and sessions are short-lived.

• Access follows the minimum-necessary principle.
• Sessions are short-lived to limit exposure.

Control status

An honest summary of where each control stands today.