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

## Home

Official URL: https://globalalliantinc.com/access/ImplementationGuide/cms.fhir.us.access | Version: 0.9.0
Draft as of 2026-03-06 | Computable Name: CMSAccessAPI

### Overview

Welcome to the CMS ACCESS Model API Implementation Guide. This comprehensive guide covers all APIs for the CMS ACCESS (Advancing Chronic Care with Effective, Scalable Solutions) Model.

The ACCESS Model aims to modernize chronic condition management across Medicare by testing a value-based payment system that prioritizes health outcomes, clinical accountability, and patient empowerment. It enables care organizations to use a wide range of technology-supported tools — including virtual care, remote monitoring, digital therapeutics, and coordinated team-based services — that are often difficult to bill under traditional fee-for-service Medicare.

For more information about the CMS ACCESS Model, please see the ACCESS Model website.

### About This Implementation Guide

This IG consolidates guidance for all ACCESS Model APIs into a single comprehensive resource, providing:

- Consistent authentication mechanisms
- Shared resources used across multiple APIs
- API-specific resources used in specific APIs

### ACCESS Model APIs

This Implementation Guide covers four primary APIs: the Eligibility API, the Alignment API, the Unalignment API, and the Data Reporting API (to be added in a subsequent release of this IG).

#### Eligibility API

This API allows participants to quickly determine if a patient meets the basic eligibility criteria for participation in the ACCESS model.

Key Operations:

- `$check-eligibility` - Submit eligibility check request
- `$submission-status` - Check status of eligibility request

Learn more about the Eligibility API in the ACCESS API Operations Manual.

#### Alignment API

This API aligns eligible patients to participants within specific ACCESS Model tracks. When a patient is aligned to an ACCESS Model track, a subscription is created to provide event notifications related to the patient to the participant. This subscription will provide information on the patient’s status throughout the ACCESS Model and provide valuable reminders.

Key Operations:

- `$align` - Submit alignment request
- `$submission-status` - Check status of alignment request

Additional Features:

- Subscription-based event notifications

Learn more about the Alignment API in the ACCESS API Operations Manual.

#### Unalignment API

This API allows a participant to manually unalign a patient from the ACCESS Model track due to specific approved reasons such as patient relocation or loss of contact.

Key Operations:

- `$unalign` - Submit unalignment request
- `$submission-status` - Check status of unalignment request

Learn more about the Unalignment API in the ACCESS API Operations Manual.

#### Data Reporting API

This API allows a participant to submit required data reporting information for patients aligned to the ACCESS Model to support program evaluation and performance measurement.

Key Operations:

- `$report-data` - Submit data report
- `$submission-status` - Check status of data submission

🔮 Coming in Future Release: The Data Reporting API details will be added in a future version of this Implementation Guide.

### ACCESS Model Tracks

All APIs support the following ACCESS Model tracks:

- eCKM (Early Cardio-Kidney-Metabolic) - Hypertension, dyslipidemia, obesity, prediabetes
- CKM (Cardio-Kidney-Metabolic) - Diabetes, chronic kidney disease, atherosclerotic cardiovascular disease
- MSK (Musculoskeletal) - Chronic musculoskeletal pain
- BH (Behavioral Health) - Depression and anxiety

### Key Features

- Asynchronous Processing - All primary operations are asynchronous, returning a URL with submission ID to check the status
- US Core Alignment - Leverages US Core 6.1.0 profiles
- OAuth 2.0 Security - Enterprise-grade authentication using client credentials flow
- FHIR R4 - Built on FHIR R4.0.1 specification
- Subscription Support - Real-time notifications for ACCESS Model events and deadlines

### Getting Started

📘 Operations Manual: Detailed implementation guidance including authentication workflows, API-specific examples, subscriptions, and testing scenarios is available in the separate Operations Manual document.

1. Review the Operations Manual - Understand common patterns, authentication, and API-specific guidance
2. Select Your APIs - Choose the appropriate APIs for your use case
3. Review Artifacts - Examine the technical specifications
4. Review Conformance Expectations - Understand conformance requirements

#### Navigation Tips

- Use the top menu bar to access different IG sections
- The Artifacts page provides a comprehensive list of all formal artifacts with links to detailed pages
- Code examples throughout use realistic placeholder URLs marked as `[base]` - replace these with your actual API endpoint
- All examples show both HTTP headers and JSON bodies separately for clarity

