Skip to main content
You’re putting an LLM in front of protected health information — a triage assistant, a clinical-notes summarizer, a patient-facing chatbot — and you need a defensible posture before it sees real PHI. This page is the checklist for a HIPAA ai deployment on the hosted gateway (api.orcarouter.ai): the controls you can turn on in your workspace today, and the few that stay on your side of the line.
OrcaRouter is not your covered entity, and turning on the HIPAA pack is not “being HIPAA compliant.” The gateway gives you technical safeguards you configure and evidence you can hand an auditor. A signed Business Associate Agreement (BAA), your own infrastructure, workforce training, and physical controls are your organization’s responsibility — the compliance report discloses them as gaps rather than pretending the gateway covers them. See §6.

​
1. What a hipaa ai deployment covers on the gateway

The HIPAA framework pack maps a handful of Security- and Privacy-Rule clauses onto controls the gateway can actually enforce on the relay path — Guardrails for the text and the Firewall for tool egress. Installing the pack materializes those controls as real, editable guardrail and firewall rows in your workspace.
Clause (45 CFR)Gateway control
§164.502(b) Minimum NecessaryRedact PHI in prompts & outputs
§164.514(b) De-identificationHard-block the HIPAA identifiers in requests
§164.312(b) Audit controlsLog every guardrail decision
§164.312(e) Transmission securityDeny tool egress to private / metadata ranges
Everything below is configured from the console (or the REST API) under your workspace session — none of it changes your agent code, and the config routes are role-gated.

​
2. Install the HIPAA pack

Browsing the catalog and checking readiness is open to any Member and free. Installing a pack is a workspace Admin action and requires a paid plan — it’s server-gated either way. 
# Admin · UserAuth session (NOT a relay sk-orca- key)
curl -X POST https://api.orcarouter.ai/api/compliance/packs/hipaa/install \
  -H "Authorization: Bearer <your-console-access-token>" \
  -H "X-Workspace-Id: <workspace-id>"
In one step this materializes the four mapped controls as guardrail and firewall rows you can then open and edit — installed in observe mode, so nothing enforces until you take the pack live. You can do the same from Console → Compliance → HIPAA → Install.
Check GET /api/compliance/readiness before and after install to see which clauses are covered, which are still gaps, and what each one maps to. Readiness is a Member-readable, free endpoint — share it with whoever owns the audit.

​
3. Redact PHI before the model sees it

The pack’s phi_redaction control seeds a guardrail that blocks US healthcare identifiers at the input stage — NPI numbers, ICD-10 codes, NDC drug codes, and DEA registration numbers — using context-anchored regex so a stray ten-digit number doesn’t trip it. Layer a PII Shield on top to mask the general identifiers (email, phone, SSN, IP, and the rest of the built-in entity set) to typed tags like [SSN] before the request leaves the gateway. Prove the rule in the editor’s Test tab before you attach it to a key: 
Input:  "Patient NPI 1234567890, dx ICD-10 J18.9, reply to jane@acme.com"
Verdict: blocked (medical_phi_block) · email → [EMAIL]
Input-stage masking is live; live output/streaming masking is not. PII Shield masks the request before the upstream model ever sees it. On responses, a block action is enforced on both streaming and non-streaming output, but mask on output is currently non-streaming only. If you need PHI scrubbed out of model output over a stream today, block rather than mask, or run non-streaming — and prove your exact stage/stream combination in the sandbox first. See the guardrails reference.

​
4. Deny PHI egress and log every decision

