Healthcare IT Compliance

What is healthcare IT compliance?

Healthcare IT compliance is the work of building and running health software so it meets the federal and state rules that apply to it, mainly HIPAA, information blocking, 42 CFR Part 2, the FTC Health Breach Notification Rule and accessibility law, and of keeping the technical evidence that shows those controls work.

Policies still matter, but they do not stop a developer from publishing an open storage bucket. The controls that do stop it live in infrastructure code, identity settings and the CI pipeline, so that is where most of the compliance work sits.

Which federal rules apply to health software?

The rules that apply depend on who you are and whose data you hold. A vendor building for a hospital, a consumer app and a substance use treatment program each sit under a different mix.

• HIPAA Security Rule: Covered entities and business associates must apply administrative, physical and technical safeguards to ePHI under 45 CFR Part 164 Subpart C, including a documented risk analysis under 164.308(a)(1)(ii)(A).
• Business associate contracts: A vendor that creates, receives, maintains or transmits PHI for a covered entity needs a business associate agreement under 45 CFR 164.502(e), with required terms in 164.504(e).
• 42 CFR Part 2: The HHS final rule of February 2024 aligned substance use disorder record consent more closely with HIPAA, with compliance required by 16 February 2026, while keeping limits on use in legal proceedings.
• FTC Health Breach Notification Rule: Vendors of personal health records that are not covered by HIPAA must notify users and the FTC after a breach of identifiable health data under 16 CFR Part 318, as amended effective 29 July 2024.
• Section 504 accessibility: Organizations that receive HHS federal financial assistance must make their web content and mobile apps conform to WCAG 2.1 Level AA under 45 CFR 84.84. Those with at least 15 employees must comply by 11 May 2027, and the rest by 10 May 2028.

Two more regimes sit beside these. Section 1557 at 45 CFR 92.210 bars covered entities from discriminating through patient care decision support tools, and FDA device rules apply when software meets the device definition rather than the clinical decision support carve-out in FDA's January 2026 guidance.

Who does information blocking actually cover?

The information blocking rule in 45 CFR Part 171 applies only to actors: health care providers, developers of certified health IT, and health information networks or exchanges. A startup that sells software to a clinic is not an actor just because its customer is one.

The rule also works as a prohibition, not a publishing mandate. A practice that is likely to interfere with access, exchange or use of electronic health information can be information blocking unless an exception applies.

For a vendor, the practical effect is indirect. Your provider customers carry the duty, so features you ship, such as a portal that holds results or an export that is slow by design, can put them at risk. Build release timing, export paths and access denials so a customer can explain each one against an exception.

The HTI-5 final rule, published on 28 October 2026, revised the certification program but did not change Part 171. Certified health IT developers should still review which certification criteria HTI-5 removed or revised before planning their next certification cycle.

What does the Security Rule require, and what is addressable?

The HIPAA Security Rule splits its technical safeguards in 45 CFR 164.312 into required and addressable specifications. Addressable does not mean optional: you implement it, or you document why an equivalent measure is reasonable.

• Required: Unique user identification, an emergency access procedure, audit controls and person or entity authentication.
• Addressable: Automatic logoff, encryption and decryption of ePHI at rest, an integrity mechanism and encryption in transmission.
• Technology-neutral: The rule does not name MFA, OAuth, TLS, role-based access control or immutable logs. Those are design choices you make to meet it.
• Proposed change: The HHS Security Rule proposed rule of January 2025 would make MFA and encryption required. Until a final rule says so, MFA is strong practice rather than a legal duty.

Two common misreadings cost teams time. First, the six-year retention period in 164.316(b)(2) covers policies, procedures and required documentation, not every audit log line. Set log retention from your risk analysis, contracts and state law instead, and record the reasoning so a reviewer can follow it. Second, minimum necessary is a Privacy Rule standard at 164.502(b), not a Security Rule control, though access design is how you meet it.

Building the program in six steps

