This page is part of the Da Vinci Risk Adjustment FHIR Implementation Guide (v0.1.0: STU 1 Ballot 1) based on FHIR R4. The current version which supercedes this version is 1.0.0. 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 on the Server.
• 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. 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.

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, therefore, multiple Condition Category codes. The group.code is used to represent the actual code for a Condition Category, 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, which includes:

• the suspect type for a Condition Category coding gap that is either historic, suspected, or unsuspected;
• the evidence status of a Condition Category 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, and if applied, whether the Condition Category 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 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. This is accomplished by setting the extension’s valueString to be the same value of the MeasureGroup.group.id of the Condition Category 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.

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:

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 (USCore Patient) as well as the Organization (USCore 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.

Usage

GET|[base]

Click Here To See Example GET Risk Adjustment Coding Gap Report

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

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

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

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]

Click Here To See Example GET Risk Adjustment Coding Gap Report Using Bulk Data

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.

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:

• FHIR R4
• US Core STU4
• Da Vinci Data Exchange for Quality Measure (DEQM) Implementation Guide.
  • Note that the only reason that this implementation guide relies on the DEQM IG is because of the use of the DEQM reporter group extension for MeasureReport. Once the reporter group extension is promoted to the base MeasureReport resource in FHIR R5, this dependency will not longer be needed.