> ## Documentation Index
> Fetch the complete documentation index at: https://docs.encoreos.io/llms.txt
> Use this file to discover all available pages before exploring further.

# FUA/FUI Follow-Up Measures — Admin Guide

> Configure the NCQA HEDIS substance-use follow-up measures — Measurement Year toggle, mid-period integrity guarantee, and high-intensity scope toggle.

## Overview

CL-29-EN-66 computes two NCQA HEDIS substance-use follow-up quality measures — **FUA**
(Follow-Up After ED Visit for Substance Use) and **FUI** (Follow-Up After High-Intensity SUD
Care) — each as a 7-day and a 30-day rate, surfaced as columns on the existing CL measure
dashboard. The measures extend the EN-65 FUH/FUM substrate and emit an at-risk cohort to CL-35;
they own no outreach and add no new route.

This guide covers the two operator-facing controls, both resolved through **PF-96 jurisdiction
profiles** (`ComplianceRules`), never hardcoded in code:

* the **active Measurement Year** toggle (MY2025 ↔ MY2026) and its mid-period integrity guarantee;
* the **FUI high-intensity scope** toggle and the external-benchmarkability trade-off it carries.

> Architecture and the upstream/downstream contract (PF-108 ADT ingest, CL-51 registration,
> CL-35 care-gap emit, the DS4P leg, and the T4.3 hardening audit) are in the
> [FUA/FUI integration doc](../architecture/integrations/CL-29-EN-66-FUA-FUI-INTEGRATION.md).
> Regulatory status and the four human-verify-open gates are in the
> [Regulatory Compliance Tracker](../compliance/REGULATORY_COMPLIANCE_TRACKER.md).

***

## 1. Setting the active Measurement Year (MY2025 ↔ MY2026)

NCQA publishes the FUA/FUI ruleset by **Measurement Year**. The two versions differ in the
denominator and numerator rules:

|                                      | MY2025                  | MY2026                                        |
| ------------------------------------ | ----------------------- | --------------------------------------------- |
| SUD diagnosis position (denominator) | Principal position only | Any position                                  |
| FUI qualifying follow-up (numerator) | Standard follow-up set  | Adds peer support + residential as qualifying |

The active version is set per org via the **PF-96 `ComplianceRules` field
`active_measurement_year_version`** (`'MY2025'` or `'MY2026'`). The engine reads it **at
evaluation time** — it never infers the year from the system clock — so the rate you see always
reflects the configured ruleset, not the calendar.

**To change the active Measurement Year:** update the org's PF-96 jurisdiction-profile
`compliance.active_measurement_year_version` value. The next measure run computes under the new
ruleset. No code deploy is required; the value flows through the PF-96 profile.

> **No hardcoded value sets.** Selecting a Measurement Year selects a *ruleset shape*. The NCQA
> value-set OIDs themselves are loaded into the CL-51 measure-spec registry from the licensed NCQA
> portal (a human-verify-open gate). Do not expect FUA/FUI prod rates to be conformant until those
> per-MY OIDs are loaded — see the integration doc §7, gate 6.

## 2. Mid-period integrity guarantee (NFR-integrity-1)

Toggling the Measurement Year **mid-period does not overwrite or restate already-computed
results.** Each computed snapshot is written to `cl_quality_measure_periods` keyed (uniquely) on
**(org, measure, period, Measurement Year version)** via a `NULLS NOT DISTINCT` unique index. So:

* the **prior-MY snapshot is preserved** exactly as computed;
* the **new-MY computation starts on the next run** and lands as a *new* row;
* there is **no silent overwrite** — both rows coexist, distinguished by their MY stamp.

This means an admin can move from MY2025 to MY2026 partway through a reporting period without
destroying the historical MY2025 figures that may already have been reported. (Illustrative only —
no real patient data: a synthetic org's `FUA-7` row for period `2026-Q1` under `MY2025` remains
intact after the org switches to `MY2026`; the `MY2026` `FUA-7` row for the same period is added
alongside it.)

## 3. FUI high-intensity scope toggle — and the benchmarkability trade-off

NCQA defines FUI's high-intensity denominator as **residential treatment + acute-inpatient SUD**
(with withdrawal management). That is the **default scope**, and it is what makes a facility's FUI
rate **comparable against NCQA-published benchmark rates.**

PF-96 exposes an **opt-in expansion** — `ComplianceRules.fui_high_intensity_expansion` — that adds
**PHP/IOP** episodes to the FUI high-intensity denominator.

| Setting            | FUI denominator scope                          | Benchmarkability                                                              |
| ------------------ | ---------------------------------------------- | ----------------------------------------------------------------------------- |
| **Default (off)**  | Residential + acute-inpatient SUD (NCQA scope) | **Benchmarkable** against NCQA-published rates                                |
| **Expansion (on)** | Adds PHP/IOP episodes                          | **Not benchmarkable** — denominator no longer matches NCQA's published cohort |

**Trade-off to weigh before enabling.** Turning the expansion **on** gives a broader internal view
of high-intensity follow-up (useful for programs that treat PHP/IOP as high-intensity), but the
resulting FUI rate **can no longer be compared to NCQA benchmark rates** because the denominator
no longer matches the published cohort. Leave it **off** for any FUI rate that will be reported
externally or benchmarked; turn it **on** only for internal quality analysis where you understand
the rate is non-comparable. The default-off / opt-in behavior is verified by acceptance criteria
AC-4.1 (default) and AC-4.2 (opt-in).

## 4. Payer-facing export — disabled by default (42 CFR Part 2)

FUA/FUI denominators are SUD-triggered, so any **payer-facing or AHCCCS-facing export** that
identifies SUD treatment episodes is gated. Internal, org-scoped computation and dashboards are
permitted under the existing HIPAA TPO exception; **payer-facing export is disabled by default**
and fail-closed at the DB until:

* the org explicitly enables payer export (`cl_fua_payer_export_settings.payer_export_enabled`), and
* active 42 CFR Part 2 consent exists for the chart and disclosure purpose
  (`cl_check_sud_consent()`), with every permitted redisclosure written to the CL-11
  redisclosure log.

Do not enable payer export until your compliance officer has confirmed the Part 2 consent basis
(TPO consent, individual authorization, or QSOA) and the AHCCCS DAP measure-weighting question for
the relevant payment year (see the integration doc §7, gates 8 and 10a-b).

***

## Reference

* Integration & architecture: [CL-29-EN-66 FUA/FUI Integration](../architecture/integrations/CL-29-EN-66-FUA-FUI-INTEGRATION.md)
* DS4P label propagation: [CL-29-EN-66 DS4P Propagation](../architecture/integrations/CL-29-EN-66-DS4P-PROPAGATION.md)
* Regulatory status & gates: [Regulatory Compliance Tracker](../compliance/REGULATORY_COMPLIANCE_TRACKER.md)
* Compliance sign-off: `specs/cl/reviews/CL-29-EN-66-COMPLIANCE-SIGNOFF.md`