Da Vinci - Coverage Requirements Discovery
2.2.1 - STU 2.2

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

## Artifact List

Page standards status: Informative | Highlight text changes?

This page provides a list of the FHIR artifacts defined as part of this implementation guide.

### Global Profiles

There are no Global profiles defined

### Terminology Parameters

Parameter | Value
--- | ---
system-version | SNOMED CT[US]

### Requirements: Actor Definitions

The following artifacts define the types of individuals and/or systems that will interact as part of the use cases covered by this implementation guide.

CRD Client | A system (or collection of systems) responsible for invoking CRD calls and responding to queries from a CRD Server.
CRD Client Organization | The legal entity responsible for configuring, running, and making the decisions around the use of a CRD Client system
CRD Server | A system (or collection of systems) responsible for responding to CRD calls.
CRD Server Organization | The legal entity responsible for configuring, running, and making the decisions around the use of a CRD Server system

### Requirements: Formal Requirements

The following artifacts describe the specific requirements to be met by systems compliant with the implementation guide.

Narrative Conformance Statements | Conformance statements found throughout the narrative of the IG consolidated into this computable resource for traceability purposes

### Behavior: Capability Statements

The following artifacts define the specific capabilities that different types of systems are expected to have in order to comply with this implementation guide. Systems conforming to this implementation guide are expected to declare conformance to one or more of the following capability statements.

CRD Client USCDI 1 | This statement defines the expected capabilities of systems wishing to conform to the ''CRD Client'' role for USCDI 1 (US Core 3.1.1). This role is responsible for initiating CDS Hooks calls and consuming received decision support. It is also responsible for returning the data requested by the CRD Server needed to provide that decision support. This capability statement does define the CDS Hooks capabilities as there is no standard way to do that yet. Instead, it focuses on the 'server' capabilities needed to respond to CRD Server queries. These capabilities are based on US Core.
CRD Client USCDI 3 | This statement defines the expected capabilities of systems wishing to conform to the ''CRD Client'' role for USCDI 3 (US-Core 6.1.0). This role is responsible for initiating CDS Hooks calls and consuming received decision support. It is also responsible for returning the data requested by the CRD Server needed to provide that decision support. This capability statement does not define the CDS Hooks capabilities as there is no standard way to do that yet. Instead, it focuses on the 'server' capabilities needed to respond to CRD Server queries. These capabilities are based on US Core.
CRD Client USCDI 4 | This statement defines the expected capabilities of systems wishing to conform to the ''CRD Client'' role for USCDI 4 (US-Core 7.9.0). This role is responsible for initiating CDS Hooks calls and consuming received decision support. It is also responsible for returning the data requested by the CRD Server needed to provide that decision support. This capability statement does not define the CDS Hooks capabilities as there is no standard way to do that yet. Instead, it focuses on the 'server' capabilities needed to respond to CRD Server queries. These capabilities are based on US Core.
CRD Server USCDI 1, 3, 4 | This statement defines the expected capabilities of systems wishing to conform to the ''CRD Server'' role. This role is responsible for responding to CDS Hooks calls and responding with appropriate decision support. Much of its interactions will be with payer back-end systems over non-FHIR protocols. This CapabilityStatement does not describe these 'server <-> payer' interactions. Instead, it focuses on the ability of the CRD server to interact with the CRD client's FHIR endpoint to retrieve additional data. All such interactions are optional, as their necessity is dependent on what types of information is needed to support payer rules, the types of coverage the payer offers, and the degree of sophistication of the decision support offered by the CRD server. All resources and search parameters supported by US Core are fair game, though the 3.1.1, 6.1.0, and 7.0.0 clients might vary in which resources, search parameters, and search parameter combinations they support. CRD servers will need to access the CapabilityStatement of the server they are communicating with to determine what search and read capabilities are available.

### Structures: Logical Models

These define data models that represent the domain covered by this implementation guide in more business-friendly terms than the underlying FHIR resources.

