Project / Health Data
Medical Privacy Guard
Redaction, audit, and approval before medical data leaves the machine.
Local-first de-identification and auditing for Chinese clinical text: detect direct identifiers, assess disclosure risk, transform, validate, and only then release.
Overview Project overview
Medical Privacy Guard is a local-first policy layer placed between medical data pipelines and external AI: it detects sensitive identifiers, assesses disclosure risk, de-identifies when transformable, validates the result, and emits an auditable decision before data leaves the machine.
Motivation Why it exists
Names, phone numbers, medical record numbers, institutions, and dates routinely co-occur in medical text. Rather than assigning blame after data has left, it turns “detect — transform — validate — release or withhold” into a fail-closed path at the boundary.
Architecture Key architecture
- Guard profiles determine policy; detectors cover direct identifiers in Chinese clinical text, and transforms support REMOVE, MASK, TOKENIZE, GENERALIZE, and DATE_SHIFT.
- Every SANITIZE validates before release; a failed validation withholds the payload.
- Audit events are chained by hashes with optional HMAC; ASK is handled through scoped, one-time, expirable authorizations.
- Provides OpenAI-compatible and Anthropic client wrappers plus an MCP stdio gateway; structured input supports JSON, CSV, and a minimal FHIR resource set.
- v0.6.0-rc.1 installs only the medical_privacy_guard namespace and adds a local serve gateway for OpenAI-compatible and Anthropic clients; it binds to loopback by default and does not inspect response content.
Capabilities Capabilities
- Detection of Chinese mobile and landline numbers, email, social accounts, national-ID candidates, dates, URLs, IPv4, patient/staff/relative names, medical record numbers, addresses, institutions/departments/wards, bed numbers, and ages.
- Structure-preserving JSON/CSV/FHIR de-identification; failed validations withhold; hash-chain audits and audit-verify.
- Read-only DICOM metadata scanning; the MCP gateway forwards, rewrites, or rejects tools/call per verdict.
- Synthetic-data benchmarks and pytest tests; unimplemented items are explicitly listed in code and docs.
- v0.5.0 adds local CLI/MCP approval files with signed review metadata, SQLite-backed grant consumption and revocation, and CSV/JSON batch token consistency; v0.6.0-rc.1 converges the public API and adds the zero-code local gateway.
Limitations Known limitations
- Does not certify HIPAA, GDPR, PIPL, or any institutional compliance, and does not replace legal review.
- Cannot prove complete anonymization; residual quasi-identifiers may still enable re-identification.
- Cannot defend against bypasses by an equally privileged party; it reduces accidental disclosure risk, not insider threats.
- XLSX, PDF/DOCX, multimodal content, and HTTP outbound proxies are not implemented; response content is not inspected.
- v0.6.0-rc.1 import paths are intentionally breaking; existing consumers must migrate. The local serve gateway binds to loopback by default.
Validation Testing & validation
- pytest covers unit and integration paths; the repository uses template-generated synthetic corpora, and strict scoring measures only internal consistency, not real-world generalization.
- docs/evaluation.md records strict evaluation and fault-injection evidence; docs/scope.md documents detection and adapter boundaries.
- Version status follows README and CHANGELOG: v0.5.0 is the stable approval/security line; v0.6.0-rc.1 is the current candidate with namespace convergence and the zero-code gateway.