> ## 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. # Medication-Assisted Treatment (MAT/MOUD) Tracking — Integration > Feature ID: CL-21 Status: 🏗️ Scaffolded (event contracts are placeholders) Spec Reference: CL-21-medication-assisted-treatment-moud-tracking.md Last Updated:… **Feature ID:** CL-21\ **Status:** 🏗️ Scaffolded (event contracts are placeholders)\ **Spec Reference:** [CL-21-medication-assisted-treatment-moud-tracking.md](../../../specs/cl/specs/CL-21-medication-assisted-treatment-moud-tracking.md)\ **Last Updated:** 2026-02-23 *** ## Overview CL-21 defines MAT/MOUD enrollment, medication events (ordered, prescribed, administered, dispensed, held, missed), and monitoring events (UDS, hepatic panel, etc.) for opioid treatment and behavioral health programs. It integrates with CL-05 (medications), CL-06 (e-prescribing), CL-10 (outcomes/CBE #3400), CL-11 (consent/42 CFR Part 2), PM-07 (charge triggers), PF-10 (alerts), and PF-70 (terminology). *** ## Quick Reference | I need to… | Pattern | Location | | --------------------------------- | ----------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------- | | Enforce consent before MAT access | SUD MAT: require linked consent\_id (42 CFR Part 2); deny if absent. Non-SUD MAT: may use chart-level SUD flag. | RLS on `cl_moud_enrollments`, `cl_moud_medication_events`, `cl_moud_monitoring_events` | | Trigger charge capture for MAT | PM-07 charge inputs from enrollment/medication/monitoring context | API\_CONTRACTS / CL-PM Encounter-to-Billing | | Send overdue monitoring alerts | PF-10 Platform Notifications | EVENT\_CONTRACTS when defined | | Use permission keys | `cl.moud.view`, `cl.moud.enroll`, `cl.moud.medication-event.create`, `cl.moud.monitoring.manage`, `cl.moud.report.view` | PF-30 seed | *** ## Pattern Library * **Consent-gated MAT access:** Always resolve consent via `consent_id` on enrollment or chart-level SUD consent; enforce in RLS with SECURITY DEFINER helpers (no direct query to RLS-protected tables). * **Charge context:** Pass enrollment/medication/monitoring context to PM-07 for encounter-to-charge mapping. * **Alerts:** Publish overdue monitoring / missed-dose events via PF-10 when event contracts are defined. *** ## Common Mistakes | Pitfall | Fix | | -------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------- | | Reading MAT data without CL-11 consent check | Enforce consent in RLS; use SECURITY DEFINER helper that checks consent\_id or chart SUD flag. | | Missing WITH CHECK on UPDATE policies | Add WITH CHECK (organization\_id) per constitution §5.2.4. | | Exposing raw MAT/SUD data in logs | Log only non-PHI identifiers; see [constitution.md §4.2 (PHI / PII Handling)](../../../constitution.md#42-phi--pii-handling). | *** ## Pre-Flight Checklist * [ ] CL-11 consent enforcement in place for all MAT tables. * [ ] Permission keys seeded (PF-30); UI gated by `cl.moud.*`. * [ ] UPDATE policies include WITH CHECK on `organization_id`. * [ ] No direct queries to RLS-protected tables inside policies. *** ## Decision Tree (major choices) ```mermaid theme={null} flowchart LR A[MAT access request] --> B{Consent check} B -->|consent_id present| C[Validate consent record] B -->|no consent_id| D1{Is SUD MAT?} D1 -->|Yes: SUD MAT requires consent_id (42 CFR Part 2)| G[Deny] D1 -->|No: Non-SUD MAT may use chart-level SUD flag| D[Chart-level SUD consent] C --> E{Allowed} D --> E E -->|Yes| F[Read/Write MAT data] E -->|No| G ``` *** ## Integration Points (from Spec) | Dependency | Pattern | Purpose | | ------------------------------- | ---------- | ------------------------------------------------------------------------------------------------------------------------ | | PF-01 (Organizations & Sites) | Direct | Multi-tenant isolation | | PF-02 (RBAC) | Direct | Permission keys | | PF-10 (Notifications) | Platform | Overdue monitoring and missed-dose alerts | | PF-70 (Terminology) | Platform | Coding support where required | | CL-01 (Patient Chart) | Internal | Chart-scoped enrollment and events (`chart_id`) | | CL-05 (Medication Management) | Internal | Medication reconciliation context | | CL-06 (E-Prescribing) | Internal | Prescription and pharmacy workflows | | CL-10 (Outcomes) | Internal | MAT outcome metrics and CBE #3400 derivations | | CL-11 (Consent / 42 CFR Part 2) | Internal | Consent checks before MAT access; see Consent (CL-11) subsection below | | PM-07 | API / Data | Charge trigger inputs for MAT encounters and services; see [CL-PM Encounter-to-Billing](./CL-PM-ENCOUNTER-TO-BILLING.md) | *** ### Consent (CL-11) * **`consent_id` on `cl_moud_enrollments`** is optional only for **non-SUD MAT cases**. For SUD MAT, a linked 42 CFR Part 2 consent must be used. * When `consent_id` is **null**, the system falls back to **chart-level SUD consent flags** (CL-11) via RLS policies before any read/write access to MAT enrollment or related events. * When `consent_id` is **present**, it ties to a specific consent record for that MAT episode. * **All** access to `cl_moud_enrollments` and related events (`cl_moud_medication_events`, `cl_moud_monitoring_events`) must pass the CL-11 consent check—either the linked `consent_id` or the chart-level SUD consent flag—enforced in RLS via SECURITY DEFINER helpers. See [CL-11 Consent Integration](consent-management-42cfr-part2-integration.md). *** ## Integration Type Mapping (for CROSS\_CORE\_INTEGRATIONS matrix) | Dependency | Integration Type | Contract / Behavior | | ---------------- | ---------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **CL-10** | Data | Outcome metrics and CBE #3400 derivations from enrollments and medication/monitoring events; consumed via shared tables and reporting. See [CL-10 Outcomes Integration](outcomes-tracking-measurement-integration.md). | | **PF-10** | Event (Platform) | Overdue monitoring and missed-dose alerts delivered via Platform Notifications; event contracts in [EVENT\_CONTRACTS.md](./EVENT_CONTRACTS.md) when defined. | | **PM-07** | API / Data | Charge trigger inputs for MAT encounters and services; API or data contract for encounter-to-charge context. See [CL-PM Encounter-to-Billing](./CL-PM-ENCOUNTER-TO-BILLING.md) and [API\_CONTRACTS.md](./API_CONTRACTS.md) when defined. | | **CL-05, CL-06** | Data | Medication reconciliation and prescription context; shared chart/medication data. | | **CL-11** | Data (consent) | Consent checks before MAT access; see Consent (CL-11) subsection below. | | **PF-70** | Platform | Terminology and coding support; platform code library. | *** ## API Contracts * **PM-07 charge triggers:** Inputs for MAT encounters and services (enrollment/medication/monitoring context) for charge capture. Document in [API\_CONTRACTS.md](./API_CONTRACTS.md) or CL-PM Encounter-to-Billing when implemented. * **Enrollments:** `cl_moud_enrollments` — enrollment, phase, status; consumed by CL-10 and reporting. * **Medication events:** `cl_moud_medication_events` — dosing and adherence; feeds CL-10 numerator/denominator logic. * **Monitoring events:** `cl_moud_monitoring_events` — UDS/lab due and completion; drives PF-10 alerts. *(Add request/response or event schemas here when APIs or events are defined.)* *** ## Event Contracts * **PF-10 (Platform):** Overdue monitoring and adherence-risk alerts published via Platform Notifications (Platform Integration Layer). * Event contracts are defined in [EVENT\_CONTRACTS.md](./EVENT_CONTRACTS.md) as: * `cl_moud_monitoring_overdue` * `cl_moud_adherence_risk` * See [EVENT\_CONTRACTS.md](./EVENT_CONTRACTS.md) for payload definitions. *** ## Security and RLS * PHI/SUD: strict RLS and CL-11 consent enforcement before access. * RLS on `cl_moud_enrollments`, `cl_moud_medication_events`, `cl_moud_monitoring_events` via SECURITY DEFINER helpers; no direct queries to RLS-protected tables in policies (constitution §5.7). * UPDATE policies must include WITH CHECK on `organization_id` (constitution §5.2.4). * Permission keys: `cl.moud.view`, `cl.moud.enroll`, `cl.moud.medication-event.create`, `cl.moud.monitoring.manage`, `cl.moud.report.view` (seed in migration per PF-30). *** ## Related Docs * [Spec](../../../specs/cl/specs/CL-21-medication-assisted-treatment-moud-tracking.md) * [CL-10 Outcomes Integration](outcomes-tracking-measurement-integration.md) * [CL-11 Consent Integration](consent-management-42cfr-part2-integration.md) * [CROSS\_CORE\_INTEGRATIONS.md](CROSS_CORE_INTEGRATIONS.md)