Two of the four HIPAA controls are about what happens after the text is clean:
The pack writes a firewall deny rule on the egress surface with a concrete host/CIDR deny list pre-filled — loopback, link-local / cloud-metadata (169.254.0.0/16), and the RFC1918 / IPv6-ULA private ranges — so a tool can’t quietly ship PHI to an internal endpoint. You don’t have to author the CIDRs; you can widen or tighten the allow/deny lists in firewall rules. Egress enforcement fires on the outbound legs your gateway integration reports as egress, so roll it out under shadow mode first to see what would be denied before it changes traffic.
The pack’s audit control records each guardrail decision into the workspace Matches feed (GET /api/guardrail/match, Member). By default the feed records that a rule fired and its detail string but not the matched substring — the privacy-conservative posture, which is what you want for PHI. Leave Log raw content off unless you have a specific triage need, since turning it on would persist the matched PHI itself.
Firewall decisions land in the workspace Events feed (Developer+) with their verdict and surface, so the action layer and the content layer each leave an independent trail.

​
5. Pin report residency and produce signed evidence

When you generate a compliance report, its data-residency region is a property of the report artifact — us, eu, uk, ap, cn, or global. Set it once (Admin); cross-region reads of a report pinned to a different region are withheld. 
# Admin · set the residency region for compliance reports
curl -X PUT https://api.orcarouter.ai/api/compliance/residency \
  -H "Authorization: Bearer <your-console-access-token>" \
  -H "X-Workspace-Id: <workspace-id>" \
  -H "Content-Type: application/json" \
  -d '{"region": "us"}'
Residency here governs the compliance report artifact, not where your inference data is processed. It is not geo-pinning of PHI through the model — that’s an infrastructure and BAA matter on your side. Don’t present the region toggle to an auditor as data localization.
A generated report is Ed25519-signed and SHA-256-hashed, so an auditor can verify it without trusting your copy:
  • Public key: GET /api/public/compliance/pubkey
  • Verify a report: POST /api/public/compliance/verify
  • Share read-only with an auditor: GET /api/public/compliance/share/:token
Reports export to CSV, JSON, or PDF. Generating and going live with a pack (POST /api/compliance/packs/hipaa/golive) are paid, Admin-gated actions.

​
6. What stays your responsibility

The pack is honest about its limits: the HIPAA checklist includes clauses the gateway cannot enforce, and the report discloses them as open gaps rather than silently marking the framework 100% covered.
Clause (45 CFR)Why it’s yours
§164.308(b)(1) Business Associate AgreementsA BAA is a legal contract between organizations — no gateway setting signs it.
§164.308(a)(5) Security awareness & trainingA people-and-process control, out of scope for relay-path automation.
Beyond those disclosed clauses, your infrastructure is your own: encryption at rest in your systems, access management for your staff, incident response, and the BAA itself. The gateway secures the traffic; you secure the organization.

​
7. Retention and right-to-erasure

Two platform defaults matter for a PHI workload:
  • Request-log retention defaults to 30 days and is server-clamped to a hard maximum of 180 days. Set your per-workspace retention no longer than your minimum-necessary policy requires.
  • Erasure is a self-service account-deletion request followed by a 30-day grace window, after which PII is irreversibly scrubbed and the associated guardrail matches and request logs are purged. Use this to service a data-subject erasure request end to end.
The Matches feed’s default of not logging raw matched content (see §4) keeps the de-identified evidence trail from itself becoming a PHI store. Confirm Log raw content is off on every PHI-facing guardrail.

​
8. Go-live checklist

  • BAA signed with the appropriate party (your responsibility).
  • HIPAA pack installed; readiness shows the four controls covered.
  • medical_phi_block + PII Shield attached to the keys your PHI workload uses, and proven in the Test tab.
  • Egress-deny firewall rule rolled out under shadow mode, then enforced once the Events feed looks right.
  • Log raw content confirmed off on PHI guardrails.
  • Report residency region set; retention set to your minimum-necessary window.
  • Organizational gaps (training, BAA) tracked outside the gateway.

Guardrails reference

PII entities, masking, the Test tab, and the Matches feed in depth.

Firewall reference

Egress rules, shadow mode, and the Events feed.

SOC 2 evidence

The same install → report → verify flow for SOC 2.

PII-safe logging

Keep PHI out of your own logs and the Matches feed.

Stop exfiltration

Author the egress controls behind §164.312(e).

Shared responsibility

Exactly where the gateway’s line ends and yours begins.