I shipped bh-fastapi-audit v0.1 on January 14th. It was a FastAPI middleware that emitted audit events. It had a memory sink for testing, a JSONL sink for local dev, and a SQLAlchemy sink for anyone brave enough to use it in production. It worked. It was small. I wasn't sure anyone would care.

Today, both bh-fastapi-audit and bh-audit-logger hit v1.0.

Three months. Seven releases each. And the packages look nothing like where they started.

Why this exists

I work in behavioral health tech. The data we handle is therapy notes, substance use records, crisis interventions. Audit logging for this kind of data is either nonexistent, inconsistent, or locked behind compliance platforms that small organizations can't afford.

I've now run into this problem in three different healthcare roles. Every time, the team reinvented some version of "good enough" audit trails. Different schemas, different assumptions, different gaps. Nobody had time to do it right because the business needed features, not infrastructure.

So I built the thing I wish existed when I started.

What v1.0 actually includes

The audit schema (bh-audit-schema v1.1) defines what a behavioral health audit event should look like. It maps directly to HIPAA Security Rule sections, SOC 2 Trust Services Criteria, and 42 CFR Part 2. That's the foundation everything else builds on.

bh-fastapi-audit is the middleware. Pure ASGI, non-blocking async emission, runtime schema validation with three failure modes depending on how strict your team wants to be. Access denial tracking that distinguishes "the system broke" from "the user wasn't authorized," which matters for HIPAA access review reports. Schema version negotiation so teams running v1.0 schemas can upgrade to v1.1 at their own pace.

bh-audit-logger is the same feature set without the FastAPI dependency. Built for Lambdas, workers, data pipelines, background jobs. Zero core dependencies. If it runs Python, it can emit compliant audit events.

Both packages ship with DynamoDB sinks designed for healthcare compliance queries. Single-table design with GSIs for patient access review, actor activity review, and access denial monitoring. Those aren't random index choices. They map to specific HIPAA sections that auditors actually ask about.

And both now support SHA-256 chain hashing for tamper-evident audit trails. Every event gets an integrity block linking it to the previous event. A verifier CLI (bh-audit verify) can validate the chain against a JSONL file or a DynamoDB table. If someone modifies or deletes an audit record, the chain breaks and the verifier catches it.

What I learned building this

Infrastructure projects are hard to measure. Nobody tweets about audit middleware. The download numbers are modest. But 306 monthly installs on a package that processes PHI in healthcare systems means something different than 306 installs on a React component library. The context matters.

The hardest part wasn't the engineering. It was scoping. Every version, I had to decide what was essential and what was optimization masquerading as progress. v0.3 could have been v0.5 if I'd let scope creep win. The frozen configs, the bounded async queues, the pure ASGI rewrite—those were all "do it now or pay for it later" decisions that I'm glad I made early.

The compliance mapping work was unexpectedly important. Listing specific HIPAA sections in the documentation transformed the project from "a Python logging library" into "an engineering implementation of federal healthcare compliance requirements." Same code. Different framing. And the framing is accurate, which is what makes it work.

What's next

as v1.0 means the API surface is stable. I'm not going to break it. Teams can adopt without worrying about chasing breaking changes every month.

The next step is integrating both packages into production at the organization where I lead technology. That integration will generate real deployment metrics: events processed per day, chain verification results, DynamoDB query patterns under real clinical load. Those numbers will feed back into the documentation and inform what v1.1 looks like.

Everything is on PyPI. Everything is Apache 2.0. 

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

The bh-healthcare GitHub org has the source, the schemas, the compliance mappings, and the documentation.

If you're building in healthcare and dealing with audit compliance, I would genuinely love to compare notes.