CRD CDS Hooks Specific Context for appointment-book (Logical Definition) | CRD-specific constraints on the appointment-book CDS Hook context
CRD CDS Hooks Specific Context for order-dispatch (Logical Definition) | CRD-specific constraints on the order-dispatch CDS Hook context
CRD CDS Hooks Specific Context for order-select (Logical Definition) | CRD-specific constraints on the order-select CDS Hook context
CRD CDS Hooks Specific Context for order-sign (Logical Definition) | CRD-specific constraints on the order-sign CDS Hook context
CRD CDSHooks Additional Orders Response (Logical Definition) | Defines CRD-specific constraints for the Additional Orders response type
CRD CDSHooks Adjust Coverage Response (Logical Definition) | Defines CRD-specific constraints for the Adjust Coverage response type
CRD CDSHooks Alternate Request Response (Logical Definition) | Defines CRD-specific constraints for the Alternate Request response type
CRD CDSHooks Base for Response (Logical Definition) | Defines common rules for all CRD-specific constraints on the CDS Hooks Response body
CRD CDSHooks Coverage Information Response (Logical Definition) | Defines CRD-specific constraints for the Coverage Information response type
CRD CDSHooks External Reference Response (Logical Definition) | Defines CRD-specific constraints for the External Reference response type
CRD CDSHooks Form Completion Response (Logical Definition) | Defines CRD-specific constraints for the Form Completion response type
CRD CDSHooks Instructions Response (Logical Definition) | Defines CRD-specific constraints for the Instructions response type
CRD CDSHooks Request (Logical Definition) | Defines CRD-specific constraints on the CDS Hooks Request logical model
CRD CDSHooks Response (Logical Definition) | Defines CRD-specific constraints on the CDS Hooks Response body
CRD CDSHooks SMART App Response (Logical Definition) | Defines CRD-specific constraints for the SMART App Launch response type
CRD Metric Data | A logical model describing the information that should be captured by CRD implementers about every CRD invocation to support measures evaluating CRD implementation

### Structures: Abstract Profiles

These are profiles on resources or data types that describe patterns used by other profiles but cannot be instantiated directly. I.e. instances can conform to profiles based on these abstract profiles, but do not declare conformance to the abstract profiles themselves.

CRD Base Appointment | This profile specifies extensions and constraints on the Appointment resource to support coverage requirements discovery.
CRD Base Bundle | This profile defines the common requirements for all CRD Bundles used as input to CDS Hooks calls.

### Structures: Resource Profiles

These define constraints on FHIR resources for systems conforming to this implementation guide.

CRD Appointment with Order | An appointment where the details of what the appointment is being booked for are provided in the associated ServiceRequest
CRD Appointment without Order | An appointment where the details of what the appointment is being booked for are provided inline and there is no associated ServiceRequest
CRD Bundle of Appointments | This profile defines the Bundle used for the appointment-book hook, expressing mustSupport for the CRD Appointment profile.
CRD Bundle of Request Resources | This profile defines the Bundle used to convey the relevant orders for the order-select, order-sign, and order-dispatch hooks.
CRD Communication Request | This profile specifies constraints on the CommunicationRequest resource to support coverage requirements discovery.
CRD Coverage | This profile specifies constraints on the Coverage resource to support coverage requirements discovery.
CRD Device | This profile specifies additional constraints on the US Core Device Profile to support coverage requirements discovery.
CRD Device Request | This profile specifies extensions and constraints on the DeviceRequest resource to support coverage requirements discovery.
CRD Dispatch Task | This profile specifies constraints on the Task resource to capture details of dispatching a request to a particular performer.
CRD Encounter | This profile specifies additional extensions and constraints on the US Core Encounter profile to support coverage requirements discovery.
CRD Location | This profile specifies constraints on the US Core Location profile to support coverage requirements discovery.
CRD Medication | This profile specifies additional constraints on the US Core Medication Profile to support coverage requirements discovery.
CRD Medication Request | This profile specifies additional constraints on the US Core MedicationRequest profile to support coverage requirements discovery.
CRD Nutrition Order | This profile specifies extensions and constraints on the NutritionOrder resource to support coverage requirements discovery.
CRD Organization | This profile specifies additional constraints on the US Core Organization profile to support coverage requirements discovery.
CRD Patient | This profile specifies additional constraints on the US Core Patient profile to support coverage requirements discovery.
CRD Practitioner | This profile specifies additional constraints on the US Core Practitioner profile to support coverage requirements discovery.
CRD Questionnaire Task | This profile specifies constraints on the Task resource to support requests for form (Questionnaire) completion.
CRD Service Request | This profile specifies constraints on the ServiceRequest resource to support coverage requirements discovery.
CRD Vision Prescription | This profile defines an initial profile on the VisionPrescription resource to support coverage requirements discovery.

