Da Vinci Risk Adjustment Implementation Guide
1.0.0 - STU 1 US

This page is part of the Da Vinci Risk Adjustment FHIR Implementation Guide (v1.0.0: STU 1) based on FHIR R4. This is the current published version in its permanent home (it will always be available at this URL). For a full list of available versions, see the Directory of published versions

Guidance

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 release of the implementation guide specifies standardized risk adjustment coding gap reports and defines an operation for a Client to query the coding gap reports from a Server 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.

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 implementation guide:
    • Exchanges are limited to mutually agreed upon (i.e., between the Server and Client) patient lists or population.
    • Security and privacy should follow Security and Privacy guidance specified in the Da Vinci Health Record Exchange (HRex) Implementation Guide.
    • Systems should use standard authentication and authorization approaches. The SMART App Launch and SMART backend services authentication/authorization approach are recommended models.

$Report Operation and Risk Adjustment Coding Gap Report

The risk adjustment coding gap reports are generated by a Server’s back end systems such as legacy system, FHIR server, and risk adjustment engine. The Risk Adjustment Coding Gap Report, a profile of the MeasureReport resource, provides a standardized representation to construct these reports. The $report operation defined in this implementation guide can be used by a Client to request risk adjustment coding gap reports of applicable risk adjustment models for one or more patients (a Group) from the Server.

$Report Operation

The $report operation requires three input (IN) parameters: subject, periodStart, and periodEnd. The subject parameter references either a single patient or a group of patients (as specified in the Patient Group profile). The term clinical evaluation period refers to the time period during which the risk adjusting encounters could be conducted and documented with expectations of submissions for risk adjustment purposes. The periodStart and periodEnd parameters are the start and end dates of the clinical evaluation period.

If the subject is valid, the dates provided in periodStart and periodEnd will then be evaluated for any overlaps against the clinical evaluation period (MeasureReport.period.start and MeasureReport.period.end) of risk adjustment coding gap reports available on the Server for that patient. The $report operation returns a Risk Adjustment Coding Gap Report Bundle if matching risk adjustment coding gap reports were found for a patient. This bundle is a FHIR collection bundle, which must contain a patient (US Core Patient) entry and zero or more entries of risk adjustment coding gap reports (Risk Adjustment Coding Gap Report). All risk adjustment coding gap reports contained in a Risk Adjustment Coding Gap Report Bundle must be for the same patient. The $report operation also defines another output (OUT) parameter, OperationOutcome, to address scenarios when the subject provided is invalid. The $report operation will always return one Parameters whether the subject is a single patient or a group of patients. Risk Adjustment Coding Gap Report Bundle for a patient is in a Parameters.parameter element. A Risk Adjustment Coding Gap Report Bundle contains the Risk Adjustment Coding Gap Reports for the same patient. For example, if a Group has 10 valid patients, then a Parameters will contain 10 Parameters.parameter elements, with each Parameters.parameter for a unique patient. Detailed documentation and conformance statements are listed on the page for $report.

An example workflow of a Client calls the $report operation to request risk adjustment coding gap reports for a single patient is shown below in Figure 3-1.

Figure 3-1 Report Operation Workflow for a Single Patient
risk-adjustment-coding-gap-report-single-patient.png

Risk Adjustment Coding Gap Report

The Risk Adjustment Coding Gap Report is used to represent coding gap report for a single patient and a version specific risk adjustment model. The required MeasureReport.subject references US Core Patient and the required MeasureReport.measure element references the Risk Adjustment Model Measure. The Risk Adjustment Model Measure profile specifies risk adjustment model information, which requires both a model identifier and a version. If the Server’s risk adjustment engine runs multiple risk adjustment models including different versions of the same model, then there will be multiple risk adjustment coding gap reports for a patient. For example, if a risk adjustment engine runs reports using CMS-HCC V25, CMS-HCC V24, and Rx-HCC V5, then there will be three separate risk adjustment coding gap reports for the patient, each for a version specific risk adjustment model.

The MeasureReport resource has zero to many group elements. Each group element contains information for a Condition Category (CC), therefore, each MeasureReport may contain multiple Condition Category (CC) codes. The group.code is used to represent the actual code for a Condition Category (CC), such as HCC 18 (Diabetes with No Complication). The Risk Adjustment Coding Gap Report profile added several extensions to the MeasureReport resource’s group element to provide additional information about a Condition Category (CC), which includes:

  • the suspect type for a Condition Category (CC) coding gap that is either historic, suspected, or unsuspected;
  • the evidence status of a Condition Category (CC) coding gap that is either closed-gap, open-gap, or pending;
  • the evidence status date indicating when the evidence status was changed to either closed-gap, open-gap, or pending; and
  • the hierarchical status indicating whether hierarchies were applied to a Condition Category (CC), and if applied, whether the Condition Category (CC) is superseded. The status can be either applied-superseded, applied-not-superseded, not-applied, or not-applicable.

