Is Obsidian Safe for HIPAA Data? Understanding the Risks of Using Obsidian for Protected Health Information

Obsidian has earned genuine admiration among knowledge workers who take their tools seriously. Its local-first architecture - notes stored as plain markdown files on the user’s own device, not in any proprietary cloud - represents a principled position about data ownership that distinguishes it from nearly every major note application. Its plugin ecosystem is extensive. Its organizational model is flexible. Its community is thoughtful and technically sophisticated. Among researchers, therapists, consultants, writers, and professionals who want a powerful personal knowledge management system that does not require trusting a cloud service with their data, Obsidian has become the default recommendation.

This reputation is well-founded for general knowledge management. For healthcare professionals who handle protected health information, the question is different and the answer is more complicated.

Healthcare professionals who use Obsidian often arrive at it through the same reasoning that leads other knowledge workers to it: they want a local-first, private, genuinely capable knowledge management tool, and Obsidian fits that profile better than most alternatives. The additional step of asking whether Obsidian satisfies HIPAA’s specific compliance requirements - not just whether it is private and secure in a general sense, but whether it meets the regulatory framework that governs protected health information - does not always happen before the tool is adopted and PHI begins to flow into it.

This article provides that analysis. It examines what HIPAA compliance requires, where Obsidian’s architecture and design place it relative to those requirements, what the specific compliance gaps are, and what the consequences are for healthcare professionals who use Obsidian for PHI in configurations that do not satisfy HIPAA’s framework. It also describes what a genuinely compliant offline-first knowledge management approach looks like for healthcare professionals whose privacy requirements align with Obsidian’s design philosophy but whose compliance obligations require more than Obsidian currently provides.

Understanding the HIPAA Framework: More Than Encryption and Local Storage

The most common misunderstanding about HIPAA compliance among technology users is that it is primarily a security standard - that a tool satisfies HIPAA by being encrypted and private. This understanding captures part of the picture and misses the rest in ways that create specific compliance exposure.

HIPAA’s compliance framework has three distinct pillars: the Privacy Rule, the Security Rule, and the Breach Notification Rule. Each creates obligations that are distinct from simple technical security.

The Privacy Rule governs how PHI can be used and disclosed. It establishes patients’ rights with respect to their health information and specifies the conditions under which covered entities can share PHI with third parties. The mechanism through which covered entities satisfy the Privacy Rule for third-party vendors is the Business Associate Agreement - the contractual instrument that extends HIPAA obligations to vendors who handle PHI on the covered entity’s behalf.

The Security Rule specifies the administrative, physical, and technical safeguards that must protect electronic PHI. Administrative safeguards are organizational and process requirements: a documented security management process, workforce training, information access management policies, a contingency plan. Physical safeguards address the security of the physical environments where PHI is processed and stored. Technical safeguards specify access controls, audit controls, integrity controls, and transmission security.

The Breach Notification Rule establishes obligations when a breach of unsecured PHI occurs: notification to affected individuals, notification to the Secretary of HHS, and - for breaches affecting 500 or more individuals - notification to prominent media outlets in the affected geographic area.

None of these pillars reduces to “the data is encrypted and stored locally.” Each specifies requirements that encryption and local storage address partially but not completely. Understanding where Obsidian satisfies these requirements and where it falls short requires examining each pillar specifically.

The BAA Requirement and Obsidian’s Current Position

The Business Associate Agreement is the cornerstone compliance requirement for technology tools used with PHI. As of the writing of this article, Obsidian does not provide a BAA and does not market itself as HIPAA compliant. This is a factual statement, not a criticism - Obsidian is a personal knowledge management tool, not a healthcare compliance platform, and it makes no representation that it satisfies HIPAA requirements.

Obsidian’s official documentation is clear that data compliance is the user’s responsibility. The company’s position is that because notes are stored as local files on the user’s device, the user controls the data and therefore bears full compliance responsibility. This position is technically accurate within Obsidian’s local-only configuration - when notes stay on the device and no cloud services are used, Obsidian itself does not handle or transmit PHI.

The BAA question for Obsidian in local-only configuration is therefore nuanced in a way that differs from the Claude analysis. Claude is a cloud service that always processes user input on remote infrastructure, making it straightforwardly a business associate that requires a BAA. Obsidian in purely local configuration does not transmit data to Obsidian’s servers - the notes stay on the device, Obsidian’s company does not handle them, and the business associate relationship for Obsidian itself does not arise for local-only use.

