HTI-4 Final Rule: Certifying CRD, DTR and PAS in Your EHR
A developer guide to the HTI-4 final rule, covering the (g)(31) to (g)(33) criteria, SVAP versions, Real World Testing and a certification checklist.
By January 1, 2027, most Medicare Advantage, Medicaid, CHIP and marketplace plans need a working FHIR prior authorization API, and if you are the one scoping that work at a health plan, you have probably already been asked whether to build it, buy it, or bring someone in. If you need the background on the rule itself, we covered it in what changes for prior authorization in 2027.
The decision is harder for a health plan than it looks from the outside, because a health plan is rarely one entity. A lot of plans subcontract parts of prior authorization to other vendors, so whatever you put in place has to work for your own team and for every vendor you’ve delegated to.
In this article we go through the three paths a plan can take: building with your own team, buying a product, or building with outside help, where you own a FHIR facade that sits in front of your vendors. For each one we cover what it involves and when it makes sense, and we’ll tell you which one we recommend for most plans.
Two points apply whichever path you choose. The first is that the FHIR APIs are the smaller part of the job. In our experience, working out how your plan actually decides a prior authorization request takes around 70 to 80 percent of the effort, and no product handles that for you out of the box. The second is that you shouldn’t build custom APIs between you and your vendors. If every vendor implements the CMS spec exactly as it’s written, you can put them behind one endpoint, and if each one gets its own custom API, it will become a mess to maintain.
TL;DR
- Most Medicare Advantage, Medicaid, CHIP and marketplace plans need a FHIR prior authorization API (CRD, DTR and PAS) by January 1, 2027 under CMS-0057-F.
- Health plans have three options: build in-house, buy a prior authorization product, or build with outside help.
- The FHIR APIs are the smaller part. Mapping how your plan actually decides a prior authorization request takes around 70 to 80 percent of the effort, and no product does that for you.
- Buying a payer-side product does not come with any certification. Payer criteria were proposed in HTI-2 but never finalized.
- Don’t build custom APIs to your prior authorization vendors. Have each one implement CRD to spec and put them behind one facade.
- For most plans we recommend building on HAPI FHIR with an experienced team for the first few months, then maintaining it in-house.
What you’re actually scoping
The work splits into two parts, and they’re very different in size. The first is the FHIR side: a CRD service that answers CDS Hooks calls from the EHR, DTR questionnaires that collect the documentation you need, a PAS endpoint that takes the request and returns a decision, and, if you work with vendors, a facade in front of all of it. We went through how CRD, DTR and PAS fit together in FHIR prior authorization explained, so we won’t repeat it here.
The second part is the decision logic behind those APIs. When a CRD call arrives, something has to work out whether the member is covered, whether this service needs prior authorization under this plan, and what documentation you’d need to approve it. The APIs only carry the question and the answer. The logic that produces the answer is yours, and it’s where most of the time goes.
Mapping your prior authorization logic is the hardest part
From what we’ve seen, the FHIR work is rarely what holds things up. What takes the time is finding out where the data you need actually lives, which system is the source of truth for eligibility, benefits and past authorizations, and how the current manual process really works.
That last part is usually harder than it sounds. In a lot of plans, prior authorization decisions come down to one or two experienced people on the floor who know which requests get approved and why. Some of that is written down in medical policies, but a good share of it is judgment they’ve built up over years and never documented. Before anything can be automated, someone has to sit with those people and turn what they do into rules a system can run.
So this is as much a process mapping problem as a technical one, and it takes most of the effort on every path in this article. Whether you build, buy or bring in outside help only changes who writes the code; the logic still has to be mapped first.
Option 1: Build it with your own team
Building in-house means your engineers stand up the FHIR server, implement CRD, DTR and PAS, and write the decision logic as code they maintain. Your business rules live in your own codebase, in a language your team already knows, and nobody outside the plan has to be involved when a policy changes.
The cost is time. With a team that has built FHIR APIs before, we’d expect this to take at least six months. With a team that’s new to FHIR, CDS Hooks and the Da Vinci guides, it can take one to two years, and some teams never get it into production. Most of that time goes into the logic mapping from the previous section, but a new team also has to learn the specs as it goes, and the specs have details that are easy to get wrong, like which CRD version to build against and how token handling is supposed to work.
This path makes sense if you already have engineers with FHIR experience and you want full control over how decisions are made. If you’re hiring that team from scratch to meet a January 2027 deadline, the timeline is the risk.
Option 2: Buy a product
There are two kinds of product you’ll come across, and a plan may end up looking at both.
The first kind sells the FHIR API layer. Availity and Onyx launched a joint platform in August 2025 that includes a FHIR server, prior authorization APIs and payer-to-payer exchange. Health Samurai’s Payerbox implements CRD, DTR and PAS alongside the other CMS-0057-F APIs. Cohere Health markets CRD, DTR and PAS support, and Edifecs and CareEvolution market broader CMS-0057-F API coverage, according to Rx Almanac’s CMS-0057-F vendor readiness matrix. Treat these as marketed scope. Before you sign, ask for a named payer running it in production and the conformance results, because marketing a feature is not the same as running it for a real payer.
The second kind sells the decision layer, usually called utilization management. Elion lists 14 products for payer-side prior authorization, including Cohere Utilization Management, Lilee, Itiliti Health and Case Health AI. Their general approach is to take a plan’s written clinical policies, turn them into decision trees, and recommend or auto-approve requests that meet the criteria. That covers the documented part of your logic. It doesn’t cover the undocumented judgment calls from the previous section, so you still have to map those yourself before any of these tools can use them. (Three products on that list, MedHok Rx, Agadia and Banjo Health, are for pharmacy authorizations, which the CMS-0057-F prior authorization API requirements don’t cover.)
Buying also adds work of its own. You have to sync your eligibility, benefits and authorization data into the product, and keep your logic in whatever format the product uses, which is often CQL, a language your team may need to learn. That ongoing cost is easy to miss when you compare a product’s price against a build estimate.
One thing you don’t get by buying is certification. On the EHR side, ONC’s HTI-4 rule added certification criteria for CRD, DTR and PAS, so a provider buying a certified EHR module inherits that certification. There’s no equivalent for health plans today. Payer-side criteria were proposed in HTI-2 but not finalized, which we went through in HTI-4 final rule: certifying CRD, DTR and PAS in your EHR, so buying a payer product doesn’t give you anything an auditor checks for. CMS could change that in future rulemaking.
Buying makes the most sense when prior authorization is one of several FHIR APIs you need. If you also have to stand up the Patient Access, Provider Access and Payer-to-Payer APIs, and support more than one version of each, a platform that covers all of them can save more than it costs. If prior authorization is the only gap, the case is weaker.
Option 3: Build it with outside help
This is the path we recommend for most plans. You build and own the code, but you bring in a team that has done it before for the first few months, while your own engineers learn the specs alongside them.
In practice that means three things. First, you map your prior authorization logic, since that work has to happen on any path. Second, you stand up a FHIR server on something like HAPI FHIR, the open source Java implementation, and build your CRD, DTR and PAS services on it. Third, if you work with vendors, you put a facade in front of them so the EHR sees one endpoint, which we cover in the next section. Once the first version is live, the outside team steps back and your team maintains it.
The reasoning is mostly about what you end up owning. Your logic stays in code your team can read and change, without syncing data into a product or learning a product’s rule format. And since buying doesn’t bring any certification with it, you aren’t giving up anything an auditor would look for. Building is also cheaper than it used to be, because AI coding tools have taken a lot of the effort out of writing standard FHIR plumbing, though that’s our observation rather than something we can put a number on.
The tradeoff is that you need some engineering capacity to keep it running after the outside team leaves. If you have none at all, buying is probably the safer choice.
Don’t build custom APIs between you and your vendors
If you delegate prior authorization for some services to vendors, the obvious move is to define an API of your own and ask each vendor to plug into it. We’d recommend against it. Ask every vendor to implement CRD exactly as if they were connecting to an EHR directly, and to test it against Inferno and the CDS Hooks sandbox. Then your job is to compose them, which the CDS Hooks APIs are designed to allow.
Composing them means building a facade: one CRD endpoint that the EHR talks to, which routes each call to your own service or to the vendor responsible for that plan or set of codes. There are three details to get right.
- Discovery: when the EHR asks which hooks you support, it should see one unified list, not ten separate order-select services. The facade calls each vendor’s discovery endpoint and merges the results.
- Prefetch: each vendor declares the data it wants up front. The facade namespaces those keys (vendor1-patient, vendor1-encounter and so on), passes them to the EHR, and strips the prefix again before forwarding the hook to that vendor.
- Tokens: the CRD spec says the access token an EHR sends with a hook shouldn’t be forwarded to systems outside your organization or your business associate agreements. So instead of handing vendors the EHR’s FHIR server and token, you host your own FHIR server, give vendors access to that, and forward their requests back to the EHR yourself.
The EHR talks to one health plan CRD endpoint. The plan routes each hook to its own service or the responsible vendor, and vendors query the plan’s FHIR server, not the EHR’s.
Discovery aggregation: the plan calls each vendor’s discovery endpoint and merges the results, so the EHR sees one list of hooks.
Agree the version up front too. CMS-0057-F references CRD 2.0.1, but ONC’s certification test kit for the HTI-4 CRD criterion is built on 2.2.1, so certified EHRs will be on 2.2.1. We recommend 2.2.1 for anyone implementing CRD, DTR and PAS now.
The same reasoning applies to how providers will reach you. Epic went live with CRD in August 2026 at Ochsner Health, Froedtert ThedaCare Health, Denver Health and Summit Health, with UnitedHealthcare, Aetna and Network Health on the payer side and 16 more insurers in testing. That launch covers CRD, not yet DTR and PAS. Availity routes prior authorization traffic across its network, including to delegated vendors. A plan whose services follow the spec can be reached through either route, or directly from an EHR, with the same code. A plan that built something custom has to adapt it for each one.
How the three paths compare
| Build with your own team | Buy a product | Build with outside help | |
|---|---|---|---|
| Team you need | Engineers with FHIR experience | People to configure the product and keep data synced | Some engineers, plus an outside team for the first few months |
| Time | At least 6 months with an experienced team, 1 to 2 years for a new one | Depends on the vendor; logic mapping still comes first | Shorter than building alone, since the outside team knows the specs |
| Where your logic lives | Your own code | The product, often in CQL | Your own code |
| Vendor dependency | None | High | Only during the first few months |
| Fits when | You already have a FHIR team and want full control | You also need Patient Access, Provider Access and Payer-to-Payer APIs across versions | You want to own the code but don’t have FHIR experience in-house yet |
If you do talk to vendors, whether to buy a product or to handle part of your prior authorization, these are the questions we’d ask:
- Which CRD version do you support, and is 2.2.1 on your roadmap?
- Can we see your Inferno test results, and which health plan is running this in production?
- Do you forward the EHR’s access token anywhere, or can you work against a FHIR server we host?
- Will your CRD service work behind our facade, with namespaced prefetch and our discovery endpoint?
If you’re scoping this now
If you’re working out which of these paths fits your plan, or you already have vendors and aren’t sure how to put them behind one endpoint, book a call with us. We build FHIR servers on HAPI FHIR and have written about facade architectures before, and we’re happy to talk through where your plan is.
If your team would rather build it themselves, our FHIR prior authorization course walks through building a CRD server that passes Inferno, including the facade for plans with vendors. And if you think we’ve got something wrong about any of the products or approaches here, let us know.
Frequently asked questions
How long does it take a health plan to build CRD, DTR and PAS?
At least six months with a team that has built FHIR APIs before. With a team new to FHIR, CDS Hooks and the Da Vinci guides, one to two years, and some never reach production. Most of that time goes into mapping the plan's own prior authorization logic, not the APIs.
What do prior authorization products not cover?
The decision logic. Utilization management products turn written clinical policies into decision trees, but the undocumented judgment calls that experienced reviewers make still have to be mapped by the plan before any product can use them. Products also need the plan's eligibility, benefits and authorization data synced in, and logic kept in the product's format, often CQL.
Does buying a product give a health plan any certification?
No. ONC's HTI-4 rule added CRD, DTR and PAS certification criteria for provider-side health IT, so an EHR module can be certified. Payer-side criteria were proposed in HTI-2 but not finalized, so there is nothing equivalent for health plans today.
Should a health plan build custom APIs to its prior authorization vendors?
No. Ask each vendor to implement CRD exactly as if they were connecting to an EHR and to test against Inferno. Then compose them behind one facade that merges discovery, namespaces prefetch, and keeps the EHR's access token inside the plan.
Which CRD version should a health plan build against?
2.2.1. CMS-0057-F references 2.0.1, but ONC's certification test kit for the HTI-4 CRD criterion is built on 2.2.1, so certified EHRs will be on 2.2.1.
Can a health plan build the facade itself?
Yes. It's a CRD endpoint that routes each hook to the plan's own service or the responsible vendor, backed by a FHIR server the plan hosts. HAPI FHIR works as the base. Buying makes more sense when prior authorization is one of several FHIR APIs the plan needs across multiple versions.
Related articles
View all
How to Implement FHIR Prior Authorization: CRD, DTR, and PAS
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 Is Prior Authorization? What Is Changing in 2027?
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.
