CRD clients SHALL use the billing-options extension to convey likely billing codes if they are known, but are not required to know billing codes (e.g. if ordering and performing systems will differ).

CRD servers SHALL NOT depend on the billing-options extension being present in order to provide a response.

If codes are provided with the billing-options extension, CRD servers SHALL consider any codes provided and MAY consider additional codes determined by their own mapping when returning coverage information responses.

CRD clients SHALL support at least one of the three specified versions of US Core.

CRD servers SHALL be able to handle all three US Core versions.

If the CRD client maintains a mustSupport data element and surfaces it to users, then it SHALL be exposed in their FHIR interface when the data exists and privacy constraints permit.

CRD servers SHALL leverage mustSupport elements as available and appropriate to provide decision support.

CRD servers SHALL populate mustSupport elements if an appropriate value exists.

CRD clients SHALL make the mustSupport data available to the appropriate user (clinical or administrative) or leverage the data within their workflow as necessary to follow the intention of the provided decision support.

When preparing Coverage Information responses, CRD servers SHALL NOT depend on or set expectations for the inclusion of resource instances not compliant with profiles defined in this guide, HRex, or US Core.

CRD servers SHALL NOT depend on or set expectations for the inclusion of any data elements not marked as mandatory (min cardinality >= 1) or mustSupport in those profiles.

When preparing response types other than Coverage Information, CRD servers SHOULD limit themselves to the same resource instances and data elements as permitted above for Coverage Information responses.

CRD clients SHALL NOT depend on or set expectations for CRD servers to communicate data elements not marked as mandatory or mustSupport in the CRD specification.

implementations MAY, by mutual agreement, pre-adopt the use of those additional CI-build profiles and/or mustSupport data elements and not be considered in violation of #1 or #3 above.

Where cardinality and other constraints present in profiles allow data elements to be omitted, CRD compliant systems SHALL NOT treat the omission of those elements as an error.

CRD clients and services and SHALL use standard CRD data elements (i.e. elements found within CRD-defined or inherited profiles and marked as mandatory or mustSupport) to communicate needed data where the elements are intended to convey such information.

CRD implementing organizations SHALL NOT publish guidance setting expectations for where certain data elements are conveyed within CRD and inherited data structures

The union of the scoping elements in each coverage-information repetition SHOULD be disjoint.

If there are multiple reason repetitions, each repetition SHOULD make clear exactly what aspect of the coverage information assertion the reason applies to.

CRD servers SHALL declare at least one supported CRD version for each supported hook.

If the services endpoint can handle multiple CRD versions, it SHALL declare all versions it supports.

The requestedVersion extension SHALL be present if the service indicates it supports multiple versions for that hook, but MAY be present always.

• Each configuration option SHALL include four mandatory elements:

• A code that will be used when setting configuration during hook invocation, and has an (extensible) binding to the CRD Response Types ValueSet.

• A data type for the parameter. At present, allowed values are "boolean" and "integer". (NOTE: These are the JSON data types and not the FHIR data types.)

• A display name for the configuration option to appear in the client's user interface when performing configuration.

• A description providing a 1-2 sentence description of the effect of the configuration option.

• A default value SHALL also be provided to show users what to expect when an override is not specified.

CRD servers SHALL, at minimum, offer configuration options for each type of card they support (with a code corresponding to the CRD Response Types ValueSet and a type of ‘boolean’, where setting the flag to false will result in the server not returning any cards of the specified type).

Guidance can be given about allowed combinations in descriptions, but CRD servers SHALL gracefully handle disallowed/nonsensical combinations.

Configuration codes SHALL be valid JSON property names and SHALL come from the CRD Response Types list if an applicable type is in that list.

Configuration codes, names, and descriptions SHALL be unique within a CDS Service definition.

Configuration codes, names, and descriptions SHOULD be consistent across different hooks supported by the same payer when dealing with the same types of configuration options.