#### For Different Roles

- API Developers: Review the Operations Manual for detailed implementation patterns, then examine the operation definitions in Artifacts.

- Integration Architects: The Operations Manual contains sequence diagrams showing the asynchronous pattern and system interactions.

- QA/Testing Teams: Use the example instances in Artifacts to understand expected responses, and see the Testing Guide in the Operations Manual for test scenarios.

- Compliance/Security Teams: The Operations Manual includes Security Considerations for authentication, TLS requirements, and data handling practices.

#### FHIR Knowledge Prerequisites

This IG assumes familiarity with:

Core FHIR Concepts:

- FHIR R4 basics including resources, data types, and the RESTful API
- HTTP/REST APIs - RESTful API basics and HTTP status codes
- FHIR Operations - Operations Framework and custom operations
- Parameters for operation inputs and outputs
- FHIR Asynchronous request patterns

US Core Profiles:

- US Core Patient
- US Core Observation profiles - US Core Vital Signs, US Core Laboratory Result, and US Core Simple Observation
- US Core DiagnosticReport

Additional FHIR Resources (for Data Reporting API):

- Bundle resource for document bundles
- Composition resource for organizing clinical data

Subscriptions (for Alignment API):

- Subscription resource for event notifications
- Bundle resource for notification messages (message bundles)
- MessageHeader for subscription notification messages

Security:

- OAuth 2.0 Client Credentials flow for API authentication
- SMART App Launch Backend Services

### Credits

These are the contributing organizations which drive the guidance in this IG:

- Centers of Medicare and Medicaid Services (CMS)
- Global Alliant, Inc.
- Firely USA Inc.

For more information contact Dave Hill (david.h[at]globalalliantinc.com).

### Globals Profiles

There are no Global profiles defined

### Package Dependencies

ℹ️ Important - Standards Compliance: It should be noted that FHIR US Core 6.1.0 is based off of ASTP/ONC USCDI v3, not USCDI v1 as indicated below, so this FHIR IG is compliant with g10 standards.

IG | Package | FHIR | Comment
--- | --- | --- | ---
CMS ACCESS Model API | cms.fhir.us.access#0.9.0 | R4 |
HL7 Terminology (THO) | hl7.terminology.r4#7.0.1 | R4 | Automatically added as a dependency - all IGs depend on HL7 Terminology
FHIR Extensions Pack | hl7.fhir.uv.extensions.r4#5.2.0 | R4 |
US Core Implementation Guide | hl7.fhir.us.core#6.1.0 | R4 |
HL7 Terminology (THO) | hl7.terminology.r4#5.0.0 | R4 |
FHIR Extensions Pack | hl7.fhir.uv.extensions.r4#1.0.0 | R4 |
Bulk Data Access IG | hl7.fhir.uv.bulkdata#2.0.0 | R4 |
SMART App Launch | hl7.fhir.uv.smart-app-launch#2.1.0 | R4 |
VSAC | us.nlm.vsac#0.11.0 | R4 |
Structured Data Capture | hl7.fhir.uv.sdc#3.0.0 | R4 |
PHINVads | us.cdc.phinvads#0.12.0 | R4 |
IHE FormatCode Vocabulary | ihe.formatcode.fhir#1.1.0 | R4 |
CARIN Consumer Directed Payer Data Exchange (CARIN IG for Blue Button®) | hl7.fhir.us.carin-bb#2.1.0 | R4 |
HL7 Terminology (THO) | hl7.terminology.r4#6.2.0 | R4 |
US Core (Reuse Wrapper) | hl7.fhir.us.core.3.1.1#3.1.1 | R4 |
US Core | hl7.fhir.us.core#3.1.1 | R4 |
VSAC | us.nlm.vsac#0.21.0 | R4 |
FHIR Tooling Extensions IG | hl7.fhir.uv.tools.r4#0.9.0 | R4 | for example references

Package hl7.fhir.uv.extensions.r4#5.2.0 This IG defines the global extensions - the ones defined for everyone. These extensions are always in scope wherever FHIR is being used (built Mon, Feb 10, 2025 21:45+1100+11:00)

Package hl7.fhir.uv.extensions.r4#1.0.0 This IG defines the global extensions - the ones defined for everyone. These extensions are always in scope wherever FHIR is being used (built Sun, Mar 26, 2023 08:46+1100+11:00)