In addition, the Risk Adjustment Coding Gap Report provides capability of sharing supporting evidence for a Condition Category (CC) through the use of the MeasureReport.evaluatedResource element. This supporting evidence may include resources for data such as encounters, lab results, medications, and procedures, and the evaluatedResource shall reference the appropriate US Core profile. The extension ra-groupReference added to the evaluatedResource element enables tying a specific supporting evidence to a Condition Category (CC). This is accomplished by setting the extension’s valueString to be the same value of the MeasureGroup.group.id of the Condition Category (CC) to establish the association between a supporting evidence and one or more Condition Categories.

Example Risk Adjustment Coding Gaps Report

Figure 3-2 is an example risk adjustment coding gap report. The Client calls the $report operation for patient Eve Everywoman (subject) and for a clinical evaluation period from January 1, 2021 to December 31, 2021 (periodStart and periodEnd). The Server receives the request and finds a matching risk adjustment coding gap report for Eve Everywoman that has a clinical evaluation period of January 1, 2021 to September 30, 2021, which overlaps the periodStart and periodEnd dates provided in the $report operation. This report was created by a backend risk adjustment engine on October 18th, 2021 using the risk adjustment model CMS-HCC V24. As shown in this example report, Eve Everywoman has five Hierarchical Condition Categories (HCCs). Three of the HCCs are historic diagnoses and two are suspected diagnoses. For example, one of the historic diagnoses is HCC 18 (Diabetes with no Complications). The status of this coding gap is shown as closed and the evidence status date is April 1, 2021. The supporting evidence field shows the clinical data that was used to close the coding gap HCC 18.

Figure 3-2 Example Risk Adjustment Coding Gap Report
report-risk-adjustment.png

Resources and Profiles

The following resources and their profiles specified in this implementation guide are used to support sharing risk adjustment coding gap reports from Server to Client:

Resource Type Profile Name Link to Profile
Bundle Risk Adjustment Coding Gap Report Bundle Profile Risk Adjustment Coding Gap Report Bundle
Group Patient Group Profile Patient Group
MeasureReport Risk Adjustment Coding Gap Report Profile Risk Adjustment Coding Gap Report
Measure Risk Adjustment Model Measure Profile Risk Adjustment Model Measure

Figure 3-3 provides a graphical view of how these resources are related to the example report above. The main resource is the Risk Adjustment Coding Gap Report profile. This coding gap report references a Risk Adjustment Model Measure, which indicates CMS-HCC V24 is the risk adjustment model this report is based on. The coding gap report also references the Patient (US Core Patient) as well as the Organization (US Core Organization) that generated the report. The graph shows three groups within a Risk Adjustment Coding Gap Report using three example HCCs from Figure 3-2 to illustrate each group corresponds to an HCC including its attributes.

Figure 3-3 Resource Graph for Risk Adjustment Coding Gap Report
report-risk-adjustment-resource-graph.png

Usage

Request Risk Adjustment Coding Gap Report

GET [base]/MeasureReport/$report

Examples

Scenario:

A provider requested a risk adjustment coding gap report for patient, ra-patient01, to see if the patient has any risk adjustment coding gaps for the clinical evaluation period from 2021-01-01 to 2021-09-30.

GET Risk Adjustment Coding Gaps Report

GET [base]/MeasureReport/$report?subject=Patient/ra-patient01&periodStart=2021-01-01&periodEnd=2021-09-30

Request body

(Note that request body is not applicable in this example)

Response

HTTP/1.1 200
Date: Tues, 16 November 2021 01:02:06 GMT
Content-Type: application/fhir+json;charset=UTF-8
...Other Headers...

