Our role with PHI: we're a processor, not an owner
Othisis is designed to provide AI-powered clinical documentation and data processing as a pure data processor. We do not practice medicine, and we do not turn PHI into a product.
Business Associate posture
Othisis functions as a Business Associate, not a data owner. Your patients' PHI is owned by the Covered Entity and patient; Othisis is a tool and processor not a secondary controller and not a direct monetizer of PHI.
"We built Othisis with a simple assumption: our data protection choices may be reviewed by a regulator, a hospital privacy officer, or an attorney."
How our AI works: assistive, reviewable, traceable
Clinicians should feel supported, not replaced. This isn't just a product choice—it's a trust choice.
- Assistive AI: Models generate drafts; clinicians make the final medical decisions.
- Human-in-the-loop: Every AI output that can impact a record is reviewed, edited, and approved by a human with full traceability.
- Traceability first: We favor systems that show exactly which source text led to which output, instead of "black box" output.
Data minimization: only what's needed
We aim to collect, store, and expose only the data necessary for a specific purpose.
Access to PHI is designed around least privilege and "minimum necessary," and PHI is not sent to tools or vendors without a valid purpose and documented controls.
Safe handling outside production
Non-production environments use de-identified or synthetic data. This reduces risk while still allowing teams to test and improve the system safely.
Vendors & AI providers
We treat third parties as part of the risk surface, not an afterthought:
- No PHI is provided to a vendor without a signed BAA (if applicable) and a completed vendor risk assessment.
- AI model providers are not allowed to train their general models on Othisis PHI.
- Providers must support Othisis's traceability and human-in-the-loop requirements.
Security controls currently in place
We keep our security posture factual and specific, focused on clinical outcomes rather than just infrastructure.
Audit logging & monitoring
We maintain audit visibility across systems that process PHI so that access and activity can be reviewed for compliance and operational accountability.
Access control & role-based permissions
We use role-based access control (RBAC) to limit access based on job function and the principle of least privilege.
Security & privacy highlights
- HIPAA-Compliant Hosting: Othisis is intended to be used only in HIPAA-compliant workflows (scribe, PDF summarization) with traceability and human review.
- Vendor Risk Management: No PHI is shared with a vendor without a BAA (when the vendor is a BA) and a documented vendor risk assessment.
- Encryption at Rest & In Transit: Our documented standard is to store data encrypted in approved locations/regions with defined retention.
- Data Backup & Recovery Plan: Our approach requires disaster recovery, backup, and availability plans that are tested and preserve encrypted copies of PHI.
- Incident Response Plan: We track preparedness and improvement using defined metrics, including time to respond to and contain incidents involving PHI.
- Audit Logging: Detailed logs are kept of who accessed and changed data, and what actions AI performed—so events are traceable and accountable.
- Access Control & Role-Based Permissions: Least privilege and "minimum necessary" are core principles, and RBAC is used in our cloud environments.
- HIPAA Training for Workforce: All workforce members with access to PHI must complete HIPAA training and an orientation on this data protection vision.
What this covers (scope)
This posture applies to PHI/ePHI processed through Othisis, including audio, transcripts, notes, PDFs, AI outputs, metadata, and logs that may contain PHI across production and non-production environments.