This nuance is the source of both Obsidian’s appeal and its compliance complexity for healthcare professionals. The local-only configuration genuinely does not create a BAA requirement with Obsidian, because Obsidian’s systems do not handle the PHI. But the local-only configuration is only one of several ways Obsidian is used, and many of Obsidian’s most valuable features - sync across devices, publishing, and plugin integrations - move beyond the local-only configuration in ways that do create compliance exposure.

More importantly: the absence of a BAA requirement for Obsidian itself in local-only configuration does not mean that local Obsidian use with PHI automatically satisfies HIPAA. The BAA pillar is satisfied in local configuration. The Security Rule’s administrative, physical, and technical safeguards, the audit trail requirements, and the breach notification obligations still apply to the covered entity’s handling of PHI in their local Obsidian vault. Compliance is not satisfied by the BAA alone.

Local Storage: What It Satisfies and What It Leaves Unaddressed

Obsidian’s local-first architecture is a genuine privacy advantage for knowledge management. Notes stored as markdown files on a local device are not accessible to Obsidian’s servers, are not subject to cloud service breach incidents, and are not governed by Obsidian’s data handling practices. For users whose primary concern is keeping their personal knowledge out of cloud infrastructure, local Obsidian delivers on its promise.

For healthcare professionals whose concern is HIPAA compliance, local storage addresses some requirements and leaves others entirely unaddressed.

On the positive side: local storage eliminates the business associate relationship with Obsidian for the storage component, removes the cloud transmission exposure that cloud-based note applications create, and keeps PHI within the covered entity’s direct physical control. These are meaningful compliance properties.

On the unaddressed side: HIPAA’s technical safeguards apply to locally stored PHI as rigorously as to cloud-stored PHI. A markdown file containing PHI on an unencrypted drive satisfies none of the Security Rule’s technical safeguard requirements for that PHI. The technical safeguard requirements are: access controls that limit access to authorized users, audit controls that record activity in systems containing PHI, integrity controls that ensure PHI is not improperly altered, and transmission security for any PHI that is transmitted. These requirements do not disappear because the storage is local.

Device-level encryption is the most fundamental technical safeguard for locally stored PHI. Full-disk encryption on the device where Obsidian vaults containing PHI are stored - BitLocker on Windows, FileVault on macOS - ensures that someone who obtains the physical device cannot read its contents without the encryption key. Without full-disk encryption, a lost or stolen laptop containing an Obsidian vault with PHI constitutes a breach of unsecured PHI that triggers HIPAA’s breach notification obligations.

Application-level encryption adds a second layer - encryption of the vault itself, separate from the device encryption. Obsidian does not provide native vault encryption. The markdown files in an Obsidian vault are plaintext on the filesystem. If the device is accessed by anyone who can reach the filesystem - another user on a shared machine, someone who logs in with administrative credentials, a recovery tool used after a device malfunction - the Obsidian vault contents are readable without any authentication barrier within Obsidian itself.

This plaintext storage of what may be a healthcare professional’s most sensitive clinical notes is a specific technical gap that local-first storage alone does not address. Full-disk encryption at the device level is a mitigating control, but it is a control that the healthcare professional must implement separately from Obsidian - it is not provided by Obsidian - and its absence in many typical device configurations creates vulnerability that HIPAA’s technical safeguards require to be addressed.

Obsidian Sync and Publish: Cloud Features That Change the Compliance Equation

For healthcare professionals who use Obsidian with full awareness of the local-only compliance landscape and who maintain strict local-only use for any PHI-containing vaults, the analysis above describes their compliance challenge. For the larger population of Obsidian users who rely on Obsidian Sync for cross-device access or Obsidian Publish for sharing notes, the compliance picture changes significantly.

Obsidian Sync is one of Obsidian’s paid features and one of its most practically useful capabilities. It synchronizes vault content across multiple devices - phone, tablet, laptop, desktop - providing the cross-device accessibility that many knowledge workers need. Obsidian Sync uses end-to-end encryption for data in transit and at rest on Obsidian’s servers, which is a meaningful security implementation.

But security and compliance are not the same thing, and Obsidian Sync creates compliance exposure that its encryption does not resolve. When vault content is synchronized through Obsidian Sync, that content passes through and is stored on Obsidian’s cloud infrastructure. Obsidian’s servers hold encrypted copies of the vault content. Even with end-to-end encryption - where Obsidian’s servers hold only encrypted content that Obsidian cannot decrypt - the data residency on Obsidian’s infrastructure creates a compliance relationship.

