tom/HealthLog

0 Fork 0

mirror of https://github.com/MBombeck/HealthLog.git synced 2026-11-08 20:42:43 +00:00

Files

T

Marc-André Bombeck e3342dc19e fix(documents): encrypt staged extracted-fact PHI at rest

The inbound-document store encrypts the raw upload
(`inbound_documents.content_encrypted`) because it is sensitive clinical
data, but the per-fact staging columns persisted the same class of data in
the clear: `extracted_facts.data_json` held the transcribed clinical values
(diagnosis text, lab values, medication names, stated codes) and
`provenance_json` held the verbatim source span (up to 2000 chars copied
straight out of the report). The at-rest guarantee was defeated for staged
facts, which persist through PENDING and are retained after the decision.

Convert both columns to the AES-256-GCM `*_encrypted` BYTEA convention shared
with the note columns, going through the same Bytes codec. The upload and
fact-edit paths encrypt on write; the confirm path decrypts at commit time to
write into the normal structured stores, so the review-then-confirm flow is
unchanged. Reads are fail-closed (a bad key id throws).

Register both columns in the encrypted-columns registry and the key-rotation
script so a dropped legacy key cannot strand them (the guard test enforces
both). Migration 0220 swaps the plaintext JSONB columns for the encrypted
BYTEA columns; pre-confirm staged rows are ephemeral and cannot be
re-encrypted in SQL, so any left by a pre-release build are dropped rather
than retained as plaintext (their parent document keeps its encrypted
original).

2026-06-28 18:12:51 +02:00

migrations

fix(documents): encrypt staged extracted-fact PHI at rest

2026-06-28 18:12:51 +02:00

README.md

docs: add navigational READMEs to key code directories

2026-06-05 15:26:34 +02:00

schema.prisma

fix(documents): encrypt staged extracted-fact PHI at rest

2026-06-28 18:12:51 +02:00

README.md

`prisma/`

The database layer. HealthLog runs PostgreSQL 16 via Prisma 7. This directory holds the single schema file and the forward-only migration history; the generated client is emitted elsewhere.

schema.prisma — 61 models, one file. cuid() primary keys, snake_case columns via @map(...), encrypted columns mostly suffixed *Encrypted (search the file; there are 24 encrypted column references). The generator client block emits to ../src/generated/prisma (imported as @/generated/prisma).
migrations/ — numbered, forward-only SQL migrations (0001_… upward). migration_lock.toml pins the provider to postgresql.

Migration workflow

# author a migration from a schema edit
pnpm dlx prisma migrate dev --name <short_snake_case_name>

# regenerate the client after any schema change
pnpm dlx prisma generate

Number a new migration with the next free prefix. The production entrypoint runs prisma migrate deploy on boot, so every migration must apply cleanly forward — there is no down-migration path. Always include the migration file in the same change as the schema edit.

Conventions

Encryption is fail-closed: *Encrypted columns are written through @/lib/crypto (AES-256-GCM, versioned key ids); never store plaintext in an encrypted column. Key rotation is scripts/rotate-encryption-key.ts + docs/ops/encryption-key-rotation.md.
The generated client under src/generated/prisma is build output — do not edit it.
Schema-touching changes that affect the API surface must regenerate docs/api/openapi.yaml (see ../CLAUDE.md).

Related: ../src/lib/README.md (db.ts, rollups/), ../docs/ops/ (migrations + backup runbooks).

README.md

prisma/

Contents

Migration workflow

Conventions

`prisma/`