HIPAA guide

The HIPAA compliance guide for healthcare and healthtech teams.

HIPAA is the US federal law that protects patient health information. This guide explains its three rules, the Business Associate Agreements (BAAs) that bind your vendors, and how HIPAA cloud compliance works in practice. It is written for founders, engineers and compliance leads who need the rules in plain words.

Back to HIPAA compliance services

01 · The Privacy Rule

The HIPAA Privacy Rule: who may use patient data, and why

The Privacy Rule draws the boundary around protected health information (PHI): who may use it, who may receive it, and the rights patients can insist on over their own records.

Minimum necessaryOnly the row the task needs is shown; everything else on the record stays redacted.

The rule protects PHI in any form: electronic, on paper or spoken aloud. A hallway conversation about a patient, a printed chart and a database row are all covered. PHI is health information that identifies a person, held by a covered entity (a provider, health plan or clearinghouse) or by a business associate working for one.

Minimum necessary

For most uses and disclosures, share only what the task requires. A billing clerk does not need clinical notes, and an analytics export does not need patient names.

The standard does not apply to

Disclosures to a provider for treatment
Disclosures to the patient themselves
Disclosures the patient has authorized in writing
Disclosures the law requires
Disclosures to the US Department of Health and Human Services (HHS) for oversight

Patient rights

AccessPatients may see and get a copy of their records.
AmendmentPatients may ask for corrections to records they believe are wrong.
Accounting of disclosuresPatients may ask for a list of certain disclosures of their PHI.
Restriction requestsPatients may ask a provider to limit how their PHI is used or shared.
Confidential communicationsPatients may ask to be contacted by a different route, such as a different address or phone.
Notice of privacy practicesPatients are given a plain document explaining how their PHI is used and what their rights are.

Permitted uses and disclosures include

Treatment: Sharing PHI between the providers caring for a patient.
Payment: Billing and claims, including sharing PHI with a health plan.
Healthcare operations: Quality review, training and business management of the covered entity.
Public health: Reporting that the law requires or authorizes, such as disease reporting.
Required by law: Disclosures the law demands, such as under a court order or a mandatory report.
Law enforcement and legal proceedings: Disclosures made under defined conditions.
Research: Allowed with a review board's waiver of authorization, as a limited data set, or with de-identified data.
With the patient's written authorization: For anything not otherwise permitted.

02 · The Security Rule

The HIPAA Security Rule: safeguards for electronic patient data

Under the Security Rule, both covered entities and their business associates must guard electronic protected health information (ePHI) using three families of safeguards: administrative, physical and technical.

Three kinds of safeguardPatient data at the core, protected in three layers of safeguards.

Administrative safeguards

The policies, people and processes.

Security management process: Find risks to ePHI and reduce them to a reasonable level.
Assigned security responsibility: One named person owns the security program.
Workforce security: Staff have the access their job needs, and it ends when they leave.
Information access management: Access to ePHI is approved, recorded and limited by role.
Security awareness and training: Staff are trained, and the training is recorded.
Security incident procedures: Incidents are detected, reported and handled in a defined way.
Contingency plan: Backups, disaster recovery and emergency operation keep ePHI available.
Evaluation: The program is reviewed again when the environment changes.
Business associate contracts: Vendors that handle ePHI are bound by agreements.

Physical safeguards

The buildings and devices.

Facility access controls: Limit who can enter the places where ePHI systems sit.
Workstation use: Define how workstations that reach ePHI may be used.
Workstation security: Protect those workstations from unauthorized use.
Device and media controls: Track, reuse and dispose of hardware and media that hold ePHI.

Technical safeguards

The technology.

Access control: Unique user IDs, emergency access and automatic logoff.
Audit controls: Record and examine activity in systems that hold ePHI.
Integrity: Prevent ePHI from being improperly changed or destroyed.
Person or entity authentication: Verify the identity of whoever or whatever asks for access.
Transmission security: Protect ePHI as it moves across networks.

Required vs addressable

Required

A required specification must be implemented as written.

Addressable

An addressable one is not optional. You assess whether it is reasonable for your environment: if it is, you implement it; if not, you document why and put an equivalent measure in place.

