Da Vinci - Coverage Requirements Discovery
2.2.0-snapshot - STU 2.2 Peer Review
Da Vinci - Coverage Requirements Discovery
2.2.0-snapshot - STU 2.2 Peer Review
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.0-snapshot 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
| Page standards status: Trial-use |
This page contains a table listing all the free-text conformance statements found in the IG. This table is provided as a useful summary for implementers for the purpose of evaluating key features and to support testing. However, reading this table alone is insufficient to understand or successfully implement the specification:
A few other notes:
The controls at the top of the table allow filtering the content to particular requirement subsets that may be of interest. As well, a computable representation (XML and JSON) of the requirements can be found here.
| Id | Expectation | Conditional? | Actor(s) | Category(ies) | Rule |
|---|---|---|---|---|---|
| SHALL SHALL NOT MAY SHOULD SHOULD NOT | Yes No Any | CRD Client CRD Client Organization CRD Server CRD Server Organization | business exchange processing storage ui | ||
| §billopt-1 | SHALL | X | CRD Client | exchange | CRD clients SHALL use the billing-options extension to convey likely billing codes if they are known, but are not required to know billing codes (e.g. if ordering and performing systems will differ). |
| §billopt-2 | SHALL NOT | X | CRD Server | processing | CRD servers SHALL NOT depend on the billing-options extension being present in order to provide a response. |
| §billopt-3 | SHALL MAY | CRD Server | processing | If codes are provided with the billing-options extension, CRD servers SHALL consider any codes provided and MAY consider additional codes determined by their own mapping when returning coverage information responses. | |
| §conf-1 | SHALL | CRD Client | exchange | CRD clients SHALL support at least one of the three specified versions of US Core. | |
| §conf-2 | SHALL | CRD Server | exchange | CRD servers SHALL be able to handle all three US Core versions. | |
| §conf-3 | SHALL | X | CRD Client | exchange | If the CRD client maintains a mustSupport data element and surfaces it to users, then it SHALL be exposed in their FHIR interface when the data exists and privacy constraints permit. |
| §conf-4 | SHALL | CRD Server | processing | CRD servers SHALL leverage mustSupport elements as available and appropriate to provide decision support. | |
| §conf-5 | SHALL | X | CRD Server | exchange | CRD servers SHALL populate mustSupport elements if an appropriate value exists. |
| §conf-6 | SHALL | CRD Client | processing ui | CRD clients SHALL make the mustSupport data available to the appropriate user (clinical or administrative) or leverage the data within their workflow as necessary to follow the intention of the provided decision support. | |
| §conf-7 | SHALL NOT | CRD Server | exchange | When preparing Coverage Information responses, CRD servers SHALL NOT depend on or set expectations for the inclusion of resource instances not compliant with profiles defined in this guide, HRex, or US Core. | |
| §conf-8 | SHALL NOT | CRD Server | exchange | CRD servers SHALL NOT depend on or set expectations for the inclusion of any data elements not marked as mandatory (min cardinality >= 1) or mustSupport in those profiles. | |
| §conf-9 | SHOULD | X | CRD Server | exchange | When preparing response types other than Coverage Information, CRD servers SHOULD limit themselves to the same resource instances and data elements as permitted above for Coverage Information responses. |
| §conf-10 | SHALL NOT | CRD Client | exchange | CRD clients SHALL NOT depend on or set expectations for CRD servers to communicate data elements not marked as mandatory or mustSupport in the CRD specification. | |
| §conf-11 | MAY | X | CRD Client CRD Server | exchange | implementations MAY, by mutual agreement, pre-adopt the use of those additional CI-build profiles and/or mustSupport data elements and not be considered in violation of #1 or #3 above. |
| §conf-12 | SHALL NOT | X | CRD Client CRD Server | exchange | Where cardinality and other constraints present in profiles allow data elements to be omitted, CRD compliant systems SHALL NOT treat the omission of those elements as an error. |
| §conf-13 | SHALL | CRD Client CRD Server | exchange | CRD clients and services and SHALL use standard CRD data elements (i.e. elements found within CRD-defined or inherited profiles and marked as mandatory or mustSupport) to communicate needed data where the elements are intended to convey such information. | |
| §conf-14 | SHALL NOT | CRD Client Organization CRD Server Organization | business | CRD implementing organizations SHALL NOT publish guidance setting expectations for where certain data elements are conveyed within CRD and inherited data structures | |
| §covinfo-1 | SHOULD | CRD Server | exchange | The union of the scoping elements in each coverage-information repetition SHOULD be disjoint. | |
| §covinfo-2 | SHOULD | X | CRD Server | exchange | If there are multiple reason repetitions, each repetition SHOULD make clear exactly what aspect of the coverage information assertion the reason applies to. |
| §dev-1 | SHALL | CRD Server | exchange | CRD servers SHALL declare at least one supported CRD version for each supported hook. | |
| §dev-2 | SHALL | X | CRD Server | exchange | If the services endpoint can handle multiple CRD versions, it SHALL declare all versions it supports. |
| §dev-3 | SHALL MAY | X | CRD Client | exchange | The requestedVersion extension SHALL be present if the service indicates it supports multiple versions for that hook, but MAY be present always. |
| §dev-4 | SHALL | CRD Server | exchange | Each configuration option SHALL include four mandatory elements. | |
| §dev-5 | SHALL | CRD Server | exchange | CRD servers SHALL, at minimum, offer configuration options for each type of card they support (with a code corresponding to the CRD Response Types ValueSet and a type of ‘boolean’, where setting the flag to false will result in the server not returning any cards of the specified type). | |
| §dev-6 | SHALL | CRD Server | exchange | Guidance can be given about allowed combinations in descriptions, but CRD servers SHALL gracefully handle disallowed/nonsensical combinations. | |
| §dev-7 | SHALL | X | CRD Server | exchange | Configuration codes SHALL be valid JSON property names and SHALL come from the CRD Response Types list if an applicable type is in that list. |
| §dev-8 | SHALL | CRD Server | exchange | Configuration codes, names, and descriptions SHALL be unique within a CDS Service definition. | |
| §dev-9 | SHOULD | CRD Server | exchange | Configuration codes, names, and descriptions SHOULD be consistent across different hooks supported by the same payer when dealing with the same types of configuration options. | |
| §dev-10 | SHOULD | CRD Server | exchange | CRD servers providing more than one type of coverage requirement information/guidance SHOULD expose configuration options allowing clients to dynamically control what information is returned by the service. | |
| §dev-11 | SHOULD | CRD Client | ui | CRD Clients SHOULD expose configuration options through a configuration screen to allow users and/or system administrators to control the types of information returned. | |
| §dev-12 | SHALL | CRD Client | exchange | CRD Clients SHALL convey configuration options when invoking the hook using the davinci-crd.configuration extension. It will be a single object whose properties will be drawn from the code values from configuration options and whose values will be of the type defined for that option. | |
| §dev-13 | SHOULD | CRD Client | processing | CRD Clients SHOULD provide an ability to leverage the dynamic configuration capabilities of payer services based on provider role, individual provider, and/or hook invocation location as best meets the needs of their users. | |
| §dev-14 | SHALL | CRD Server | processing | CRD Servers SHALL behave in the manner prescribed by any supported configuration information received from the CRD Client. | |
| §dev-15 | SHALL NOT | CRD Server | processing | CRD Servers SHALL NOT require the inclusion of configuration information in a hook call (i.e. no hook invocation is permitted to fail because configuration information was not included). | |
| §dev-16 | MAY | CRD Client | exchange | CRD Clients MAY send configuration information that CRD Servers do not support. | |
| §dev-17 | SHALL | CRD Server | processing | CRD Servers SHALL ignore unsupported configuration information. | |
| §dev-18 | SHALL | CRD Server | exchange | Prefetches with dependencies SHALL be listed after the prefetches they depend on. | |
| §dev-19 | SHOULD | CRD Server | exchange | When included with a Task, the creation of the Questionnaire needs to be conditional - it SHOULD only occur if that specific Questionnaire version does not already exist | |
| §dev-20 | SHALL | CRD Server | exchange | the CRD server SHALL query to determine if the client has a copy of the Questionnaire before sending the request. | |
| §dev-21 | SHALL | CRD Client | processing | For the purposes of this implementation guide, the inclusion of the id element in 'created' resources and references in created and updated resources within multi-action suggestions SHALL be handled as per FHIR's transaction processing rules. | |
| §dev-22 | SHALL | CRD Server | processing | Specifically, this means that if a FHIR Reference points to the resource type and id of a resource of another 'create' Action in the same Suggestion, then the reference to that resource SHALL be updated by the server to point to the id assigned by the client when performing the 'create'. | |
| §dev-23 | SHALL | CRD Client | processing | CRD Clients SHALL perform 'creates' in an order that ensures that referenced resources are created prior to referencing resources. | |
| §dev-24 | SHALL | X | CRD Server | exchange | If a hook service is invoked on a collection of resources, all cards returned that are specific to only a subset of the resources passed as context SHALL disambiguate in the detail element which resources they are associated with in a human-friendly way. |
| §dev-25 | SHOULD | CRD Server | exchange | As well, cards SHOULD include the associated-resource extension to allow computable linkage. | |
| §dev-26 | SHALL | CRD Client | exchange | CRD clients SHALL only invoke hooks on payer services where the patient record indicates active coverage with the payer associated with the service and where there is no recorded indication the patient intends to bypass insurance coverage (i.e. the service or product is not flagged as 'patient-pay'). | |
| §dev-27 | MAY | CRD Client | exchange | CRD clients MAY limit hook invocation to only those payers that are believed to potentially have relevant information related to the current action - for example, clinical guidance, contraindication detection, etc. | |
| §dev-28 | SHALL | X | CRD Client | exchange | To avoid confusion for providers, where a patient has multiple active coverages that could be relevant to the current order/appointment/etc., CRD clients SHALL select from those coverages which is most likely to be primary and only solicit coverage information for that one payer. |
| §dev-29 | SHALL MAY | CRD Client | exchange | This primary coverage SHALL be the only one included in the prefetch content as part of the CRD request, though other coverages MAY be exposed over the CRD client's FHIR API. | |
| §dev-30 | SHALL | X | CRD Client | exchange | If they invoke CRD on other payers, CRD clients SHALL ensure that response types that return coverage information are disabled for those 'likely secondary' payers. |
| §dev-31 | MAY | X | CRD Client | exchange | In situations where a CRD client determines that there are different primary coverages for different items in the same order action, they MAY choose to send separate CRD calls (each with its own access token) for the collection of services pertinent to that Coverage. |
| §dev-32 | SHALL | X | CRD Client | exchange | Where the patient has multiple active coverages that the CRD client deems appropriate to call the respective CRD servers for, the CRD client SHALL invoke all CRD server calls in parallel and display results simultaneously to ensure timely response to user action. |
| §found-1 | MAY | CRD Client CRD Server | exchange | CRD servers and CRD clients MAY mutually agree to support additional hooks, additional card patterns, additional resources, additional extensions, etc. | |
| §found-2 | SHALL | CRD Server | processing | CRD servers SHALL return responses for all supported hooks and SHALL respond within the required time 90% of the time. | |
| §found-3 | MAY | X | CRD Client | processing | If a CRD client does not receive a response within the 5 or 10-second window, it MAY either abandon the call or process the response asynchronously. |
| §found-4 | SHOULD | X | CRD Server Organization | business | Where a CRD server responds with a coverage information extension indicating doc-needed of 'clinical', 'admin', or 'patient' and the payer supports DTR, the responsible organization SHOULD support gathering the additional information via DTR. |
| §found-5 | SHOULD | X | CRD Server | exchange | CRD servers SHOULD query all data necessary to make their coverage determination decisions if that data is available for query in the EHR and that data is not returned in prefetch. |
| §found-6 | SHALL | CRD Client | ui | CRD clients SHALL provide a mechanism for providers to bypass a CRD process that is taking longer than the aforementioned time limit to ensure users are not blocked from proceeding with their business flow. | |
| §found-7 | MAY | X | CRD Client | exchange | For responses that come back in a time period that exceeds the time maximm duration specifd in this guide, CRD clients MAY ignore the resulting cards and/or system actions. |
| §found-8 | SHALL | CRD Server | processing | CRD servers SHALL ensure that the guidance returned with respect to coverage and prior authorizations (e.g., assertions that a service is covered, or prior authorization is not necessary) is as accurate as guidance that would be provided by other means (e.g., portals, phone calls). | |
| §found-9 | SHOULD | CRD Server | exchange | Also, coverage and authorization guidance SHOULD allow for possible variances in coding and submission. | |
| §found-10 | SHALL | CRD Server | storage processing | CRD servers SHALL retain all coverage guidance provided and take into account answers provided via CRD (and DTR) when subsequently adjudicating claims. | |
| §found-11 | SHOULD | X | CRD Client | exchange | Where the selected code is not already a billing code and CRD clients are able to automatically determine what the corresponding billing code is, they SHOULD send a Coding with the billing code alongside the clinical code to reduce the risk of the receiving payer making a different translation. |
| §found-12 | SHALL | CRD Server | processing | CRD servers SHALL ensure that CDS Hooks return only messages and information relevant and useful to the intended recipient. | |
| §found-13 | SHALL | X | CRD Server | exchange | If a CRD server supports endpoint discovery, they SHALL have at most a single endpoint for each coverage (e.g., Medicare, Medicaid, or commercial) they provide coverage under. |
| §found-14 | SHALL | X | CRD Server | exchange | If a CRD server does not support endpoint discovery, they SHALL expose only one CRD endpoint capable of handling all coverages. |
| §found-15 | SHOULD | CRD Client | processing | When the connection between a particular client and server has evolved to an automated configuration approach, CRD Clients SHOULD perform the discovery process on the CRD server at least once per day to detect any changes to supported hooks, prefetch requirements, and/or configuration options. | |
| §found-16 | SHOULD | X | CRD Client | processing | If a CRD client encounters an error when invoking a hook, they SHOULD re-run the discovery process before failing. |
| §found-17 | MAY | CRD Client CRD Server | processing | CRD clients and servers MAY leverage the payer registry developed by PDex (which will eventually fold into the national directory under FAST) as a means of determining which endpoints exist for which payers as candidates for configuration. | |
| §found-18 | SHOULD | X | CRD Client | exchange | Once plans are in the national directory, CRD clients SHOULD include that plan identifier to uniquely identify a plan. |
| §found-19 | SHALL | CRD Client | exchange | When a CRD client invokes a CRD server via CDS Hooks, it SHALL provide an access token that allows the CRD server to retrieve additional patient information. | |
| §found-20 | SHALL | CRD Client | processing | The CRD client SHALL limit the scopes provided in their access token as narrowly as feasible to reflect the data requirements identified by the CRD server as necessary to perform their decision support. | |
| §found-21 | SHOULD | CRD Client | processing | Such access tokens SHOULD have an expiration time of no longer than 30 seconds which should be sufficient for even 'parallel' decision support with something like 'Order Select' where a user continues to work while the decision support call is processing. | |
| §found-22 | SHALL | CRD Client CRD Server | exchange | For this release of the IG, conformant CRD clients and servers SHALL support the CDS Hooks prefetch capability. | |
| §found-23 | SHALL | CRD Client | exchange | Clients SHALL be able to supply all the existing resources defined in the prefetch section below for request resources they support. | |
| §found-24 | SHALL | X | CRD Server | exchange | Servers SHALL use prefetch expressions in the manner described if those data elements are relevant to their coverage determination or other decision support. |
| §found-25 | MAY | CRD Server | exchange | They MAY include more and/or less prefetch requests than described in this Additional Data Retrieval section, based on which data is desired. | |
| §found-26 | SHOULD | CRD Server | exchange | Prefetch requests SHOULD only include information that is always expected to be needed for each hook invocation. | |
| §found-27 | SHALL | X | CRD Server | exchange | When information is only needed for certain invocations of the hook (e.g., for specific types of medications or services), that information SHALL only be retrieved by query using the provided token, never requested universally via prefetch. |
| §found-28 | SHALL | CRD Server | processing | CRD Servers SHALL be able to parse and execute prefetches that use the x-fhir-query syntax defined in the current CDS Hooks specification and not fail if that syntax is present. | |
| §found-29 | SHOULD NOT | CRD Client | processing | CRD client implementations SHOULD NOT depend on standardized prefetch key names. | |
| §found-30 | SHALL | CRD Client | processing | CRD clients supporting prefetch SHALL inspect the CDS Hooks discovery endpoint to determine exact prefetch key names and queries. | |
| §found-31 | SHALL | CRD Client | exchange | As mentioned in Controlling Hook Invocation, Coverage included in prefetch SHALL be limited to a single instance. | |
| §found-32 | SHALL NOT | CRD Server | processing | HTTP 412 responses SHALL NOT be used in situations where the prefetch was provided or the query was successfully performed but the record in question did not have all the data the payer might have needed/desired. | |
| §found-33 | SHALL | CRD Client CRD Server | exchange | CRD clients and servers SHALL ignore unexpected elements when processing instances. | |
| §found-34 | SHALL | CRD Server | processing | CRD servers SHALL provide what coverage requirements they can based on the information available. | |
| §found-35 | SHALL SHOULD MAY | CRD Client | exchange | In the specific case of order-based hooks, "what if" SHOULD use the Order Sign hook but SHALL use the configuration option that prevents the return of an unsolicited determination and MAY use configuration options to prevent the return of other irrelevant types of cards (e.g., duplicate therapy). | |
| §found-36 | SHALL | CRD Client | exchange | When CRD clients pass resources to a CRD server as part of context, the resources SHALL have an 'id' and that 'id' SHALL be usable as a target for references in resources manipulated by CDS Hooks actions and/or by SMART apps. | |
| §found-37 | SHALL | CRD Client CRD Server | storage | Therefore, in addition to any logging performed for security purposes, both CRD clients and CRD servers SHALL retain logs of all CRD-related hook invocations and their responses for access in the event of a dispute. | |
| §found-38 | SHALL | CRD Client Organization CRD Server Organization | business | Organizations SHALL have processes to ensure logs can be accessed by appropriate authorized users to help resolve discrepancies or issues in a timely manner. NOTE: Because the information in these logs will often contain PHI, access to the logs themselves will need to be restricted and logged for security purposes. | |
| §found-39 | SHOULD | CRD Client | ui | CRD clients SHOULD ensure that multiple cards with the same advice are handled in a way that will not create a burden on the user. | |
| §found-40 | SHOULD | CRD Client CRD Server | exchange | Conformant systems SHOULD omit non-significant whitespace in transmitted instances for performance reasons. | |
| §hook-1 | SHALL | CRD Client | processing | CRD Clients conforming to this implementation guide SHALL be able to determine the correct payer CRD server to use for each request. | |
| §hook-2 | SHALL SHOULD | CRD Client | exchange | 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. | |
| §hook-3 | SHALL | X | CRD Client | exchange | For systems that support ordering products or services covered by one of the CRD-supported request types, such clients SHALL support the order-sign hook for the order types they support. |
| §hook-4 | SHALL | X | CRD Server | exchange | 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. |
| §hook-5 | MAY | CRD Client CRD Server | exchange | 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. | |
| §hook-6 | SHOULD | X | CRD Client CRD Server | exchange | When supporting hooks not covered by this guide, systems SHOULD adhere to the general conformance expectations defined in this specification for those additional hooks. |
| §hook-7 | SHALL | CRD Client | ui | CRD clients SHALL allow hook invocation to occur transparently as part of user workflow. | |
| §hook-8 | SHALL NOT | X | CRD Client | ui | CRD clients SHALL NOT require transcription of order, appointment, or other data into a separate interface distinct from regular provider workflow unless performing "what if" situations. |
| §hook-9 | SHALL | X | CRD Server | exchange | If the CRD Server encounters an error when processing the request, the system SHALL return an appropriate error HTTP Response Code, starting with the digit "4" or "5", indicating that there was an error. |
| §hook-10 | SHALL | X | CRD Server | exchange | If an issue is identified at a layer of the CRD Server that is FHIR aware (e.g. not a "wrong endpoint" or "not authorized" issue), the server SHALL provide an OperationOutcome for internal issue tracking by the client system. |
| §hook-11 | MAY | CRD Client | ui | The CRD Client MAY display to the user that the Coverage Requirements Discovery Service is unavailable. | |
| §hook-12 | MAY | X | CRD Client | ui | If additional information (e.g. number to call) is available, it MAY also be included in the message to the user. |
| §hook-13 | SHALL SHOULD | CRD Server | exchange | CRD Servers SHALL use the 400 and 422 codes in a manner consistent with the FHIR RESTful Create Action | |
| §hook-14 | MAY | X | CRD Server | processing | If a CRD server's validation process does not differentiate between validation issues stemming from the JSON syntax validation, FHIR core validation, CDS Hooks validation, and CRD-specific validation, it MAY treat all validation rules as 400 errors. |
| §hook-15 | MAY | X | CRD Client | processing | A CRD client MAY opt to re-invoke a CRD hook either due to manual user intervention or automatically in the background if there is a reason to believe that a substantive change in the patient's record and/or coverage might produce a different CRD response. |
| §hook-16 | SHALL | CRD Server | exchange | CRD Servers SHALL, at minimum, return a Coverage Information system action for 'primary' hooks, even if the response indicates that further information is needed or that the level of detail provided is insufficient to determine coverage. | |
| §hook-17 | MAY | CRD Client | exchange | 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. | |
| §hook-18 | SHOULD | X | CRD Client | exchange | CRD clients SHOULD use the configuration options to instruct CRD servers to not even try to return responses if the client does not intend to display/process them. |
| §hook-19 | SHALL NOT | X | CRD Server | exchange | 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. |
| §hook-20 | SHALL | CRD Client | exchange | Where profiles are provided in a table for the hook sections below, CRD clients SHALL ensure that data included in the hook invocation complies with the listed profiles. | |
| §hook-21 | SHALL NOT | CRD Server | processing | CRD servers SHALL NOT depend on data not covered by the identified profiles in order to return valid coverage-information responses. | |
| §hook-22 | SHALL | CRD Server | processing | CRD Servers SHALL handle unrecognized context elements by ignoring them. | |
| §hook-23 | MAY | CRD Server | processing | CRD Servers MAY use the appointment-book hook as a basis for associating a patient with a particular practitioner from a payer attribution perspective. | |
| §hook-24 | SHALL | CRD Client CRD Server | exchange processing | CRD clients and servers SHALL, at minimum, support returning and processing the Coverage Information system action for all invocations of the appointment-book hook. | |
| §hook-25 | MAY | CRD Server | processing | CRD Servers MAY use the appointment-book hook as a basis for associating a patient with a particular practitioner from a payer attribution perspective. | |
| §hook-26 | SHOULD | CRD Server | processing | 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. | |
| §hook-27 | MAY | CRD Server | processing | CRD Servers MAY use the order-dispatch hook as a basis for associating a patient with a particular practitioner from a payer attribution perspective. | |
| §hook-28 | SHALL | CRD Client CRD Server | exchange processing | CRD clients and servers SHALL, at minimum, support returning and processing the Coverage Information system action for all invocations of the order-dispatch hook. | |
| §hook-29 | SHOULD | CRD Server | processing | 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. | |
| §hook-30 | MAY | X | CRD Client | processing | Where CRD Clients have an appropriate workflow and data capture mechanism, the order-select hook MAY be used in scenarios that do not involve creating a true order. |
| §hook-31 | MAY | CRD Server | processing | CRD Servers MAY use the order-select hook as a basis for associating a patient with a particular practitioner from a payer attribution perspective. | |
| §hook-32 | SHALL | CRD Client CRD Server | exchange processing | CRD clients and servers SHALL, at minimum, support returning and processing the Coverage Information system action for all invocations of the order-select hook. | |
| §impl-1 | SHALL | CRD Client | ui | Clients that suppress 'default presumption' coverage-information of messages SHALL mitigate the potential for misinterpretation in the event CRD is unavailable. | |
| §impl-2 | SHOULD | CRD Server | processing | CRD servers SHOULD strive to achieve a minimum of 3-9s availability for their services and strive to provide at least some level of useful response to CRD clients even if some of their back-end systems are unavailable. | |
| §impl-3 | SHALL | CRD Client CRD Server | exchange | Even if implemented using multiple components, there is still a requirement that the exchanges between the provider HIT (including any ePA coordinators) and the payer HIT (including any ePA coordinators) SHALL replicate all of the defined exchanges between provider and payer. | |
| §impl-4 | MAY | X | CRD Client | exchange | In situations where CRD clients are aware of the likely billing codes at the time of ordering, they MAY send these codes as additional CodeableConcept.coding repetitions to assist in server processing. |
| §impl-5 | SHOULD | CRD Server | exchange | Where a CRD server has made inferences beyond what is explicit in the CRD request, the response SHOULD make clear what assumptions around billing codes, in/out-of-network, delivery location were made in providing the response. | |
| §metric-1 | SHOULD MAY | CRD Client CRD Server | storage | Each of these IGs recommends a set of metrics that SHOULD or MAY be collected by their respective implementations to facilitate the evaluation of adoption, functionality, processes, and improved outcomes. | |
| §ops-1 | SHOULD | CRD Client CRD Server | exchange | CRD clients and servers SHOULD support encounter-start and order-select, both to allow payer caching and to allow payers to return useful responses when possible (e.g. coverage expired, service not covered) with the limited information available in those hooks. | |
| §prof-1 | SHALL | CRD Client | exchange | CRD Clients SHALL use either this Appointment with Order profile and/or the with-order to provide appointments context objects to CRD Servers when invoking the appointment-book hook as well as to resolve other references to Appointment resources. | |
| §prof-2 | SHALL | CRD Client | exchange | CRD Clients SHALL use either this Appointment without Order and/or the no-order to provide appointments context objects to CRD Servers when invoking the appointment-book hook as well as to resolve other references to Appointment resources. | |
| §prof-3 | SHALL | CRD Client | exchange | CRD Clients SHALL use the CRD CommunicationRequest profile to resolve references to CommunicationRequest resources passed to CRD Servers (e.g. selections context references) and to populate draftOrders context objects. | |
| §prof-4 | SHALL | CRD Client | exchange | CRD Clients SHALL use the CRD Coverage profile to resolve references to insurance Coverage resources passed to CRD Servers. | |
| §prof-5 | SHALL | CRD Client | exchange | CRD Clients SHALL use the CRD Device profile to resolve references to Device resources passed to CRD Servers. | |
| §prof-6 | SHALL | CRD Client | exchange | CRD Clients SHALL use the CRD DeviceRequest profile to resolve references to DeviceRequest resources passed to CRD Servers (e.g. selections context references) and to populate draftOrders context objects. | |
| §prof-7 | SHALL | CRD Client | exchange | CRD Clients SHALL use the CRD Encounter profile to resolve references to Encounter resources passed to CRD Servers, including encounterId context references. | |
| §prof-8 | SHALL | CRD Client | exchange | CRD Clients SHALL use the CRD Location profile to resolve references to insurance Location resources passed to CRD Servers. | |
| §prof-9 | SHALL | CRD Client | exchange | CRD Clients SHALL use the CRD MedicationRequest profile to resolve references to MedicationRequest resources passed to CRD Servers (e.g. selections context references) and to populate draftOrders context objects | |
| §prof-10 | SHALL | CRD Client | exchange | CRD Clients SHALL use CRD NutritionOrder profile to resolve references to NutritionOrder resources passed to CRD Servers (e.g. selections context references) and to populate draftOrders context objects. | |
| §prof-11 | SHALL | CRD Client | exchange | CRD Clients SHALL use the CRD ServiceRequest profile to resolve references to ServiceRequest resources passed to CRD Servers (e.g. selections context references) and to populate draftOrders context objects. | |
| §prof-12 | SHALL | CRD Client | exchange | CRD Clients SHALL use the CRD VisionPrescription profile to resolve references to VisionPrescription resources passed to CRD Servers (e.g. selections context references) and to populate draftOrders context objects. | |
| §prof-13 | SHALL | X | CRD Client | exchange | If a Location is a fine-grained location such as a bed or room, the address SHALL be propagated from the higher-level location it is part of. |
| §prof-14 | MAY | CRD Client | exchange | While the codes for the medication are expected to be drawn from RxNorm, EHRs MAY send additional coding repetions to communicate other code systems (e.g. HCPCS J codes). | |
| §resp-1 | SHOULD | CRD Server | exchange | The Card.indicator SHOULD be populated from the perspective of the clinical decision maker, not the payer | |
| §resp-2 | SHOULD | CRD Server | exchange | Most Coverage Requirements SHOULD be marked as 'info'. | |
| §resp-3 | SHALL | CRD Server | exchange | All Card.suggestion elements SHALL populate the Suggestion.uuid element. | |
| §resp-4 | SHALL | CRD Server | exchange | The Card.source.label SHALL be populated with an insurer name that the user and patient are likely to 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 server on behalf of the payer. | |
| §resp-5 | SHALL | CRD Server | exchange | Card.source.topic SHALL be populated, and has an extensible binding to the ValueSet CRD Response Types. | |
| §resp-6 | SHOULD | CRD Server | exchange | Card.summary SHOULD provide actionable information. | |
| §resp-7 | SHOULD | CRD Server | exchange | Card.detail and/or external links SHOULD only be provided when coverage recommendations cannot be clearly provided in the 140-character limit of Card.summary. | |
| §resp-8 | SHOULD | CRD Server | exchange | 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. | |
| §resp-9 | SHOULD | CRD Server | exchange | Card.detail SHOULD provide enough context that a user can determine whether it is worth their time to launch an app or follow an external link, ideally providing a sense of where to look for and how to use whatever link or app they launch in the specific context of the order they are making. | |
| §resp-10 | SHOULD | CRD Server | exchange | 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. | |
| §resp-11 | SHOULD | CRD Server | exchange | 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 is not available. | |
| §resp-12 | SHOULD NOT | X | CRD Server | exchange | Where systemActions are used, CRD servers SHOULD NOT return equivalent information in a card for user display. |
| §resp-13 | SHALL | CRD Client CRD Server | exchange | Conformant CRD clients and services SHALL support the Coverage Information response type. | |
| §resp-14 | SHOULD | CRD Client CRD Server | exchange | Conformant CRD clients and services SHOULD support the additional (non-coverage information) types defined by this guide. | |
| §resp-15 | SHOULD | X | CRD Server | exchange | CRD servers that provide decision support for domains outside of coverage and/or documentation requirements SHOULD take reasonable steps to check that the CRD client does not have the information within its store that would allow it to detect the issue itself. |
| §resp-16 | SHALL NOT | CRD Server | exchange | CRD servers SHALL NOT use "External Reference" cards to direct users to a portal for the purpose of initiating prior authorization or determining coverage. | |
| §resp-17 | SHALL | CRD Server | exchange | The card SHALL have at least one Card.link. | |
| §resp-18 | SHALL | CRD Server | exchange | The Link.type SHALL have a type of "absolute". | |
| §resp-19 | SHOULD | X | CRD Server | exchange | When reasonable, an "External Reference" card SHOULD contain a summary of the actionable information from the external reference in the detail element. |
| §resp-20 | SHOULD | X | CRD Server | exchange | As much as technically possible, links provided SHOULD be 'deep' links that take the user to the specific place in the documentation relevant to the current hook context to minimize provider reading and navigation time. |
| §resp-21 | SHALL NOT | CRD Server | exchange | CRD servers SHALL NOT use Instructions Response cards to direct users to a portal for the purpose of initiating prior authorization or determining coverage. Use the Coverage Information response instead. | |
| §resp-22 | SHALL NOT | CRD Server | exchange | Regardless of the content, this "Coverage Information" response type SHALL NOT use a card. | |
| §resp-23 | SHALL | CRD Server | exchange | CRD servers SHALL support supplying coverage information for all primary hooks: order-sign, order-dispatch, and appointment-book. | |
| §resp-24 | MAY | CRD Server | exchange | CRD servers MAY support supplying coverage information for all other (non-primary) hooks. | |
| §resp-25 | SHALL | X | CRD Server | exchange | CRD servers SHALL supply coverage information for all hooks where they support it unless the EHR sends a configuration option asking them not to. |
| §resp-26 | SHALL | X | CRD Server | exchange | If coverage information is evaluated, a system action SHALL be returned for each in-scope request resource unless that request resource already has a coverage-information extension, and the CRD server has no new information to add. |
| §resp-27 | SHALL | CRD Server | exchange | Such qualifiers around when the coverage assertion is considered valid SHALL be included as part of the annotation. | |
| §resp-28 | SHALL | X | CRD Client | exchange | If a CRD client submits a claim related to an order for which it has received a coverage-information extension for the coverage type associated with the claim, that claim SHALL include the coverage-assertion-id and, if applicable, the satisfied-pa-id in the X12 837 K3 segment. |
| §resp-29 | SHALL | X | CRD Server | exchange | If multiple extension repetitions of the coverage-information extension are present, all repetitions referencing differing insurance (coverage-information.coverage) SHALL have distinct coverage-assertion-ids and satisfied-pa-ids, if present. |
| §resp-30 | MAY | X | CRD Server | exchange | Where multiple repetitions apply to the same coverage, they MAY have the same coverage-assertion-ids and satisfied-pa-ids (if present). |
| §resp-31 | MAY | CRD Client | exchange | Systems MAY make CRD calls to servers related to orders even if there is already a coverage assertion recorded on the order. | |
| §resp-32 | SHALL NOT | CRD Server | exchange | However, CRD servers SHALL NOT send a systemAction to update the order unless something is new or changed. | |
| §resp-33 | SHOULD | CRD Server | processing | CRD servers SHOULD take into account the previous decision in deciding how much processing is necessary before returning a response. | |
| §resp-34 | SHALL NOT | X | CRD Server | exchange | When returning a systemAction to update a resource with the "Coverage Information" response type, the resource content SHALL NOT make changes to any data elements other than adding or modifying coverage-information extensions. |
| §resp-35 | SHOULD | X | CRD Server | exchange | If a coverage-information extension indicates the need to collect additional information (via 'doc-needed'), the extension SHOULD include a reference to the questionnaire(s) to be completed. |
| §resp-36 | SHALL | X | CRD Client | ui | When a coverage-information response type indicates that additional clinical or patient documentation is needed and the CRD client supports DTR, CRD clients SHALL ensure that clinical users have an opportunity to launch their DTR solution as part of the current workflow. |
| §resp-37 | SHOULD | CRD Client | ui | CRD clients SHOULD allow clinical users to have an opportunity to launch their DTR solution but SHOULD make it clear that the information to be captured is non-clinical. | |
| §resp-38 | SHOULD | CRD Server | exchange | The CRD server SHOULD either prompt for the additional needed information using DTR or return a coverage-information extension indicating that the patient is not covered with a reason indicating the issue (e.g. the member could not be found/resolved). | |
| §resp-39 | SHALL | X | CRD Server | exchange | If the CRD server is unable to resolve the patient, the Coverage Information SHALL indicate "not covered" with a reason code of no-member-found. |
| §resp-40 | SHALL | X | CRD Server | exchange | If the CRD is able to resolve the patient but they do not have active coverage, the Coverage Information SHALL indicate "not covered" with a reason of no-active-coverage. |
| §resp-41 | SHALL | X | CRD Client | storage ui | If a system action containing a coverage-information extension is returned, the CRD client SHALL retain that coverage-information extension and expose it as part of the Request resource in all subsequent communications with that payer, including communications made using DTR and PAS. |
| §resp-42 | SHALL | CRD Client | exchange | When using the "Coverage Information" response type, the proposed order or appointment being submitted for update SHALL comply with the required profiles | |
| §resp-43 | SHALL | CRD Client CRD Server | exchange storage | CRD clients and servers SHALL support the new CDS Hooks system action functionality to cause annotations to automatically be stored on the relevant request, appointment, etc. without any user intervention. | |
| §resp-44 | SHALL | CRD Client | ui | In this case, the discrete information propagated into the order extension SHALL be available to the user for viewing. However, this might be managed with icons, flyovers, or alternate mechanisms than traditional CDS Hooks card rendering. | |
| §resp-45 | MAY | CRD Client | exchange | CRD clients MAY be configured to not execute system actions under some circumstances, for example if the order has been cancelled or abandoned. | |
| §resp-46 | SHOULD | CRD Server | exchange | Where CRD servers need for data that was not transmitted, they SHOULD attempt to infer values from elements that are present. | |
| §resp-47 | SHOULD | CRD Server | exchange | Each suggestion SHOULD contain either a single "update" action to revise the existing proposed order; or a "delete" action for the current proposed order and a "create" action for the new proposed order. | |
| §resp-48 | SHOULD | CRD Server | exchange | The choice of "update" vs. "delete + create" SHOULD be based on how significant the change is and how relevant the other decision support on the original request will still be. | |
| §resp-49 | SHALL | CRD Server | exchange | When using the "Propose Alternate Request" response type, the proposed orders (and any associated resources) SHALL comply with the required profiles. | |
| §resp-50 | SHALL | CRD Server | exchange | When using the "Identify Additional Orders" response type, the proposed orders and any associated resources SHALL comply with the required profiles | |
| §resp-51 | SHALL NOT | CRD Server | exchange | The Request Form Completion response type **SHALL NOT** be used in place of DTR | |
| §resp-52 | MAY | CRD Server | exchange | Instead of using a card for "Request Form Completion", CRD servers MAY opt to use a systemAction. | |
| §resp-53 | SHALL | X | CRD Client | exchange | CRD clients supporting the Request Form Completion response type SHALL support both the card and systemAction approach. |
| §resp-54 | SHALL | CRD Server | exchange | When using the "Request Form Completion" response type, the resources in the card or system action SHALL comply with the required profiles | |
| §resp-55 | SHOULD | CRD Server | exchange | CRD servers SHOULD use questionnaires that are compliant with either the Argonaut questionnaire profiles (for forms to be completed within the CRD client) or the Structured Data Capture (SDC) profiles (for more sophisticated forms to be created within a SMART on FHIR app or through an external service). | |
| §resp-56 | SHOULD | CRD Client | storage | CRD clients SHOULD retain a copy of all completed forms for future reference. | |
| §resp-57 | MAY | CRD Server | exchange | Instead of using a card for "Update Coverage Records", CRD servers MAY opt to use a systemAction instead. | |
| §resp-58 | SHALL | CRD Client | exchange | CRD clients supporting the Update Coverage Records response type SHALL support both the card and system action approach. | |
| §resp-59 | MAY | X | CRD Client | processing | If receiving a system action, a CRD client MAY opt to place the updated record in a holding area for human review rather than directly modifying their source of truth. |
| §resp-60 | SHALL NOT | CRD Server | exchange | This Update Coverage Records capability SHALL NOT be used in situations where regulation dictates the use of the X12 functionality. | |
| §resp-61 | SHOULD NOT | X | CRD Server | exchange | If returning a card rather than a system action, the "Update Coverage Records" response type SHOULD NOT be returned for hook types that are likely to be triggered by clinical users rather than administrative staff. Cards of this type would be appropriate for hooks such as encounter-start or appointment-book but would not be appropriate for order-select or order-sign. |
| §sec-1 | SHALL | CRD Client CRD Server | exchange | Implementers SHALL adhere to inherited security and privacy rules | |
| §sec-2 | SHALL | CRD Client CRD Server | exchange | As per the CDS Hooks specification, communications between CRD clients and CRD servers SHALL use TLS. | |
| §sec-3 | SHOULD | CRD Client CRD Server | exchange | CRD servers and CRD clients SHOULD enforce a minimum version and other TLS configuration requirements based on HRex rules for PHI exchange. | |
| §sec-4 | SHALL | X | CRD Client | exchange | CRD clients that support the Launch SMART Application Response Type SHALL support running applications that adhere to the SMART on FHIR confidential app profile. |
| §sec-5 | SHALL | CRD Server | processing | CRD servers SHALL use information received solely for coverage determination and decision support purposes. | |
| §sec-6 | SHALL NOT | CRD Server | storage | Servers SHALL NOT retain data received over the CRD interfaces for any purpose other than audit or providing context for form completion using DTR. | |
| §sec-7 | SHALL | CRD Client | processing | CRD clients SHALL ensure that the resource identifiers exposed over the CRD interface are distinct from and have no determinable relationship with any business identifiers associated with those records. | |
| §sec-8 | SHOULD | CRD Client Organization | business | CRD client organizations SHOULD audit access to check for reasonableness and appropriateness. | |
| §sec-9 | SHOULD NOT | CRD Client Organization | processing | Access tokens provided as part of CRD calls **SHOULD NOT** be forwarded to systems that are not managed by the same organization or have business associate agreements that allow centralized audit of access. |
IG © 2019+ HL7 International / Financial Management.
Package hl7.fhir.us.davinci-crd#2.2.0-snapshot based on FHIR 4.0.1.
Generated
2026-01-30
Links: Table of Contents |
QA Report
| Version History |
|
Propose a change