Why Dify fits healthcare AI work when PHI stays inside
Healthcare staff increasingly want assistants that answer questions over internal policies, clinical guidance and records, but protected health information cannot leave the organization's control. Self-hosting Dify is a practical way to meet that constraint because the application layer, its knowledge bases, its agents and its LLMOps monitoring all run in infrastructure you choose. Dify is an LLM application development platform for building workflows, RAG pipelines and agents through a visual interface, with a prompt IDE, support for many model providers, LLMOps monitoring and backend-as-a-service APIs. Pointing those workflows at a self-hosted model endpoint keeps prompts, retrieved documents and outputs inside your network, which is the core reason the topic exists. Confirm with your architects which model endpoints, embedding services and file stores will receive patient-related content before any pilot begins.
Keeping data inside does not transfer HIPAA responsibility to the software. The HIPAA Security Rule (45 CFR Part 164 Subpart C) applies to covered entities and business associates for all electronic protected health information they create, receive, maintain or transmit. Dify is open-source software, so the safeguards in the Security Rule, including access control, audit controls, integrity and transmission security, are yours to design, operate and document. Dify's own settings, such as the SECRET_KEY value used for session cookies and JWTs, the SSRF proxy that blocks internal and private IP ranges, and the agent sandbox network isolation added in 1.16.1, support that work but do not complete it. A risk analysis and a written plan should name each of these controls and the person who owns them.
Edition choice also shapes the access model. The self-hosted Community edition is free and limited to a single workspace, which may suit a single pilot team but leaves little room to separate clinical, administrative and research groups. The Enterprise edition adds SSO, multiple workspaces, advanced security and professional support, and its SSO documentation lists OpenID Connect, SAML and OAuth2 with identity providers such as Microsoft Entra ID and Okta. Pricing for Enterprise is custom, so ask vendors for a written quote that states what is included, and confirm with your compliance lead whether separate workspaces are needed to keep staff-facing assistants apart from any patient-facing ones.
Which HIPAA Security Rule requirements shape the Dify build
This table maps the HIPAA Security Rule provisions most relevant to a Dify deployment to the design decisions each one raises. Read each row as a question your team must answer and document, not as a statement that Dify meets the requirement. Dify is software, and the covered entity or business associate remains responsible for its own safeguards and risk analysis.
| Requirement | What it asks for | What it means for the Dify build |
|---|---|---|
| Scope (45 CFR 164.302) | Covered entities and business associates must protect electronic PHI they create, receive, maintain or transmit | Any Dify app, knowledge base, log or file store that touches ePHI falls in scope, including prompts, uploads and retrieved chunks |
| Unique user identification (164.312(a)(2)(i), required) | Each user of an ePHI system has a unique identifier | Staff-facing Dify apps need named accounts or SSO identities, not shared logins, and workspace roles tied to those identities |
| Emergency access procedure (164.312(a)(2)(ii), required) | A documented way to reach ePHI during an emergency | Plan who can reach Dify workflows and knowledge bases when the identity provider is down, and document the break-glass path |
| Automatic logoff (164.312(a)(2)(iii), addressable) | Sessions end after a period of inactivity, or an equivalent measure is documented | Confirm session lifetime settings for the Dify console and web apps, and document the decision if the default is kept |
| Encryption and decryption (164.312(a)(2)(iv), addressable) | Assess whether encryption of ePHI is reasonable and appropriate, and document the result | Decide how Dify data at rest (database, object storage, vector store) and in transit is protected, and record the reasoning |
| Audit controls (164.312(b)) | Mechanisms that record and examine activity in systems with ePHI | Confirm which Dify logs capture prompts, user actions and API calls, where they are stored and who reviews them |
| Business associate terms (164.314(a)(2)(i)) | Contracts require the business associate to comply, flow terms to subcontractors handling ePHI, and report incidents | Model providers, hosting partners and any vendor receiving prompts with PHI need contracts that meet these terms before go-live |
| Addressable specifications (164.306(d)) | Assess reasonableness, document any decision not to implement, and adopt an equivalent measure where appropriate | Every addressable Dify control needs a written assessment, which is the evidence an auditor will ask to see |
| Policies and documentation (164.316) | Written policies and documentation kept current and retained | Keep Dify configuration, SECRET_KEY handling, upgrade records and access reviews in a controlled record set |
Which Dify modules and settings matter for clinical data
Six Dify components decide where patient data goes, who can reach it and what leaves the deployment. Review them together before any clinical content enters a knowledge base, because a secure model endpoint does not help if a sandbox or export path moves the same data somewhere else.
Model routing and vector stores
Every prompt and retrieved passage is sent to whichever model endpoint a workflow calls, and retrieved chunks are stored in the vector database you select. Dify supports many model providers, so route PHI-bearing workflows only to on-premises inference or to endpoints covered by a business associate agreement. Confirm that the vector store (Weaviate by default, or options such as Qdrant, pgvector or OpenSearch) runs inside your boundary and is covered by the same controls as the database.
Metadata database and file storage
The metadata database holds app configuration, users and conversation records, while file storage holds uploaded clinical documents. Dify can use PostgreSQL (the default), MySQL or OceanBase for metadata, and OpenDAL, S3-compatible storage, Azure Blob or Google Cloud Storage for files. Ask which storage backend your records will land on, where its encryption at rest is managed, and who holds its backup copies.
SECRET_KEY and workspace encryption keys
SECRET_KEY signs session cookies and JWTs and encrypts OAuth credentials, so treat it as a controlled secret stored outside the repository. Changing it after deployment logs out all users. Workspace encryption keys can be stored locally or in Azure Key Vault, and the choice determines who can recover encrypted provider credentials. Document key custody, rotation and recovery before go-live.
SSRF_PROXY outbound filtering
Dify workflows and tools can make outbound HTTP requests, which is a route for data to leave the network or reach internal services. The SSRF_PROXY settings send that traffic through a proxy that blocks internal and private IP ranges. Confirm the proxy configuration in your environment, and test that a workflow cannot reach hospital systems or metadata endpoints on your network.
Agent sandbox isolation and service tokens
Dify 1.16.1 added agent sandbox network isolation through a Squid proxy and token-based API authentication between services, along with sandboxed Jinja2 template rendering. These changes limit what generated code and agent tools can reach and how internal services identify each other. For clinical use, verify the sandbox egress rules on your version and keep the release current, since minor releases arrive roughly monthly.
Export limits and what DSL leaves out
App exports as YAML DSL include configuration, workflow nodes, model parameters, prompts and knowledge base connections. They exclude third-party API keys, knowledge base content and usage logs. This makes DSL safe to version and review, but it does not back up patient data. Protect clinical content through database and file backups, and confirm that exported prompts contain no patient identifiers.
How a healthcare Dify rollout moves from pilot to production
The sequence moves a Dify deployment from a scoped, non-PHI pilot to a production service where access, review, logging and upgrades are documented and owned before clinical staff rely on it.
Classify data and set the scope
Privacy, compliance and clinical leads list the data each proposed assistant would touch, separating non-PHI content, ePHI and other regulated records. The team records which use cases are in scope for the first release and which are excluded. Done when the scope statement is signed off and every planned data source is labeled with its classification. Confirm with your counsel which HIPAA covered entity and business associate roles apply to each system and vendor involved.
Design architecture and trust boundaries
Architects draw where Dify, its database, vector store, file storage, model endpoints and sandboxes run, and which traffic crosses each boundary. They decide whether models are hosted internally or reached through an approved external provider, and how outbound requests are restricted through the SSRF proxy. Done when the diagram shows every data flow that could carry ePHI and each control protecting it, and the security team has reviewed it.
Build identity and access design
Identity engineers map staff roles to Dify workspaces and web app access, and decide how users sign in. Community edition login options differ from Enterprise SSO, which lists OpenID Connect, SAML and OAuth2 with separate scopes for workspace and web app access. Done when each assistant has a named access group, unique user identification is enforced for every account, and the access matrix is approved by the data owner.
Run a knowledge base pilot on non-PHI content
A small team loads policy documents, approved patient education material and internal procedures into a knowledge base and tests answers against known questions. Nothing containing patient identifiers enters the pilot. Done when the team has a test set with expected answers, has recorded where retrieval failed, and has agreed the criteria that must be met before any clinical content is considered.
Design clinical human review
Clinical leaders define which outputs need a clinician to approve before use, such as anything that could inform a diagnosis, treatment or patient message. Workflow designers add review steps and record who approved each output. Done when the review rules are written, each review step is tested with a clinician reviewer, and the team has confirmed that unreviewed output cannot reach patients.
Set logging and retention rules
The compliance lead decides which prompts, responses, access events and administrative changes are logged, where logs are stored, who can read them and how long they are kept. Logs are checked for accidental PHI exposure. Done when the retention schedule is approved, log access is restricted, and a test confirms that the chosen logs capture the events needed to investigate an incident.
Document the upgrade routine and backups
Platform engineers write a routine that follows Dify's roughly monthly minor releases, reads the upgrade guide for each target version, checks .env.example for new variables and takes a backup before every upgrade. They rehearse a restore in a non-production environment. Done when the routine is written, a restore has been tested, and the on-call team knows where the backup and rollback steps are kept.
Onboard staff and move to production
Trainers brief staff on what each assistant may and may not be used for, how review steps work and how to report a problem. Access is granted only to the named groups. Done when every user has completed the briefing, the go-live decision is recorded by the data owner, and monitoring and incident contacts are active.
Where human review belongs in clinical assistants
Policy lookup assistants answer staff questions from procedures, formularies and internal policy documents held in a Dify knowledge base. The risk is less about patient harm than about staff acting on an outdated or misread policy, so review is usually designed around document ownership and version control rather than case-by-case approval. Confirm with clinical governance which policies require a named owner to certify the source content before it is indexed.
- Source ownership: Name the policy owner for each knowledge base and require them to approve each document version before it is uploaded.
- Citation display: Configure the assistant to show the source document and section for every answer so staff can check the original.
- Sign-off: The policy owner or the governance committee approves changes to the knowledge base, and the platform team records who uploaded each version.
- Logging: Keep conversation logs and the document version that answered each query, subject to your retention schedule.
- Escalation: Route questions outside the indexed scope to a named helpdesk instead of letting the model guess.
Check whether your policy owners can commit to a review cadence, and whether your retention rules allow staff queries containing patient identifiers to be stored at all.
Drafting patient communications, such as appointment reminders, pre-procedure instructions or billing letters, sends model output directly to a person outside the organization. A workflow should treat the model as a drafting aid only, with a trained staff member reviewing the draft before anything leaves the system. The review should check factual accuracy against the chart or scheduling record, tone, reading level and whether the message contains information that should not be disclosed.
- Draft-only output: Configure the workflow to write to a review queue, never to a send action, so the model cannot reach a patient on its own.
- Reviewer role: Assign drafting review to a named role such as a clinic administrator or nurse, and separate that role from the person who sends the message.
- Data minimization: Pass only the fields the message needs into the prompt, and document which fields the template may read.
- Logging: Record the draft, the edits made by the reviewer and the final sent text, so the organization can reconstruct each communication.
- Disclosure checks: Confirm with counsel which messages must never be generated automatically, such as results or diagnoses.
Check how your patient messaging platform records approvals and whether it can hold a draft without sending it.
Summarizing clinical notes is the use case where errors are most likely to affect care. A summary can omit a medication change, invert a negation or attribute a finding to the wrong date. The workflow should therefore present a summary as a draft that a clinician must read against the source note before it is filed or used for handover. The clinician who authored or is responsible for the encounter should be the sign-off point, and the system should make the source text visible alongside the summary.
- Source-linked review: Display the original note next to the summary so the clinician can verify each statement without searching the record.
- Clinician attestation: Require an explicit accept, edit or reject action, and record which version the clinician accepted.
- No automatic filing: Keep summaries out of the legal record until a clinician has signed them, and check how your EHR integration handles unsigned content.
- Logging: Store the model version, prompt version, input reference and reviewer decision, while limiting copies of the full note inside Dify logs.
- Clinical safety review: Ask clinical safety or informatics staff to test the workflow against representative notes before go-live.
Confirm with clinical governance whether any summary type is permitted without clinician sign-off, and how the EHR treats AI-generated text.
Coding and billing assistants suggest codes or documentation gaps from clinical text. Suggestions affect claims, reimbursement and regulatory exposure, so the review step belongs to a certified coder or revenue cycle specialist who is accountable for the claim. The model should explain which documentation supports each suggestion, and a suggestion without a supporting passage should not be accepted. Coding rules change over time, so the knowledge base must carry dates and owners.
- Coder accountability: A certified coder approves every suggested code before submission, and the workflow must not write to the billing system directly.
- Evidence requirement: Require each suggestion to cite the supporting sentence in the note, and reject suggestions that cite none.
- Rule currency: Assign an owner to the coding reference documents and record the effective date of each version.
- Logging: Keep suggestions, accepted or rejected status and the reviewer identity for audit and dispute handling.
- Compliance review: Ask your compliance team and counsel to define which audit trails they need before the workflow is designed.
Confirm with your compliance and revenue cycle leaders which code sets and payer rules apply in your jurisdiction, since these requirements vary and are not settled by this page.
Compliance evidence a healthcare team must assemble
A self-hosted Dify deployment does not make a healthcare organization compliant, and no HIPAA certificate exists to point to. What a regulator or auditor will ask for is evidence: contracts, configuration records, risk analysis, and a documented view of which obligations apply to which data. DeployOpen prepares systems, controls and evidence for assessments, but independent auditors and certification bodies issue any attestations or reports.
No HIPAA certification exists
HHS states that no Security Rule standard requires an entity to certify compliance, and that HHS does not recognize private certifications. A vendor badge or a self-declared Dify configuration checklist does not settle the question. Your team should be ready to show, on request, how each applicable Security Rule standard is met in your environment, and who owns each control.
Business associate contracts and flow-down
If a Dify deployment, its hosting provider or a model vendor handles ePHI on your behalf, the relationship needs a business associate contract under 45 CFR 164.314. That contract must require Security Rule compliance, flow the same terms to subcontractors that handle ePHI, and require incident reporting. Confirm which model providers, hosts and support firms touch prompts, documents or logs, and whether each will sign.
Penalty exposure under 45 CFR 102.3
Civil money penalties are adjusted for inflation each year. For penalties assessed on or after January 28, 2026, the range runs from $145 per violation to $2,190,294 per violation, with a calendar-year cap of $2,190,294. The exposure grows when a known gap is left open, so documented risk decisions and timely corrections carry real weight in how a violation is judged.
Pending Security Rule revision
HHS proposed a major Security Rule revision on January 6, 2025 (90 FR 898), with comments due March 7, 2025. As of October 2026 no final rule has been published, and the Unified Agenda projects final action for July 2027. Build your Dify controls against the current rule, and track the proposal for changes to encryption, asset inventory, and recovery planning that would affect your AI deployment.
NIST SP 800-66 Rev. 2 as a mapping aid
NIST SP 800-66 Rev. 2, published in February 2024, gives key activities and sample questions for each Security Rule standard. HHS lists it as informational rather than legally binding. Use it to structure your Dify evidence map, with one row per standard showing the configuration, the owner, and the record that proves it, such as access reviews, backup restore tests and audit log exports.
HITRUST and EU obligations
HITRUST CSF v11.9.0 is an assessment framework that organizations may choose for assurance, and its e1, i1 and r2 certifications are issued through a formal assessment, not by self-declaration. If you treat EU patients or operate in a sector NIS2 covers, GDPR Articles 32 and 34 apply, and a 2026 CNIL fine of EUR 500,000 turned on missing VPN and multi-factor authentication for external access. Confirm with counsel which regimes apply before you choose which evidence to build first.
What healthcare teams ask before hiring a partner for Dify
Can our own team deploy and run Dify without a partner?
Yes, many teams can deploy the Community edition in-house, provided they have people who can operate Docker or Kubernetes, manage PostgreSQL, Redis and object storage, and maintain TLS and secrets. The Docker Compose deployment starts the api, worker, web, plugin daemon, PostgreSQL, Redis, Weaviate, Nginx, a code sandbox and an SSRF proxy, so the work is more than a single container. The harder parts for healthcare are the ones that sit outside the install: mapping data flows to the HIPAA Security Rule, designing access for staff assistants, setting log retention, and defining human review for clinical content. Ask your team to name an owner for each of these before deciding whether to bring in a partner for part or all of the work.
What drives the cost and effort of a Dify healthcare project?
Cost follows scope more than the software itself, because Dify Community is free to self-host. The main drivers are the number of workflows and knowledge bases, the number of systems Dify must connect to, whether models run inside your environment or through an external provider, how identity is integrated, and how much documentation and evidence the compliance team needs. Recurring costs include infrastructure, model usage, staff time for reviews and upgrades, and any support retainer. Ask any partner for a written scope that lists each integration, each model endpoint, each identity provider and each deliverable, so that the quote can be compared line by line.
What must our organization provide before implementation starts?
Implementation moves faster when your organization supplies decisions and access early. Typical inputs include a named data owner for each knowledge base, clinical reviewers who define which outputs need human sign-off, an identity administrator who can configure SSO and group mapping, and a network or cloud contact who can provision hosts, storage and outbound proxy rules. You should also provide your current policies on log retention, backup frequency and approved model providers. Confirm these responsibilities in the written scope so that delays are assigned to a named role rather than discovered mid-build.
Is the Dify Community edition enough for a healthcare deployment?
The Community edition may be enough for a single workspace used by one team, but it has limits that healthcare organizations often hit. According to the Dify pricing page, Community is free and limited to a single workspace, while the Enterprise edition adds SSO, multiple workspaces, advanced security, a commercial license and professional support. Enterprise SSO supports OpenID Connect, SAML and OAuth2 with providers such as Microsoft Entra ID and Okta. Confirm with Dify which edition matches your number of workspaces, identity requirements and support expectations, and check that your intended use is covered by the license terms. Note that the Dify Open Source License prohibits operating a multi-tenant environment without written authorization.
How are upgrades and backups handled for a self-hosted Dify?
Upgrades are a planned change, not a routine image pull. Dify publishes minor releases roughly monthly, and the Docker Compose documentation says to follow the upgrade guide for the target version, take a backup before every upgrade, and check .env.example for new variables afterward. Backups should cover the metadata database, file storage and vector store, and the SECRET_KEY must be preserved, since changing it logs out all users. Dify 1.16.1 added security changes such as agent sandbox network isolation, so timing matters for security reviews. Ask any partner how it will test upgrades in a non-production environment, how restores are verified, and who approves each change.
Do we need a business associate agreement with a Dify partner?
A business associate agreement is needed when a partner creates, receives, maintains or transmits electronic protected health information on your behalf. Under 45 CFR 164.314(a)(2)(i), that agreement must require the business associate to comply with the Security Rule, flow the same terms down to subcontractors that handle ePHI, and report security incidents to the covered entity. If a partner works only on infrastructure you control and never accesses ePHI, ask your privacy officer to confirm whether an agreement is still required for the access it does have, such as remote administration sessions. Have legal counsel review the agreement, and confirm the terms in writing before any access to a live environment.
Does HIPAA certification of Dify or a partner mean we are compliant?
No, there is no HIPAA certification. HHS states that no Security Rule standard requires an entity to certify compliance, and that private certifications do not prevent HHS from later finding a violation. Compliance is shown through your own risk analysis, policies, safeguards and documentation, which the HHS Office for Civil Rights can review through complaints, compliance reviews and audits. A partner can help prepare systems, controls and evidence, but it cannot issue an attestation. Ask any partner to show which evidence it will produce and which parts remain your responsibility.
What to ask a partner before signing a fixed-scope agreement
Most DeployOpen engagements are fixed-scope, which means the scope, deliverables and timelines are written down and agreed before work starts. For a healthcare organization, that document is where PHI handling must be settled. Ask the partner to state in writing whether any engagement activity will touch real patient records, such as sample data for knowledge base testing, workflow debugging or log review. If it will, ask how that data is copied, where it is held during the work, who can see it, and how it is destroyed afterward. If the partner will handle ePHI on your behalf, the business associate terms in 45 CFR 164.314(a)(2)(i) should be reviewed by your counsel before the work starts, since they require the partner to comply with the Security Rule and report security incidents to you.
Ask how the partner gets into your environment and what it can reach. For a self-hosted Dify deployment, the questions are concrete: which cloud accounts, Kubernetes namespaces or hosts it will use, whether it holds administrator rights on the PostgreSQL, Redis, object storage or vector store, and who holds the SECRET_KEY and the workspace encryption keys at handover. Ask what evidence will be delivered at the end, such as configuration exports, access reviews, backup restore test records and the change log for each upgrade. Ask whether the evidence is produced for your own control owners or only for the project. DeployOpen prepares evidence for compliance assessments but does not issue audit reports or certifications, so ask which independent auditor or HHS process your documents are meant to support.
Clarify the licensing position early. The Community edition is free and limited to a single workspace, while the Enterprise edition is custom priced and adds SSO, multiple workspaces, advanced security and professional support. Ask the partner to show which features your clinical and staff-facing design needs, and which of them the Community edition can cover. Ask who buys the license, whether it is priced inside or outside the fixed scope, and how it renews. Finally, ask about support and retainers: response expectations, who answers a security patch request, how minor releases that arrive roughly monthly are tested before rollout, and what the retainer covers beyond the fixed build. Get each answer in writing, because a verbal assurance will not survive a later incident review.
How DeployOpen works on this
DeployOpen plans, builds, hardens and documents self-hosted Dify inside your own cloud accounts, data centers or air-gapped networks, so clinical and patient data stays under your control. Engagements start with a written scope that names the workflows, data sources, model endpoints and access rules before any build begins.
How we scope
- Inventory the assistants, knowledge bases and workflows that would touch clinical or patient data, and record which ones are in and out of scope.
- Map each data source and model endpoint to a data flow diagram that shows where PHI is stored, processed and logged.
- Agree in writing which HIPAA Security Rule standards, business associate terms and internal policies the deployment must support.
How we build
- Deploy Dify in your environment with the database, object storage and vector store your security team has approved.
- Configure outbound request filtering, secret handling, sign-up policy and API exposure, then test each control against the written design.
- Connect staff-facing assistants to your identity provider and configure human review steps for any output that reaches clinical records.
How we hand over
- Document the architecture, configuration baseline, access model, log retention settings and backup and restore procedure.
- Run a verification pass that records test results for access control, logging and review steps, so your team can reproduce them.
- Train the operators who will run upgrades, queue monitoring and backups, and hand over the runbooks they will use after go-live.
How we support
- Offer ongoing support, upgrades and continuous security testing as a retainer, scoped to your Dify version and environment.
- Review each minor release against your configuration baseline, including new environment variables, before it reaches production.
- Prepare control evidence for your internal reviews and for independent assessors, without issuing any audit report or certification ourselves.
