Note that Zus Risk Adjustment features are currently in public preview and are subject to change.

Zus provides customers with the ability to upload CSV files to bulk upload payer provided information, which will appear as Payer Risk Gap MeasureReports within the Risk Gaps product.

It's important to enroll your patients before uploading Payer Risk Gap information for them. See our documentation on Enrolling your Patients for more info.

Payer Risk Gap CSV Upload Process

CSV Imports are handled through SFTP. Reach out to your Zus support representative to set up a secure SFTP connection to the Zus system.

Once an SFTP upload folder is properly mounted, uploading a properly formatted Payer Risk Gap CSV File in that folder will create corresponding Payer Risk Gap MeasureReport FHIR Resources.

Payer Risk Gap CSV File Format

All uploaded CSVs are expected to include the following columns. Each row will pass through our deduplication process to either create or update a Payer Risk Gap MeasureReport.

Column Name	Description	Example
`PATIENT_IDENTIFIER_SYSTEM`	A System URL that the customer already has for the patient. Used for Patient Matching at Import Time	`https://fhir.athena.io/sid/ah-patient`(The system value for an Athena Patient)
`PATIENT_IDENTIFIER_VALUE`	An ID that the customer has for the Patient. Expected to be usable within the PATIENT_IDENTIFIER_SYSTEM url. Used for Patient Matching at Import Time	`a-12345.E-12345` (An Athena Patient ID)
`HCC_CODE_VALUE`	The HCC code of the Payer Risk Gap	`37` (The HCC code for “Diabetes with Chronic Complications”)
`HCC_CODE_MODEL_VERSION`	The model of the given HCC code. Optional, but defaults to V28 in the final Payer Risk Gap MeasureReport if not provided.	If this column is included, this field accepts only the following value: `V28` (HCC CMS V28)
`PAYER`	Your customer specific value used for tracking which Payer that reported this gap.	`BCBS_MA` (Blue Cross Blue Shield of Massachusetts) `ACME_INSURANCE_RI` (Acme Insurance of Rhode Island)
`REPORTING_PERIOD`	The most relevant calendar year of this Payer Gap Data.	`2025`, `2026`, etc.
`GAP_STATUS`	Determines whether the payer suspects the risk gap to be open or not. This field helps inform the gap status of a patients Risk Gap Measure Report depending on the REPORTING_PERIOD, and other factors.	This field accepts only the following values: `open` The payer reported that the risk gap is open. `closed` The payer reported that the risk gap is closed.
`RECAPTURE_FLAG`	Whether the customer determined this risk gap to have already occurred from a previous reporting period. This value will only be used when calculating Risk Gaps for the current `REPORTING_PERIOD`.	This field accepts only the following values: `0`(Gap was not recaptured within the given `REPORTING_PERIOD`) `1` (Gap was recaptured within the given `REPORTING_PERIOD`)
`ICD_10_CM_CODE_VALUE`	The ICD-10-CM Code of the contributing factor, needed for ICD-10 code attribution. This is expected to correlate to the given `HCC_CODE_VALUE`.	This field is converted into a common ICD-10-CM format. `E11319`- This will be converted to E11.319 in the final resource `E11.319`- This will be unadjusted and remain E11.319 in the final resource `E11` - This will be unadjusted and remain E11 in the final resource
`LAST_CLAIM_DATE`	The date that the ICD-10 code last appeared on a claim (or your closest approximation). For example: The Payer AETNA might provide you a full date, so you provide the entire date. The Payer BCBS only provides the last year that the ICD-10 appeared, so you approximate based on your company policy (e.g. use on the month/date that you processed the file from BCBS and provide that full date value).	Expected to be a date string in YYYY-MM-DD format: `2023-12-31` `2026-01-1`
`REASON`	Human readable string describing the evidence behind the payer gap.	`At least 1 risk adjustable visit. Last observed 2 years ago.` `15 risk adjustable visits. Last observed 20SEP2024` `Payer file submitted with no other reason given`

Payer Risk Gap Deduplication Process

During CSV import, we do not create a new Payer Risk Gap Measure Report for a patient if we have previously received similar data. This is true whether we receive similar rows of data in the current CSV file or across multiple CSV file uploads.

The following details are combined into a unique fingerprint for our Payer Risk Gap Data:

The Patient ID associated with the MeasureReport (Determined through Patient Matching).
The HCC Code (HCC_CODE_VALUE and HCC_CODE_MODEL_VERSION columns)
ICD-10-CM code (ICD_10_CM_CODE_VALUE column)
The Reporting Period (REPORTING_PERIOD column)
The Payer (PAYER column)

If a previous Payer Risk Gap MeasureReport for a patient was created with these same values, the existing Measure Report will be updated with the remaining data (e.g. REASON or GAP_STATUS). Similarly, a new Payer Risk Gap MeasureReport will be created if we do NOT have an existing Measure Report with these same values.

Patient Matching at Import Time

Before creating or updating a Payer Risk Gap Measure Report in our CSV pipeline, we require that a Patient record exists in the current builder that matches the PATIENT_IDENTIFIER_SYSTEM and PATIENT_IDENTIFIER_VALUE.

For example, if you have uploaded a CSV with a row that has the values

https://fhir.athena.io/sid/ah-patient for PATIENT_IDENTIFIER_SYSTEM
a-12345.E-12345 and PATIENT_IDENTIFIER_VALUE

Then a Patient FHIR record is expected to exist in your builder with a similar Identifier:

{
  "id": "[uuid]",
  "identifier": [{
     "system": "https://fhir.athena.io/sid/ah-patient",
		 "value": "a-12345.E-12345" 
  },
  ... other identifiers
  ],
  ... additional Patient Data
}

If there is no Patient in your builder with that identifier, then no Payer Risk Gap Measure Report will be created for that row.

Please see our docs about Enrolling your Patients for more information.