Responsible AI Policy

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. Purpose and Scope

This Responsible AI Policy describes how DocVerb designs, deploys, and governs the artificial intelligence systems that power our clinical documentation platform. It applies to all AI-driven features including medical scribing, SOAP note generation, prescription drafting, clinical summaries, and follow-up recommendations.

We do not claim certification, regulatory approval, or compliance with any specific AI standard beyond what is stated herein. This policy reflects our operational commitments as of the effective date and will evolve as technology and best practices advance.

2. AI System Overview

DocVerb's AI systems are documentation assistants, not clinical decision-makers. Our models perform the following functions:

  • Medical Scribing: Transcribe and structure doctor-patient consultation audio into clinical documentation
  • SOAP Note Generation: Organize clinical information into Subjective, Objective, Assessment, and Plan format
  • Prescription Drafting: Generate draft prescription text based on dictated medication orders
  • Clinical Summaries: Produce concise visit summaries, discharge notes, and referral letters
  • Follow-up Recommendations: Suggest follow-up intervals, tests, or referrals based on documented content

All outputs are drafts requiring review, editing, and approval by the treating healthcare provider before clinical use.

3. Human-in-the-Loop: Mandatory Clinical Review

DocVerb assists with documentation and workflow. The treating healthcare provider remains responsible for clinical decisions.

  • Every AI-generated output is presented in an editable interface requiring explicit provider review
  • No output is auto-saved, auto-sent, or auto-executed without provider action
  • Providers must verify accuracy, completeness, and clinical appropriateness before signing or transmitting
  • Prescription drafts require manual dose, frequency, and duration confirmation
  • SOAP notes require provider attestation before entering the medical record

There are no autonomous clinical decisions. The AI does not diagnose, recommend treatment plans independently, or override provider judgment.

4. Accuracy, Limitations, and Hallucination Risk

We are transparent about system limitations:

  • Hallucination Risk: Generative models may produce plausible but incorrect clinical content (wrong drug names, dosages, ICD codes, or clinical assertions). Providers must verify every detail.
  • Not a Diagnostic Tool: DocVerb does not perform diagnosis, differential diagnosis, risk stratification, or clinical decision support. It structures information you provide.
  • Audio Quality Dependency: Transcription accuracy degrades with background noise, overlapping speech, accents, or poor microphone placement
  • Specialty and Language Coverage: Performance varies across specialties and Indian languages. We publish benchmark results per specialty/language quarterly
  • Context Limitations: The model lacks access to full patient history, lab results, imaging, or longitudinal records unless explicitly provided in the consultation

We publish accuracy metrics (word error rate, clinical entity F1, prescription accuracy) per specialty and language on our website, updated quarterly.

5. Bias Mitigation

  • Diverse Training Data: Models trained on multi-specialty, multi-lingual, multi-accent clinical data representing diverse patient populations across India
  • Regular Evaluation: Quarterly bias audits measuring performance disparities across gender, age groups, languages, accents, and specialties
  • Disparity Thresholds: If any demographic group shows >5% relative performance gap vs. overall, we prioritize targeted data collection and model retraining
  • External Review: Annual third-party bias assessment by independent clinical informatics researchers

6. Transparency and Explainability

  • AI-Generated Labels: Every output field carries a visible "AI-generated" indicator
  • Confidence Indicators: Low-confidence transcriptions or uncertain clinical entities highlighted in the editing interface
  • Source Attribution: Where possible, generated content linked to source audio segments for verification
  • Model Cards: Published model cards documenting training data composition, intended use, limitations, and performance benchmarks per model version

7. Privacy and Data Protection

  • No Training on User Data: Your consultations, audio, and generated documentation are never used to train, fine-tune, or improve our models
  • Data Minimisation: Audio processed transiently and deleted within 24 hours. No centralized patient identity databases
  • No Patient Identifiers Collected: We do not collect patient names, IDs, phone numbers, Aadhaar, ABHA IDs, or demographics as separate fields
  • Processor Role: DocVerb acts as Data Processor; you (the doctor/practice) are the Data Controller
  • India-Hosted Inference: Primary AI inference runs in India (Mumbai/Bangalore regions) per DPDP Act requirements

See our Privacy Policy and DPDP Compliance page for full details.

8. UID Architecture: Anonymous-by-Design Identity

