Counting Services for Table 6A
Each row in the “Selected Services Rendered” section of Table 6A uses one of two approaches for visit and patient counts. Most rows use Billing and Diagnosis Codes linked to a visit, while a few rows use Data Elements.
Rows using Billing and Diagnosis Codes
For these rows, visits are counted when they include one of the billing or diagnosis codes indicated in the UDS manual and listed on-screen in Relevant’s UDS module.
How can we count services that aren’t billed or don’t use these codes?
For various reasons, health centers may provide certain services—such as Covid tests, Pap tests, or flu shots—but not attach the specified billing or diagnosis codes to the visit in question. The most frequent reason this occurs is when a health center performs these services but does not bill for them. Several workarounds are possible to ensure these services are counted.
Use standard codes with $0 charge. The primary recommendation in the UDS manual is to attach the correct billing code to the visit in the EHR, while adjusting the EHR configuration so the code in question reports a $0 charge. Making this fix in the EHR means that no additional work is required in Relevant’s UDS module.
Add dummy codes in the EHR. If health centers use custom or “dummy” codes to document certain procedures, the UDS manual suggests that such codes may also be counted in a variety of conditions. You can add and edit these custom codes in Relevant, as pictured below. Note: users must have the “Manage Reports” ability to configure these custom billing codes.
Insert dummy codes in Relevant. If it’s too late to configure the EHR with zero-charge or dummy codes, it may still be possible to work these corrections into Relevant’s data warehouse. If the data resides somewhere else in the EHR (for instance, in a lab report), the fix involves adjusting the mapping of the Visit Billing Codes Data Element in order to attach the zero-charge or dummy code to the visit in question. Please contact your Relevant team no later than November 15 to discuss this approach; it can be labor intensive and professional services fees may apply.
How does de-duplication work?
Per the UDS manual and guidance from the UDS Support Center, we count only one visit per patient, per service category, per day, per provider and location. (See “Counting Multiple Visits by Category of Service” in the UDS manual for additional details.) In Relevant, Visit Set Memberships are used as a proxy for service category.
Rows using Data Elements
For a few services, including mammograms and HIV tests, we take a different approach and pull directly from the Data Element indicated on-screen. This makes it simpler to ensure that the appropriate services are counted, regardless of billing workflows or other documentation issues. In addition, this approach means the Data Element becomes the single source of truth for reporting on a given concept, across various UDS tables and ad-hoc reporting.
Numbers too low?
Have your data team check the mapping for the Data Element in question; it may need to be updated to capture scanned documents or other services that do not have a standard code attached.
Numbers too high?
If certain rows in a Data Element should not be counted for purposes of Table 6A (for example, because the service was not provided or paid for by the health center), analysts can adjust the Data Element’s mapping to set exclude_from_table_6a = true.
Does this approach align with HRSA guidance?
Yes. While the UDS Manual begins its Table 6A instructions by providing qualifying ICD and CPT codes, it also provides for a variety of exceptions based on real-world circumstances. The Data Element approach aligns with HRSA guidance while providing health centers the flexibility to report the most accurate numbers possible.
How are “visits” calculated?
For rows powered by Data Elements, the “Number of Visits” column is calculated as the number of rows in the Data Element with a performed_on date during the reporting year (provided that the patient had a countable UDS visit at any time during the reporting year).
How does de-duplication work?
For rows powered by Data Elements, only one service per patient per day is counted.
General questions about Table 6A Selected Services
Q: Why are some rows powered by Data Elements but not others?
A: For 2025 reporting, we’re piloting the Data Element approach for the handful of Table 6A rows that most frequently require customization. In addition, we’re using this approach for rows that have been newly introduced by HRSA (such as Line 26c3, Medications for opioid use disorder) where no billing or diagnosis codes are specified—making Data Elements the only viable approach. In the future, we may migrate additional rows to use Data Elements.
Q: Can I switch between the Billing Codes and Data Element approach?
A: No. For a given row, Relevant only supports one method or the other. However, if you want a Data Element-powered row to strictly match the billing codes approach, you can achieve this result by modifying the Data Element’s mapping.
Q: Why is my UDS Table 6A count lower than my drill-through count?
A: Some visits or services may be excluded from Table 6A due to de-duplication rules. However, these rows will still be displayed when drilling through to line-level details. For this reason, the visit count displayed in Column (a) may be slightly lower than the number of rows in the drill-through.
Q: Does a service need to be provided at a UDS visit to be counted in Table 6A?
A: No. Services that occur during the reporting year are counted as long as the patient had a qualifying UDS visit at any point during the reporting year.
Q: How is age calculated?
A: For diagnoses and tests with specified age ranges, age is calculated at the time of visit or service.
Q: How do snapshots work?
A: When Relevant takes a UDS snapshot, all records for the Selected Services Rendered section are saved in the uds_table_6a_rendered_service_records table. The record_table_name column will either identify visits for visit-powered rows or the Data Element (e.g. mammograms) as the origin of the record.