Da Vinci Risk Adjustment Implementation Guide, published by HL7 International / Clinical Quality Information. This guide is not an authorized publication; it is the continuous build for version 3.0.0-ballot built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/HL7/davinci-ra/ and changes regularly. See the Directory of published versions

Use Cases

Page standards status: Trial-use

Highlight text changes?

Introduction

The Da Vinci Project member organizations have identified the need of standardizing how risk adjustment coding gaps are communicated between payers and providers. This implementation guide (IG) specifies standardized risk adjustment coding gap reports and provides guidance to query the coding gap reports from a Payer for one or more patients. Standardizing the reporting structure helps lessen the burden on the providers in processing the reports so they can more easily address the patients’ care needs. This standardized structure also supports the Payer sharing information that they have but the providers may not, such as data from other providers’ claims, lab results, filled prescriptions, etc.

This IG also provides mechanisms enabling the feedback loop from Provider to Payer. Providers may add a Condition Category Remark(s) to the Risk Adjustment Coding Gap Report to indicate that they took some action(s) for a specific coding gap on the report and communicates that back to the Payer. However, if the Provider identifies a coding gap that is on the report needs to be closed or invalidated based on medical record review, this feedback process is done using the Risk Adjustment Data Exchange MeasureReport, which allows the Provider to send the supporting clinical evaluation evidence to the Payer. This feedback loop is important for achieving the goal of improving the accuracy and completeness of risk adjustment.

Preconditions and Assumptions

• A contract for medical services exists between the Server and the Client requesting the Risk Adjustment Coding Gap Reports.
• Risk Adjustment Coding Gap Reports are pre-generated on the Server by a backend system such as a risk adjustment engine for risk adjustment model(s).
• It is the responsibility of the Server to ensure that the data used in the report is present in a structured and retrievable form.
• The Server and the Client have agreed upon a process to identify specific patient(s) and exchange the Patient resource's logical id or the Patient Group resource's logical id.
• Although the exact mechanisms for securing these exchanges are not specified as part of this IG:
  • Exchanges are limited to mutually agreed upon (i.e., between the Server and the Client) patient lists or population.
  • Security and privacy should follow Security and Privacy guidance specified in the Da Vinci Health Record Exchange (HRex) IG.
  • Systems should use standard authentication and authorization approaches. The SMART App Launch and SMART backend services authentication/authorization approach are recommended models.

Risk Adjustment Lifecycle and Workflow Overview

Figure 2.1-1 shows a high level overview of the risk adjustment workflow, which consists of three main phases: Report Generation, Report Query, and Submit Data to Payer. Detailed guidance for each phase is provided on a separate page under the Methodology section.

Report Generation

For a complete introduction and background to Report Generation, please visit Report Generation Introduction and Background. Report generation describes two different approaches to generate a Risk Adjustment Coding Gap Report, which are referred to as Assisted and Generated in this IG.

• Assisted: A non-FHIR approach. The Payer uses their existing processes, such as SQL, SAS, and object-oriented languages, to generate a comma-separated values (CSV) file with tuples of patient and risk adjustment data. The Payer uses a non-FHIR RESTful API to populate a Risk Adjustment Coding Gap Report based on data in the CSV file. A REST server then POSTs the generated MeasureReports to the FHIR server. A standardized CSV header that could be used by this approach is defined in this IG. This approach will not contain evaluatedResources in a MeasureReport.
• Generated: Mostly a non-FHIR approach. The Payer generates a FHIR Risk Adjustment Coding Gap Report and evaluates resources based on data from traditional risk adjustment coding gap reports. These traditional reports are generated by their existing processes using patient data and risk adjustment data produced by risk adjustment engines. A REST server then POSTs the generated MeasureReports to the FHIR server.

You will find more details on the two approaches at Report Generation Approaches.

Report Query

The Client can query the Risk Adjustment Coding Gap Report once they are generated. For example, the Payer acting as the Reporting Client can query reports based on search parameters and POST them to the Provider server. See the Report Query page for details and guidance.

Report Condition Category Remark

Once the queried Risk Adjustment Coding Gap MeasureReports have been sent to the intended recipient, it can be filtered as defined by the EMR and their configuration options to ensure that only germane coding gaps (e.g., HCC gaps) are made available to providers. The Provider (or a software program acting on behalf of the Provider) determines whether the coding gap is currently valid, and whether the requested encounter data evidence exists to close the gap.

At that time, if the Provider wants to note the action they took regarding a Risk Adjustment coding gap, they can add that comment to the Risk Adjustment Coding Gap Report using the Condition Category Remark extension and return it to the Payer. This process is called Condition Category Remark.

Note: The Condition Category Remark extension is not intended to change the status of a Condition Category gap. To change the coding gap status, follow the Submit Data to Payer section of this guidance. Note that both a Condition Category remark and Submit Data to Payer can be generated at the time the Provider sees the patient if that is appropriate.