CRD servers providing more than one type of coverage requirement information/guidance SHOULD expose configuration options allowing clients to dynamically control what information is returned by the service.

CRD Clients SHOULD expose configuration options through a configuration screen to allow users and/or system administrators to control the types of information returned.

CRD Clients SHALL convey configuration options when invoking the hook using the davinci-crd.configuration extension. It will be a single object whose properties will be drawn from the code values from configuration options and whose values will be of the type defined for that option.

CRD Clients SHOULD provide an ability to leverage the dynamic configuration capabilities of payer services based on provider role, individual provider, and/or hook invocation location as best meets the needs of their users.

CRD Servers SHALL behave in the manner prescribed by any supported configuration information received from the CRD Client.

CRD Servers SHALL NOT require the inclusion of configuration information in a hook call (i.e. no hook invocation is permitted to fail because configuration information was not included).

CRD Clients MAY send configuration information that CRD Servers do not support.

CRD Servers SHALL ignore unsupported configuration information.

Prefetches with dependencies SHALL be listed after the prefetches they depend on.

When included with a Task, the creation of the Questionnaire needs to be conditional - it SHOULD only occur if that specific Questionnaire version does not already exist

the CRD server SHALL query to determine if the client has a copy of the Questionnaire before sending the request.

For the purposes of this implementation guide, the inclusion of the id element in 'created' resources and references in created and updated resources within multi-action suggestions SHALL be handled as per FHIR's transaction processing rules.

Specifically, this means that if a FHIR Reference points to the resource type and id of a resource of another 'create' Action in the same Suggestion, then the reference to that resource SHALL be updated by the server to point to the id assigned by the client when performing the 'create'.

CRD Clients SHALL perform 'creates' in an order that ensures that referenced resources are created prior to referencing resources.

If a hook service is invoked on a collection of resources, all cards returned that are specific to only a subset of the resources passed as context SHALL disambiguate in the detail element which resources they are associated with in a human-friendly way.

As well, cards SHOULD include the associated-resource extension to allow computable linkage.

CRD clients SHALL only invoke hooks on payer services where the patient record indicates active coverage with the payer associated with the service and where there is no recorded indication the patient intends to bypass insurance coverage (i.e. the service or product is not flagged as 'patient-pay').

CRD clients MAY limit hook invocation to only those payers that are believed to potentially have relevant information related to the current action - for example, clinical guidance, contraindication detection, etc.

To avoid confusion for providers, where a patient has multiple active coverages that could be relevant to the current order/appointment/etc., CRD clients SHALL select from those coverages which is most likely to be primary and only solicit coverage information for that one payer.

This primary coverage SHALL be the only one included in the prefetch content as part of the CRD request, though other coverages MAY be exposed over the CRD client's FHIR API.

If they invoke CRD on other payers, CRD clients SHALL ensure that response types that return coverage information are disabled for those 'likely secondary' payers.

In situations where a CRD client determines that there are different primary coverages for different items in the same order action, they MAY choose to send separate CRD calls (each with its own access token) for the collection of services pertinent to that Coverage.

Where the patient has multiple active coverages that the CRD client deems appropriate to call the respective CRD servers for, the CRD client SHALL invoke all CRD server calls in parallel and display results simultaneously to ensure timely response to user action.

CRD servers and CRD clients MAY mutually agree to support additional hooks, additional card patterns, additional resources, additional extensions, etc.

CRD servers SHALL return responses for all supported hooks and SHALL respond within the required time 90% of the time.

If a CRD client does not receive a response within the 5 or 10-second window, it MAY either abandon the call or process the response asynchronously.

Where a CRD server responds with a coverage information extension indicating doc-needed of 'clinical', 'admin', or 'patient' and the payer supports DTR, the responsible organization SHOULD support gathering the additional information via DTR.

CRD servers SHOULD query all data necessary to make their coverage determination decisions if that data is available for query in the EHR and that data is not returned in prefetch.