Package hl7.fhir.uv.bulkdata#2.0.0 FHIR based approach for exporting large data sets from a FHIR server to a client application (built Fri, Nov 26, 2021 05:56+1100+11:00)

Package hl7.fhir.uv.sdc#3.0.0 The SDC specification provides an infrastructure to standardize the capture and expanded use of patient-level data collected within an EHR. This includes two components: * Support more sophisticated questionnaire/form use-cases such as those needed for research, oncology, pathology and other clinical domains. *Support pre-population and auto-population of EHR data into forms/questionnaires for uses outside direct clinical care (patient safety, adverse event reporting, public health reporting, etc.). (built Tue, Mar 8, 2022 18:32+0000+00:00)

Package ihe.formatcode.fhir#1.1.0 Implementation Guide for IHE defined FormatCode vocabulary. (built Thu, Feb 24, 2022 16:55-0600-06:00)

Package hl7.fhir.us.core#6.1.0 The US Core Implementation Guide is based on FHIR Version R4 and defines the minimum conformance requirements for accessing patient data. The Argonaut pilot implementations, ONC 2015 Edition Common Clinical Data Set (CCDS), and ONC U.S. Core Data for Interoperability (USCDI) v1 provided the requirements for this guide. The prior Argonaut search and vocabulary requirements, based on FHIR DSTU2, are updated in this guide to support FHIR Version R4. This guide was used as the basis for further testing and guidance by the Argonaut Project Team to provide additional content and guidance specific to Data Query Access for purpose of ONC Certification testing. These profiles are the foundation for future US Realm FHIR implementation guides. In addition to Argonaut, they are used by DAF-Research, QI-Core, and CIMI. Under the guidance of HL7 and the HL7 US Realm Steering Committee, the content will expand in future versions to meet the needs specific to the US Realm. These requirements were originally developed, balloted, and published in FHIR DSTU2 as part of the Office of the National Coordinator for Health Information Technology (ONC) sponsored Data Access Framework (DAF) project. For more information on how DAF became US Core see the US Core change notes. (built Fri, Jun 30, 2023 14:02+0000+00:00)

Package hl7.fhir.us.carin-bb#2.1.0 CARIN Consumer Directed Payer Data Exchange (CARIN IG for Blue Button®) (built Tue, Feb 18, 2025 17:31+0000+00:00)

Package hl7.fhir.uv.tools.r4#0.9.0 This IG defines the extensions that the tools use internally. Some of these extensions are content that are being evaluated for elevation into the main spec, and others are tooling concerns (built Tue, Dec 16, 2025 23:18+1100+11:00)

### Cross Version Analysis

This is an R4 IG. None of the features it uses are changed in R4B, so it can be used as is with R4B systems. Packages for both R4 (cms.fhir.us.access.r4) and R4B (cms.fhir.us.access.r4b) are available.

### Intellectual Property Considerations

This publication includes IP covered under the following statements.

- Copyright (c) 2026 Centers for Medicare and Medicaid Services (CMS).
  Show Usage
  - ACCESS Alignment Request Result Codes: ACCESSAlignmentResponseParameters, ACCESSAlignmentResultVS, Parameters/AlignmentResponseAlignedExample and Parameters/AlignmentResponseSwitchApprovedExample
  - ACCESS Eligibility Result Codes: ACCESSCheckEligibilityResponseParameters, ACCESSEligibilityResultVS, Parameters/CheckEligibilityResponseEligibleExample and Parameters/SubmissionStatusResponseExample
  - ACCESS Event Types: ACCESSEventTypeVS
  - ACCESS Referral Type: ACCESSAlignmentRequestParameters, ACCESSReferralTypeVS, Align, Parameters/AlignmentRequestExample and Parameters/AlignmentRequestWithSwitchConsentExample
  - ACCESS Model Tracks: ACCESSAlignmentRequestParameters, ACCESSCheckEligibilityRequestParameters... Show 10 more, ACCESSTrackVS, ACCESSUnalignmentRequestParameters, Align, CheckEligibility, Parameters/AlignmentRequestExample, Parameters/AlignmentRequestWithSwitchConsentExample, Parameters/CheckEligibilityRequestExample, Parameters/UnalignmentRequestESRDExample, Parameters/UnalignmentRequestExample and Unalign
  - ACCESS Unalignment Reason Codes: ACCESSUnalignmentReasonVS, ACCESSUnalignmentRequestParameters, Parameters/UnalignmentRequestESRDExample and Parameters/UnalignmentRequestExample
  - ACCESS Unalignment Request Result Codes: ACCESSUnalignmentResponseParameters, ACCESSUnalignmentResultVS and Parameters/UnalignmentResponseUnalignedExample
