CRD functionality will typically not be able to be fully implemented using payers' existing adjudication engines. The business process involved is quite different:

• Traditional adjudication engines expect a formal submission of a prior authorization request that includes all elements necessary for adjudication, including specific billing codes, modifier codes, billing diagnoses, service types, etc. The specific performer, quantity, performer, timeframe, etc. will all be known and properly specified. A specific response is expected only for the service described.

• With CRD, the only information available is what the clinical user specifically enters when creating a clinical order, appointment, etc. Back-end or financially-oriented users will generally not be involved at all. The user's objective is to drive the clinical process, not the billing process. The codes provided will be clinical ones and the information entered will focus on what the performer needs to execute the request, not on what a payer might want to support prior authorization. Information such as who will perform, where they will perform, when they will perform, etc. may not be known. With CRD there can be multiple contingent responses. For example "Not covered if billed as A or B, covered with prior authorization needed if billed as C or D, and no authorization required if billed as E".

• CRD isn't only seeking information about approval of a prior authorization. It also includes determining whether coverage exists, whether additional information is needed (such as DTR), etc. Legacy engines will not necessarily be set up to do this.

• The timeframes for evaluation will also differ. Many payers have an asynchronous prior authorization process where processing may take several minutes or even longer. CRD timelines are much shorter: 5 to 10 seconds, depending on circumstances.

Because of these consisderations, modifications of existing engines or even development of independent engines to support CRD is likely.

Specific strategies that may be helpful for payers include:

General strategies

It will be common that the amount of information provided may be insufficent for a CRD service to confidently assert whether the requested service is covered or whether prior authorization is needed. Often the answer will be something like "if it's in network, then…", "if it's done on an out-patient basis, then…", or "if it's billed under one of these 3 codes, then…" The base results will fit into one of four buckets: "not covered", "covered with prior authorization required", "covered, with prior authorization granted", or "covered with no authorization needed". Typically the "covered, with prior authorization granted" will not occur if there are multiple possible answers, as payers will not want to grant authorization if it's not clear what service will actually be billed. This means that, even in the worst case, a payer could theoretically provide a response with three coverage-information extensions, each documenting the circumstances in which that particular coverage circumstance will apply.

As much as possible, payers should endeavor to do exactly this. The specification allows payers to indicate the list of billing codes under which a particular option will hold, as well as qualifiers to indicate things such as in/out of network, performer type, etc. that apply to a particular coverage assertion.

However, in some cases the rules for determining what the coverage expectations are are too complex to reasonably express or even to evaluate without more information. In these cases, a payer has a few options:

• If the request in the CDS Hook does not indicate the performer, the timeframe and/or the location and the payer's logic dictates that this information must be known before a reasonable response can be provided, the CRD service can use the 'info-needed' element to indicate what additional information (to be provided during order-dispatch or some other later business stage) is necessary to allow the payer to provide a useful response.

• Otherwise, the 'doc-needed' element can be sent indicating that additional (DTR) questions will need to be answered to provide the CRD service enough information to evaluate coverage.

Terminology

Information passed to the CRD server will typically contain clinical terminologies, might not contain billing terminologies, and will generally not include billing modifier codes or similar information often included in prior authorization requests.

CRD servers will need to support these clinical terminologies or map them to internally-used billing terminologies when determining decision support results. Even when the code present on an order is a billing code such as CPT, the interpretation is different. Having a CPT code on an order does not guarantee that the same CPT code will appear on the eventual claim. CRD services will need to map "order billing codes" to "potential claim billing codes" in the same manner as they map clinical codes.

In situations where CRD clients are aware of the likely billing codes at the time of ordering, they MAY send these codes as additional CodeableConcept.coding repetitions to assist in server processing. If using CPT, note the ability to convey CPT modifier codes via post-coordination as described in the Using CPT page on terminology.hl7.org. However, payers cannot depend on such additional codings being present. Mappings will be required.

This guide does not define how mappings between "ordered" codes and "potential resulting billing codes" are produced. Ideally, such mappings would be informed by payer knowledge of what sorts of claims typically result from orders of a particular type. In some cases, the mappings could vary based on performing organization or practitioner. Mappings will need to evolve as clinical and billing practices evolve and as the clinical and billing terminologies change.