CRD clients SHALL provide a mechanism for providers to bypass a CRD process that is taking longer than the aforementioned time limit to ensure users are not blocked from proceeding with their business flow.

For responses that come back in a time period that exceeds the time maximm duration specifd in this guide, CRD clients MAY ignore the resulting cards and/or system actions.

CRD servers SHALL ensure that the guidance returned with respect to coverage and prior authorizations (e.g., assertions that a service is covered, or prior authorization is not necessary) is as accurate as guidance that would be provided by other means (e.g., portals, phone calls).

Also, coverage and authorization guidance SHOULD allow for possible variances in coding and submission.

CRD servers SHALL retain all coverage guidance provided and take into account answers provided via CRD (and DTR) when subsequently adjudicating claims.

Where the selected code is not already a billing code and CRD clients are able to automatically determine what the corresponding billing code is, they SHOULD send a Coding with the billing code alongside the clinical code to reduce the risk of the receiving payer making a different translation.

CRD servers SHALL ensure that CDS Hooks return only messages and information relevant and useful to the intended recipient.

If a CRD server supports endpoint discovery, they SHALL have at most a single endpoint for each coverage (e.g., Medicare, Medicaid, or commercial) they provide coverage under.

If a CRD server does not support endpoint discovery, they SHALL expose only one CRD endpoint capable of handling all coverages.

When the connection between a particular client and server has evolved to an automated configuration approach, CRD Clients SHOULD perform the discovery process on the CRD server at least once per day to detect any changes to supported hooks, prefetch requirements, and/or configuration options.

If a CRD client encounters an error when invoking a hook, they SHOULD re-run the discovery process before failing.

CRD clients and servers MAY leverage the payer registry developed by PDex (which will eventually fold into the national directory under FAST) as a means of determining which endpoints exist for which payers as candidates for configuration.

Once plans are in the national directory, CRD clients SHOULD include that plan identifier to uniquely identify a plan.

When a CRD client invokes a CRD server via CDS Hooks, it SHALL provide an access token that allows the CRD server to retrieve additional patient information.

The CRD client SHALL limit the scopes provided in their access token as narrowly as feasible to reflect the data requirements identified by the CRD server as necessary to perform their decision support.

Such access tokens SHOULD have an expiration time of no longer than 30 seconds which should be sufficient for even 'parallel' decision support with something like 'Order Select' where a user continues to work while the decision support call is processing.

For this release of the IG, conformant CRD clients and servers SHALL support the CDS Hooks prefetch capability.

Clients SHALL be able to supply all the existing resources defined in the prefetch section below for request resources they support.

Servers SHALL use prefetch expressions in the manner described if those data elements are relevant to their coverage determination or other decision support.

They MAY include more and/or less prefetch requests than described in this Additional Data Retrieval section, based on which data is desired.

Prefetch requests SHOULD only include information that is always expected to be needed for each hook invocation.

When information is only needed for certain invocations of the hook (e.g., for specific types of medications or services), that information SHALL only be retrieved by query using the provided token, never requested universally via prefetch.

CRD Servers SHALL be able to parse and execute prefetches that use the x-fhir-query syntax defined in the current CDS Hooks specification and not fail if that syntax is present.

CRD client implementations SHOULD NOT depend on standardized prefetch key names.

CRD clients supporting prefetch SHALL inspect the CDS Hooks discovery endpoint to determine exact prefetch key names and queries.

As mentioned in Controlling Hook Invocation, Coverage included in prefetch SHALL be limited to a single instance.

HTTP 412 responses SHALL NOT be used in situations where the prefetch was provided or the query was successfully performed but the record in question did not have all the data the payer might have needed/desired.

CRD clients and servers SHALL ignore unexpected elements when processing instances.

CRD servers SHALL provide what coverage requirements they can based on the information available.

