Da Vinci - Coverage Requirements Discovery
2.1.0-preview - STU 2 United States of America flag

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

Contents:

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

Global profiles

There are no Global profiles defined

Structures: CDS Hooks Extensions

Models that define extensions on CDS Hooks JSON structures

CDS Hooks Services Configuration Extension

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

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 data requested by the CRD Server needed to provide that decision support. This capability statement doesn’t define the CDS Hooks capabilities as there is no standard way to do that as yet. Instead, it focuses on the ‘server’ capabilities needed to respond to CRD Server queries. These capabilities are based on US Core.

In addition to the U.S. core expectations, the CRD Client SHALL support all ‘SHOULD’ ‘read’ and ‘search’ capabilities listed below for resources referenced in supported hooks and order types if it does not support returning the associated resources as part of CDS Hooks pre-fetch. The CRD Client SHALL also support ‘update’ functionality for all resources listed below where the client allows invoking hooks based on the resource.
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 data requested by the CRD Server needed to provide that decision support. This capability statement doesn’t define the CDS Hooks capabilities as there is no standard way to do that as yet. Instead, it focuses on the ‘server’ capabilities needed to respond to CRD Server queries. These capabilities are based on US Core.

In addition to the U.S. core expectations, the CRD Client SHALL support all ‘SHOULD’ ‘read’ and ‘search’ capabilities listed below for resources referenced in supported hooks and order types if it does not support returning the associated resources as part of CDS Hooks pre-fetch. The CRD Client SHALL also support ‘update’ functionality for all resources listed below where the client allows invoking hooks based on the resource.
CRD Server USCDI 1
This statement defines the expected capabilities of systems wishing to conform to the ‘‘CRD Server’’ role for USCDI 1 (US-Core 3.1.1). 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 service 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 [[CapabilityStatement-crd-client client endpoints]] might vary in which resources they support.
CRD Server USCDI 3
This statement defines the expected capabilities of systems wishing to conform to the ‘‘CRD Server’’ role for USCDI 3 (US-Core 6.1.0). 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 service 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 [[CapabilityStatement-crd-client client endpoints]] might vary in which resources they support.

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 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: Resource Profiles

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

CRD Appointment

This profile specifies extensions and constraints on the Appointment resource to support coverage requirements discovery.
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 Encounter - USCDI 1

This profile specifies additional extensions and constraints on the US Core Encounter profile to support coverage requirements discovery. Compliant with USCDI 1
CRD Encounter - USCDI 3

This profile specifies additional extensions and constraints on the US Core Encounter profile to support coverage requirements discovery. Compliant with USCDI 3
CRD Location

This profile specifies constraints on the US Core Location 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 constraints on the US Core profile on the Practitioner resource 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: Extension Definitions

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

Coverage Information

Captures assertions from a payer about whether the service is covered and/or requires prior authorization.

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 Mappable Location Codes

Extends the base HL7-defined value set codes with supplementary codes needed to provide full coverage to the CMS location code set
CRD After Completion Code Value Set

Actions to take after completing form
CRD Card Types Value Set

List of card types defined by the CRD spec
CRD Configuration Code Data Types Value Set

Allowed data types for configuration settings in the CDS Hook configuration extension
CRD Coverage Assertion Reasons

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 Codes Value Set

Codes for name-value-pair details on a coverage assertion
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 perfomer, 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

A list of codes indicating whether an access token was used as part of CDS Hook processing
CRD Order Detail Codes Value Set

Detail codes for products and services that are the focus of a CRD call
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
CRD Task Reason Codes Value Set

Reasons for creating tasks in CRD

Terminology: Code Systems

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

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

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 example

Example 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
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
NutritionOder 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 example

Example practitioner populated based on CRD profile
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