Da Vinci - Coverage Requirements Discovery
2.2.0-snapshot - STU 2.2 Peer Review

Da Vinci - Coverage Requirements Discovery, published by HL7 International / Financial Management. This guide is not an authorized publication; it is the continuous build for version 2.2.0-snapshot built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/HL7/davinci-crd/ and changes regularly. See the Directory of published versions

## CDS Hooks Response Profiles

Page standards status: Trial-use | Highlight text changes?

CDS Hooks defines two different mechanisms for services to respond to a hook call: cards and system actions. This page profiles (constrains) the general rules for these responses from the CDS Hooks specification to reflect how they must be used when complying with this CRD specification.

### General Card and SystemAction rules

In addition to the guidance provided in the CDS Hooks specification, the following additional guidance applies to CRD servers when constructing cards:

- The `Card.indicator` SHOULD be populated from the perspective of the clinical decision maker, not the payer §resp-1. While failure to procure a prior authorization might be 'critical' from the perspective of payment, it would be - at best - a 'warning' from the perspective of clinical care. 'critical' must be reserved for reporting life or death or serious clinical outcomes. Issues where the proposed course of action will negatively affect the ability of the payer or patient to be reimbursed would generally be a 'warning'. Most Coverage Requirements SHOULD be marked as 'info'. §resp-2

- All `Card.suggestion` elements SHALL populate the Suggestion.uuid element. §resp-3

- 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. §resp-4 If an insurer provides recommendations from another authority (e.g., a clinical society), the society's name and logo might be displayed, though usually only with the permission of that organization.

- `Card.source.topic` SHALL be populated, and has an extensible binding to the ValueSet CRD Response Types. §resp-5 The rationale is to allow CRD clients to filter or track the usage of different types of cards.

