HL7.FHIR.US.DAVINCI-CRD\Formal Specification

us-core-practitionerrole^‡

profile-patient

profile-practitioner

^† DeviceRequest is not currently supported by the order-select and order-sign hooks. A proposal has been submitted to add them. CRD Services SHALL NOT treat the presence of these resources in the draftOrders Bundle as an error and SHOULD support these resource types if relevant to their operations.

^‡ While this hook does not explicitly list PractitionerRole as an expected resource type for userId, it is not prohibited and is included to allow linking the user to a Practitioner in a specific role acting on behalf of a specific Organization.

Note: While this hook is defined for use when ordering, it is still relevant when proposing (e.g. as part of a consult note) or planning (e.g. as part of a care plan) the use of an intervention. All the ‘Request’ resources support differentiating between plans, proposals, and orders. Where CRD Clients have an appropriate workflow and data capture mechanism, this hook MAY be used in scenarios that don’t involve creating a true order.

order-sign

This hook is described in the CDS Hook specification here. This version of the CRD implementation guide refers to version 1.0 of the hook.

This hook serves a very similar purpose to order-select. The main difference is that all the listed draft orders are considered ‘complete’. That means that it’s appropriate to provide warnings if there is insufficient information to determine coverage requirements. As well, all draftOrders are appropriate to comment on when using order-sign as the selections field in order-select is absent.

Use and profiles for order-select also apply to order-sign.

Cards

Cards are the mechanism used to return coverage requirements from the CRD Service to the CRD Client.

General guidance

In addition to the guidance provided in the CDS Hooks specification, the following additional recommendations apply to CRD Services when constructing cards:

The Card.indicator SHOULD be populated from the perspective of the clinical decision maker, not the payer. 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’.
The Card.source SHOULD be populated with an insurer name that the user and patient would 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 service on behalf of the payer. If an insurer is providing 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 Card Types. The rationale is to allow EHRs to potentially filter or track the usage of different types of cards.
Users are busy. Time spent reading a payer-returned card is inevitably time not spent 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. “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 can’t 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 the precious seconds to launch an app or external link or not - ideally providing a sense of where to look for and how to use whatever link or app they do launch in the specific context of the order they’re making at the time.
- 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, using the smallest number of cards that still support descriptive actionable summaries is best.
- When providing links, don’t send the user to the first page of an 80+ page PDF. Keep document size short and/or provide linking 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. 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 isn’t possible.

The card.source.topic element above is new.

Potential CRD Response Types

This section describes the different types of responses that CRD Services 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 Services and CRD Clients will support additional card response patterns than those listed here, but such behavior is outside the scope of this specification. Future versions of this specification might standardize additional response types.

Of the response types in this guide, conformant CRD Clients SHALL support the External reference, Instructions and Annotate responses and SHOULD support the remaining types. CRD Services SHALL support at least one of these response type and MAY support as many as necessary to convey the requirements of the types of coverage they support.

Response types are listed from least sophisticated to most sophisticated - and potentially more useful/powerful. As a rule, the more a card 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 CDS Hook request context object. 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 will frequently contain multiple cards and those cards might draw from a variety of response types. 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

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

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

{
  "summary": "CMS Home Oxygen Therapy Coverage Requirements",
  "indicator": "info",
  "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.",
  "source": {
    "label": "Centers for Medicare & Medicaid Services",
    "url": "https://cms.gov",
    "topic": "coverage"
  },
  "links": [
    {
      "label": "Home Oxygen Therapy Guidelines",
      "url": "https://www.cms.gov/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://www.cms.gov/Outreach-and-Education/Medicare-Learning-Network-MLN/MLNProducts/Downloads/Home-Oxygen-Therapy-Text-Only.pdf",
      "type": "absolute"
    }
  ]
}

Instructions

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, rules around prior authorization, or even something as simple as “No special coverage requirements”. It can be generated in a more sophisticated context for the payer, while remaining simple to consume for the provider because it more easily 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.

This example CDS Hook Card just contains a message:

{
  "summary": "Prior authorization required",
  "indicator": "warning",
  "detail": "All prescriptions for _Drug X_ with a dose higher than 100mg/day require prior authorization.  Forms and instructions can be found [here](http://example.org/prior-auth.pdf).",
  "source": {
    "label": "You're Covered Insurance",
    "url": "https://example.com",
    "icon": "https://example.com/img/icon-100px.png",
    "topic": "prior-auth"
  }
}

Annotate

This response type presents a Card with a piece of information that should be retained with the order/appointment/etc. For example, “No prior authorization for drug X required by ABC insurance”, “Prior authorization number for X-ray from ABC insurance is 13245”, or “This referral is not covered under the patient’s DEF plan”. With information like this, merely displaying the text on the screen in a card is not sufficient - it needs to be recorded in the associated order for future use or evidence. These cards involve ‘replacing’ the submitted order, but leaving the order unchanged, with the exception that an additional ‘note’ is added to the resource instance.

The note uses the Annotation datatype and captures the comment, the date, and who made the assertion. In this case, the commenter would be the payer organization. The payers should include all the discrete information in the ‘annotation’ and the ‘detail’ for the card should indicate that the statement is point-in-time. Note that the text should also be displayed in the card, with the button link simply saying “Add to record” or something like that. The requested action is always an ‘update’ and there is only ever one alternative. It is to be noted that this will be handled as a single ‘update’ action and EHRs that don’t support the extension will ignore it and just store the annotation.