• 1. Draw the data flow: List every screen, API, queue, database, log sink and vendor that touches identifiable health data, and mark which rule applies to each hop.
• 2. Settle contracts and prune vendors: Sign a business associate agreement with each vendor that handles PHI for you, and remove SDKs, trackers or tools whose vendor will not sign and that care delivery does not need.
• 3. Codify the infrastructure baseline: Use Terraform or similar code for private networks, encryption keys, backups and least-privilege roles, and add policy checks in CI that block a public bucket or an unencrypted volume before merge.
• 4. Build application controls: Give every user a unique identity, check record ownership on every API call, and write a structured audit event for each PHI read, change and export with actor, role, patient, resource, time and source.
• 5. Automate the evidence: Connect cloud accounts, source control, the identity provider and HR offboarding to a monitoring platform so drift opens a ticket the same day.
• 6. Test the response: Run a breach-notification tabletop under 45 CFR Part 164 Subpart D, act on penetration test findings, and test key patient flows against WCAG 2.1 AA with a screen reader.

Where compliance programs break down

Most failures are ordinary configuration and contract gaps rather than advanced attacks. The list below is a failure-point check to run before a hospital review.

• Shared responsibility misread: Hosting on a cloud with a BAA covers the provider's part. Your team still configures eligible services, keys, IAM, network isolation and application logs.
• PHI in logs and prompts: Full request payloads in application logs, crash reports or prompts sent to a model endpoint with no BAA put PHI where no safeguard was planned.
• Trackers on patient pages: Analytics or advertising tags on intake, booking or portal pages can disclose PHI to a vendor with no agreement in place.
• Real PHI in staging: Production copies in test environments carry the full Security Rule burden, and staging rarely has it. Synthetic data, for example from Synthea, avoids the problem.
• A risk analysis that stops at launch: New integrations, AI features and microservices change the risk picture, and 164.308(a)(1) expects the analysis to track them.
• Slow offboarding: Contractor accounts left active in the cloud console, source control or the EHR after departure are an access control failure.
• State law left out: Washington's My Health My Data Act and similar state laws can add consent duties that HIPAA does not impose.

What evidence do hospital security reviewers ask for?

Hospital security reviewers usually ask for architecture and data-flow diagrams, the vendor and BAA inventory, the latest risk analysis, a penetration test summary and the incident response plan. Keeping these current turns a review into a document handover rather than a sprint.

• Access evidence: Role definitions, the last quarterly access review and proof that departed users lost access.
• Encryption evidence: Which stores are encrypted, who holds the keys and how keys rotate, or the documented reason an addressable control was met another way.
• Logging evidence: A sample audit event, where logs are stored, who can alter them and how long they are kept.
• Change evidence: Pull-request approval rules, dependency scanning results under NIST SP 800-218 practices and the release record.
• Accessibility evidence: A WCAG 2.1 AA test report for patient-facing flows if the customer receives HHS funding.

HHS does not issue a HIPAA certification, so no badge replaces this packet. Third-party attestations such as SOC 2 or HITRUST can support it, but reviewers still read the underlying controls. Keep one owner for the packet and date every document in it, so a stale diagram never reaches a buyer.

How Agnotic can help

Compliance evidence is most credible when the system produces it. Agnotic Technologies builds that layer for healthcare software teams: audit event schemas, ownership checks in the API, policy-as-code in the delivery pipeline and the Sprinto integrations that turn cloud and identity settings into daily checks.

Agnotic can also map your data flows against the rules above, close the gaps a hospital questionnaire will find, and set up the evidence packet your sales team hands to reviewers.

Sources

• 45 CFR 164.312: HIPAA Security Rule technical safeguards
• 45 CFR 164.316: Policies, procedures and documentation retention
• Federal Register: HIPAA Security Rule proposed rule (January 2025)
• 45 CFR 171.102: Information blocking definitions, including actors
• HHS: 42 CFR Part 2 final rule fact sheet
• FTC: Health Breach Notification Rule, 16 CFR Part 318
• Federal Register: Section 504 web and mobile accessibility compliance date extension (May 2026)
• NIST SP 800-218: Secure Software Development Framework