For PHI in a vault synchronized through Obsidian Sync, Obsidian is handling PHI on behalf of the covered entity - which makes Obsidian a business associate for that PHI. The BAA requirement applies. Obsidian does not provide a BAA. The use of Obsidian Sync for PHI-containing vaults is therefore a HIPAA violation regardless of the encryption quality of the Sync implementation.

Obsidian Publish creates a different but equally clear compliance exposure. Publish allows users to publish their notes as websites, making selected vault content accessible on the web. Publishing content that contains PHI is an unauthorized disclosure of PHI to the public - a clear and serious HIPAA violation. The encryption discussion is not relevant to Publish because the intended purpose is to make content accessible to external parties without credentials.

Even publishing content that has been carefully de-identified before publication requires verification that the de-identification is complete according to HIPAA’s Safe Harbor standard. Publishing notes from a clinical practice about general clinical topics - without any PHI - does not create a compliance concern. Publishing notes that contain any identifying information about patients, or that could be combined with other information to identify patients, is a PHI disclosure.

Healthcare professionals who use Obsidian should maintain strict vault separation for any PHI-containing vaults - keeping them completely isolated from Sync and Publish, maintaining them on devices with full-disk encryption, and treating them with the full technical safeguard discipline that local PHI storage requires.

The Plugin Ecosystem: A Compliance Wild Card

Obsidian’s plugin ecosystem is one of its most celebrated features and, for healthcare compliance purposes, one of its most significant risk factors. The extensibility that allows Obsidian to be customized for almost any workflow also creates potential pathways for PHI exposure that the base application’s local-first design does not create.

The plugin ecosystem includes thousands of community-developed plugins that add capabilities ranging from calendar integration and spaced repetition to database management and API connectivity. These plugins can access vault content, modify files, and in many cases transmit data to external services.

The compliance concern is not theoretical. A plugin that backs up vault content to a cloud storage service - even a popular, reputable one - creates the same PHI cloud exposure that Obsidian Sync creates, but potentially without the encryption quality that Obsidian Sync implements. A plugin that sends vault content to an AI service for processing creates PHI exposure to the AI service. A plugin that integrates with a task management or productivity application may transmit note excerpts or titles to that application’s servers.

HIPAA requires that all software components interacting with PHI be properly secured and monitored. The Security Rule’s administrative safeguard requirements include a risk assessment that identifies the specific risks to PHI in the covered entity’s environment. An honest risk assessment for an Obsidian vault used for PHI must evaluate every plugin installed in that vault for potential PHI exposure.

The community-maintained nature of Obsidian’s plugin ecosystem means there is no standardized security review process for plugins. A plugin that accesses vault content has access to all vault content, including any PHI. The plugin author may not be aware of HIPAA compliance requirements. The plugin may transmit data to external services without making that transmission visible to the user. The plugin may have security vulnerabilities that create exposure pathways that neither the author nor the user has identified.

For healthcare professionals using Obsidian for PHI, the practical implication is that every plugin installed in a PHI-containing vault requires individual compliance evaluation: what data does this plugin access, where does it transmit data, does the service it transmits to have a BAA in place, and has the plugin been evaluated for security vulnerabilities? This evaluation is not a one-time exercise - plugins are updated, their data handling practices can change, and new plugins added to the vault require fresh evaluation.

The compliance burden created by the plugin ecosystem is a meaningful real-world cost of using Obsidian for PHI. It is not an argument against Obsidian for general use, where the plugin ecosystem’s flexibility is an unambiguous benefit. It is an argument for careful architecture when PHI is involved - potentially including maintaining a completely plugin-free vault for PHI-containing notes, separated from the richly-pluginned vault used for general knowledge work.

Audit Trails: The Gap That Cannot Be Patched

HIPAA’s audit control requirement specifies that covered entities must implement hardware, software, or procedural mechanisms that record and examine activity in information systems that contain or use electronic PHI. This requirement exists because HIPAA’s enforcement framework is evidence-based - covered entities must be able to demonstrate that PHI was handled appropriately, and demonstration requires records.

Obsidian does not provide built-in audit logging. There is no native mechanism that records who accessed a vault, what notes were opened or modified, when those actions occurred, or whether any content was exported or transmitted. The markdown files themselves carry modification timestamps that the filesystem maintains, but these are not HIPAA audit logs - they do not record user identity, they do not record access attempts that did not result in modification, and they can be altered without any tamper-evidence mechanism.