In the specific case of order-based hooks, "what if" SHOULD use the Order Sign hook but SHALL use the configuration option that prevents the return of an unsolicited determination and MAY use configuration options to prevent the return of other irrelevant types of cards (e.g., duplicate therapy).

When CRD clients pass resources to a CRD server as part of context, the resources SHALL have an 'id' and that 'id' SHALL be usable as a target for references in resources manipulated by CDS Hooks actions and/or by SMART apps.

Therefore, in addition to any logging performed for security purposes, both CRD clients and CRD servers SHALL retain logs of all CRD-related hook invocations and their responses for access in the event of a dispute.

Organizations SHALL have processes to ensure logs can be accessed by appropriate authorized users to help resolve discrepancies or issues in a timely manner.

NOTE: Because the information in these logs will often contain PHI, access to the logs themselves will need to be restricted and logged for security purposes.

CRD clients SHOULD ensure that multiple cards with the same advice are handled in a way that will not create a burden on the user.

Conformant systems SHOULD omit non-significant whitespace in transmitted instances for performance reasons.

CRD Clients conforming to this implementation guide SHALL be able to determine the correct payer CRD server to use for each request.

CRD Clients conforming to this implementation guide SHALL support at least one of the hooks and (for order-centric hooks), at least one of the order resource types listed below, and SHOULD support all that apply to the context of their system.

For systems that support ordering products or services covered by one of the CRD-supported request types, such clients SHALL support the order-sign hook for the order types they support.

CRD Servers conforming to this implementation guide SHALL provide a service for all hooks and order resource types required of CRD clients by this implementation guide unless the server has determined that the hook will not be reasonably useful in determining coverage or documentation expectations for the types of coverage provided.

CRD Clients and CRD Servers MAY choose to support additional hooks available in the registry on the CDS Hooks continuous integration build or custom hooks defined elsewhere.

When supporting hooks not covered by this guide, systems SHOULD adhere to the general conformance expectations defined in this specification for those additional hooks.

CRD clients SHALL allow hook invocation to occur transparently as part of user workflow.

CRD clients SHALL NOT require transcription of order, appointment, or other data into a separate interface distinct from regular provider workflow unless performing "what if" situations.

If the CRD Server encounters an error when processing the request, the system SHALL return an appropriate error HTTP Response Code, starting with the digit "4" or "5", indicating that there was an error.

If an issue is identified at a layer of the CRD Server that is FHIR aware (e.g. not a "wrong endpoint" or "not authorized" issue), the server SHALL provide an OperationOutcome for internal issue tracking by the client system.

The CRD Client MAY display to the user that the Coverage Requirements Discovery Service is unavailable.

If additional information (e.g. number to call) is available, it MAY also be included in the message to the user.

• While any 4xx or 5xx response code could be raised, the CRD Server SHALL use the 400 and 422 codes in a manner consistent with the FHIR RESTful Create Action, specifically:
• 400 - Bad Request - The request is not parsable as JSON or the content fails validation against FHIR core or CDS Hooks specification rules. Also used if a CRD server receives a call where the primary Coverage (either provided by prefetch or queried by the payer) does not have a payer.identifier that identifies a payer that is handled by that CRD server endpoint, the server SHALL return a 400 error and SHOULD provide an OperationOutcome. This includes situations where no Coverage is accessible, multiple Coverages are accessible, or the provided Coverage does not have a payer.identifier at all.
• 422 - Unprocessable Entity - The request is valid JSON and meets FHIR and CDS Hook validation rules, but fails to adhere to constraints imposed by this specification.

If a CRD server's validation process does not differentiate between validation issues stemming from the JSON syntax validation, FHIR core validation, CDS Hooks validation, and CRD-specific validation, it MAY treat all validation rules as 400 errors.

A CRD client MAY opt to re-invoke a CRD hook either due to manual user intervention or automatically in the background if there is a reason to believe that a substantive change in the patient's record and/or coverage might produce a different CRD response.