DocVerb employs a Unique Identifier (UID) architecture that fundamentally decouples clinical data from human identity. This is not pseudonymization—it is structural anonymity by design.

  • Only SOAP notes and prescriptions stored: No identifying information (names, IDs, phone numbers, Aadhaar, ABHA, demographics) is ever stored on our servers
  • Name/details shown on screen once, never uploaded: During the first consultation process, patient details appear on the doctor's screen for verification but are never transmitted or stored on DocVerb infrastructure
  • UID not linked to human identification: The UID is a random opaque token generated per consultation. It has no mapping to any real-world identity in our systems
  • Anonymous on server: On DocVerb servers, the UID exists only as a linkage key between Doctor ID, Patient ID, and timestamp—without any of these components, the data is cryptographically inaccessible
  • Identification only via external sharing: A patient can only be identified if the UID is explicitly shared from outside the system (e.g., doctor communicates UID to patient via external channel)
  • Doctor ID + Patient ID matching required: Data is encrypted and partitioned such that without both the Doctor ID and Patient ID matching, the clinical content cannot be decrypted or accessed
  • Four-factor identification: The only way to resolve a consultation to a real identity is the combination of Doctor ID + Patient ID + UID + timestamp—all four must be present and held by the same party (the treating doctor)

This architecture means DocVerb cannot identify patients, cannot build longitudinal profiles across doctors, and cannot comply with data requests for "all data about person X" because that linkage does not exist in our systems.

9. AI Governance Enabled by UID Architecture

The UID architecture directly enables our AI governance commitments:

  • No training on PII: Since no PII exists in our stored data (only SOAP content, prescriptions, UID, Doctor ID, Patient ID, timestamp), there is no PII to accidentally include in training data. Model training uses only de-identified clinical text with zero identity linkage
  • Bias testing on de-identified data: Quarterly bias audits evaluate model performance across clinical attributes (specialty, language, acuity, note length) using fully de-identified datasets. Demographic bias testing uses only the clinical proxies present in the documentation itself—no external demographic data is joined
  • Audit trail via UID + timestamp: Every AI generation event is logged with UID, timestamp, model version, Doctor ID hash, and content hash. This provides a complete, tamper-evident audit trail of what was generated, when, by which model, for which consultation—without ever recording who the patient is
  • Provider-controlled accountability: The treating doctor holds all four identification factors. They can produce an audit trail for any specific consultation by presenting the UID + timestamp. DocVerb cannot do this unilaterally
  • Incident scoping without identity exposure: If an AI safety event is detected, the incident can be traced to the specific UID + timestamp + model version for root cause analysis, without ever exposing patient identity

10. Accountability and Audit Trails

  • Immutable Audit Logs: Every AI generation, edit, approval, and export event logged with timestamp, user ID, model version, and content hash
  • Version Control: All model versions, prompts, and configuration changes tracked in version control with change rationale and testing evidence
  • Provider Attestation: Final signed documentation includes provider identity, timestamp, and explicit approval action
  • Incident Response: Documented process for AI-related safety events, including root cause analysis and corrective action tracking

11. Continuous Monitoring

  • Real-Time Metrics: Latency, error rates, fallback triggers, and confidence distributions monitored per model version
  • Clinical Quality Sampling: Random stratified sample of generated notes reviewed weekly by clinical quality team
  • Drift Detection: Statistical monitoring for input distribution shifts and output quality degradation
  • Automated Rollback: Canary deployments with automated rollback on quality regression thresholds

12. User Feedback Loop

  • In-App Feedback: One-click "Report Issue" on every generated field captures provider corrections
  • Correction Analytics: Aggregated correction patterns drive model improvement priorities (no individual data used)
  • Quarterly Provider Council: Structured feedback sessions with practicing clinicians across specialties
  • Public Changelog: Model updates, accuracy improvements, and bug fixes published with release notes

13. What We Are Improving

We acknowledge current limitations and are actively investing in:

  • Reducing hallucination rates through retrieval-augmented generation grounded in clinical knowledge bases
  • Expanding language and accent coverage for Indian regional languages
  • Improving specialty-specific accuracy (currently strongest in general medicine, pediatrics, cardiology)
  • Better uncertainty quantification and calibrated confidence scores
  • Structured evaluation frameworks for clinical safety (beyond transcription accuracy)
  • Formal red-teaming for clinical harm scenarios

14. Governance and Oversight

  • AI Governance Committee: Cross-functional committee (clinical, engineering, legal, security) reviews policy quarterly
  • Clinical Safety Officer: Designated clinician responsible for AI safety oversight
  • Regulatory Tracking: Monitor evolving AI regulations (EU AI Act, India DPDP, FDA guidance, ABDM standards)
  • Policy Versioning: This policy version-controlled; material changes notified 30 days in advance

15. Related Policies

16. Contact

Questions, concerns, or feedback on this Responsible AI Policy:

docverb.no.reply@gmail.com (Subject: Responsible AI)

We commit to responding within 30 days.