Where the data goes,
every transfer accounted for.
End-to-end PHI inventory. Every transfer a customer prompt or document makes, who sees it, what controls protect it, and where it ends up. This is the document procurement teams ask for; we publish it openly.
Seven transfers, fully documented
- 01
Browser → HASP edge
User enters a chat prompt, uploads a document, or submits an internal-app form. The connection terminates at the global edge network before reaching HASP's origin. The edge sees only request metadata (IP, User-Agent, TLS handshake); no PHI is logged at the edge.
- TLS 1.2+ in transit (TLS 1.3 preferred)
- Edge WAF + rate limiting
- No PHI in edge access logs
- 02
Edge → AI Gateway
The request reaches HASP's application servers and routes through a single AI Gateway service that mediates every AI call. The Gateway authenticates the request (session or API key), confirms the org's BAA status, and looks up the org's PHI-handling policy.
- Authentication and BAA-status check
- Per-org rate-limit enforcement
- Single enforcement point for every AI call
- 03
AI Gateway → PHI handling pipeline
Inbound text — chat turn, uploaded text content, tool definition — flows through HASP's own PHI anonymization pipeline with healthcare-specific custom recognizers. The pipeline returns detected PHI categories and offsets. The Gateway applies the org's configured action (redact / allow / block) before any prompt leaves HASP's substrate.
- HASP-owned pipeline (no third-party gateway in the path)
- Inbound-only — no PHI leaves the substrate without action policy applied
- Detection event written to the audit chain
- 04
AI Gateway → Amazon Bedrock
If the policy allows the prompt to proceed, the Gateway calls the selected model on Amazon Bedrock. HASP runs every language model through Amazon Bedrock under its Business Associate Agreement with Amazon Web Services, so prompts and outputs stay inside the AWS boundary and are never sent to Anthropic or OpenAI. Only the prompt content (post-PHI-policy) and metadata required for inference are sent. The inference provider's retention terms for each model family are published on the sub-processor register. Bedrock model-invocation logging is off.
- Amazon Web Services, Inc. (Amazon Bedrock) is the business associate for inference, under the AWS BAA
- Provider-routing policy configurable per org on Business+ tiers
- Inference in AWS United States and Canada regions
- No training on customer data — HASP policy; prompts and outputs never sent to model authors
- 05
Response → audit chain → storage
The completion streams back through the Gateway. Both the request and the response are written as one (or more) entries in the org's hash-chained audit log, signed with an Ed25519 key bound to the tenant. Conversation history and document content are stored in the org's isolated data plane — row-level isolation by org on Solo, Professional, and Business plans; a dedicated per-org data plane on Enterprise.
- Ed25519 signature on every entry
- Hash chain links each entry to the previous
- RFC 3161 TSA timestamp anchoring at chain checkpoints
- 06
Storage layer
Solo, Professional, and Business orgs run on our HIPAA-eligible compliance substrate with row-level isolation by org. Enterprise orgs run on a dedicated per-org data plane with their own vector index for document RAG and their own object-storage bucket for raw uploads.
- Encryption at rest
- Encryption in transit between application and database
- Per-row encryption for high-sensitivity columns
- Backups encrypted; backup access audited
- 07
Audit access and export
Org admins access the audit chain via the admin UI or programmatically via the audit-export API. Exports are plain JSON plus a verification recipe; auditors verify on their own machine without HASP software in the loop.
- Audit-chain access events logged to the audit chain (recursive — meta-auditing works)
- Export endpoint authenticated and rate-limited
- Public verification recipe at /trust/verify
What gets stored where
Eight data categories, each with its own retention curve and storage location. PHI-eligible categories are covered by the BAA; non-PHI categories aren't, but the audit chain still captures access events.
| Category | Where it lives | Retention | Controls |
|---|---|---|---|
| Chat content (PHI-eligible under BAA) | Org-isolated data plane | Until org-initiated deletion or 30-day offboarding window after cancel | Encryption at rest, per-row encryption on PHI columns, per-org isolation |
| Uploaded documents | Org-isolated data plane + object storage | Until org-initiated deletion or 30-day offboarding window | Encryption at rest, virus-scanned at upload, per-org isolation |
| Document embeddings | Org-isolated vector index | Until source document is deleted | Same per-org isolation as source content; embeddings carry no privileged plaintext |
| Audit-chain entries | Org-isolated audit store (partitioned) | 7 years on every paid tier; custom windows (10+ years) available on Enterprise | Hash-chained, Ed25519-signed, TSA-anchored, immutable |
| PHI detection events | Audit chain (no separate copy) | Same as audit chain (7 years) | One entry per detection: categories, action, user. No raw PHI re-stored. |
| Internal-app static files | Object storage (per-org bucket) | Until app or org is deleted; 100 versions per app on Business; custom (100+) on Enterprise | Per-org routing, authenticated access only, version history audited |
| Account + billing metadata (no PHI) | HASP platform data store + payment processor | 7 years for billing records (legal requirement) | Encryption at rest, tokenized payment data, no raw card storage |
| Edge / access logs (no PHI) | Edge CDN logs | 365 days | Request metadata only; credentials, cookies and query strings are redacted before the log is written |
Need this in your security questionnaire format?
We respond to SIG, CAIQ, HECVAT, and customer-specific questionnaires promptly. The data-flow content above maps directly to the questions those frameworks ask.