HIPAA Privacy Rule Explained
This article is for educational purposes only and does not constitute professional compliance advice or legal counsel. HIPAA requirements and enforcement practices evolve, and you should consult with a qualified compliance professional about your specific situation.
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. But "protected health information" is a specific definition in HIPAA, not just any data your organization handles. 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.
How PHI Is Defined Technically
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.
Permitted Uses and Disclosures of Patient Data
The Privacy Rule defines what uses of PHI are permitted without patient authorization. A use is when an organization uses PHI internally. A disclosure is when it shares PHI with someone outside the organization. This distinction matters because different rules apply to each.
Permitted uses include treatment (providing healthcare to the patient), payment (billing and payment processing), and healthcare operations (administrative and business functions like accreditation, auditing, and quality assurance). These are the core uses. Healthcare organizations can use patient data for these purposes without explicit patient authorization if they have documented policies and safeguards in place. 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. If a healthcare organization wants to use patient data for research, marketing, pharmaceutical trials, or any purpose beyond treatment, payment, and operations, they need a specific written authorization from the patient. This authorization is not the same as the patient knowing their data is being used. It must be 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.
Patient Rights: Access, Amendment, Accounting of Disclosures
The Privacy Rule grants patients specific rights regarding their own data. These aren't suggestions or best practices. They're regulatory requirements that the organization must support.
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. This is primarily an administrative and legal requirement, but it frequently falls to IT to implement the systems and audit logs that create the evidence. 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. Audit logging and access controls are therefore Privacy Rule requirements as well as Security Rule requirements.
Business Associate Agreements and Why They're Non-Negotiable
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.
What requires a BAA? 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. 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 Microsoft Teams 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. They 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: What You Need to Keep and Why
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 documentation 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. You need to maintain records of any breaches or unauthorized access and your investigation and response.
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 not optional. It's how you prove to HHS auditors that you actually comply with the regulation.
The Relationship Between Privacy and Security
It's important to understand that Privacy and Security Rules overlap but aren't identical. The Privacy Rule defines what you can do with patient data (uses and disclosures). The Security Rule defines how you protect patient data (encryption, access controls, audit logging). 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).
Closing
The Privacy Rule is primarily a legal and administrative framework, not a technical one, but IT plays a critical supporting role. You understand that 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.
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.