Da Vinci - Coverage Requirements Discovery
2.2.1 - STU 2.2

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.1 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.1 | Highlight text changes?
Standards status: Trial-use Active as of 2026-03-26 | 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:

- CRDCoverageAssertionReasons
- CRDCoverageDetailCodes
- CRDConformanceStatementCategories

Properties

This code system defines the following properties for its concepts

Name | Code | URI | Type
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:

Lvl | Code | Display | Definition | Not 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).