US health IT developers face two security-relevant regimes from HHS's Assistant Secretary for Technology Policy and Office of the National Coordinator for Health IT (ASTP/ONC): the certification criteria in 45 CFR 170.315, and the information blocking rules in 45 CFR Part 171 that decide when a security control becomes an unlawful barrier to data access. The Health Data, Technology, and Interoperability (HTI) rules have reshaped both, and the latest, HTI-5, was released on 26 October 2026, so many teams are now checking what changed. This guide is for security, product and compliance teams at certified health IT developers, health information networks and exchanges, and providers. It covers the privacy and security certification criteria, the security exception to information blocking, and how to design controls that satisfy both. It does not repeat HIPAA; see the HIPAA Security Rule Guide and the Healthcare Cyber Regulation Map.
Source note: the 45 CFR text and HHS OIG pages were read directly (eCFR, current as of 22 and 23 October 2026). The HTI-5 final rule text itself could not be accessed, so the HTI-5 summary is based on secondary sources: client alerts from McGuireWoods and Holland & Knight, both dated October 2026. Figures and dates from HTI-5 are included only where both agree. Confirm against the official text before relying on it.
Key takeaways
- The privacy and security criteria survived HTI-5. Both law firm summaries report that HTI-5 kept the privacy and security certification criteria.
- Thirteen criteria set the security baseline. 45 CFR 170.315(d)(1) to (d)(13) cover authentication and authorisation, tamper-resistant auditing, time-out, device encryption, integrity, trusted connections, credential encryption and MFA attestations.
- Security can justify limiting access, under conditions. The 45 CFR 171.203 security exception protects a practice only if it is directly related to safeguarding EHI, tailored to the risk, and applied consistently, plus either a written policy or a case-by-case determination.
- Information blocking penalties are real. HHS OIG can impose civil monetary penalties of up to $1 million per violation for conduct from 1 September 2023, and providers face separate disincentives under Part 171 Subpart J.
- Information blocking changes were deferred. HTI-5 did not finalise its proposed information blocking changes, so the existing exceptions and penalties apply.
The HTI rules in brief
| Rule | Security-relevant content | Status as of November 2026 |
|---|---|---|
| HTI-1 | Created the decision support interventions criterion at 170.315(b)(11) with source attribute and risk management requirements for predictive tools; updated certification and information blocking provisions | Final; DSI provisions narrowed by HTI-5 |
| HTI-3 (Protecting Care Access) | Added the Protecting Care Access exception at 171.206 | Final; exception appears in current eCFR |
| HTI-4 | Added criteria for electronic prior authorisation | Final |
| HTI-5 (Deregulatory Actions to Unleash Prosperity) | Removed 14 of 60 certification criteria and revised 7; narrowed DSI; kept privacy and security criteria | Released 26 October 2026; changes take effect in stages, with later stages on 1 January 2027 and, for one change, 1 January 2030 |
Both summaries report that HTI-5 did not finalise its proposed information blocking changes, and that existing rules still apply; the deferred proposals could return in later rulemaking. ASTP/ONC maintains a list of removed and revised criteria with their timing on healthit.gov: check it for each criterion your product is certified to.
The privacy and security certification criteria
These are the criteria in 45 CFR 170.315(d), as shown on eCFR. Certified modules must meet the ones that apply to the criteria they are certified against.
| Criterion | Title | What it requires (summary) | NIST SP 800-53 Rev 5 (our mapping) |
|---|---|---|---|
| (d)(1) | Authentication, access control, and authorization | Verify the user's identity and enforce what each user may access and do | IA-2, AC-3 |
| (d)(2) | Auditable events and tamper-resistance | Record actions on health information and audit log and encryption status; protect logs and detect alteration | AU-2, AU-9 |
| (d)(3) | Audit report(s) | Create and sort audit reports for a chosen period | AU-6 |
| (d)(4) | Amendments | Handle patient amendment requests | None |
| (d)(5) | Automatic access time-out | End access after inactivity; require re-authentication | AC-12 |
| (d)(6) | Emergency access | Allow an identified set of users emergency access | AC-3 |
| (d)(7) | End-user device encryption | Encrypt health data stored on end-user devices, or prevent local storage | SC-28 |
| (d)(8) | Integrity | Create message digests and verify exchanged information is unaltered | SC-8 |
| (d)(9) | Trusted connection | Establish a trusted connection at message or transport level | SC-8 |
| (d)(10) | Auditing actions on health information | Auditing on by default, restricted disabling, protected logs | AU-2, AU-9 |
| (d)(11) | Accounting of disclosures | Record disclosures for treatment, payment and health care operations | AU-10 |
| (d)(12) | Encrypt authentication credentials | Developer attests whether stored credentials are encrypted | IA-5 |
| (d)(13) | Multi-factor authentication | Developer attests whether the module supports multi-factor user authentication | IA-2 |
Note what (d)(12) and (d)(13) actually require: an attestation of yes or no, not mandatory implementation. A "no" attestation is lawful under the criterion but is visible to buyers. Our recommendation is to treat both as yes-by-design: encrypted credential storage and MFA support are expected by customers and by HIPAA risk analysis, and the HHS 2025 HIPAA Security Rule proposal discussed in the HHS HIPAA Security Rule Update Guide points the same way.
Information blocking: who, what and the penalties
ASTP/ONC defines information blocking as a practice by an actor that is likely to interfere with the access, exchange or use of electronic health information (EHI), unless required by law or covered by an exception. The 21st Century Cures Act (2016) set the policy.
| Actor | Knowledge standard | Consequence |
|---|---|---|
| Health IT developers of certified health IT | Knows, or should know, the practice is likely to interfere | OIG civil monetary penalty up to $1 million per violation; ONC certification review for nonconformity |
| Health information networks and exchanges | Knows, or should know | OIG civil monetary penalty up to $1 million per violation |
| Health care providers | Knows the practice is unreasonable and likely to interfere | Disincentives under 45 CFR 171 Subpart J; findings may be posted publicly under Subpart K |
OIG states it will not penalise conduct before 1 September 2023.
The exceptions
Part 171 groups the exceptions into three subparts.
- Not fulfilling requests (Subpart B): 171.201 Preventing harm, 171.202 Privacy, 171.203 Security, 171.204 Infeasibility, 171.205 Health IT performance, 171.206 Protecting Care Access.
- Procedures for fulfilling requests (Subpart C): 171.301 Manner, 171.302 Fees, 171.303 Licensing.
- TEFCA participation (Subpart D): 171.403 TEFCA manner.
Meeting an exception means a practice is not information blocking; failing to meet one does not automatically mean it is, but the case is then judged on its facts.
Designing security controls that fit the security exception
Most security controls restrict access somewhere: rate limits, app vetting, token lifetimes, IP allow lists, account lockouts. Under 171.203 a practice that interferes with access to EHI for security reasons is protected if it meets three baseline conditions and one of two alternatives.
| Condition | What it means | Evidence to keep |
|---|---|---|
| Directly related | The practice protects the confidentiality, integrity and availability of EHI | Threat or risk the control addresses |
| Tailored | Addresses the specific security risk at hand | Why a narrower control would not work |
| Consistent and non-discriminatory | Applied uniformly, not selectively against competitors or particular requesters | Policy applied the same way to all apps and requesters |
| Alternative A: organisational policy | Written policy based on assessed risks, aligned with consensus-based standards or best practice guidance, with objective timeframes for handling security incidents | The policy, the risk assessment, the standards it follows |
| Alternative B: case-by-case determination | The practice is necessary to mitigate the risk and no reasonable, less interfering alternative exists | Dated, documented determination |
Practical examples (our analysis, not ASTP/ONC guidance)
- Third-party app registration review: vetting apps that connect to a patient access API is defensible when the review checks security properties against a published policy and applies the same checks to every app. Delaying a competitor's app longer than others fails the consistency test.
- Rate limiting: limits set to protect availability and applied by policy fit; limits set so low that bulk export is impractical invite challenge under the manner and infeasibility analysis too.
- Token lifetimes and MFA: short-lived access tokens and MFA for clinicians are standard practice and can be tied to recognised guidance. See the SMART on FHIR Security Guide.
- Blocking after an incident: cutting off a connected app during an active compromise fits Alternative B if the determination is recorded and access is restored when the risk is mitigated.
Where identity fits
Health IT runs on machine-to-machine access: FHIR API clients, bulk data export clients, HIE connections and integration engines all authenticate with client credentials, keys or certificates. Criteria (d)(1) and (d)(13) focus on users, so these non-human identities need their own controls: one client registration per integration, asymmetric client authentication where supported, short token lifetimes, an owner per client and prompt revocation when an integration ends. Applying the same rules to every client also supports the consistency condition of the security exception. See the Healthcare Identity Security Guide and the API Security Guide.
Implementation approach for developers
- Re-baseline after HTI-5: for each certified criterion, check the ASTP/ONC removal and revision list and note which HTI-5 stage applies to it.
- Confirm the (d) criteria coverage: map each certified module to its applicable (d) criteria and verify the (d)(12) and (d)(13) attestations are current and accurate.
- Write the security exception policy: one policy covering app vetting, rate limits, token lifetimes and incident blocking, citing the standards it follows and incident timeframes.
- Inventory machine clients: every API client and connection with an owner, scope and credential type.
- Log access decisions: record when and why a request was refused or delayed for security reasons, so an exception can be shown later.
- Review DSI products: HTI-5 narrowed the decision support interventions criterion and its AI transparency requirements, but HIPAA risk analysis and customer contracts still apply; keep your own model documentation.
- Test before rollback: when removing features tied to removed criteria, confirm customers do not still rely on them for other programmes before switching them off.
Measuring progress
- Attestation accuracy: (d)(12) and (d)(13) attestations verified against the shipped product each release.
- MFA support uptake: share of customer tenants with MFA enabled for clinical users.
- Client ownership: share of API clients with a named owner and recorded scope.
- Documented refusals: share of security-based access refusals with a recorded policy or determination.
- App review consistency: spread of review times across third-party apps.
Common failure patterns
- Security as a pretext: controls applied only to competitor apps fail the consistency condition.
- No written policy: without Alternative A, every refusal needs a documented case-by-case determination.
- Attesting "no" by default: treating (d)(13) as optional leaves customers unable to enforce MFA.
- Shared integration credentials: one client secret used by several integrations cannot be revoked selectively.
- Assuming HTI-5 removed everything: privacy and security criteria and information blocking rules remain.
Framework mapping
| Area | NIST CSF 2.0 | NIST SP 800-53 Rev 5 |
|---|---|---|
| Tracking HTI and Part 171 changes | GV.OC-03 | None |
| Authentication and MFA ((d)(1), (d)(13)) | PR.AA-03 | IA-2 |
| Access permissions ((d)(1), (d)(6)) | PR.AA-05 | AC-3 |
| Audit logging ((d)(2), (d)(10)) | PR.PS-04 | AU-2, AU-9 |
Practitioner checklist
- Check each certified criterion against the HTI-5 removal and revision list and dates.
- Confirm the applicable 170.315(d) criteria for every certified module.
- Ship encrypted credential storage and MFA support so (d)(12) and (d)(13) attest yes.
- Publish a written security policy that supports the 171.203 exception.
- Apply app vetting and rate limits uniformly to all requesters.
- Record every security-based refusal or delay with its reason.
- Give each API client its own registration, owner and scope.
- Brief legal and product teams on the $1 million per violation penalty exposure.
- Watch for later rulemaking on the deferred information blocking proposals.
Standards and references
- eCFR: 45 CFR 170.315 Certification criteria for health IT
- eCFR: 45 CFR Part 171 Information blocking
- ASTP/ONC: Information blocking
- HHS OIG: Information blocking
- McGuireWoods: HHS finalizes HTI-5
- Holland & Knight: HTI-5 promotes deregulatory certification actions
- NIST: SP 800-53 Rev 5 Security and Privacy Controls
This guide summarises the ONC HTI rules, 45 CFR Parts 170 and 171, and is not legal advice. Related NHI Mgmt Group resources: Healthcare Cyber Regulation Map · HIPAA Security Rule Guide · SMART on FHIR Security Guide · Healthcare Identity Security Guide