Business Rules - HIPAA Compliance for Software Builders

> Legal/medical note: This section is descriptive and informational. > It does not constitute medical diagnosis, legal advice, or compliance counsel. > Always consult a qualified professional (Privacy Officer, healthcare counsel) before making operational decisions. > Governing reference: HIPAA 45 CFR Part 164 - Privacy Rule and Security Rule (2023).

This document lists the invariant business rules of the HIPAA compliance domain from the perspective of a builder of software that processes ePHI. Each rule describes a constraint of the compliance process (control, audit, attestation) - not a clinical instruction. Identified with BR-NNN codes, technology-independent.

---

BR-001 - Mandatory access control on every ePHI resource

Code: BR-001 Name: Every system processing ePHI enforces unique access control Description: In the HIPAA domain, access to ePHI must be mediated by technical mechanisms that uniquely identify the user and limit privileges. Shared accounts or generic credentials for PHI access are described as non-compliant with the process. Motivation: Ensure individual traceability and enforce the minimum-necessary principle. Priority: CRITICAL Actors: Privacy Officer, Healthcare Operator, Identity & Access Management System Traceability: 45 CFR § 164.312(a)(1); § 164.312(a)(2)(i) Unique User Identification; glossary "Access Control".

---

BR-002 - Tamper-evident audit logging

Code: BR-002 Name: Every access to a PHI record generates an immutable audit entry Description: The compliance process requires that who, when, from which device, and with what action accessed a PHI record be recorded in an append-only audit log. Entries must not be alterable after the fact and must be retained per applicable schedules. Motivation: Enable event reconstruction during an OCR audit or incident investigation. Priority: HIGH Actors: Auditor, Audit Logging System, Privacy Officer Traceability: 45 CFR § 164.312(b) Audit Controls; glossary "Audit Controls".

---

BR-003 - Encryption of ePHI at rest and in transit

Code: BR-003 Name: ePHI is encrypted at rest and in transit per industry standards Description: The HIPAA domain treats encryption as an addressable specification: descriptively, AES-256 at rest and TLS 1.2+ in transit are considered reasonable and appropriate in modern systems. PHI transmitted in cleartext over a public network is described as a reportable incident. Motivation: Protect the confidentiality and integrity of ePHI. Priority: HIGH Actors: Encryption System, Privacy Officer Traceability: 45 CFR § 164.312(a)(2)(iv); § 164.312(e)(2)(ii); glossary "Data at Rest", "Data in Transit".

---

Code: BR-004 Name: No PHI is shared with a third party without a signed BAA Description: In the compliance process, every third-party vendor (cloud, analytics, billing) with PHI access must have a signed Business Associate Agreement before data is shared. The BAA sets permitted uses and safeguard obligations. Motivation: Contractually extend HIPAA obligations down the supply chain. Priority: CRITICAL Actors: Privacy Officer, Business Associate, Legal Traceability: 45 CFR § 164.504(e); § 160.103; glossary "BAA".

---

BR-005 - Breach notification within prescribed deadlines

Code: BR-005 Name: A confirmed PHI breach triggers the notification workflow Description: The domain provides that a breach (impermissible use/disclosure compromising PHI security/privacy) triggers the Breach Notification Rule: notice to affected individuals, to HHS, and - for large breaches - to media, within prescribed deadlines. Motivation: Ensure transparency and compliance with post-incident obligations. Priority: CRITICAL Actors: Privacy Officer, Incident Response Team, HHS/OCR Traceability: 45 CFR §§ 164.400–414 Breach Notification Rule; glossary "Data Breach".

---

BR-006 - Documented risk analysis and management

Code: BR-006 Name: The organization maintains an accurate, current ePHI risk analysis Description: The compliance process requires identifying all ePHI, assessing threats and vulnerabilities, estimating likelihood and impact, and documenting mitigation measures (risk management). The analysis must be complete, accurate, and periodically reviewed. Motivation: Ground security measures on a formal, traceable assessment. Priority: HIGH Actors: Privacy Officer, Risk Analyst Traceability: 45 CFR § 164.308(a)(1)(ii)(A) Risk Analysis; § 164.308(a)(1)(ii)(B) Risk Management.

---

BR-007 - Minimum-necessary principle

Code: BR-007 Name: PHI requests and disclosures are limited to the minimum necessary Description: In the HIPAA domain, PHI access and disclosures must be limited to the minimum information needed for the authorized purpose. In practice this is described via RBAC with most-restrictive permissions and avoiding unjustified bulk exports. Motivation: Reduce PHI exposure surface. Priority: HIGH Actors: Privacy Officer, Healthcare Operator, RBAC System Traceability: 45 CFR § 164.514(d); § 164.502(b); glossary "Minimum Necessary", "RBAC".

---

BR-008 - Assigned security responsibility

Code: BR-008 Name: There is an identified person responsible for ePHI security Description: The compliance process requires formally identifying a figure (Security/Privacy Officer) responsible for developing and implementing security policies, with adequate authority and resources. Motivation: Ensure accountability of the compliance program. Priority: MEDIUM Actors: Privacy Officer, Management Traceability: 45 CFR § 164.308(a)(2) Assigned Security Responsibility; § 164.308(a)(5) Workforce Training.