I started this year mulling over the same problem I've now run into, and partially solved, in three different healthcare roles.

Behavioral health systems handle some of the most sensitive data in healthcare. Therapy notes, substance use records, crisis interventions. Yet audit logging is often inconsistent, ad hoc, or treated as an afterthought until an auditor asks uncomfortable questions.

Each time, teams ended up reinventing their own version of "good enough" audit trails. Different schemas, different assumptions, different gaps.

So I decided to step back and start from first principles. What should a behavioral health audit event actually look like?

The Problem

Audit logging in behavioral health is either nonexistent, inconsistent, or locked behind compliance platforms that cost $500/month or more. Small and mid-sized BH organizations get the worst of it because they need it the most and can afford it the least.

The tools that do exist weren't designed for behavioral health workflows. They don't account for 42 CFR Part 2 (the federal regulation protecting substance use records, which is stricter than standard HIPAA). They don't distinguish between "the system failed" and "the user wasn't authorized," which is a distinction that HIPAA access review reports actually require. And they're not built with the assumption that the data flowing through them is about someone's worst day.

What I Built

The bh-healthcare organization now has four projects, all open source under Apache 2.0.

bh-audit-schema is the foundation. A canonical, versioned audit event standard with compliance mappings to seven HIPAA Security Rule sections, four SOC 2 Trust Services Criteria, and two 42 CFR Part 2 sections. It defines what an audit event should look like in behavioral health.

bh-fastapi-audit is a pure ASGI middleware that emits PHI-safe audit events from FastAPI applications. Non-blocking async emission, runtime schema validation, configurable access denial tracking, and schema version negotiation for teams upgrading at their own pace. On PyPI.

bh-audit-logger is the framework-agnostic version. Same feature set, designed for Lambdas, workers, data pipelines, and anything that isn't a web framework. Zero core dependencies. Also on PyPI.

bh-sentinel is the newest. A multi-layer NLP pipeline for detecting clinical safety signals in unstructured behavioral health text. Pattern matching, transformer inference, emotion analysis, and a rules engine. 37 clinical flags across 6 domains mapped to C-SSRS. Text in, flags out, clinician decides.

Why Open Source

This is intentionally boring infrastructure. No compliance theater. Just a clean way to answer basic but critical questions like who accessed what, when, and why, without putting sensitive data at risk.

The goal is not to replace security teams or legal guidance. It is to lower the baseline so that both small and large teams building real healthcare systems don't have to reinvent audit logging from scratch every time.

Everything is installable today: 

pip install bh-fastapi-audit
pip install bh-audit-logger

If you are building in behavioral health, or healthcare more broadly, and care about auditability without leaking sensitive data, I would genuinely value your perspective. Find me on LinkedIn or through the bh-healthcare GitHub org.