{
  "resourceType" : "Bundle",
  "id" : "ra-bundle01",
  "meta" : {
    "profile" : [
      "http://hl7.org/fhir/us/davinci-ra/StructureDefinition/ra-measurereport-bundle"
    ]
  },
  "identifier" : {
    "system" : "urn:ietf:rfc:3986",
    "value" : "urn:uuid:8d3e72d9-9d74-4cbb-b797-a1cab0d13492"
  },
  "type" : "collection",
  "entry" : [
    {
      "fullUrl" : "https://ra-sandbox.alphora.com/cqf-ruler-r4/fhir/MeasureReport/ra-measurereport01",
      "resource" : {
        "resourceType" : "MeasureReport",
        "id" : "ra-measurereport01",
        "meta" : {
          "profile" : [
            "http://hl7.org/fhir/us/davinci-ra/StructureDefinition/ra-measurereport"
          ]
        },
        "status" : "complete",
  "type" : "individual",
  "measure" : "https://build.fhir.org/ig/HL7/davinci-ra/Measure-RAModelExample01",
  "subject" : {
    "reference" : "Patient/ra-patient01"
  },
  "date" : "2021-10-18",
  "reporter" : {
    "reference" : "Organization/ra-payer01"
  },
  "period" : {
    "start" : "2021-01-01",
    "end" : "2021-09-30"
  },
  "group" : [
    {
      "id" : "group-001",
      "extension" : [
        {
          "url" : "http://hl7.org/fhir/us/davinci-ra/StructureDefinition/ra-suspectType",
          "valueCodeableConcept" : {
            "coding" : [
              {
                "system" : "http://hl7.org/fhir/us/davinci-ra/CodeSystem/suspect-type",
                "code" : "historic"
              }
            ]
          }
        },

      ...

}

Bulk data request for Risk Adjustment Coding Gap Reports

If Clients are requesting risk adjustment coding gap reports for many patients, they may consider using the FHIR Asynchronous Request Patterns for the Bulk Data exchange operation.

GET [base]/MeasureReport/$report

Examples

Scenario:

The Client would like to request risk adjustment coding gap reports on many patients. They have created a FHIR Group resource using the Risk Adjustment Patient Group profile with the id of ra-group123. Because they expect the creation of the reports to take a while and many FHIR bundles will be returned and be processed, they would like to make the request in an asynchronous manner returning NDJSON that will be easier for them to process.

The request below asks for Group id of ra-group123 to be run asynchronously with FHIR+ndjson as the output format. The header portions should be entered in the API client header section. For example, in the Postman tool, enter “Prefer” in Key and “respond-async” in Value as an entry in the Headers tab.

GET Risk Adjustment Coding Gap Report Using Bulk Data

Run $report operation in an asynchronous mode:

GET [base]/MeasureReport/$report?subject=Group/ra-group123&periodStart=2021-01-01&periodEnd=2021-12-31

Headers:

  • Prefer respond-async
  • Accept application/fhir+json

Note that both Prefer and Accept are required. Prefer specifies the response is immediate or asynchronous, which SHALL be set to respond-async. Accept specifies the format of the optional OperationOutcome response to the kick-off request. Any of the Serialization Format Representations are supported. See the base FHIR specification Asynchronous Request Patterns for details.

Query Parameters:

  • _outputFormat (string, optional, defaults to application/fhir+ndjson)

Currently, only application/fhir+ndjson is supported.

Post Risk Adjustment Coding Gap Report

POST [base]/bundle

Examples

Scenario:

A payer posts a risk adjustment coding gap report for patient, ra-patient01, to let the provider know if the patient has any risk adjustment coding gaps for the clinical evaluation period from 2021-01-01 to 2021-09-30.

POST Risk Adjustment Coding Gaps Report

POST [base]/bundle/ra-bundle01

Request body

{
    "resourceType": "Bundle",
    "id": "ra-bundle01",
    "meta": {
        "profile": [
            "http://hl7.org/fhir/us/davinci-ra/StructureDefinition/ra-measurereport-bundle"
        ]
    },
    "identifier": {
        "system": "urn:ietf:rfc:3986",
        "value": "urn:uuid:8d3e72d9-9d74-4cbb-b797-a1cab0d13492"
    },
    "type": "collection",
    "timestamp": "2021-11-16T06:17:58.172+00:00",
    "entry": [
        {
            "fullUrl": "https://ra-sandbox.alphora.com/cqf-ruler-r4/fhir/MeasureReport/ra-measurereport01",
            "resource": {
                "resourceType": "MeasureReport",
                "id": "ra-measurereport01",
                "meta": {
                    "profile": [
                        "http://hl7.org/fhir/us/davinci-ra/StructureDefinition/ra-measurereport"
                    ]
                },
                ...

Response

HTTP/1.1 200 ok

Attribution

Member attribution establishes associations between providers and payers. The process of establishing and exchanging patient lists for risk adjustment coding gap report 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 - Risk Based Contracts Member Attribution (ATR) List IG.

Must Support

Certain elements in the profiles defined in this implementation guide are marked as Must Support. This flag is used to indicate that the element plays a critical role in defining and sharing risk adjustment coding gaps, and implementations SHALL understand and process the element.

This implementation guide uses US Core profiles where appropriate, therefore, the implications of the Must Support flag for US Core profiles must also be considered.

For more information, see the definition of Must Support in the base FHIR specification.

Dependencies

This implementation guide relies on the following specifications: