Skip to content

HIPAA & data handling

Last updated: June 2026

This page explains, plainly and honestly, how PromptDoc approaches sensitive-data handling — and what it does and does not claim. We have written it to be accurate rather than reassuring: please read it before using PromptDoc in any setting that could involve patient information.

The honest version

There is no such thing as “HIPAA-certified” software — no such certification exists, and any product claiming it is misrepresenting the law. HIPAA compliance is a property of contracts, configuration, and practice: a signed Business Associate Agreement (BAA) with each vendor that handles protected health information (PHI), services configured so data is not retained or used for training, and workflows on your side that respect the rules. PromptDoc is built around that reality.

What PromptDoc claims — and what it does not

  • We do not claim PromptDoc is “HIPAA compliant” or “HIPAA-certified.” PromptDoc provides prompt templates and tooling designed to support safe workflows; it does not, by itself, make your use HIPAA compliant.
  • We do not claim to have a BAA in place covering your patient data. The in-app AI chat is built to run on a BAA-capable provider (Microsoft Azure OpenAI), but whether a BAA actually applies depends on the account configuration and signed agreements, which are the customer’s responsibility.
  • PromptDoc currently operates in a no-PHI posture. It is intended for de-identified, educational, and drafting use. You must not enter patient-identifiable information.

How PromptDoc is designed to protect data

  • No PHI by design. Every prompt instructs you not to enter patient-identifiable information, and the AI chat screens every message with a PHI guard (based on the HIPAA Safe Harbor identifier categories) before it is sent. High-confidence matches block sending until you redact or confirm the data is not real.
  • Zero retention by default. Chat message content is not stored unless you opt in, and opting out deletes anything stored.
  • Explicit provider, never a silent fallback. The chat only calls the model provider configured by the operator. If none is configured, the chat is disabled rather than routed to a consumer endpoint. The active provider is shown in the runner header.
  • Counts-only logging. The PHI guard records that a check ran and how many matches were found — never the content.

The PHI guard is an aid, not a guarantee

Pattern-based detection can miss identifiers and can over-flag harmless text. It is designed to make entering PHI a deliberate, friction-ful act — not to make it safe. The obligation not to enter patient-identifiable information always remains yours.

What full PHI use would require

Before any genuinely sensitive patient data flows through a deployment, the operator and customer would need to ensure:

  • a signed BAA between the responsible entity and the inference provider (and any other vendor handling PHI);
  • the provider configured for zero data retention and with abuse-monitoring/human-review opt-outs completed where applicable;
  • appropriate organisational policies, access controls, and staff training; and
  • review of these arrangements by qualified legal counsel.

Until those are in place, do not enter real patient data.

Australian context

HIPAA is a United States framework. If you practise in Australia, your obligations arise instead under the Privacy Act 1988 (Cth) and the Australian Privacy Principles, the My Health Records Act 2012 (Cth) where relevant, and applicable state and territory health-records legislation. The same principle applies: do not enter patient-identifiable information, and ensure any tool you use meets your obligations. See our Privacy Policy for how we handle your personal information.

Questions

If you are evaluating PromptDoc for a setting that may involve patient information, contact us first at mahmoud121999@gmail.com and confirm the full chain — contract, configuration, and practice — with your own compliance team and legal counsel.