PHI, privacy, and secure coding in regulated systems

What changes about ordinary backend engineering when the data is medical. The technical controls are mostly things you should do anyway; what changes is that they become obligations you must be able to evidence.

The regimes you will be asked about

The practical HIPAA point for an engineer: any third party processing PHI on your behalf — cloud provider, LLM API, log aggregator, error tracker — needs a Business Associate Agreement. That single fact rules out a surprising number of default tool choices, and naming it is a strong signal that you have worked in this space.

De-identification

HIPAA gives two routes, and knowing both by name is worth a lot:

• Safe Harbor — remove 18 enumerated identifiers (names, geography finer than state, all dates more precise than year, contact details, record numbers, biometrics, and so on). Mechanical, defensible, and it destroys a lot of analytical value — full dates are usually the loss that hurts.
• Expert Determination — a qualified statistician certifies the re-identification risk is very small. More flexible, lets you keep more granularity, and requires an actual expert.

Neither makes data safe by itself. Re-identification through linkage is real: a handful of quasi-identifiers (age, sex, postcode, admission date) uniquely identifies most people in a population. Anything you release externally needs k-anonymity or differential privacy thinking, not just field removal. See ../../ai_ml/14_guardrails_safety/03_pii_privacy_and_compliance.md.

Technical controls that actually get checked

Encryption. TLS 1.3 in transit including between internal services; encryption at rest with managed keys (KMS, Key Vault) and documented rotation. Encrypted disks are the floor, not the answer — application-level or column-level encryption for the most sensitive fields.

Access control. Role-based, least privilege, and enforced server-side per request rather than by hiding UI. Break-glass access for emergencies exists in healthcare and must be logged and reviewed, not silently permitted.

Audit logging. Who accessed which patient record, when, and why. This is a functional requirement in healthcare, not an observability nice-to-have: append-only, tamper-evident, retained for years, and queryable when someone asks whether a specific employee viewed a specific record.

Data minimisation. Do not select columns you do not need, do not copy production PHI into staging, and do not put identifiers in URLs where they land in access logs and browser history.

Logging discipline. This is the one engineers get wrong most often. logger.info(f"processing {patient}") puts PHI in your log aggregator, which is now a system holding PHI, with its own retention and BAA implications. Log identifiers, not payloads; redact by default and allow-list what may be logged.

Secure coding, the OWASP layer

Nothing exotic, but in a regulated environment these are auditable requirements rather than good practice:

• Parameterised queries everywhere — see ../25_security/02_sql_injection.md
• Validation at the boundary with Pydantic, and rejection of unexpected fields on internal APIs
• Authentication and authorisation checked per request, including on every internal service
• Dependency scanning and an SBOM, with a documented response time for critical CVEs
• Secrets from a secret manager, never in code or environment files in the repo — see ../../system_design/04_secrets_config/01_secrets_and_configuration.md
• Static analysis in CI (bandit, ruff’s security rules, pip-audit) with failures blocking the merge

The regulated difference is evidence. It is not enough that scanning happens; you need the pipeline record showing it ran on the commit that shipped.

LLMs on clinical data

Directly relevant to the RAG/clinical-intelligence role, and a place candidates get caught out:

• Sending PHI to a model API requires a BAA with that provider, and confirmation that data is not retained or used for training. Check this before designing around a provider.
• Prefer de-identification before the call where the task allows it, and re-identify locally afterwards.
• Self-hosted or in-VPC inference (Bedrock in your account, or an open-weights model) is the answer when the data cannot leave.
• Log prompts and completions carefully — a prompt containing a patient record turns your LLM observability stack into a PHI system.
• Ground and cite. For clinical use, an answer without a source is not usable. Retrieval with citations back to the source document is a requirement, not a feature. See ../../ai_ml/09_rag_embeddings/.
• Never present model output as a clinical decision. Human review of anything affecting care is both the ethical and the regulatory position.

Interview angle

• “What changes when you handle PHI?” - encryption in transit and at rest, per-request authorisation, append-only audit logs of every access, data minimisation, and a BAA with every subprocessor. The last one is the answer that shows real experience, because it constrains tool choice before you write any code.
• “How do you de-identify health data?” - Safe Harbor (remove the 18 identifiers, mechanical, loses date granularity) or Expert Determination (a statistician certifies low re-identification risk, keeps more value). And note that field removal alone does not prevent linkage attacks.
• “Where does PHI leak in a normal application?” - logs, error trackers, URLs, analytics, non-production database copies, and LLM API calls. Redact by default and allow-list what may be logged, rather than filtering after the fact.
• “Can you use a hosted LLM on clinical documents?” - only with a BAA and no-retention terms, or by de-identifying first, or by running inference inside your own boundary. Say which you would choose and why before describing the RAG design.
• “Is audit logging an observability concern here?” - no, it is a functional requirement with its own retention, immutability and query needs. Mixing it into general application logging with a 14-day retention fails an audit.