In addition to the annotation, 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.

CRD Services that make assertions with respect to coverage and prior authorization SHALL provide an annotation card that includes both the human-readable and computable version. Clients SHALL store at least one of the two forms.

When using this response type, the proposed order or appointment being updated SHALL comply with the following profiles:

CRD Profiles	US Core Profiles
profile-appointment
profile-devicerequest
profile-medicationrequest
profile-nutritionorder
profile-servicerequest

CRD Profiles

US Core Profiles

profile-appointment

profile-devicerequest

For example, this card proposes indicates that a prior authorization has been granted for a planned prescription:

"suggestions": [{
  "label": "Prior authorization granted by XYZ insurer.  Auth #:12345 - add to record?",
  "actions": [{
    "type": "update",
    "description": "Add authorization to record",
    "resource": {
      "resourceType": "ServiceRequest",
      "id": "idfromcontext",
      "extension": [
        {
          "url": "http://hl7.org/fhir/us/davinci-crd/StructureDefinition/ext-coverage-information"
          "extension": [
            {
              "url": "coverageInfo",
              "valueCoding": {
                "system": "http://hl7.org/fhir/us/davinci-crd/CodeSystem/coverageGuidance",
                "code": "prior-auth",
                "display": "Prior Authorization"
              }
            },
            {
              "url": "coverage",
              "valueReference": {
                "reference": "Coverage/example"
              }
            },
            {
             "url": "date",
             "valueDate": "2019-02-15"
            },
            {
             "url": "identifier",
             "valueString": "12345ABC"
            }
          ]
        } 
      ],
      "status": "draft",
      "intent": "original-order",
      "code": {
        "coding": [{
          "system": "http://snomed.info/sct",
          "code": "726551006",
          "display": "Contrast enhanced spectral mammography (Procedure)"
        }]
      },
      "subject": {
        "reference": "Patient/123",
        "display": "Jane Smith"
      },
      "encounter": {
        "reference": "Encounter/ABC"
      },
      "authoredOn": "2019-02-15",
      "requester": {
        "reference": "PractitionerRole/987",
        "display": "Dr. Jones"
      },
      "note": [
        {
          "authorString": "XYZ Insurance",
          "time": "2019-02-15T15:07:18-05:00",
          "text": "Prior authorization required for Contrast enhanced spectral mammography under coverage ABC.  (Determination 1234ABC made Feb 15, 2019)"
        }
      ]
    }
  }]
}]

CRD clients and services MAY, by mutual agreement, make use of the new CDS Hooks system action functionality to cause annotations to automatically be stored on the relevant request, appointment, etc. without any user intervention. I.e. the user would not need to click on the card to store the information. In this case, a card SHALL still be displayed to the user conveying the coverage assertion. These implementations will be responsible for ensuring that the only changes made to the EHR record are to add the annotations contemplated here. It is likely that the conformance expectation on the use of system actions will be tighter in future releases.

Balloters are requested to provide their feedback on whether the conformance expectation here should be stronger.

Propose alternate request

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 to replace 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 and/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 both a “delete” action for the current proposed order and a “create” action for the new proposed order. In some cases, additional “create” actions might be needed if there’s 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 other decision support on the original request will still be. 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 this response type, the proposed orders (and any associated resources) SHALL comply with the following profiles:

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

CRD Profiles

US Core Profiles

profile-device

profile-devicerequest

profile-encounter^†

us-core-medication

profile-communicationrequest

^† 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 generic medication.

"suggestions": [{
  "label": "Change to generic (name brand not covered)",
  "actions": [{
    "type": "delete",
    "description": "Remove name-brand prescription",
    "resource": {
      "resourceType": "MedicationRequest",
      "id": "draftrx1"
    }
  }, {
    "type": "create",
    "description": "Add equivalent generic prescription",
    "resource": {
      "resourceType": "MedicationRequest",
      "status": "draft",
      "intent": "original-order",
      "medicationCodeableConcept": {
        "coding": [{
          "system": "http://www.nlm.nih.gov/research/umls/rxnorm",
          "code": "616447",
          "display": "Cellcept 250 MG Oral Capsule"
        }]
      },
      "subject": {
        "reference": "Patient/123",
        "display": "Jane Smith"
      },
      "encounter": {
        "reference": "Encounter/ABC"
      },
      "authoredOn": "2019-02-15",
      "requester": {
        "reference": "PractitionerRole/987",
        "display": "Dr. Jones"
      },
      "dosageInstruction": [{
        "text": "6 tablets every 12 hours.",
        "timing": {
          "repeat": {
            "frequency": 1,
            "period": 12,
            "periodUnit": "h"
          }
        },
        "doseAndRate": [{
          "doseQuantity": {
            "value": 6,
            "unit": "tablet"
          }
        }]
      }]
    }
  }]
}]

Identify additional orders as companions/pre-requisites for current order

This response type can be used to present a Card that recommends the introduction of additional orders. For example, the payer may 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 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 (e.g. Medication, Device, etc.)

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

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

CRD Profiles

US Core Profiles

profile-device

profile-devicerequest

us-core-medication