Generated Narrative: Requirements fromNarrative These requirements apply to the following actors: CRD Server CRD Server Organization CRD Client Organization CRD Client billopt-1 SHALL 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 CRD servers SHALL NOT depend on the billing-options extension being present in order to provide a response. billopt-3 SHALL, MAY 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 clients SHALL support at least one of the three specified versions of US Core. conf-2 SHALL CRD servers SHALL be able to handle all three US Core versions. conf-3 SHALL 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 servers SHALL leverage mustSupport elements as available and appropriate to provide decision support. conf-5 SHALL CRD servers SHALL populate mustSupport elements if an appropriate value exists. conf-6 SHALL 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 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 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 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 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 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 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 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 implementing organizations SHALL NOT publish guidance setting expectations for where certain data elements are conveyed within CRD and inherited data structures covinfo-1 SHOULD The union of the scoping elements in each coverage-information repetition SHOULD be disjoint. covinfo-2 SHOULD 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 servers SHALL declare at least one supported CRD version for each supported hook. dev-2 SHALL If the services endpoint can handle multiple CRD versions, it SHALL declare all versions it supports. dev-3 SHALL, MAY The requestedVersion extension SHALL be present if the service indicates it supports multiple versions for that hook, but MAY be present always. Each configuration option SHALL include four mandatory elements. SHALL Each configuration option SHALL include four mandatory elements: A code that will be used when setting configuration during hook invocation, and has an (extensible) binding to the CRD Response Types ValueSet. A data type for the parameter. At present, allowed values are "boolean" and "integer". (NOTE: These are the JSON data types and not the FHIR data types.) A display name for the configuration option to appear in the client's user interface when performing configuration. A description providing a 1-2 sentence description of the effect of the configuration option. A default value SHALL also be provided to show users what to expect when an override is not specified. dev-5 SHALL 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 Guidance can be given about allowed combinations in descriptions, but CRD servers SHALL gracefully handle disallowed/nonsensical combinations. dev-7 SHALL 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 Configuration codes, names, and descriptions SHALL be unique within a CDS Service definition. dev-9 SHOULD 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 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 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 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 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 Servers SHALL behave in the manner prescribed by any supported configuration information received from the CRD Client. dev-15 SHALL NOT 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 Clients MAY send configuration information that CRD Servers do not support. dev-17 SHALL CRD Servers SHALL ignore unsupported configuration information. dev-19 SHOULD 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 the CRD server SHALL query to determine if the client has a copy of the Questionnaire before sending the request. dev-21 SHALL 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 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 CRD client to point to the id assigned by the client when performing the 'create'. dev-23 SHALL CRD Clients SHALL perform 'creates' in an order that ensures that referenced resources are created prior to referencing resources. dev-24 SHALL 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 As well, cards SHOULD include the associated-resource extension to allow computable linkage. dev-26 SHALL 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 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 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 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 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 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 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 servers and CRD clients MAY mutually agree to support additional hooks, additional card patterns, additional resources, additional extensions, etc. not found in this specification. found-2 SHALL CRD servers SHALL return responses for all supported hooks and SHALL respond within the required time 90% of the time. found-3 MAY 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 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 soliciting the identified additional information via DTR. found-5 SHOULD 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 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 SHOULD Where a CRD client opts to not block users from proceeding for responses that come back in a period of time longer than the target time window in this guide (i.e., 5s or 10s), the client SHOULD ensure that users are made aware of the information when it is available. found-8 MAY 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-9 SHALL 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-10 SHOULD Also, coverage and authorization guidance SHOULD allow for possible variances in coding and submission. found-11 SHALL CRD servers SHALL retain all coverage guidance provided and take into account answers provided via CRD (and DTR) when subsequently adjudicating claims. found-12 SHOULD 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-13 SHALL CRD servers SHALL ensure that CDS Hooks return only messages and information relevant and useful to the intended recipient. found-14 SHALL 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-15 SHALL If a CRD server does not support endpoint discovery, they SHALL expose only one CRD endpoint capable of handling all coverages. found-16 SHOULD 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-17 SHOULD If a CRD client encounters an error when invoking a hook, they SHOULD re-run the discovery process before failing. found-18 MAY 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-19 SHOULD Once plans are in the national directory, CRD clients SHOULD include that plan identifier to uniquely identify a plan. found-20 SHALL 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-21 SHALL 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-22 SHOULD 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-23 SHALL CRD Clients SHALL be able to parse and execute prefetches that use the simple FHIRPath approach and not fail if that syntax is present. found-24 SHALL For this release of the IG, conformant CRD clients and servers SHALL support the CDS Hooks prefetch capability. found-25 SHALL Clients SHALL be able to supply the information listed in the bullets above via prefetch for the request resources they support when data exists using the search parameters and FHIRPath expressions covered in the standard prefetch section below. This includes the ability to fetch subsets of the specified queries. found-26 MAY They MAY include more and/or less prefetch requests than described in 'standard' prefetch section below, based on which data is desired. found-27 SHOULD Prefetch requests SHOULD only include information that is always expected to be needed for each hook invocation. found-28 SHOULD When information is only needed for certain invocations of the hook (e.g., for specific types of medications or services), that information SHOULD only be retrieved by query using the provided token, not requested universally via prefetch. found-29 SHALL Servers SHALL use prefetch expressions in the manner described below if those data elements are relevant to their coverage determination or other decision support. found-30 SHOULD-NOT CRD client implementations SHOULD NOT depend on standardized prefetch key names or a specific ordering of search filters. found-31 SHALL CRD clients SHALL inspect the CDS Hooks discovery endpoint to determine exact prefetch key names and queries. found-32 SHALL NOT 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 clients and servers SHALL ignore unexpected elements when processing instances. found-34 SHALL CRD servers SHALL provide what coverage requirements they can based on the information available. found-35 SHALL, SHOULD, MAY In the specific case of order-based hooks, "what if" SHOULD use the Order Sign hook but SHALL pass the unsolicited-determ configuration option with a value of 'false' to prevent 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 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 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 Organizations SHALL have processes to ensure logs can be accessed by appropriate authorized users to help resolve discrepancies or issues in a timely manner. found-39 SHOULD 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 Conformant systems SHOULD omit non-significant whitespace in transmitted instances for performance reasons. hook-1 SHALL 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 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 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 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 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 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 clients SHALL allow hook invocation to occur transparently as part of user workflow. hook-8 SHALL NOT 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 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 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 The CRD Client MAY display to the user that the Coverage Requirements Discovery Service is unavailable. hook-12 MAY If additional information (e.g. number to call) is available, it MAY also be included in the message to the user. CRD Servers SHALL use the 400 and 422 codes in a manner consistent with the FHIR RESTful Create Action SHALL, SHOULD While any 4xx or 5xx response code could be raised, the CRD Server SHALL use the 400 and 422 codes in a manner consistent with the FHIR RESTful Create Action, specifically: 400 - Bad Request - The request is not parsable as JSON or the content fails validation against FHIR core or CDS Hooks specification rules. Also used if a CRD server receives a call where the primary Coverage (either provided by prefetch or queried by the payer) does not have a payer.identifier that identifies a payer that is handled by that CRD server endpoint, the server SHALL return a 400 error and SHOULD provide an OperationOutcome. This includes situations where no Coverage is accessible, multiple Coverages are accessible, or the provided Coverage does not have a payer.identifier at all. 422 - Unprocessable Entity - The request is valid JSON and meets FHIR and CDS Hook validation rules, but fails to adhere to constraints imposed by this specification. hook-14 MAY 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 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 Unless reporting an error or coverage information already exists and there is no new information, CRD Servers SHALL include a Coverage Information system action in the response 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 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 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 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 The body of hook invocations SHALL conform to the [CRD CDSHooks Request logical model. Additionally, profiles are provided in a table for the hook sections below. hook-21 SHALL CRD clients SHALL ensure that data included in the hook invocation complies with the listed profiles. hook-22 SHALL NOT CRD servers SHALL NOT depend on data not covered by the identified profiles in order to return valid coverage-information responses. hook-23 SHALL CRD Servers SHALL handle unrecognized context elements by ignoring them. hook-24 SHALL The 'context' field in invocations of the appointment-book hook SHALL conform to the logical model specified here hook-25 MAY 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 SHALL 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-27 SHALL The 'context' field in invocations of the encounter-start hook SHALL conform to the logical model specified here hook-28 MAY CRD Servers MAY use the encounter-start hook as a basis for associating a patient with a particular practitioner from a payer attribution perspective. hook-29 SHALL The 'context' field in invocations of the encounter-discharge hook SHALL conform to the logical model specified here hook-30 SHOULD 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-31 SHALL The 'context' field in invocations of the order-dispatch hook SHALL conform to the logical model specified here hook-32 MAY 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-33 SHALL 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-34 SHOULD 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-35 SHALL The 'context' field in invocations of the order-select hook SHALL conform to the logical model specified here hook-36 MAY 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-37 SHALL The 'context' field in invocations of the order-sign hook SHALL conform to the logical model specified here hook-38 MAY CRD Servers MAY use the order-sign hook as a basis for associating a patient with a particular practitioner from a payer attribution perspective. hook-39 SHALL 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 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 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 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 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 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 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 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 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 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. 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. SHALL 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 when invoking the following CDS Hooks: order-select order-sign order-dispatch prof-4 SHALL CRD Clients SHALL use the CRD Coverage profile to resolve references to insurance Coverage resources passed to CRD Servers. prof-5 SHALL CRD Clients SHALL use the CRD Device profile to resolve references to Device resources passed to CRD Servers. 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. SHALL 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 when invoking the following CDS Hooks: order-select order-sign order-dispatch CRD Clients SHALL use the CRD Encounter profile to resolve references to Encounter resources passed to CRD Servers, including encounterId context references. SHALL CRD Clients SHALL use the CRD Encounter profile to resolve references to Encounter resources passed to CRD Servers, including encounterId context references when invoking the following CDS Hooks: appointment-book encounter-start encounter-discharge order-select order-sign order-dispatch prof-8 SHALL CRD Clients SHALL use the CRD Location profile to resolve references to insurance Location resources passed to CRD Servers. 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 SHALL 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 when invoking the following CDS Hooks: order-select order-sign order-dispatch 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. SHALL 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 when invoking the following CDS Hooks: order-select order-sign order-dispatch 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. SHALL 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 when invoking the following CDS Hooks: order-select order-sign order-dispatch 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. SHALL 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 when invoking the following CDS Hooks: order-select order-sign order-dispatch prof-13 SHALL 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 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). prof-15 SHOULD CRD servers SHOULD start sending the ActReason codes in parallel with the CRD-specific codes once they are available to ease transition in future releases when the CRD value set will be deprecated and eventually retired. resp-1 SHOULD The Card.indicator SHOULD be populated from the perspective of the clinical decision maker, not the payer resp-2 SHOULD Most Coverage Requirements SHOULD be marked as 'info'. resp-3 SHALL All Card.suggestion elements SHALL populate the Suggestion.uuid element. resp-4 SHALL 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 Card.source.topic SHALL be populated, and has an extensible binding to the ValueSet CRD Response Types. resp-6 SHOULD Card.summary SHOULD provide actionable information. resp-7 SHOULD 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 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 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 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 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 Where systemActions are used, CRD servers SHOULD NOT return equivalent information in a card for user display. resp-13 SHALL All CRD responses SHALL comply with the general profile found here. resp-14 SHALL Conformant CRD clients and services SHALL support the Coverage Information response type. resp-15 SHOULD Conformant CRD clients and services SHOULD support the additional (non-coverage information) types defined by this guide. resp-16 SHOULD 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-17 SHALL NOT 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-18 SHALL The card SHALL have at least one Card.link. resp-19 SHALL The Link.type SHALL have a type of "absolute". resp-20 SHOULD When reasonable, an "External Reference" card SHOULD contain a summary of the actionable information from the external reference in the detail element. resp-21 SHOULD 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-22 SHALL External Reference responses SHALL comply with the logical model profile found here. resp-23 SHALL NOT 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-24 SHALL Instructions responses SHALL comply with the logical model profile found here. resp-25 SHALL NOT Regardless of the content, this "Coverage Information" response type SHALL NOT use a card. resp-26 SHALL CRD servers SHALL support supplying coverage information for all primary hooks: order-sign, order-dispatch, and appointment-book. resp-27 MAY CRD servers MAY support supplying coverage information for all other (non-primary) hooks. resp-28 SHALL 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-29 SHALL 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-30 SHALL Such qualifiers around when the coverage assertion is considered valid SHALL be included as part of the annotation. resp-31 SHALL 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 in the form of a FHIR ServiceRequest or other Request resource with an embedded coverage-information extension as an attachment to the X12 837 submission and, if applicable, the satisfied-pa-id in the X12 837 REF-Prior Authorization segment. resp-32 SHALL 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-33 MAY Where multiple repetitions apply to the same coverage, they MAY have the same coverage-assertion-ids and satisfied-pa-ids (if present). resp-34 MAY Systems MAY make CRD calls to servers related to orders even if there is already a coverage assertion recorded on the order. resp-35 SHALL NOT However, CRD servers SHALL NOT send a systemAction to update the order unless something is new or changed. resp-36 SHOULD CRD servers SHOULD take into account the previous decision in deciding how much processing is necessary before returning a response. resp-37 SHALL NOT 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-38 SHOULD 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-39 SHOULD CRD Servers SHOULD access information via the FHIR Rest API as part of CRD and only fall back to data capture via DTR when computable access is not possible. resp-40 SHALL 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-41 SHOULD 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-42 SHOULD 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-43 SHALL If the CRD server encounters technical issues that prevent it from determining a coverage, prior auth, or documentation requirement response (e.g. due to internal communication issues, authorization failure, temporary unavailability of the CRD client's FHIR API, etc.), it SHALL indicate "indeterminate" in the appropriate element with a reason code of technical and additional details in the reason.text. resp-44 SHALL If the CRD server is unable to resolve the patient for a reason other than technology failure, the Coverage Information SHALL indicate "not-covered" in 'coverage' with a reason code of no-member-found. resp-45 SHALL If the CRD server is able to resolve the patient but they do not have active coverage or cannot resolve to a single coverage, the Coverage Information SHALL indicate "not-covered" with a reason of either coverage-not-found or no-active-coverage, as appropriate. resp-46 SHALL 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. When using the "Coverage Information" response type, the proposed order or appointment being submitted for update SHALL comply with the required profiles SHALL When using the "Coverage Information" response type, the proposed order or appointment being submitted SHALL comply with the following profiles: profile-appointment-with-order profile-appointment-no-order profile-devicerequest profile-medicationrequest profile-nutritionorder profile-servicerequest profile-visionprescription resp-48 SHALL 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-49 SHALL 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-50 MAY CRD clients MAY be configured to not execute system actions under some circumstances, for example if the order has been cancelled or abandoned. resp-51 SHOULD Where CRD servers need data that was not transmitted, they SHOULD attempt to infer values from elements that are present. resp-52 SHALL Coverage Information responses SHALL comply with the logical model profile found here. resp-53 SHOULD 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-54 SHOULD 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. When using the "Propose Alternate Request" response type, the proposed orders (and any associated resources) SHALL comply with the required profiles. SHALL When using the "Propose Alternate Request" response type, the proposed orders (and any associated resources) SHALL comply with the following profiles: profile-device profile-devicerequest profile-encounter† us-core-medication profile-medicationrequest profile-nutritionorder profile-servicerequest profile-visionprescription † Only used if updating an Encounter (e.g., to add a note) resp-56 SHALL Alternate Request responses SHALL comply with the logical model profile found here. When using the "Identify Additional Orders" response type, the proposed orders and any associated resources SHALL comply with the required profiles SHALL When using the "Identify Additional Orders" response type, the proposed orders and any associated resources SHALL comply with the following profiles: profile-communicationrequest profile-device profile-devicerequest us-core-medication profile-medicationrequest profile-nutritionorder profile-servicerequest profile-visionprescription resp-58 SHALL Additional Orders responses SHALL comply with the logical model profile= found here. The Request Form Completion response type **SHALL NOT** be used in place of DTR SHALL NOT The Request Form Completion response type SHALL NOT be used if: DTR is applicable to the use case (i.e. the form relates to prior auth, claim submission, appropriate use, or order fulfillment), DTR is supported by the CRD client (whether voluntarily or as required by regulation), and DTR is available from the server (e.g. not temporarily unavailable or not supported by a payer not subject to regulation). resp-60 MAY Instead of using a card for "Request Form Completion", CRD servers MAY opt to use a systemAction. resp-61 SHALL CRD clients supporting the Request Form Completion response type SHALL support both the card and systemAction approach. When using the "Request Form Completion" response type, the resources in the card or system action SHALL comply with the required profiles SHALL When using the "Request Form Completion" response type, the resources in the card or system action SHALL comply with the following profiles: profile-taskquestionnaire resp-63 SHOULD 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-64 SHOULD CRD clients SHOULD retain a copy of all completed forms for future reference. resp-65 SHALL Form Completion responses SHALL comply with the logical model profile found here. resp-66 MAY Instead of using a card for "Update Coverage Records", CRD servers MAY opt to use a systemAction instead. resp-67 SHALL CRD clients supporting the Update Coverage Records response type SHALL support both the card and system action approach. resp-68 MAY 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-69 SHALL NOT This Update Coverage Records capability SHALL NOT be used in situations where regulation dictates the use of the X12 functionality. resp-70 SHOULD-NOT 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. resp-71 SHALL Adjust Coverage responses SHALL comply with the logical model profile found here. resp-72 SHALL Launch SMART responses SHALL comply with the logical model profile found here. Implementers SHALL adhere to inherited security and privacy rules SHALL Implementers SHALL adhere to any security and privacy rules defined by: FHIR Core: Security & Privacy Module, Security Principles and Implementer's Checklist HRex: Privacy & Security CDS Hooks: Security & Safety SMART on FHIR: SMART App Launch sec-2 SHALL As per the CDS Hooks specification, communications between CRD clients and CRD servers SHALL use TLS. sec-3 SHOULD 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 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 servers SHALL use information received solely for coverage determination and decision support purposes. sec-6 SHALL NOT 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 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 organizations SHOULD audit access to check for reasonableness and appropriateness. 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. SHOULD-NOT 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. Possible alternatives to token-sharing include: * Routing all requests for information through the initial endpoint system * Making use of RFC 8693 to allow the creation of 'delegate' tokens for downstream systems"
HL7 International / Financial Management
Conformance statements found throughout the narrative of the IG consolidated into this computable resource for traceability purposes
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).
CRD servers **SHALL NOT** depend on the billing-options extension being present in order to provide a response.
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.
CRD clients **SHALL** support at least one of the three specified versions of US Core.
CRD servers **SHALL** be able to handle all three US Core versions.
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.
CRD servers **SHALL** leverage mustSupport elements as available and appropriate to provide decision support.
CRD servers **SHALL** populate mustSupport elements if an appropriate value exists.
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.
When preparing [Coverage Information](StructureDefinition-ext-coverage-information.html) 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.
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.
When preparing [response types](cards.html) other than Coverage Information, CRD servers **SHOULD** limit themselves to the same resource instances and data elements as permitted above for Coverage Information responses.
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.
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.
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.
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.
CRD implementing organizations **SHALL NOT** publish guidance setting expectations for where certain data elements are conveyed within CRD and inherited data structures
The union of the scoping elements in each coverage-information repetition **SHOULD** be disjoint.
If there are multiple reason repetitions, each repetition **SHOULD** make clear exactly what aspect of the coverage information assertion the reason applies to.
CRD servers **SHALL** declare at least one supported CRD version for each supported hook.
If the services endpoint can handle multiple CRD versions, it **SHALL** declare all versions it supports.
The requestedVersion extension **SHALL** be present if the service indicates it supports multiple versions for that hook, but **MAY** be present always.
Each configuration option SHALL include four mandatory elements.
* Each configuration option **SHALL** include four mandatory elements: * A `code` that will be used when setting configuration during hook invocation, and has an ([extensible](http://www.hl7.org/fhir/terminologies.html#extensible)) binding to the [CRD Response Types](ValueSet-cardType.html) ValueSet. * A data `type` for the parameter. At present, allowed values are "boolean" and "integer". (NOTE: These are the JSON data types and not the FHIR data types.) * A display `name` for the configuration option to appear in the client's user interface when performing configuration. * A `description` providing a 1-2 sentence description of the effect of the configuration option. * A `default` value **SHALL** also be provided to show users what to expect when an override is not specified.
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-cardType.html) 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).
Guidance can be given about allowed combinations in descriptions, but CRD servers **SHALL** gracefully handle disallowed/nonsensical combinations.
Configuration codes **SHALL** be valid JSON property names and **SHALL** come from the [CRD Response Types](ValueSet-cardType.html) list if an applicable type is in that list.
Configuration codes, names, and descriptions **SHALL** be unique within a [CDS Service](http://cds-hooks.hl7.org/2026Jan/index.html#response) definition.
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.
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.
CRD Clients **SHOULD** expose configuration options through a configuration screen to allow users and/or system administrators to control the types of information returned.
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.
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.
CRD Servers **SHALL** behave in the manner prescribed by any supported configuration information received from the CRD Client.
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).
CRD Clients **MAY** send configuration information that CRD Servers do not support.
CRD Servers **SHALL** ignore unsupported configuration information.
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
the CRD server **SHALL** query to determine if the client has a copy of the Questionnaire before sending the request.
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](http://hl7.org/fhir/R4/http.html#trules).
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 CRD client to point to the `id` assigned by the client when performing the 'create'.
CRD Clients **SHALL** perform 'creates' in an order that ensures that referenced resources are created prior to referencing resources.
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.
As well, cards **SHOULD** include the associated-resource extension to allow computable linkage.
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').
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.
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.
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.
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.
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.
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.
CRD servers and CRD clients **MAY** mutually agree to support additional hooks, additional card patterns, additional resources, additional extensions, etc. not found in this specification.
CRD servers **SHALL** return responses for all supported hooks and **SHALL** respond within the required time 90% of the time.
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.
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 soliciting the identified additional information via DTR.
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.
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.
Where a CRD client opts to not block users from proceeding for responses that come back in a period of time longer than the target time window in this guide (i.e., 5s or 10s), the client **SHOULD** ensure that users are made aware of the information when it is available.
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.
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).
Also, coverage and authorization guidance **SHOULD** allow for possible variances in coding and submission.
CRD servers **SHALL** retain all coverage guidance provided and take into account answers provided via CRD (and DTR) when subsequently adjudicating claims.
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.
CRD servers **SHALL** ensure that CDS Hooks return only messages and information relevant and useful to the intended recipient.
If a CRD server supports [endpoint discovery](http://hl7.org/fhir/us/davinci-hrex/1.2.0/endpoint-discovery.html), they **SHALL** have at most a single endpoint for each coverage (e.g., Medicare, Medicaid, or commercial) they provide coverage under.
If a CRD server does not support endpoint discovery, they **SHALL** expose only one CRD endpoint capable of handling all coverages.
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.
If a CRD client encounters an error when invoking a hook, they **SHOULD** re-run the discovery process before failing.
CRD clients and servers **MAY** leverage the [payer registry](http://hl7.org/fhir/us/davinci-pdex-plan-net) developed by PDex (which will eventually fold into the [national directory under FAST](https://confluence.hl7.org/display/FAST/National+Healthcare+Directory)) as a means of determining which endpoints exist for which payers as candidates for configuration.
Once plans are in the national directory, CRD clients **SHOULD** include that plan identifier to uniquely identify a plan.
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.
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.
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.
CRD Clients **SHALL** be able to parse and execute prefetches that use the simple FHIRPath approach and not fail if that syntax is present.
For this release of the IG, conformant CRD clients and servers **SHALL** support the CDS Hooks prefetch capability.
Clients **SHALL** be able to supply the information listed in the bullets above via prefetch for the request resources they support when data exists using the search parameters and FHIRPath expressions covered in the [standard prefetch](foundation.html#standard-prefetch) section below. This includes the ability to fetch subsets of the specified queries.
They **MAY** include more and/or less prefetch requests than described in 'standard' prefetch section below, based on which data is desired.
Prefetch requests **SHOULD** only include information that is always expected to be needed for each hook invocation.
When information is only needed for certain invocations of the hook (e.g., for specific types of medications or services), that information **SHOULD** only be retrieved by query using the provided token, not requested universally via prefetch.
Servers **SHALL** use prefetch expressions in the manner described below if those data elements are relevant to their coverage determination or other decision support.
CRD client implementations **SHOULD NOT** depend on standardized prefetch key names or a specific ordering of search filters.
CRD clients **SHALL** inspect the CDS Hooks discovery endpoint to determine exact prefetch key names and queries.
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.
CRD clients and servers **SHALL** ignore unexpected elements when processing instances.
CRD servers **SHALL** provide what coverage requirements they can based on the information available.
In the specific case of order-based hooks, "what if" **SHOULD** use the Order Sign hook but **SHALL** pass the [unsolicited-determ](ValueSet-cardType.html#expansion) configuration option with a value of 'false' to prevent 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).
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.
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.
Organizations **SHALL** have processes to ensure logs can be accessed by appropriate authorized users to help resolve discrepancies or issues in a timely manner.
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.
Conformant systems **SHOULD** omit non-significant whitespace in transmitted instances for performance reasons.
CRD Clients conforming to this implementation guide **SHALL** be able to determine the correct payer CRD server to use for each request.
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.
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.
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](https://build.fhir.org/ig/HL7/cds-hooks-library) or custom hooks defined elsewhere.
When supporting hooks not covered by this guide, systems **SHOULD** adhere to the general conformance expectations defined in this specification for those additional hooks.
CRD clients **SHALL** allow hook invocation to occur transparently as part of user workflow.
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.
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.
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.
The CRD Client **MAY** display to the user that the Coverage Requirements Discovery Service is unavailable.
If additional information (e.g. number to call) is available, it **MAY** also be included in the message to the user.
CRD Servers SHALL use the 400 and 422 codes in a manner consistent with the FHIR RESTful Create Action
* While any 4xx or 5xx response code could be raised, the CRD Server **SHALL** use the 400 and 422 codes in a manner consistent with the FHIR RESTful Create Action, specifically: * 400 - Bad Request - The request is not parsable as JSON or the content fails validation against FHIR core or CDS Hooks specification rules. Also used if a CRD server receives a call where the primary Coverage (either provided by prefetch or queried by the payer) does not have a payer.identifier that identifies a payer that is handled by that CRD server endpoint, the server **SHALL** return a 400 error and **SHOULD** provide an OperationOutcome. This includes situations where no Coverage is accessible, multiple Coverages are accessible, or the provided Coverage does not have a payer.identifier at all. * 422 - Unprocessable Entity - The request is valid JSON and meets FHIR and CDS Hook validation rules, but fails to adhere to constraints imposed by this specification.
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.
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.
Unless reporting an error or coverage information already exists and there is no new information, CRD Servers **SHALL** include a Coverage Information system action in the response 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.
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](deviations.html#new-hook-configuration-mechanism) to instruct CRD servers to not even try to return responses if the client does not intend to display/process them.
If Coverage Information is returned for these hooks, it **SHALL NOT** include messages indicating a need for [clinical](ValueSet-AdditionalDocumentation.html) or [administrative](ValueSet-AdditionalDocumentation.html) information, as such information is expected to be made available later in the process and therefore such guidance is not useful.
The body of hook invocations **SHALL** conform to the [CRD CDSHooks Request logical model. Additionally, 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.
CRD servers **SHALL NOT** depend on data not covered by the identified profiles in order to return valid coverage-information responses.
CRD Servers **SHALL** handle unrecognized context elements by ignoring them.
The 'context' field in invocations of the appointment-book hook **SHALL** conform to the logical model specified [here](StructureDefinition-CRDAppointmentBookContext.html)
CRD Servers **MAY** use the appointment-book hook as a basis for associating a patient with a particular practitioner from a payer attribution perspective.
CRD clients and servers **SHALL**, at minimum, support returning and processing the [Coverage Information](StructureDefinition-ext-coverage-information.html) system action for all invocations of the appointment-book hook.
The 'context' field in invocations of the encounter-start hook **SHALL** conform to the logical model specified [here](http://hl7.org/fhir/tools/1.1.2/StructureDefinition-CDSHookEncounterStartContext.html)
CRD Servers **MAY** use the encounter-start hook as a basis for associating a patient with a particular practitioner from a payer attribution perspective.
The 'context' field in invocations of the encounter-discharge hook **SHALL** conform to the logical model specified [here](http://hl7.org/fhir/tools/1.1.2/StructureDefinition-CDSHookEncounterDischargeContext.html)
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.
The 'context' field in invocations of the order-dispatch hook **SHALL** conform to the logical model specified [here](StructureDefinition-CRDOrderDispatchContext.html)
CRD Servers **MAY** use the order-dispatch hook as a basis for associating a patient with a particular practitioner from a payer attribution perspective.
CRD clients and servers **SHALL**, at minimum, support returning and processing the [Coverage Information](StructureDefinition-ext-coverage-information.html) system action for all invocations of the order-dispatch hook.
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.
The 'context' field in invocations of the order-select hook **SHALL** conform to the logical model specified [here](StructureDefinition-CRDOrderSelectContext.html)
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.
The 'context' field in invocations of the order-sign hook **SHALL** conform to the logical model specified [here](StructureDefinition-CRDOrderSignContext.html)
CRD Servers **MAY** use the order-sign hook as a basis for associating a patient with a particular practitioner from a payer attribution perspective.
CRD clients and servers **SHALL**, at minimum, support returning and processing the [Coverage Information](StructureDefinition-ext-coverage-information.html) system action for all invocations of the order-select hook.
Clients that suppress 'default presumption' coverage-information of messages **SHALL** mitigate the potential for misinterpretation in the event CRD is unavailable.
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.
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.
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.
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.
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.
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.
CRD Clients **SHALL** use either this Appointment with Order profile and/or the [with-order](StructureDefinition-profile-appointment-with-order.html) to provide `appointments` context objects to CRD Servers when invoking the [appointment-book](hooks.html#appointment-book) hook as well as to [resolve other references](foundation.html#additional-data-retrieval) to Appointment resources.
CRD Clients **SHALL** use either this Appointment without Order and/or the [no-order](StructureDefinition-profile-appointment-no-order.html) to provide `appointments` context objects to CRD Servers when invoking the [appointment-book](hooks.html#appointment-book) hook as well as to [resolve other references](foundation.html#additional-data-retrieval) to Appointment resources.
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.
CRD Clients **SHALL** use the CRD CommunicationRequest profile to [resolve references](foundation.html#additional-data-retrieval) to CommunicationRequest resources passed to CRD Servers (e.g. `selections` context references) and to populate `draftOrders` context objects when invoking the following CDS Hooks: * [order-select](hooks.html#order-select) * [order-sign](hooks.html#order-sign) * [order-dispatch](hooks.html#order-dispatch)
CRD Clients **SHALL** use the CRD Coverage profile to [resolve references](foundation.html#additional-data-retrieval) to insurance Coverage resources passed to CRD Servers.
CRD Clients **SHALL** use the CRD Device profile to [resolve references](foundation.html#additional-data-retrieval) to Device resources passed to CRD Servers.
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.
CRD Clients **SHALL** use the CRD DeviceRequest profile to [resolve references](foundation.html#additional-data-retrieval) to DeviceRequest resources passed to CRD Servers (e.g. `selections` context references) and to populate `draftOrders` context objects when invoking the following CDS Hooks: * [order-select](hooks.html#order-select) * [order-sign](hooks.html#order-sign) * [order-dispatch](hooks.html#order-dispatch)
CRD Clients SHALL use the CRD Encounter profile to resolve references to Encounter resources passed to CRD Servers, including encounterId context references.
CRD Clients **SHALL** use the CRD Encounter profile to [resolve references](foundation.html#additional-data-retrieval) to Encounter resources passed to CRD Servers, including `encounterId` context references when invoking the following CDS Hooks: * [appointment-book](hooks.html#appointment-book) * [encounter-start](hooks.html#encounter-start) * [encounter-discharge](hooks.html#encounter-discharge) * [order-select](hooks.html#order-select) * [order-sign](hooks.html#order-sign) * [order-dispatch](hooks.html#order-dispatch)
CRD Clients **SHALL** use the CRD Location profile to [resolve references](foundation.html#additional-data-retrieval) to insurance Location resources passed to CRD Servers.
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
CRD Clients **SHALL** use the CRD MedicationRequest profile to [resolve references](foundation.html#additional-data-retrieval) to MedicationRequest resources passed to CRD Servers (e.g. `selections` context references) and to populate `draftOrders` context objects when invoking the following CDS Hooks: * [order-select](hooks.html#order-select) * [order-sign](hooks.html#order-sign) * [order-dispatch](hooks.html#order-dispatch)
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.
CRD Clients **SHALL** use CRD NutritionOrder profile to [resolve references](foundation.html#additional-data-retrieval) to NutritionOrder resources passed to CRD Servers (e.g. `selections` context references) and to populate `draftOrders` context objects when invoking the following CDS Hooks: * [order-select](hooks.html#order-select) * [order-sign](hooks.html#order-sign) * [order-dispatch](hooks.html#order-dispatch)
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.
CRD Clients **SHALL** use the CRD ServiceRequest profile to [resolve references](foundation.html#additional-data-retrieval) to ServiceRequest resources passed to CRD Servers (e.g. `selections` context references) and to populate `draftOrders` context objects when invoking the following CDS Hooks: * [order-select](hooks.html#order-select) * [order-sign](hooks.html#order-sign) * [order-dispatch](hooks.html#order-dispatch)
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.
CRD Clients **SHALL** use the CRD VisionPrescription profile to [resolve references](foundation.html#additional-data-retrieval) to VisionPrescription resources passed to CRD Servers (e.g. `selections` context references) and to populate `draftOrders` context objects when invoking the following CDS Hooks: * [order-select](hooks.html#order-select) * [order-sign](hooks.html#order-sign) * [order-dispatch](hooks.html#order-dispatch)
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.
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).
CRD servers **SHOULD** start sending the ActReason codes in parallel with the CRD-specific codes once they are available to ease transition in future releases when the CRD value set will be deprecated and eventually retired.
The `Card.indicator` **SHOULD** be populated from the perspective of the clinical decision maker, not the payer
Most Coverage Requirements **SHOULD** be marked as 'info'.
All `Card.suggestion` elements **SHALL** populate the Suggestion.uuid element.
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.
`Card.source.topic` **SHALL** be populated, and has an [extensible](http://www.hl7.org/fhir/terminologies.html#extensible) binding to the ValueSet [CRD Response Types](ValueSet-cardType.html).
`Card.summary` **SHOULD** provide actionable information.
`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`.
`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.
`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.
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`.
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.
Where [systemActions](http://cds-hooks.hl7.org/2026Jan/index.html#system-action) are used, CRD servers **SHOULD NOT** return equivalent information in a card for user display.
All CRD responses **SHALL** comply with the general profile found [here](StructureDefinition-CRDHooksResponseBase.html).
Conformant CRD clients and services **SHALL** support the [Coverage Information](cards.html#coverage-information-response-type) response type.
Conformant CRD clients and services **SHOULD** support the additional (non-coverage information) types defined by this guide.
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.
CRD servers **SHALL NOT** use "External Reference" cards to direct users to a portal for the purpose of initiating prior authorization or determining coverage.
The card **SHALL** have at least one `Card.link`.
The `Link.type` **SHALL** have a type of "absolute".
When reasonable, an "External Reference" card **SHOULD** contain a summary of the actionable information from the external reference in the `detail` element.
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.
External Reference responses **SHALL** comply with the logical model profile found [here](StructureDefinition-CRDHooksResponse-externalReference.html).
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](cards.html#coverage-information-response-type) response instead.
Instructions responses **SHALL** comply with the logical model profile found [here](StructureDefinition-CRDHooksResponse-instructions.html).
Regardless of the content, this "Coverage Information" response type **SHALL NOT** use a card.
CRD servers **SHALL** support supplying coverage information for all primary hooks: order-sign, order-dispatch, and appointment-book.
CRD servers **MAY** support supplying coverage information for all other (non-primary) hooks.
CRD servers **SHALL** supply coverage information for all hooks where they support it unless the EHR sends a configuration option asking them not to.
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.
Such qualifiers around when the coverage assertion is considered valid **SHALL** be included as part of the annotation.
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` in the form of a FHIR ServiceRequest or other Request resource with an embedded coverage-information extension as an attachment to the X12 837 submission and, if applicable, the satisfied-pa-id in the X12 837 REF-Prior Authorization segment.
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.
Where multiple repetitions apply to the same coverage, they **MAY** have the same coverage-assertion-ids and satisfied-pa-ids (if present).
Systems **MAY** make CRD calls to servers related to orders even if there is already a coverage assertion recorded on the order.
However, CRD servers **SHALL NOT** send a `systemAction` to update the order unless something is new or changed.
CRD servers **SHOULD** take into account the previous decision in deciding how much processing is necessary before returning a response.
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.
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.
CRD Servers **SHOULD** access information via the FHIR Rest API as part of CRD and only fall back to data capture via DTR when computable access is not possible.
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.
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.
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).
If the CRD server encounters technical issues that prevent it from determining a coverage, prior auth, or documentation requirement response (e.g. due to internal communication issues, authorization failure, temporary unavailability of the CRD client's FHIR API, etc.), it **SHALL** indicate "indeterminate" in the appropriate element with a reason code of [technical](ValueSet-coverageAssertionReasons.html#logical-definition-cld) and additional details in the reason.text.
If the CRD server is unable to resolve the patient for a reason other than technology failure, the Coverage Information **SHALL** indicate "not-covered" in 'coverage' with a reason code of [no-member-found](ValueSet-coverageAssertionReasons.html#logical-definition-cld).
If the CRD server is able to resolve the patient but they do not have active coverage or cannot resolve to a single coverage, the Coverage Information **SHALL** indicate "not-covered" with a reason of either [coverage-not-found](ValueSet-coverageAssertionReasons.html#logical-definition-cld) or [no-active-coverage](ValueSet-coverageAssertionReasons.html#logical-definition-cld), as appropriate.
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.
When using the "Coverage Information" response type, the proposed order or appointment being submitted for update SHALL comply with the required profiles
When using the "Coverage Information" response type, the proposed order or appointment being submitted **SHALL** comply with the following profiles: | | | | :--- | :--- | | [profile-appointment-with-order](StructureDefinition-profile-appointment-with-order.html) | | | [profile-appointment-no-order](StructureDefinition-profile-appointment-no-order.html) | | | [profile-devicerequest](StructureDefinition-profile-devicerequest.html) | | | [profile-medicationrequest](StructureDefinition-profile-medicationrequest.html) | | | [profile-nutritionorder](StructureDefinition-profile-nutritionorder.html) | | | [profile-servicerequest](StructureDefinition-profile-servicerequest.html) | | | [profile-visionprescription](StructureDefinition-profile-visionprescription.html) | |
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.
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.
CRD clients **MAY** be configured to not execute system actions under some circumstances, for example if the order has been cancelled or abandoned.
Where CRD servers need data that was not transmitted, they **SHOULD** attempt to infer values from elements that are present.
Coverage Information responses **SHALL** comply with the logical model profile found [here](StructureDefinition-CRDHooksResponse-coverageInformation.html).
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.
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.
When using the "Propose Alternate Request" response type, the proposed orders (and any associated resources) SHALL comply with the required profiles.
When using the "Propose Alternate Request" response type, the proposed orders (and any associated resources) **SHALL** comply with the following profiles: | | | | :--- | :--- | | [profile-device](StructureDefinition-profile-device.html) | | | [profile-devicerequest](StructureDefinition-profile-devicerequest.html) | | | [profile-encounter†](StructureDefinition-profile-encounter.html) | | | | [us-core-medication](http://hl7.org/fhir/us/core/STU6.1/StructureDefinition-us-core-medication.html) | | [profile-medicationrequest](StructureDefinition-profile-medicationrequest.html) | | | [profile-nutritionorder](StructureDefinition-profile-nutritionorder.html) | | | [profile-servicerequest](StructureDefinition-profile-servicerequest.html) | | | [profile-visionprescription](StructureDefinition-profile-visionprescription.html) | | † Only used if updating an Encounter (e.g., to add a note)
Alternate Request responses **SHALL** comply with the logical model profile found [here](StructureDefinition-CRDHooksResponse-alternateRequest.html).
When using the "Identify Additional Orders" response type, the proposed orders and any associated resources SHALL comply with the required profiles
When using the "Identify Additional Orders" response type, the proposed orders and any associated resources **SHALL** comply with the following profiles: | | | | :--- | :--- | | [profile-communicationrequest](StructureDefinition-profile-communicationrequest.html) | | | [profile-device](StructureDefinition-profile-device.html) | | | [profile-devicerequest](StructureDefinition-profile-devicerequest.html) | | | | [us-core-medication](http://hl7.org/fhir/us/core/STU6.1/StructureDefinition-us-core-medication.html) | | [profile-medicationrequest](StructureDefinition-profile-medicationrequest.html) | | | [profile-nutritionorder](StructureDefinition-profile-nutritionorder.html) | | | [profile-servicerequest](StructureDefinition-profile-servicerequest.html) | | | [profile-visionprescription](StructureDefinition-profile-visionprescription.html) | |
Additional Orders responses **SHALL** comply with the logical model profile= found [here](StructureDefinition-CRDHooksResponse-additionalOrders.html).
The Request Form Completion response type **SHALL NOT** be used in place of DTR
The Request Form Completion response type **SHALL NOT** be used if: 1. DTR is applicable to the use case (i.e. the form relates to prior auth, claim submission, appropriate use, or order fulfillment), 1. DTR is supported by the CRD client (whether voluntarily or as required by regulation), and 1. DTR is available from the server (e.g. not temporarily unavailable or not supported by a payer not subject to regulation).
Instead of using a card for "Request Form Completion", CRD servers **MAY** opt to use a [systemAction](http://cds-hooks.hl7.org/2026Jan/index.html#system-action).
CRD clients supporting the Request Form Completion response type **SHALL** support both the card and systemAction approach.
When using the "Request Form Completion" response type, the resources in the card or system action SHALL comply with the required profiles
When using the "Request Form Completion" response type, the resources in the card or system action **SHALL** comply with the following profiles: | | | | :--- | :--- | | [profile-taskquestionnaire](StructureDefinition-profile-taskquestionnaire.html) | |
CRD servers **SHOULD** use questionnaires that are compliant with either the [Argonaut questionnaire profiles](https://github.com/argonautproject/questionnaire) (for forms to be completed within the CRD client) or the [Structured Data Capture (SDC) profiles](http://hl7.org/fhir/uv/sdc/index.html) (for more sophisticated forms to be created within a SMART on FHIR app or through an external service).
CRD clients **SHOULD** retain a copy of all completed forms for future reference.
Form Completion responses **SHALL** comply with the logical model profile found [here](StructureDefinition-CRDHooksResponse-formCompletion.html).
Instead of using a card for "Update Coverage Records", CRD servers **MAY** opt to use a [systemAction](http://cds-hooks.hl7.org/2026Jan/index.html#system-action) instead.
CRD clients supporting the Update Coverage Records response type **SHALL** support both the card and system action approach.
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.
This Update Coverage Records capability **SHALL NOT** be used in situations where regulation dictates the use of the X12 functionality.
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.
Adjust Coverage responses **SHALL** comply with the logical model profile found [here](StructureDefinition-CRDHooksResponse-adjustCoverage.html).
Launch SMART responses **SHALL** comply with the logical model profile found [here](StructureDefinition-CRDHooksResponse-launchSMART.html).
Implementers SHALL adhere to inherited security and privacy rules
Implementers **SHALL** adhere to any security and privacy rules defined by: * FHIR Core: [Security & Privacy Module](http://hl7.org/fhir/R4/secpriv-module.html), [Security Principles](http://hl7.org/fhir/R4/security.html) and [Implementer's Checklist](http://hl7.org/fhir/R4/safety.html) * HRex: [Privacy & Security](http://hl7.org/fhir/us/davinci-hrex/1.2.0/security.html) * CDS Hooks: [Security & Safety](http://cds-hooks.hl7.org/2026Jan/index.html#security-and-safety) * SMART on FHIR: [SMART App Launch](http://www.hl7.org/fhir/smart-app-launch)
As per the CDS Hooks specification, communications between CRD clients and CRD servers **SHALL** use TLS.
CRD servers and CRD clients **SHOULD** enforce a minimum version and other TLS configuration requirements based on [HRex rules](http://hl7.org/fhir/us/davinci-hrex/1.2.0/security.html#exchange-security) for PHI exchange.
CRD clients that support the Launch SMART Application Response Type **SHALL** support running applications that adhere to the SMART on FHIR [confidential app](https://hl7.org/fhir/smart-app-launch/STU2.2/app-launch.html#support-for-public-and-confidential-apps) profile.
CRD servers **SHALL** use information received solely for coverage determination and decision support purposes.
Servers **SHALL NOT** retain data received over the CRD interfaces for any purpose other than audit or providing context for form completion using DTR.
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.
CRD client organizations **SHOULD** audit access to check for reasonableness and appropriateness.
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.
* 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. Possible alternatives to token-sharing include: * Routing all requests for information through the initial endpoint system * Making use of RFC 8693 to allow the creation of 'delegate' tokens for downstream systems"