Every organization that touches protected health information (PHI), whether a hospital, a health tech startup, or a third-party app connecting to an EHR, faces the same fundamental question: what is HIPAA compliance, and what does it actually require? The answer matters because getting it wrong carries real consequences: fines that can reach millions of dollars, criminal penalties, and the kind of reputational damage that's hard to recover from.

HIPAA compliance isn't a single checkbox. It's a set of federal regulations that govern how healthcare data is stored, transmitted, accessed, and disclosed. These rules apply not just to healthcare providers and insurers but also to every vendor and technology partner that handles patient data on their behalf, a category known as business associates. If your software reads, writes, or moves PHI, you're on the hook.

This is exactly why we built SoFaaS™. Our managed SMART on FHIR platform handles the heavy lifting of HIPAA-compliant infrastructure, including encryption, audit logging, and secure authorization flows, so healthcare innovators can connect to EHRs like Epic and Cerner without building compliance from scratch. We deal with the integration and security burden; you focus on your application.

In this article, you'll get a clear breakdown of HIPAA compliance: what it covers, who it applies to, and the specific rules and requirements you need to meet. Whether you're a developer, a product manager, or a business leader in healthcare IT, this guide will give you the working knowledge you need to stay compliant and move faster.

HIPAA compliance definition in plain English

The Health Insurance Portability and Accountability Act was signed into law in 1996, but understanding what is HIPAA compliance in practical terms goes beyond knowing its name. At its core, HIPAA compliance means meeting the federal requirements that protect individuals' medical information from being disclosed, misused, or inadequately secured. Compliance isn't a product you buy or a certificate you hang on a wall. It's an ongoing operational posture that requires your organization to implement specific administrative, physical, and technical safeguards whenever you handle protected health information, and to maintain those safeguards consistently over time.

HIPAA compliance is not a one-time audit pass. It's a continuous practice of protecting patient data through documented policies, trained staff, and technical controls that hold up under scrutiny.

Where HIPAA comes from

Congress passed HIPAA in 1996 primarily to make it easier for workers to keep health insurance between jobs, but the law also created the first national standards for protecting patient health data. Over the years, the Department of Health and Human Services (HHS) expanded it with additional rules, most notably the Privacy Rule in 2000 and the Security Rule in 2003. The HITECH Act of 2009 then strengthened enforcement significantly and extended HIPAA obligations to business associates, which are the vendors and technology partners that process health data on behalf of covered entities. That extension is what made HIPAA relevant to cloud providers, software developers, and API platforms, not just hospitals and insurers.

What "compliance" actually means in practice

Many people assume compliance is purely a legal concept, but it has very practical, day-to-day implications for how your organization operates. Every employee who can access patient records, every server that stores a diagnosis, and every API that transmits a lab result falls within HIPAA's scope. Compliance means you have documented policies that define how data is handled, staff members who understand those policies, and technical controls that enforce them automatically rather than relying on human memory.

The distinction between being "compliant" and simply "trying to comply" matters enormously. Regulators look at whether your organization has implemented the required safeguards and whether you can demonstrate it through audit logs, training records, and signed business associate agreements. Intention isn't enough; documented evidence is what actually protects you when an incident occurs or an investigation begins.

Protected health information: the core concept

Everything in HIPAA revolves around one central idea: protected health information, or PHI. PHI is any information that can identify an individual and relates to their past, present, or future physical or mental health condition, the provision of healthcare, or payment for care. This is broader than most people expect. A patient's name combined with a diagnosis, a billing record, an appointment date, or even a device identifier linked to a health record all qualify as PHI under the law.

HIPAA also defines electronic protected health information, or ePHI, which covers any PHI that is created, stored, transmitted, or received electronically. This distinction matters especially for technology teams because the Security Rule applies specifically to ePHI. If your application reads a patient's medication list from an EHR through an API call, that data is ePHI the moment it moves. Every step of its lifecycle, including transit, storage, access control, and deletion, must meet HIPAA's security requirements. Most modern healthcare applications deal almost exclusively with ePHI, which means the Security Rule is where developers and product teams spend the majority of their compliance effort.

What HIPAA covers and who must comply

Understanding HIPAA's scope starts with recognizing that the law draws a clear boundary around who bears legal responsibility for protecting patient data. Two main categories of organizations fall under HIPAA's requirements: covered entities and business associates. If your organization fits into either category, you must comply with the relevant rules. Asking "what is HIPAA compliance" without knowing whether it applies to you is like asking how to drive without knowing if you own a car.

