Da Vinci - Coverage Requirements Discovery
2.2.0 - STU 2.2 United States of America flag

Da Vinci - Coverage Requirements Discovery, published by HL7 International / Financial Management. This guide is not an authorized publication; it is the continuous build for version 2.2.0 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/HL7/davinci-crd/ and changes regularly. See the Directory of published versions

CodeSystem: CRD Temporary Codes

Official URL: http://hl7.org/fhir/us/davinci-crd/CodeSystem/temp Version: 2.2.0
Standards status: Trial-use Active as of 2026-03-04 Maturity Level: 4 Computable Name: CRDTempCodes
Other Identifiers: OID:2.16.840.1.113883.4.642.40.18.16.1

Codes temporarily defined as part of the CRD implementation guide. These will eventually migrate into an officially maintained terminology (likely either SNOMED CT or HL7's UTG code systems).

This code system contains codes that are expected to be formally proposed as codes in other 'official' code systems in the future such as LOINC, SNOMED, etc. or as part of code systems managed in http://terminology.hl7.org. The canonical URL (and possibly the codes themselves) for all codes appearing in this code system ARE expected to change in a future release. Implementers should prepare for this transition when they write their code, allowing for the possibility of checking for both the old and new code and ensuring it is straightforward to transmit both the old and new code when the time comes. Concept maps will likely be available to assist with this transition.

This Code system is referenced in the definition of the following value sets:

Properties

This code system defines the following properties for its concepts

NameCodeURIType
Not Selectable abstract http://hl7.org/fhir/concept-properties#notSelectable boolean

Concepts

This case-sensitive code system http://hl7.org/fhir/us/davinci-crd/CodeSystem/temp defines the following codes in a Is-A hierarchy:

LvlCodeDisplayDefinitionNot Selectable
1 gold-card Gold card Ordering Practitioner has been granted 'gold card' status with this payer/coverage type.
1 no-member-found Member not found The server was unable to find a matching member or was unable to resolve to a single member, so no coverage information can be provided.
1 no-active-coverage Coverage not active The referenced coverage for the member was found but is not in force during the relevant time period for which the coverage is being evaluated.
1 coverage-not-found Coverage not found The payer is not available to resolve the provided coverage information to an existing coverage record, or it is not specific enough to resolve to a single coverage.
1 auth-out-network Authorization needed out-of-network Authorization is necessary if out-of-network.
1 technical Technical issues The server encountered technical issues either internally or with their interaction with the client. It is possible these issues are transient and later calls might provide more information.
1 _limitation Limitation details Identifies detail codes that define limitations of coverage. (Category should be 'cat-limitation') true
2   allowed-quantity Maximum quantity Indicates limitations on the number of services/products allowed (possibly per time period). Value should be a Quantity
2   allowed-period Maximum allowed period Indicates the maximum period of time that can be covered in a single order. Value should be a Period
1 _decisional Decisional details Identifies detail codes that may impact patient and clinician decision making (Category should be 'cat-decisional') true
2   in-network-copay Copay for in-network Indicates a percentage co-pay to expect if delivered in-network. Value should be a Quantity.
2   out-network-copay Copay for out-of-network Indicates a percentage co-pay to expect if delivered out-of-network. Value should be a Quantity.
2   concurrent-review Concurrent review Additional payer-defined documentation will be required prior to claim payment. Value should be a boolean.
2   appropriate-use-needed Appropriate use Payer-defined appropriate use process must be invoked to determine coverage. Value should be a boolean.
1 _other Other details Identifies detail codes that are generally not relevant to clinicians/patients (Category should be 'cat-other') true
2   policy-link Policy Link A URL pointing to the specific portion of a payer policy, coverage agreement or similar authoritative document that provides a portion of the basis for the decision documented in the coverage-information. Value should be a url.
1 instructions Instructions Information to display to the user that gives guidance about what steps to take in achieving the recommended actions identified by this coverage-information (e.g. special instructions about requesting authorization, details about information needed, details about data retention, etc.). Value should be a string. (Category may vary.)
1 _cardType Card Type (abstract) A collector for different profiles on CDS Hooks card true
2   coverage-info Coverage Information Information related to the patient's coverage, including whether a service is covered, requires prior authorization, is approved without seeking prior authorization, and/or requires additional documentation or data collection
3     unsolicited-determ Unsolicited Determination An unsolicited approval of the service as having prior authorization requirements met without a formal submission of a prior authorization request
2   claim Claim Information about what steps need to be taken to submit a claim for the service
2   insurance Insurance Allows a provider to update the patient's coverage information with additional details from the payer (e.g. expiry date, coverage extensions)
2   limits Limits Messages warning about the patient approaching or exceeding their limits for a particular type of coverage or expiry date for coverage in general
2   network Network Providing information about in-network providers that could deliver the order (or in-network alternatives for an order directed out-of-network)
2   appropriate-use Appropriate Use Guidance on whether appropriate-use documentation is needed
2   cost Cost What is the anticipated cost to the patient based on their coverage
2   therapy-alternatives-opt Optional Therapy Alternatives Are there alternative therapies that have better coverage and/or are lower-cost for the patient
2   therapy-alternatives-req Required Therapy Alternatives Are there alternative therapies that must be tried first prior to coverage being available for the proposed therapy
2   clinical-reminder Clinical Reminder Reminders that a patient is due for certain screening or other therapy (based on payer recorded date of last intervention)
2   duplicate-therapy Duplicate Therapy Notice that the proposed intervention has already recently occurred with a different provider when that information is not already available in the provider system
2   contraindication Contraindication Notice that the proposed intervention may be contraindicated based on information the payer has in their record that the provider does not have in theirs
2   guideline Guideline Indication that there is a guideline available for the proposed therapy (with an option to view)
2   off-guideline Off Guideline Notice that the proposed therapy may be contrary to best-practice guidelines, typically with an option to view the relevant guideline
1 _reqcat Requirements Categories Codes that help to categorize requirements statements true
2   behavioral Behavioral Categories related to how the system behaves true
3     business Business Requirements relating to the business operations of the entities responsible for a system
3     functional Functional Requirements related to what the system does (inputs turned into outputs)
4       exchange Exchange Requirements relating to when, how, or what data is exchanged with other systems
4       processing Processing Requirements related to how data must be analyzed, transformed, considered, or otherwise used within a system
4       storage Storage Requirements related to if or how data is persisted in a system
3     non-functional Non-functional Requirements related to how the system accomplishes functional requirements
4       availability Availability Requirements related to how and when a system needs to be reachable and useable
4       ui User Interface Requirements related to how information is collected from and exposed to humans (or animals)
5         ui-accessibility UI Accessibility Requirements around user interface that ensure a satisfactory experience for users from different backgrounds or with varying physical, cognitive, and/or sensory abilities
5         ui-consistency UI Consistency Requirements around ensuring that different implementations have sufficiently aligned appearance and mechanisms of interaction
5         ui-usability UI Usability Requirements related to the intuitiveness, simplicity, and ease-of-use of a user-interface
4       security Security/Privacy Requirements that ensure that data is appropriately protected from threats and respects rules around what parties are permitted to access or manipulate
4       safety Safety Requirements that ensure that system operation does not negatively impact the wellbeing of people or assets
4       performance Performance/Scalability Requirements that deal with timeliness of processing and/or responsiveness under differing levels of load/volume
2   source Source Categories related to where the requirement came from true
3     user User Requirements Requirements originating from the community of individuals expected to use the system/solution
3     legal Legal Requirements Requirements originating from regulation or law
3     design Design Decisions Requirements documenting decisions made in the design of the solution

Description of the above table(s).