HIPAA Compliance Status

Effective Date: August 2, 2025 | Last Updated: August 2, 2025

DocVerb separates patient identity from clinical documentation. Our server architecture is designed to exclude direct patient identifiers such as names, phone numbers, email addresses, dates of birth, government IDs, locations, and other demographic attributes from clinical processing, storage, and indexing. Clinical conversations are processed exclusively to extract relevant medical information for generating SOAP notes and prescriptions, without creating patient identity profiles.

Only SOAP notes, prescriptions, and a doctor-specific anonymous UID are securely stored. This UID maintains continuity of care exclusively within the same doctor–patient relationship without creating a universal patient identity.

1. Current Status — Direct Statement

DocVerb is not HIPAA compliant as of the effective date.

We do not have a Business Associate Agreement (BAA) in place. We do not hold any HIPAA certification, attestation, or formal compliance designation. We are not a Business Associate under HIPAA until a BAA is executed.

This page describes our current controls honestly, identifies gaps against the HIPAA Security Rule and Privacy Rule, and outlines our roadmap. DocVerb is designed with data minimisation principles. Clinical documentation is protected using encryption at rest and in transit. The treating healthcare provider remains responsible for clinical decisions. DocVerb assists with documentation and workflow.

2. What HIPAA Requires (Summary for Context)

The HIPAA Security Rule (45 CFR Part 164, Subpart C) requires covered entities and their business associates to implement:

  • Administrative safeguards: Risk analysis (§164.308(a)(1)), workforce training (§164.308(a)(5)), contingency planning (§164.308(a)(7)), BAA with subprocessors (§164.308(b)(1))
  • Physical safeguards: Facility access controls, workstation/device security (§164.310)
  • Technical safeguards: Access control (§164.312(a)), audit controls (§164.312(b)), integrity (§164.312(c)(1)), transmission security (§164.312(e))
  • Privacy Rule: Permitted uses/disclosures, minimum necessary, individual rights, breach notification (§164.400–414)
  • Breach Notification Rule: Notification to individuals, HHS, and media (where applicable) within 60 days

3. What We Have That Aligns With HIPAA Technical Safeguards

The following controls are implemented today and map to HIPAA Security Rule technical safeguards. These are technical controls only — they do not constitute HIPAA compliance without the administrative and physical safeguards, a BAA, and formal risk analysis.

3.1 Access Control (§164.312(a))

  • Unique user identification: JWT-based authentication (RS256, 15-min expiry), refresh tokens with rotation
  • Emergency access procedure: Break-glass documented for engineering; MFA + approval required
  • Automatic logoff: Token expiry enforced; concurrent session limits; admin revocation
  • Encryption/decryption: AES-256-GCM at rest; TLS 1.3 in transit; envelope encryption via cloud KMS
  • Role-based access: Owner, Admin, Clinician, Staff, Billing, Read-only; workspace-scoped; custom roles for enterprise

3.2 Audit Controls (§164.312(b))

  • Immutable audit logs (append-only, Object Lock/WORM) capturing: authentication, authorization changes, data access, export, deletion, admin actions, AI generation
  • Each entry includes: timestamp, actor (user/service), action, resource, result, IP, user-agent, correlation ID
  • Retention: 2 years minimum; 7 years for export/deletion events
  • SIEM integration with real-time alerts for anomalous access, privilege escalation, geo-impossible login

3.3 Integrity Controls (§164.312(c)(1))

  • AES-256-GCM provides authenticated encryption (confidentiality + integrity)
  • Database row-level security enforces workspace boundaries; no cross-practice access
  • Signed URLs (HMAC-SHA256) for QR follow-up workflows with ephemeral one-time tokens

3.4 Transmission Security (§164.312(e))

  • TLS 1.3 for all external traffic; mTLS for internal service-to-service
  • Certificate pinning on mobile SDKs
  • No plaintext PHI in URLs, logs, or error messages

3.5 Data Minimisation Architecture (Supports Minimum Necessary)

  • No patient identity database: We do not store patient identifiers that could link consultations across providers
  • Per-user isolated workspaces (UID namespace): Cryptographic isolation; no cross-patient linking
  • Transient audio processing: Audio deleted after documentation generation
  • No patient accounts: QR follow-up uses signed URLs — no patient PII, no login, no sessions

3.6 UID Architecture (De-Identification by Design)

The following describes our UID-based architecture that supports HIPAA-aligned de-identification. This is a technical architecture description — it does not constitute a HIPAA Safe Harbor or Expert Determination.

  • Only clinical content stored: SOAP notes and prescriptions are stored. No patient name, phone, email, government ID, date of birth, or other direct identifiers are ever persisted in our systems.
  • On-screen display only: Patient name and details are shown on the clinician's screen exactly once during the encounter for verification, but are never uploaded, logged, or transmitted to our servers.
  • UID is not linked to human identity: The UID (Unique Identifier) exists only as an anonymous reference within our server. It cannot be resolved to a human identity by DocVerb.
  • External linkage only: A patient can only be identified if the UID is explicitly shared from outside our system (e.g., by the clinician or patient themselves through external channels).
  • Multi-factor data isolation: Data access requires Doctor ID + Patient ID matching. Without this match, clinical data remains cryptographically inaccessible.
  • Complete identification tuple: The only theoretical identification path requires all four components simultaneously: Doctor ID + Patient ID + UID + Timestamp. No subset of these elements can identify a patient.

