TL;DR: "HIPAA-compliant AI" is not a checkbox you tick or a badge a vendor prints on a landing page. It is a specific set of contractual, technical, and operational controls: a signed Business Associate Agreement with every tool that touches protected health information (PHI) and with the underlying model providers, contractual zero-training-use of your inputs, encryption in transit and at rest, granular access controls with audit logging, and a data-ingestion pipeline where scored files from Q-global, PARiConnect, or WPS are read inside your covered environment rather than pasted into a public chatbot. This guide walks through each piece in plain language so you can run real due diligence before you trust a tool with a client's file.
Not legal advice — HIPAA obligations depend on your role, jurisdiction, and facts; confirm with qualified counsel and your compliance officer before making compliance decisions for your practice.
If you have read our companion pieces on why everyone is scared of AI report writing and the real risks of using Claude & ChatGPT for reports (liability), you already know the two big fears: clinical inaccuracy and privacy exposure. This article is about the second one. HIPAA compliant report writing is achievable, but only when you understand what the acronyms actually demand.
1. Covered Entity vs. Business Associate: Know Your Role First
Before you can evaluate any ai-powered mental health assessment tool, you have to locate yourself in the HIPAA structure, because your obligations flow from your role.
Most psychologists in independent or group practice are covered entities — you provide health care and transmit health information electronically for billing or similar transactions. A school district psychologist may sit in a more complicated position (FERPA often governs educational records), which is exactly the kind of fact you confirm with counsel.
Any outside vendor that creates, receives, maintains, or transmits PHI on your behalf is a business associate. An AI report-writing platform that ingests a scored WISC-V PDF is a business associate. So is the cloud host it runs on, and — critically — so is any large language model provider whose API processes that PHI downstream. This is the chain most clinicians miss.
The subprocessor chain
When a platform sends your client's data to a third-party model API to generate text, that model provider is a subprocessor, and it is also handling PHI. A BAA for AI tools is only meaningful if it flows down the chain: the vendor signs a BAA with you, and the vendor has a signed BAA with its model provider that covers your data. If a tool cannot show you that the model layer is under a BAA, then your PHI is being processed by an entity with no HIPAA obligation to you. That is the single most common gap in "HIPAA-compliant AI" claims.
2. The BAA: Why It Is Non-Negotiable and What It Must Cover
A Business Associate Agreement is the contract that legally binds a vendor to safeguard PHI, limit its use, report breaches, and return or destroy data when the relationship ends. Without one, you cannot lawfully share PHI with that vendor, full stop. HHS publishes sample BAA provisions (linked in the References) that show the required elements.
A credible BAA for an assessment-writing platform should, at minimum:
A vendor that hesitates to sign a BAA, or offers one that excludes the AI/model layer, has answered your due-diligence question for you.
3. Data Retention and Zero-Training-Use: Where PHI Actually Goes
This is where marketing language and reality diverge most.
"We don't train on your data" needs to be in writing
The difference between a consumer chatbot and a clinical tool is retention and training policy. Consumer LLM products have historically retained inputs and, under some settings, used them to improve models. For assessment work you need the opposite: a contractual, zero-training-use guarantee that your inputs are never added to any training corpus, and a defined, minimal retention window after which PHI is deleted. "We don't train on your data" in a blog post is not the same as that promise living in your BAA.
Retention should be minimal and configurable
Ask two concrete questions: How long is my client's data stored? and Can I delete it on demand and export it if I leave? The HIPAA minimum-necessary principle argues for the shortest viable retention. A mature vendor gives you deletion controls and a clean export path — data portability is both a compliance feature and a lock-in safeguard.
4. Score Ingestion Done Right: The Q-global / PAR / WPS Reality
Here is the honest, technical part that most "integration" marketing glosses over. The core of psychological assessment data integration is getting scored results out of your testing platform and into your report tool without leaking PHI to systems that have no business touching it.
Most test publishers do not offer open APIs
Clinicians often ask for the "best integration providers for assessment integrations," imagining a tidy API handshake between their scoring platform and their report writer. The reality: major publishers — Pearson's Q-global, PAR's PARiConnect, and WPS — largely do not expose open, developer-friendly APIs for pulling scored data. That is a business and security decision on their end, and it is unlikely to change soon.
So the realistic, secure path is structured ingestion of exported scored files. You export the scored PDF or CSV from Q-global or PARiConnect, and the report platform parses that file inside your covered environment — extracting index scores, subtest scaled scores, and confidence intervals into structured fields. The key requirements:
This is why a platform's HIPAA-compliant integrations page should describe file-based structured ingestion, not overpromise nonexistent live API links to the big publishers. Honesty here is a maturity signal.
Webhooks and metadata APIs for downstream systems
Where APIs do exist is usually downstream — practice-management systems, EHRs, or storage. A hipaa-compliant webhook ingestion tool can move report metadata and status events (not raw PHI) between your systems, or push a finished, encrypted document to your record store. Webhooks and APIs are safe when they run over TLS, authenticate every call, carry the minimum necessary data, and terminate only at endpoints that are themselves under a BAA. A webhook firing PHI to an unbound third-party automation service is a breach waiting to happen.
5. The Security Rule in Practice: Encryption, Access, and Audit Logs
The HIPAA Security Rule (see References) requires administrative, physical, and technical safeguards. For an AI assessment tool, four technical controls matter most, and you should be able to verify each.
Encryption in transit and at rest
PHI should be encrypted in transit (modern TLS) and at rest (strong encryption on stored files and databases). This is table stakes; a vendor that cannot describe its encryption posture in a sentence is not ready for your data.
Access controls and role-based permissions
Who at the vendor can see your client's file? The answer should be "almost no one, and only under logged, justified conditions." Look for role-based access control, enforced authentication (MFA for staff), and the principle of least privilege.
Audit logging
Audit logs record who accessed what and when. They are both a Security Rule expectation and your forensic lifeline if something goes wrong. You should be able to see access and activity history for your own data.
Breach notification
Your vendor must detect and report breaches to you on a defined timeline so you can meet your own notification obligations. This belongs in the BAA and should be backed by a real incident-response process. Much of this overlaps with the broader compliance-first buyer checklist for psychoed platforms, which is worth reading alongside this piece.
6. What "De-Identified" Does and Doesn't Buy You
The most common workaround clinicians reach for is: "I'll just strip the name and date of birth, then it's fine to paste into any AI." Be careful.
De-identification is a high bar
True HIPAA de-identification is a formal standard — either expert determination or the Safe Harbor removal of eighteen specific identifier types. Deleting a name and DOB does not meet it. A rich clinical narrative, an unusual score constellation, a rare diagnosis, plus contextual details can re-identify a person even without a name. Assessment reports are dense with exactly this kind of re-identifying detail.
De-identification does not fix the vendor relationship
Even if data were genuinely de-identified, that does not automatically make a consumer tool appropriate for clinical work — you still lose traceability, and you are relying on your own manual scrubbing being perfect every time, on every file, forever. The safer architecture is not "de-identify then use an unsafe tool"; it is "use a tool that is contractually safe with identified PHI." That is the entire point of a BAA and a covered environment. Our trust & security page lays out how that model works in practice.
Vendor Due-Diligence Checklist
Before you send a single client's data to any AI report tool, get a clear yes on every line. Treat a "no" or a dodge as disqualifying.
Run this list against any tool that claims hipaa compliant ai for psychological reports. The good vendors will welcome the questions; they built for exactly this scrutiny. As always, this is clinical-risk framing to structure your evaluation — it is not legal advice, and your compliance officer and counsel have the final word on your specific situation.