HIPAA Privacy Rule Explained

Reviewed by Dr. Sarah Chen, HCISPP, CISA

The HIPAA Privacy Rule governs how covered entities and business associates use, disclose, and manage protected health information. It is primarily a legal and administrative rule — not a technical one. IT supports Privacy Rule compliance by implementing access controls, encryption, and audit logging, but the rule itself is owned by compliance and legal teams. PHI includes any individually identifiable health information across 18 specific identifier categories. Uses for treatment, payment, and healthcare operations are permitted without patient authorization; all other uses require explicit written consent.

Your legal team keeps bringing up the Privacy Rule and what it requires for handling patient data. You're an IT director, not a compliance officer, and you're wondering how much of this actually applies to your department. The truth is straightforward: the Privacy Rule is primarily a legal and administrative rule, not a technical one. IT supports Privacy Rule compliance through security controls, but you're not the owner of Privacy Rule requirements. This distinction matters because it clarifies what IT actually needs to do and what compliance and legal need to handle. Understanding this boundary saves you from taking on work that belongs in other departments and helps you focus on what actually falls in your wheelhouse.

What the Privacy Rule Covers: Protected Health Information

The Privacy Rule controls how healthcare organizations and their business associates can use, disclose, and manage protected health information. PHI is any health information that can identify an individual — medical records, billing information, health plan data, anything that relates to someone's physical or mental health, healthcare provision, or healthcare payment that can be linked back to them directly or indirectly.

The definition is broad intentionally. A patient's name linked to a diagnosis is PHI. A patient ID number linked to treatment history is PHI. A medical record number is PHI. Even just a date of birth combined with a zip code combined with a diagnosis could theoretically identify someone and thus count as PHI. The regulation errs on the side of caution, which is why healthcare organizations need clear policies about what qualifies as PHI and how to handle it. You can't manage something you haven't defined, and that's where many organizations fail — they don't have a clear organizational definition of what counts as PHI, so different departments treat the same data differently.

What's not PHI includes aggregate data that can't identify individuals (statistical summaries of treatment outcomes), properly de-identified data that's been stripped of identifying information using specific methods defined in the regulation, or health information that's already been de-identified through statistical certification. The de-identification standard is important because it's the escape hatch. If you can genuinely de-identify data using the right method, you're no longer subject to Privacy Rule restrictions on what you can do with it, which brings us to the specific identifiers that make this determination.

The 18 Identifiers That Define PHI

The Privacy Rule lists 18 specific identifiers that, when present, make information count as PHI. These include patient name, patient ID numbers, telephone numbers, email addresses, street address, birth date, dates of medical events, dates of healthcare service, social security numbers, insurance claim numbers, medical record numbers, account numbers, certificate and license numbers, vehicle identifiers, device serial numbers, website URLs, IP addresses, biometric identifiers, and any other unique identifying number or characteristic. If you remove all 18 identifiers through a certified safe harbor method, the remaining information is considered de-identified and is no longer subject to the Privacy Rule.

This creates a legitimate path for healthcare organizations to use patient data for research, analytics, or other purposes: de-identify it properly. But proper de-identification requires either removing all 18 identifiers through a specific method or obtaining a statistical certification from a privacy expert. The process is not trivial. Many organizations think they've de-identified data when they haven't. Partially redacted data or data with some identifiers removed but not all is still PHI if other identifiers remain. If you remove names and social security numbers but leave dates of service and diagnoses, you haven't de-identified the data — someone could still potentially identify the individual by cross-referencing public records.

The importance of clear PHI definition isn't just regulatory — it's operational. If you don't have a clear definition of what PHI is in your organization, you can't have consistent policies about how to handle it. Employees don't know whether something needs to be encrypted or access-controlled. Data ends up in email inboxes, unencrypted backups, or shared drives where it shouldn't be. Clarity on PHI definition is the foundation of Privacy Rule compliance, and it's also what determines which uses and disclosures are permitted.

Permitted Uses and Disclosures of Patient Data

Healthcare organizations can use and disclose PHI for treatment, payment, and healthcare operations without explicit patient authorization. All other uses require specific written authorization from the patient.