Encryption is the common example. The rule treats it as addressable, yet in practice almost everyone needs it, because encrypted data keeps a lost laptop or stolen backup from becoming a reportable breach.

Why the risk analysis comes first

The risk analysis is the foundation of the Security Rule. You cannot choose reasonable safeguards, or justify an addressable decision, until you know what ePHI you hold, where it lives and what could happen to it. Reviewers often find that the analysis was never done, or has not been refreshed since the systems changed.

03 · Breach notification

The HIPAA Breach Notification Rule: what to report, to whom, and when

If unsecured PHI is breached, the Breach Notification Rule obliges you to notify the people affected and, depending on the size of the breach, the federal health department (HHS) and the press. The outer limit is 60 days from discovery, and delay without good reason is not allowed within it.

Who must be toldWhen unsecured PHI is breached, up to three kinds of notice go out.

A breach is any use or disclosure of PHI that the Privacy Rule does not allow and that puts the information's privacy or security at risk. The rule assumes such an event is a breach unless you can show otherwise, and the only way to do so is a written risk assessment concluding that the chance of the PHI being compromised is low.

“Unsecured” PHI is PHI not made unusable to unauthorized people, for example by encryption that meets the standard HHS sets. Properly encrypted data is outside the reporting duty: the safe harbor.

Three exceptions

Good-faith workforce access: A staff member accessed PHI unintentionally, in good faith and within their role, and did not misuse it.
Internal inadvertent disclosure: One authorized person shared PHI with another authorized person at the same organization by mistake, and it went no further.
Recipient could not retain it: There is a good-faith belief that the person who received the PHI could not have kept it.

The four-factor risk assessment

Nature of the PHIThe types of identifiers involved and how likely the data is to identify someone.
Who received itWho ended up with the PHI without permission, and whether that person is bound by a duty to protect it.
Whether it was actually viewedWhether the PHI was actually acquired or looked at, or only exposed.
How far risk was reducedWhether you have limited the harm, for example with a signed assurance that the recipient destroyed it.

Who to notify, when and how

Who	When	How
Affected individuals	Promptly, and in any case within 60 days of discovery	Written notice, by first-class mail, or by email if the person agreed to it
HHS, 500 or more people	At the same time as individual notice, within 60 days	HHS online breach reporting portal
HHS, fewer than 500 people	Within 60 days after the end of the calendar year	HHS online breach reporting portal, as a yearly log
Media, more than 500 residents of one state	Within 60 days of discovery	Notice to prominent media outlets in that state
Business associate to covered entity	Promptly, within the same 60-day outer limit; the contract often sets a shorter one	Written notice with who was affected and the details the covered entity needs for its own notices

Discovery counts from the day the breach is known, or would have been known with reasonable diligence.

The 60-day clockCounting from discovery: the day a breach is known, or would have been with reasonable diligence.

Business associate → covered entityFirst, often sooner under the BAA
Affected individualsWithout unreasonable delay
HHS, 500 or more peopleAlongside individual notice
Media, more than 500 residents of one stateProminent outlets in that state
HHS, fewer than 500 peopleYearly log, within 60 days of year-end

What a notice must contain

What happened, including the dates of the breach and of its discovery where known.
The types of information involved.
The steps people should take to protect themselves.
What the organization is doing to investigate, limit harm and prevent a repeat.
How to reach the organization with questions.

04 · Business Associate Agreements

Business Associate Agreements (BAAs): the contract behind every vendor

HIPAA expects a written Business Associate Agreement (BAA) wherever a vendor touches PHI on a covered entity's behalf. The same paper is needed one level down, between that vendor and each subcontractor it brings in.

Two parties, one agreementTwo parties: no patient data changes hands until the BAA is signed.

Who counts as a business associate

Any organization that creates, receives, maintains or transmits PHI for a covered entity. Typical examples:

Software-as-a-service platforms and electronic health record vendors
Cloud hosting and storage providers
Medical billing and claims processors
Managed IT and support providers
Data analytics vendors
Transcription services and consultants

A BAA is a contract, and no one issues a certificate for it. Signing one does not make a vendor compliant.

Clauses every BAA needs