Community plugins provide version control and file change tracking capabilities that offer partial mitigation. Plugins that integrate with Git or maintain their own change history can track when files were modified. But these plugins do not satisfy HIPAA’s audit trail requirements for several reasons: they typically do not record user identity with the access event, they are not tamper-resistant, they do not capture access events that do not result in file modification, and their operation is dependent on the plugin continuing to function correctly - a dependency that creates brittleness in the audit record.

For a healthcare professional who needs to respond to a compliance investigation, a patient request for an accounting of disclosures, or an internal security incident requiring forensic analysis, the absence of robust audit logging in Obsidian creates a fundamental accountability gap. The question “who accessed this patient’s notes, and when?” cannot be answered from Obsidian’s native record. The question “was this note modified without authorization, and by whom?” cannot be answered.

This gap is not addressable through user discipline or careful practice. Audit logs must be generated by the system processing PHI at the time of access. There is no way to reconstruct access records after the fact for events that were not logged as they occurred. A healthcare organization whose PHI vault lacks audit logging has a permanent gap in its compliance documentation for every access event that occurred without a log.

For healthcare professionals using Obsidian for general clinical note-keeping, this gap means that the compliance documentation their HIPAA obligations require is not being generated. If a compliance question arises, the absence of audit records is itself a compliance failure - separate from whatever the underlying question may be.

Administrative Safeguards: The Organizational Compliance Work That Obsidian Cannot Do

The Security Rule’s administrative safeguard requirements address the organizational dimension of HIPAA compliance - the policies, procedures, training, and governance processes that create a compliance culture rather than just a compliance technology stack. These requirements apply to any covered entity that handles PHI, regardless of the technical tools used.

The security management process standard requires covered entities to implement a security management process that includes a risk assessment, a risk management plan, and a sanction policy for workforce members who fail to comply with security policies. For a healthcare professional using Obsidian for PHI, the security management process requires a formal risk assessment that identifies the specific risks that Obsidian’s architecture creates for their PHI - the plaintext storage risk, the plugin ecosystem risk, the audit trail gap - and a risk management plan that addresses each identified risk with specific mitigation measures.

The workforce security standard requires covered entities to implement policies and procedures to ensure that workforce members have appropriate access to PHI. For a solo practitioner using Obsidian, this may seem straightforward - they are the only workforce member. But practices with staff or administrative support have obligations to document who has access to which clinical information systems and to ensure that access is limited to what each role requires.

The information access management standard requires covered entities to implement policies governing access authorization. For Obsidian specifically, this requires specifying who is authorized to access each vault, under what circumstances, and through what authentication mechanism - documentation that must be maintained even for a locally-held vault.

The security awareness and training standard requires covered entities to train workforce members on security policies and procedures. For practices with clinical staff who use Obsidian for documentation, this requires training on the specific compliance requirements that apply to Obsidian use: the separation of PHI-containing vaults from Sync and Publish, the plugin evaluation requirements, the device encryption requirements, and the incident reporting procedures if a potential breach is suspected.

The contingency plan standard requires covered entities to develop and maintain plans for responding to emergencies that could damage systems containing PHI. For Obsidian vaults, this requires a backup strategy that satisfies HIPAA’s data availability requirements while maintaining the security controls that protect PHI - a backup to an encrypted drive, to a HIPAA-compliant backup service with a BAA, or through another mechanism that preserves the privacy of backed-up PHI.

None of these administrative safeguard requirements are satisfied by choosing Obsidian as a note-taking tool. They are organizational obligations that the covered entity must address through policy, documentation, training, and governance - work that Obsidian neither does nor claims to do.

The Specific Breach Risk: When a Lost Device Becomes a HIPAA Incident

The most concrete illustration of the compliance risk from locally stored PHI without adequate technical safeguards is the lost device scenario - which, for healthcare professionals who work across multiple devices and carry devices to and from clinical settings, is not a remote hypothetical.

A laptop containing an Obsidian vault with clinical notes is left in a rideshare vehicle. The laptop does not have full-disk encryption. The vault does not have application-level encryption. Anyone who can access the laptop’s filesystem can read the clinical notes in plaintext.

Under HIPAA, this is a breach of unsecured PHI. The breach requires notification to each patient whose PHI was in the vault - potentially hundreds of notifications depending on the size of the practice. If the number of affected individuals exceeds 500, notification to the Secretary of HHS and to prominent media outlets in the affected area is required. The notification must be sent within 60 days of the discovery of the breach.