A use is when an organization uses PHI internally. A disclosure is when it shares PHI with someone outside the organization. A clinician accessing a patient's records to provide treatment is a permitted use. A billing department accessing records to process insurance claims is a permitted use. An internal audit reviewing clinical documentation is a permitted use. Beyond those core uses, any other use requires specific patient authorization — a specific written request from the patient saying "yes, you may use my data for this specific purpose in this specific way."

Disclosures have defined categories too. Disclosures for treatment, payment, and operations are permitted. Disclosures required by law are permitted (like responding to a subpoena or court order). Disclosures to business associates under a Business Associate Agreement are permitted. Any other disclosure requires patient authorization. This is where patient rights come in — patients have the right to request that their PHI not be disclosed beyond what's minimally necessary for treatment or payment, and they have the right to request a log of who has accessed their information.

The "minimum necessary" standard is a core Privacy Rule concept that directly affects IT. When PHI is used or disclosed, only the minimum amount of information necessary for the purpose should be shared. A billing clerk doesn't need the full clinical record to process a claim. A researcher doesn't need patient names to analyze treatment outcomes. This principle translates into technical requirements for role-based access controls and data segmentation, connecting the Privacy Rule to the access controls IT implements under the Security Rule.

Patient Rights Under the Privacy Rule

The Privacy Rule grants patients specific rights regarding their own data. These are regulatory requirements, not suggestions.

The right of access means patients can request access to their own health information and get a copy. The organization has 30 days to provide it. This includes medical records, billing records, and any information maintained as part of their health record. The right of amendment means patients can request that incorrect or incomplete information in their record be corrected or supplemented. The organization has 60 days to respond and must provide an explanation if they deny the request.

The right to accounting of disclosures means patients can request a list of everyone who has accessed or received their PHI beyond treatment, payment, or healthcare operations. This creates a fundamental requirement: the organization must track who has accessed patient data and be able to report it on demand. For IT, this means patient requests for this information regularly get routed to your team. You'll need to be able to respond with: "Here's everyone who accessed this patient's data in the EHR over the last year, with dates and times." If you can't produce that information, the organization is violating patient rights and Privacy Rule requirements. HHS enforcement actions have specifically cited failure to provide patients with access to their records — including a $5.1 million settlement with Memorial Healthcare System in 2017 for failure to audit and control access. Audit logging and access controls are therefore Privacy Rule requirements as well as Security Rule requirements, which is why Business Associate Agreements must address these capabilities.

Business Associate Agreements: The Non-Negotiable Contract

Any vendor, contractor, or external organization that handles patient data on behalf of a covered entity must have a Business Associate Agreement in place before touching any PHI. A BAA is a legal contract that establishes the privacy and security obligations of both parties. Signing before the vendor touches patient data isn't optional — it's a legal requirement.

Cloud hosting providers that store patient data, managed service providers that support healthcare networks, email services if they're hosting patient data, backup and disaster recovery vendors, billing and payment processors, transcription services, consultants who access patient data, and any other vendor who stores, processes, or transmits PHI all require BAAs. Even internal service providers in the same organization might need BAAs if they're handling PHI in a way that separates them from the main covered entity structure.

The gray area exists around vendors who merely provide a generic tool. If an organization uses a communications platform and encrypts the data themselves before uploading it, the vendor technically isn't handling unencrypted PHI. The question of whether a BAA is required becomes ambiguous. But in practice, covered entities are highly cautious and typically require BAAs from anyone touching any part of their infrastructure that could potentially access patient data. Better to have unnecessary BAAs than to discover too late that you needed one.

The BAA itself includes required legal language about how the vendor will safeguard data, what uses of the data are permitted, what the vendor must do if there's a breach, what audit and inspection rights the covered entity has, and what happens with the data when the contract ends. The BAA is a legal document, not an IT document, but IT often gets asked to review whether the privacy and security commitments the organization is making in a BAA are technically feasible. This is a reasonable request because nobody wants to sign a BAA committing to encryption standards that your systems don't support.

Documentation Requirements

The Privacy Rule requires extensive documentation, and this is where many organizations fail. The covered entity must have written privacy policies that explain how they use and disclose PHI, maintain documented patient authorizations and consents, document business associate agreements, maintain access logs and audit trails, and document any security incidents involving patient data.