CRD Servers SHALL, at minimum, return a Coverage Information system action for 'primary' hooks, even if the response indicates that further information is needed or that the level of detail provided is insufficient to determine coverage.

These hooks MAY return cards or system actions, but are not expected to, and CRD clients are free to ignore any cards or actions returned.

CRD clients SHOULD use the configuration options to instruct CRD servers to not even try to return responses if the client does not intend to display/process them.

If Coverage Information is returned for these hooks, it SHALL NOT include messages indicating a need for clinical or administrative information, as such information is expected to be made available later in the process and therefore such guidance is not useful.

Where profiles are provided in a table for the hook sections below, CRD clients SHALL ensure that data included in the hook invocation complies with the listed profiles.

CRD servers SHALL NOT depend on data not covered by the identified profiles in order to return valid coverage-information responses.

CRD Servers SHALL handle unrecognized context elements by ignoring them.

CRD Servers MAY use the appointment-book hook as a basis for associating a patient with a particular practitioner from a payer attribution perspective.

CRD clients and servers SHALL, at minimum, support returning and processing the Coverage Information system action for all invocations of the appointment-book hook.

CRD Servers MAY use the appointment-book hook as a basis for associating a patient with a particular practitioner from a payer attribution perspective.

Coverage requirements SHOULD be limited only to those resources that are included in the dispatchedOrders context, though the content of other resources SHOULD also be considered before making recommendations about what additional actions are necessary.

CRD Servers MAY use the order-dispatch hook as a basis for associating a patient with a particular practitioner from a payer attribution perspective.

CRD clients and servers SHALL, at minimum, support returning and processing the Coverage Information system action for all invocations of the order-dispatch hook.

Coverage requirements SHOULD be limited only to those resources that are included in the selections context, though the content of other resources SHOULD also be considered before making recommendations about what additional actions are necessary.

Where CRD Clients have an appropriate workflow and data capture mechanism, the order-select hook MAY be used in scenarios that do not involve creating a true order.

CRD Servers MAY use the order-select hook as a basis for associating a patient with a particular practitioner from a payer attribution perspective.

CRD clients and servers SHALL, at minimum, support returning and processing the Coverage Information system action for all invocations of the order-select hook.

Clients that suppress 'default presumption' coverage-information of messages SHALL mitigate the potential for misinterpretation in the event CRD is unavailable.

CRD servers SHOULD strive to achieve a minimum of 3-9s availability for their services and strive to provide at least some level of useful response to CRD clients even if some of their back-end systems are unavailable.

Even if implemented using multiple components, there is still a requirement that the exchanges between the provider HIT (including any ePA coordinators) and the payer HIT (including any ePA coordinators) SHALL replicate all of the defined exchanges between provider and payer.

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.

Where a CRD server has made inferences beyond what is explicit in the CRD request, the response SHOULD make clear what assumptions around billing codes, in/out-of-network, delivery location were made in providing the response.

Each of these IGs recommends a set of metrics that SHOULD or MAY be collected by their respective implementations to facilitate the evaluation of adoption, functionality, processes, and improved outcomes.

CRD clients and servers SHOULD support encounter-start and order-select, both to allow payer caching and to allow payers to return useful responses when possible (e.g. coverage expired, service not covered) with the limited information available in those hooks.

CRD Clients SHALL use either this Appointment with Order profile and/or the with-order to provide appointments context objects to CRD Servers when invoking the appointment-book hook as well as to resolve other references to Appointment resources.

CRD Clients SHALL use either this Appointment without Order and/or the no-order to provide appointments context objects to CRD Servers when invoking the appointment-book hook as well as to resolve other references to Appointment resources.

CRD Clients SHALL use the CRD CommunicationRequest profile to resolve references to CommunicationRequest resources passed to CRD Servers (e.g. selections context references) and to populate draftOrders context objects when invoking the following CDS Hooks:

• order-select
• order-sign
• order-dispatch

CRD Clients SHALL use the CRD Coverage profile to resolve references to insurance Coverage resources passed to CRD Servers.

CRD Clients SHALL use the CRD Device profile to resolve references to Device resources passed to CRD Servers.

CRD Clients SHALL use the CRD DeviceRequest profile to resolve references to DeviceRequest resources passed to CRD Servers (e.g. selections context references) and to populate draftOrders context objects when invoking the following CDS Hooks:

• order-select
• order-sign
• order-dispatch

CRD Clients SHALL use the CRD Encounter profile to resolve references to Encounter resources passed to CRD Servers, including encounterId context references when invoking the following CDS Hooks:

• appointment-book
• encounter-start
• encounter-discharge
• order-select
• order-sign
• order-dispatch

CRD Clients SHALL use the CRD Location profile to resolve references to insurance Location resources passed to CRD Servers.

CRD Clients SHALL use the CRD MedicationRequest profile to resolve references to MedicationRequest resources passed to CRD Servers (e.g. selections context references) and to populate draftOrders context objects when invoking the following CDS Hooks:

• order-select
• order-sign
• order-dispatch

CRD Clients SHALL use CRD NutritionOrder profile to resolve references to NutritionOrder resources passed to CRD Servers (e.g. selections context references) and to populate draftOrders context objects when invoking the following CDS Hooks:

• order-select
• order-sign
• order-dispatch

CRD Clients SHALL use the CRD ServiceRequest profile to resolve references to ServiceRequest resources passed to CRD Servers (e.g. selections context references) and to populate draftOrders context objects when invoking the following CDS Hooks:

• order-select
• order-sign
• order-dispatch

CRD Clients SHALL use the CRD VisionPrescription profile to resolve references to VisionPrescription resources passed to CRD Servers (e.g. selections context references) and to populate draftOrders context objects when invoking the following CDS Hooks:

• order-select
• order-sign
• order-dispatch

If a Location is a fine-grained location such as a bed or room, the address SHALL be propagated from the higher-level location it is part of.

While the codes for the medication are expected to be drawn from RxNorm, EHRs MAY send additional coding repetions to communicate other code systems (e.g. HCPCS J codes).

The Card.indicator SHOULD be populated from the perspective of the clinical decision maker, not the payer

Most Coverage Requirements SHOULD be marked as 'info'.

All Card.suggestion elements SHALL populate the Suggestion.uuid element.

