Bosshh
Sign in Book a demo

Security and compliance

Bosshh handles protected health information. This page describes how the software is built to handle it, and is written to be checkable rather than reassuring.

If you are deploying this yourself: the controls below are what the application implements. Certifications, business associate agreements, infrastructure hardening, backup policy, and breach procedures are properties of a deployment and an organisation — not of source code. Do not represent an audit posture you have not actually completed.

Access control

  • Every user belongs to exactly one agency, and every query for patient data is scoped to that agency. Cross-tenant reads are not possible through the application.
  • Four roles — clinician, intake coordinator, coder, administrator — gate the features each person can reach.
  • Sessions are cookie-based, HTTP-only, SameSite-restricted, secure when served over TLS, and time out after an idle period.
  • Passwords are stored with a modern hashing algorithm and rehashed on sign-in when the algorithm's parameters change.
  • Every state-changing request carries a CSRF token.

Audit trail

  • Record access is logged, not just record modification — who viewed which patient, chart, or referral, from which address, and when.
  • Clinical writes record the model that produced them, the token counts, the generation time, and the transcript the draft was derived from.
  • Charts are versioned rather than overwritten. Signing captures the signer, the timestamp, and an explicit attestation.
  • Coding decisions record which person accepted, edited, or rejected each suggested code.

Where data goes

  • Visit audio is stored outside the web root and served only through authenticated, authorised routes.
  • Transcription runs on a provider you configure. The default requires no third party at all — a clinician enters the transcript — and a local Whisper option keeps audio on your own hardware.
  • Text sent to the model API is the transcript, referral content, and chart context needed for the task at hand. Anything you send to a model vendor belongs inside whatever business associate arrangement covers the rest of your PHI.
  • Signed charts leave as a structured JSON payload, either to a local outbox directory or to an HTTPS endpoint you control.

Application hardening

  • A strict Content Security Policy with per-request nonces for inline script; no third-party origins are permitted.
  • Uploads are validated by sniffed content type rather than filename, stored under generated names, and kept outside the document root. Path traversal is blocked on read.
  • All database access uses prepared statements with bound parameters.
  • Authenticated pages are marked no-store, and application pages are excluded from search indexing.
  • Error output is suppressed in production so a stack trace cannot disclose patient data.

Clinical safety

  • Generated documentation is a draft. A licensed clinician reviews and signs it, and the attestation is recorded with their identity.
  • Blocking gaps prevent signature until they are resolved or explicitly addressed.
  • Scored items carry their supporting evidence and a confidence level, so review is verification rather than trust.
  • Suggested diagnosis codes require a coder's explicit decision before becoming part of the coded record.
  • Vitals and measurements are recorded only when stated; the system does not estimate clinical values.

Questions

Send security and compliance questions to security@bosshh.example, or raise them on a demo call — we would rather answer them early than late.