The covered entity must also conduct a breach investigation and document its findings. The investigation must determine the scope of the breach - which patients were affected, what PHI was involved, what the likelihood is that the PHI was acquired or viewed by an unauthorized person. The investigation documentation must be maintained for six years.

A covered entity that had full-disk encryption on the device would likely be able to treat the lost device as an incident that did not constitute a reportable breach - because the PHI on the encrypted device would not be accessible to an unauthorized person who found the device. The encryption itself is the safeguard that makes the PHI “secured” in HIPAA’s terminology, and secured PHI that is lost on an encrypted device does not trigger the notification requirement.

This is the practical operational importance of full-disk encryption for healthcare professionals using Obsidian locally. It is not just a general security best practice - it is the specific technical safeguard that determines whether a lost device is a notification event or not.

For healthcare professionals who have been using Obsidian on unencrypted devices for clinical notes, the risk that has been created is retrospective as well as prospective. If any of those devices were lost, stolen, or disposed of without secure erasure, an unreported breach may have already occurred. The compliance exposure from historical use of unencrypted local storage for PHI may be significant.

What a Compliant Offline-First Clinical Documentation Approach Looks Like

The compliance analysis of Obsidian for PHI is not an argument against local-first, private clinical knowledge management. It is an argument for understanding what genuinely satisfies HIPAA’s requirements for local-first PHI storage - and what needs to be added to an Obsidian-based approach to bring it into compliance.

For healthcare professionals who want the privacy and data sovereignty of local-first note management and who want their tool choice to satisfy HIPAA’s requirements, the relevant questions are: does the tool provide encryption that satisfies HIPAA’s technical safeguards for locally stored PHI? Does it provide audit logging that satisfies HIPAA’s audit control requirements? Does it operate without creating cloud exposure that requires BAA coverage? And is the architecture verifiable, so that the privacy claims can be confirmed rather than accepted on trust?

VaultBook is built to answer these questions affirmatively. Where Obsidian stores notes as plaintext markdown files with no native encryption, VaultBook applies AES-256-GCM encryption to vault content - the same encryption standard used by financial institutions and security-critical software worldwide, implemented with locally derived keys that exist only in the user’s memory and active browser session. There is no plaintext exposure of PHI on the filesystem. There is no encryption key stored anywhere that a third party could access.

Where Obsidian lacks native audit trail capabilities, VaultBook maintains version history for every note - a complete record of every edit, timestamped and locally held, that provides the documentation of note content history that compliance-conscious clinical documentation requires.

Where Obsidian’s plugin ecosystem creates potential PHI exposure pathways through third-party code that accesses vault content, VaultBook’s architecture makes zero network requests under any circumstances. Not reduced network requests. Not network requests only for authorized functions. Zero network requests for any purpose during any operation. A healthcare professional who opens VaultBook’s developer tools and watches the Network tab during an extended session sees nothing - no requests, no data transmission, no external contact of any kind.

This verifiability is not incidental. For healthcare professionals who need to be able to represent to compliance reviewers, patients, or regulators that their clinical documentation tool creates no external data exposure, VaultBook’s zero-network architecture provides that representation with technical evidence rather than vendor assurance.

The Data Lifecycle Dimension: Retention and Disposal of Clinical PHI

HIPAA’s requirements extend through the full lifecycle of PHI - from creation through use to retention and ultimately to disposal. The disposal requirement is specifically addressed by the Security Rule, which requires that covered entities implement policies and procedures to address the final disposition of electronic PHI and the hardware or electronic media on which it is stored.

Obsidian’s plaintext file storage creates specific challenges at the disposal stage of the PHI lifecycle. Deleting markdown files that contain PHI from a local drive does not necessarily render the PHI unrecoverable - standard file deletion marks the space as available but does not overwrite the data, which may be recoverable using file recovery tools. Secure deletion requires either overwriting the file contents before deletion or using secure erase utilities that prevent recovery.

For healthcare professionals who transition between devices, who replace storage media, or who retire old devices, the secure disposal of PHI in Obsidian vaults requires specific technical actions beyond simply deleting the vault folder - actions that most users are not taking because the compliance requirement to take them is not well understood.

VaultBook’s encrypted storage model changes the disposal calculus. PHI that is encrypted with AES-256-GCM using a locally derived key is effectively unreadable without the key. When an encrypted VaultBook vault is deleted, the encrypted data that remains is not accessible without the encryption key - which exists only in the user’s memory and temporary session. The disposal obligation for encrypted data is substantially less demanding than for plaintext data, because the encryption itself provides the protection that secure erasure would otherwise need to provide.

