Security at Auravio.

Auravio handles patient-derived information. Trust in clinical software is earned through specific, verifiable choices, not assurances. This page documents what's in place today, what's planned, and what isn't yet.

How patient data is handled

Encryption at rest. Every patient-derived field, source transcripts, translations, summaries, structured extractions, is encrypted at the column level using authenticated encryption. The encryption key is held outside the database and rotated independently. Compromise of the database alone does not yield readable patient data.

Encryption in transit. All connections to Auravio, clinician to web app, web app to backend, backend to model providers, use TLS 1.3. Certificates are managed automatically and renewed continuously.

Authentication. Auravio uses OpenID Connect single sign-on. Today this means Google Workspace; SAML and hospital identity provider integration are part of the deployment-ready architecture.

Session security. Sessions are signed JWTs with an 8-hour lifetime, transmitted over secure cookies with strict cross-site protection. Session revocation is immediate on logout.

Role-based access. Clinician, admin, and read-only roles are enforced server-side. No client-controlled access logic. Privilege boundaries are tested with the deployed test suite.

Every session event is recorded

Auravio maintains an append-only audit log of every meaningful event: session creation, audio submission, trust evaluations, summary generation, FHIR exports, deletions, and admin actions. The append-only property is enforced by database-level constraints rather than application logic, so ordinary application code paths cannot modify or remove audit entries.

The audit log is the basis for institutional accountability. A hospital deploying Auravio gets a verifiable trail of every clinical interaction the system was part of, including the trust signals surfaced and the recommendations issued.

Auravio maintains an append-only audit log of every meaningful event: session creation, audio submission, trust evaluations, summary generation, FHIR exports, deletions, and admin actions. The append-only property is enforced at the database level, not in application code. Even Auravio’s own administrators cannot retroactively modify or delete audit entries.

The audit log is the basis for institutional accountability. A hospital deploying Auravio gets a verifiable trail of every clinical interaction the system was part of, including the trust signals surfaced and the recommendations issued.

Data lifecycle

Retention is configurable per deployment. Defaults are conservative: session content retained 90 days unless explicitly preserved by the clinician; soft-deletion grace period of 30 days; audit log retained 7 years per HIPAA-aligned requirements.

Session-level deletion is supported and propagates through all derived data (transcripts, translations, summaries, FHIR drafts) while preserving audit trail entries that record the deletion event itself. Hard deletion runs on a scheduled retention cleanup job.

Where Auravio stands today

Architected for HIPAA-aligned operational practices. The technical safeguards required by the HIPAA Security Rule — access control, audit controls, integrity controls, transmission security, are implemented. Administrative and physical safeguards are documented in the deployment guide.

BAA execution is a contracting step, not a re-architecture. Auravio’s architecture separates patient data flow from administrative metadata, so the contractual requirements a Business Associate Agreement imposes map cleanly onto the system as built. No BAA is currently in effect, and Auravio has not processed protected health information. Subprocessor BAAs — with our speech recognition provider, model providers, and infrastructure host — will be executed before any PHI is processed, as HIPAA requires of a business associate’s subcontractor chain.

Not yet HIPAA-certified. HIPAA does not have a single certification body in the way SOC 2 does, but formal third-party security audits, penetration testing, HITRUST assessment, or equivalent, have not yet been completed. These are part of the path to a real production hospital deployment that Auravio plans to embark on.

No SOC 2 report yet. SOC 2 Type 1 and Type 2 reports require sustained operational maturity that an early-stage product cannot honestly claim. SOC 2 work is on the path; it is not done.

Subprocessors

The vendors below would process or store patient-derived data in a production deployment. None currently process protected health information. Each requires an executed Business Associate Agreement before PHI may flow through it, and this list will be updated as those agreements are put in place.

Vendor | Purpose | Data handled | BAA status

AssemblyAI | Speech recognition | Session audio, source transcripts | Not executed

Anthropic | Translation, summarization | Transcripts, translations, summaries | Not executed

OpenAI | Translation, summarization | Transcripts, translations, summaries | Not executed

Railway | Application hosting, database | All patient-derived stored data | Not executed

Cloudflare | DNS, CDN | Network metadata only | Not applicable

Framer | Marketing website only | No patient data | Not applicable

Questions about this list, or requests for security documentation, can be sent to support@auravio.org.