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.1.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

Change History

This page describes the primary releases of the specification and summarizes the content for each:

Release 2.1.0

• FHIR-47329, FHIR-48622 - Added support for USCDI v4 (US Core 7.0.0) and clarify language about what multi-US-Core release implementation means
• FHIR-48352 - Set mustSupport expectations for practitioner, practitionerRole and organization for multi-target relationships
• FHIR-48430 - Set clearer expectations for handling failure states
• FHIR-48559 - Make ability to bypass CRD services that are running too long a 'SHALL'
• FHIR-48560 - Make clear that clients need to constrain scopes provided to what's needed
• FHIR-48722 - Collapse the 2 Encounter profiles (USCDI 1, USCDI 3+4) into one

Release 2.1.0-preview

Significant Coverage Information changes:

• FHIR-46088 - Set MS expectations (and general expectations too)
• FHIR-46460 - Remove 'response' element
• FHIR-46089 - Tightened invariants around info-needed
• FHIR-44410 - Add support for policy links and information as qualifiers
• FHIR-45440 - Added new configuration option for 'wanting information' ServiceRequest and one not
• FHIR-44909 - Added support for additional information from patient

Significant other changes:

• FHIR-46440, FHIR-46603 - Set expectations for endpoints and endpoint discovery
• FHIR-45551 - Removed the CRD Practitioner profile (use HRex instead)
• FHIR-46254 - Define a Task profile for order-dispatch hook
• FHIR-44891 - Clarified expectations for mandatory hook support
• FHIR-46006 - Added PractitionerRole to Appointment profile
• FHIR-44527 - Corrected contexts for order-dispatch
• FHIR-46120, FHIR-43435 - Made Location.type MS and require it to be present in the hierarchy
• FHIR-46383 - Prohibit use of CRD to point to portal launch
• FHIR-43182 - Add expiration date to Coverage-Information
• FHIR-45295 - Relax expections on Request statuses to not have to be 'draft'
• FHIR-44388 - Split Appointment profile into two - one pointing to
• FHIR-45230 - Relaxed 'reason' constraints in profiles to align with US Core
• FHIR-46793 - Set expectations for CRD clients to query data when possible

A variety of minor corrections and clarifications to wording and examples.

Release 2.0.1

Corrected the embedded JSON examples to be technically correct and in line with other rules in the specification

Release 2.0.0

A number of additional changes and enhancements. Key differences are:

• Renamed the 'Annotate' card to Coverage Information and made it a system action rather than a card
• Removed the Unsolicited determination card type
• Added system action as an optional feature of the form completion and update coverage information cards
• Removed guidance on deferring card actions (as it's no longer terribly relevant for CRD and SMART now defines a mechanism)
• Added additional properties to the coverage-information extension including the ability to specify questionnaires and draft responses for DTR, authorized billing codes, dependencies on other orders, and other details.
• Removed support for 'de-identified' invocation of CRD
• Corrected ServiceRequest.location to be 0..1 instead of 1..1
• Dropped expectation for coverage information to be conveyed as part of orders
• Changed language to make clear that CRD does not provide prior authorizations
• Tightened general conformance expectations
• A few additional corrections and numerous clarifications and refinements

Release 1.1.0

Added a number of enhancements and some changes to approach. Key differences are:

• Clarified that CRD results can be returned to non-clinical users
• Highlighted the challenges of CRD data coming in a different form and set of codes than payers have traditionally dealt with
• Explicit expectations with respect to performance and accuracy of CRD Servers
• Expectations around client ability to flag sensitive orders
• Specified a starter set of codes for configuration options and mandated the appearance of those codes in cards in a new topic element
• Made support for a minimal set of configuration options mandatory
• Added an extension to link cards to requests
• Introduced the new order-dispatch hook
• Added the Annotate and Unsolicited Determination card types
• Revamped how Prefetch handles retrieving a patient's coverage information
• Provided explicit guidance around deferring card actions
• Added a section on registering DTR apps with CRD
• Updated to support CRD 2.0, which included changes to the 'topic' element within cards
• Added support for system actions and made their use mandatory for updates to orders and coverage
• Added a definition of mustSupport for this guide
• Acknowledged that CRD clients can be made up of multiple systems
• Removed constraint prohibiting [ServiceRequest.doNotPerform])(StructureDefinition-profile-servicerequest.html#profile)
• Added guidance on enabling a CRD server
• Added guidance on CRD access tokens
• Clarified expectations about controlling hook invocation
• Provided guidance on external references
• Corrected cardType codes to use the IG temporary code system, as it is likely that long-term these codes won't all live as part of the IG
• Added CapabilityStatements describing CRD client and CRD Server responsibilities

As well there were various other adjustments to specification language, profiles, and examples to align with these changes and to correct minor typos or improve wording.

Release 1.0

Initial release of the CRD specification.