# ACCESS Requirements Traceability Matrix v0.3

**Scope:** Maps material CMS ACCESS Model requirements to proposed database tables, validation rules, and implementation status.
**Source documents:** ACCESS Participation Agreement (June 2026), ACCESS API Implementation Office Hour (March 2026), API documentation at dsacms.github.io/cmmi-access-model.

> **Note:** The "Test Evidence" column is partially blocked — sanitized ACCESS API test code, synthetic payloads, and CMS submission logs referenced in the brief have not been provided. Those cells are marked `[BLOCKED — pending tester materials]`.

---

## A. Beneficiary Eligibility

| # | CMS Requirement | CMS Source / Section | API / Workflow | DB Table | Validation Rule | Source System | Review / Approval | Reporting / Timing | Status | Test Evidence |
|---|---|---|---|---|---|---|---|---|---|---|
| A1 | Participant must screen beneficiaries for ACCESS eligibility | Agreement §7.01 | Eligibility API | `eligibility_checks`, `intake_records` | Beneficiary must be Medicare-eligible, not ESRD (with exceptions), in service area | Healthie → Core DB → CMS API | Physician review required before CMS submission | Per intake workflow | Schema drafted | [BLOCKED] |
| A2 | Eligibility check result must be tracked | Agreement §7.01 | Eligibility API | `eligibility_checks.check_status` | Enum: pending, eligible, ineligible, control_group, error | CMS API response | System-derived | Real-time at intake | Schema drafted | [BLOCKED] |
| A3 | Control group assignment must be recorded | Agreement §7.01 | Eligibility API | `eligibility_checks.check_status = control_group` | CMS determines control group status | CMS API response | None (CMS-assigned) | At eligibility check | Schema drafted | [BLOCKED] |

## B. Beneficiary Alignment

| # | CMS Requirement | CMS Source / Section | API / Workflow | DB Table | Validation Rule | Source System | Review / Approval | Reporting / Timing | Status | Test Evidence |
|---|---|---|---|---|---|---|---|---|---|---|
| B1 | Voluntary alignment to participant must be recorded | Agreement §7.02 | Alignment API | `alignments`, `enrollment_decisions` | Beneficiary must have passed eligibility + consent | Core DB → CMS API | Physician enrollment decision + patient consent | Within alignment window | Schema drafted | [BLOCKED] |
| B2 | Alignment date must be tracked | Agreement §7.02 | Alignment API | `alignments.aligned_at` | Date from CMS alignment response | CMS API response | None (system-captured) | At alignment | Schema drafted | [BLOCKED] |
| B3 | Required patient notices and documented consent before alignment | Agreement §7.02, §8 | N/A (internal workflow) | `patient_consent` | consent_type=data_sharing, status=granted, notice_provided=true | Healthie intake + internal workflow | Physician or compliance review | Before alignment | Schema drafted | [BLOCKED] |
| B4 | Beneficiary data-sharing opt-out must be honored | Agreement §8.03 | N/A (data-sharing restriction) | `patient_consent.data_sharing_scope` | If opted out, CMS data sharing restricted | Patient declaration | Compliance review | At intake / alignment | Schema drafted | [BLOCKED] |

## C. Care Periods & Clinical Tracks

| # | CMS Requirement | CMS Source / Section | API / Workflow | DB Table | Validation Rule | Source System | Review / Approval | Reporting / Timing | Status | Test Evidence |
|---|---|---|---|---|---|---|---|---|---|---|
| C1 | Care period must be established upon alignment | Agreement §4.06 | Alignment workflow | `care_periods` | start_date = alignment date; end_date per CMS rules | Core DB (system-derived) | Physician review | At alignment | Schema drafted | [BLOCKED] |
| C2 | Clinical track assignment (CKM, eCKM, MSK) must be recorded | Agreement §4.06 | Alignment API | `care_periods.clinical_track_id` | Enum: CKM, eCKM, MSK | CMS API / physician routing | Physician decision | At alignment | Schema drafted | [BLOCKED] |
| C3 | Baseline data collection must occur at Day 0 / start of care period | Agreement §5.01 | Internal workflow | `care_periods.baseline_status`, `oap_measure_observations` | baseline_status transitions: pending → complete | Lab / PROM / intake | Physician review | Within baseline reporting window | Schema drafted | [BLOCKED] |
| C4 | Care period status (active/paused/completed/unaligned) must be tracked | Agreement §4.06 | Internal workflow | `care_periods.operational_status` | Values used in code: active, ended, withdrawn, unaligned (free-text field; terminal set handled by CMS signals) | Core DB (system-driven) | Physician decision for changes | Ongoing | Schema drafted | [BLOCKED] |

