Why private LLM chat for healthcare starts with PHI, not features
Clinicians and compliance leads need one decision before any feature comparison: whether prompts containing ePHI may reach a third-party model service at all. Staff already paste visit notes, discharge summaries and drug questions into public tools, so the organization is either governing that behavior or ignoring it. A self-hosted assistant answers the question by design, because Open WebUI or LibreChat running on Ollama or vLLM can keep prompts, files and model inference on infrastructure the organization controls. The interface choice matters less than where the model runs and who can reach the logs.
HIPAA obligations do not disappear because the model is local. The Security Rule applies to covered entities and business associates for all ePHI they create, receive, maintain or transmit (45 CFR 164.302), so any hosting party, managed service provider or support engineer who can read chat history falls inside that scope. Chat transcripts, uploaded documents and retrieval indexes are all ePHI stores that need access control, audit logging and retention settings. Confirm with counsel whether any vendor touching the stack will sign a business associate agreement under 45 CFR 164.314(a)(2)(i), and map every component to a role before the first pilot user logs in.
HIPAA has no certification, so there is no badge to show a buyer, auditor or OCR investigator. The evidence is the documented risk analysis, the controls it selects, and proof that those controls operate, such as SSO group mappings, audit log samples and retention configurations. Plan the risk analysis as the first deliverable of the project, not the last, because the answers determine the architecture: which models run locally, which identities can see which chats, and what gets deleted and when.
Which HIPAA Security Rule requirements shape the chat build
This table maps the HIPAA Security Rule technical and administrative standards, plus the business associate contract rule, to decisions a build team makes for a chat assistant. The technical implementation specifications in 45 CFR 164.312 number 7, with 2 required and 5 addressable, and they set the baseline for identity, sessions, encryption and audit. Treat each row as a design input, then confirm the evidence with your compliance lead and counsel.
| Requirement | Build decision | Evidence an assessor expects |
|---|---|---|
| Unique user identification, 164.312(a)(2)(i), required | Sign in through SSO using OIDC or LDAP, with no shared chat accounts and SCIM deprovisioning when staff leave | Identity provider configuration, and a user roster reconciled to HR records |
| Emergency access procedure, 164.312(a)(2)(ii), required | Keep a sealed break-glass administrator account and a written procedure to reach chat history and model services during an outage | Documented procedure, plus a dated record of at least one test |
| Automatic logoff, 164.312(a)(2)(iii), addressable | Set an idle session timeout in the reverse proxy and the chat application, shorter for shared clinical workstations | Configured timeout values and a test showing an idle session ends |
| Encryption and decryption, 164.312(a)(2)(iv), addressable | Encrypt the chat database, uploaded files and knowledge stores at rest, with keys held outside the application host | Storage encryption settings and a key custody record |
| Transmission security, 164.312(e)(1), addressable specifications | Use TLS from browser to proxy and between the chat application and inference endpoints, and keep Ollama or vLLM bound to internal addresses | Network diagram, TLS configuration and a scan showing no plaintext listeners |
| Audit controls, 164.312(b), standard | Log logins, admin changes, file access and chat activity by policy, and set log retention and access rules before go-live | Sample log entries, retention settings and the list of staff who can read logs |
| Person or entity authentication, 164.312(d), standard | Require authenticator-app MFA for every account, and restrict who can change model and configuration files | MFA enforcement report and change records for model and config files |
| Access management, 164.308(a)(4) | Map chat roles to clinical groups with least privilege, and limit which groups may upload patient documents | Group-to-role matrix and periodic access review records |
| Business associate contract, 164.314(a) | Obtain a signed business associate agreement from any hosting, support or managed service party that can reach ePHI, with flow-down to subcontractors and incident reporting terms | Executed agreements, subcontractor list and confirmed incident notification timelines |
Which open-source chat stack fits a clinical environment
Open WebUI is the most feature-complete option in this group for a clinical chat service, and its identity features map well to how hospitals manage staff. It is distributed under the Open WebUI License, which is BSD-style but adds a branding clause. That clause prohibits altering or removing Open WebUI branding in deployments above 50 end users in any rolling 30-day period unless the operator holds an enterprise license or written permission. A hospital-wide rollout will exceed that threshold, so the license question belongs in procurement, not after go-live.
- Identity integration: Documented support for SSO through OIDC and LDAP, SCIM 2.0 provisioning of users and groups, and role-based access control with groups and per-resource permissions, which lets access follow clinical roles.
- Authenticator-app MFA: Built-in multi-factor authentication for local accounts, to be reviewed against the access controls your risk analysis requires.
- Retrieval options: Support for 13 vector databases, including PGVector, Qdrant, Milvus and Elasticsearch, so clinical document stores can stay on your own infrastructure.
- Enterprise terms: Enterprise licenses allow white-labeling, and pricing is quoted by Open WebUI enterprise sales from an expected seat count.
Confirm with the vendor whether the audit logging, chat retention settings and export options meet your retention schedule and access review needs, because these are not settled by the feature list alone.
LibreChat is an AI chat interface licensed under MIT. For organizations whose procurement or legal teams prefer permissive terms without a branding restriction tied to user count, it is the alternative to evaluate first. It connects to model endpoints and supports multiple providers, so it can sit in front of a local Ollama or vLLM endpoint as easily as in front of an external API. The trade-off is that the identity, audit and administration features you need must be checked against your requirements rather than assumed from the license.
- License fit: MIT terms carry no user-count branding clause, which simplifies rollout to thousands of staff without an enterprise license negotiation.
- Model endpoint control: Point the interface only at internal endpoints, and disable any external provider you do not approve for clinical use.
- Identity features: Confirm which SSO protocols, group mapping and provisioning methods your version supports, and how removed staff lose access.
- Upgrade cadence: The latest tagged version is v0.8.8, so plan a tested upgrade path and a change record for each release.
Before choosing, have the security team test LibreChat's audit trail, message deletion behavior and export options against your HIPAA risk analysis and records policy.
Ollama runs open-weight models locally, written in Go with a llama.cpp backend and licensed under MIT. It binds to 127.0.0.1 on port 11434 by default and its local API does not require authentication, so it must sit behind an authenticated proxy before any clinical user reaches it. Its concurrency defaults are conservative, which suits a supervised pilot on a small number of workstations or a single server. They are a poor fit for a hospital-wide service without tuning and capacity testing.
- Default concurrency: OLLAMA_NUM_PARALLEL defaults to 1 parallel request per model, OLLAMA_MAX_LOADED_MODELS defaults to 3 times the number of GPUs (or 3 on CPU) and OLLAMA_MAX_QUEUE defaults to 512 queued requests.
- Pilot fit: A small clinical pilot with a limited user group and predictable use can run on these defaults while you measure response times.
- Network exposure: Changing OLLAMA_HOST exposes the API, so pair it with TLS and access control at a reverse proxy.
- Cloud features: Set OLLAMA_NO_CLOUD=1 or the equivalent server configuration so no request leaves the environment.
Confirm that Ollama's logging behavior and the host's logs meet your audit requirements, since the runtime does not replace the chat layer's own audit trail.
vLLM is an inference and serving engine licensed under Apache-2.0, and it is designed for serving models to many concurrent users from shared GPUs. For a hospital-wide assistant used across clinical units, it is the layer to evaluate for capacity, because it exposes an OpenAI-compatible endpoint that the chat interface can call. Its benefit is throughput under load, but it needs GPU sizing, monitoring and a patch process that a clinical IT team must own or contract.
- Shared serving: One endpoint serves many staff and applications, with capacity set by GPU count and model size rather than per-user installs.
- Sizing work: Load-test with realistic clinical prompt lengths and concurrency before committing hardware, and document the results for change control.
- Interface pairing: Open WebUI or LibreChat connect to the vLLM endpoint, and the endpoint itself should require authentication and stay on an internal network segment.
- Operations: Plan monitoring, version pinning and model update testing, because a model change alters clinical output and should follow your validation process.
Confirm with your platform and security teams how request and response logging is configured on the serving layer, and where those logs are retained, because they may contain patient data.
Platforms that fit a healthcare chat deployment and why
A healthcare chat deployment is a chain: an interface, a model runtime, a gateway that controls and logs requests, and an observability layer that keeps the audit trail. Each platform below covers one link in that chain, and each carries a licensing or access condition that a compliance and procurement review should check before it is placed in the PHI path.
Open WebUI as the staff interface
Open WebUI gives clinicians a ChatGPT-style front end that connects to Ollama or other OpenAI-compatible providers, with SSO through OIDC or LDAP, SCIM 2.0 provisioning and role-based access by group. For PHI use, confirm that the chosen role model maps to care team membership, not just department. Check the branding clause: deployments above 50 users in any rolling 30-day period may not alter or remove branding without an enterprise license or written permission, so get that decision in writing before rollout.
LibreChat as the alternative interface
LibreChat is an MIT-licensed chat interface that some teams evaluate as an alternative to Open WebUI, especially where its multi-provider configuration or license terms fit procurement better. Compare the two on the controls that matter for PHI: how each integrates with your identity provider, how it scopes conversations per user, and what it writes to logs by default. Whichever interface you choose, the chat history it stores is ePHI and needs the same access and retention controls as the medical record it may quote.
Ollama as the local model runtime
Ollama runs open-weight models on your own hardware under the MIT license, and its local API listens on 127.0.0.1 port 11434 by default. That local endpoint has no authentication, so binding it to a wider interface without a controlled proxy in front exposes PHI-bearing prompts to any host that can reach it. Place it behind a reverse proxy that enforces authentication and network policy, disable cloud features with OLLAMA_NO_CLOUD=1, and confirm that no cloud API key path is in use for patient data.
vLLM for shared inference
vLLM is an Apache-2.0 serving engine that suits a shared internal model service when many clinicians call the same model at once. It exposes an OpenAI-compatible endpoint, which lets the chat interface and gateway stay the same if the runtime changes. Ask any implementation partner how it sizes GPUs for your peak concurrency, how it authenticates requests, and how it pins model versions, because model upgrades change output behavior and must go through the same change control as other clinical software. The current release supplied for this review is v0.31.0.
LiteLLM for gateway logging and guardrails
LiteLLM sits between applications and model endpoints and provides routing, keys, cost tracking, guardrails and request logging. In a healthcare deployment it is the point where you can enforce which users and applications may send which data, and where request metadata is recorded. Its MIT license covers the core, but the enterprise directory uses a separate license, so confirm which features you need fall outside it. Confirm also what the gateway logs by default, because full prompt bodies in gateway logs create a second copy of ePHI.
Langfuse for prompt and output audit trails
Langfuse is a self-hosted observability platform that records traces of prompts, outputs, latency and cost, so a compliance team can reconstruct what a clinician asked and what the model returned. The core is MIT licensed, but its ee directories are excluded, so confirm the features you plan to use. Because traces contain ePHI, treat the Langfuse database as a regulated system with its own access controls, encryption, and retention schedule. Note that Arize Phoenix uses the Elastic License 2.0, which prohibits offering it to third parties as a hosted or managed service, and that Dify's modified Apache license may require a commercial license to run a multi-tenant service; both affect any managed-service model you consider.
How retention, audit logging and access control work together
Treat every store in the assistant as ePHI. Chat history, uploaded files, knowledge collections and gateway or observability logs can all contain patient details pasted by a clinician, so each needs access control, encryption and a written retention period. In an Open WebUI deployment that means the PostgreSQL database holding chats and user records, the shared file storage used across replicas, any vector database built from uploaded documents, and the request logs kept by a gateway such as LiteLLM or a tracing tool. Confirm with the security officer which of these stores exist in the chosen design, who can read each one, and how long each keeps data. Deleting a chat in the interface removes it from the user's view, but it does not automatically purge backups, replicas or logs, so the retention policy must name each of those copies and their schedules separately.
Audit logging answers who accessed which chat, file or patient-related record, and when. Configure the assistant so that administrative actions, role and group changes, file uploads and access to shared knowledge are recorded, and send those records to storage the security team controls. Role scoping by care team turns the same records into a need-to-know control: a ward group should reach only the knowledge and model access its role requires, and group membership should come from the identity provider through SSO and SCIM rather than manual edits. A useful cautionary case is the CNIL's September 2026 fine of EUR 500,000 against a French hospital, which cited external access to its patient record system without VPN or multi-factor authentication and an access model that ignored the care team's need to know. The same gaps apply to a chat assistant reachable from outside the network. Also confirm with counsel whether the assistant is a high-risk AI system, because the record-keeping duties in Articles 12 and 19 of the EU AI Act apply only in that case.
How a healthcare chat rollout moves from risk analysis to production
This sequence takes a healthcare organization from deciding what staff may paste into a chat assistant to a supervised production service with a documented change routine. Each phase closes with a named artifact that a privacy, security or compliance lead can review before the next phase starts.
Scope use cases and classify pasted data
The organization, with its privacy officer, clinical leads and the security team, lists the staff roles and tasks the assistant will support and sorts the data types staff might paste or upload, such as de-identified text, PHI, free-text notes and documents. Each category gets a written rule for what is allowed. The output is a signed scope statement and a data classification table that the rest of the rollout is tested against.
Complete the HIPAA risk analysis
The security team runs the risk analysis required under the Security Rule's administrative safeguards, mapping every place ePHI can enter, sit or leave the chat stack: the browser, the interface database, uploaded files, vector stores, model server logs, backups and admin consoles. NIST SP 800-66 Rev. 2 is a practical reference for structuring the analysis and linking each risk to a control. The output is a risk register with owners and a risk treatment decision for each item. The proposed revision to the Security Rule was published as a proposal on 6 January 2025, and no final rule had been published as of October 2026, so the analysis should be written against the current rule and reviewed if the final text changes.
Design and harden the architecture
The implementation partner builds the reference design inside the organization's own environment: a self-hosted interface, local model serving with Ollama or vLLM bound to internal addresses only, PostgreSQL as the shared database, and encrypted storage for files and backups. Cloud features in model runtimes are turned off where the design calls for it, and the team confirms that prompts are not sent to any external API. Access paths, logging destinations and encryption settings are documented against the technical safeguard specifications. The output is an architecture decision record and a hardened build with a configuration baseline.
Run a pilot with a small clinical group
A small group of clinicians and staff, chosen with clinical leadership, uses the assistant on the approved data categories only. The team checks login with the identity provider, group-based access, audit log content, retention behavior and the staff's understanding of the pasting rules, and records incidents, including any attempt to paste data outside the rule. Pilot findings feed back into the risk register and the configuration baseline. The output is a pilot report that states which controls worked, which failed and what changed before expansion.
Move to production in SSO group waves
Access expands in waves defined by identity groups, with each wave tied to a clinical or administrative unit and a named owner. Before each wave, the team checks role mappings, deprovisioning of leavers, business associate terms for any hosting or support party that can reach the environment, and the measurements defined during the pilot. The output is a wave record for each group and a production sign-off that confirms the risk register items are either closed or accepted by an owner.
Test model and interface updates before release
Model weights, Open WebUI and Ollama or vLLM releases arrive often, so every update goes to a staging copy with the same configuration, identity links and sample test prompts. The team compares responses and access behavior against the baseline, reviews release notes for security changes and confirms that logging still works before promoting the change. Rollback steps are tested as part of the same cycle. The output is a change record for each update that the security owner approves before production.
Operate with monitoring and change control
Operations staff monitor authentication failures, administrative actions, log integrity, storage and service health, and review audit records on a schedule the organization sets. Changes to the model list, access groups, retention settings and branding are routed through the change process, and the risk register is reviewed when the scope changes or when regulatory text is finalized. The output is a recurring evidence pack with access reviews, change records and monitoring reports that the compliance team can present during an internal review or an outside assessment.
Evidence a HIPAA risk analysis and auditors will ask for
This table lists the evidence a covered entity or business associate should be able to produce for a self-hosted healthcare chat assistant, the component that generates each item, and where teams usually fall short. HHS does not certify HIPAA compliance, and the HHS Office for Civil Rights enforces the Security Rule through complaints, compliance reviews and audits, so the evidence set is what an assessor will actually examine. Use the rows as a checklist for the risk analysis and the pre-rollout review.
| Evidence item | Produced by | Where it usually falls short |
|---|---|---|
| Risk analysis record covering prompts, uploads, chat history and vector stores | Risk management team with the security officer, documented in the organization's own tooling | Scope omits uploaded files, model caches, backups or admin consoles |
| Access control matrix mapping SSO groups to chat, model and knowledge permissions | Identity provider group definitions plus Open WebUI role and group settings | Groups are inherited from the directory without review, so former staff keep access |
| Unique user identification configuration | Identity provider user IDs passed through OIDC or LDAP into Open WebUI accounts | Shared clinic logins or generic service accounts used for daily chat |
| Automatic logoff and session timeout settings | Open WebUI session configuration and the reverse proxy or load balancer settings | Timeouts set only in the browser, or not documented for shared workstations |
| Encryption configuration for data in transit and at rest | TLS termination at the proxy, database and file storage encryption settings, key management records | Ollama or vLLM endpoints reachable over plain HTTP inside the network, or volumes unencrypted |
| Audit log samples showing logins, admin changes, model use and file access | Open WebUI logs, gateway or Langfuse logs, forwarded to the organization's log store | Logs record prompts without access controls, or no one reviews them and retention is undefined |
| Retention schedule for chats, uploads, embeddings and logs | Open WebUI retention settings, storage lifecycle policies and the backup system | Backups keep deleted patient content for longer than the schedule states |
| Business associate agreements for every party that can access ePHI | Legal and procurement records for hosting, cloud, backup and support providers | Support engineers or cloud providers with ePHI access but no signed agreement on file |
| Incident response runbook and contact path to the covered entity | Security team runbook, tested through a tabletop exercise with the business associate | Runbook does not cover misdirected prompts or breach notification timing |
What healthcare buyers ask before a private chat rollout
What drives the cost of a private LLM chat for a hospital?
The cost splits into GPU servers or cloud GPUs for inference, the chat interface and any enterprise license, integration and security work, and ongoing operations. Hardware and cloud GPU charges recur, while design, integration with identity and logging, and security testing are mostly one-time engagement costs. Model size, expected concurrency and the number of clinical workflows you connect move the total the most. Ask any partner for a quote built from a written scope that lists each of these components separately, including who pays for GPUs and who operates them after go-live. Ollama's published pricing covers its cloud plans only, and running models on your own hardware is listed there as unlimited, so confirm the actual hardware budget with your own environment.
Can our internal IT team run a private chat rollout on its own?
Often yes for a small pilot, but a clinical rollout usually needs skills across several areas at once: model serving, identity integration, database and storage design, logging, and security testing. Most teams can deploy Open WebUI with Docker Compose for a limited trial, but multi-instance use requires PostgreSQL, Redis and shared file storage, which changes the operating model. Assess your team against each area and decide which parts to keep in house and which to scope with a partner. DeployOpen plans, implements, hardens and supports self-hosted platforms in your own infrastructure under fixed-scope agreements, and the division of work should be written down before any build starts.
How long does a pilot take, and what sets the timeline?
The timeline depends on the scope you agree, not on a standard duration. The main variables are the number of user groups and identity integrations, whether documents will be uploaded, the GPU capacity you already own or must procure, and how much of the HIPAA risk analysis is done before a go-live date is set. Procurement lead times for GPU hardware are often the longest item, so confirm them early. Ask for a written plan with phases, acceptance criteria for the pilot, and the evidence each phase produces. Any duration you are quoted should appear in the signed scope rather than in a sales conversation.
Do we need a business associate agreement with a private chat partner?
Yes, when a party that touches electronic protected health information is a business associate, a written business associate contract is required under 45 CFR 164.314(a)(2)(i). That contract must require the business associate to comply with the Security Rule, flow the same terms to subcontractors that handle ePHI, and report security incidents, including breaches of unsecured PHI. Whether an implementation partner, a hosting provider or a managed service becomes a business associate depends on whether it creates, receives, maintains or transmits ePHI in its role. Have counsel map each party in the architecture before you sign. Keeping models and logs on your own infrastructure reduces the number of parties that touch ePHI, but it does not remove the analysis.
Is there a HIPAA certification for a private chat platform?
No. HHS states that no Security Rule standard requires an entity to certify compliance, and private certifications do not prevent HHS from later finding a violation, according to HHS FAQ 2003. The HHS Office for Civil Rights enforces the rule through complaints, compliance reviews and audits. Vendors may market certifications or attestations, but you should read what they cover and who issued them. HITRUST offers a voluntary assessment framework, and its certifications are issued by an independent assessor rather than by DeployOpen, which prepares controls and evidence but does not issue attestations or certifications. Your evidence for a HIPAA risk analysis is your own documented analysis and controls.
What does the Open WebUI branding license mean for a hospital?
The Open WebUI License prohibits altering or removing Open WebUI branding in deployments with more than 50 end users in any rolling 30-day period, unless you hold an enterprise license or written contributor permission. A hospital with a clinical workforce will usually exceed that threshold, so plan for the branding clause before rollout rather than after. Enterprise licenses allow white-labeling and custom branding, and pricing is quoted by Open WebUI after you contact its sales team with an expected seat count. Alternatives such as LibreChat, licensed under MIT, carry different terms. Have legal review the license text and your chosen version, since releases after v0.6.6 fall under this license.
How does penalty exposure change the priority of a private chat project?
For penalties assessed on or after 28 January 2026, the inflation-adjusted HIPAA civil money penalty ranges from $145 to $2,190,294 per violation, with a calendar-year cap of $2,190,294, according to 45 CFR 102.3. The cap means the exposure is bounded per calendar year for each provision, but it can still be significant for a hospital. For a chat assistant, the main risks are uncontrolled ePHI in prompts, unaudited chat history and weak access control. Treat the chat project as a risk-reduction priority, and document the risk analysis, access model and retention rules before expanding users. The cap figure is a regulatory maximum, not an estimate of your exposure.
Questions to put to an implementation partner for clinical chat
Start with the risk analysis, because a partner who cannot explain how they support it will struggle with everything after it. Ask who on their team drafts the risk analysis inputs for the chat platform, how they map the assistant's data flows (prompts, uploads, chat history, logs, backups) to where ePHI is created, received, maintained or transmitted, and which artifacts they hand over: an asset and data-flow inventory, a control mapping to the Security Rule standards in 45 CFR 164.308, 164.310 and 164.312, a documented decision on each addressable specification, and a residual risk register. Ask them to confirm that the risk analysis remains the covered entity's own decision and that they will not present their documents as a HIPAA certification, because HHS states no standard requires one. Ask how they will update the analysis when the proposed Security Rule revision moves toward final action.
Ask how PHI is kept off external endpoints. The partner should show you the egress rules for the model host, the chat interface and the gateway, and confirm that no cloud inference path is enabled. Ask specifically how the Ollama API is protected: the local API on port 11434 does not require authentication, and Ollama binds to 127.0.0.1 by default. Ask whether they will keep that default, place a reverse proxy with authentication and TLS in front of it if the bind address changes (for example with OLLAMA_HOST), and disable cloud features with OLLAMA_NO_CLOUD=1. Ask how they will test this, including a scan from outside the model network. For SSO, SCIM and RBAC, ask which identity provider they will connect to Open WebUI or LibreChat via OIDC or LDAP, how SCIM 2.0 group provisioning maps clinical roles to groups, how per-resource permissions limit which care teams see which knowledge collections, and how deprovisioning removes access within your required timeframe.
Ask how audit logs and retention are configured and tested. Clarify which events are recorded (logins, role changes, prompts, uploads, administrative actions), where they are stored, who can read them, and how chat retention is set and enforced, including deletion from backups. Ask them to demonstrate a test where a deleted chat is confirmed gone from the database, file storage and log copies. Ask what BAA terms they will sign if they will create, receive, maintain or transmit ePHI, including the terms required by 45 CFR 164.314(a)(2)(i) such as flow-down to subcontractors and incident reporting. Ask whether they will sign at all if their work is limited to a system the covered entity operates alone, and confirm this with your counsel. Finally, ask how model and release updates are validated: whether they pin versions, run clinical test prompts before each change, keep a rollback path, and track fast-moving releases such as Open WebUI and Ollama against a documented change record. Ask also how they handle backups of the database, the vector store and model files, and how they test emergency access, meaning who can reach the platform when the identity provider is down and how that break-glass access is logged and reviewed.