Permitted uses. States what the vendor may do with the PHI, and nothing beyond it.
Safeguards. Requires the vendor to protect the PHI, including ePHI under the Security Rule.
Incident reporting. Requires the vendor to report unauthorized uses, disclosures and security incidents.
Subcontractor terms. Requires subcontractors to accept the same restrictions.
Access. Makes PHI available so the covered entity can meet patient access requests.
Amendment. Makes PHI available so corrections can be made.
Accounting of disclosures. Gives the covered entity what it needs to produce a disclosure list.
Government review. Makes the vendor's practices and records available to HHS.
Return or destruction. Requires PHI to be returned or destroyed when the contract ends, where feasible.
Termination. Lets the covered entity end the contract if the vendor breaks its terms.

Vendor due-diligence checklist

Confirm whether the vendor will actually handle PHI.
Ask for its security documentation and independent reports, such as System and Organization Controls 2 (SOC 2) or ISO/IEC 27001.
Sign the BAA before any PHI is shared.
Check that the BAA contains every required clause.
Record the review and the result.
Agree how incidents will be reported and by when.
Review the vendor again on a schedule, and when what it handles changes.

05 · HIPAA in the cloud

HIPAA cloud compliance: shared responsibility on AWS, Azure and Google Cloud

A cloud provider secures its own infrastructure, but how you configure and use the platform decides whether your ePHI is protected.

Shared responsibilityThe provider secures the data centers, hardware and network. You configure encryption, access and logging.

The provider covers

The physical data centers
The underlying network and hardware
The virtualization layer
The security of the services it offers

You cover

Which services you use for ePHI
Who can access them, and how
Encryption settings and key handling
Application and database security
Logging, monitoring and review
Backups, retention and deletion
Your own Business Associate Agreements

Cloud BAAs

Amazon Web Services (AWS), Microsoft Azure and Google Cloud each offer a BAA covering the services they list as HIPAA-eligible. Sign the BAA before ePHI goes in, use only eligible services for ePHI, and check each provider's current list, because the lists change.

Amazon Web Services (AWS)
Microsoft Azure
Google Cloud

A cloud BAA is necessary but not sufficient. It makes the provider your subcontractor; it does not secure your account.

Configuration checklist

Encryption at rest and in transit. Turn it on for databases, storage, backups and every network link.
Key management. Use a managed key service, limit who can use and administer keys, and rotate them.
Logging. Record administrative actions and access to ePHI, and keep the logs protected.
Access. Give each person and service the least access they need, with multi-factor authentication (MFA) for all human users.
Network. Keep ePHI systems in private networks and close everything not required.
Backups. Encrypt backups, test restores, and control who can reach snapshots.
Monitoring. Alert on unusual access, configuration changes and failed sign-ins, and review the alerts.
Data location. Know which regions hold ePHI and who can reach each.

Common cloud mistakes

Assuming “eligible” means “compliant”. A HIPAA-eligible service is only allowed to hold ePHI. It is not secured for you.
Public exposure. Open storage buckets, public snapshots and wide-open database ports.
ePHI in the wrong places. Patient data leaking into logs, error reports, analytics tools or other services without a BAA.
Logs nobody reads. Logging switched on, but nobody reviewing it, so an incident goes unnoticed.

06 · Implementation roadmap

From guide to program: the six-phase roadmap

Knowing the rules is the start. A working program takes six phases, and the first two, discovery and the security risk assessment (SRA), are also available as a standalone HIPAA Security Risk Assessment.

DiscoverConfirm how HIPAA applies to you, build a PHI inventory, map how it moves and rank the gaps.
AssessRun the documented security risk assessment and plan how to treat each risk.
DocumentWrite the privacy and security policies, the incident response procedure and the BAA templates.
ImplementPut access control, encryption and audit logging in place on every system holding ePHI.
TrainTrain staff by role, run awareness and phishing exercises, and keep the records.
ValidateTest the controls with penetration testing, check policies against practice, run a mock audit and fix the findings.

See how the HIPAA compliance program works and what you receive

Turn the guide into a working program.

If you want to know where your patient data is and what you can prove, start with a HIPAA risk assessment.

Get a HIPAA risk assessment Book a free consultation Back to HIPAA compliance services