September 28, 2026
If you’re building the provider side of FHIR prior authorization into an EHR, HTI-4 is the rule that sets out what ONC will certify that work against. ASTP/ONC finalized it on July 31, 2025, and it was published as part of CMS’s FY2026 IPPS/LTCH PPS final rule on August 4, 2025 (90 FR 36536), so if you’re looking for the regulation text, you’ll find it inside that much larger CMS document rather than in a standalone ONC rule. The rule took effect on October 1, 2025.
For prior authorization, HTI-4 adds three new certification criteria at §170.315(g)(31), (g)(32) and (g)(33), one each for CRD, DTR and PAS. It also adds two supporting API criteria that the prior authorization criteria depend on: §170.315(j)(20), which covers workflow triggers for decision support interventions on the client side, and §170.315(j)(21), which covers the Subscriptions client. Outside prior authorization, the rule updates the §170.315(b)(3) electronic prescribing criterion and introduces a new §170.315(b)(4) real-time prescription benefit criterion. This article focuses on the prior authorization criteria and what goes into certifying against them, including how HTI-4 relates to the other HTI rules, which implementation guide versions each criterion references and where the 2.2.x versions fit in, what the test procedures expect you to demonstrate, and how ONC-ACB certification works.
If you’re after the policy context, such as why providers will be asking you for these capabilities once participants in the Medicare Promoting Interoperability program and the MIPS Promoting Interoperability performance category start reporting on an electronic prior authorization measure in 2027, and how that connects to CMS-0057-F, we covered it in What Is Prior Authorization? What Is Changing in 2027?
If you want to see how CRD, DTR and PAS fit together in a single prior authorization before getting into certification, we walked through that in How to Implement FHIR Prior Authorization: CRD, DTR, and PAS.
The HTI rules are ASTP/ONC’s series of regulations for the ONC Health IT Certification Program and the information blocking rules, and each one builds on the previous one. HTI-1 was finalized in December 2023 and made a structural change that affects everything after it: it dropped year-themed editions such as “2015 Edition” and replaced them with a single set of criteria called the “ONC Certification Criteria for Health IT”, which is why the HTI-4 criteria show up as new entries under §170.315 rather than as part of a new edition. HTI-1 also adopted USCDI v3 as the baseline for certification from January 1, 2026, along with SMART App Launch v2 for the standardized API criteria and a revised decision support intervention criterion (HTI-1 key dates).
The next rule, HTI-2, was proposed as one large package and finalized in pieces. In December 2024, the TEFCA provisions were finalized as the HTI-2 final rule on December 16, and the information blocking provisions were finalized as HTI-3 on December 17. The e-prescribing and prior authorization proposals were left out of both. HTI-4 finalized those proposals, and the Federal Register table of contents for the FY2026 IPPS rule still labels its prior authorization section “(HTI-2)”. ASTP/ONC lists HTI-4’s proposed rule date as August 5, 2024, which is the HTI-2 proposal.
After HTI-4, ASTP/ONC published the HTI-5 proposed rule on December 29, 2025. It would remove 34 of the program’s 60 certification criteria and revise seven more, but it retains the HTI-4 criteria without changes. The comment period closed on February 27, 2026, and as of this writing HTI-5 hasn’t been finalized, so the certification requirements for (g)(31) through (g)(33) described in the rest of this article are the current rules. On the same day, ASTP/ONC withdrew the remaining provisions of the HTI-2 proposed rule that hadn’t been finalized.
HTI-4’s prior authorization criteria consist of three (g) criteria, each mapped to one Da Vinci implementation guide, plus two modular (j) criteria that the (g) criteria rely on. The (j) criteria exist as standalone criteria, but most developers will run into them through the (g) criteria. Certifying to (g)(31) means you also demonstrate conformance with and certify to (j)(20), and certifying to (g)(33) brings in (j)(21) in the same way. (g)(32) has no (j) dependency.
| Criterion | What it covers | Standard referenced | Also requires |
|---|---|---|---|
| §170.315(g)(31) | CRD client | Da Vinci CRD IG 2.0.1 (STU 2) | (j)(20) |
| §170.315(g)(32) | DTR, as a Full DTR EHR | Da Vinci DTR IG 2.0.1 (STU 2), SMART Backend Services | None |
| §170.315(g)(33) | PAS client | Da Vinci PAS IG 2.0.1 (STU 2), SMART Backend Services | (j)(21) |
| §170.315(j)(20) | Workflow triggers for decision support, client side | CDS Hooks 2.0.1 (STU 2 Release 2) | None |
| §170.315(j)(21) | Subscriptions, client side | Subscriptions R5 Backport IG 1.1.0 | None |
The CRD criterion certifies your EHR as a “CRD Client” under at least one of the implementation specifications listed at §170.215(j)(1). The regulation names only one hook explicitly, requiring (j)(20) support that includes the order-sign CDS Hook. The phrase “at least one of the implementation specifications” also shows up in the DTR and PAS criteria, and it’s what allows more than one IG version to count for certification, which we’ll come back to in the next section.
DTR and PAS both use SMART Backend Services for system authentication. The DTR criterion and the PAS criterion both specify system authentication and authorization through the Backend Services section of the SMART specifications adopted at §170.215(c), which covers both SMART App Launch 1.0.0 and v2.0.0. PAS is also where subscriptions come in, since (j)(21) exists so the EHR can receive pended authorization responses rather than polling for them. You also have to publish complete technical documentation for the REST-hook subscription endpoint that your client exposes.
If you’re working from ONC’s October 2025 key dates fact sheet, its PAS entry says that certifying to (g)(31) requires (j)(21). The regulation text and the (g)(33) certification companion guide both tie (j)(21) to (g)(33), so that line in the fact sheet looks like a typo.
Prescription prior authorization has its own track in HTI-4 through NCPDP SCRIPT. The updated §170.315(b)(3) e-prescribing criterion now requires the electronic prior authorization transactions, from PAInitiationRequest through PANotification, whenever a module certifies using NCPDP SCRIPT 2023011. Developers can certify to either SCRIPT 2017071 or 2023011 until December 31, 2027, and only 2023011 after that. Any module certified to (b)(3) also has to certify to the new (b)(4) real-time prescription benefit criterion, and (b)(4) becomes part of the Base EHR definition on January 1, 2028 (HTI-4 key dates).
The regulation text for all three criteria references version 2.0.1 of the Da Vinci IGs. For CRD, that’s version 2.0.1, STU 2, dated January 8, 2024. The newer versions come in through the Standards Version Advancement Process (SVAP), a voluntary route set up in the ONC Cures Act Final Rule. SVAP lets certified developers update their modules to newer standard versions before those versions are adopted in regulation. The 2026 SVAP cycle added CRD 2.2.1, DTR 2.2.0 and PAS 2.2.1 for (g)(31), (g)(32) and (g)(33) respectively, and developers could start using them on August 29, 2026.
| IG | Referenced in HTI-4 | Available through 2026 SVAP | Proposed in CMS-0062-P |
|---|---|---|---|
| CRD | 2.0.1 | 2.2.1 | 2.2.1, with 2.0.1 expiring January 1, 2028 |
| DTR | 2.0.1 | 2.2.0 | 2.2.0, with 2.0.1 expiring January 1, 2028 |
| PAS | 2.0.1 | 2.2.1 | 2.2.1, with 2.0.1 expiring January 1, 2028 |
You can use an SVAP version when you first certify a module or when you update a module that’s already certified. If you’re updating an existing certification, you have to notify your affected customers and your ONC-ACB in advance. That notice has to state that you intend to update, how the update will affect the interoperability of each module, and whether you’ll keep supporting the certificate for the existing version. In either case, you have to demonstrate conformance with the newer version, and your Real World Testing plans and results have to cover it afterwards. The module isn’t considered certified to the SVAP version, and CHPL isn’t updated, until every one of those steps is done. That also means you can’t claim certification to a version you only partly support. One change from earlier SVAP cycles is that approved versions now stay available across cycles unless they’re superseded, so a 2.2.x approval won’t disappear when the next cycle comes around (2026 SVAP fact sheet).
The 2.2.x versions may also become the regulatory baseline through the CMS-0062-P proposed rule from April 2026, which extends prior authorization requirements to drugs. In it, ONC proposes adopting newer versions of the standards in §170.215(j)(1) through (3) and giving the current versions a January 1, 2028 expiration date, provided the newer versions are finalized. On the payer side, CMS proposes requiring impacted payers to use a set of IGs that the 2024 final rule only recommended. That list includes CRD, DTR and PAS at either 2.0.1 (expiring January 1, 2028) or the 2.2.x versions. This is still a proposed rule. ONC’s July 2026 developer roundtable described these proposals as requiring version 2.2 of the CRD, DTR and PAS IGs for certification, so if they’re finalized as written, 2.0.1 stops being an option after January 1, 2028.
The version your module certifies to and the version a particular payer runs are two separate questions. Under the CMS-0062-P proposal, when more than one unexpired version is adopted, payers can use any of them, which means your CRD client can expect to meet payers on 2.0.1 and payers on 2.2.x during any transition. In our course, Sidharth recommends building to 2.2.1 regardless of which version you certify to, and the version negotiation lesson covers the extensions a CRD server uses to advertise the versions it supports and to see which version a client is requesting.
[IMAGE: Reuse “CRD CDS Hooks Services Response with Extensions” from the L5 lesson. Crop out the browser bar, bookmarks and ngrok URL, and keep a single service entry (order-sign).]
ONC publishes a certification companion guide and a test procedure for every criterion, and the test procedure lists numbered steps the test lab verifies. The CRD companion guide also sets a general rule: every conformance requirement in the referenced standards and implementation guides, such as “SHALL” or “Must Support” requirements, has to be supported for certification unless something says otherwise, so the numbered steps summarize the requirements rather than replacing the IG. Conformance can be shown through documentation, visual inspection (usually a live demo), and test tools, and ONC doesn’t provide test data for these criteria, so you’ll need your own.
The (g)(31) test procedure has eight steps. CRD-1 and CRD-2 cover registering with a CRD server, including all the configuration its CDS Hooks need, and discovering what that server supports through a CRD Client Capability Statement. CRD-3 is the order-sign hook, including receiving and processing “Coverage Information” system actions, and CRD-4 checks that your module fires the required hooks at the right points in the clinical workflow. CRD-5 through CRD-7 cover security and data access. Your client authenticates to the CRD server with JSON web tokens, authorizes the server to access FHIR resources by provisioning an access token, and supports “read” and “search” on the resources profiled for the required hooks. CRD-8 is where your EHR processes the coverage information it gets back, updating the relevant FHIR resources in your module and optionally showing the decision support to the user.
Because (j)(20) is certified alongside (g)(31), the same capabilities are tested again at the general CDS Hooks level. The (j)(20) steps cover registering with a CDS service, triggering it through a CDS Hook, authenticating with JWT, and provisioning the access token the service needs for FHIR access. CDS-5 and CDS-6 cover that FHIR resource access and, where relevant, processing and displaying the decision support returned. A module that passes the CRD steps has done most of this already, but it’s certified as its own criterion.
The DTR test procedure certifies your module as a “Full DTR EHR”, meaning the EHR itself does the questionnaire work rather than relying on a SMART app. DTR-1 and DTR-2 cover registering with a DTR payer service and authenticating through Backend Services. DTR-3 and DTR-4 are the questionnaire flows. For standard questionnaires, that means supporting the $questionnaire-package operation, and for adaptive questionnaires, it means supporting both $questionnaire-package and $next-question. DTR-5 is value set expansion through $expand, and DTR-6 requires executing CQL to pre-populate questionnaires. The last two steps cover showing the pre-populated questionnaire to the user for review and completion, and storing the completed questionnaire in your module.
The PAS test procedure starts with the same registration and Backend Services steps (PAS-1 and PAS-2). PAS-3 is submitting a new prior authorization request with the $submit operation. PAS-4 covers the follow-up actions, all done through $submit: cancelling a whole request, cancelling or revising a single item, and adding an item or supporting documentation to a request already sent. PAS-5 and PAS-6 are the subscription steps, where you create, update and delete subscriptions with the payer’s server and consume the notifications it sends. PAS-7 is checking the status of a previous request with $inquire.
The subscription requirements are spelled out in (j)(21). Your subscription has to use the REST-hook channel and follow the “R4/B Topic-Based Subscription” profile. Your REST-hook endpoint also has to handle handshake, heartbeat and event-notification transactions. This means your EHR also has to accept inbound traffic, since the payer needs a publicly reachable endpoint to deliver pended decisions to.
(g)(31) and (g)(33) each require published technical documentation for the API capabilities your client exposes. That includes API syntax, function names, parameters and data types, return structures, exception handling, mandatory software components and configurations, and everything a counterparty needs to register. It also has to be available through a public link that doesn’t require any preconditions or extra steps to reach. Under the API Condition of Certification, the (g)(31) documentation has to be published as part of your complete business and technical documentation. The (g)(32) test procedure has no documentation step, and ONC’s ePA fact sheet notes that the §170.404(b)(1) requirements don’t apply to (g)(32).
Three parties are involved in certifying a module. You bring the module to an ONC-Authorized Testing Laboratory (ONC-ATL) for testing, and once it has passed, an ONC-Authorized Certification Body (ONC-ACB) certifies it and posts it to the Certified Health IT Product List (CHPL). After certification, ONC-ACBs carry out ongoing surveillance to check that certified modules still meet requirements once they’re running in production, and ONC can also review modules or developers directly. CHPL is also where your SVAP updates and Real World Testing plans and results end up.
Each of the three prior authorization criteria also requires two design and performance criteria: (g)(4), quality management system, and (g)(5), accessibility-centered design. For (g)(5), you either identify the accessibility standard you used or state that you didn’t use one. HTI-5 as proposed would remove the accessibility-centered design criterion, but the prior authorization criteria are among those it leaves unchanged.
All three test procedures name the Inferno Framework as the test tool, and as of their last update the link to the tool itself was still listed as “coming”. Until that’s published, Inferno on HealthIT.gov hosts IG-level test kits you can use to prepare. The CRD test kit includes client and server suites for version 2.2.1, the DTR test kit covers both 2.0.1 and 2.2.0, and the PAS test kit tests both client and server implementations. ONC notes that the CRD IG tests check baseline IG conformance and don’t cover every certification requirement. For certification itself, a draft (g)(31) certification test kit is on Inferno’s QA server, and the certification-ready release is planned for October 2026.
The Subscriptions test kit, which is relevant to (j)(21), has known gaps. It supports only the REST-hook channel, doesn’t test error handling or recovery from missed notifications, and doesn’t send heartbeat notifications when simulating a server for the client test suite. Since (j)(21) requires your endpoint to handle heartbeats, ask your ONC-ATL early how they plan to verify that.
The API Condition and Maintenance of Certification requirements at §170.404 apply to developers of modules certified to any of (g)(31), (g)(32) or (g)(33). The requirements at §170.404(b)(1) don’t apply to (g)(32), and for (g)(31), the documentation described in the previous section has to be published as part of your complete business and technical documentation.
HTI-4 also added (g)(31) through (g)(33) and (j)(20) and (j)(21) to the Real World Testing condition, so modules certified to any of them before August 31, 2026 test during calendar year 2027 and submit results in March 2028. The general cycle is that your annual plan has to cover everything certified as of August 31 of the year you submit it, and plans are published on CHPL by December 15, with results following by March 15. A module certified after August 31, 2026 would therefore go into the plan submitted in December 2027, be tested during 2028, and have results due in March 2029. Any module you update to a newer standard version through SVAP before August 31 also has to be included in that year’s plan.
This obligation may shrink. HTI-5 proposes descoping the Real World Testing condition, including its plans, results and its connection to SVAP. ONC has already narrowed Real World Testing through enforcement discretion, most recently by limiting the CY2025 results it expects to modules certified to (g)(7) through (g)(10). Neither change affects the rules in force for (g)(31) through (g)(33) today, but check the status of both before planning your 2027 testing.
This is the order we’d work through the requirements in, from deciding what to certify through the obligations after certification. Each item points back to the section that explains it.
ONC certifies the client side, which is what this article covers. A (g)(31) client is only useful once it’s talking to a real CRD server, though, and several CRD design decisions sit on that side of the connection. Those include how a payer groups several delegate vendors behind one discovery endpoint, which of the six response types it sends back and when, and how it handles version negotiation when your client runs 2.2.1 but the payer enforces 2.0.1. Those decisions determine what your client receives in production, and the test procedures don’t cover them.
Our course, Prior authorization on FHIR: CRD, DTR and PAS for health plans, builds that server side. It covers CDS Hooks discovery, JWT authentication, prefetch, every CRD hook and every response type, with each step tested live against the Inferno CRD 2.2.1 test suite. It also covers why passing Inferno and conforming to the IG aren’t the same thing, because many conformance requirements aren’t covered by any test in the kit.
HTI-4 is an ASTP/ONC rule that adds new certification criteria to the ONC Health IT Certification Program for electronic prior authorization, e-prescribing and real-time prescription benefit. It was finalized on July 31, 2025 and published as part of CMS's FY2026 IPPS/LTCH PPS final rule (CMS-1833-F) on August 4, 2025.
HTI-4 adds three criteria: 45 CFR 170.315(g)(31) for the CRD client, (g)(32) for DTR, and (g)(33) for the PAS client. It also adds two supporting API criteria, (j)(20) for CDS Hooks workflow triggers and (j)(21) for the Subscriptions client. Certifying to (g)(31) also requires (j)(20), and certifying to (g)(33) also requires (j)(21).
The rule took effect on October 1, 2025. Some related dates come later. The electronic prior authorization measure for providers starts in 2027, SCRIPT 2017071 stops being accepted for (b)(3) certification after December 31, 2027, and (b)(4) becomes part of the Base EHR definition on January 1, 2028.
The regulation text references version 2.0.1 of the CRD, DTR and PAS implementation guides. Through the 2026 SVAP cycle, developers can also certify to CRD 2.2.1, DTR 2.2.0 and PAS 2.2.1, and these became available on August 29, 2026.
That's been proposed but not finalized. The CMS-0062-P proposed rule from April 2026 includes ONC proposals to adopt the 2.2.x versions and give 2.0.1 an expiration date of January 1, 2028. ONC has described these proposals as requiring version 2.2 for certification if they're finalized as written.
CMS-0057-F sets prior authorization API requirements for impacted payers, while HTI-4 sets the certification criteria for the provider-side health IT that connects to those APIs. The two rules are designed to work together, with payers running CRD, DTR and PAS servers and certified EHRs acting as the clients.
No. The HTI-5 proposed rule would remove 34 of the program's 60 certification criteria, but it keeps the HTI-4 criteria without changes. It would also scale back Real World Testing. As of this writing, HTI-5 hasn't been finalized.
The test procedures name the Inferno Framework as the test tool. You can prepare with the CRD, DTR, PAS and Subscriptions test kits on Inferno, but these don't cover every certification requirement. A draft (g)(31) certification test kit is available, and the certification-ready release is planned for October 2026. Formal testing is done by an ONC-ATL, and certification is done by an ONC-ACB.
It covers it through a separate track. The updated (b)(3) e-prescribing criterion requires the NCPDP SCRIPT electronic prior authorization transactions for modules certifying to SCRIPT 2023011. The Da Vinci-based criteria at (g)(31) through (g)(33) are separate from that.
A technical reference for the FHIR prior authorization APIs. What CRD, DTR, and PAS each exchange, how one hands off to the next, and the authentication, versioning, performance, and testing rules underneath them.
What prior authorization is, why the process has been so slow, and what CMS-0057-F and HTI-4 require health plans to fix by January 2027.
Healthcare interoperability keeps failing for the same two reasons: inconsistent data models and bad sync. Here's what solving both would actually take.
No comments yet. Be the first to comment!
