Da Vinci - Coverage Requirements Discovery
2.1.0 - STU 2.1
Da Vinci - Coverage Requirements Discovery
2.1.0 - STU 2.1
This page is part of the Da Vinci Coverage Requirements Discovery (CRD) FHIR IG (v2.1.0: STU 2.1) based on FHIR (HL7® FHIR® Standard) R4. This is the current published version. For a full list of available versions, see the Directory of published versions
| Page standards status: Trial-use |
Each CDS Hook corresponds to a point in the workflow/business process within a CRD Client system where a specific type of decision support is relevant. For example, the order-select hook SHOULD fire whenever a user of a CRD Client creates a new order or referral. In many CRD Clients, the same hook might fire in multiple different workflows. (For example, an CRD client might have different screens for ordering regular medications vs. vaccinations vs. chemotherapy, not to mention distinct screens for lab orders, imaging orders and referrals. An order-select hook might be initiated from any or all of these screens/workflows.)
Within this implementation guide, CDS Hooks are used by CRD Clients to perform coverage requirements discovery from CRD Servers used by patients' payers. Six hooks are identified that cover the main situations where coverage requirements discovery is likely to be needed: appointment-book, encounter-start, encounter-discharge, order-dispatch, order-select, and order-sign. Payers and respective CRD Servers will vary between patients. CRD Clients conforming to this implementation guide SHALL be able to determine the correct payer CRD Service to use for each request.
Not all CRD Clients will support all hook types or order resource types. For example, community CRD client systems will not likely support encounter-discharge. Community pharmacy systems would not likely support appointment-book. Some EHRs might not support VisionPrescription when using order-sign. CRD Clients conforming to this implementation guide SHALL support at least one of the hooks and (for order-centric hooks), at least one of the order resource types listed below and SHOULD support all that apply to the context of their system. Future releases of this specification may increase expectations to support additional hooks.
Similarly, not all payers will necessarily provide coverage that is relevant to all hook types or order resource types. For example, a payer that only provides drug coverage would be unlikely to have coverage information to return on an encounter-discharge event or a VisionPrescription order. CRD Servers conforming to this implementation guide SHALL provide a service for all hooks and order resource types required of CRD clients by this implementation guide unless the server has determined that the hook will not be reasonably useful in determining coverage or documentation expectations for the types of coverage provided.
CRD Clients and CRD Servers MAY choose to support additional hooks available in the registry on the CDS Hooks continuous integration build or custom hooks defined elsewhere. In these cases, systems SHOULD adhere to the conformance expectations defined in this specification for any hooks listed here.
In the absence of guidance from the CDS Hooks specification, CRD Servers are expected to conform to the following rules when responding to requests from a CRD Client:
The hooks supported by this guide can be categorized into two types: 'primary' hooks and 'supporting' hooks.
The 'primary' hooks are Appointment Book, Orders Sign, and Order Dispatch. CRD Servers SHALL, at minimum, return a Coverage Information system action for these hooks, even if the response indicates that further information is needed or that the level of detail provided is insufficient to determine coverage.
The 'secondary' hooks are Orders Select, Encounter Start, and Encounter Discharge. These hooks MAY return cards or system actions, but are not expected to, and CRD clients are free to ignore any cards or actions returned. (CRD clients SHOULD use the configuration options to instruct CRD servers to not even try to return cards if they do not intend to display/process them.) If Coverage Information is returned for these hooks, it SHALL NOT include messages indicating a need for clinical or administrative information, as such information is expected to be made available later in the process and therefore such guidance is not useful.
The following sections describe the hooks covered by this implementation guide as well as any constraints, profiles, and resources expected to be supported by conformant implementations.
The hooks listed on the CDS hooks website are subject to update by the community at any time until they go through the ballot process. However, all substantive changes are noted in the Change Log section at the bottom of the page describing each hook. For each hook listed below, this specification identifies a specific version. For the sake of interoperability, implementers are expected to adhere to the interface defined in the specified version of each hook, though compatible changes from future versions can also be supported. CRD Servers SHALL handle unrecognized context elements by ignoring them.
Below is a summary diagram that outlines all the hooks, indicating when responses are mandatory or optional, and provides insights into what contributes to caching and attribution.
Note: Any hook can theoretically be used to assert a relationship from a member attribution perspective. The two hooks highlighted are the most appropriate ones as they could theoretically allow information to flow from the payer as part of the 'current' care delivery. Hooks later in the workflow would typically be too late to allow data to flow in a way that would allow that information to be taken into account in the current care event.
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 would be triggered when the user of a CRD Client books a future appointment for a patient with themselves, with someone else within their organization, or with another organization. (Note that whether the CRD Client will create an appointment - triggering the appointment-book hook - or a ServiceRequest - triggering an order-select or order-sign hook - can vary depending on the service being booked and the organizations involved.)
Potentially relevant CRD advice related to this hook might include:
Requirements related to the intended location and/or participants (e.g. warnings about out-of-network)
Requirements related to the service being booked (e.g. Is prior authorization needed? Is the service covered? Is the indication appropriate? Is special documentation required?)
Requirements related to the timing of the service (e.g. is the coverage still expected to be in effect? is the service too soon since the last service of that type?)
Reminders about additional services that are recommended to be scheduled or booked for the same patient - either as part of the scheduled encounter or as part of additional appointments that could be created at the same time
While this hook supports userIds of Patient and RelatedPerson, for CRD purposes it is enough to support Practitioner and PractitionerRole. Support for Patient and RelatedPerson as users is optional. (Note that Practitioner and PractitionerRole include both licensed healthcare professionals as well as administrative staff.)
The profiles expected to be used for the resources resolved to by the userId, patientId and encounterId and in the appointments context elements are as follows:
| CRD Profiles | HRex & US Core Profiles |
|---|---|
| profile-appointment-with-order or profile-appointment-no-order | |
| profile-encounter | |
| profile-patient | |
| US Core practitioner | |
| hrex-practitionerrole |
Notes:
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 would be triggered when a patient is admitted, a patient arrives for an out-patient visit, and/or when a provider first engages with a patient during an encounter. The encounter-start hook serves a similar purpose to the appointment-book hook, though it provides less lead time to react to recommendations. If the purpose of the appointment is to perform a service that requires a 2-week prior authorization process, it is more efficient to identify prior-authorization requirements proactively through the use of the appointment-book hook to prevent the patient from showing up for an appointment that will need to be canceled and rescheduled.
The advice returned for this hook would include the same sorts of advice as provided for using appointment-book. However, the hook is still necessary because not all encounters will be the result of appointments, not all systems that schedule appointments will necessarily have checked for coverage requirements, and the patient's circumstances and/or coverage as well as the payer's guidelines could have evolved since the appointment was scheduled.
Note that Practitioner and PractitionerRole include both licensed healthcare professionals, as well as administrative staff.
The profiles expected to be used for the resources resolved to by the userId, patientId, and encounterId context references are as follows:
| CRD Profiles | HRex & US Core Profiles |
|---|---|
| profile-encounter | |
| profile-patient | |
| US Core practitioner | |
| hrex-practitionerrole |
Notes:
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 would generally be specific to an in-patient encounter and would fire when a provider is performing the discharge process within the CRD Client.
Potentially relevant CRD advice related to this hook might include:
Verifying that documentation requirements for the services performed have been met to ensure the services provided can be reimbursed
Ensuring that required follow-up planning is complete and appropriate transfer of care has been arranged, particularly for accountable care models
The profiles expected to be used for the resources resolved to by the userId, patientId, and encounterId context references are as follows:
| CRD Profiles | HRex & US Core Profiles |
|---|---|
| profile-encounter | |
| profile-patient | |
| US Core practitioner | |
| hrex-practitionerrole |
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 is a new hook that allows for decision support to be provided when the intended performer of a service is not chosen when the order is written, but instead at some later time-point, quite frequently by someone other than the practitioner who wrote the order. Because knowing 'who' will perform the service is often relevant when determining coverage and prior authorization requirements, and because it is also a useful point for providing guidance such as suggesting alternative "in-network" providers, this is a useful point in client workflow to provide decision support.
This hook will fire at some point after (possibly well after) the order-sign hook fires. It only passes the patient id, order id, performer, and (optionally) the Task that describes the fulfillment request as part of the context. This specification does not require use of the Task resource.
This hook allows multiple resource types to be present. Resources provided could all be the same type or be a mixture of types. Coverage requirements SHOULD be limited only to those resources that are included in the dispatchedOrders context, though the content of other resources SHOULD also be considered before making recommendations about what additional actions are necessary. (I.e. don't recommend an action if there's already an order to perform that action.)
The different relevant resource types are as follows (support can vary between clients):
CommunicationRequest: Used when a provider requests that another provider transfer patient records or other supporting information to another organization or agency.
DeviceRequest: Used for durable medical equipment orders, such as wheelchairs, prosthetics, diabetic supplies, etc. It can also be used to order glasses and other vision-correction devices.
MedicationRequest: Used to order inpatient and outpatient medications.* Can also be used to order vaccinations.
ServiceRequest: Used to order a referral, lab tests, diagnostic imaging, and sometimes to schedule a future appointment (also see appointment-book).
NutritionOrder: Used to order the preparation of specific meal types. Generally used for in-patient care, but potentially also relevant for homecare.
* - Note: in the medication space, regulations may mandate alternate standards for some of the functionality covered by CRD for certain classes of medications. E.g. NCPDP Script
CRD responses might include:
Information about preauthorization and clinical documentation requirements, including forms to be completed
Alternative performers (e.g. in-network providers)
There are no constraints or special rules related to this hook beyond the profiles expected to be used for the resources resolved to by the patientId or encounterId or in the dispatchedOrders context element:
† 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.
Notes:
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.
Support for this hook is optional, as not all information will necessarily be available when this hook is invoked. Therefore, the Order Sign and Order Dispatch hooks are more critical to implement because they fire when information is required to be more complete and also represent the 'end' of the user engagement in their respective processes. That said, the "Order Select" hook is still quite useful.
First, because it fires earlier in the user's system interactions, it provides an opportunity for CRD services to initiate back-end queries that might take time to complete so that relevant information is already retrieved and cached before Order Sign is reached. This increases performance and makes it easier for CRD services to respond in the required timeframe.
Second, where a CRD service is able to provide guidance to providers earlier in the process (e.g. upon selection of a service but before entering detailed instructions), it can help to make the provider experience more efficient. (If a provider knows up-front that a service won't be paid for but an alternative would be, they might be happier if they can save the time on entering full details before finding this out.) Not all providers or EHRs will necessarily want to receive 'proactive' decision support during the order entry process. EHRs can be configured as to what types of cards they're interested in receiving back for this hook, including no cards at all if the hook is being invoked solely for performance/caching reasons.
This hook allows multiple resource types to be present. Resources provided could all be the same type or be a mixture of types. Coverage requirements SHOULD be limited only to those resources that are included in the selections context, though the content of other resources SHOULD also be considered before making recommendations about what additional actions are necessary. (I.e. don't recommend an action if there's already a draft order to perform that action.)
The different relevant resource types are as follows (support can vary between clients):
CommunicationRequest: Used when a provider requests that another provider transfer patient records or other supporting information to another organization or agency.
DeviceRequest: Used for durable medical equipment orders, such as wheelchairs, prosthetics, diabetic supplies, etc. It can also be used to order glasses and other vision-correction devices.
MedicationRequest: Used to order inpatient and outpatient medications.* Can also be used to order vaccinations.
ServiceRequest: Used to order a referral, lab tests, diagnostic imaging, and sometimes to schedule a future appointment (also see appointment-book).
NutritionOrder: Used to order the preparation of specific meal types. Generally used for in-patient care, but potentially also relevant for homecare.
* - Note: in the medication space, regulations may mandate alternate standards for some of the functionality covered by CRD for certain classes of medications. E.g. NCPDP Script
CRD responses might include:
Information about preauthorization and clinical documentation requirements, including forms to be completed
Alternative therapies that are covered or required first-line therapies
Potential drug-drug interactions based on existing payer knowledge
Recommendations about in-network vs. out-of-network providers for referrals
There are no constraints or special rules related to this hook beyond the profiles expected to be used for the resources resolved to by the patientId or encounterId or in the draftOrders context element:
† 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.
Notes:
This hook is described in the CDS Hook specification here. This version of the CRD implementation guide refers to version 1.1 of the hook which, at the time of publication, was not available as a snapshot. Therefore the preceding link refers to the CDS hooks current build..
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 found in in order-select is not used in order-sign..
Use and profiles for order-select also apply to order-sign.
Notes:
IG © 2019+ HL7 International / Financial Management. Package hl7.fhir.us.davinci-crd#2.1.0 based on FHIR 4.0.1. Generated 2024-12-11
Links: Table of Contents |
QA Report
| Version History |
|
Propose a change