Risk adjustment
Public Preview
This service is in a stage of development that may be subject to change or deprecation and may not yet be feature complete or perform consistently. Breaking changes, deprecation, or packaging changes may occur with limited advanced notice.
Accurately capturing a patient's burden of illness is critical to effective performance and operations under value-based care contracts, and also supports comprehensive clinical documentation practices.
Zus currently supports the CMS-HCC risk adjustment model for both v24 and v28. In addition to calculating risk scores and helping identify patients for outreach, Zus will be developing a point-of-care workflow for diagnosis capture.
Data Marts for population-level views
Risk scores and opportunities can be accessed via Data Marts for analysis and automation of outreach efforts to high-potential patients.
Currently, Zus relies solely on clinical data for establishing patient scores. This may result in several simplifications or assumptions that may lead to inaccurate scores. We recommend that customers interested in more fine-grained analysis invest in incorporating payer data into the ZAP to refine accuracy:
- Zus assumes that an 'encounter diagnosis' found on a network document with an encounter date within the current year is sufficient evidence of 'closure'. This does not consider the possibility of codes being changed during retrospective review, not making it onto a claim, or not being accepted by a payer. Customers interested in more refined logic should talk to the Customer Success team about payer data ingestion.
- All patients are assumed to be in the 'Community Non-Dual Aged' segment. Additional segments can be supported if a client provides reliable categorization.
- Duration of beneficiary enrollment and institutionalized status is similarly not considered.
- Zus does not yet calculate financial impact of risk adjustment.
Zus offers the risk adjustment information in the ZUS_VBC_INSIGHTS_PUBLIC_PREVIEW schema within Data Marts. This includes the following TABLE / VIEW schema (see diagram below for relationships and fields). Each set of TABLE / VIEWS has a version for v24 and v28 wherever relevant:
| TABLE / VIEW | DESCRIPTION | PURPOSE |
|---|---|---|
| RAF_SCORE_V2X | Provides a calculated RAF score and HCC count by patient, differentiating between current (in-year closed factors only) score and potential (all possible factors). | Can be used to track patient scores, identify high complexity patients, and identify patients with a high gap between current and potential (significant opportunity). |
| ALL_PATIENT_FACTORS_V2X | Unifies all contributing factors, along with their status (open v. closed) and what the coefficient is. The 'source' column specifies the type of factor. | Unified view of all of the inputs used to calculate RAF_SCORE. |
| DIAGNOSIS_FACTORS_V2X | List of all diagnosis factors, grouped by HCC. Includes classification of type (net-new, historic, suspect), underlying ICD-10's, pointers to evidence, and other supplemental diagnosis-level data. | List of the diagnosis factors commonly focused on for risk adjustment. Offers traceability of inputs into RAF score as well. |
| DIAGNOSIS_COUNT_FACTORS_V2X | An incremental coefficient based on the count of diagnoses to capture the risk driven by complex medical status. | Traceability of inputs into RAF score. |
| INTERACTION_FACTORS_V2X | If a patient has two conditions that drive increased risk due to comorbidity, those interactions will be captured. | Traceability of inputs into RAF score. |
| DEMOGRAPHIC_FACTORS | Age and sex based factors are captured here. | Traceability of inputs into RAF score. |
| RAF_SEGMENT | Defines what segment a patient is considered to be in. Today, defaults to CNA (Community Non-dual Aged) for all patients. | Drives appropriate selection of coefficients. |
Below is a diagram of the SCHEMA that illustrates all table, views, fields and relationships:
There are several fields in these views that require additional definition:
- Recorded Date:
- EARLIEST_RECORDED_DATE: This reflects the earliest date that the HCC is identified in the Zus data. It incorporates both encounter diagnoses and problem list entries as both suggest clinical evidence.
- LATEST_RECORDED_DATE: This reflects the latest recorded date that the HCC is identified in the Zus data. It incorporates both encounter diagnoses and problem list entries as both suggest clinical evidence.
- CURRENT_DIAGNOSIS_DATE: This is the first diagnosis event in the current calendar year, which drives the open v. closed logic. It only considers encounter diagnoses, as problem list entries alone do not suggest risk capture.
- CC_TYPE:
- net-new: HCC's that are newly identified in the current reporting year (calendar year) on an encounter, with no prior recording.
- historic: HCC's that are identified based on conditions that have been previously documented on an encounter diagnosis or problem list prior to the current reporting year in the Zus data.
- suspect: HCC's that are not based on structured condition data (problem list, encounter diagnosis), but rather based on other clinical evidence (e.g. lab results, medications, clinical notes, etc.)
- STATUS:
- open: HCC's that have not been diagnosed on an encounter in the current reporting year (calendar year).
- closed: HCC's that have been documented on an encounter in the current reporting year (calendar year). For DIAGNOSIS_COUNT_FACTORS and INTERACTION_FACTORS, a factor is only closed if all of the underlying DIAGNOSIS_FACTORS are closed, otherwise it is 'open'.
- CONDITION_ID: In the CONDITION_HCC table, we refer to the specific CONDITION resource underlying the latest recording event. In some cases, this might be a problem list entry.
Updated 1 day ago