### Structures: Data Type Profiles

These define constraints on FHIR data types for systems conforming to this implementation guide.

CRD Timing Data Type | This profile specifies CRD-specific expectations on the use of the Timing data type

### Structures: Extension Definitions

These define constraints on FHIR data types for systems conforming to this implementation guide.

Billing Options | Identifies billing codes that could potentially be used for this clinical code
Coverage Information | Captures assertions from a payer about the coverage rules for a service - in particular, whether it is covered and/or requires prior authorization.
Request Category | A high-level categorization of the type of request

### Structures: CDS Hooks Extensions

Models that define extensions on CDS Hooks JSON structures

CDS Hooks Service Request Configuration Extension | Allows passing configuration parameters when invoking a card
CDS Hooks Service Request Requested CRD Version Extension | Allows indicating the desired CRD version when invoking CRD on a service that supports multiple versions
CDS Hooks Service Response Associated Resource Extension | Indicates a request resource that is one of those that drove the creation of the card
CDS Hooks Service Response If-None-Exist Extension | Indicates a value to assert as an if-none-exist header on a create or update action
CDS Hooks Services Configuration Extension | An extension for the CDS Hooks 'services' object that indicates configuration options supported by the CDS server
CDS Hooks Services Discovery CRD Version Extension | Indicates the version(s) of CRD supported by the service for a given type of hook

### Terminology: Value Sets

These define sets of codes used by systems conforming to this implementation guide.

CDS Hook Types Value Set | Codes identifying a type of CDS Hook
CDS Hooks Card Suggestion Action Types Value Set | Codes allowed for defining the type of action in a CDS Hooks suggestion
CMS Location Codes Value Set | Numeric codes defined by CMS to identify types of locations
CRD Billing Codes Value Set | Codes appropriate for inclusion in a claim or prior authorization
CRD Configuration Code Data Types Value Set | Allowed data types for configuration settings in the CDS Hooks configuration extension
CRD Conformance Statement Categories | Categories for conformance statements found in the CRD IG
CRD Coverage Assertion Reasons Value Set | Reasons for a coverage assertion in the coverage-information extension
CRD Coverage Classes Value Set | Restriction of coverage classes for CRD purposes
CRD Coverage Detail Categories Value Set | Codes that define the type of coverage information detail being provided
CRD Coverage Information Additional Documentation Value Set | Codes defining whether additional documentation needs to be captured
CRD Coverage Information Covered Value Set | Codes defining whether the ordered/requested service is covered under patient's plan
CRD Coverage Information Documentation Reason Value Set | List of reasons for additional documentation
CRD Coverage Information Prior Authorization Value Set | Codes defining whether prior auth will be needed for coverage to be provided
CRD Device Request Codes Value Set | Codes for ordering devices. NOTE: This value set contains many inappropriate codes because the underlying code systems do not provide a straight-forward mechanism to select only device-related codes and, given the evolving nature of the underlying code systems, strict enumeration is not a viable approach to defining the value set.
CRD Information Needed Value Set | Codes defining whether information about the performer, location, and/or performance date is needed to determine coverage information
CRD Location Address Types Value Set | Address codes allowed for CRD locations - those that are physical addresses
CRD Metric Data Source Value Set | A list of codes indicating the perspective from which metric data was captured
CRD Metric Token Use Value Set | A list of codes indicating whether an access token was used as part of CDS Hooks processing
CRD Order Detail Codes Value Set | Detail codes for products and services that are the focus of a CRD call
CRD Response Types Value Set | List of CDS Hook response types defined by the CRD spec
CRD Service Request Codes Value Set | Example value set defines a set of CPT, SNOMED CT, HCPCS Level II and LOINC codes mirroring bindings found in the US Core Procedure and Observation Lab profiles
Deprecated CRD Coverage Detail Codes Value Set | Codes for name-value-pair details on a coverage assertion - replaced by the coverageDetailNew value set. Support for this ValueSet will be dropped in a future version.
Diet Codes | Codes that can be used to indicate the type of food being ordered for a patient. It includes codes from SNOMED CT where concept is Dietary Regime (182922004) and its sub-concepts, Enteral Feeding (229912004) and its sub-concepts, Mixed Breast Milk and Bottle Feeding (35011000087100), Breast Milk Feeding (1297276008), Bottle Feeding of Patient (40043006).
ICD10CM Disease codes | All ICD10 CM Disease codes
NUBC Type of Bill | All NUBC type of bill codes
NUCC Healthcare Provider Taxonomy Individual or Groups | All NUCC Healthcare Provider Taxonomy codes that fall within the Individual or Groups (of Individuals) heading
NUCC Healthcare Provider Taxonomy Non-Individual | All NUCC Healthcare Provider Taxonomy codes that fall within the Non-Individual heading
Nutrient Codes | Copied from FHIR Core R6 draft. NutrientModifier : Codes for types of nutrients that are being modified such as carbohydrate or sodium. This value set includes codes from SNOMED CT where concept is-a 226355009 (Nutrients(substance)), and the concepts for Sodium, Potassium and Fluid. This is provided as a suggestive example.
Official CRD Coverage Detail Codes Value Set | Codes for name-value-pair details on a coverage assertion - now using official FHIR codes
Types of Edible Substances | Copied from FHIR Core R6 draft. This value set represents codes for types of edible substances. It include codes from SNOMED CT where concept 762766007 Edible Substance (substance) and its sub-concepts, Infant Formula (412413001) and its sub-concepts, Enteral and Supplement Feeds (346415002) and its sub-concepts, Water (11713004), Potable Water (890302005) and its sub-concepts, and Tap Water (444923006).
X12 Service Type | This set of codes provides a high-level classification for what service is being requested.