Covered entities: the primary group

Covered entities are the organizations directly involved in providing or paying for healthcare. Three distinct types qualify as covered entities under federal law:

• Healthcare providers: doctors, hospitals, clinics, pharmacies, and any provider that transmits health information electronically in connection with a standard transaction
• Health plans: insurers, HMOs, Medicare, Medicaid, and employer-sponsored health plans
• Healthcare clearinghouses: businesses that convert nonstandard health information from another entity into standardized data formats

If your organization falls into one of these categories, all of the major HIPAA rules apply to you directly, including the Privacy Rule, the Security Rule, and the Breach Notification Rule.

Business associates and their vendors

The HITECH Act of 2009 extended HIPAA's reach significantly by making business associates directly liable for compliance. A business associate is any person or organization that creates, receives, maintains, or transmits PHI on behalf of a covered entity. This definition pulls in a wide range of technology and service providers, including cloud storage vendors, billing services, EHR integration platforms, and API middleware.

If your application or service touches patient data while working for a covered entity, you are a business associate and must comply with HIPAA's Security Rule and the relevant provisions of its Privacy Rule.

Before sharing any PHI with a vendor, covered entities must execute a Business Associate Agreement (BAA) with that partner. A BAA is a formal contract that specifies how PHI can be used, requires the business associate to implement appropriate safeguards, and outlines breach notification responsibilities for both parties. Sharing PHI with any vendor who has not signed a BAA is itself a HIPAA violation, even if no breach actually occurs.

Business associates can also engage their own subcontractors who handle PHI. Those subcontractors carry the same obligations as business associates and must sign BAAs with the party that hired them, extending HIPAA's requirements all the way down the vendor chain.

The HIPAA rules you need to know

HIPAA is not a single rule but a framework made up of several distinct regulations, each targeting a specific aspect of patient data protection. Knowing which rules apply to your organization is the first step toward understanding what is HIPAA compliance in operational terms. The four rules below form the backbone of the compliance framework most organizations need to address.

The Privacy Rule

Finalized in 2000, the Privacy Rule establishes national standards for how covered entities can use and disclose PHI. It gives patients rights over their own health information, including the right to access their records, request corrections, and receive an accounting of disclosures. For your organization, this rule means you must have clear policies that define permitted uses of PHI and limit disclosure to the minimum necessary for any given purpose. You cannot share more patient information than the task actually requires.

The Security Rule

Unlike the Privacy Rule, the Security Rule applies specifically to electronic protected health information (ePHI) and requires covered entities and business associates to implement administrative, physical, and technical safeguards to protect it. If your application transmits, stores, or processes ePHI in any form, this rule defines the controls you must put in place, from access management and encryption to audit logging and data integrity verification.

The Security Rule does not mandate specific technologies, but it does require you to document why your chosen controls are appropriate and review them regularly as threats evolve.

The Breach Notification Rule

Added through HITECH in 2009, the Breach Notification Rule requires covered entities to notify affected individuals, HHS, and in some cases the media following the discovery of an unsecured PHI breach. Business associates must notify the covered entity within 60 days of discovering a breach. Your organization's incident response process needs to account for these notification timelines before a breach ever happens, not after one surfaces.

The Omnibus Rule

Passed in 2013, the Omnibus Rule closed significant gaps that existed in the original legislation. It strengthened protections around genetic information, expanded the definition of business associates to include subcontractors, and increased the penalty tiers organizations face for non-compliance. For technology vendors working in the healthcare supply chain, this rule established that downstream subcontractors carry the same HIPAA obligations as the primary business associate, which means your vendors' vendors can expose you to liability if their agreements and safeguards aren't in order.

HIPAA compliance requirements and safeguards

The Security Rule organizes HIPAA's technical and operational requirements into three distinct safeguard categories: administrative, physical, and technical. Understanding what is HIPAA compliance at this level means knowing exactly what each category demands from your organization and where your documentation, controls, and vendor agreements need to hold up under scrutiny.

Administrative safeguards

Administrative safeguards are the policies, procedures, and workforce responsibilities that anchor your entire compliance program. Your organization must designate a Security Officer responsible for developing security policies, conducting risk analyses, and overseeing staff training. These requirements account for the largest share of the Security Rule and typically demand the most sustained effort to document and maintain correctly.

