Risk Adjustment Data Marts

Risk adjustment analytics are exposed via flattened, query-friendly views derived from the underlying FHIR MeasureReport resources and the clinical data behind them. The views are published through the VBC Risk Snowflake listing and refresh once a day. See Accessing the VBC Risk listing below for how to add it to your Snowflake account, and Migrating from the public preview schema at the end of this page if you query the ZUS_VBC_INSIGHTS_PUBLIC_PREVIEW schema today.

Every view has a builder_id where the row belongs to a builder, so a parent account can tell its sub-builders apart. Rows are filtered to the builders your account is allowed to see.

Accessing the VBC Risk listing

The views are delivered as a Snowflake private listing named VBC Risk, separate from the FHIR Core listing that carries your relational FHIR data. It is granted per Snowflake account on request, so it does not appear until Zus adds your account.

Before you start

• Your organization needs its own Snowflake account on the Business Critical edition with a signed BAA with Snowflake. If you reach Zus data another way, such as a Zus-hosted reader account, ask your account manager about VBC Risk availability.
• Ask your Zus account manager to add your account to the listing. Send the same details used for the FHIR Core listing: Snowflake region, account locator, organization name, and account name. The Access via Snowflake (private listing) page shows where to find them.
• Accepting a listing requires ACCOUNTADMIN or a role that can accept shares and create databases from listings.

Accepting the listing

1. In Snowsight, open Data Products and then Private Sharing (labelled Data Sharing > External Sharing in some accounts).
2. Find the VBC Risk listing from Zus Health and click Get.
3. Choose a database name. The examples on this page use VBC_RISK.
4. Grant the database to the roles that will query it:

GRANT IMPORTED PRIVILEGES ON DATABASE VBC_RISK TO ROLE <role_name>;

In some regions the first acceptance takes about ten minutes while Snowflake starts replication.

Using the views

All eight views are in the PUBLIC schema of the database you created. Column descriptions are stored as Snowflake comments, so the data dictionary is available in Snowsight and with DESCRIBE VIEW.

SHOW VIEWS IN SCHEMA VBC_RISK.PUBLIC;
DESCRIBE VIEW VBC_RISK.PUBLIC.RISK_GAP;

SELECT builder_id, gap_type, COUNT(*) AS gaps
FROM VBC_RISK.PUBLIC.RISK_GAP
WHERE reporting_year = 2026
  AND gap_status = 'open-gap'
  AND NOT is_acute
  AND superseded_by_risk_gap_id IS NULL
GROUP BY builder_id, gap_type;

A few things to know:

• Rows are filtered for you. Every view returns only the builders your Snowflake account is entitled to, so there is no builder filter to apply unless you want a subset. A builder added to your account appears after the next daily refresh.
• The views refresh once a day. They are rebuilt from the Zus platform each morning US time. A listing is a live reference, not a copy, so you see each refresh as soon as it completes with no re-acceptance.
• The views are the contract. Zus keeps the names and columns stable and may add columns without notice. Select columns by name rather than SELECT * in anything that depends on column order.

The listing contains eight views:

Risk Gap Views

risk_gap

One row per CMS-HCC v28 individual risk gap (MeasureReport), with its current status, HCC reference data, supersession, evidence counts, payer closure, latest encounter diagnoses and user review activity. Count gaps here, never off a join to risk_gap_evidence.

Identity and classification

Evidence

Latest encounter diagnoses

The latest encounter diagnosis (a Condition with LOINC category 29308-4) in the gap's evaluated evidence, split by who owns it. First-party means your builder owns the Condition; third-party means another builder does.

Review activity

Timestamps

risk_gap_status

One row per status update event per risk gap (full history). The most recent value is also on risk_gap.gap_status.

risk_gap_hierarchy

Represents superseding relationships between gaps based on HCC hierarchy. Each superseded gap links to the nearest superseding gap for the same patient and period, so a chain of three gaps appears as two links. The same link is also on risk_gap.superseded_by_risk_gap_id.

risk_gap_diagnosis_code

Normalized mapping of ICD-10 codes to risk gaps (one row per ICD-10 per gap).

risk_gap_evidence

Normalized mapping from risk gaps to evidence resources. Clinical evidence (evaluated) means a Zus process used the resource to identify the gap, such as a Condition or Claim showing a previous diagnosis. Related resources (related) are context expected to be useful when evaluating the gap, such as a recent A1c for a diabetes gap, and may support or refute it.

Linking back to FHIR

You can construct a direct FHIR reference from resource_type and resource_id:

https://api.zusapi.com/fhir/{resource_type}/{resource_id}

