Why self-hosted LLM inference for healthcare starts with PHI in every prompt
Clinical informatics and security leaders are being asked to put documentation, coding and patient messaging help in front of clinicians, and every prompt can carry protected health information. The realistic path is a shared inference service inside the covered entity's or business associate's environment, where prompts, outputs and logs stay under the same safeguards as the rest of the ePHI. Hosted APIs add a business associate relationship and data flows that need their own contract and risk analysis before anyone types a patient name into them. HIPAA has no certification to point to. HHS states that no Security Rule standard requires an entity to certify compliance, and the HHS Office for Civil Rights judges the program through complaints, compliance reviews and audits. Your evidence is therefore the risk analysis, the safeguard decisions behind it, and records that show those safeguards operate. Confirm with counsel which parts of your environment fall under the Security Rule and which business associate contracts already cover model vendors.
On the platform side, the short answer is vLLM for shared GPU serving and Ollama for smaller or CPU-bound nodes. vLLM exposes OpenAI-compatible endpoints, but its security documentation says the --api-key option does not protect every route, so a reverse proxy that allowlists only the endpoints meant for clinical applications belongs in front of it. Ollama binds to 127.0.0.1 on port 11434 by default and its local API does not require authentication, so any exposure beyond the host must be handled by a proxy and network controls you define. Around both engines, plan a gateway such as LiteLLM or Apache APISIX for keys and access logging, and a log store for the audit trail. This is general guidance, not legal advice, and HHS has not finalized its proposed Security Rule revision published on 6 January 2025, so confirm the current requirements with your compliance and legal teams before clinical teams rely on the service.
Which HIPAA and related requirements shape the build
This table maps the HIPAA Security Rule requirements and the vLLM security notes to specific decisions in an in-house inference build. Read each row as a requirement, what it means for the serving stack, and the evidence a risk analysis or assessor will ask to see. Confirm scope with counsel and your compliance lead before treating any row as settled.
| Requirement | What it asks for | Build decision and evidence |
|---|---|---|
| Security Rule scope (45 CFR 164.302) | Covers covered entities and business associates for all ePHI they create, receive, maintain or transmit | Decide whether the inference service is inside the covered boundary, and document every prompt, output and log that may carry PHI |
| Appendix A standards (18) and specifications (36) | Administrative, physical and technical standards, with 14 required and 22 addressable specifications | Map each specification to a control owner for the GPU nodes, gateway and logs, and record why any addressable item is accepted, modified or declined |
| Unique user identification (164.312) | Required specification that each user of ePHI systems has a unique identifier | Avoid a single shared API key for clinical tools; issue per-application or per-user identity at the proxy in front of the engine and log it |
| Automatic logoff and encryption (164.312) | Addressable specifications for session termination and encryption of ePHI | Set session timeouts on chat front ends, and encrypt traffic between clients, proxy and inference nodes and data at rest on model and prompt stores |
| Emergency access procedure (164.312) | Required specification for obtaining ePHI during an emergency | Describe how clinicians keep access to the tool or a documented fallback when the inference cluster is down, and test it |
| Business associate contracts (164.314) | Require the vendor to meet the Security Rule, flow terms to subcontractors handling ePHI and report security incidents | Check whether the implementation partner, hosting provider and any support vendor with access to ePHI will sign a business associate agreement |
| vLLM node-to-node traffic | Multi-node communication is insecure by default with no authorization or encryption; isolate nodes on a private network | Place GPU nodes on an isolated segment and verify with network tests that no other network can reach inter-node ports |
| vLLM --api-key option | Protects /v1, /v2, /inference and /cohere paths but not /invocations, /metrics, /health or control endpoints; docs warn against relying on it alone | Put a reverse proxy in front that allowlists only user-facing endpoints, and block /metrics and control routes from clinical networks |
| Evidence for a risk analysis | Accurate inventory of systems, data flows and threats; the Security Rule does not require a certification | Keep a current data flow diagram, access logs from the gateway and engine, and a documented review cycle; confirm which assessor evidence your counsel expects |
How clinical documentation, coding and patient messaging change the data risk
Note drafting sends the most complete clinical record into the model. A clinician who asks for a discharge summary or progress note usually pastes or retrieves the encounter transcript, problem list, medication list, lab values and sometimes prior notes, so the prompt carries direct identifiers together with diagnoses, treatments and mental health or substance use details. The output is also PHI, because the draft repeats those details and is saved back into the record. For the inference platform, this means the prompt and completion logs are ePHI from the first request, and any retrieval step that pulls prior notes adds a second copy.
- PHI in prompts: names, dates of service, record numbers, diagnoses, medications, allergies and free-text history from the encounter.
- PHI in outputs: the generated draft repeats identifiers and clinical facts, so it needs the same access controls as the source note.
- Audit trail: log the user, patient context, time, model version and whether the draft was signed, edited or discarded, without storing full prompt text in general application logs.
- Human review: the clinician reviews and signs every note, and the platform should not write drafts directly into the record without that step.
- Confirm with the vendor: whether the chosen front end stores chat history or uploaded files by default, and how those stores are purged.
Before go-live, check which fields the drafting prompt template includes and whether any field can be trimmed to the minimum the note needs.
Coding assistance usually sends a narrower set of inputs, but the outputs can be dense with clinical meaning. A coder or a coding assistant may submit a note excerpt and ask for candidate diagnosis or procedure codes, or ask for a query to the physician about missing documentation. The prompt often includes the patient's encounter identifier and the note text, and the output lists codes that link the patient to a diagnosis. Those codes are PHI when they sit alongside an identifier, so coding logs can reveal conditions even when names are removed.
- PHI in prompts: encounter and account numbers, note excerpts, procedure descriptions and diagnoses.
- PHI in outputs: suggested codes, rationale text and physician query drafts, which tie conditions to a patient.
- Audit trail: record which coder requested which suggestion, which code was accepted, and which reference version of the code set the tool used.
- Human review: a certified coder or a clinician confirms every code before claim submission, since coding errors affect billing and the legal record.
- Confirm with the vendor: whether the tool can be given a fixed code set version and whether suggestions are retained after the claim is closed.
Separate the coding workspace from general staff chat so that coding prompts do not mix with unrelated access groups.
Patient messaging is the use case where model output reaches a patient directly or shapes what the patient reads. Inputs may include the patient's portal message, appointment details, medication questions and prior replies, and the model may draft a response for a staff member to send. The data flow is bidirectional: patient-authored free text can contain sensitive information the patient chose to share, and the reply can contain clinical instructions. The risk is less about the prompt leaving the building, which self-hosting prevents, and more about wrong or unsafe text reaching a patient without review.
- PHI in prompts: the patient's message, identifiers, appointment and medication context, and the thread history.
- PHI in outputs: draft replies that restate medications, results or instructions, and any generated summary sent to the care team.
- Audit trail: log the draft, the editor's changes, the sender and the send time, so the record shows who approved the text a patient received.
- Human review: a clinical or qualified staff member reviews every patient-facing reply before sending, with clear escalation rules for urgent symptoms.
- Confirm with the vendor: whether the model's output can be blocked from automatic sending and whether any guardrail layer filters clinical advice.
Set the review step in the workflow design, not in a policy document, and test it with staff before patients are involved.
Which open-source platforms fit a HIPAA inference environment
A HIPAA-aligned inference environment is a chain of components: an engine that serves the model, a gateway that controls who calls it, a logging layer that records use, and a front end for staff. Each link has its own license terms, default network exposure and authentication behavior, so each choice needs confirmation against the current release before it touches prompts that contain PHI.
vLLM as the serving engine
vLLM is licensed under Apache-2.0 and exposes OpenAI-compatible endpoints such as /v1/chat/completions, so clinical applications can call it without a hosted provider. It also publishes Prometheus metrics at /metrics and supports several Kubernetes deployment paths. Confirm which endpoints you expose, because the security documentation says the --api-key option does not cover every route, including /metrics and /health, and recommends a reverse proxy that allowlists only user-facing paths. Node-to-node traffic in multi-node runs is unauthenticated by default and needs an isolated network.
Ollama for smaller, contained nodes
Ollama is MIT licensed and binds to 127.0.0.1 on port 11434 by default, so a clinical workstation or small server stays local unless someone changes OLLAMA_HOST. Its local API requires no authentication, which means the proxy, network policy and host firewall must supply access control. Set OLLAMA_NO_CLOUD=1 so cloud features cannot route prompts outside the environment, and verify that setting on every node. Ollama is better suited to small deployments than to high-concurrency shared services.
LiteLLM for keys, logging and guardrails
LiteLLM is an AI gateway that places one OpenAI-format interface in front of model backends, with logging, guardrails and per-key controls. It is MIT licensed except for its enterprise directory, so confirm which of the features you need sit outside that directory before relying on them. In a healthcare design, the gateway is where user identity maps to clinical roles, where request metadata is logged without unnecessary PHI, and where access reviews are evidenced. Test that the logging configuration does not store full prompts in places with weaker controls.
Langfuse for self-hosted traces
Langfuse records traces, evaluations and cost data for LLM applications, and its core is MIT licensed with its ee directories excluded. Self-hosting keeps those traces in your own database, which matters because traces often contain prompt and output text that is PHI. Decide the retention period and who can open traces before enabling capture, and confirm that the features you rely on are outside the ee directories. Phoenix is an alternative, but its Elastic License 2.0 prohibits offering it to third parties as a hosted or managed service, which affects managed deployments.
Open WebUI or LibreChat for staff
Clinicians and coders reach the models through a chat front end, and Open WebUI and LibreChat are the common choices. LibreChat is MIT licensed. Open WebUI is covered by a BSD-style license whose clause 4 limits altering or removing its branding, with exceptions for deployments of no more than 50 end users in any rolling 30-day period, written permission or other listed cases. A hospital with more staff should confirm its branding position before deployment. Either interface needs SSO, session timeouts and disabled public sign-up to meet the access control expectations in the Security Rule.
Confirm capabilities before selection
Each component above changes between releases, and the features described here, including logging hooks, endpoint controls and license boundaries, must be verified against the version you intend to deploy. Ask each vendor or project for its current license text and its security documentation, and record the version in your risk analysis. Build a test plan that confirms unauthenticated routes are blocked, that cloud calls are disabled, and that logs hold what you intended. Treat this card as a checklist to validate, not as a statement of current behavior.
Isolating GPU nodes and endpoints for PHI workloads
Inference nodes that handle PHI should sit on a network segment that accepts connections only from the AI gateway, and nothing else should reach them directly. The engine itself is not the security boundary. vLLM's security documentation says communication between nodes in a multi-node deployment is insecure by default, with no authorization or encryption, so any tensor or pipeline parallel traffic between GPU servers must stay on an isolated network that clinical applications, workstations and general corporate subnets cannot reach. Ollama binds to 127.0.0.1 on port 11434 by default and its local API requires no authentication, so any change to OLLAMA_HOST to expose it beyond the host needs a proxy in front of it. Confirm with your network team that firewall rules block the inference ports from every subnet except the gateway's.
The --api-key option on vLLM does not protect every route. According to the vLLM security documentation, it covers the /v1, /v2, /inference and /cohere paths but not /invocations, /pause, /resume, /abort_requests, /metrics or /health. Those unprotected routes need to be removed from anything a user or application can reach. Put a reverse proxy in front of the engine that allowlists only the endpoints meant for clients, and keep /metrics reachable only by the monitoring system. Ask your partner to show the proxy rules and a test that requests to the blocked paths fail from a client network.
Access logging belongs at the gateway, where each request can be tied to a user or service identity, a timestamp, the endpoint, the model and the outcome. Decide before go-live whether raw prompts are logged. Prompts often contain PHI, so the default should be metadata only, with prompt content logged only where the risk analysis documents a need, a retention period and a protected store with restricted access. Confirm the approach with your privacy officer and security team, and check whether any retained logs fall under your audit log retention rules, because the EU AI Act's Article 19(1) retention period applies only to high-risk systems placed on the EU market and only where the act's obligations apply.
Access control failures are where regulators look hardest. France's CNIL fined Hopital Prive de la Loire EUR 500,000 on 3 September 2026 under GDPR Articles 32 and 34, finding that external access to its patient record system lacked VPN and multi-factor authentication and that access control ignored the care team's need to know. Illustratively, a model endpoint reachable from outside the clinical network with a shared key and unlogged prompts would raise the same questions. Treat each GPU node, the gateway and the monitoring stack as in scope for the risk analysis.
How a healthcare inference rollout moves from risk analysis to clinical use
The sequence turns a clinical idea into an inference service that clinical teams can rely on, with each phase producing a record that the next phase depends on. Risk analysis and data flow mapping come before any infrastructure is built, and clinical sign-off comes before any real patient prompt is sent.
Scope the use case and select the workflow
The health system's clinical leaders, privacy officer and security lead agree on one or two workflows, such as draft clinical notes, coding suggestions or patient message drafts, and state what the model may and may not do. DeployOpen documents the users, the input and output types, whether PHI is present, and whether any output reaches a patient without a clinician review. The step closes with a signed scope statement that names the business owner and the clinical safety owner.
Complete the risk analysis and map data flows
The security team, with the privacy officer and clinical owners, runs a risk analysis across the HIPAA Security Rule administrative, physical and technical safeguards and records each threat, likelihood, impact and planned control. In parallel, DeployOpen maps every path a prompt, file, embedding and log takes, including backups, monitoring agents and any vendor support access. The closing artifacts are a risk analysis record and a data flow diagram that marks every location where ePHI is stored or transmitted.
Design the environment and network boundary
Based on the data flow diagram, the team designs where the inference servers, gateway, logging stores and GPU nodes sit inside the existing HIPAA environment, which subnets can reach them, and which identities can call them. DeployOpen specifies encryption for data in transit and at rest, unique user identification through the health system's identity provider, and automatic logoff for interactive sessions. The vLLM documentation states that node-to-node traffic in multi-node deployments is insecure by default, so the design isolates those nodes on a dedicated network. The output is an architecture decision record and a network diagram reviewed by the security team.
Pilot with synthetic or de-identified data
Before any real PHI reaches the service, DeployOpen deploys the stack with synthetic notes and de-identified records that mirror the target document types. The team tests latency, output quality, failure behavior, access control on every endpoint, and whether prompts or outputs appear in any log they should not. Engineers confirm the reverse proxy exposes only the endpoints intended for users, since the vLLM --api-key option does not cover every route. The output is a pilot test report with pass and fail results against the risk analysis controls.
Validate outputs and obtain clinical governance sign-off
Clinical reviewers score model outputs against an agreed reference set, record error types and their clinical severity, and decide which uses require mandatory clinician review. The governance committee, with the privacy officer and compliance lead, reviews the validation results, the residual risks and the monitoring plan before approving any use. Where the service supports records that fall under other rules, such as 21 CFR Part 11 for regulated research records, the team confirms those obligations separately. The output is a validation report and a signed approval that names the approved workflows and their limits.
Harden production with logging and monitoring
DeployOpen moves the approved configuration into production, enables access logging that records who called which endpoint and when without storing unnecessary prompt content, and sets retention periods that the privacy and legal teams approve. Prometheus metrics from the vLLM /metrics endpoint are wired to alerting, and the team restricts /metrics and /health to internal monitoring networks. The team tests backup and restore for model artifacts and configuration. The output is a hardened configuration baseline and a monitoring runbook.
Hand over operations and keep the risk analysis current
DeployOpen trains the health system's operations team on patching, engine upgrades, model changes and incident response, and agrees how security incidents involving PHI are reported to the covered entity. Any change to the model, engine version or intended use triggers a documented review against the risk analysis and, where needed, a new clinical validation. The closing deliverables are an operations handbook, an access and change log procedure, and a current risk analysis record that the organization owns.
Evidence auditors and HHS reviewers ask for
This table lists the records an assessor or HHS reviewer is likely to request for an in-house model service, and the component that produces each one. Use it to confirm that every artifact has an owner and a retention path before clinical teams rely on the service. HIPAA has no certificate, so the evidence itself is what gets reviewed.
| Evidence artifact | What it shows | Component that produces it |
|---|---|---|
| Risk analysis and risk management records | Where ePHI enters, is stored and leaves the inference stack, and the threats and controls chosen for each path | Organization's risk management process, informed by inventory of the gateway, engine, proxy and GPU nodes |
| Business associate agreements | Contract terms requiring Security Rule compliance and incident reporting, flowed down to each subcontractor handling ePHI | Legal and procurement records, covering the hosting provider, support partner and any vendor touching ePHI |
| Unique user identification and access records | Each clinician or service account maps to one identity, with role-based access to endpoints and model routes | Identity provider, reverse proxy allowlist and the AI gateway's key and user registry |
| Gateway and inference request logs | Who called which model, when, from where, and whether PHI-bearing requests were blocked or logged | AI gateway audit log and the vLLM or Ollama server logs, forwarded to central storage |
| Configuration baselines | Approved settings for the engine, proxy, bind addresses, API key handling and disabled endpoints | Infrastructure-as-code repository and configuration files for vLLM, Ollama and the reverse proxy |
| Patch and engine release records | Which engine and dependency versions ran in production, when they changed and what was tested first | Change management tickets, container image registry and release notes from the engine project |
| Backup and recovery test results | Evidence that model artifacts, configuration and logs can be restored within the agreed recovery targets | Backup tooling and the test runbook signed off by the operations team |
| Certification status | No HIPAA certificate exists; HITRUST assessments are optional and e1, i1 and r2 certifications last one, one and two years | Independent HITRUST assessor, only if the organization chooses that assessment |
What healthcare teams ask before hiring an implementation partner
What drives the cost of a self-hosted LLM inference platform for healthcare?
Cost is driven by GPU or accelerator capacity, the surrounding infrastructure, the integration work with EHR and coding systems, the depth of the HIPAA risk analysis, validation work and the people who operate the service afterward. vLLM and Ollama carry no license fee for self-hosted use, so the largest line items are usually hardware, implementation labor and ongoing operations. Ask any partner for a quote that separates one-time work (architecture, deployment, integration, risk analysis, documentation) from recurring work (monitoring, patching, engine upgrades, access reviews and support). Ask for hardware specified by model size and concurrency, not a single lump sum.
How long does a healthcare inference deployment take?
The timeline depends on the number of use cases, whether GPUs are already installed, how many systems must be integrated, and how long clinical and privacy reviews take. A single clinical documentation pilot on existing hardware is usually simpler than a multi-department platform that touches EHR, coding and patient messaging workflows. DeployOpen agrees scope, deliverables and timelines in writing before work starts, so ask for a milestone plan that names the clinical sign-off and risk analysis dates. Request a duration only from a written scope, not from a generic estimate.
What does our team need to provide before an engagement starts?
A clinical owner for each use case, a security lead who can approve network and access designs, and someone who can describe the data flow in detail. The partner will need to know which systems send prompts, what data those prompts contain, where outputs are stored, and which staff roles should see them. Without these inputs, the risk analysis and access design will rest on assumptions. Also confirm the business associate status of every vendor in the flow, because a business associate contract under 45 CFR 164.314(a)(2)(i) must cover the Security Rule terms for any subcontractor that handles ePHI.
Can our internal engineers run the platform after handover?
Often yes, but only if the team is staffed for GPU operations, Linux and container administration, monitoring and on-call response. vLLM ships new minor releases about every two weeks (for example v0.30.0 on September 22, 2026 and v0.31.0 on October 5, 2026), so someone must own patching, regression testing and rollback. Ask the partner for a handover plan covering runbooks, backup of model artifacts and configuration, capacity monitoring and a documented upgrade cadence. Decide before the project starts whether you will run it in-house, retain support, or split responsibilities.
Is a HITRUST assessment required for a self-hosted model service?
No. There is no HIPAA certification, and HHS states that no Security Rule standard requires an entity to certify compliance. HITRUST is a voluntary framework that some customers and partners ask for, and it is assessed by an authorized assessor, not by DeployOpen. What you do need is a documented risk analysis, the administrative, physical and technical safeguards in 45 CFR Part 164 Subpart C, and evidence that you can show an auditor or HHS Office for Civil Rights. Ask your counterparties whether they require HITRUST before you commit to an assessment.
What do Ollama's paid cloud plans change for PHI?
Running models on your own hardware is unlimited under Ollama's pricing page, and the paid plans (Pro, Max, Team and Enterprise) apply to its cloud models. Direct cloud inference at ollama.com requires an API key, which means prompts leave your environment. For PHI, the safe design is to keep Ollama on your own servers, bind it deliberately, and disable cloud features with OLLAMA_NO_CLOUD=1 or the server configuration file. Do not send PHI to Ollama cloud endpoints unless a signed business associate agreement and a risk analysis cover that flow. Confirm the terms with Ollama directly, because a plan does not change your HIPAA obligations.
What penalty exposure should a healthcare leader understand before launch?
For penalties assessed on or after January 28, 2026, the inflation-adjusted HIPAA civil money penalty runs from $145 to $2,190,294 per violation, with a calendar-year cap of $2,190,294 under 45 CFR 102.3. The exposure depends on the level of culpability and on whether the organization can show a risk analysis and reasonable safeguards. Use these figures to justify funding the risk analysis, access controls and logging, not as a forecast of any outcome. Ask your counsel how the platform fits your breach notification and incident reporting duties.
Questions to put to an implementation partner before signing
Start with the business associate question, because it decides whether the partner can touch PHI at all. Ask who signs a business associate agreement with DeployOpen, and how that agreement flows down to every subcontractor that can reach ePHI, such as a cloud provider, a managed monitoring service or an on-call vendor. 45 CFR 164.314(a)(2)(i) requires the same Security Rule terms to flow down and requires incident reporting back to the covered entity. A partner that answers with a generic privacy policy instead of a subcontractor list with signed agreements is a reason to stop. Ask for the list of parties that could access the environment, and confirm the contract language with your counsel before any PHI is loaded.
Next, ask how each engine endpoint is secured. The vLLM security documentation says the --api-key option protects only the /v1, /v2, /inference and /cohere paths, and that /metrics, /health, /pause, /resume, /abort_requests and /invocations are not covered. Ask for the reverse proxy configuration that allowlists only the paths clinical applications use, and ask how multi-node traffic is isolated, since the same docs state node-to-node communication is insecure by default. A partner who has no isolation plan for multi-node traffic, or who plans to rely on the API key alone, has not read the engine's own guidance. Also ask how Ollama's default binding to 127.0.0.1 on port 11434 is preserved or changed when it sits behind a proxy.
Then ask how engine and model updates are validated before clinical use. vLLM has shipped new minor releases about every two weeks (v0.30.0 on September 22 and v0.31.0 on October 5, 2026), so ask for the change-control process, a staging environment, a regression set of clinical prompts with expected outputs, and who approves each promotion. Ask how logs are kept without storing PHI unnecessarily: which fields are retained, whether prompt bodies are logged or only token counts and request identifiers, how retention is set, and how access to the logs is reviewed. Ask how the partner supports your risk analysis under 45 CFR 164.308, and who is on call for GPU failures and patch emergencies, with the response expectations written into the statement of work. Confirm every answer in writing before signing.
