HighFile-scope Plug & play

Do not log PHI; mask and drop sensitive fields

Never write Protected Health Information (PHI/ePHI) to logs. Redact fields like name, SSN, MRN, DOB, address, diagnoses, and lab results; store only non-identifying metadata and a stable request trace id. If logging is required for troubleshooting, replace values with consistent tokens and record access separately in the audit log.

Add to Mesrai Open workspace

Why this matters

HIPAA requires safeguarding PHI; logging PHI creates uncontrolled copies and disclosure risk.

Bad vs. good

Side-by-side examples engineers can pattern-match during review.

Avoid

log.info("GET /patients/{id}", { patientName, ssn, mrn, dob, diagnosis })

Prefer

log.info("GET /patients/{id}", { traceId, route:"/patients/:id", status:200 }) // audit_log.write({ action:"READ_PHI", subject: userId, resource: patientId, purpose: header.Purpose-Of-Use })

More snippets

Bad

logger.info({ mrn, diagnosis })

Good

logger.info({ traceId, status }); /* audit_log.write({action:"READ_PHI",subject:userId,resource:patientId}) */

Related rules

From the same buckets as this rule.

Critical
Check consent and role-based authorization before returning ePHI
Handlers must verify the requester’s role and a valid consent/relationship (e.g., care team assignment) before disclosing ePHI; include Purpose-Of-Use in the decision and audit the outcome.
compliance-hipaasecurity-hardening+2
Critical
Encrypt ePHI at rest with KMS-managed AES-256 and envelope keys
Before persisting ePHI, encrypt using a data key protected by a Key Management Service (KMS). Use authenticated encryption (AES-256-GCM or equivalent), rotate keys, and store the key id and algorithm with the record.
compliance-hipaasecurity-hardening+2
High
De-identify analytics and block PHI egress to third parties
Any PR that adds or modifies telemetry/analytics must prove that no PHI leaves the boundary. Use irreversible tokenization or hashing (HMAC with secret salt) for identifiers and document the data dictionary.
compliance-hipaaprivacy-pii+2

Do not log PHI; mask and drop sensitive fields

Bad vs. good

Side-by-side examples engineers can pattern-match during review.

Avoid

log.info("GET /patients/{id}", { patientName, ssn, mrn, dob, diagnosis })

Prefer

log.info("GET /patients/{id}", { traceId, route:"/patients/:id", status:200 }) // audit_log.write({ action:"READ_PHI", subject: userId, resource: patientId, purpose: header.Purpose-Of-Use })

More snippets

Bad

logger.info({ mrn, diagnosis })

Good

logger.info({ traceId, status }); /* audit_log.write({action:"READ_PHI",subject:userId,resource:patientId}) */

Related rules

From the same buckets as this rule.

Critical

Check consent and role-based authorization before returning ePHI

Handlers must verify the requester’s role and a valid consent/relationship (e.g., care team assignment) before disclosing ePHI; include Purpose-Of-Use in the decision and audit the outcome.

compliance-hipaasecurity-hardening+2

Critical

Encrypt ePHI at rest with KMS-managed AES-256 and envelope keys

Before persisting ePHI, encrypt using a data key protected by a Key Management Service (KMS). Use authenticated encryption (AES-256-GCM or equivalent), rotate keys, and store the key id and algorithm with the record.

compliance-hipaasecurity-hardening+2

High

De-identify analytics and block PHI egress to third parties

Any PR that adds or modifies telemetry/analytics must prove that no PHI leaves the boundary. Use irreversible tokenization or hashing (HMAC with secret salt) for identifiers and document the data dictionary.

compliance-hipaaprivacy-pii+2