The Card.source.label SHALL be populated with an insurer name that the user and patient are likely to recognize (i.e., the responsible insurer on the patient's insurance card), including in situations where coverage recommendations are being returned by a benefits manager or intermediary operating the CRD server on behalf of the payer.

Card.source.topic SHALL be populated, and has an extensible binding to the ValueSet CRD Response Types.

Card.summary SHOULD provide actionable information.

Card.detail and/or external links SHOULD only be provided when coverage recommendations cannot be clearly provided in the 140-character limit of Card.summary.

Card.detail SHOULD provide graduated information, with critical information being provided in the first paragraph and less critical information towards the end of the page.

Card.detail SHOULD provide enough context that a user can determine whether it is worth their time to launch an app or follow an external link, ideally providing a sense of where to look for and how to use whatever link or app they launch in the specific context of the order they are making.

While links are permitted in the markdown content of Card.detail, support for this is not universal, so links SHOULD also be provided in Card.link.

CRD client systems might not support all card capabilities, therefore card options SHOULD provide sufficient information for a user to perform record changes manually if automated support is not available.

Where systemActions are used, CRD servers SHOULD NOT return equivalent information in a card for user display.

Conformant CRD clients and services SHALL support the Coverage Information response type.

Conformant CRD clients and services SHOULD support the additional (non-coverage information) types defined by this guide.

CRD servers that provide decision support for domains outside of coverage and/or documentation requirements SHOULD take reasonable steps to check that the CRD client does not have the information within its store that would allow it to detect the issue itself.

CRD servers SHALL NOT use "External Reference" cards to direct users to a portal for the purpose of initiating prior authorization or determining coverage.

The card SHALL have at least one Card.link.

The Link.type SHALL have a type of "absolute".

When reasonable, an "External Reference" card SHOULD contain a summary of the actionable information from the external reference in the detail element.

As much as technically possible, links provided SHOULD be 'deep' links that take the user to the specific place in the documentation relevant to the current hook context to minimize provider reading and navigation time.

CRD servers SHALL NOT use Instructions Response cards to direct users to a portal for the purpose of initiating prior authorization or determining coverage. Use the Coverage Information response instead.

Regardless of the content, this "Coverage Information" response type SHALL NOT use a card.

CRD servers SHALL support supplying coverage information for all primary hooks: order-sign, order-dispatch, and appointment-book.

CRD servers MAY support supplying coverage information for all other (non-primary) hooks.

CRD servers SHALL supply coverage information for all hooks where they support it unless the EHR sends a configuration option asking them not to.

If coverage information is evaluated, a system action SHALL be returned for each in-scope request resource unless that request resource already has a coverage-information extension, and the CRD server has no new information to add.

Such qualifiers around when the coverage assertion is considered valid SHALL be included as part of the annotation.

If a CRD client submits a claim related to an order for which it has received a coverage-information extension for the coverage type associated with the claim, that claim SHALL include the coverage-assertion-id and, if applicable, the satisfied-pa-id in the X12 837 K3 segment.

If multiple extension repetitions of the coverage-information extension are present, all repetitions referencing differing insurance (coverage-information.coverage) SHALL have distinct coverage-assertion-ids and satisfied-pa-ids, if present.

Where multiple repetitions apply to the same coverage, they MAY have the same coverage-assertion-ids and satisfied-pa-ids (if present).

Systems MAY make CRD calls to servers related to orders even if there is already a coverage assertion recorded on the order.

However, CRD servers SHALL NOT send a systemAction to update the order unless something is new or changed.

CRD servers SHOULD take into account the previous decision in deciding how much processing is necessary before returning a response.

When returning a systemAction to update a resource with the "Coverage Information" response type, the resource content SHALL NOT make changes to any data elements other than adding or modifying coverage-information extensions.

If a coverage-information extension indicates the need to collect additional information (via 'doc-needed'), the extension SHOULD include a reference to the questionnaire(s) to be completed.

When a coverage-information response type indicates that additional clinical or patient documentation is needed and the CRD client supports DTR, CRD clients SHALL ensure that clinical users have an opportunity to launch their DTR solution as part of the current workflow.

CRD clients SHOULD allow clinical users to have an opportunity to launch their DTR solution but SHOULD make it clear that the information to be captured is non-clinical.

The CRD server SHOULD either prompt for the additional needed information using DTR or return a coverage-information extension indicating that the patient is not covered with a reason indicating the issue (e.g. the member could not be found/resolved).

If the CRD server is unable to resolve the patient, the Coverage Information SHALL indicate "not covered" with a reason code of no-member-found.

If the CRD is able to resolve the patient but they do not have active coverage, the Coverage Information SHALL indicate "not covered" with a reason of no-active-coverage.

If a system action containing a coverage-information extension is returned, the CRD client SHALL retain that coverage-information extension and expose it as part of the Request resource in all subsequent communications with that payer, including communications made using DTR and PAS.

When using the "Coverage Information" response type, the proposed order or appointment being submitted SHALL comply with the following profiles:

CRD clients and servers SHALL support the new CDS Hooks system action functionality to cause annotations to automatically be stored on the relevant request, appointment, etc. without any user intervention.

In this case, the discrete information propagated into the order extension SHALL be available to the user for viewing. However, this might be managed with icons, flyovers, or alternate mechanisms than traditional CDS Hooks card rendering.

CRD clients MAY be configured to not execute system actions under some circumstances, for example if the order has been cancelled or abandoned.

Where CRD servers need for data that was not transmitted, they SHOULD attempt to infer values from elements that are present.

Each suggestion SHOULD contain either a single "update" action to revise the existing proposed order; or a "delete" action for the current proposed order and a "create" action for the new proposed order.

The choice of "update" vs. "delete + create" SHOULD be based on how significant the change is and how relevant the other decision support on the original request will still be.

When using the "Propose Alternate Request" response type, the proposed orders (and any associated resources) SHALL comply with the following profiles:

† Only used if updating an Encounter (e.g., to add a note)

When using the "Identify Additional Orders" response type, the proposed orders and any associated resources SHALL comply with the following profiles:

The Request Form Completion response type SHALL NOT be used if:

1. DTR is applicable to the use case (i.e. the form relates to prior auth, claim submission, appropriate use, or order fulfillment),
2. DTR is supported by the CRD client (whether voluntarily or as required by regulation), and
3. DTR is available from the server (e.g. not temporarily unavailable or not supported by a payer not subject to regulation).

Instead of using a card for "Request Form Completion", CRD servers MAY opt to use a systemAction.

CRD clients supporting the Request Form Completion response type SHALL support both the card and systemAction approach.

When using the "Request Form Completion" response type, the resources in the card or system action SHALL comply with the following profiles:

CRD servers SHOULD use questionnaires that are compliant with either the Argonaut questionnaire profiles (for forms to be completed within the CRD client) or the Structured Data Capture (SDC) profiles (for more sophisticated forms to be created within a SMART on FHIR app or through an external service).

CRD clients SHOULD retain a copy of all completed forms for future reference.

Instead of using a card for "Update Coverage Records", CRD servers MAY opt to use a systemAction instead.

CRD clients supporting the Update Coverage Records response type SHALL support both the card and system action approach.

If receiving a system action, a CRD client MAY opt to place the updated record in a holding area for human review rather than directly modifying their source of truth.

This Update Coverage Records capability SHALL NOT be used in situations where regulation dictates the use of the X12 functionality.

If returning a card rather than a system action, the "Update Coverage Records" response type SHOULD NOT be returned for hook types that are likely to be triggered by clinical users rather than administrative staff. Cards of this type would be appropriate for hooks such as encounter-start or appointment-book but would not be appropriate for order-select or order-sign.

Implementers SHALL adhere to any security and privacy rules defined by:

• FHIR Core: Security & Privacy Module, Security Principles and Implementer's Checklist
• HRex: Privacy & Security
• CDS Hooks: Security & Safety
• SMART on FHIR: SMART App Launch

As per the CDS Hooks specification, communications between CRD clients and CRD servers SHALL use TLS.

CRD servers and CRD clients SHOULD enforce a minimum version and other TLS configuration requirements based on HRex rules for PHI exchange.

CRD clients that support the Launch SMART Application Response Type SHALL support running applications that adhere to the SMART on FHIR confidential app profile.

CRD servers SHALL use information received solely for coverage determination and decision support purposes.

Servers SHALL NOT retain data received over the CRD interfaces for any purpose other than audit or providing context for form completion using DTR.

CRD clients SHALL ensure that the resource identifiers exposed over the CRD interface are distinct from and have no determinable relationship with any business identifiers associated with those records.

CRD client organizations SHOULD audit access to check for reasonableness and appropriateness.

• Access tokens provided as part of CRD calls SHOULD NOT be forwarded to systems that are not managed by the same organization or have business associate agreements that allow centralized audit of access. Possible alternatives to token-sharing include:
• Routing all requests for information through the initial endpoint system
• Making use of RFC 8693 to allow the creation of 'delegate' tokens for downstream systems"

Additional testing and standardization work needs to happen around making delegated access function well, particularly in a time-constrained environment.