## D. OAP Measures & Reporting

| # | CMS Requirement | CMS Source / Section | API / Workflow | DB Table | Validation Rule | Source System | Review / Approval | Reporting / Timing | Status | Test Evidence |
|---|---|---|---|---|---|---|---|---|---|---|
| D1 | OAP measures must be tracked per clinical track | Agreement §5.01 | Data Reporting API | `oap_measure_definitions`, `oap_measure_observations` | Measure definitions match CMS spec per track | CMS technical manual | Physician review before submission | Baseline, quarterly, end-of-period | Schema drafted | [BLOCKED] |
| D2 | CKM measures: BP, LDL-C, weight, BMI, HbA1c, eGFR, uACR | Agreement §5.01 | Data Reporting API | `oap_measure_observations`, `clinical_observations`, `lab_results` | LOINC code mapped; value + unit validated | Labcorp/Quest, patient device | Physician review | Per reporting window | Schema drafted | [BLOCKED] |
| D3 | eCKM measures: BP, weight/BMI, blood glucose | Agreement §5.01 | Data Reporting API | `oap_measure_observations`, `clinical_observations` | LOINC code mapped; value + unit validated | Lab, patient device | Physician review | Per reporting window | Schema drafted | [BLOCKED] |
| D4 | MSK measures: standardized PROM instruments | Agreement §5.01 | Data Reporting API | `oap_measure_observations`, `prom_scores`, `prom_responses` | Instrument name, version, scoring logic preserved | PROM form (Healthie) | Physician review | Per reporting window | Schema drafted | [BLOCKED] |
| D5 | Reporting windows: baseline, quarterly, end-of-period, early success | Agreement §5.01 | Data Reporting API | `oap_reporting_windows`, `oap_measure_observations.validity_window_status` | Window dates calculated from care period start; status = in_window/late/missing/out_of_window | Core DB (system-calculated) | None (system-calculated) | Per CMS schedule | Schema drafted | [BLOCKED] |
| D6 | Data must be submitted to CMS via Data Reporting API | Agreement §5 | Data Reporting API | `oap_measure_observations.cms_submission_payload/response`, `cms_api_requests/responses` | Submission status tracked: draft → locked → submitted → accepted/rejected | Core DB → CMS API | Physician approval before submission | Per reporting window | Schema drafted | [BLOCKED] |
| D7 | Performance monitoring — CMS may monitor participant performance | Agreement §5.02 | N/A (CMS-side) | `aggregate_outcomes`, `reporting_views` | Aggregated, cell-size suppressed | Core DB (derived) | None (internal use) | Ongoing | Schema drafted | N/A (CMS-side) |

## E. Payment, Reconciliation & Recoupment

| # | CMS Requirement | CMS Source / Section | API / Workflow | DB Table | Validation Rule | Source System | Review / Approval | Reporting / Timing | Status | Test Evidence |
|---|---|---|---|---|---|---|---|---|---|---|
| E1 | Monthly OAPs paid per aligned beneficiary | Agreement §6.04 | CMS payment files | `cms_payment_files` | OAP amount per beneficiary per month | CMS files | Finance review | Monthly | Schema drafted | [BLOCKED] |
| E2 | Reconciliation process at end of performance period | Agreement §6.05 | CMS reconciliation | `care_periods.reconciliation_status`, `cms_payment_files` | Status: pending → in_progress → complete | CMS / Core DB | Finance + compliance | End of period | Schema drafted | [BLOCKED] |
| E3 | Recoupment for non-performance or compliance issues | Agreement §6.06 | CMS recoupment | `recoupment_events` | Amount, reason, status tracked | CMS | Finance + compliance | As triggered by CMS | Schema drafted | [BLOCKED] |

## F. Unalignment

| # | CMS Requirement | CMS Source / Section | API / Workflow | DB Table | Validation Rule | Source System | Review / Approval | Reporting / Timing | Status | Test Evidence |
|---|---|---|---|---|---|---|---|---|---|---|
| F1 | Participant may remove beneficiary from alignment under specified conditions | Agreement §7.03 | Unalignment API | `unalignment` | Reason code required | Core DB → CMS API | Physician decision | As needed | Schema drafted | [BLOCKED] |
| F2 | Beneficiary may withdraw from alignment | Agreement §7.03, §7.05 | Unalignment API | `unalignment`, `patient_consent.status=withdrawn` | Patient withdrawal documented | Patient → Core DB → CMS API | Physician notification | As requested | Schema drafted | [BLOCKED] |