- Users are busy. Time spent reading a payer-returned card is time taken from reviewing other information or interacting with the patient. If not useful or relevant, users will quickly learn to ignore - or even demand the disabling of - payer-provided alerts. Therefore, information must be delivered efficiently and be tuned to provide maximum relevance. Specifically:

  - `Card.summary` SHOULD provide actionable information. §resp-6 "Coverage alert" would not be very helpful. "Drug not covered. Covered alternatives available" or "Prior authorization required" would be better.

  - `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`. §resp-7

  - `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. §resp-8

  - `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. §resp-9

  - Keep the number of cards manageable. Consider whether user workflow will be faster with separate cards for each link or a single card having multiple links. Typically, it is best to use the smallest number of cards that still support descriptive and actionable summaries.

  - When providing links, do not send the user to the first page of a large document. Keep document size short and/or link directly to the section that is relevant for the context.

  - 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`. §resp-10 This also provides a consistent place for users to access all relevant links.

- 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. §resp-11

- Where systemActions are used, CRD servers SHOULD NOT return equivalent information in a card for user display. §resp-12 It is the responsibility of the CRD client to determine how best to present the results of the newly created or revised records.

A profile defining the generic constraints that apply to all CRD responses can be found here.

### Potential CRD Response Types

The sections below describe the different types of responses that CRD servers can use when returning coverage requirements to CRD clients, including CRD-specific profiles on cards to describe CRD-expected behavior. It is possible that some CRD servers and CRD clients will support response types other than those listed here (i.e. other allowed sets of constraints on Card and/or SystemAction). Such behavior is outside the scope of this specification. Future versions of this specification might standardize additional response types.

Conformant CRD clients and services SHALL support the Coverage Information response type. §resp-13 (See specific support expectations documented there.) Conformant CRD clients and services SHOULD support the additional (non-coverage information) types defined by this guide. §resp-14

NOTE: Support for a response type does not mean that all orders, appointments, etc. will necessarily receive card guidance, merely that it must be able to return those response types for at least a subset of CRD invocations.

Provision of and acceptance of decision support cards outside the coverage and documentation requirements space is optional (for both server and client). CRD servers that provide decision support for domains outside of coverage and/or documentation requirements are expected to only provide decision support that the CRD client cannot do alone. To minimize duplicate alerts and provider burden, 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. §resp-15 If the information already exists in the CRD client, then the obligation is on the CRD client to manage the issue detection and reporting in its own manner and CRD servers should not get involved.

Response types are listed from least sophisticated to most sophisticated, and potentially more useful or powerful. As a rule, the more a response can automate manual processes and the more context-specific the behavior is, the more useful the decision support will be to the clinician and the more likely it will be used.

Notes:

- CRD clients will provide resources, such as MedicationRequest, in the context object of the CDS Hooks request. These resources might be temporary in the context in which the CDS Hook is triggered, such as when a proposed medication order is being reviewed. In this case, the CDS client must maintain a stable identifier for these temporary resources to allow CRD responses to refer to them in CDS Hook actions.

- Hook responses may contain multiple cards and/or system actions corresponding to a mixture of the response types defined in this IG. For example, providing links, textual guidance, as well as suggestions for alternative orders.

- The response types listed here are not the same as the Configuration Options specified above. A single response type could correspond to multiple configuration options. For example, External Reference could apply to clinical practice guidelines, prior authorization requirements, claims attachment requirements, and other things. Similarly, one configuration option could be satisfied with multiple response types. For example, required prior authorization forms could include both External References and explicit Request Form Completion responses.

### External Reference Response Type

This response type presents a card with one or more links to external web pages, PDFs, or other resources that provide relevant coverage information. The links might provide clinical guidelines, prior authorization requirements, printable forms, etc. Typically, these references would be links to information available from the payer's website, though pointers to other authoritative sources are possible too. CRD servers SHALL NOT use "External Reference" cards to direct users to a portal for the purpose of initiating prior authorization or determining coverage. §resp-16 Use the Coverage Information response instead.

The card SHALL have at least one `Card.link`. §resp-17 The `Link.type` SHALL have a type of "absolute". §resp-18

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

For example, this CDS Hooks Card contains two Links - a standard and a printer-friendly version.

    {
      "extension" : {
        "davinci-crd.associated-resource" : [
          {
            "reference" : "ServiceRequest/2468"
          }
        ]
      },
      "uuid" : "urn:uuid:07bc9814-9d2a-11ee-8c90-0242ac120002",
      "summary" : "CMS Home Oxygen Therapy Coverage Requirements",
      "detail" : "Learn about covered oxygen items and equipment for home use; coverage requirements; criteria you must meet to furnish oxygen items and equipment for home use; Advance Beneficiary Notice of Noncoverage; oxygen equipment, items, and services that are not covered; and payments for oxygen items and equipment and billing and coding guidelines.",
      "indicator" : "info",
      "source" : {
        "label" : "Centers for Medicare & Medicaid Services",
        "url" : "https://example.org/cms",
        "topic" : {
          "system" : "http://terminology.hl7.org/CodeSystem/cdshooks-card-type",
          "code" : "guideline",
          "display" : "Guideline"
        }
      },
      "links" : [
        {
          "label" : "Home Oxygen Therapy Guidelines",
          "url" : "https://example.org/cms/Outreach-and-Education/Medicare-Learning-Network-MLN/MLNProducts/Downloads/Home-Oxygen-Therapy-ICN908804.pdf",
          "type" : "absolute"
        },
        {
          "label" : "Home Oxygen Therapy Guidelines (printer-friendly)",
          "url" : "https://example.org/cms/Outreach-and-Education/Medicare-Learning-Network-MLN/MLNProducts/Downloads/Home-Oxygen-Therapy-Text-Only.pdf",
          "type" : "absolute"
        }
      ]
    }

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. §resp-20

A profile defining the expectations of an External Reference response can be found here.

### Instructions Response Type

This response type presents a card with textual guidance to display to the user making the decisions. The text might provide clinical guidelines, suggested changes, or rules around prior authorization. It can be generated in a more sophisticated context for the payer, while remaining easy to consume for the provider because it allows returned information to be tuned to the specific context of the order/encounter that triggered the hook. In some cases, the text returned might be generated uniquely each time a hook is fired. 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. §resp-21

This example CDS Hooks card just contains a message:

    {
      "uuid" : "urn:uuid:fbc9e223-4ba8-4bb9-a31c-4720c14f00d2",
      "summary" : "Patient is overdue for a PAP smear",
      "detail" : "Last date on record for a PAP test for this patient was May, 2014.  Tests should ideally be performed every 1-3 years",
      "indicator" : "info",
      "source" : {
        "label" : "You are Covered Insurance",
        "url" : "https://example.org",
        "icon" : "https://example.org/img/icon-100px.png",
        "topic" : {
          "system" : "http://terminology.hl7.org/CodeSystem/cdshooks-card-type",
          "code" : "clinical-reminder",
          "display" : "Clinical Reminder"
        }
      }
    }

A profile defining the expectations of an Instructions response can be found here.

### Coverage Information Response Type

This response type uses a systemAction to automatically update the order or other resource in the CRD client with an extension that conveys information related to the coverage of the order. As discussed on the home page, the functionality of this response type has been enhanced to allow directly returning a prior authorization number as part of a CRD response. Regardless of the content, this "Coverage Information" response type SHALL NOT use a card. §resp-22

Support expectations for this hook by CRD servers are as follows:

1. CRD servers SHALL support supplying coverage information for all primary hooks: order-sign, order-dispatch, and appointment-book. §resp-23
2. CRD servers MAY support supplying coverage information for all other (non-primary) hooks. §resp-24
3. CRD servers SHALL supply coverage information for all hooks where they support it unless the EHR sends a configuration option asking them not to. §resp-25
4. 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. §resp-26

A new FHIR coverage-information extension is defined that allows assertions around coverage and prior authorization to also be captured computably, including what assertion is made, what coverage the assertion is made with respect to, when the assertion was made, and - optionally - a trace ID that can be used for audit purposes.

The extension generally gets added to the request resource that was passed to the CDS server (the Appointment, Encounter, ServiceRequest, etc.). There is one exception, which is if an Appointment is 'basedOn' a ServiceRequest, the system action requesting a resource update to add or change the coverage-information extension(s) will be against the ServiceRequest, not the appointment.

Assertions about coverage, prior authorization requirements, etc. are contingent on the eventual claim for the ordered service being aligned with payer expectations. Because the order/appointment/etc. will not have the same information that would typically be included in a formal request for prior authorization or pre-determination, the payer will need to infer from the order what billing codes, qualifiers, dollar amounts, etc. would typically be involved. In some cases, the answer might differ depending on factors such as in/out of network, when the service is delivered, etc. Such qualifiers around when the coverage assertion is considered valid SHALL be included as part of the annotation. §resp-27

If a CRD server has provided limitations about when a coverage assertion applies that turn out to not be consistent with what the provider intends to do (e.g., payer says "covered if billed as X", but provider intends to bill as Y), then the provider can always use the normal prior authorization process to solicit an authorization that more precisely aligns with their expectations for how the service will eventually be billed.

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. §resp-28 Further details about the specific location of each element will be available in the X12 specifications. These identifiers will provide the necessary context to allow the payer to respect any commitments made as part of the CRD call and also to link together CRD results and eventual claims for analytics purposes.

In some cases, multiple coverage-information extension repetitions may be added by the CRD server. This might represent different guidance for different coverages the service supports for the same patient or different expectations (related to coverage, prior auth, or additional information) for different billing codes, different qualifiers (e.g., in-network vs out-of-network), etc. 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. §resp-29 Where multiple repetitions apply to the same coverage, they MAY have the same coverage-assertion-ids and satisfied-pa-ids (if present). §resp-30 It is possible that some repetitions for a coverage might have satisfied prior authorization with an ID, while others will not.

Systems MAY make CRD calls to servers related to orders even if there is already a coverage assertion recorded on the order. §resp-31 There is always the possibility that context has changed or new information available in the order will result in a new decision or additional guidance. The payer might also have other useful information not related to coverage or authorization. Information about the order or context might change between an initial `order-select` or `order-sign` and a subsequent `order-dispatch` or other hook invocation.

However, CRD servers SHALL NOT send a `systemAction` to update the order unless something is new or changed. §resp-32 CRD servers SHOULD take into account the previous decision in deciding how much processing is necessary before returning a response. §resp-33

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. §resp-34

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. §resp-35 If the payer supports Da Vinci DTR, the indicated forms will be the ones completed within the DTR form filler. If no Questionnaires are specified, DTR will determine the needed forms itself. For systems that do not support DTR (e.g. because the coverage is not subject to regulation mandating DTR), the indicated Questionnaire canonicals can be used to determine data to be gathered in some other (non-DTR) way.

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. §resp-36 Where a coverage-information response indicates that additional administrative documentation is needed, 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. §resp-37

NOTE: Launching DTR does not necessarily mean launching a SMART on FHIR application. Some CRD clients might incorporate DTR client functionality natively rather than using an app.

When invoking CRD, there may be situations where 'needed' information is not available. For example, the date of birth might be 'unknown' and there might only be a subscriber id but not a member id. Alternatively, the payer may not be able to find a member with the specified identifier, the payer might want a location and none is provided, or the payer needs a diagnosis code, but the provided code is free text. In such situations, this is NOT considered an error with the CDS Hooks invocation. A successful response with a coverage-information system action is still necessary.

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). §resp-38

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. §resp-39

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. §resp-40

This specification allows returning either a single coverage-information repetition that says "conditional" or multiple coverage-information repetitions with specific assumptions that then indicate "covered", "auth-needed", etc. The recommended criteria for deciding whether to return a single or multiple are as follows:

- If the decision is driven by different subsets of billing codes or different timeframes (i.e. discrete information that can be conveyed using coverage-information.billingCode or detail codes of allowed-period), then use multiple repetitions.
- If the decision is driven by other information that cannot be easily listed in the coverage-information (e.g. what specific provider delivers the service, where it happens, etc.) then use 'Conditional' and indicate the specific additional information needed to make a decision.

For example, if the payer does not know whether authorization is necessary (or if the service is covered at all) because it is necessary to know whether the performer will be in network or not, this ought to be conveyed as a single coverage-information extension that is marked as 'conditional' for authorization and/or coverage with info-needed set to at least include provider and/or location, with a 'reason' indicating the authorization rules. This might be the standard code of auth-out-network-only.

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. §resp-41 The coverage-information.coverage-assertion-id will service as a 'linking' id allowing the payer to associate any cached information they have retained relating to the processing of this Request.

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

CRD Profiles | US Core Profiles
--- | ---
profile-appointment-with-order |
profile-appointment-no-order |
profile-devicerequest |
profile-medicationrequest |
profile-nutritionorder |
profile-servicerequest |
profile-visionprescription |

!

For example, this response indicates that a prior authorization has been satisfied for a planned procedure:

    {
      "type" : "update",
      "resource" : {
        "resourceType" : "ServiceRequest",
        ...
        "extension" : [
          {
            "extension" : [
              {
                "url" : "coverage",
                "valueReference" : {
                  "reference" : "http://example.org/fhir/Coverage/example"
                }
              },
              {
                "url" : "covered",
                "valueCode" : "covered"
              },
              {
                "url" : "pa-needed",
                "valueCode" : "satisfied"
              },
              {
                "url" : "doc-needed",
                "valueCode" : "conditional"
              },
              {
                "url" : "info-needed",
                "valueCode" : "OTH"
              },
              {
                "url" : "billingCode",
                "valueCoding" : {
                  "system" : "http://www.ama-assn.org/go/cpt",
                  "code" : "77065"
                }
              },
              {
                "url" : "billingCode",
                "valueCoding" : {
                  "system" : "http://www.ama-assn.org/go/cpt",
                  "code" : "77066"
                }
              },
              {
                "url" : "billingCode",
                "valueCoding" : {
                  "system" : "http://www.ama-assn.org/go/cpt",
                  "code" : "77067"
                }
              },
              {
                "url" : "reason",
                "valueCodeableConcept" : {
                  "coding" : [
                    {
                      "system" : "http://hl7.org/fhir/us/davinci-crd/CodeSystem/temp",
                      "code" : "auth-out-network",
                      "display" : "Authorization needed out-of-network"
                    }
                  ],
                  "text" : "In-network required unless exigent circumstances"
                }
              },
              {
                "url" : "reason",
                "valueCodeableConcept" : {
                  "text" : "Diagnosis needed to determine documentation requirements"
                }
              },
              {
                "extension" : [
                  {
                    "url" : "category",
                    "valueCode" : "cat-limitation"
                  },
                  {
                    "url" : "code",
                    "valueCodeableConcept" : {
                      "coding" : [
                        {
                          "system" : "http://hl7.org/fhir/us/davinci-crd/CodeSystem/temp",
                          "code" : "out-network-copay"
                        }
                      ]
                    }
                  },
                  {
                    "url" : "value",
                    "valueQuantity" : {
                      "value" : 10,
                      "system" : "http://unitsofmeasure.org",
                      "code" : "%"
                    }
                  },
                  {
                    "url" : "qualification",
                    "valueString" : "Copay minimum is $15"
                  }
                ],
                "url" : "detail"
              },
              {
                "url" : "dependency",
                "valueReference" : {
                  "reference" : "http://example.org/fhir/ServiceRequest/example2"
                }
              },
              {
                "url" : "date",
                "valueDate" : "2019-02-15"
              },
              {
                "url" : "coverage-assertion-id",
                "valueString" : "12345ABC"
              },
              {
                "url" : "satisfied-pa-id",
                "valueString" : "Q8U119"
              },
              {
                "url" : "contact",
                "valueContactDetail" : {
                  "telecom" : [
                    {
                      "system" : "url",
                      "value" : "http://some-payer/xyz-sub-org/get-help-here.html"
                    }
                  ]
                }
              }
            ],
            "url" : "http://hl7.org/fhir/us/davinci-crd/StructureDefinition/ext-coverage-information"
          }
        ],
        ...
      }
    }

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. §resp-43 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. §resp-44 The key consideration is that the user is aware that information is available and they can easily access it. Client implementations will be responsible for ensuring that the only changes made to the CRD client record are to add the annotations contemplated here. CRD clients MAY be configured to not execute system actions under some circumstances, for example if the order has been cancelled or abandoned. §resp-45

The information added to the order here is often going to be relevant/important not only to the creator of the order, but also to its eventual performer. This guide does not define how information around coverage is conveyed from the ordering system to the performing system. However, the Post-acute Orders implementation guide does provide a mechanism for electronic sharing of orders and could be used to convey the additional notes or extensions envisioned here as well.

Payers with existing tools that process prior authorization requests may have dependencies on data elements that are not found in the clinical orders being submitted as part of CRD such as service type or modifier codes. Where CRD servers need for data that was not transmitted, they SHOULD attempt to infer values from elements that are present. §resp-46 For example, 'service type' can often be inferred based on the nature of the service, the location, the performer, etc. In situations where the inferred element has an impact on the results, payers should document that as part of their 'coverage-information' extension. In situations where inference is not possible and an element must be known; the payer may indicate that formal prior authorization is necessary. This situation should be minimized as much as possible.

A profile defining the expectations of an Coverage Information response can be found here.

### Propose Alternate Request Response Type

This response type can be used by payers to present a card with suggested alternatives to the current proposed therapy. This might be updating the order to change certain information or proposing replacing the order completely with one or more alternatives. This might be used to propose a change to a first-line treatment, to alter therapy frequency or drug dosage to be consistent with coverage guidelines, to propose covered products or services as substitutes for a non-covered service, or to propose therapeutically equivalent treatments that will have a lower cost to the patient.

Multiple alternatives can be proposed by providing multiple suggestions. 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. §resp-47 In some cases, additional "create" actions might be needed if there is a need to convey a non-contained Medication, Device, or other resource. The "delete" action resource element is not expected to adhere to any profile, as it is only expected to contain the "id" property of the resource being replaced. Any other elements will be ignored.

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. §resp-48 If cards returned by other service providers might still be relevant (e.g., because there was just a small change in dose or frequency), then performing an update will allow updates from other decision support cards to also be applied. If the change is significant enough that other decision support will not be relevant, a "delete + create" will allow the client to suppress decision support cards that no longer apply.

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

CRD Profiles | US Core Profiles
--- | ---
profile-device |
profile-devicerequest |
profile-encounter† |
| us-core-medication
profile-medicationrequest |
profile-nutritionorder |
profile-servicerequest |
profile-visionprescription |

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

!

For example, this card proposes replacing the draft prescription for a brand-name drug (shown only as the 'resourceType' and 'id' from the `draftOrders` entry) and instead creating an equivalent prescription with a lower-cost medication.

    {
      "label" : "Change to lower price name brand (selected name brand not covered)",
      "actions" : [
        {
          "type" : "delete",
          "description" : "Remove name-brand prescription",
          "resourceId" : "MedicationRequest/2222"
        },
        {
          "type" : "create",
          "description" : "Add lower-cost alternative",
          "resource" : {
            "resourceType" : "MedicationRequest",
            "id" : "1",
            ...
            "medicationCodeableConcept" : {
              "coding" : [
                {
                  "system" : "http://www.nlm.nih.gov/research/umls/rxnorm",
                  "code" : "1790533",
                  "display" : "Abuse-Deterrent 12 HR oxycodone 9 MG Extended Release Oral Capsule [Xtampza]"
                }
              ]
            },
            ...
          }
        }
      ]
    }

A profile defining the expectations of an Alternate Request response can be found here.

### Identify Additional Orders Response Type

This response type can be used to present a card that recommends the introduction of additional orders as companions or prerequisites for the current order. For example, the payer might recommend that certain lab tests be ordered along with a medication that is known to affect liver function. This will normally involve additional 'create' actions. The fact that there is no 'delete' for the original order conveys that these are supplemental actions rather than replacement actions. As with the Propose Alternate Request response type, in some cases multiple resources will need to be created to convey the full suggestion such as 'medication', 'device', etc.

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

CRD Profiles | US Core Profiles
--- | ---
profile-communicationrequest |
profile-device |
profile-devicerequest |
| us-core-medication
profile-medicationrequest |
profile-nutritionorder |
profile-servicerequest |
profile-visionprescription |

!

This example proposes adding a monthly test to check liver function:

    {
      "label" : "Add monthly AST test for 1st 3 months",
      "actions" : [
        {
          "type" : "create",
          "description" : "Add order for AST test",
          "resource" : {
            "resourceType" : "ServiceRequest",
            "id" : "1",
            "status" : "draft",
            "intent" : "original-order",
            "category" : [
              {
                "coding" : [
                  {
                    "system" : "http://snomed.info/sct",
                    "code" : "108252007",
                    "display" : "Laboratory procedure"
                  }
                ]
              }
            ],
            "code" : {
              "coding" : [
                {
                  "system" : "http://www.ama-assn.org/go/cpt",
                  "code" : "80076",
                  "display" : "Hepatic function panel"
                }
              ]
            },
            "subject" : {
              "reference" : "http://example.org/fhir/Patient/123",
              "display" : "Jane Smith"
            },
            "encounter" : {
              "reference" : "http://example.org/fhir/Encounter/ABC"
            },
            "occurrenceTiming" : {
              "repeat" : {
                "boundsDuration" : {
                  "value" : 3,
                  "unit" : "months",
                  "system" : "http://unitsofmeasure.org",
                  "code" : "mo"
                },
                "frequency" : 1,
                "period" : 1,
                "periodUnit" : "mo"
              }
            },
            "authoredOn" : "2019-02-15",
            "requester" : {
              "reference" : "http://example.org/fhir/PractitionerRole/987",
              "display" : "Dr. Jones"
            }
          }
        }
      ]
    }

A profile defining the expectations of an Additional Orders response can be found here.

### Request Form Completion Response Type

NOTE: DTR is the preferred solution where forms are needed for capturing information for payer purposes including, but not limited to, prior authorization, claims submission, or audit because of its ability to minimize data entry burden.

The Request Form Completion response type SHALL NOT be used if: §resp-51

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).

This response type can be used to present a card that indicates that there are forms that need to be completed. The indicated forms might indicate additional documentation that must be submitted for prior authorization, attachments for claims submission, documentation that must be completed and retained as proof that clinical need protocols have been followed, or that must otherwise be retained and available for future audits. While forms can also be expressed as static or active PDFs referenced by External References, or within a SMART Application, this response type provides the form definition as a FHIR Questionnaire and creates a Task within the CRD client allowing the completion of the form to be appropriately scheduled and/or delegated. Alternatively, the provider could choose to execute the task and fill out the form immediately if that makes more sense from a clinical workflow perspective.

This suggestion will always include a create action for the Task. The Task will point to the Questionnaire to be completed using a `Task.input` element with a `Task.input.type` of "questionnaire" and the canonical URL for the questionnaire in `Task.input.valueCanonical`. Additional `Task.input` elements will provide information about how the completed questionnaire response is to be submitted to the payer with a service endpoint if required. The `Task.code` will always include the CRD-specific `complete-questionnaire` code. The reason for completion will be conveyed in `Task.reasonCode`. The Questionnaire might also be included with a separate conditional create action or it might be excluded with the presumption it will already be available or retrievable by the client via its canonical URL, either from the original source or from a local registry.

Instead of using a card for "Request Form Completion", CRD servers MAY opt to use a systemAction. §resp-52 CRD clients supporting the Request Form Completion response type SHALL support both the card and systemAction approach. §resp-53

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

CRD Profiles | US Core Profiles
--- | ---
profile-taskquestionnaire |

!

No profile is provided for the questionnaires pointed to by the Task. 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). §resp-55

Note:

- Where CRD servers use the SDC profiles, they have the option of indicating an endpoint for submission of the questionnaire using Task.input or the SDC Questionnaire.endpoint extension to specify a service endpoint to submit completed questionnaires. If an endpoint is specified in both locations, both apply.
- CRD clients SHOULD retain a copy of all completed forms for future reference. §resp-56

The following is an example CDS Hooks Suggestion, where the specified questionnaire is either expected to be available within the CRD client or available for retrieval through its canonical URL. As such, the Action only contains the FHIR Task resource. An example showing inclusion of both the Task and the referenced Questionnaire can be found above.

    {
      "label" : "Add 'completion of the ABC form' to your task list (possibly for reassignment)",
      "actions" : [
        {
          "extension" : {
            "davinci-crd.if-none-exist" : [
              "url=http://example.org/Questionnaire/XYZ&version=2"
            ]
          },
          "type" : "create",
          "description" : "Add version 2 of the XYZ form to the clinical system's repository (if it doesn't already exist)",
          "resource" : {
            "resourceType" : "Questionnaire",
            ...
            "url" : "http://example.org/Questionnaire/XYZ",
            ...
          }
        },
        {
          "type" : "create",
          "description" : "Add 'Complete ABC form' to the task list",
          "resource" : {
            "resourceType" : "Task",
            "id" : "1",
            "basedOn" : [
              {
                "reference" : "http://example.org/fhir/Appointment/27"
              }
            ],
            "status" : "ready",
            "intent" : "order",
            "code" : {
              "coding" : [
                {
                  "system" : "http://hl7.org/fhir/uv/sdc/CodeSystem/temp",
                  "code" : "complete-questionnaire"
                }
              ]
            },
            "description" : "Complete XYZ form for local retention",
            "for" : {
              "reference" : "http://example.org/fhir/Patient/123"
            },
            "authoredOn" : "2018-08-09",
            "requester" : {
              "reference" : "http://example.org/fhir/Practitioner/987"
            },
            "input" : [
              {
                "type" : {
                  "text" : "questionnaire"
                },
                "valueCanonical" : "http://example.org/Questionnaire/XYZ|2"
              },
              {
                "type" : {
                  "text" : "afterCompletion"
                },
                "valueCodeableConcept" : {
                  "coding" : [
                    {
                      "system" : "http://example.org/fhir/CodeSystem/SomeCodes",
                      "code" : "987",
                      "display" : "Local Use"
                    }
                  ]
                }
              }
            ]
          }
        }
      ]
    }

A profile defining the expectations of an Form Completion response can be found here.

### Update Coverage Records Response Type

This response type is used when the CRD server has updates or corrections to make to the primary insurance coverage record held by the CRD client eing used for the CRD call. For example, the CRD client might be aware that a patient has coverage with a provider, but have incorrect details such as expiry date, coverage types, etc. This response allows the CRD server to convey that information to the CRD client and link it to the current/proposed action. In theory, this type of response could also be used to convey corrected/additional prior authorization information the payer was aware of, however that functionality is out of scope for this release of the implementation guide.

Instead of using a card for "Update Coverage Records", CRD servers MAY opt to use a systemAction instead. §resp-57 CRD clients supporting the Update Coverage Records response type SHALL support both the card and system action approach. §resp-58 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. §resp-59

NOTE: This functionality is somewhat redundant with the capabilities of the X12 270/271 transactions. This Update Coverage Records capability SHALL NOT be used in situations where regulation dictates the use of the X12 functionality. §resp-60

This response will contain a single suggestion. The primary action will be a suggestion to update an existing coverage instance.

For example, this CDS Hooks card includes a single suggestion with an action to update the Coverage.

    {
      "label" : "Update coverage information to be current",
      "uuid" : "urn:uuid:1207df9d-9ff6-4042-985b-b8dec21038c2",
      "actions" : [
        {
          "type" : "update",
          "description" : "Update current coverage record",
          "resource" : {
            "resourceType" : "Coverage",
            "id" : "1234",
            "status" : "active",
            "subscriberId" : "192837",
            "beneficiary" : {
              "reference" : "http://example.org/fhir/Patient/123"
            },
            "relationship" : {
              "coding" : [
                {
                  "system" : "http://terminology.hl7.org/CodeSystem/subscriber-relationship",
                  "code" : "self"
                }
              ]
            },
            "period" : {
              "start" : "2023-01-01",
              "end" : "2023-11-30"
            },
            "payor" : [
              {
                "reference" : "http://example.org/fhir/Organization/ABC"
              }
            ],
            "class" : [
              {
                "type" : {
                  "coding" : [
                    {
                      "system" : "http://terminology.hl7.org/CodeSystem/coverage-class",
                      "code" : "group"
                    }
                  ]
                },
                "value" : "A1"
              }
            ]
          }
        }
      ]
    }

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. §resp-61

A profile defining the expectations of an Adjust Coverage response can be found here.

### Launch SMART Application Response Type

SMART apps allow more sophisticated interaction between payers and providers. They provide full control over user interface, workflow, etc. With permission, they can also access patient clinical data to help guide the interactive experience and minimize data entry. Apps can provide a wide variety of functions, including eligibility checking, guiding users through form entry, providing education, etc.

All such apps will need to go through the approval processes for the client's provider organization and typically also the associated software vendor. This response type can cause the launching of such apps to occur in the context in which they are relevant to patient care and/or to payment-related decision making.

This response type is just a modified version of the External Reference response type. However, the `Link.type` will be "smart" instead of "absolute". The `Link.appContext` will typically also be present.

NOTE: This mechanism is no longer to be used for launching DTR applications. That process is now handled entirely through the Coverage Information response type above. It can still be used for launching other types of SMART apps not focused on gathering data for payer use with questionnaires.

For example, this card contains a SMART app link to perform an opioid assessment:

    {
      "extension" : {
        "davinci-crd.associated-resource" : [
          {
            "reference" : "MedicationRequest/2222"
          }
        ]
      },
      "uuid" : "urn:uuid:353cd963-2ecd-46f9-958b-ed7d2bbf6e01",
      "summary" : "Launch opioid XYZ-assessment",
      "indicator" : "info",
      "source" : {
        "label" : "Some Payer",
        "url" : "https://example.org",
        "icon" : "https://example.org/img/icon-100px.png",
        "topic" : {
          "system" : "http://terminology.hl7.org/CodeSystem/cdshooks-card-type",
          "code" : "guideline",
          "display" : "Guideline"
        }
      },
      "links" : [
        {
          "label" : "Opioid XYZ-assessment",
          "url" : "https://example.org/opioid-assessment",
          "type" : "smart",
          "appContext" : "{\"payerXYZQNum\":\"205f471f-f408-45d4-9213-0eedf95f417f\"}"
        }
      ]
    }

A profile defining the expectations of an Launch SMART response can be found here.