Submit Data to Payer

To return clinical data, the Provider will use the Risk Adjustment Data Exchange MeasureReport and FHIR Resful API to submit data to Payer. The Payer will then be able to use the provided patient data to update the data in their system that will be included on their next coding gap report generation.

See the Submit Data to Payer page for more details and guidance.

Pre-Visit and Encounter-Time Risk Adjustment

This section describes how a provider and payer can use the $risk-gap operation to support proactive clinical gap closure during a patient’s upcoming visit.

In this example use case, patient A is establishing care with a new primary care physician (PCP). Patient A has a scheduled appointment approximately one month from today. The clinic and payer exchange information related to potential risk conditions before and during the visit, enabling accurate and timely assessment.

• Pre-Visit Initialization: en days prior to the appointment, the Electronic Medical Record (EMR) system initiates a Risk Adjustment request API to the payer, which is the $risk-gap. The request includes a unique event identifier, the contextId that’s provided in the HTTP header of the operation, as part of the pre-visit workflow for the upcoming encounter. The payer responds with current risk gaps and suspected conditions, returning the same unique event identifier for linkage by using the Context Id extension of the Risk Adjustment Coding Gap Report profile.
• Pre-Visit Chart Review: The clinic has a partnership with a third-party vendor to conduct pre-visit chart reviews on their behalf. A clinical nurse reviews past medical records and documents additional information related to Patient A’s Sarcoidosis condition, noting historical pulmonology visits and previous fills of associated medications. This pre-visit activity enhances the completeness of clinical data for accurate risk capture.
• Appointment Preparation: One to two days before the visit, the PCP nurse prepares the upcoming visit in the system. The system transitions the appointment into a forthcoming Encounter resource. A subsequent Risk Adjustment request, using the $risk-gap operation, may be sent to the payer. The API call maintains the same unique event identifier (via contextId) sent in the first $risk-gap API call since it is related to the same event/visit. Current/updated risk gaps, conditions, and corresponding information are returned in the API response, allowing the care team to address pending items during the encounter. Insurance eligibility is also verified as part of the preparation.
• Day of Visit: During the appointment, the PCP reviews Patient A’s conditions, assess the patient, and documents clinical findings in the patient’s record. Risk gaps are actively addressed as part of routine care.
• Feedback on Conditions: Following the assessment, the EMR system will send a feedback API communicating actions taken on the condition to the payer, by adding condition category remark (see Add Remark to Condition Category) to a Risk Adjustment Coding Gap Report. The gap report contains the same unique identifier (contextId) for the event.

Payer can utilize the unique identifier for the event to track/tie together when a request was received, date of the event, when PCP took an action on the condition.

By maintaining a consistent unique event identifier across pre-visit, encounter-time, and feedback transactions, this information can be used to monitor providers adoption rate, timing of assessing the condition, and determining incentive payments.

The overarching goal is to encourage providers to assess the condition when they are seeing the patient, versus waiting until the last couple months of the year. This real-time exchange supports higher accuracy in risk adjustment, more complete clinical documentation, and improved care coordination.

Attribution

Member attribution establishes associations between providers and payers. The process of establishing and exchanging patient lists for risk adjustment coding gap reports is not in the scope of this implementation guide. One possible way of exchanging Member Attribution Lists between providers and payers is described in the Da Vinci - Member Attribution (ATR) List implementation guide.

Actors and Roles

Different entities can play different Roles in different scenarios. The Actors in this implementation guide are Payer and Provider. Their roles as Client and Server are described below.

Client:

• Reporting Client
  • Payer plays this role when they request a Risk Adjustment Coding Gap Report to POST to Provider's FHIR Server
  • Provider plays this role 1) when they request a Risk Adjustment Coding Gap Report, or 2) when they add a Condition Category Remark to a Risk Adjustment Coding Gap Report
• Data Submission Client
  • Provider plays this role when they create a Risk Adjustment Data Exchange MeasureReport and submit to Payer

Server:

• Reporting Server
  • The Payer plays this role when they 1) generate and store a Risk Adjustment Coding Gap Report, or 2) when they add Condition Category remark to the Risk Adjustment Coding Gap Report, if the Payer chooses to share any or all Condition Category remarks submitted by the Provider
  • The Payer plays this role when they receive and process the Risk Adjustment Data Exchange MeasureReport
• Data Submission Server
  • The Provider plays this role when they POST Risk Adjustment Coding Gap Report with Condition Category Remark(s)

The Methodology section of this implementation guide describes these Actors in more detail in the context of report generation, report query, and data submission steps of risk adjustment lifecycle and adding of Condition Category remarks to the Risk Adjustment Coding Gap report.