For IT teams, this translates to several specific requirements. You need documented policies regarding access to patient data systems. You need to maintain audit logs showing who accessed what and when. You need to document any security incidents involving patient data and your response. You need to be able to produce evidence that your systems are configured to support Privacy Rule requirements like access controls and audit logging.

Most organizations fail on documentation not because they don't have the controls but because they don't maintain proper records of those controls and who has access to what. A healthcare organization might have excellent access controls, but if they can't produce a list of who has access to patient data systems or when access was removed for a terminated employee, they've failed the Privacy Rule test. Documentation is how you prove to HHS auditors that you actually comply with the regulation, and understanding this documentation burden clarifies why the Privacy Rule and Security Rule, while separate, depend on each other.

The Relationship Between Privacy and Security

Privacy and Security Rules overlap but aren't identical. The Privacy Rule defines what you can do with patient data. The Security Rule defines how you protect patient data. Both rules require audit logging, for example, but for different reasons. Privacy Rule requires logging to support the right to accounting. Security Rule requires logging to detect unauthorized access. Both are needed.

IT's role is primarily in the Security Rule domain — implementing the technical and administrative safeguards that make Privacy Rule compliance possible. But you need to understand the Privacy Rule well enough to ensure that the controls you implement actually support privacy requirements, not just security requirements. An access control system that grants access based on job function supports both Privacy Rule requirements (limiting access to necessary information) and Security Rule requirements (limiting access to appropriate individuals).

The Privacy Rule is primarily a legal and administrative framework, but IT plays a critical supporting role. Privacy policies, data handling requirements, and patient authorization management are compliance and legal's job. Your job is providing the technical controls and audit trails that enable Privacy Rule compliance. Business Associate Agreements must be in place before vendors touch PHI — this is non-negotiable and falls to legal to negotiate but IT to implement and maintain. Audit logging and access controls are Privacy Rule requirements as well as Security Rule requirements, so understanding the Privacy Rule helps you understand why certain technical controls matter. Your responsibility is narrower than you might initially think, but those narrow responsibilities — access controls, encryption, audit logging, and forensic capability — are essential to the entire privacy program.

Frequently Asked Questions

Does the Privacy Rule apply to de-identified data?
No. Data that has been properly de-identified using the HIPAA Safe Harbor method (removing all 18 identifiers) or the Expert Determination method (statistical certification by a qualified expert) is no longer PHI and is not subject to the Privacy Rule. However, re-identification of de-identified data is prohibited, and improper de-identification — removing some but not all identifiers — does not exempt the data.

What is the minimum necessary standard and how does IT support it?
The minimum necessary standard requires that only the minimum amount of PHI needed for a particular purpose be used or disclosed. IT supports this through role-based access controls that limit what data each role can view, data segmentation that separates clinical data from billing data, and system configurations that restrict query results to the minimum data set needed for each function.

How long must Privacy Rule documentation be retained?
HIPAA requires documentation retention for six years from the date of creation or the date when the documentation was last in effect, whichever is later. This applies to privacy policies, BAAs, patient authorizations, access logs, and incident records. Some state laws require longer retention periods.

Can patients request their data in electronic format?
Under the HITECH Act amendments to the Privacy Rule, patients have the right to receive their PHI in electronic format if the covered entity maintains it electronically. The organization must provide the data in the format requested by the patient if readily producible, or in a mutually agreed-upon format. Fees for electronic copies must be reasonable and cost-based.

What happens if a covered entity doesn't have a BAA with a vendor handling PHI?
Operating without a required BAA is itself a HIPAA violation, independent of whether a breach occurs. HHS has imposed penalties specifically for failure to execute BAAs. If a breach occurs through that vendor, the covered entity faces compounded liability — both for the breach and for the missing BAA. The vendor is also subject to direct HHS enforcement as a de facto business associate.

Fully Compliance provides educational content about IT compliance and cybersecurity. This article reflects information about HIPAA as of its publication date. Regulations, penalties, and requirements evolve — consult a qualified compliance professional for guidance specific to your organization.