### Terminology: Code Systems

These define new code systems used by systems conforming to this implementation guide.

CRD Metric Codes | Codes used within 'code' elements in the CRD Metric logical model.
CRD Temporary Codes | Codes temporarily defined as part of the CRD implementation guide. These will eventually migrate into an officially maintained terminology (likely either SNOMED CT or HL7's UTG code systems).
Coverage Information Codes | Codes used by 'code' elements within the Coverage-Information extension.

### Example: Example Instances

These are example instances that show what data produced and consumed by systems conforming with this implementation guide might look like.

Appointment ServiceRequest example | Example appointment tied to a ServiceRequest based on CRD profile
Appointment example | Example stand-alone appointment populated based on CRD profile
CommunicationRequest example | Example communication request populated based on CRD profile
Coverage example | Example identified coverage populated based on CRD profile
Device example | Example device populated based on CRD profile
DeviceRequest example | Example DeviceRequest populated based on CRD profile
Dispatch Task example | Example dispatch Task populated based on CRD profile
Encounter example | Example encounter populated based on CRD profile
Location example | Example location populated based on CRD profile
MedicationRequest annotated example | Example medication request with an annotation showing coverage expectations
MedicationRequest example | Example medication request populated based on CRD profile
NutritionOrder example | Example nutrition order populated based on CRD profile
Organization example | Example organization populated based on CRD profile
Patient example | Example patient populated based on CRD profile
Practitioner full example | An example showing a fully populated US Core Practitioner instance (used in CRD examples)
Questionnaire Task example | Example questionnaire-completion Task populated based on CRD profile
ServiceRequest example | Example service request populated based on CRD profile
VisionPrescription example | Example vision prescription based on CRD profile

### Example: CDS Hooks Examples

Examples of CDS Hooks JSON instances

Example CRD Discovery Response | An example of a CRD discovery response
Example CRD Request with CommunicationRequest | An example of a CRD request for order-sign with CommunicationRequest
Example CRD Request with MedicationRequests | An example of a CRD request for order-dispatch with MedicationRequests
Example CRD Request with ServiceRequests | An example of a CRD request for order-sign with ServiceRequests
Example CRD Request with appointment-book | An example of a CRD request for appointment-book
Example CRD Response with simple Coverage Information | An example CRD response to a CommunicationRequest with a simple Coverage Information system action
Example CRD Response with: Links, Information, Coverage Information, and Order Replacement example | An example of a CRD response of all 'mustSupport' response types, plus 'change order' response type
Example CRD Response with: Order Replacement, Order supplement, Form Completion, Coverage Update, SMART launch | An example CRD response with various optional response types