Key administrative requirements your organization must address include:

• Risk analysis: Identify all ePHI risks and document steps to reduce them to a reasonable level
• Workforce training: Every staff member who can access PHI must complete security awareness training
• Access management: Grant access based on job function and revoke it immediately when roles change
• Contingency planning: Maintain a documented emergency response plan that covers ePHI availability and recovery

Physical safeguards

Physical safeguards control access to the locations and hardware where ePHI is stored or processed. Your organization must restrict facility entry to authorized individuals, establish workstation use policies, and manage how devices containing ePHI are reused or disposed of. If your team runs on cloud infrastructure, much of the physical safeguard burden shifts to your provider, but you still need a signed Business Associate Agreement confirming those controls are actually in place.

Many software teams overlook physical safeguards entirely, but regulators expect documented evidence of how physical access to ePHI systems is controlled, even when those systems live in a third-party data center.

Technical safeguards

Technical safeguards are the controls embedded directly in your systems to protect ePHI as it moves between services and rests in storage. The Security Rule requires access controls so only authorized users can read or modify ePHI, audit logging that records and attributes every system activity, data integrity mechanisms that detect unauthorized changes, and transmission security such as TLS encryption for data in transit. Your systems also need unique user identification and automatic session timeouts so every access event remains traceable to a specific person.

How to become HIPAA compliant step by step

Many organizations treat compliance as something to address after a product launches, and that approach almost always creates problems. Understanding what is HIPAA compliance as a process, not a destination, means building it into your operations from the start. The steps below give you a practical sequence to follow, whether you're establishing a new program or auditing an existing one.

Conduct a risk analysis and build your safeguards

Your risk analysis is the foundation of your entire compliance program and the first element regulators examine during an investigation. You need to document every location where your organization creates, receives, stores, or transmits ePHI, then identify the threats to that data and assess the controls you currently have in place. Without this step completed in writing, you cannot make defensible decisions about which safeguards to implement or demonstrate to HHS that your program reflects a genuine assessment of your environment.

A risk analysis is not a one-time exercise. Repeat it whenever you introduce new systems, change vendors, or expand your application's scope.

Once your analysis identifies gaps, implement the administrative, physical, and technical safeguards the Security Rule requires, and document all of them. Regulators expect written policies, configuration records, and evidence that your controls are actively enforced. Intention without documentation offers you no protection when an investigation begins.

Train your staff and execute your agreements

Workforce training must cover how your policies work in daily practice, not just the legal text behind them. Every staff member who can access ePHI needs to complete security awareness training, and your records need to prove it happened. Generic annual videos rarely satisfy this requirement; your training should map directly to your documented policies and real workflows.

Before sharing any ePHI with a vendor, confirm that a signed Business Associate Agreement is in place. This applies to cloud providers, integration platforms, billing services, and any subcontractors those vendors use downstream. Operating without these agreements puts you in violation even when no breach occurs, so treat unsigned BAAs as a compliance gap that needs immediate resolution.

Test your incident response process

Your breach notification procedures need to be tested before an incident surfaces, not drafted in response to one. Run through a simulated breach scenario at least once per year to confirm your team knows exactly when to notify affected individuals, your business associates, and HHS within the required timeframes. Documented test results with recorded findings serve as concrete evidence of a functioning compliance program and demonstrate the kind of sustained operational discipline that stands up under regulatory review.

What counts as a HIPAA violation and penalties

A violation occurs any time your organization fails to meet a HIPAA requirement, regardless of whether a breach actually results. Regulators do not require harm to patients to impose penalties; the failure to implement required safeguards, execute a missing BAA, or train staff adequately is itself a violation. Understanding what is HIPAA compliance fully means recognizing that enforcement targets the absence of controls just as much as it targets data theft or accidental disclosure.

Common types of HIPAA violations

Violations fall into two broad categories: willful neglect and reasonable cause. Willful neglect means your organization knowingly failed to meet a requirement or showed reckless disregard for patient data. Reasonable cause means a violation occurred despite your good-faith efforts, but your safeguards were still insufficient. Most enforcement actions stem from predictable, preventable operational failures rather than sophisticated attacks.

The most frequently cited violations include:

• Unauthorized access or disclosure: sharing PHI with parties who have no permitted need for it
• Missing or expired Business Associate Agreements: transmitting ePHI to vendors without a signed BAA in place
• Insufficient access controls: failing to restrict ePHI access based on job role or leaving terminated accounts active
• Inadequate risk analysis: operating without a documented, current assessment of your ePHI environment
• Lack of workforce training: employees handling PHI without completing required security awareness training
• Failure to encrypt ePHI: transmitting or storing patient data without appropriate encryption controls

A single misconfigured cloud storage bucket that exposes patient records publicly can trigger both a Breach Notification obligation and a Security Rule violation simultaneously.

Penalty tiers and enforcement

HHS enforces HIPAA through the Office for Civil Rights (OCR), which investigates complaints and conducts audits. Penalties are tiered based on the level of culpability your organization demonstrates. At the lowest tier, violations your organization was unaware of and could not have reasonably avoided carry minimum fines of $100 per violation. At the highest tier, violations resulting from willful neglect that your organization did not correct carry minimums of $50,000 per violation, with annual caps reaching $1.9 million per violation category.

Criminal penalties apply when individuals knowingly obtain or disclose PHI in violation of HIPAA. Offenses committed under false pretenses or for personal gain can result in prison sentences of up to 10 years. Beyond government action, a HIPAA violation can also expose your organization to state attorney general enforcement and the reputational damage that follows a publicly disclosed breach.

HIPAA compliance for APIs, cloud, and FHIR apps

Modern healthcare applications rarely store or process data in isolation. They call external APIs, run on shared cloud infrastructure, and exchange patient records through standards like FHIR (Fast Healthcare Interoperability Resources). This architecture creates compliance obligations at every layer of the stack, and understanding what is HIPAA compliance in this context means recognizing that each component handling ePHI carries its own set of Security Rule requirements, regardless of whether you built it yourself or licensed it from a vendor.

APIs that transmit ePHI

Every API call that carries patient data is a transmission of ePHI, and the Security Rule's technical safeguard requirements apply the moment that data moves. Your API endpoints must enforce TLS encryption in transit, require authenticated and authorized requests tied to individual user identities, and produce audit logs that record who accessed what and when. OAuth 2.0 is the standard authorization mechanism for healthcare APIs, but implementing it correctly in a HIPAA context requires more than just issuing tokens. You need to enforce token expiration, scope restrictions, and revocation procedures that your audit trail can verify.

An API that transmits ePHI without logging each request and response at the user level creates an audit gap that regulators will treat as a Security Rule deficiency.

Cloud infrastructure and shared responsibility

Running your application on a major cloud provider does not automatically make you HIPAA compliant. Providers like Microsoft Azure and Amazon Web Services offer HIPAA-eligible services and will sign Business Associate Agreements, but the compliance responsibility is shared. Your cloud provider secures the underlying infrastructure; you are responsible for how you configure services, manage access, and protect data within your environment. A misconfigured storage bucket or an overly permissive IAM policy is your problem, not your provider's, even when both parties have signed a BAA.

FHIR apps and the SMART on FHIR standard

SMART on FHIR is the authorization framework healthcare organizations use to let third-party applications connect securely to EHRs. Building a SMART on FHIR application means implementing OAuth 2.0 authorization flows, handling patient consent, and managing token lifecycles in a way that satisfies both the EHR vendor's requirements and HIPAA's Security Rule. Each EHR system, whether Epic, Cerner, or Allscripts, has its own configuration requirements and approval processes, which means your integration work multiplies with each new EHR connection. Platforms like SoFaaS™ address this directly by providing pre-built connectors, a unified API, and managed HIPAA-compliant infrastructure so your team can integrate with major EHRs in days without rebuilding security controls for each one.

Key takeaways and next steps

Understanding what is HIPAA compliance comes down to one core idea: if your organization handles protected health information, you are legally required to implement specific safeguards and maintain them over time. Covered entities and business associates both carry direct liability, and the penalties for gaps in your program can be severe, whether those gaps involve missing Business Associate Agreements, insufficient encryption, or untrained staff.

Your compliance program needs to cover all three safeguard categories: administrative, physical, and technical. It requires documented risk analyses, signed vendor agreements, trained staff, and tested incident response procedures. For technology teams building healthcare applications on FHIR, the compliance burden extends to every API call and every cloud service that touches ePHI.

If you're building a SMART on FHIR application and want to skip months of integration and compliance groundwork, launch your SMART on FHIR app on a compliant managed platform and connect to major EHRs in days, not months.