HIPAA, FHIR, and other healthcare compliance requirements serve distinct purposes and do not substitute for one another. HIPAA is a federal law that establishes privacy and security obligations for covered entities and their business associates when they handle protected health information. FHIR is a technical standard for structuring and exchanging healthcare data -- it defines how information is represented and transmitted, not who can access it or under what legal conditions. Healthcare compliance is broader than either: it also encompasses applicable state privacy laws, FDA medical device requirements, interoperability mandates, and the contractual obligations that arise from specific vendor relationships.
Buyers should determine which requirements apply to their specific product, data, organization, and intended use -- not assume that a single law or standard covers everything they need to address.
Featured snippet: Before engaging a healthcare software vendor, buyers should verify how the vendor handles protected health information, what safeguards it maintains, whether a business associate agreement is needed, which FHIR version and implementation guides apply, how integrations will be tested and accepted, and what documentation confirms the vendor's security responsibilities. Neither a signed BAA nor FHIR support alone establishes full compliance readiness.
HIPAA, FHIR, and healthcare compliance address different questions, and confusing them leads to real gaps in planning. HIPAA is a privacy and security law. FHIR is a data-exchange standard. Healthcare compliance is the broader set of legal, contractual, and regulatory obligations that may apply to a given product or organization -- which often goes well beyond HIPAA and FHIR alone.
The Health Insurance Portability and Accountability Act (HIPAA) establishes national standards for the privacy and security of protected health information (PHI). It applies to covered entities -- health plans, healthcare clearinghouses, and healthcare providers that electronically transmit health information in connection with covered transactions -- and to business associates, entities that create, receive, maintain, or transmit PHI on behalf of a covered entity in performing services for it. The HIPAA Privacy Rule (45 CFR Part 164, Subparts A and E) governs permitted uses and disclosures of PHI. The HIPAA Security Rule (45 CFR Part 164, Subparts A and C) sets requirements for protecting electronic PHI (ePHI) through administrative, physical, and technical safeguards. The Breach Notification Rule (45 CFR §§ 164.400--414) establishes when and how covered entities and business associates must notify individuals and regulators of breaches of unsecured PHI.
Fast Healthcare Interoperability Resources (FHIR, pronounced "fire") is a standard published by Health Level Seven International (HL7) for representing and exchanging healthcare information electronically. FHIR organizes information into defined units called resources -- Patient, Observation, MedicationRequest, Encounter, and hundreds of others -- which can be combined, referenced, and exchanged through APIs. FHIR R4 (Release 4) is the version most widely implemented in the United States for regulatory and integration purposes, though R5 is the current published specification. FHIR does not define who may access patient information or under what legal conditions -- it defines how that information is structured and exchanged. Using FHIR does not, by itself, make an application secure or HIPAA-compliant.
Healthcare compliance encompasses the full set of obligations that may apply to a given product, organization, and engagement -- which extends beyond HIPAA and FHIR to include state consumer health data privacy laws, FDA requirements for software functions that may qualify as medical devices, applicable ONC and CMS interoperability requirements, FTC health-data rules for consumer apps outside HIPAA's scope, and the contractual obligations that specific healthcare customers impose. Which requirements apply depends on the organization's role, the product's intended use, the type of data involved, and the applicable legal and regulatory framework. Identifying what applies to a particular product is the first task in healthcare compliance -- not selecting a checklist and working through it.
| Concept | Primary purpose | What it affects | What a buyer should verify |
|---|---|---|---|
| HIPAA | Federal law governing privacy and security of PHI for covered entities and their business associates | Who may use and disclose PHI, how ePHI must be protected, when breaches must be reported, and when a BAA is required | Whether the vendor qualifies as a business associate; BAA coverage; safeguards in place; breach notification obligations |
| FHIR | Technical standard for structuring and exchanging healthcare data using defined resources and APIs | How information is represented, what APIs systems expose, which data elements can be exchanged, and how integrations are built | Which FHIR version and implementation guides apply; which resources and operations are supported; how the integration will be tested and accepted |
| Healthcare compliance (broader) | The full set of legal, regulatory, and contractual obligations applicable to a specific product, organization, and data type | Which laws and regulations apply, which certifications or interoperability requirements are relevant, and what contractual obligations healthcare customers impose | Which requirements apply to this specific product and engagement; whether qualified legal, privacy, and regulatory review has been completed |
HIPAA applies to covered entities and to business associates that create, receive, maintain, or transmit PHI on a covered entity's behalf -- it does not automatically apply to every application that handles health-related information. Whether a specific software project or vendor relationship requires HIPAA compliance depends on the role of the organizations involved and the nature of the data flows in that specific engagement.
A healthcare provider that electronically submits insurance claims is a covered entity. A software development firm that builds that provider's patient portal and, in doing so, has access to patient records is typically a business associate. The same development firm building a general wellness app for a consumer-facing startup that has no relationship with a covered entity may not be a business associate at all -- even if the app stores health-related information.
The analysis depends on the actual facts. Key questions include: Does the organization creating or buying the software qualify as a covered entity? Does the vendor's role involve creating, receiving, maintaining, or transmitting PHI on behalf of that covered entity? Do the vendor's hosting, support, analytics, integration, or maintenance activities involve PHI? If a vendor has access to production systems, receives patient data for testing or integration purposes, or operates software that processes PHI as part of its contracted services, a business associate relationship -- and a BAA -- may be needed.
Two additional points are commonly overlooked. First, HIPAA is not the only privacy law that may apply to health-related data. State laws -- including Washington's My Health MY Data Act and similar legislation in other states -- may impose requirements on products and organizations outside HIPAA's scope. The FTC Act and the FTC Health Breach Notification Rule (as amended in 2024) may apply to health apps and consumer services that are not subject to HIPAA, including direct-to-consumer health apps and personal health record services. Second, the analysis must be based on actual data flows and vendor responsibilities -- not on what a vendor calls itself or how it markets its services.
Browse verified provider reports covering HIPAA-compliant development, healthcare app builds, EHR integration, and healthcare AI -- organized by documented capability.
A healthcare software development partner that understands compliance approaches architecture, data handling, security practices, and documentation differently from one whose experience is primarily in other industries. The right partner brings genuine healthcare experience -- not just general engineering capability paired with a compliance checklist.
Key areas to assess before committing to an engagement include: the vendor's experience delivering healthcare software development projects with documented compliance requirements; its approach to HIPAA-compliant software development, including how it manages data access, environment controls, and security responsibilities; its FHIR and EHR integration experience and its track record with specific systems; its security documentation and evidence of ongoing risk management; its approach to testing, particularly for integrations involving PHI; and how it structures contractual responsibilities for compliance obligations.
Buyers evaluating healthcare app developers should look beyond marketing language. Ask for specific examples of comparable projects, documented security practices, evidence of security assessments, and a clear explanation of how the vendor will handle PHI in this engagement. A vendor that cannot explain which party is responsible for specific safeguards before signing is unlikely to resolve that ambiguity more cleanly once the project begins.
If your project involves healthcare AI, the evaluation adds a further dimension: data sourcing, model governance, clinical validation, and ongoing monitoring responsibilities. Buyers planning healthcare AI development should define those requirements before selecting a partner, not after. Understanding realistic healthcare software development costs -- broken down by project type and compliance scope -- also helps buyers set realistic budgets and evaluate vendor proposals more accurately.
HIPAA imposes specific requirements on covered entities and business associates regarding how they protect and handle PHI. The requirements vary by role: a covered entity's obligations differ from a business associate's, and the specific controls required depend on an organization's size, systems, risk profile, and the nature of the PHI it handles. What follows is an overview of the major areas -- not a complete compliance program for any specific organization.
The Privacy Rule restricts how covered entities and their business associates may use and disclose PHI. It requires appropriate safeguards for PHI, gives individuals certain rights over their health information (including the right to access and request corrections), and establishes a minimum-necessary standard for using and disclosing PHI -- organizations should use or disclose only the information reasonably needed for the stated purpose. Business associates are contractually bound to similar restrictions through their BAAs, and they must flow down these requirements to subcontractors that handle PHI on their behalf.
The Security Rule requires covered entities and business associates to protect the confidentiality, integrity, and availability of ePHI through administrative, physical, and technical safeguards (45 CFR Parts 160 and 164, Subparts A and C). It requires a documented risk analysis -- identifying risks to ePHI -- and ongoing risk management to reduce those risks to a reasonable level. Specific requirements include access controls, audit controls and activity monitoring, authentication, and transmission security. A January 2025 proposed rule would strengthen the Security Rule's cybersecurity requirements further, though as of this writing it has not been finalized.
The Security Rule does not prescribe specific technologies. It sets requirements for what must be achieved and gives covered entities and business associates flexibility in how they meet them -- with the expectation that controls are appropriate for the organization's size, complexity, and risk environment. Implementing a specific security tool or obtaining a certification does not, by itself, satisfy the Security Rule.
When a breach of unsecured PHI occurs, covered entities must notify affected individuals, the HHS Secretary, and -- in the case of breaches affecting more than 500 residents of a state -- the media, all within 60 days of discovery (45 CFR §§ 164.400--414). Business associates must notify the covered entity without unreasonable delay and no later than 60 days after discovery. A breach is generally an impermissible use or disclosure of PHI that compromises its security or privacy, unless a documented risk assessment shows a low probability of compromise.
A BAA is a required contract when a covered entity engages a business associate. It documents the business associate's permitted uses and disclosures of PHI, its safeguard obligations, its breach notification responsibilities, and what happens to PHI at termination. A signed BAA documents the parties' obligations -- it does not verify that the business associate's actual practices comply with them. Buyers should separately evaluate whether a vendor's controls are consistent with what the BAA requires. For a detailed breakdown of what a BAA and SOW should contain, see TechRadiant's BAA and SOW buyer's checklist.
FHIR helps healthcare systems exchange data by providing a standardized way to represent clinical and administrative information as discrete, reusable units -- resources -- that can be queried, combined, and transmitted through standard web APIs. Two systems that both implement FHIR can exchange information in a consistent format without requiring custom data transformations for every integration.
A FHIR resource represents a specific concept: a Patient resource holds demographics and identifiers; an Observation resource holds a clinical measurement like a lab result or vital sign; an Encounter resource represents a clinical visit. Resources include structured data elements, codes from standard vocabularies (SNOMED CT, LOINC, ICD-10), and references to related resources. A FHIR API exposes these resources through standard HTTP operations -- read a specific patient, search for observations by date, create a new medication request.
Implementation guides layer additional rules on top of the base FHIR specification for specific use cases. The HL7 US Core Implementation Guide, for example, defines minimum conformance requirements for FHIR resources in the United States, aligned with the U.S. Core Data for Interoperability (USCDI). The SMART App Launch Framework (SMART on FHIR) adds authorization and authentication conventions using OAuth 2.0 and OpenID Connect, enabling third-party apps to request controlled access to FHIR data.
FHIR does not guarantee that two systems can exchange every piece of required clinical information without additional work. EHR vendors implement FHIR in different ways, support different resource types and search parameters, and may map local data to FHIR resources differently. Terminology differences, identity-matching challenges, authorization configurations, and unsupported operations all require assessment during an actual integration project. "Supports FHIR" is a starting point for a conversation, not a guarantee of interoperability.
Buyers should define FHIR integration requirements in writing before selecting a vendor or approving a development scope. A vague requirement such as "the product must support FHIR" is not sufficient for planning -- it does not specify which version, which resources, which operations, which implementation guide, or how the integration will be tested and accepted.
A practical pre-integration checklist:
Two systems both advertise FHIR R4 support. System A maps diagnoses to ICD-10-CM codes. System B stores diagnoses using SNOMED CT. Both are valid under base FHIR R4 -- but when System A sends a Condition resource to System B, System B cannot process the code without a terminology translation step that neither system automatically provides.
The integration works in the sense that a FHIR resource is transmitted and received -- but the receiving system cannot reliably use the clinical data it contains without additional mapping work. A buyer who specified "must support FHIR R4 Condition resources" without specifying required code systems and translation responsibilities would discover this gap during testing, not during vendor selection.
HIPAA and FHIR address different layers of a healthcare system and must both be addressed in a compliant FHIR-based implementation. FHIR defines how data is structured and exchanged; HIPAA governs whether that exchange is permitted and what safeguards must protect the data. Neither replaces the other.
In a FHIR implementation that involves PHI, the following areas require attention from both a technical and a compliance perspective:
The ONC 21st Century Cures Act Final Rule requires certified health IT developers to support FHIR R4 APIs that enable patients and authorized third parties to access their health information. The CMS Interoperability and Patient Access Final Rule similarly requires certain payers to implement FHIR-based Patient Access and Provider Directory APIs. These requirements are separate from HIPAA -- they impose interoperability obligations on specific categories of organizations, independent of HIPAA's privacy and security framework.
HIPAA is not the only compliance requirement that healthcare software products may face. Whether these additional requirements apply depends on the product's type, the data it handles, its intended users, and the organization's role -- not every requirement listed here applies to every product.
Several states have enacted health data privacy laws that apply to organizations not covered by HIPAA, or that impose additional requirements beyond HIPAA. Washington's My Health MY Data Act (effective March 2024 for most organizations) is among the most expansive, extending privacy protections to consumer health data regardless of HIPAA applicability. Buyers building consumer-facing health applications should assess applicable state law obligations early, before product launch, rather than treating HIPAA compliance as an automatic substitute.
The FTC Health Breach Notification Rule, as amended in 2024, applies to vendors of personal health record (PHR) applications and related services that are not covered by HIPAA. As amended, it explicitly reaches health apps, websites, and other direct-to-consumer services that hold health information and have the technical capacity to draw from multiple sources. A breach under the amended rule is not limited to cyberattacks -- it includes unauthorized disclosures such as sharing data with advertising vendors. Consumer health apps that fall outside HIPAA's scope should assess whether this rule applies.
The FDA regulates software functions that meet the definition of a medical device. Software intended to diagnose, treat, cure, mitigate, or prevent disease or other conditions -- or to affect the structure or function of the body -- may qualify as a Software as a Medical Device (SaMD) and may require FDA premarket review. General wellness apps and clinical decision support software that meets certain criteria may fall outside FDA's active enforcement discretion, but this depends on the specific intended use. Buyers building or procuring software with any clinical decision-making function should assess FDA applicability before development, not after. For a detailed explanation, see TechRadiant's guide on when a health app needs FDA clearance.
The ONC 21st Century Cures Act Final Rule establishes information-blocking prohibitions and health IT certification requirements for certain categories of actors -- health IT developers of certified health IT, healthcare providers, health information exchanges, and health information networks. Certified EHR technology must meet specific FHIR API requirements. Organizations developing or procuring health IT that may be subject to these rules -- or that will integrate with certified EHR systems -- should assess whether any information-blocking or certification requirements apply to their role and activities.
Even where a specific regulation does not directly apply to a vendor, healthcare customers routinely require compliance with HIPAA safeguards, specific security standards (such as NIST, HITRUST, or SOC 2), audit rights, and other security and privacy obligations as conditions of their contracts. These contractual obligations may impose requirements on a vendor that are broader or more specific than what applicable law alone would require. For a comparison of HIPAA with HITRUST and SOC 2, see TechRadiant's overview of HIPAA vs HITRUST vs SOC 2.
Buyers should evaluate a vendor's compliance claims by asking for specific, verifiable evidence -- not accepting general statements such as "we are HIPAA-compliant" or "we follow best practices." The questions below help distinguish vendors with genuine healthcare experience and documented controls from those with only a marketing claim.
A vendor's certifications provide useful context but should not substitute for these questions. A SOC 2 Type II report describes a vendor's controls at a specific point in time within a defined scope -- it is not an assessment of fitness for your particular engagement.
A pre-development compliance checklist helps buyers identify gaps before architecture decisions are made and before a vendor is selected -- when changes are least expensive and most effective. This checklist is a planning tool, not a guarantee of compliance or a substitute for qualified expert review.
The most common healthcare compliance mistakes in software projects are not obscure -- they are predictable gaps that arise from planning assumptions that seem reasonable but do not hold under the actual facts of the engagement.
Buyers planning a healthcare software project -- whether building with an external development partner or procuring an existing product -- should work through the following questions before making commitments. These are suitable for a vendor evaluation meeting or a project-planning session.
The most effective compliance and interoperability planning happens before architecture decisions are made, before a vendor is selected, and before development begins. The steps below give buyers a practical starting point.
TechRadiant's verified reports cover HIPAA-compliant development, healthcare app development, EHR integration, and healthcare AI -- organized by documented capability across service categories and market segments.
The questions below address what buyers most often ask when beginning to plan a healthcare software project or evaluate a development partner. Each answer is a concise summary -- specific situations require qualified professional review.
Human-verified rankings across AI, development, and marketing — updated quarterly.