3.7 Processor Role

  • DocVerb acts as a data processor; the healthcare provider is the data controller
  • Data Processing Agreements (DPAs) in place with all subprocessors (cloud, AI inference, payments, email, monitoring)
  • Subprocessor list available on request: docverb.no.reply@gmail.com

4. Gaps Against HIPAA Requirements

The following gaps exist as of the effective date. These are not oversights — they are deliberate priorities for our roadmap.

4.1 No Business Associate Agreement (BAA)

We do not offer a BAA today. Without a BAA, DocVerb is not a Business Associate under HIPAA. Covered entities using DocVerb do so without HIPAA business associate protections.

4.2 No Formal Risk Analysis (§164.308(a)(1))

We conduct internal threat modeling (STRIDE) for new features and maintain architecture decision records, but we have not completed a formal, documented HIPAA Security Rule risk analysis covering all ePHI systems, threats, vulnerabilities, and likelihood/impact assessments.

4.3 No Formal Workforce Training Program (§164.308(a)(5))

Employees complete general security awareness (phishing simulation, secure coding, incident reporting), but we do not have a HIPAA-specific workforce training program with documented completion tracking, periodic updates, and sanctions policy.

4.4 No Documented Contingency Plan (§164.308(a)(7))

We have an incident response plan (72-hour notification, runbooks, tabletop exercises) and encrypted per-workspace backups with point-in-time recovery. However, we do not have a formal HIPAA contingency plan covering: data backup plan, disaster recovery plan, emergency mode operation plan, testing/revision procedures, and applications/data criticality analysis specific to ePHI.

4.5 No BAAs With All Subprocessors

We have DPAs with all subprocessors (GDPR/DPDP standard). We do not yet have HIPAA-compliant BAAs with subprocessors that would process ePHI on our behalf (cloud infrastructure, AI inference providers, monitoring).

4.6 No Formal Sanctions Policy (§164.308(a)(1)(ii)(C))

We have confidentiality agreements and offboarding procedures, but no documented sanctions policy for workforce violations of HIPAA policies.

4.7 No Formal Business Associate Due Diligence (§164.308(b)(1))

Subprocessor due diligence includes security questionnaires, SOC 2 review, and penetration test reports — but not HIPAA-specific assessment or BAA execution.

5. Roadmap

We are building toward HIPAA readiness with the following milestones:

Milestone Target Notes
BAA availability for US-covered entities Q1 2026 Enterprise plans first; technical controls already mapped to Security Rule
Formal HIPAA risk analysis Q1 2026 NIST 800-30 aligned; documented, reviewed, updated annually
HIPAA workforce training program Q1 2026 Role-based, tracked completion, annual refresh, sanctions policy
Formal contingency plan (§164.308(a)(7)) Q2 2026 Backup, DR, emergency mode, testing, criticality analysis
BAAs with all subprocessors handling ePHI Q2 2026 Cloud, AI inference, monitoring; aligned with our DPA renewals
Sanctions policy (§164.308(a)(1)(ii)(C)) Q1 2026 Documented, communicated, enforced
Third-party HIPAA attestation H2 2026 Targeting external audit after BAA execution and controls maturity

6. Guidance for US-Based Healthcare Providers

You are the Covered Entity. Under HIPAA, you retain responsibility for:

  • Determining whether DocVerb is appropriate for your workflow given our current status
  • Ensuring any PHI disclosed to DocVerb is permitted without a BAA (e.g., for treatment, payment, operations — but note: without a BAA, we are not a Business Associate and HIPAA does not regulate us directly)
  • Your own HIPAA compliance: risk analysis, workforce training, contingency planning, BAAs with your business associates
  • Breach notification obligations if a breach occurs involving PHI processed through DocVerb
  • Clinical decisions: The treating healthcare provider remains responsible for clinical decisions. DocVerb assists with documentation and workflow.

Until a BAA is executed:

  • DocVerb is not your Business Associate
  • HIPAA does not impose direct obligations on DocVerb
  • We are contractually bound by our Terms of Service and Privacy Policy (processor commitments under GDPR/DPDP), not HIPAA
  • You should evaluate whether using DocVerb without a BAA aligns with your compliance program and risk tolerance

We recommend consulting your HIPAA privacy/security officer or legal counsel before using DocVerb for PHI.

7. What Changes When a BAA Is Executed

Upon BAA execution (target Q1 2026 for enterprise plans):

  • DocVerb becomes your Business Associate under HIPAA
  • We assume direct HIPAA obligations for the ePHI we process on your behalf
  • We will provide: BAA, risk analysis summary, workforce training evidence, contingency plan, subprocessor BAA status
  • Breach notification: We will notify you within 72 hours of discovery (aligned with our IR plan and GDPR/DPDP)
  • You retain all Covered Entity responsibilities; the BAA defines our respective obligations

8. Related Policies

9. Contact for BAA Discussions

If you are a US-covered entity interested in a BAA, or have questions about our HIPAA roadmap:

docverb.no.reply@gmail.com (Subject: BAA / HIPAA)

We will respond within 5 business days. BAA discussions are prioritized for enterprise plans; we will share our BAA template, risk analysis summary (when available), and subprocessor status upon request under NDA.