1. What Fortify is — and is not
Fortify is a compliance-management platform. It tracks whether your practice's clinical systems, identity providers, and operational processes are configured the way HIPAA, SOC 2, ISO 27001, and GDPR require. The actual clinical work — the EHR, the practice-management system, the billing clearinghouse — stays where it lives today. Fortify is the layer that watches the configuration, not the layer that stores the patient data.
Fortify is not a Business Associate under HIPAA. That distinction is intentional and structural. We do not need a Business Associate Agreement with you because we do not handle Protected Health Information on your behalf.
2. The no-PHI invariant — four enforcement layers
“We don't want PHI” is a policy. “We can't accept PHI” is an architecture. Fortify treats it as the latter, enforced at four independent layers so a bug at any single layer does not breach the guarantee.
Layer 1 — AI prompt firewall
Every call to the language-model provider includes a system prompt (NO_PHI_AI_SYSTEM_PROMPT) explicitly instructing the model to refuse any input that contains identifiable patient information and to never echo such data back. Fortify's prompts to the model carry only compliance metadata: control names, framework citations, integration scan results, control statuses.
Layer 2 — API schema gate
Every API endpoint that accepts free-text input passes the body through a PHI-pattern scanner before any database write. The scanner looks for SSN patterns, MRN labels, date-of-birth labels, ICD-10 diagnosis codes, and other obvious PHI signals. A match returns a 422 with a clear rejection message — the request never reaches the database.
Layer 3 — Database CHECK constraint
Every multi-tenant table that could conceivably store text fields carries a Postgres CHECK constraint (_no_phi_check) at the schema level. A row that contains a recognized PHI pattern is rejected by the database itself, regardless of which application code attempted the write or with what privileges.
Layer 4 — UI surfaces
Every page where a workforce member can upload a file, paste text, or write a note displays a persistent NO-PHI badge and a red warning at the point of action. The customer is reminded — every time — that this platform is not configured to receive Protected Health Information.
3. What Fortify does store
Compliance-program metadata only:
- Control library content (framework citations, mappings, remediation guidance)
- The practice's self-asserted posture against each control (compliant / partial / non-compliant)
- Evidence-collection results: integration scan outputs (e.g. “MFA enrollment 96%”), document upload paths, attestation timestamps
- Workforce membership: name, email, role, employment dates
- OIG LEIE exclusion-screening results (workforce members only, never patients)
- Audit logs of every privileged action within the platform
- Encrypted integration credentials (OAuth tokens, API keys), sealed via a KMS-backed helper with the symmetric key held outside the database
4. What Fortify never stores
- Patient names, addresses, phone numbers, dates of birth, ages over 89
- Medical record numbers, account numbers, health plan beneficiary numbers
- Diagnoses, treatment notes, medication lists, lab results, imaging
- Billing line-items, insurance claim contents
- Any of the 18 HIPAA Safe Harbor identifiers
5. Subprocessor list
Because Fortify does not store PHI, none of our subprocessors are HIPAA Business Associates of yours. They are infrastructure vendors providing standard SaaS services:
- Supabase — Postgres database + authentication + object storage. Hosts compliance metadata only.
- Vercel — Application hosting + serverless functions + cron.
- Anthropic (Claude) — Language-model API for compliance narrative generation. Receives only compliance metadata, never PHI (enforced by Layer 1 above).
- Stripe — Billing only. Never receives patient data.
- Resend — Transactional email (workforce notifications, task reminders).
6. Customer responsibility
The architectural guarantees above hold as long as customers do not deliberately attempt to upload PHI to Fortify. The Customer Agreement explicitly requires that customers not upload PHI; the point-of-action warnings reinforce this; the API and database gates reject obvious cases. A determined customer could still defeat the gates (e.g., by uploading an encrypted file containing PHI under an innocuous filename). That risk sits with the customer — not with Fortify — and is the structural reason Fortify is not a Business Associate.
7. Verifying these claims
Every claim in this document corresponds to source code in Fortify's repository. Specifically:
- Layer 1:
lib/compliance/no-phi.ts—NO_PHI_AI_SYSTEM_PROMPT - Layer 2:
lib/schemas/api.ts—scanFieldsForPhi - Layer 3:
supabase/migrations/013_no_phi_invariant.sql— table CHECK constraints - Layer 4:
components/ui/NoPhiBadge.tsx,components/ui/NoPhiWarning.tsx - Customer warnings: every form that accepts file upload or free text imports
NoPhiWarning - Server-side upload scanner:
lib/compliance/phi-scanner.ts
A read-only repository review under NDA is available to enterprise customers' security teams. Contact security@fortifynow.xyz.