- ISO maintains the copyright on the country codes, and controls its use carefully. For further details see the ISO 3166 web page: https://www.iso.org/iso-3166-country-codes.html
  Show Usage
  - ISO 3166-1 Codes for the representation of names of countries and their subdivisions — Part 1: Country code: ACCESSAlignmentAPICapabilityStatement, ACCESSAlignmentRequestParameters... Show 37 more, ACCESSAlignmentResponseParameters, ACCESSAlignmentResultCS, ACCESSAlignmentResultVS, ACCESSBHCondition, ACCESSBHDiagnosisVS, ACCESSCKMCondition, ACCESSCKMDiagnosisVS, ACCESSCheckEligibilityRequestParameters, ACCESSCheckEligibilityResponseParameters, ACCESSClinicalExclusionCondition, ACCESSCondition, ACCESSEligibilityAPICapabilityStatement, ACCESSEligibilityResultCS, ACCESSEligibilityResultVS, ACCESSEventTypeCS, ACCESSEventTypeVS, ACCESSMSKCondition, ACCESSMSKDiagnosisVS, ACCESSReferralTypeCS, ACCESSReferralTypeVS, ACCESSSubmissionStatusResponseParameters, ACCESSTrackCS, ACCESSTrackVS, ACCESSUnalignmentAPICapabilityStatement, ACCESSUnalignmentReasonCS, ACCESSUnalignmentReasonVS, ACCESSUnalignmentRequestParameters, ACCESSUnalignmentResponseParameters, ACCESSUnalignmentResultCS, ACCESSUnalignmentResultVS, ACCESSeCKMCondition, ACCESSeCKMDiagnosisVS, Align, CMSAccessAPI, CheckEligibility, SubmissionStatus and Unalign
- This CodeSystem is not copyrighted.
  Show Usage
  - C4BB Identifier Type Code System: Parameters/AlignmentRequestExample, Parameters/AlignmentRequestWithSwitchConsentExample, Parameters/CheckEligibilityRequestExample, Parameters/UnalignmentRequestESRDExample and Parameters/UnalignmentRequestExample
- This material derives from the HL7 Terminology (THO). THO is copyright ©1989+ Health Level Seven International and is made available under the CC0 designation. For more licensing information see: https://terminology.hl7.org/license.html
  Show Usage
  - Condition Category Codes: Condition/ConditionDepressionExample, Condition/ConditionDiabetesExample... Show 6 more, Condition/ConditionHypertensionExample, Condition/ConditionOsteoarthritisExample, Condition/ESRDConditionExample, Parameters/AlignmentRequestExample, Parameters/AlignmentRequestWithSwitchConsentExample and Parameters/UnalignmentRequestESRDExample
  - Condition Clinical Status Codes: Condition/ConditionDepressionExample, Condition/ConditionDiabetesExample... Show 6 more, Condition/ConditionHypertensionExample, Condition/ConditionOsteoarthritisExample, Condition/ESRDConditionExample, Parameters/AlignmentRequestExample, Parameters/AlignmentRequestWithSwitchConsentExample and Parameters/UnalignmentRequestESRDExample
  - ConditionVerificationStatus: Condition/ConditionDepressionExample, Condition/ConditionDiabetesExample... Show 6 more, Condition/ConditionHypertensionExample, Condition/ConditionOsteoarthritisExample, Condition/ESRDConditionExample, Parameters/AlignmentRequestExample, Parameters/AlignmentRequestWithSwitchConsentExample and Parameters/UnalignmentRequestESRDExample
  - identifierType: Parameters/AlignmentRequestExample, Parameters/AlignmentRequestWithSwitchConsentExample... Show 5 more, Parameters/CheckEligibilityRequestExample, Parameters/UnalignmentRequestESRDExample, Parameters/UnalignmentRequestExample, Patient/PatientESRDExample and Patient/PatientExample