Run UDS Reports

athenaCollector + athenaClinicals

This is a topic that focuses on Uniform Data System (UDS) reporting. Use this topic to learn more about locating the UDS Reports in athenOne, understanding the filters for pulling data, and running the reports.

 

 

 

To help support the UDS reporting obligation by HRSA for our FQHC clients, athenahealth developed the HRSA tables and helper reports designed to assist in pulling and reconciling your organization’s data for UDS reporting. The information and steps below will help you locate, run, and utilize these reports. The workflows differ slightly between tables that contain clinical quality measure data and tables that do not.

 

 

  1. On the Main Menu, click Reports.
  2. Click Report Library.
  3. Click the UDS tab
    Note: You must have the "UDS Admin" role to see the UDS tab.
  4. Click run next to the UDS table you're running.

Tip: Here's a quick path to remember:
From the menu bar: Reports > Report Library > UDS tab > run

 

 

Each UDS report has a similar set of options. See below to understand more about the available filters and output options.

 

 

The type of report filter determines how the data is aggregated and presented for the selected report. Below is a description of each type of report and a grid describing when to use each report type.

 

 

This is a reproduction of the UDS table in the format defined by HRSA. The data reported in this table is based on the data in the Filtered Data report.

 

 

This file format shows only UDS visits from FQHC departments. It is a de-duplicated, filtered version of the Raw Data file, where multiple claims/encounters for the same UDS visit are removed. Only the most recent qualifying UDS visit is reported (Filtered is per patient for Patients by ZIP code, Table 3A, 3B, and 4. Filtered is per visit for Table 5 and Table 5 Addendum. It’s per claim/encounter for Table 6A. It’s per charge for Table 9D) . You can’t translate the filtered data to the raw data since athenOne adds additional de-duplicating logic.

 

 

This file format presents relevant details for UDS visits, grouped up at the level of the patient. Like the Filtered Data Report View, these values will match up to the Rolled Up data. If a patient has multiple visits, we will the data as specified in HRSA‘s UDS manual (e.g. insurance as of the last visit of the year, homeless status as of the first visit where the patient reported as homeless, etc.).

 

 

This file format presents relevant details for UDS visits.

 

 

This file format presents all visit data from FQHC departments, including non-UDS visits. Since this file is unduplicated, you could see multiple rows for a single patient created during the same visit. These rows could represent claims, encounters, OB episode entries, and more. Not all these rows are always marked as UDS visits. If there is one UDS visit for the patient in that day, the patient’s data pulls into the filtered and rolled up reports.

 

Report Type What it does When to use it Applicable Tables
Rolled Up Data Presents data in the format for HRSA Reporting Use this report type to preview or pull your report for submission Patients by Zip, 3A, 3B, 4, 5, 5 Addendum, 6A, 6B, 7A, 7B, 7C, 9D
Filtered Data Presents the complete data used to produce the Rolled Up view, grouped up by whatever level of specificity HRSA requires for each table Use this report type if you prefer to roll up your own data or if you are conducting QA on the data contained within the Rolled Up view Patients by Zip, 3A, 3B, 5, 5 Addendum, 6B, 7A, 7B, 7C, 9D
Filtered by Patient Presents the complete data used to produce the Rolled Up view, grouped up at the Patient level Use this report type if you prefer to roll up your own data or if you are conducting QA on the data contained within the Rolled Up view 4, 6A
Filtered by Visit Presents relevant details at the level of the UD visit Use this report type to understand how patient characteristics such as insurance coverage update across multiple visits 4
Raw Data Presents all data from FQHC departments, including non-UDS visits Use this report type if you are conducting QA to determine discrepancies in your rolled up/filtered data Patients by Zip, 3A, 3B, 4, 5, 6A, 6B, 7A, 7B, 7C, 9D

 

 

 

Tables 3A, 3B, 4, 5, and 6A have an additional drop-down filter called “Special Population 2018+ Only”. This field allows you to filter to a specific special population for the purpose of grant reporting.

 

athenahealth provides the Special Population Characteristics UDS reporting required for 330h and 330g grantee reporting as long as the appropriate population demographic fields are activated (see the UDS Guide to Success for further details). This allows you to generate rolled up grant reports just as you would your regular UDS reports.

 

The raw data reports for these tables each contain columns that report if the patient is homeless, an agricultural worker, or public housing patient. For example, you can use the “PATIENT_HOMELESS” column to filter the report to include only data from homeless patients.

 

 

Using the date-pickers you can filter the data based on the date of service.

 

The date range drown down menu allows you to filter the data from a predetermined set of date ranges.

 

Note: if your organization’s fiscal year is set in athenOne, selecting “Year-to-Date” will return your fiscal year, rather than the calendar year.

 

 

The report year option allows you to run the UDS table reports using the specifications from prior program years. In other words, you can filter for data in any time period, but apply the program specifications from a prior program year.

 

 

The report format options allow you to view report results in your browser (HTML version) or download the results in a format that you can manipulate in excel (tab-delimited or comma-delimited).

 

 

The report options allow you to make changes to the meta information that returns in your report. Importantly, the option to run the report offline is also available in the report options section.

 

 

The UDS Visit Inclusion report allows you to audit how athenOne categorizes encounters as UDS eligible encounters. Using this report, you can understand and control what is classified as a UDS visit. The UDS Visit Inclusion report is in the Report Library UDS Tab along with all of the other UDS Table reports.

 

 

 

We classify all CPT codes in the CPT inclusions and exclusions list; any visit with a CPT code on the inclusion list counts as a UDS-eligible visit. You can use the IS_UDS flag in the report to see what we’re including or excluding. This can help you find where certain departments might be using ineligible CPT codes or understand where you might disagree with the athenOne classification. If the IS_UDS column is “Y” the visit is UDS-eligible because there is a qualifying UDS Visit or that is an STAO override that categorizes the visit as a UDS Visit. If this column is “N” it is not a UDS-eligible visit because the visit lacks a qualifying CPT code and it also lacks an STAO override that would categorize it as a UDS Visit.

 

 

If you see excluded visits that you believe should be included, you can locate those visits in the UDS Visit Inclusion report by filtering to the patient ID or to the specific claim ID or appointment ID in question. Filtering to the patient ID may be most helpful because you can easily check whether there were multiple qualifying visits of the same type on a single day. We can only count one visit per patient per visit type per day. The report will include all CPT codes tied to that visit and indicate which ones, if any, qualify the visit as UDS-eligible. If there are two visits of the same type for the same patient on the same day, they will both be flagged as UDS-eligible, but only one of the visits will appear in the report.

 

 

The report indicates the visit type, any STAO that might override the visit type, and the provider and specialty. We also include the department so that you can check for visit types that might be out of the ordinary for a department, such as medical visits at a mental-health clinic. You can then check for configuration errors in athenOne or process issues in the department.

 

 

Related Topics Link IconRelated Topics