HTI-4 certifies only half of electronic prior authorization. The rule, finalized in July 2025 and in effect since October 2025, turned the 3 Da Vinci implementation guides for prior authorization into federal certification criteria for the health IT that providers use. An EHR can now be certified to ask a payer what a service requires and to submit the request in a standard format. Nothing in the rule certifies the payer’s side of the same exchange.
The payer side is the Prior Authorization API that CMS requires most of the payers it regulates to run by January 2027. CMS recommended the same guides when it set that deadline in 2024. In April 2026, it proposed to require them from October 2027, along with a public list of payer endpoints. The comment period closed on June 15.
A standard is a contract between 2 systems, and it is only as reliable as the less tested of the 2. Payer endpoints should face the same public tests as EHRs, with results published beside the endpoints CMS plans to list.
Key takeaways
- HTI-4 made the prior authorization guides certification criteria. The rule created a criterion for each of the 3 Da Vinci guides, based on version 2.1.0 of each.
- Certification is voluntary. ASTP says there are “currently no requirements for developers to implement these criteria.”
- Only provider systems are covered. ASTP proposed payer-side criteria in 2024, including a prior authorization API for payers. HTI-4 finalized only the provider side.
- Payer APIs are due in January 2027. CMS recommended the Da Vinci guides in 2024. Its April 2026 proposal would require them from October 2027.
- Adoption is rising from a low base. Electronic adoption for medical prior authorization reached 40% in 2024, up from 31% in the 2023 CAQH Index.
- Both ends should be tested in public. ONC’s open-source test kits already include tests for payer servers. CMS could publish each payer’s results beside the endpoints it proposes to list.
What HTI-4 certifies
HTI-4 was published in August 2025 as part of CMS’s FY2026 inpatient payment final rule and took effect in October 2025. It finalized prior authorization provisions that ASTP, the federal health IT office, first put forward in its 2024 HTI-2 proposal. The final version split the proposed single criterion into separate criteria, according to Healthcare Dive, so that vendors can certify a product for a single function.
| Criterion | What it lets provider systems do | Standard |
|---|---|---|
| § 170.315(g)(31), coverage requirements discovery | Ask a payer whether a service needs authorization and what documentation it requires | Da Vinci CRD, version 2.1.0 |
| § 170.315(g)(32), documentation templates and rules | Complete the payer’s documentation template inside the clinical workflow, with data drawn from the record | Da Vinci DTR, version 2.1.0 |
| § 170.315(g)(33), prior authorization support | Submit the request and check its status | Da Vinci PAS, version 2.1.0 |
| § 170.315(j)(20), workflow triggers | Fire decision support at points in the EHR workflow, as coverage discovery requires | CDS Hooks, version 2.0.1 |
| § 170.315(j)(21), subscriptions | Receive notifications from a server, such as an update to a pending request | FHIR Subscriptions R5 Backport, version 1.1.0 |
From ASTP’s electronic prior authorization fact sheet (October 2025). All of the criteria build on FHIR Release 4.
How the exchange works
The guides divide a prior authorization into steps that happen inside the clinician’s workflow. Take an outpatient MRI ordered in clinic. When the clinician signs the order, the EHR sends a coverage discovery request to the patient’s payer. The payer’s server answers while the order is still open. It can say that no authorization is needed, or it can say that authorization is needed and point to a documentation template.
If a template is needed, the EHR loads it and fills in what it can from the record. The clinician answers the remaining questions. The completed request then goes to the payer’s endpoint in a standard format. The payer answers with a decision or pends the request for review. The EHR can subscribe to updates instead of polling for them.
Each step is a conversation between 2 systems. HTI-4 certifies the system that asks. The system that answers is the payer’s, and it sits outside the certification program.
Obligations that come with certification
The criteria carry the usual duties of certified APIs. Modules certified to them fall under the API conditions of certification. Authenticity verification and registration requirements apply to the coverage discovery and submission criteria, though not to the documentation template criterion, according to ASTP.
Modules certified to the new API criteria before August 31, 2026 must run real world testing in calendar year 2027. Results are due in March 2028, according to ASTP’s key dates guide. Developers can also move to newer versions of the guides through ASTP’s standards version advancement process.
Certification is a choice
ASTP’s fact sheet is direct about the status of the new criteria. “There are currently no requirements for developers to implement these criteria within their Health IT Modules.” The rule did add a requirement to the base EHR definition, but it covers real-time prescription benefit checks from January 2028, not prior authorization.
That leaves adoption to the market. Providers have reasons to want certified tools, including an electronic prior authorization measure that CMS created in its Promoting Interoperability programs. EHR developers have reasons to certify, because that measure is built around certified technology. Neither reason applies to the payer at the other end.
ASTP estimated $19 billion in labor savings over 10 years, according to Healthcare Dive. Those savings depend on transactions that work end to end, which is the part HTI-4 does not test.
What HTI-4 leaves out
The 2024 HTI-2 proposal had a wider scope. Alongside the provider criteria, it proposed certification criteria for the health IT that payers use, according to ASTP’s HTI-2 fact sheet (July 2024).
| Proposed payer criterion | Purpose |
|---|---|
| Patient access API | Lets patients reach their health and administrative information through an app of their choice |
| Provider access API for payer servers | Lets providers retrieve a patient’s clinical and claims data from the payer |
| Payer-to-payer API | Moves patient information between payer systems |
| Prior authorization API, payer | Supports electronic prior authorization on the payer’s side |
| Provider directory API | Publishes the providers in a plan’s network |
From the HTI-2 proposed rule fact sheet (July 2024). The proposed paragraph numbers differ from those HTI-4 used.
HTI-4 finalized the provider side of prior authorization and none of these payer criteria. The payer side of the exchange is governed instead by CMS’s 2024 interoperability and prior authorization rule, which requires the API but does not certify it.
Why the payer side carries the content
In the Da Vinci design, the provider’s system asks and the payer’s system answers. When a clinician orders a service, coverage discovery sends the order to the payer. The payer’s server decides what comes back. It may report that no authorization is needed. It may return a documentation template, written by the payer, whose logic decides which questions the clinician sees. The request itself goes to the payer’s endpoint, which has to accept it and respond.
The templates are where most of the payer’s work lives. A documentation template is a questionnaire with logic attached, and the logic decides which questions to skip and which answers the EHR can fill in from the record. That only works when the payer’s logic asks for data the way the EHR stores it. A template can be valid under the guide and still pull nothing from a real record.
Each of those answers is payer content. A certified EHR can display a template perfectly and still show the clinician a template that is out of date, or one that asks for data the record cannot supply. It can format a request correctly and still send it to a server that rejects valid requests. Certification of the client tells a provider that its half of the conversation is in order. It says nothing about the other half.
That gap matters more as plans change their rules. Insurers that signed the 2025 industry pledge reported in April 2026 that they had removed codes from their prior authorization lists, as our review of the pledge described. Every removed code has to disappear from the payer’s coverage discovery responses too. If it does not, the clinician sees a requirement that no longer exists.
What CMS proposed in April
CMS’s 2024 rule requires impacted payers to run a Prior Authorization API by January 2027. The rule, CMS-0057-F, strongly encourages the Da Vinci guides. CMS released a proposed rule, CMS-0062-P, on April 10, 2026. It would turn the recommendation into a requirement and extend the API to drugs.
| Proposal | What it would require | Proposed start |
|---|---|---|
| Required guides | Payers conform to a set of guides, including the 3 Da Vinci prior authorization guides | October 1, 2027 |
| Drugs in the API | The Prior Authorization API supports drugs covered under a medical benefit | October 1, 2027 |
| FHIR as the HIPAA standard | HHS adopts FHIR for prior authorization and eligibility transactions in place of X12 | 24 months after a final rule, or 36 for small plans |
| Endpoint list | Payers report their API endpoints and capability statements for CMS to publish in a central list | 60 days after a final rule takes effect |
| Usage metrics | Payers report how much their interoperability APIs are used | 2027 data, reported in 2028 |
From the CMS fact sheet (April 2026) and Crowell & Moring (April 2026).
The HIPAA change would matter more than it looks. HIPAA’s current standard for prior authorization transactions is X12. The PAS guide was written to coexist with it, which has meant translating between FHIR and X12 in many implementations. Adopting FHIR as the HIPAA standard would remove that step and put the certified EHR and the payer API on the same format end to end.
For drugs under the pharmacy benefit, the proposal relies on NCPDP standards rather than the Da Vinci guides. Medicaid and CHIP programs would also have to decide drug prior authorization requests within 24 hours. Our analysis of decision timeframes covers the clocks that already apply to medical services.
A first bridge between the halves
The proposal ties compliance to versions of the standards adopted in federal health IT regulation, according to Crowell & Moring. That is the first formal link between the 2 halves. If it is finalized, a payer’s server and a certified EHR would be held to the same versions of the same guides.
The endpoint list matters too. Today a developer often has to find each payer’s endpoint and documentation on its own. A central list would let anyone see which payers have published an API and which versions they claim to support.
What the proposal does not add is a test. Neither the fact sheet nor the summaries reviewed for this analysis describe conformance testing of payer systems. Compliance would be left to CMS’s usual oversight, which tends to find problems after providers have already run into them.
What adoption looks like
Electronic prior authorization is growing from a low base. The 2025 CAQH Index, reported by AJMC in May 2026, found that electronic adoption for medical prior authorization reached 40% in 2024, up from 31% in the 2023 Index. The rest still run through payer portals or manual channels such as fax.
The industry has its own deadline. Insurers that signed the June 2025 pledge committed to have FHIR-based electronic prior authorization operational by January 1, 2027, the same month the CMS requirement begins. Our earlier argument that a standard should be judged by the fax it retires applies here. The measure of success is how many of those manual channels close.
Adoption figures count transactions that start electronically. They do not measure whether the answer that comes back is correct. A request submitted electronically against a requirement that no longer exists still counts as electronic. So does a template that asks a clinician 20 questions when the criteria use 4.
Test both ends of the exchange
HTI-4 tests the provider’s half because the certification program has always been built around the products providers buy. The payer’s half needs an equivalent, and much of it already exists.
There is a precedent on the provider side. The standardized patient API that EHRs certify under § 170.315(g)(10) is tested with ONC’s Inferno tools, and that testing gave app developers a baseline they could rely on. Payers have run their own patient access APIs under CMS rules since 2021 without any equivalent certification. The prior authorization API is about to follow the same path unless someone chooses a different one.
ONC’s Prior Authorization Support test kit, released in April 2024, “includes tests for clients (e.g., electronic health record systems) and servers (e.g., payer systems).” It is open source. ONC has since built test kits for the other 2 Da Vinci guides.
A certified client talking to an untested server is half a test.
| Check | What it shows | Available today |
|---|---|---|
| Format conformance | The server accepts valid requests and returns responses in the guide’s format | Yes, through the open test kits |
| Version support | Which guide versions the server implements | Partly, through capability statements |
| Content accuracy | Coverage discovery answers match the plan’s current prior authorization list | No |
| Template economy | Templates ask only for the data the criteria use | No |
| Response timing | Answers arrive while the order is still open | No |
Our framework. The first 2 checks can be automated with existing tools. The last 3 need payer test cases.
A workable approach would use what exists.
- Test payer servers with the same kits. Payers can run the open test kits against their own endpoints today. CMS could ask for the results, as ASTP asks developers to report real world testing.
- Publish results beside the endpoints. CMS has proposed a central list of payer API endpoints. Each entry could show which guide versions the payer supports and when its server last passed the tests.
- Test the content, not only the format. For each service on its prior authorization list, a payer could publish a test case that shows what coverage discovery returns. When a code leaves the list, the test case changes with it. Our case for publishing coverage criteria like code describes how.
- Report failures as well as passes. A result that appears only when it is clean is marketing. Results should show what failed and when it was fixed.
- Finish the payer criteria. ASTP proposed payer criteria in 2024. Finalizing them would let payers certify voluntarily, and CMS could later decide whether to rely on that certification.
There are fair objections. Payers will point to cost, and to the number of guides and versions they already support. Testing also cannot settle disputes about clinical criteria, which belong in coverage policy rather than in a test kit. A public failure can also embarrass a payer that is working in good faith. Each objection argues for a gentle start, such as voluntary testing with published results, rather than for no testing at all.
The deeper point is symmetry. Providers will spend 2027 using certified tools against payer systems that were never held to an equivalent test. When an exchange fails, the provider will see the failure first and will have no easy way to tell which side caused it.
Where Redlake stands
Redlake builds tools that health plans use in utilization review, so we sit on the payer side of this exchange. We hold those tools to 3 rules. A clinician makes every denial, so a machine can say yes, but only a person can say no. Every recommendation shows its reasons. Every decision can be reconstructed.
Those rules map onto the Da Vinci exchange. A coverage discovery response should name the criteria behind it, so the clinician sees why documentation is needed. A documentation template should ask only for what the criteria use. An automated approval can come back through the same exchange while the order is open. A request that may end in a denial should go to a clinician, and the response should carry its reasons.
We think payers should run the public test kits against their endpoints and publish the results, starting before the January 2027 deadline. A certified EHR deserves a tested server on the other end. We would rather see a failure published and fixed than leave providers to discover it.
What to watch in the rest of 2026
- The CMS-0062-P final rule. Watch whether CMS finalizes required guides for October 2027, and whether the final rule adds any testing of payer systems.
- HTI-5. ASTP’s deregulatory proposal from December 2025 would remove 34 of the 60 existing certification criteria for EHRs, according to the National Law Review. Watch whether the final version changes the prior authorization criteria.
- Real world testing plans. Developers that certify prior authorization modules before August 31, 2026 will need to test them in 2027. Their plans will show how many certified products are in use.
- Payer readiness. The January 2027 deadline arrives with the industry pledge’s target for FHIR-based prior authorization, and both will be visible in how many endpoints go live.
About this analysis
Method. The HTI-4 certification criteria are compared with the payer API requirements in CMS’s 2024 rule and its April 2026 proposal, using ASTP and CMS fact sheets supplemented by press and law firm summaries.
Data notes. The CAQH figures are as AJMC reported them. The table of proposed payer criteria uses descriptions from ASTP’s 2024 fact sheet, and the paragraph numbers in that proposal differ from those HTI-4 finalized. CMS-0062-P is a proposal, and its provisions may change. The testing approach is this analysis’s suggestion, not a CMS or ASTP proposal.
Sources. ASTP, electronic prior authorization fact sheet (October 2025) and HTI-4 key dates guide (October 2025). ASTP, HTI-2 proposed rule fact sheet (July 2024). Healthcare Dive (August 2025). CMS, CMS-0057-F fact sheet (January 2024) and CMS-0062-P fact sheet (April 2026). Crowell & Moring (April 2026). AJMC (May 2026). ONC, PAS test kit announcement (April 2024). National Law Review (January 2026).
Frequently asked questions
What is HTI-4?
HTI-4 is a federal health IT rule that took effect in October 2025. It created certification criteria for electronic prior authorization in the health IT that providers use, based on the Da Vinci implementation guides, along with updated criteria for electronic prescribing.
Does HTI-4 apply to payers?
No. HTI-4’s prior authorization criteria cover provider systems only. Payers must run a Prior Authorization API under CMS’s 2024 rule, but no certification program tests that API. ASTP proposed payer criteria in 2024 and has not finalized them.
Do EHR vendors have to certify to the HTI-4 prior authorization criteria?
No. ASTP says there are currently no requirements for developers to implement the criteria. Certification is voluntary, though CMS’s electronic prior authorization measure gives providers a reason to want certified modules.
What did CMS propose for prior authorization APIs in April 2026?
CMS proposed requiring payers to conform to the Da Vinci prior authorization guides from October 1, 2027. It also proposed adding drugs covered under a medical benefit to the API and publishing payer endpoints in a central list. The comment period closed on June 15, 2026.