The data lifecycle controls built into VaultBook extend this dimension further. Expiry dates on specific entries flag content for removal when its retention purpose is complete. The 60-day purge policy ensures permanent removal of expired and deleted content from the vault. For healthcare professionals managing clinical records with specific retention schedules - notes that must be retained for defined minimum periods and then disposed of - these controls provide active retention management rather than passive accumulation.

Building a HIPAA-Conscious Clinical Documentation Practice

For healthcare professionals who currently use Obsidian for clinical documentation and are recognizing compliance gaps in that practice, the path forward involves both immediate risk mitigation and longer-term architectural decisions.

Immediate risk mitigation should begin with device encryption. Every device that contains an Obsidian vault with PHI should be verified to have full-disk encryption enabled and functioning. This is the single most important technical control for local PHI storage, and its absence makes a lost device a notification event rather than an inconvenience.

Plugin audit is the second immediate priority. Every plugin installed in vaults that contain PHI should be reviewed for external data transmission. Plugins that transmit data to external services - backup services, AI tools, productivity integrations - should be disabled for PHI-containing vaults. The plugin audit should be documented, with the rationale for each plugin’s approval or removal recorded for compliance purposes.

Vault segregation formalizes the separation between PHI-containing and non-PHI vaults. A PHI-containing vault should be a separate, dedicated vault - not a section of a general knowledge management vault - maintained on a device with full-disk encryption, with no Sync or Publish configuration, and with only plugins that have been evaluated for PHI safety.

For longer-term architectural decisions, healthcare professionals should evaluate whether Obsidian in a carefully managed local-only configuration is the best available tool for their clinical documentation needs, or whether a tool purpose-designed for the compliance requirements of clinical PHI management provides a better foundation. The compliance work required to use Obsidian for PHI - device encryption, plugin auditing, vault segregation, manual audit trail supplements, secure disposal practices - is not trivial, and it recreates through effort much of what a purpose-designed compliant tool provides by architecture.

VaultBook’s design eliminates most of this compliance overhead by building the relevant technical properties into the application architecture. The encryption, the zero-network operation, the version history, the data lifecycle controls - these are architectural properties of VaultBook, not configurations that require separate implementation and ongoing management. For healthcare professionals whose compliance discipline is the limiting factor in their PHI management practice, a tool that satisfies the technical safeguard requirements by design rather than by configuration provides a more reliable compliance foundation.

Obsidian’s Strengths and the Right Use Context

Nothing in this compliance analysis diminishes Obsidian’s genuine strengths for the uses it was designed for. Its local-first architecture is principled and effective for general knowledge management. Its plain text format provides long-term portability that proprietary formats cannot match. Its plugin ecosystem provides customization depth that no other knowledge management tool currently approaches. Its organizational model - bidirectional linking, graph view, flexible hierarchies - provides knowledge connection capabilities that many researchers and writers find genuinely transformative.

For healthcare professionals who use Obsidian for non-PHI knowledge management - clinical literature organization, research notes, professional development documentation, personal knowledge management that does not involve patient information - these strengths are available without the compliance concerns that PHI introduces. The compliance analysis applies specifically to PHI, not to all clinical professional use of Obsidian.

The clear recommendation that emerges from the analysis is vault separation by compliance class: a general knowledge management vault in Obsidian, taking full advantage of its plugin ecosystem, sync capabilities, and organizational flexibility for non-PHI content, and a separate, purpose-designed compliant vault for clinical PHI. The two vaults serve different needs with different compliance profiles, and maintaining their separation preserves the benefits of each without requiring either to satisfy the requirements of the other.

For the PHI layer - the clinical notes, treatment documentation, assessment records, and sensitive correspondence that require HIPAA’s full technical safeguard compliance - a purpose-designed tool like VaultBook that provides encryption, zero-network operation, version history, and data lifecycle controls by architecture is the appropriate foundation. Not as a replacement for Obsidian’s general knowledge management strengths, but as the right tool for the specific compliance requirements of PHI management.

The goal is a documentation practice that is both capable and compliant - that uses the best available tool for each category of work and ensures that the most sensitive content receives the most appropriate protection. For clinical PHI, appropriate protection means technical safeguards that satisfy HIPAA’s requirements, implemented by architecture rather than dependent on user discipline alone. That is the standard that patient trust in the clinical relationship deserves - and the standard that a purpose-designed compliant tool provides from the first note forward.