How a health plan splits CRD across prior authorization vendors

The last lesson covered what a payer can send back to the EHR: coverage confirmed with no further action, a message describing what’s required, links to documentation, forms that need completing, or a DTR questionnaire to launch. Those are the responses that come back through the hooks we already went through.

One question comes up constantly. A health plan has its own systems, but it also works with other vendors, and prior authorization decisions for a given patient might actually sit with one of them. How does that get split up? What does the vendor implement, and what does the health plan build itself?

This lesson answers that. We’ll look at why these APIs are composable enough to support that kind of delegation, why the access token from the EHR can’t be forwarded down the chain to a vendor, how discovery works so the EHR sees one unified service rather than one per vendor, and how prefetch gets namespaced once there’s more than one vendor behind the health plan.

We can build CRD, DTR and PAS for you

We already do this for health plans and their vendors. Reach out if you want help with the build, or just want to talk through your setup

Book a Call

These APIs are composable enough to delegate

The answer is that the CDS Hooks APIs underneath CRD are composable enough to support this kind of split. A vendor can implement CRD independently, exactly as if it were connecting to the EHR directly, and the health plan builds a thin client in front of it that proxies the request through.

Testing this isn’t a separate problem either. A vendor implementing CRD on its own can run the same Inferno test suite the health plan would use, since Inferno already covers the CRD testing methodology end to end. That means a health plan can ask its vendors to implement the spec exactly as written and verify it themselves, rather than the health plan having to design and validate a custom integration for each one.

CMS technically mandates CRD 2.0.1, but what’s actually expected of EHRs is 2.2.1. The recommendation, for CRD, DTR, and PAS alike, is to build against 2.2.1 regardless of what’s formally mandated.

The facade pattern

Say a health plan gets a CRD request from the EHR. That request carries a FHIR access token, scoped to the EHR’s own FHIR server, so the health plan can look up whatever it needs about that patient.

The health plan doesn’t just forward that token to whichever vendor is handling this particular plan or set of codes. Instead, it runs its own FHIR server and keeps its own version of that patient data. When the request needs to go out to a vendor, the vendor gets a request against the health plan’s FHIR server, not the EHR’s. The vendor never talks to the EHR directly, and it doesn’t need to. A lot of the time that EHR endpoint sits inside an internal network the vendor couldn’t reach anyway.

So the health plan sits in the middle as a facade. It receives the hook from the EHR, decides which vendor (if any) is responsible for this patient or plan, and proxies the request to that vendor using its own FHIR server as the intermediary. The vendor responds, and the health plan forwards that response back to the EHR using the same mechanisms it would use if it had handled the request itself.

Why the token can’t be forwarded

The CRD spec is direct about this in its privacy and security section. Access tokens provided as part of a CDS Hooks call shouldn’t be forwarded to systems that aren’t managed by the same organization, or that don’t have a Business Associate Agreement in place. Keeping that boundary is what allows for centralized audit of access. The spec also points out an alternative: route requests for information back through the initiating system instead of passing the token along.

What that means in practice is straightforward. The hook coming in from the EHR carries a FHIR access token scoped to that EHR’s own server. The health plan shouldn’t hand that token to a vendor as-is. The vendor has no business relationship with the EHR, and forwarding the token would mean the EHR effectively loses visibility into who’s accessing its data on its behalf.

This is why the facade pattern from the last section exists in the first place. The health plan holds the token, queries its own FHIR server, and gives the vendor a request against that server instead. The vendor never sees the EHR’s token or the EHR’s endpoint at all.

Discovery aggregation

When the EHR sets up CRD, it makes a discovery call asking the health plan what hooks it supports and what services are available. The health plan shouldn’t respond with a separate order-select service for every vendor behind it. That would mean ten hooks showing up for order-select if there are ten vendors, which isn’t something the EHR should have to sort through.

Instead, the health plan does its own discovery call out to each of its vendors first, collects what each one supports, and aggregates all of that into a single, unified response. From the EHR’s side, there’s one /cds-services response, one set of hooks, coming from what looks like a single CRD server. The fact that several vendors sit behind that response is invisible to the EHR entirely.

Prefetch namespacing

Each vendor behind the health plan might ask for its own set of prefetch resources, say a patient, an encounter, or a couple of encounters, each with its own key. When the health plan aggregates all of these into the single service it advertises to the EHR, it can’t just pass those keys through as-is, since different vendors might use the same key names for different things.

So the health plan namespaces them. If vendor one asks for prefetch keys p1, e1, and e2, the health plan renames them to something like vendor1_p1, vendor1_e1, and vendor1_e2 before including them in what it advertises to the EHR. The underscore isn’t required, any consistent prefix works, as long as it’s unique per vendor. The health plan’s own prefetch requirements, if it has any, get added in alongside these without a prefix.

When the EHR actually triggers the hook and sends back the prefetch bundle, the health plan reads off the namespaced keys, works out which vendor each one belongs to, strips the prefix back off, and forwards the vendor its own p1, e1, and e2 exactly as that vendor originally asked for them. Most health plans just forward the prefetch resources through as-is rather than trying to resolve them again themselves.

The closing recommendation

The recommendation is to have every vendor implement the CDS Hooks and CRD spec exactly as written, the same spec the health plan itself implements, rather than coming up with a custom authentication scheme or a bespoke API for each one.

That’s also what makes the facade pattern practical. A vendor can implement CRD on its own, test it against Inferno and the CDS Hooks sandbox, and the health plan can compose it in through the same discovery aggregation and prefetch namespacing already covered. Building something custom per vendor instead means the health plan ends up maintaining a different integration for each business partner, which turns into exactly the kind of mess this approach avoids.