Apeirion

A clinical-data ingestion platform built around strict PII/PHI separation — encrypted identifiers, opaque patient references, and a human-in-the-loop review queue before anything is trusted.

Source

Started this summer as a from-scratch exercise in the architecture pattern that matters most in health-tech: never let identifying information and clinical data share a table, and never trust a document until a human has looked at what got extracted from it.

A FastAPI service validates every extracted document against a Pydantic schema with `extra="forbid"` and clinical sanity checks before ingestion, then writes it through SQLAlchemy 2.0 models with idempotent, blind-index deduplication so the same report can't be ingested twice under a different filename. Anything the extractor is unsure about lands in a human-in-the-loop review queue instead of the datastore, and every write passes through audit middleware that logs who touched what.

Two commits, four days apart, and then paused mid-sprint — it's an active build, not a finished product, and it's here because the schema design and the encryption boundary are worth showing even before there's a UI in front of them.

What it does

Fernet field-level encryption on all PII, with blind-index columns for lookup without decryption
Strict PII/PHI table separation — patients only ever referenced by opaque UUID elsewhere
Idempotent ingestion with blind-index dedup so re-uploads can't duplicate a record
Human-in-the-loop review queue for anything the extractor flags as uncertain
Audit middleware logging every write against the datastore
Alembic migrations, docker-compose, and a written PII/PHI security model in docs/SECURITY.md

What it taught me

Designing a schema around a hard privacy boundary instead of bolting encryption on after
Making ingestion idempotent so a retried or duplicated upload can't corrupt state
Writing an audit trail as a first-class part of the data model, not a logging afterthought