> ## 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.

# Clinical Reporting & Quality Measures Expansion — Admin Guide

> Configure Phase 2 & 3: dual-track incident deadlines, clinical audit and quality-measure reports, portal QM consent, and audit logging.

## Overview

This admin guide covers the configuration, governance, and operational steps for the CL-15 Phase 2 & 3 expansion. For end-user behavior, see the [CL-15-P2-3 user guide](/cl/cl-15-p2-3-user-guide). Configuring incident tracks and report definitions requires org-admin rights; the report actions use the `cl.report_definitions.*` permission keys.

## Deployment & configuration

Incident deadline behavior is driven by `cl_module_settings`, edited from **CL Settings → Incident reporting** (`/cl/settings`, surfaced by `CLSettingsForm`).

| Setting                        | Purpose                                                                                                                                                                        |
| ------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `incident_deadline_track`      | Regulatory track: `azdhs` (default), `ahcccs`, or `dual`. Controls which deadline rules apply.                                                                                 |
| `incident_business_day_config` | Business-day rules for AHCCCS, e.g. `{ "excludeWeekends": true }`. Weekday-only exclusion is supported this release; holiday calendars are deferred.                           |
| `incident_sentinel_options`    | Sentinel-event classification, e.g. `{ "sentinelTypes": [...], "reportingWindow": "..." }`. Sentinel events inherit the parent deadline and can be escalated via PF-10 alerts. |

Defaults preserve Phase 1 behavior: a new org is `azdhs` with empty business-day and sentinel config.

<Warning>
  Changing the track is **not retroactive** — only incidents created after the change use the new rules. Verify the track with Compliance before go-live.
</Warning>

## Legal verification before enabling AHCCCS or dual track

The default `azdhs` track preserves licensed-facility behavior. **Do not** switch to `ahcccs` or `dual` until Legal/Compliance has verified the applicable timeframes:

1. Confirm the facility's AHCCCS contract scope and which Policy 961 timelines apply.
2. Record the verification (signer, date, attached memo) in `docs/compliance/REGULATORY_COMPLIANCE_TRACKER.md` under **CL-15 Open Question Q4**.
3. Only then change `incident_deadline_track`. The change is captured in the audit log (see below).

## Report definitions (clinical audit, HEDIS, CARF)

Report definitions live in `cl_report_definitions`; runs are recorded in `cl_report_runs`. Creating a definition requires `cl.report_definitions.create`; deleting requires `cl.report_definitions.delete`.

* **Clinical audit** — set `report_type = 'clinical_audit'` and select dimensions (break-glass, disclosures, documentation timeliness, consent, risk screening) via the dialog checkboxes. Dimension selections persist on the definition's `filters` JSONB.
* **HEDIS / CARF** — set `report_type = 'hedis'` or `'carf'`. Each run computes a lightweight aggregate from CL-10 outcome data (`cl_outcome_measures`) over the trailing 12 months.

<Note>
  Full per-dimension audit drill-down (T5 / T-COMP-3) and full NCQA HEDIS conformance with PF-70 value sets (T-COMP-2) are pending. Today's runs produce aggregate summaries in `cl_report_runs.result_summary`.
</Note>

## Patient-portal QM & consent

The portal QM view is read-only and patient-scoped. Administratively, the key behavior to understand is **42 CFR Part 2 (SUD) consent gating**: measures derived from SUD data are only shown to a portal user when the patient's consent status permits it. No additional per-org switch is required to enforce this — it follows the patient's consent record. Confirm consent capture (CL-11) is configured for SUD programs so portal measures display correctly.

## CARF survey readiness

The CARF readiness surface reads accreditation data from Governance (GR-08) through the read-only `@/platform/governance` contract. There is no CL-side data store to configure; ensure CARF accreditations are entered in **Governance**, otherwise the readiness view shows its empty state. The dedicated readiness page/route (T10) is pending.

## Audit & compliance logging

Changes to the dual-track settings are recorded in `pf_audit_logs` (action `cl_module_settings.incident_track.update`), capturing who changed the track and when. Use this trail when demonstrating change control during AZDHS/AHCCCS or CARF reviews. Report runs are independently logged in `cl_report_runs`.

## Troubleshooting

| Symptom                                                         | Likely cause / resolution                                                                    |
| --------------------------------------------------------------- | -------------------------------------------------------------------------------------------- |
| Existing incident deadlines didn't change after switching track | By design — track changes are not retroactive. Only new incidents use the new track.         |
| CARF readiness shows the empty state                            | No accreditation data in Governance; add accreditations in GR-08.                            |
| A user can't view or run reports                                | Missing `cl.report_definitions.view` (view/run) or `cl.report_definitions.create` (create).  |
| Portal QM omits some measures                                   | Expected when SUD-derived measures lack the required 42 CFR Part 2 consent for that patient. |
| Holiday handling not applied to AHCCCS deadlines                | Holiday calendars are deferred this release; only weekday exclusion is supported.            |

<Note>
  This page documents shipped product behavior. It is not medical, legal, or
  billing advice. Verify against your organization's policies and applicable
  regulations before using it for clinical, compliance, or billing decisions.
  Protected health information (PHI) shown in the product is governed by your
  tenant's access controls and is never exposed in this documentation.
</Note>