## G. Data Sharing & Compliance

| # | CMS Requirement | CMS Source / Section | API / Workflow | DB Table | Validation Rule | Source System | Review / Approval | Reporting / Timing | Status | Test Evidence |
|---|---|---|---|---|---|---|---|---|---|---|
| G1 | CMS shares beneficiary-identifiable data with participant | Agreement §8.02 | CMS data sharing | `cms_api_responses`, `cms_claims_files` | Data access restricted to authorized users | CMS → Core DB | RBAC enforcement | Ongoing | Schema drafted | [BLOCKED] |
| G2 | Participant must maintain compliance with laws (HIPAA, etc.) | Agreement §9.01 | N/A (internal) | All tables (PHI encryption, audit) | Encrypted PHI, RBAC, audit trail | Core DB | Compliance review | Ongoing | Schema drafted | N/A |
| G3 | Compliance plan required | Agreement §9.02 | N/A (internal) | `audit_events` | Every action logged | Core DB | Compliance officer | Ongoing | Schema drafted | N/A |
| G4 | Records must be maintained for audit and inspection | Agreement §15.01-15.02 | N/A (internal) | All tables + `audit_events` + `clinical_documents` (S3) | Retention policy (not yet defined) | Core DB + S3 | Compliance | Per retention policy | Schema drafted | N/A |
| G5 | CMS monitoring and oversight activities | Agreement §9.03-9.04 | N/A (CMS-side) | `aggregate_outcomes`, `reporting_views` | Data available for CMS review | Core DB | None (CMS-initiated) | As requested by CMS | Schema drafted | N/A |

## H. Participant Activities

| # | CMS Requirement | CMS Source / Section | API / Workflow | DB Table | Validation Rule | Source System | Review / Approval | Reporting / Timing | Status | Test Evidence |
|---|---|---|---|---|---|---|---|---|---|---|
| H1 | Care coordination activities required | Agreement §4.05-4.06 | Internal workflow | `care_team_review_tasks`, `clinical_review_tasks` | Task assignment and completion tracked | Core DB | Clinical staff | Ongoing | Schema drafted | N/A |
| H2 | Medical Director required | Agreement §4.04 | Internal workflow | `users` (role=physician_reviewer) | Physician role in system | Core DB | Compliance | At program start | Schema drafted | N/A |
| H3 | Care delivery plan required | Agreement §4.01 | Internal workflow | `protocol_versions`, `protocol_assignment_versions` | Protocol version tracked per beneficiary | Core DB | Physician | At enrollment | Schema drafted | N/A |
| H4 | HIT requirements for data exchange | Agreement §4.07 | Internal + CMS API | `cms_api_requests/responses`, `external_system_identifiers` | API integration capability | Core DB | Technical validation | Ongoing | Schema drafted | [BLOCKED] |

## I. Public Reporting

| # | CMS Requirement | CMS Source / Section | API / Workflow | DB Table | Validation Rule | Source System | Review / Approval | Reporting / Timing | Status | Test Evidence |
|---|---|---|---|---|---|---|---|---|---|---|
| I1 | CMS may publicly report participant outcome measures | Agreement §5.03 | N/A (CMS-side) | `aggregate_outcomes`, `reporting_views` | Cell-size suppression, no patient-level data | Core DB (derived) | Compliance approval | As determined by CMS | Schema drafted | N/A (CMS-side) |
| I2 | Participant may publish outcomes with restrictions | Agreement §14.01-14.02 | Internal workflow | `public_report_exports`, `suppression_rules` | No patient-level data, no small cells, CMS vs MetaFlow distinction | Core DB | Physician + compliance approval | As decided by MetaFlow | Schema drafted | N/A |

---

**Summary of implementation status:**
- **Schema drafted:** 100% of identified CMS requirements have corresponding tables in Schema Draft v0.3.
- **Validation rules:** Defined at the schema level (enum constraints, FK relationships). Application-level validation (e.g., reporting window calculation, LOINC mapping) is pending implementation.
- **Test evidence:** Blocked on prior technical tester materials (API test code, synthetic payloads, CMS submission logs).
- **Retention policy:** Not yet defined — required for Agreement §15.02 compliance.