HighPR-scope

Introduce an auditable “break-glass” path only with justification

Emergency access to ePHI must go through a dedicated break_glass path that requires reason, approver, limited time window, and automatic post-incident review. The PR must include changes to the audit log schema and runbook.

Add to Mesrai Open workspace

Why this matters

HIPAA allows emergency access but mandates accountability and post-access review.

Bad vs. good

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

Avoid

PR description:
"Adds /emergency-access endpoint"

Prefer

PR description:
- Add POST /break_glass with required {reason, approverId, expiresAt}
- Audit: audit_log.action=BREAK_GLASS, fields {reason, approverId}
- Runbook: incident-review.md updated
- Alerts: pager rule for BREAK_GLASS events

More snippets

Bad

- Add /emergency-access
- no audit updates

Good

- Add /break_glass with reason+approver
- Update audit schema and runbook

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

Bad vs. good

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

Avoid

PR description:
"Adds /emergency-access endpoint"

Prefer

PR description:
- Add POST /break_glass with required {reason, approverId, expiresAt}
- Audit: audit_log.action=BREAK_GLASS, fields {reason, approverId}
- Runbook: incident-review.md updated
- Alerts: pager rule for BREAK_GLASS events

More snippets

Bad

- Add /emergency-access
- no audit updates

Good

- Add /break_glass with reason+approver
- Update audit schema and runbook

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