HTI-4 puts electronic prior authorization in certified health IT—not clinical decision authority

Certification gives the workflow a defined technology layer

The direct answer in ASTP/ONC's summary is that HTI-4 brings electronic prior authorization into new and updated health IT certification criteria. It does so beside electronic prescribing, real-time prescription benefit information, related API functionality, and HHS standards for clinical and administrative exchange with payers. That combination makes the technical boundary important: similar user-facing workflows can rely on different standards, messages, actors, and certification criteria.

A product inventory should name the developer, certified product and version, criterion, certification status and date, standard and implementation-guide version, optionality, configured module, API endpoint, customer responsibility, and production evidence. Saying a system is 'HTI-4 ready' without those details hides whether the statement concerns a certified capability, a roadmap, a payer endpoint, an integration, or a local workflow.

A certified capability does not decide medical necessity

Certification can provide evidence that health IT meets defined criteria under the Certification Program. It does not establish that a particular requested service is covered, medically necessary, sufficiently documented, timely, or approved. Those conclusions depend on the applicable plan, benefit, criteria, request facts, professional review, and governing requirements. The technology and the decision authority must remain separately attributable.

A representative test should trace coverage-requirement discovery, documentation capture, submission, status, payer response, denial reason, request for more information, correction, appeal or reconsideration path, and final disposition. The record should show what the certified module transmitted or displayed, what another system supplied, and what a clinician, payer, or other accountable actor decided.

API success is not end-to-end conformance

HTI-4 includes related API criteria and HHS exchange standards, but an endpoint's successful response is only one layer of evidence. End-to-end operation also depends on identity, authorization, data quality, code and value-set handling, implementation-guide versions, attachments, workflow state, error behavior, security, privacy, logging, payer policy, and human review. Different products may divide those responsibilities differently.

Buyers should test normal, incomplete, conflicting, unavailable, duplicate, changed, and urgent cases across both sides of the exchange. Preserve request and response payload versions, transformations, provenance, timing, exceptions, retries, user actions, and the final authoritative record. A passing certification test or API call should not be relabeled as a guarantee that the entire operational process is compliant or clinically sound.

Rule identity and effective date stay visible

ASTP/ONC identifies HTI-4 as part of CMS-1833-F and gives an October 1, 2025 effective date. The page also notes that the rule finalizes certain proposals from HTI-2. Teams should preserve proposed and final records, the precise final provisions they implement, certification deadlines where applicable, subsequent guidance, and the product release that supports them rather than blending several HTI rules into one label.

This summary establishes the federal rule's high-level scope; it does not substitute for the final regulatory text, Certification Program materials, implementation specifications, payer requirements, contracts, or case facts. Interoperability, clinical, utilization-management, compliance, security, privacy, product, and legal owners should apply those sources. Systems should make the boundary between technical conformity and decision authority inspectable.

Enterprise buyer test

Translate this change into the exact population, record type, workflow stage, decision owner, effective date, and evidence that could be affected. Ask current or prospective providers to demonstrate the named workflow with representative data and an exception—not a polished feature tour. Record what official documentation establishes, what a provider states, what the team observes, and what remains unresolved.

A defensible review also identifies the dependency outside the product. Authority interpretation, policy configuration, data quality, integrations, human judgment, approval rights, release governance, training, and retained evidence may remain customer or service responsibilities. The evaluation should preserve those boundaries instead of treating a technology claim as the complete operating model.

What we will watch next

Health Interoperability Review will watch the named source and affected market records for later evidence that changes status, scope, availability, implementation timing, workflow consequence, or the limits of the initial report. A later announcement does not silently overwrite this dated account; the change ledger preserves the sequence.