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
Official URL: http://hl7.org/fhir/us/davinci-crd/ImplementationGuide/hl7.fhir.us.davinci-crd | Version: 2.1.0 | |||
IG Standards status: Trial-use | Maturity Level: 3 | Computable Name: CoverageRequirementsDiscovery |
This STU update of the specification reflects several changes based on implementer feedback about the Coverage Requirements Discovery (hereafter,CRD) specification arising from detailed review, connectathons and implementation experience. "STU notes" call out additional key considerations where feedback is desired.
This specification is a Standard for Trial Use. It is expected to continue to evolve and improve through connectathon testing and feedback from early adopters.
Feedback is welcome and may be submitted through the FHIR change tracker indicating "US Da Vinci CRD" as the specification.
This implementation guide is dependent on other specifications. Please submit any comments you have on these base specifications as follows:
- Feedback on CDS Hooks should be posted to the FHIR change tracker with "CDS Hooks" as the specification.
- Feedback on the FHIR Core specification should be submitted to the FHIR change tracker with "FHIR Core" as the specification.
- Feedback on the US Core profiles should be submitted to the FHIR change tracker with "US Core" as the specification.
Individuals interested in participating in the Coverage Requirements Discovery implementation guide project or other HL7 Da Vinci projects can find information about Da Vinci [here](http://www.hl7.org/about/davinci).
A summary of the major changes from the previous release can be found here.
The process of billing a patient’s insurance provider is complex and costly, particularly in the United States. Healthcare providers work with a range of payers who fund the products and clinical services provided to patients. Each payer and plan provides its own mix of coverages for healthcare products and services, and each has its own unique process to determine whether each service is necessary and appropriate. These processes have many different requirements for documentation, prior authorization, or other approval steps. Claims submitted for payment that do not meet payer requirements will typically be denied which may result in service delay, resubmission, or appeal. These delays and additional processes may result in negative health outcomes or financial cost for patients, as well as financial and productivity losses for providers.
This Coverage Requirements Discovery (CRD) implementation guide defines a workflow in which a payer makes coverage requirement information available to a healthcare provider within the provider’s software system at the point of care where treatment decisions are made. This will help clinicians and administrative staff make informed recommendations to their patients and meet payer submission requirements.
This implementation guide supports both Protected Health Information (PHI)-specific and non-PHI mechanisms for CRD to meet the needs and privileges of different payer organizations. These mechanisms will allow payers to share a wide variety of information with providers in a context-sensitive manner including:
This implementation guide is designed to allow for initial support of basic capabilities and to subsequently build new features over time.
The scope of this specification has increased to also support prior authorization process earlier in the workflow by allowing prior authorization to be returned during the CRD interaction. Specifically:
On Feb 28, 2024, the Office of Burden Reduction and Health Informatics (OBRHI) National Standards Group (NSG) announced an enforcement discretion that they would not enforce the requirement to use the X12 278 for prior authorization if the covered entities were using the FHIR-based Prior Authorization API as described in the CMS Interoperability and Prior Authorization final rule (CMS-0057-F). This allows payers to return a prior authorization number for use in the X12 837 in coverage extension of the CRD and DTR IGs or as part of the all FHIR exchange of the Prior Authorization Response Bundle in the PAS IG. For CRD, this specifically means that the satisfied-pa-id in the Coverage Information extension can be used as an X12 prior authorization number.
This implementation guide sets expectations for two types of systems:
CRD clients are typically systems that healthcare providers use at the point of care, including electronic medical records systems, pharmacy systems, and other provider and administrative systems used for ordering, documenting, and executing patient-related services. Users of these systems need coverage requirements information to support care planning.
Examples of potential CRD clients include EHRs, EMRs, practice management systems, scheduling systems, patient registration systems, etc.
The CRD client may actually involve multiple systems. For example, the systems that handle order entry may be different from what is used for appointment booking and different again from the system that exposes information over the FHIR interface. It is possible that a provider environment might use an intermediary to coordinate CRD client calls from multiple systems. Such an architecture is sufficient provided that:
There are three distinct sets of capabilities for CRD clients, one for USCDI v1 (US-Core 3.1.1), one for USCDI v3 (US-Core 6.1.0), and one for USCDI v4 (US-Core 7.0.0). Typically a client would support only one of these based on which US Core release it supports internally. There is a single CRD server set of capabilities which must be able to handle data from any of the three supported USCDI versions.
When CRD clients are made up of multiple systems, there will be orchestration requirements to allow each system to interact in a way that together they appear as a single monolithic system from the perspective of the CRD server. This IG provides some discussion of this on the ePA Coordinators page, though it does not yet provide any standardization about how components should interoperate to achieve the intended monolithic behavior. If there is industry interest, future releases of this IG may work to standardize some of these "intra-client" interactions.
CRD servers (or servers) are systems that act on behalf of payer organizations to share information with healthcare providers about rules and requirements related to healthcare products and services covered by a patient's health plan. A CRD server will provide coverage information related to one or more insurance plans. CRD servers are a type of CDS service as defined in the CDS Hooks Specification.
There are is a single set of capabilities for CRD servers that spans USCDI v1 (US-Core 3.1.1) USCDI v3 (US-Core 6.1.0), and USCDI v4 (US-Core 7.0.0) expectations. Payers will need to be handle content from any of the releases, as CRD clients will be transitioning support for the versions at different times - and in some cases may provide content that spans a mixture of versions.
This implementation guide (and the menu for it) is organized into the following sections:
This guide is based on the FHIR R4 specification that is mandated for use in the U.S. as well as the CDS Hooks 2.0 and CDS Hooks CI Build releases of the CDS Hooks specification. It also leverages the SMART on FHIR specification for CRD clients that opt to use that approach for "what-if" scenarios.
In addition, this guide also relies on a number of parent implementation guides:
IG | Package | FHIR | Comment |
---|---|---|---|
Da Vinci - Coverage Requirements Discovery | hl7.fhir.us.davinci-crd#2.1.0 | R4 | |
HL7 Terminology (THO) | hl7.terminology.r4#6.0.2 | R4 | Automatically added as a dependency - all IGs depend on HL7 Terminology |
FHIR Extensions Pack | hl7.fhir.uv.extensions.r4#5.1.0 | R4 | Automatically added as a dependency - all IGs depend on the HL7 Extension Pack |
US Core (Reuse Wrapper) | hl7.fhir.us.core.v311#3.1.1 | R4 | |
US Core Implementation Guide | hl7.fhir.us.core#6.1.0 | R4 | |
US Core (Reuse Wrapper) | hl7.fhir.us.core.v700#7.0.0 | R4 | |
Structured Data Capture | hl7.fhir.uv.sdc#3.0.0 | R4 | |
Da Vinci Health Record Exchange (HRex) | hl7.fhir.us.davinci-hrex#1.1.0 | R4 | |
VSAC | us.nlm.vsac#0.19.0 | R4 |
This implementation guide defines additional constraints and usage expectations above and beyond the information found in these base specifications.
This implementation guide and the underlying FHIR specification are licensed as public domain under the FHIR license. The license page also describes rules for the use of the FHIR name and logo.
This publication includes IP covered under the following statements.