The latest_*_encounter_diagnosis_condition_id columns on risk_gap resolve the same way, at /fhir/Condition/{id}.

RAF Score Views

patient_raf_score

One row per patient, builder, and measurement period, calculated by the risk gap calculator and published from the resulting RAF Score MeasureReport. All three scores use the CMS-HCC v28 community model (CNA) with the patient's demographic factors and differ only in which gaps' HCCs they count.

Patient Views

patient_detail

One row per patient, builder, and reporting year, for every patient with a risk gap or RAF score that year. The data flags, suspecting run, and appointments are per person, matched on upid. Gap counts and RAF are not here: join risk_gap and patient_raf_score.

Payer Risk Gap Views

payer_risk_gap

Payer-provided evidence of a risk gap. Payers return risk adjustment data describing which diagnoses and encounters are eligible as risk gaps. Customers standardize that data as CSV and provide it to Zus, which matches it to a patient, deduplicates it, and stores it as a MeasureReport.

Migrating from the public preview schema

Before the VBC Risk listing, risk views were published in the ZUS_VBC_INSIGHTS_PUBLIC_PREVIEW schema alongside the relational FHIR data. The preview schema stays in place for a migration period after the listing is generally available, and Zus will announce its retirement date in advance. Plan to move queries over before then.

The listing is not a rename. Views were dropped, renamed, and widened, and a few columns changed type. The sections below cover what to change.

What moved where

Replacements for dropped columns and views

• Source attribution (risk_gap_source, and sources on risk_gap_diagnosis_code). Use risk_gap_status, whose source column records which system produced each status change: zus-rules, zus-ai, payer-gap, claim-file, risk-diagnoses, or user-update. The earliest status row for a gap is the system that created it. For "did payer data close this gap", use risk_gap.closed_from_payer_data_at directly.
• First-party versus third-party evidence (has_third_party_source on risk_gap_evidence and risk_gap_diagnosis_code). risk_gap_evidence.has_first_party_source is kept and now resolves ownership from the resource itself, including the raw resources behind a lens summary. Third-party is has_first_party_source = FALSE; NULL means the owner could not be resolved. For counts, risk_gap carries first_party_clinical_evidence_count, third_party_clinical_evidence_count, and payer_evidence_count, so most queries no longer need the evidence view at all.
• Encounter diagnosis dates (recorded_date on risk_gap_diagnosis_code). risk_gap carries latest_first_party_encounter_diagnosis_recorded_at and latest_third_party_encounter_diagnosis_recorded_at, each with the Condition ID behind it, and the third-party row also names the provider and organization. These are per gap rather than per ICD-10 code.
• RAF estimates (raf_score_v28, raf_score_v24). Use patient_raf_score, which is the calculator's own score. potential_raf_score - actual_raf_score replaces raf_gap. There is no v24 equivalent; the listing is CMS-HCC v28 only. For HCC counts, count distinct code_hcc on risk_gap with the status filter you need.
• Deleted gaps (risk_gap_archive). Not available. A gap that disappears from risk_gap between refreshes was removed by recalculation.

Query changes

• Qualified names. ODS_EXPORTS.ZUS_VBC_INSIGHTS_PUBLIC_PREVIEW.RISK_GAP becomes <your database>.PUBLIC.RISK_GAP.
• Top-level gaps. The preview required an anti-join to risk_gap_hierarchy. Use superseded_by_risk_gap_id IS NULL on risk_gap instead.
• Year filtering. period_start is still a string, but reporting_year is an integer, so WHERE reporting_year = 2026 replaces WHERE period_start = '2026-01-01'.
• Recapture flag. Compare payer_reported_recapture_flag to TRUE and FALSE, not to '1' and '0'.

Before, on the preview:

SELECT g.id, g.code_hcc, g.gap_status
FROM ODS_EXPORTS.ZUS_VBC_INSIGHTS_PUBLIC_PREVIEW.RISK_GAP g
WHERE g.period_start = '2026-01-01'
  AND g.gap_status = 'open-gap'
  AND NOT EXISTS (
    SELECT 1 FROM ODS_EXPORTS.ZUS_VBC_INSIGHTS_PUBLIC_PREVIEW.RISK_GAP_HIERARCHY h
    WHERE h.risk_gap_id = g.id
  );

After, on the listing:

SELECT id, code_hcc, hcc_description, gap_status
FROM VBC_RISK.PUBLIC.RISK_GAP
WHERE reporting_year = 2026
  AND gap_status = 'open-gap'
  AND superseded_by_risk_gap_id IS NULL;