|
| 1 | +# HIPAA_REQUIREMENTS.md |
| 2 | + |
| 3 | +This document describes what is required to operate Faxbot in a HIPAA‑aligned manner. It is a technical guide and checklist for engineers and operators. It is not legal advice. Always consult your compliance team and counsel. You (the operator) are responsible for implementing and documenting the controls below and for executing a formal risk analysis and governance program. |
| 4 | + |
| 5 | +## Scope & Data Flows |
| 6 | +- Covered workflows: sending faxes that may contain PHI. |
| 7 | +- Not covered: receiving faxes (non‑goal), messaging, IVR, EHR integrations. |
| 8 | + |
| 9 | +Backends (choose one): |
| 10 | +- Phaxio (cloud): Client → Faxbot API → Phaxio → PSTN/Fax. Phaxio fetches the PDF from your `PUBLIC_API_URL` and posts status callbacks. |
| 11 | +- SIP/Asterisk (self‑hosted): Client → Faxbot API → Asterisk (T.38/UDPTL) → SIP trunk → PSTN/Fax. |
| 12 | + |
| 13 | +PHI touchpoints: |
| 14 | +- PDF/TXT upload to Faxbot API. |
| 15 | +- Stored job artifacts (original, PDF, TIFF for SIP). |
| 16 | +- Status updates (Phaxio callbacks or Asterisk AMI user events). |
| 17 | +- Application/Reverse proxy logs (must be PHI‑free). |
| 18 | + |
| 19 | +## Roles & Agreements |
| 20 | +- If you are a Covered Entity or Business Associate, you must: |
| 21 | + - Execute a BAA with any cloud provider that may handle PHI (e.g., Phaxio). Contact provider sales to obtain a BAA; do not use without a BAA. |
| 22 | + - Treat Faxbot and Asterisk operators as Business Associates if they are separate entities. |
| 23 | +- Self‑hosted SIP stack does not remove HIPAA obligations; it moves them to you. |
| 24 | + |
| 25 | +## Technical Safeguards (Security Rule) |
| 26 | +Implement the following as minimum controls: |
| 27 | + |
| 28 | +1) Transport security |
| 29 | +- Public API must be served over HTTPS. Use TLS certs from a reputable CA. |
| 30 | +- For Phaxio backend: |
| 31 | + - `PUBLIC_API_URL` must be HTTPS in production. |
| 32 | + - Enable callback signature verification (default on): `PHAXIO_VERIFY_SIGNATURE=true`. Server verifies `X-Phaxio-Signature` (HMAC‑SHA256 over raw body with `PHAXIO_API_SECRET`). |
| 33 | +- For SIP backend: |
| 34 | + - SIP signaling should use TLS if supported by your provider; media (T.38 over UDPTL) is typically not encrypted. Mitigate with a site‑to‑site VPN/private interconnect to your SIP provider and strict firewalling. |
| 35 | + - Never expose AMI (5038/tcp) to the public internet. |
| 36 | + |
| 37 | +2) Access control |
| 38 | +- Require API key on all /fax and /fax/{id} calls (`X-API-Key`). Do not run with blank `API_KEY` in production. |
| 39 | +- Restrict inbound traffic with a reverse proxy: IP allowlists and rate limiting. |
| 40 | +- Rotate credentials and set a strong AMI password. Do not use `changeme`. |
| 41 | + |
| 42 | +3) Data minimization & confidentiality |
| 43 | +- Do not log PHI. Ensure request bodies (PDF/TXT) and rendered content are never logged. |
| 44 | +- Faxbot redacts tokenized PDF URLs from logs. |
| 45 | +- Tokenized PDF access: |
| 46 | + - The server issues a per‑job, random `pdf_token` with a short TTL (`PDF_TOKEN_TTL_MINUTES`, default 60). The `/fax/{job_id}/pdf` endpoint requires exact token equality and enforces expiry. |
| 47 | + - Keep TTL as short as operationally feasible. |
| 48 | + |
| 49 | +4) Storage security (at rest) |
| 50 | +- Store database and artifacts on encrypted volumes or use a managed, encrypted database. SQLite is acceptable only if disk encryption and backups are in place. |
| 51 | +- Separate storage for development vs production. Limit admin access and use MFA on hosts. |
| 52 | +- Data retention policy: delete PDFs/TIFFs after transmission completes and your minimum retention requirement is satisfied. |
| 53 | + |
| 54 | +5) Integrity & auditing |
| 55 | +- Maintain audit logs of access to `/fax/{job_id}/pdf`, job creation, and status changes. No PHI in logs; use job IDs and metadata only. |
| 56 | +- Time synchronize servers (NTP) for accurate audit trails. |
| 57 | + |
| 58 | +6) Availability & recovery |
| 59 | +- Back up database (and optionally artifacts) on a secure, encrypted target with rotation. |
| 60 | +- Document restore procedures and test periodically. |
| 61 | + |
| 62 | +## Administrative Safeguards |
| 63 | +- Perform and document a HIPAA risk analysis for this system, covering threats to confidentiality, integrity, and availability. |
| 64 | +- Draft and adopt policies: access control, incident response, change management, data retention/secure destruction, vulnerability management. |
| 65 | +- Train workforce members on PHI handling and minimum necessary principles. |
| 66 | +- Maintain vendor due diligence (e.g., Phaxio BAA, SOC2 reports where applicable). |
| 67 | + |
| 68 | +## Physical Safeguards |
| 69 | +- Secure data center/hosting environment. For on‑prem: locked server rooms, visitor controls. For cloud: select providers with appropriate attestations. |
| 70 | + |
| 71 | +## Backend‑Specific Guidance |
| 72 | + |
| 73 | +### Phaxio (Cloud) |
| 74 | +- Required: |
| 75 | + - BAA with Phaxio before sending PHI. |
| 76 | + - HTTPS `PUBLIC_API_URL`, valid certificate. |
| 77 | + - `PHAXIO_VERIFY_SIGNATURE=true`. |
| 78 | + - Strong `API_KEY` and reverse proxy restrictions. |
| 79 | +- Recommended: |
| 80 | + - Keep `PDF_TOKEN_TTL_MINUTES` small (e.g., 15–60 minutes). |
| 81 | + - Immediately delete PDFs after successful transmission unless retention policy requires otherwise. |
| 82 | + - Validate that `PHAXIO_STATUS_CALLBACK_URL` is reachable only over TLS. |
| 83 | + |
| 84 | +### SIP/Asterisk (Self‑Hosted) |
| 85 | +- T.38/UDPTL is not encrypted. Mitigations: |
| 86 | + - Use a site‑to‑site VPN/private interconnect to your SIP provider, or run Asterisk in a private data center with dedicated connectivity. |
| 87 | + - Strict firewall allows only necessary ports and only to/from provider IPs. |
| 88 | + - Use SIP TLS for signaling if supported by your provider; still keep media protected by VPN. |
| 89 | +- Asterisk hardening: |
| 90 | + - Do not expose AMI externally. Bind to private networks only. |
| 91 | + - Use non‑default usernames, strong secrets, fail2ban/IDS. |
| 92 | + - Rotate credentials periodically. Log and alert on failed auth. |
| 93 | + |
| 94 | +## MCP (AI Assistant) Considerations |
| 95 | +- MCP transmits base64 file content for the `send_fax` tool. Treat the MCP server with the same controls as the API (auth, network restrictions, audit logging). |
| 96 | +- Do not send PHI to LLMs or external services unless you have a signed BAA and an approved use case. |
| 97 | +- Keep MCP HTTP behind authentication and rate limiting. |
| 98 | + |
| 99 | +## Operational Checklist (Minimum) |
| 100 | +- [ ] Signed BAA with Phaxio (if using cloud backend). |
| 101 | +- [ ] TLS everywhere (HTTPS for public endpoints; VPN/private link for SIP media). |
| 102 | +- [ ] API auth enabled (`API_KEY` set). Reverse proxy with IP allowlist + rate limiting. |
| 103 | +- [ ] Callback signature verification enabled (`PHAXIO_VERIFY_SIGNATURE=true`). |
| 104 | +- [ ] Tokenized PDF access enabled with short TTL (`PDF_TOKEN_TTL_MINUTES`). |
| 105 | +- [ ] Logs do not contain PHI; tokens redacted; job IDs only. |
| 106 | +- [ ] Encrypted storage for DB and artifacts; backups configured. |
| 107 | +- [ ] Data retention policy implemented (delete artifacts after N days or on success). |
| 108 | +- [ ] Asterisk AMI not exposed; strong credentials; fail2ban. |
| 109 | +- [ ] Risk analysis, policies, and training documented. |
| 110 | + |
| 111 | +## Current Implementation Status (2025‑Q3) |
| 112 | +- Implemented: |
| 113 | + - API key support, reverse proxy guidance. |
| 114 | + - Tokenized PDF access with equality check and TTL expiry. |
| 115 | + - Phaxio callback signature verification (HMAC‑SHA256). |
| 116 | + - AMI concurrency/backoff improvements; SIP dialplan emits granular results. |
| 117 | + - Docs for HTTPS, rate limiting, NAT/port‑forwarding. |
| 118 | +- Gaps (operator‑dependent): |
| 119 | + - Encryption at rest (volume or DB) is operator‑managed. |
| 120 | + - Automated retention cleanup (cron/job) recommended (see below). |
| 121 | + - Centralized audit logging & alerting recommended. |
| 122 | + |
| 123 | +## Remediation Plan & Roadmap |
| 124 | +1) Automate artifact retention |
| 125 | +- Add `ARTIFACT_TTL_DAYS` env with a daily cleanup job to purge PDFs/TIFFs older than TTL when job status is final. |
| 126 | + |
| 127 | +2) Configurable audit logging |
| 128 | +- Structured logs with job lifecycle events; optional sink to SIEM. |
| 129 | + |
| 130 | +3) Optional hard fail on plain HTTP |
| 131 | +- Reject `PUBLIC_API_URL` with `http://` in non‑local environments unless `ALLOW_INSECURE_PUBLIC_URL=true`. |
| 132 | + |
| 133 | +4) Secrets management |
| 134 | +- Guidance and examples for loading secrets from a vault (AWS/GCP/Azure) instead of env files. |
| 135 | + |
| 136 | +5) Provider‑specific SIP hardening |
| 137 | +- Example configs for TLS signaling and site‑to‑site VPN topologies. |
| 138 | + |
| 139 | +## Example: Retention Cleanup (Operator) |
| 140 | +- Create a cron or systemd timer to delete artifacts after N days: |
| 141 | +``` |
| 142 | +# delete PDFs/TIFFs older than 7 days |
| 143 | +find /path/to/faxdata -type f \( -name '*.pdf' -o -name '*.tiff' \) -mtime +7 -delete |
| 144 | +``` |
| 145 | +- Ensure backups honor retention and secure destruction policies. |
| 146 | + |
| 147 | +## Legal Notice |
| 148 | +- This document does not constitute legal advice. HIPAA compliance depends on your specific implementation, vendor agreements, and organizational controls. Engage qualified counsel and security professionals. |
0 commit comments