File size: 6,190 Bytes
c8cd802 | 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 | # HIPAA / FERPA gap analysis
Honest accounting of the regulatory gaps between the current EmpathRAG
prototype and what a UMD Counseling Center pilot would require. This doc
exists so the gaps are named explicitly rather than hand-waved.
**Bottom line:** EmpathRAG is a research / class prototype and is **not**
HIPAA-compliant, **not** FERPA-compliant for student records, and would
need substantial work to be deployable on UMD infrastructure.
---
## Why we even discuss this
EmpathRAG conversations contain content that is plausibly:
- **Protected health information (PHI)** under HIPAA, when students disclose
mental-health-adjacent symptoms, treatments, or care relationships.
- **Educational records** under FERPA, when students discuss grades,
academic standing, disciplinary history, or advisor relationships.
- **Sensitive personal information** that, even if not technically PHI
or educational records, students reasonably expect to be private.
If UMD CAPS or the CC hosts EmpathRAG and treats it as a pre-intake or
adjunct support tool, the conversations almost certainly become subject
to HIPAA's privacy and security rules.
## Where we fail HIPAA
### Privacy Rule (45 CFR 164.500 et seq.)
| Requirement | Current state | Gap |
|---|---|---|
| Business Associate Agreements (BAAs) with subprocessors | Groq does not sign BAAs for commercial chat completions API; Anthropic API does for some plans but not by default. | **Hard blocker.** No BAA = sending PHI to Groq is itself a violation. |
| Minimum necessary disclosure | Full user messages sent to Groq for paraphrasing; full conversation history sent for context | **Gap.** Could be mitigated by truncation / redaction before send, but only partial. |
| Notice of Privacy Practices | None today; demo has a 1-line scope disclaimer | **Gap.** Required document if deployed; not present. |
| Patient access to records (right to obtain) | Support Plan export is the closest thing; not formally a "designated record set" | **Partial.** Student-facing export exists; structured record-set retention does not. |
| Patient amendment of records | Not supported | **Gap.** |
| Accounting of disclosures | Not logged | **Gap.** |
| Authorization for use beyond TPO (treatment / payment / operations) | No mechanism today | **Gap.** Required for any research / pilot use. |
### Security Rule (45 CFR 164.302 et seq.)
| Requirement | Current state | Gap |
|---|---|---|
| Access control | None — local demo runs on http:// 127.0.0.1 with no auth | **Hard blocker** for deployment. |
| Audit controls | Optional `EMPATHRAG_LOG_TURNS=1` writes raw user text to JSONL | **Gap.** Logs PHI in plain text if enabled. |
| Encryption in transit | Local: http; deployed: depends on reverse proxy | **Gap.** Requires TLS termination + HTTPS-only. |
| Encryption at rest | session_message_history is in-memory; support plan PDF is written unencrypted to OS temp | **Gap.** OS temp dirs are often world-readable on multi-user systems. |
| Workforce training | N/A — no workforce | **N/A.** |
| Incident response | No documented IRP | **Gap.** |
| Backup / contingency | No designed plan | **Gap.** |
### Breach Notification Rule
Not applicable until breach risk exists; once deployed, would need to be addressed.
## Where we fail FERPA
| Requirement | Current state | Gap |
|---|---|---|
| Annual notification of FERPA rights | N/A — not a school yet | **Gap if deployed by UMD.** |
| Records access by parents (under 18) / students | Support plan export exists; no formal records system | **Partial.** |
| Consent before disclosure of education records | No consent flow today | **Gap.** Any disclosure (e.g., to a counselor) needs documented consent. |
| Directory information opt-out | N/A | **N/A.** |
## What it would actually take to close the gaps
### Tier 1: bare minimum for an IRB-light pilot (probably 3-6 months of work)
1. **Custom LLM provider with BAA.** Replace Groq with Azure OpenAI (signs BAA for $$$$), AWS Bedrock (BAA available), or self-hosted Llama 3.3 on UMD-controlled infra. Cost goes from ~$0.0005/turn to ~$0.05-0.10/turn — 100x increase.
2. **TLS-terminated reverse proxy.** Cloudflare in front, https-only.
3. **Auth via terpconnect SSO** so student identity is known and access-controlled.
4. **Server-side session storage with encryption at rest.** Postgres or similar; encrypt user-message columns; access logged.
5. **Explicit consent flow** at the start of every session: scope, data handling, retention, sharing.
6. **Retention policy.** Default delete after N days; student can request earlier deletion.
7. **Audit log** of every access to PHI columns.
8. **IRB-light or full IRB review** depending on whether the pilot generates publishable findings about students.
9. **Notice of Privacy Practices.**
10. **Updated scope disclaimer with HIPAA-specific language.**
### Tier 2: full HIPAA-covered deployment (probably 12+ months and $$$$)
11. All Tier-1, plus:
12. Workforce training records.
13. Documented incident response plan.
14. Disaster recovery / backup plan.
15. Regular security audit / penetration test.
16. Documented data flow / risk assessment.
17. Patient access / amendment / accounting-of-disclosures mechanisms.
18. Sub-BAA chain documented for every dependency that touches PHI.
## What we CAN say today
- The architecture is HIPAA-compatible in design (deterministic planner, no PHI required for routing, all retrieval is from a fixed verified registry, no learned-from-users behavior).
- Crisis intercept never touches the LLM, so PHI in crisis messages never leaves UMD if the LLM provider is the only off-network dependency.
- The Support Plan export is student-controlled — no automatic sharing.
- Server-side persistence is currently zero by design (browser-state only).
These are starting positions, not compliance claims. They make a future
HIPAA-deployed version easier to build; they don't make the current
prototype HIPAA-compliant.
## What we will NOT say
- "EmpathRAG is HIPAA-compliant."
- "Student conversations are private."
- "Your messages stay on your device." (They go to Groq.)
- "This is safe to use for real student support."
|