A system (or collection of systems) responsible for invoking CRD calls and responding to queries from a CRD Server.

The legal entity responsible for configuring, running, and making the decisions around the use of a CRD Client system

A system (or collection of systems) responsible for responding to CRD calls.

The legal entity responsible for configuring, running, and making the decisions around the use of a CRD Server system

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

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.

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.

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.

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.

CRD-specific constraints on the appointment-book CDS Hook context

CRD-specific constraints on the order-dispatch CDS Hook context

CRD-specific constraints on the order-select CDS Hook context

CRD-specific constraints on the order-sign CDS Hook context

Defines CRD-specific constraints for the Additional Orders response type

Defines CRD-specific constraints for the Adjust Coverage response type

Defines CRD-specific constraints for the Alternate Request response type

Defines common rules for all CRD-specific constraints on the CDS Hooks Response body

Defines CRD-specific constraints for the Coverage Information response type

Defines CRD-specific constraints for the External Reference response type

Defines CRD-specific constraints for the Form Completion response type

Defines CRD-specific constraints for the Instructions response type

Defines CRD-specific constraints on the CDS Hooks Request logical model

Defines CRD-specific constraints on the CDS Hooks Response body

Defines CRD-specific constraints for the SMART App Launch response type

A logical model describing the information that should be captured by CRD implementers about every CRD invocation to support measures evaluating CRD implementation

This profile specifies extensions and constraints on the Appointment resource to support coverage requirements discovery.

This profile defines the common requirements for all CRD Bundles used as input to CDS Hooks calls.

An appointment where the details of what the appointment is being booked for are provided in the associated ServiceRequest

An appointment where the details of what the appointment is being booked for are provided inline and there is no associated ServiceRequest

This profile defines the Bundle used for the appointment-book hook, expressing mustSupport for the CRD Appointment profile.

This profile defines the Bundle used for the order-dispatch hook to convey the Tasks with the dispatching information.

This profile defines the Bundle used to convey the relevant orders for the order-select, order-sign, and order-dispatch hooks.

This profile specifies constraints on the CommunicationRequest resource to support coverage requirements discovery.

This profile specifies constraints on the Coverage resource to support coverage requirements discovery.

This profile specifies additional constraints on the US Core Device Profile to support coverage requirements discovery.

This profile specifies extensions and constraints on the DeviceRequest resource to support coverage requirements discovery.

This profile specifies constraints on the Task resource to capture details of dispatching a request to a particular performer.

This profile specifies additional extensions and constraints on the US Core Encounter profile to support coverage requirements discovery.

This profile specifies constraints on the US Core Location profile to support coverage requirements discovery.

This profile specifies additional constraints on the US Core Medication Profile to support coverage requirements discovery.

This profile specifies additional constraints on the US Core MedicationRequest profile to support coverage requirements discovery.

This profile specifies extensions and constraints on the NutritionOrder resource to support coverage requirements discovery.

This profile specifies additional constraints on the US Core Organization profile to support coverage requirements discovery.

This profile specifies additional constraints on the US Core Patient profile to support coverage requirements discovery.

This profile specifies additional constraints on the US Core Practitioner profile to support coverage requirements discovery.

This profile specifies constraints on the Task resource to support requests for form (Questionnaire) completion.

This profile specifies constraints on the ServiceRequest resource to support coverage requirements discovery.

This profile defines an initial profile on the VisionPrescription resource to support coverage requirements discovery.

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

Identifies billing codes that could potentially be used for this clinical code

Captures assertions from a payer about the coverage rules for a service - in particular, whether it is covered and/or requires prior authorization.

A high-level categorization of the type of request

Allows passing configuration parameters when invoking a card

Allows indicating the desired CRD version when invoking CRD on a service that supports multiple versions

Indicates a request resource that is one of those that drove the creation of the card

Indicates a value to assert as an if-none-exist header on a create or update action

An extension for the CDS Hooks 'services' object that indicates configuration options supported by the CDS server

Indicates the version(s) of CRD supported by the service for a given type of hook

Codes identifying a type of CDS Hook

Codes allowed for defining the type of action in a CDS Hooks suggestion

Numeric codes defined by CMS to identify types of locations

Codes appropriate for inclusion in a claim or prior authorization

Allowed data types for configuration settings in the CDS Hooks configuration extension

Categories for conformance statements found in the CRD IG

Reasons for a coverage assertion in the coverage-information extension

Restriction of coverage classes for CRD purposes

Codes that define the type of coverage information detail being provided

Codes defining whether additional documentation needs to be captured

Codes defining whether the ordered/requested service is covered under patient's plan

List of reasons for additional documentation

Codes defining whether prior auth will be needed for coverage to be provided

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.

Codes defining whether information about the performer, location, and/or performance date is needed to determine coverage information

Address codes allowed for CRD locations - those that are physical addresses

A list of codes indicating the perspective from which metric data was captured

A list of codes indicating whether an access token was used as part of CDS Hooks processing

Detail codes for products and services that are the focus of a CRD call

List of CDS Hook response types defined by the CRD spec

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

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.

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

All ICD10 CM Disease codes

All NUBC type of bill codes

All NUCC Healthcare Provider Taxonomy codes that fall within the Individual or Groups (of Individuals) heading

All NUCC Healthcare Provider Taxonomy codes that fall within the Non-Individual heading

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.

Codes for name-value-pair details on a coverage assertion - now using official FHIR codes

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

This set of codes provides a high-level classification for what service is being requested.

Codes used within 'code' elements in the CRD Metric logical model.

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

Codes used by 'code' elements within the Coverage-Information extension.

Example appointment tied to a ServiceRequest based on CRD profile

Example stand-alone appointment populated based on CRD profile

Example communication request populated based on CRD profile

Example identified coverage populated based on CRD profile

Example device populated based on CRD profile

Example DeviceRequest populated based on CRD profile

Example dispatch Task populated based on CRD profile

Example encounter populated based on CRD profile

Example location populated based on CRD profile

Example medication request with an annotation showing coverage expectations

Example medication request populated based on CRD profile

Example nutrition order populated based on CRD profile

Example organization populated based on CRD profile

Example patient populated based on CRD profile

An example showing a fully populated US Core Practitioner instance (used in CRD examples)

Example questionnaire-completion Task populated based on CRD profile

Example service request populated based on CRD profile

Example vision prescription based on CRD profile

An example of a CRD discovery response

An example of a CRD request for order-sign with CommunicationRequest

An example of a CRD request for order-dispatch with MedicationRequests

An example of a CRD request for order-sign with ServiceRequests

An example of a CRD request for appointment-book

An example CRD response to a CommunicationRequest with a simple Coverage Information system action

An example of a CRD response of all 'mustSupport' response types, plus 'change order' response type

An example CRD response with various optional response types