CMS ACCESS Model API
0.9.0 - ci-build
CMS ACCESS Model API
0.9.0 - ci-build
CMS ACCESS Model API - Local Development build (v0.9.0) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions
| Official URL: https://globalalliantinc.com/access/ValueSet/ACCESSAlignmentResultVS | Version: 0.9.0 | |||
| Draft as of 2026-03-06 | Computable Name: ACCESSAlignmentResultVS | |||
Copyright/Legal: Copyright (c) 2026 Centers for Medicare and Medicaid Services (CMS). |
||||
This value set includes all codes from the ACCESS Alignment Result code system.
References
https://globalalliantinc.com/access/CodeSystem/ACCESSAlignmentResultCS version 📍0.9.0
Expansion performed internally based on codesystem ACCESS Alignment Request Result Codes v0.9.0 (CodeSystem)
This value set contains 7 concepts
| System | Code | Display (en) | Definition | JSON | XML |
https://globalalliantinc.com/access/CodeSystem/ACCESSAlignmentResultCS | aligned | Aligned | Patient is eligible and has been aligned so the participant can now begin providing services to the patient under the ACCESS Model. | ||
https://globalalliantinc.com/access/CodeSystem/ACCESSAlignmentResultCS | not-aligned-control-group | Not aligned - assigned to Control Group | The patient is technically eligible, but based on the randomized control group algorithm, the patient has been placed in the control group for 12 months and therefore cannot be aligned for 12 months. | ||
https://globalalliantinc.com/access/CodeSystem/ACCESSAlignmentResultCS | not-aligned-already-aligned | Not aligned - already aligned to another participant in the track | The patient is technically eligible, but is already aligned to another participant and receiving services under the ACCESS Model in the same track. A patient can only be aligned to one participant in each track. If a switch consent attestation is submitted, but the patient is still within the 3-month lock-in period, this response will be received. | ||
https://globalalliantinc.com/access/CodeSystem/ACCESSAlignmentResultCS | not-aligned-not-medicare | Not aligned - not receiving Medicare | The patient either is not enrolled in Medicare Part A and Part B or dual eligible for Medicare and Medicaid, or they do not have Medicare as their primary insurance, so they are not eligible for services under the ACCESS Model. | ||
https://globalalliantinc.com/access/CodeSystem/ACCESSAlignmentResultCS | not-aligned-services | Not aligned - receiving services that prevent eligibility | The patient is receiving services (such as hospice, end stage renal disease (ESRD), etc.) making them ineligible to be part of the ACCESS Model. | ||
https://globalalliantinc.com/access/CodeSystem/ACCESSAlignmentResultCS | not-aligned-diagnoses | Not aligned - no qualifying diagnosis | The patient does not have a treating diagnosis that qualifies them for service in the track indicated and therefore cannot get services under the ACCESS Model. | ||
https://globalalliantinc.com/access/CodeSystem/ACCESSAlignmentResultCS | aligned-switch-approved | Aligned and switch approved | The request to switch the patient's alignment from a different participant after the 3-month lock in period is accepted and the patient is considered switched and now re-aligned. |
Explanation of the columns that may appear on this page:
| Level | A few code lists that FHIR defines are hierarchical - each code is assigned a level. In this scheme, some codes are under other codes, and imply that the code they are under also applies |
| System | The source of the definition of the code (when the value set draws in codes defined elsewhere) |
| Code | The code (used as the code in the resource instance) |
| Display | The display (used in the display element of a Coding). If there is no display, implementers should not simply display the code, but map the concept into their application |
| Definition | An explanation of the meaning of the concept |
| Comments | Additional notes about how to use the code |