> Disclaimer: This content is for educational and reference purposes for software builders only. It does not constitute medical, legal, financial, or regulatory advice. Consult a qualified professional before making decisions based on this content.
Access Control
Access control is the mechanism that restricts which users, processes, and systems can read, write, or execute data and operations. Under the HIPAA Security Rule, covered entities must implement technical policies and procedures for electronic PHI (ePHI) so that only authorised persons or software programs are granted access. Effective access control combines authentication, authorisation, and audit logging. (45 CFR § 164.312(a)(1), HIPAA Security Rule)
Addressable Implementation Specification
An addressable implementation specification in HIPAA is one that a covered entity must implement if, after assessing its environment, the specification is a reasonable and appropriate safeguard. If not, the entity must document its rationale and implement an equivalent alternative. This contrasts with "required" specifications which must always be implemented. (45 CFR § 164.306(d)(3), HIPAA Security Rule)
Assigned Security Responsibility
Assigned security responsibility is a required HIPAA administrative safeguard mandating that covered entities identify a Security Official responsible for developing and implementing security policies and procedures for the protection of ePHI. This person is the compliance point of contact for all HIPAA Security Rule matters and must have the authority and resources to manage the security programme effectively. (45 CFR § 164.308(a)(2), HIPAA Security Rule)
Administrative Safeguards
Administrative safeguards are the policies, procedures, and management actions to manage the selection, development, implementation, and maintenance of security measures that protect ePHI. They include security management process, workforce training, contingency planning, and evaluation. (45 CFR § 164.308, HIPAA Security Rule)
Audit Controls
Audit controls are hardware, software, and procedural mechanisms that record and examine activity in information systems that contain or use ePHI. A builder must capture who accessed what PHI record, when, from which IP or device, and what action was performed. Audit logs must be tamper-evident and retained in compliance with state and entity-level retention schedules. (45 CFR § 164.312(b), HIPAA Security Rule)
Authentication
Authentication is the verification of the identity of a person or entity seeking access to ePHI. HIPAA requires covered entities to implement procedures to verify that a person or entity seeking access to ePHI is who they claim to be. Common patterns include password-plus-MFA, certificate-based auth, and biometric methods. (45 CFR § 164.312(d), HIPAA Security Rule)
Authorization
Authorization determines what an authenticated user is permitted to do with specific ePHI records. Systems must enforce the minimum-necessary principle: users should only access the minimum PHI needed to accomplish their authorised task. RBAC (Role-Based Access Control) is the standard implementation pattern. (45 CFR § 164.514(d), HIPAA Privacy Rule)
BAA (Business Associate Agreement)
A Business Associate Agreement is a contract between a covered entity and a business associate that establishes the permitted uses and disclosures of PHI by the business associate, and requires the business associate to safeguard the information appropriately. Any third-party vendor with access to PHI must have a signed BAA before PHI is shared. (45 CFR § 164.504(e), HIPAA Privacy Rule)
Breach
A breach is an impermissible use or disclosure of PHI that compromises its security or privacy. Breaches trigger HIPAA's Breach Notification Rule, which requires covered entities to notify affected individuals, HHS, and (for large breaches) the media. Builders must implement breach detection pipelines to identify and report incidents within mandated timeframes. (45 CFR § 164.400–414, HIPAA Breach Notification Rule)
Business Associate
A business associate is a person or entity that, on behalf of a covered entity, creates, receives, maintains, or transmits PHI to perform a function or activity. Cloud storage providers, analytics platforms, billing services, and software vendors with PHI access are common business associates. Each must execute a BAA and comply with the HIPAA Security Rule. (45 CFR § 160.103, HIPAA definitions)
CCPA (California Consumer Privacy Act)
The CCPA grants California residents rights over their personal information. For healthcare software builders operating in California, both HIPAA and CCPA may apply simultaneously. CCPA's right to deletion and right to opt out of sale may conflict with HIPAA's retention requirements; the more stringent obligation generally controls.
Contingency Plan
A contingency plan is a required HIPAA administrative safeguard requiring covered entities to establish plans and procedures to respond to emergencies or other events that damage systems containing ePHI. Required components include a data backup plan, disaster recovery plan, emergency mode operation plan, testing and revision procedures, and applications and data criticality analysis. (45 CFR § 164.308(a)(7), HIPAA Security Rule)
Covered Entity
A covered entity under HIPAA is a health plan, health care clearinghouse, or health care provider that transmits health information electronically for standard transactions. Software builders must determine whether their client is a covered entity and design systems accordingly. (45 CFR § 160.103, HIPAA definitions)
Device Management Policy
A device management policy defines procedures for the inventory, secure configuration, monitoring, decommissioning, and sanitisation of all hardware devices that access or store ePHI. It must cover enterprise laptops, mobile devices, networked medical devices, and removable media. Sanitisation at decommissioning must meet NIST SP 800-88 standards. (45 CFR § 164.310(d), HIPAA Security Rule)
Data at Rest
Data at rest refers to ePHI stored on disk, in databases, on removable media, or in backups. HIPAA requires encryption of data at rest as an addressable specification; in practice, AES-256 is the industry standard and is considered reasonable and appropriate for all modern systems. (45 CFR § 164.312(a)(2)(iv), HIPAA Security Rule)
Data in Transit
Data in transit is ePHI being transmitted over a network. HIPAA requires encryption of ePHI in transit as an addressable specification. TLS 1.2 or higher is the current minimum; TLS 1.3 is recommended. Any transmission of PHI over public networks without encryption is a reportable breach. (45 CFR § 164.312(e)(2)(ii), HIPAA Security Rule)
De-identification
De-identification is the process of removing or generalising PHI so that the resulting dataset can no longer reasonably identify an individual. HIPAA provides two safe-harbour methods: the Expert Determination method and the Safe Harbor method (removing 18 specific identifiers). De-identified data is no longer subject to HIPAA restrictions. (45 CFR § 164.514(a)–(b), HIPAA Privacy Rule)
Designated Record Set
A designated record set is the group of records maintained by or for a covered entity that includes medical records, billing records, and other records used to make decisions about individuals. Patients have HIPAA rights to access and request amendments to their designated record set. (45 CFR § 164.501, HIPAA Privacy Rule)
ePHI (Electronic Protected Health Information)
ePHI is any PHI that is created, received, maintained, or transmitted in electronic form. The HIPAA Security Rule applies exclusively to ePHI. Builders must identify all ePHI data flows in their system and apply appropriate administrative, physical, and technical safeguards to each.
Encryption
Encryption transforms data into an unreadable format using cryptographic keys, ensuring that only authorised parties with the correct decryption key can read the data. For ePHI at rest, AES-256 is standard. For ePHI in transit, TLS 1.2+ is required. HIPAA treats encryption as an addressable specification but considers it reasonable and appropriate in virtually all contexts. (45 CFR § 164.312(a)(2)(iv), (e)(2)(ii))
Emergency Access Procedure
An emergency access procedure is a protocol allowing authorised users to access ePHI in emergency circumstances even when normal access controls cannot be completed. Systems must implement emergency override mechanisms that are themselves audited and time-limited. (45 CFR § 164.312(a)(2)(ii), HIPAA Security Rule)
FHIR (Fast Healthcare Interoperability Resources)
FHIR is an HL7 standard for exchanging healthcare information electronically. It uses REST, JSON/XML, and OAuth 2.0. When building FHIR APIs, PHI transmitted via FHIR is ePHI and subject to HIPAA. Access tokens must be scoped to the minimum-necessary patient data.
HHS (Department of Health and Human Services)
HHS is the US federal department that administers HIPAA enforcement through its Office for Civil Rights (OCR). Covered entities and business associates report breaches to HHS and are subject to OCR audits. HHS publishes the official HIPAA guidance at hhs.gov/hipaa.
HITECH Act
The Health Information Technology for Economic and Clinical Health (HITECH) Act of 2009 strengthened HIPAA's enforcement provisions, introduced the Breach Notification Rule, and extended HIPAA obligations to business associates. It also significantly increased civil and criminal penalties for non-compliance.
Integrity Controls
Integrity controls are security measures that corroborate that ePHI has not been altered or destroyed in an unauthorised manner. Implementation techniques include checksums, hash verification, digital signatures, and version control. (45 CFR § 164.312(c)(1), HIPAA Security Rule)
Minimum Necessary
The minimum-necessary principle requires that covered entities and business associates limit requests and disclosures of PHI to the minimum needed to accomplish the intended purpose. In practice this means implementing RBAC with the narrowest permission scopes and avoiding bulk PHI exports without clinical justification. (45 CFR § 164.514(d), HIPAA Privacy Rule)
MFA (Multi-Factor Authentication)
MFA requires users to present two or more verification factors before accessing ePHI systems. It is a best-practice implementation of HIPAA's authentication requirements and is increasingly required by cyber-insurance underwriters. Common second factors include TOTP codes, push notifications, and hardware security keys.
Notice of Privacy Practices (NPP)
An NPP is a document that covered entities must provide to patients describing how PHI is used, disclosed, and protected. Builders of patient-facing applications must implement an NPP display and electronic acknowledgement workflow.
OCR (Office for Civil Rights)
OCR is the HHS division that enforces HIPAA Privacy and Security Rules, investigates complaints, and conducts audits. OCR publishes resolution agreements and corrective action plans that provide concrete implementation guidance for software builders.
PHI (Protected Health Information)
PHI is individually identifiable health information that is created, received, maintained, or transmitted by a covered entity or business associate. PHI includes 18 categories of identifiers: names, geographic data, dates, phone numbers, email addresses, Social Security numbers, medical record numbers, health plan beneficiary numbers, account numbers, certificate/license numbers, vehicle identifiers and serial numbers including license plate numbers, device identifiers and serial numbers, web URLs, IP addresses, biometric identifiers including finger and voice prints, full-face photographs and comparable images, and any other unique identifying number or characteristic. (45 CFR § 164.514(b)(2)(i), HIPAA Privacy Rule)
Physical Safeguards
Physical safeguards under HIPAA are measures to protect covered entities' electronic information systems, and the facilities in which they are housed, from natural and environmental hazards and unauthorised intrusion. For cloud-hosted systems, the cloud provider's physical security typically satisfies this requirement, but builders must verify and document it in a BAA. (45 CFR § 164.310, HIPAA Security Rule)
Privacy Rule
The HIPAA Privacy Rule establishes national standards for the protection of health information, defining patient rights over their PHI and the conditions under which PHI may be used or disclosed. It applies to all forms of PHI (paper, oral, and electronic). (45 CFR Parts 160 and 164 Subparts A and E)
RBAC (Role-Based Access Control)
RBAC is a policy-neutral access control mechanism defined around roles, not individual users. Roles aggregate permissions, and users are assigned one or more roles. In HIPAA contexts, roles correspond to clinical functions (physician, nurse, billing clerk) with each role having the minimum PHI permissions necessary for that function.
Required Implementation Specification
A required implementation specification under HIPAA is one that must be implemented with no flexibility. Covered entities cannot substitute an alternative measure. Examples include unique user identification and automatic logoff. (45 CFR § 164.306(d)(2), HIPAA Security Rule)
Retention Policy
A data retention policy defines how long ePHI must be kept and when it can be destroyed. HIPAA requires covered entities to retain documentation of their HIPAA compliance policies for six years from creation or last effective date. Medical records have separate retention requirements set by state law, typically 5–10 years.
Risk Assessment
A risk assessment is the process of determining the likelihood and potential impact of threats to ePHI within an organisation. As a component of the required HIPAA risk analysis, a risk assessment must cover all ePHI, applicable threats, existing controls, and residual risk levels. Its outputs drive the risk management process. (45 CFR § 164.308(a)(1)(ii)(A), HIPAA Security Rule)
Risk Analysis
A risk analysis is a required HIPAA administrative safeguard in which a covered entity identifies all ePHI, assesses threats and vulnerabilities, determines the likelihood and impact of each risk, and documents findings. It must be comprehensive, accurate, and thorough. (45 CFR § 164.308(a)(1)(ii)(A), HIPAA Security Rule)
Risk Management
Risk management is the required process of implementing security measures to reduce identified ePHI risks to a reasonable and appropriate level and documenting the selected measures. It flows from the risk analysis. (45 CFR § 164.308(a)(1)(ii)(B), HIPAA Security Rule)
Security Incident
A security incident is any attempted or successful unauthorised access, use, disclosure, modification, or destruction of ePHI or interference with system operations containing ePHI. Covered entities must implement procedures to identify, respond to, mitigate, and document security incidents. (45 CFR § 164.308(a)(6), HIPAA Security Rule)
Security Management Process
The security management process is the foundational HIPAA administrative safeguard requiring covered entities to implement policies and procedures to prevent, detect, contain, and correct security violations affecting ePHI. It is the umbrella requirement encompassing risk analysis, risk management, sanction policy, and information system activity review. (45 CFR § 164.308(a)(1), HIPAA Security Rule)
Security Rule
The HIPAA Security Rule establishes national standards to protect ePHI by requiring covered entities to implement administrative, physical, and technical safeguards. It applies only to ePHI (not paper or oral PHI). (45 CFR Parts 160 and 164 Subparts A and C)
Transmission Integrity Controls
Transmission integrity controls are security mechanisms to verify that ePHI has not been modified without authorisation during transmission. They ensure both authenticity and integrity of transmitted data using techniques such as TLS with modern cipher suites, digital signatures, and cryptographic checksums on each message or file payload. (45 CFR § 164.312(e)(2)(i), HIPAA Security Rule)
Technical Safeguards
Technical safeguards are the automated processes used to protect ePHI and control access. They include access controls, audit controls, integrity controls, authentication mechanisms, and transmission security. (45 CFR § 164.312, HIPAA Security Rule)
Unique User Identification
Unique user identification is a required HIPAA implementation specification that mandates assigning a unique name or number for identifying and tracking user identity in all systems containing ePHI. Shared credentials and service accounts used to access PHI are a HIPAA violation. (45 CFR § 164.312(a)(2)(i), HIPAA Security Rule)
Workforce Training
Workforce training is a required HIPAA administrative safeguard mandating that covered entities train all workforce members on HIPAA policies and procedures relevant to their job functions. Builders deploying internal tools used by healthcare staff must document training programmes. (45 CFR § 164.308(a)(5), HIPAA Security Rule)
Workstation Use and Security
HIPAA requires covered entities to implement policies specifying the proper functions to be performed on workstations with access to ePHI, the manner in which those functions are to be performed, and physical safeguards for workstations. Builders must implement screen lock timeouts and automatic logoff for web and desktop apps. (45 CFR § 164.310(b)–(c), HIPAA Security Rule)
Zero Trust Architecture
Zero Trust is a security model in which no user, device, or network segment is trusted by default, regardless of location. Every access request must be authenticated, authorised, and continuously validated. In HIPAA-regulated environments, Zero Trust reduces the blast radius of breached credentials by ensuring lateral movement requires re-authentication at each PHI data boundary.