Health data privacy, security and software rules for health-tech vendors and their clients: HIPAA, HITECH, HITRUST, 21 CFR Part 11, IEC 62304, ABDM and information blocking.
Health data is among the most protected categories of data in every jurisdiction, and health software carries extra rules when it affects patient safety or regulated records. Health-tech companies usually meet these rules through their customers: a hospital, clinic, insurer or pharmaceutical company that is itself regulated and passes obligations down by contract.
United States
HIPAA's Privacy, Security and Breach Notification Rules apply to covered entities and to their business associates, which includes most software vendors that create, receive, maintain or transmit protected health information for them. The HITECH Act strengthened enforcement and made business associates directly liable. HITRUST is a voluntary, certifiable framework that many US health organisations ask vendors for. The 21st Century Cures Act information blocking rules affect health IT developers and the exchange of electronic health information.
Regulated records and medical software
21 CFR Part 11 sets FDA requirements for electronic records and signatures in regulated activities such as clinical trials and manufacturing. IEC 62304 defines software life cycle processes for medical device software and is widely used to show conformity under medical device regulations.
India
The Ayushman Bharat Digital Mission sets technical and policy requirements for systems that connect to India's digital health network, alongside the DPDP Act, which governs personal data generally.
Common engineering ground
Across all of them, auditors look for access control by role, complete audit trails, encryption, integrity of records, breach detection, and a documented way of handling patient requests.
United States, applying to electronic records and signatures used to meet FDA requirements, including by companies outside the US that submit data to FDA or make FDA-regulated products.
India. Applies to hospitals, clinics, labs, pharmacies, health apps and software vendors that choose to integrate with ABDM, and to government health programmes that require it.
National Health Authority (NHA), Ministry of Health and Family Welfare
Title 21 Code of Federal Regulations Part 11: Electronic Records; Electronic Signatures (US Food and Drug Administration)
21 CFR Part 11 sets the conditions under which the FDA accepts electronic records and electronic signatures as equivalent to paper records and handwritten signatures. It requires validated systems, secure computer-generated audit trails, access and authority controls, record protection and retention, and controls for unique, verified electronic signatures linked to records. FDA guidance narrows its scope, applies risk-based thinking, and, for device makers, promotes computer software assurance over heavy documentation.
Information blocking provisions of the 21st Century Cures Act (Section 4004) and HHS rules at 45 CFR Part 171
The information blocking provisions of the 21st Century Cures Act prohibit practices that are likely to interfere with access, exchange or use of electronic health information, unless required by law or covered by a regulatory exception. They apply to health care providers, certified health IT developers and health information networks. Developers and networks face civil penalties of over $1 million per violation, providers face Medicare disincentives, and HHS stepped up enforcement in 2025 and 2026.
Ayushman Bharat Digital Mission (ABDM) and its Health Data Management Policy, with integration standards for health information providers and users
The Ayushman Bharat Digital Mission is India's national digital health ecosystem. It gives people an ABHA health ID, registers health professionals and facilities, and lets health records move between providers and apps only with the patient's consent, through a federated network where records stay with the providers that created them. Its Health Data Management Policy sets rules on consent, privacy, security and data rights, and software must follow ABDM standards and pass sandbox certification to integrate.
Health Insurance Portability and Accountability Act of 1996: Privacy, Security and Breach Notification Rules (45 CFR Parts 160 and 164)
HIPAA is the US federal law that protects health information held by health plans, healthcare clearinghouses and most healthcare providers, and by their business associates, which include many software, cloud and IT vendors. Its Privacy Rule limits uses and disclosures of protected health information, its Security Rule requires administrative, physical and technical safeguards for electronic health information, and its Breach Notification Rule sets deadlines for reporting breaches. Compliance is mandatory where it applies.
Health Information Technology for Economic and Clinical Health Act (Title XIII of the American Recovery and Reinvestment Act of 2009)
The HITECH Act is a 2009 US law that pushed adoption of electronic health records and strengthened HIPAA. For IT vendors, its key effects are that business associates became directly liable for HIPAA Security Rule compliance, breaches of unsecured health information must be notified, penalties were increased in tiers, state attorneys general can enforce HIPAA, and, since a 2021 amendment, regulators must consider recognised security practices an organisation had in place when setting penalties.
HITRUST Common Security Framework (CSF) and HITRUST e1, i1 and r2 assessments and certifications
HITRUST is a private security and privacy framework and certification program widely used in US healthcare. Its Common Security Framework harmonises requirements from HIPAA, NIST, ISO, PCI DSS and other sources into one control set, and its e1, i1 and r2 assessments offer increasing levels of assurance, validated by authorised assessors and HITRUST quality review. It is voluntary and not a government certification, but many health systems and payers require HITRUST from vendors that handle patient data.
IEC 62304: Medical device software, Software life cycle processes (Edition 1.1, IEC 62304:2006+AMD1:2015)
IEC 62304 defines the software life cycle processes for medical device software, including standalone software as a medical device. It classifies software into safety classes A, B and C based on the harm a failure could cause, then scales requirements for planning, requirements, architecture, design, implementation, verification, release, maintenance, risk management, configuration management and problem resolution. Regulators in the US and EU expect conformance, and a second edition broadening scope to health software is in development.
No. HHS does not certify or endorse HIPAA compliance. Third-party assessments and frameworks such as HITRUST can provide evidence, but they are not a government certification.
Does HIPAA apply to a software vendor outside the US?
It can, through a business associate agreement with a US covered entity or business associate. The agreement makes you contractually and, under HITECH, legally responsible for safeguarding the data.
When does health software count as a medical device?
It depends on its intended purpose and the rules in each market. Software that diagnoses, treats or monitors patients can be regulated as a medical device. The IEC 62304 guide explains where to check.
We build the parts auditors and privacy laws look for: role-based access, audit logs, encryption, consent records, data export and erasure, and secure development practices. Tell us about your product and get a free quote within one business day.
