Why a self-hosted vector database for healthcare must be treated as PHI
Embeddings derived from electronic protected health information should be governed as PHI, and a self-hosted vector store inside the organization's HIPAA-controlled boundary is the usual starting point for a health provider or payer team that wants retrieval over clinical notes and records. The reason is that a vector is not an anonymous number. Embeddings can be inverted or probed to recover much of the meaning of the text they came from, and chunk payloads often store the original passage, patient identifiers, encounter dates or diagnosis codes so results can be cited. A vector store that holds those payloads holds ePHI. The HIPAA Security Rule (45 CFR Part 164 Subpart C) applies to ePHI a covered entity or business associate creates, receives, maintains or transmits, so the embedding pipeline, the vector collections, the snapshots and the logs all fall inside its scope, not only the source EHR.
The choice between Qdrant, Milvus, Weaviate or pgvector matters less than the controls around it. Qdrant, for example, is unsecured by default: its security documentation states that self-deployed instances listen on all interfaces with no authentication configured, so the team must enable API keys or JWT-based access with per-collection read and write permissions, enable TLS, and turn on the JSON audit logging available since v1.17.0. The same questions apply to pgvector inside PostgreSQL: who holds roles on the tables holding embeddings, how backups are encrypted, and where query logs go. Confirm each control in your own environment and map it to the Security Rule standards for access control, audit controls and transmission security, using the Appendix A matrix on eCFR as your reference.
No certification exists for HIPAA. HHS states that no Security Rule standard requires certifying compliance, and private certifications do not prevent a later finding of violation, so no platform can be called HIPAA compliant on its own. The evidence is what your organization can show: a risk analysis that lists the vector store, documented access decisions per collection, business associate agreements with any hosting or support provider that touches ePHI, tested backup and restore records, and audit log samples. Before the build starts, ask your security officer whether the vector store falls under the existing risk analysis and which owner signs off on it.
Which HIPAA Security Rule standards reach the vector store
This table maps each HIPAA Security Rule requirement and related regulation to the part of a self-hosted vector store it affects. Read it as a checklist for the build: the requirement shows what is asked, the source tells you where to verify it, and the last column states what your team must decide or configure.
| Requirement | Source | What it means for the build |
|---|---|---|
| Scope over ePHI held by covered entities and business associates | 45 CFR 164.302 | Embeddings and payloads derived from clinical notes or records are electronic PHI when they are created, received, maintained or transmitted, so the vector store falls inside the Security Rule boundary. |
| 18 standards and 36 implementation specifications, 14 required and 22 addressable | Appendix A to Subpart C of Part 164 | Document which addressable specifications you adopt, which you implement differently and why. Each choice needs written justification that an assessor can review. |
| Unique user identification and emergency access procedure | 45 CFR 164.312 (required specifications) | Each engineer and service account needs its own identity. Qdrant API keys are shared by default, so plan per-user or per-service access and a documented break-glass path. |
| Automatic logoff and encryption of ePHI | 45 CFR 164.312 (addressable specifications) | Set session timeouts for admin consoles and enable TLS for REST and gRPC. Encryption at rest on the storage volumes is a separate decision to record and justify. |
| Audit controls over access to ePHI | 45 CFR 164.312 technical safeguards | Enable audit logging of authenticated API operations and forward it to central, tamper-resistant storage. Confirm the retention period with your compliance lead. |
| Business associate terms for vendors touching the store | 45 CFR 164.314(a)(2)(i) | Any hosting provider, support firm or subcontractor that can reach the vector data needs a contract requiring Security Rule compliance and incident reporting, with the same terms flowed down to subcontractors. |
| No HIPAA certification exists | HHS FAQ 2003 | Do not accept a vendor claim of HIPAA certification as proof of compliance. Ask for your own risk analysis and evidence of the controls you implemented. |
| Proposed Security Rule revision | 90 FR 898 (January 6, 2025); RIN 0945-AA22 | No final rule had been published as of October 2026, and the Unified Agenda projects final action for July 2027. Design for current rules and track changes that could add requirements. |
| Access control and need-to-know for EU-facing data | GDPR Article 32; CNIL decision of 3 September 2026 | CNIL fined Hopital Prive de la Loire EUR 500,000 for external access without VPN or multi-factor authentication and for access control that ignored the care team's need to know. Scope vectors per collection to the roles that need them. |
| Civil money penalties | 45 CFR 102.3 (inflation-adjusted range for penalties assessed on or after January 28, 2026) | The range runs from $145 to $2,190,294 per violation, with a calendar-year cap of $2,190,294. Treat unmanaged vector stores as a documented risk in your risk analysis. |
Which open-source platforms fit clinical data and why
Clinical embeddings are PHI-derived data, so the store, the retrieval layer and the model gateway all need to keep data inside controlled infrastructure with access limits and logs. The options below differ mainly in how much access control, auditing and operational work they leave to your team.
Dedicated Qdrant
Qdrant is a dedicated vector engine under Apache-2.0, with v1.19.2 published October 5, 2026. It suits large clinical collections and per-collection separation of record types. The default install is not secure: it listens on all interfaces with no authentication, so API keys, TLS, per-collection JWT permissions (v1.9.0) and JSON audit logging (v1.17.0) must be configured and tested before any clinical data is loaded. Confirm which of these controls your chosen version and deployment path support, and who owns the log retention.
pgvector inside existing PostgreSQL
pgvector is a PostgreSQL extension under the PostgreSQL License, with v0.8.7 released October 1, 2026, and it supports PostgreSQL 13 and later. Vectors sit beside the relational records they came from, so existing database roles, backups and high availability can apply. Exact search is the default, and HNSW or IVFFlat approximate indexes are available, but indexed vector columns are limited to 2,000 dimensions. Filters apply after the index scan, so confirm that patient-level filters still return complete results. Check that your team can operate the extension at your volume.
Retrieval layer above the store
RAGFlow (Apache-2.0) or AnythingLLM (MIT) can sit above the vector store to handle ingestion, chunking and answers with citations. The retrieval layer often copies clinical text into its own database, cache and logs, which can widen the PHI footprint beyond the vector store. Before adoption, confirm where documents, chunks, chat history and uploads are stored, whether they can be encrypted and deleted per source record, and whether the layer supports per-user filtering that matches your clinical access rules.
Gateway that enforces model access
LiteLLM is MIT licensed except its enterprise directory, and it sits between applications and model providers to route calls, manage keys, set budgets and log requests. It is useful for keeping clinical prompts and retrieved passages on approved endpoints. Confirm which logging features you need are in the non-enterprise code, whether prompt and response logs can be redacted or disabled, and how the gateway's own logs are protected and retained.
Where the vector store runs for PHI, option by option
Your team installs and runs Qdrant in your own data center or cloud account, so the ePHI in vectors and payloads stays on infrastructure you control. Qdrant is Apache-2.0 licensed and free to self-host, but the license does not carry any HIPAA obligations, and the operating burden sits with you. By default, self-deployed Qdrant listens on all network interfaces with no authentication, so hardening is the first task, not an optional one.
- Storage: Qdrant needs block-level storage with a POSIX-compatible file system. It cannot run on NFS or S3-style object storage, and SSD or NVMe drives are recommended.
- Quorum: For production, the distributed deployment documentation recommends at least three nodes so quorum survives a node failure.
- Access control: Use TLS for REST and gRPC, admin and read-only API keys, and JWT-based per-collection permissions, then enable JSON audit logging of authenticated operations.
- Production path: Choose between the community Helm chart and the enterprise Kubernetes operator. The Helm chart lacks zero-downtime upgrades and automatic shard rebalancing.
- Owned controls: Your organization owns encryption, backup, key management, logging retention and access reviews, and it signs any business associate agreement with the cloud provider that hosts the nodes.
Confirm with your counsel and security team which hosting provider will sign a business associate agreement before any PHI is loaded.
Qdrant Hybrid Cloud runs managed Qdrant clusters on your own infrastructure, while Qdrant Private Cloud is a dedicated, fully isolated enterprise deployment. Both are priced through Qdrant sales, so the commercial relationship and the vendor's operating role shape the risk more than the software does. Your data still sits on your infrastructure, but part of the day-to-day operations moves to a vendor team with access to the environment.
- Operator role: Establish in writing which Qdrant staff can reach the cluster, the control plane or the logs, and how that access is granted, logged and revoked.
- Business associate agreement: Ask whether Qdrant will sign one and, if so, whether it covers subcontractors that touch ePHI and incident reporting to you.
- Block storage and nodes: The same block-storage requirement and three-node minimum for quorum apply to the clusters you host.
- Owned controls: Your organization still owns the underlying infrastructure, encryption keys, backups, network segmentation and access reviews for your own staff.
- Pricing terms: Quotes, support levels and uptime commitments come from the sales agreement, so have counsel review the contract before any PHI workload starts.
Request the vendor's written answers on operator access, subprocessors, breach notification and business associate terms before you compare quotes.
pgvector is a PostgreSQL extension under the PostgreSQL License, and it stores vectors in the same database as your relational data. If your organization already runs PostgreSQL with mature backup, access and monitoring controls, pgvector lets ePHI-derived vectors inherit those controls rather than adding a second data store. Its limits are the ones you must design around: supported PostgreSQL versions start at 13, and the approximate indexes cover vector columns of up to 2,000 dimensions.
- Inherited controls: Vectors use the existing roles, row-level security, encryption at rest, backup and point-in-time recovery already audited for the database.
- Filtering: With approximate indexes, filtering runs after the index is scanned, so confirm that iterative index scans return enough results for patient-scoped queries.
- Scale boundary: Plan the point at which vector load or query rate justifies a dedicated store, and document that decision.
- Version support: PostgreSQL ships a major version about once a year with five years of support each, so the upgrade path must include pgvector compatibility testing.
- Owned controls: Your database team owns access reviews, log retention, backup restore tests and deletion of vectors when source records change.
Confirm that the database hosting or managed service provider will sign a business associate agreement, since the vectors inherit that provider's obligations.
How a clinical vector deployment rolls out
The sequence moves from deciding what is in scope to proving that clinical vectors are protected, deletable and recoverable before any clinician uses the system. Each phase closes with a document or test result the organization keeps.
Scope record types, users and PHI status
Agree which source records, such as clinical notes, discharge summaries or imaging reports, feed the embedding pipeline, which teams will query it and which data is excluded. The organization's privacy officer and security lead classify each source and record a decision on whether the derived vectors are ePHI, treating them as ePHI unless counsel documents otherwise. The output is a signed data classification register and an in-scope data inventory that every later phase references.
Design the boundary and permission model
Define the network zone, hosting location and administrative paths for the vector store, then map identity integration so that users authenticate through the organization's existing identity provider with multi-factor authentication. Design one collection per data classification or care context, with read and write permissions assigned per collection and a named owner for each. The output is an architecture diagram, an access matrix and a list of the business associate or subprocessor terms that apply to any external party in the data path.
Build the cluster with hardened defaults
The engineering team installs the chosen engine on the organization's infrastructure and removes default-open settings before any data is loaded. This includes binding to the intended interfaces, enabling API keys or JWT-based access, enabling TLS for REST and gRPC, turning on audit logging and placing data on block storage rather than network file systems. Where high availability is required, the team deploys a three-node distributed cluster so quorum survives a node failure. The output is a configuration baseline, a hardening checklist with each setting verified, and a record of the versions deployed.
Wire the embedding and deletion pipeline
Connect the source record system to the embedding job so that every vector stores a pointer to its source record and version. When a note is amended, withdrawn or deleted in the source system, the pipeline removes or re-embeds the affected points and their payloads and logs the action. The team tests this with sample records to confirm that no orphaned vectors remain. The output is a pipeline runbook, a tested mapping between source identifiers and vector identifiers, and deletion logs that show each change was applied.
Test restores and verify deletion in backups
Take snapshots of the collections, restore them into an isolated environment running a matching version, and confirm that search results and permissions match production. Then run a deletion scenario: remove a source record, confirm the vector is gone from the live collection, and check whether the deleted content still exists in earlier snapshots or backups. The team sets a retention or purge procedure for backups that addresses any remaining copies. The output is a restore test report and a deletion-in-backup record that the organization can show to auditors.
Assess security and assemble the evidence pack
Run an independent security assessment of the deployed system, covering configuration, access control, API exposure, TLS and audit logging, and document each finding with its remediation and retest result. DeployOpen prepares the controls and evidence for your compliance assessment, but independent auditors and certification bodies issue any attestation. The output is an evidence pack containing the classification register, architecture, access matrix, configuration baseline, audit log samples, restore and deletion records and the assessment report. No clinical user is onboarded until the organization's security and privacy owners sign off on this pack.
Deleting vectors when source records change
A vector is derived from a clinical note or record, so it inherits the status of that source. When a record is amended, corrected or retired, the matching points and their payloads must be removed or re-embedded, or the assistant will keep answering from content the clinical record no longer supports. The control starts before any deletion happens: keep a mapping table between each source record identifier (the EHR document ID, version and date of last change) and the point IDs written to Qdrant, with the collection name and embedding model version stored alongside. Without that mapping, a correction in the source system cannot be traced to the vectors it produced, and the deletion cannot be proven later. Confirm with your clinical informatics and privacy teams which record events (amendment, correction, retraction, patient request under local law) trigger a delete and which trigger a re-embed.
Deletion should run through the Qdrant API with a service identity whose per-collection write permission is limited to the collections it maintains, so every removal is attributable to a known account. Qdrant's JSON audit logging of authenticated API operations, available since v1.17.0, should be enabled and shipped to the organization's log store, so each delete request has a timestamp, caller and target. Record the source ID, point IDs, request result and a re-query that confirms the points no longer return. Snapshots and backups are the part most teams miss: a snapshot taken before the deletion still holds the removed vectors and payloads until that snapshot expires or is destroyed. Ask your partner how backup retention and snapshot rotation are set for healthcare collections, and whether restores can re-introduce deleted records. Evidence should cover live data and backups together.
Re-embedding after an embedding model change is a separate event. It replaces vectors across a collection in bulk, so it needs its own change record: the old and new model identifiers, the date, the collection affected, the operator, and the counts of points written and removed. Keep that record apart from individual patient-level deletions so auditors can follow each path. Before going live, have the partner demonstrate a full chain on a test collection: amend a source record, delete the mapped points, show the audit entries, confirm the vectors are absent from live search, and then restore an older snapshot in an isolated environment to show how deleted content is handled. Check the HIPAA Security Rule requirements for audit controls and integrity with your compliance lead before you finalize the procedure.
What auditors and regulators ask to see, and which component produces it
This table maps the evidence a HIPAA assessor, HHS Office for Civil Rights reviewer or customer security team typically requests to the system component that generates it. Read each row as a question to answer with a record, and confirm the retention and storage location of each record in your own environment. HIPAA has no certification, so the goal is evidence that holds up when someone asks for it.
| Evidence | What it shows | Component that produces it |
|---|---|---|
| Access reviews of per-collection permissions | Which users, services and roles can read or write each collection of clinical embeddings, and when that was last reviewed | Qdrant JWT-based per-collection permissions and API keys, or pgvector roles and grants reviewed from the database catalog |
| Audit logs of authenticated operations | Who queried, inserted, updated or deleted vectors, from which identity and when | Qdrant JSON audit logging of authenticated API operations (v1.17.0 and later), plus PostgreSQL logs when pgvector is used |
| Encryption in transit | Client and inter-node traffic carrying ePHI uses TLS rather than plaintext | Qdrant TLS for REST and gRPC, or PostgreSQL SSL settings; confirm certificate management in your environment |
| Encryption at rest | Storage holding vectors and payloads is encrypted, including backups and snapshots | Volume or disk encryption on the block storage Qdrant requires, or database-level encryption; confirm the method per environment |
| Backup and restore test records | Backups exist, cover all collections, and a restore was tested and produced consistent data | Qdrant snapshots or PostgreSQL backup tooling, with restore test logs kept by your operations team |
| Deletion records tied to source changes | When a clinical record is amended or deleted, the linked vectors and payloads were removed and the removal was logged | Your embedding pipeline's delete job and the vector store's delete operations, with pipeline logs linking source record IDs to point IDs |
| Business associate agreements and subcontractor list | Every vendor or hosting party that handles ePHI is bound by terms that meet 45 CFR 164.314 requirements | Contract records held by your compliance team; list each embedding model host, cloud provider and implementation partner |
| Change records for upgrades | Each version change was planned, tested and approved, with the version in use recorded | Change tickets and deployment records; for example, Qdrant v1.19.2 (published October 5, 2026) as the version under review |
| Risk analysis | Threats to ePHI in the vector store were identified, rated and linked to controls and treatment decisions | Your organization's risk assessment, informed by NIST SP 800-66 Rev. 2; confirm scope includes embeddings and backups |
Questions to ask an implementation partner before a PHI build
Start by asking the partner to show, not describe, that no default-open interface remains. Qdrant's security documentation states that self-deployed instances listen on all network interfaces and have no authentication configured by default, so ask which bind addresses, API keys, TLS settings and per-collection JWT permissions are set in the delivered configuration, and ask for the file or Kubernetes manifest that carries them. Then ask how they will prove that a scan from outside the permitted network segments fails, and whether the JSON audit logging of authenticated API operations, available since v1.17.0, is enabled and forwarded to the organization's log store. Ask for a written scope that lists every component, port and account the build creates, and check that list against the access control and audit standards in the HIPAA Security Rule (45 CFR 164.312), which the organization must meet regardless of who builds the system.
Ask how the partner will show that a deleted vector is gone from snapshots and backups, not just from the live collection. Qdrant snapshots and any database backups can retain point payloads, so ask for the written procedure that expires or rebuilds them after a source record is amended or erased, the retention period for each backup tier, and the evidence the partner will hand over, such as a deletion record and a restore test that confirms the point is absent. On business associate terms, ask whether the partner will sign a business associate agreement that meets 45 CFR 164.314(a)(2)(i), flows the same terms down to every subcontractor that can reach ePHI, and commits to reporting security incidents. Ask for a list of subcontractors and cloud regions. Finally, ask the partner to restore a backup into an isolated environment during the engagement, demonstrate per-collection permissions and show the audit log entry for one sample access. Be clear about what the partner will not do: it will not issue a HIPAA certification, because none exists, and it will not sign the organization's compliance attestations or agreements on its behalf.
What health organizations ask before hiring help with a clinical vector store
What drives the cost of a clinical vector store implementation?
Scope drives most of the cost: how many record types are embedded, how many collections you need, how identity integration is built, how deletion is wired to source systems, and how much testing and evidence the assessors will expect. Each item adds design, build and verification work, and a fixed-scope quote follows from that written scope. Ask any partner to break the quote into these components so you can see which ones your own data and controls push up. DeployOpen does not publish a price list, so request a written scope and quote before comparing options.
Is the work one-time, or does it recur after go-live?
The build is one-time, but operating a clinical vector store is not. Upgrades, security patching, backup and restore testing, control evidence collection and retained support recur for as long as the store holds PHI. Qdrant documents rolling upgrade behavior differently across its production paths, so an upgrade plan is part of the recurring work. Ask a partner which items are included in the fixed-scope build, which are offered as an ongoing retainer, and what you must provide to keep the system current.
What does the healthcare organization need to provide?
The engagement depends on people from several teams. Data owners must identify which clinical notes and records feed the embedding pipeline and which must be excluded. The identity team must supply the directory integration and role definitions for per-collection access. Privacy and legal review must confirm the treatment of embeddings as PHI and the terms of any business associate contract. You also need a non-production test environment that mirrors the production controls, with a representative but de-identified data set for testing deletion and restores.
Can our own team build and run a clinical vector store alone?
A team can do it alone if it already has strong PostgreSQL or Kubernetes skills and is willing to document a control set before deployment. That includes TLS, authentication, per-collection permissions, audit logging, encryption, backup and restore, and a documented deletion process. The harder parts are usually the deletion pipeline tied to source record changes and the evidence package for assessors, since both require ongoing discipline. Be honest about on-call capacity, because a vector store that holds PHI needs someone accountable for it every day.
Is HIPAA certification available for a vector database?
No, there is no HIPAA certification. 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. The HHS Office for Civil Rights enforces the rule through complaints, compliance reviews and audits. Some organizations also pursue a HITRUST assessment as an additional assurance program, which is a separate decision. DeployOpen prepares systems, controls and evidence for assessments, but it does not issue audit reports, attestations or certifications.
Will DeployOpen sign a business associate agreement?
Whether a business associate agreement is needed depends on your role and on whether a partner's staff may access electronic protected health information. Under 45 CFR 164.314, a business associate 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. Confirm the requirement with your counsel, then review the partner's written terms and the scope of access before the engagement starts. Do not rely on a general statement of compliance as a substitute for the contract.
How is the timeline set for a healthcare vector store project?
Most engagements are fixed-scope, which means scope, deliverables and timelines are agreed in writing before work starts. The timeline follows from the record types, the number of collections, the identity integration, and the testing your assessors will require. Ask the partner to show the milestones, the review points for your privacy and security teams, and the conditions that would change the schedule. Avoid any plan that starts build work before the data classification and access model are signed off.
Should we choose Qdrant or pgvector for PHI-derived embeddings?
Choose on operational fit and control needs rather than on feature lists alone. pgvector runs inside PostgreSQL, so vectors share the database, backup and high availability processes you may already operate, and PostgreSQL releases a new major version about once a year. Qdrant offers per-collection JWT permissions and JSON audit logging of authenticated API operations, but it needs block storage, a multi-node design for production, and a separate operations skill set. If your team already runs PostgreSQL well and collections are modest, pgvector may fit. Test both against your filtering, deletion and restore requirements before deciding.
How DeployOpen scopes, builds and supports a clinical vector store
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, so clinical embeddings stay under the organization's control from the first pipeline run. Engagements are fixed-scope, with the scope, deliverables and timelines agreed in writing before work starts.
How we scope
- Inventory which clinical sources feed the embedding pipeline, including notes, records and attachments, and classify the derived vectors as PHI.
- Map collections to care teams and roles so access control reflects need-to-know rather than a single shared index.
- Agree in writing which controls, logs, backup rules and deletion procedures the engagement covers, and which items stay with the client.
How we build
- Deploy the chosen engine, such as Qdrant or pgvector, inside the client's own cloud account, data center or private network with TLS and authentication enabled.
- Configure per-collection permissions, audit logging of authenticated API operations and encrypted storage, then test that unauthorized reads and writes fail.
- Wire the embedding pipeline so each vector carries a reference to its source record, which makes later deletion traceable.
How we hand over
- Document the architecture, access model, key handling, backup and restore runbooks, and the source-to-vector deletion procedure.
- Provide evidence packs that show configuration, test results and log samples, prepared for the client's own assessors and auditors.
- Run restore and deletion tests with the client's operations team so the handover includes a rehearsed procedure, not only a document.
How we support
- Offer ongoing support, upgrades and continuous security testing as a retainer, scoped separately from the build.
- Review engine releases and patch versions against the client's change control process before applying them to clinical collections.
- Re-test access controls and deletion workflows after each material change, such as a new source system or a new embedding model.
Sources and further reading
- 45 CFR Part 164 Subpart C, Security Standards for the Protection of ePHI ↗
- Appendix A to Subpart C of Part 164, Security Standards: Matrix ↗
- HHS FAQ 2003: Are we required to certify our organization's compliance with the standards? ↗
- Introduction to the HITRUST CSF v11.7.0 ↗
- Qdrant security ↗
- pgvector on GitHub ↗
