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

## : ACCESS Alignment API Capability Statement - JSON Representation

Active as of 2026-01-23

Raw json | Download

    {
      "resourceType" : "CapabilityStatement",
      "id" : "ACCESSAlignmentAPICapabilityStatement",
      "text" : {
        "status" : "extensions",
        "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\"><p class=\"res-header-id\"><b>Generated Narrative: CapabilityStatement ACCESSAlignmentAPICapabilityStatement</b></p><a name=\"ACCESSAlignmentAPICapabilityStatement\"> </a><a name=\"hcACCESSAlignmentAPICapabilityStatement\"> </a><h2 id=\"title\">ACCESS Alignment API Capability Statement</h2><ul><li>Implementation Guide Version: 0.9.0 </li><li>FHIR Version: 4.0.1 </li><li>Supported Formats: <code>json</code>, <code>xml</code></li><li>Published on: 2026-01-23 </li><li>Published by: Global Alliant, Inc. </li></ul><blockquote class=\"impl-note\"><p><strong>Note to Implementers: FHIR Capabilities</strong></p><p>Any FHIR capability may be 'allowed' by the system unless explicitly marked as 'SHALL NOT'. A few items are marked as MAY in the Implementation Guide to highlight their potential relevance to the use case.</p></blockquote><h3 id=\"shallIGs\">SHALL Support the Following Implementation Guides</h3><ul><li><a href=\"index.html\">https://globalalliantinc.com/access/ImplementationGuide/cms.fhir.us.access</a></li></ul><h2 id=\"rest\">FHIR RESTful Capabilities</h2><div class=\"panel panel-default\"><div class=\"panel-heading\"><h3 id=\"mode1\" class=\"panel-title\">Mode: <code>server</code></h3></div><div class=\"panel-body\"><div><p>The ACCESS Alignment API supports aligning patients to ACCESS participants for specific tracks (eCKM, CKM, MSK, BH).</p>\n</div><div class=\"lead\"><em>Security</em></div><div class=\"row\"><div class=\"col-lg-6\">Enable CORS: yes</div><div class=\"col-lg-6\">Security services supported: </div></div><blockquote><div><p>Implementations SHALL use TLS 1.3 and implement OAuth 2.0 Client Credentials flow for authentication. MBI and other PHI must be protected according to HIPAA requirements.</p>\n</div></blockquote></div></div><h3 id=\"resourcesCap1\">Capabilities by Resource/Profile</h3><h4 id=\"resourcesSummary1\">Summary</h4><p>The summary table lists the resources that are part of this configuration, and for each resource it lists:</p><ul><li>The relevant profiles (if any)</li><li>The interactions supported by each resource (<b><span class=\"bg-info\">R</span></b>ead, <b><span class=\"bg-info\">S</span></b>earch, <b><span class=\"bg-info\">U</span></b>pdate, and <b><span class=\"bg-info\">C</span></b>reate, are always shown, while <b><span class=\"bg-info\">VR</span></b>ead, <b><span class=\"bg-info\">P</span></b>atch, <b><span class=\"bg-info\">D</span></b>elete, <b><span class=\"bg-info\">H</span></b>istory on <b><span class=\"bg-info\">I</span></b>nstance, or <b><span class=\"bg-info\">H</span></b>istory on <b><span class=\"bg-info\">T</span></b>ype are only present if at least one of the resources has support for them.</li><li><span>The required, recommended, and some optional search parameters (if any). </span></li><li>The linked resources enabled for <code>_include</code></li><li>The other resources enabled for <code>_revinclude</code></li><li>The operations on the resource (if any)</li></ul><div class=\"table-responsive\"><table class=\"table table-condensed table-hover\"><thead><tr><th><b>Resource Type</b></th><th><b>Profile</b></th><th class=\"text-center\"><b title=\"GET a resource (read interaction)\">R</b></th><th class=\"text-center\"><b title=\"GET all set of resources of the type (search interaction)\">S</b></th><th class=\"text-center\"><b title=\"PUT a new resource version (update interaction)\">U</b></th><th class=\"text-center\"><b title=\"POST a new resource (create interaction)\">C</b></th><th><b title=\"Required and recommended search parameters\">Searches</b></th><th><code><b>_include</b></code></th><th><code><b>_revinclude</b></code></th><th><b>Operations</b></th></tr></thead><tbody><tr><td><a href=\"#Patient1-1\">Patient</a></td><td>\u00a0</td><td class=\"text-center\"/><td class=\"text-center\"/><td class=\"text-center\"/><td class=\"text-center\"/><td/><td/><td/><td><code>$align</code>, <code>$submission-status</code></td></tr></tbody></table></div><hr/><div class=\"panel panel-default\"><div class=\"panel-heading\"><h4 id=\"Patient1-1\" class=\"panel-title\"><span style=\"float: right;\">Resource Conformance: supported </span>Patient</h4></div><div class=\"panel-body\"><div class=\"container\"><div class=\"row\"><div class=\"col-lg-4\"><span class=\"lead\">Core FHIR Resource</span><br/><a href=\"http://hl7.org/fhir/R4/patient.html\">Patient</a></div><div class=\"col-lg-4\"><span class=\"lead\">Reference Policy</span><br/></div><div class=\"col-lg-4\"><span class=\"lead\">Interaction summary</span><br/><ul/></div></div><p/><p/><div class=\"row\"><div class=\"col-12\"><span class=\"lead\">Documentation</span><blockquote><div><p>Patient resource for ACCESS alignment operations</p>\n</div></blockquote></div></div><div class=\"row\"><div class=\"col-12\"><span class=\"lead\">Extended Operations</span><table class=\"table table-condensed table-hover\"><thead><tr><th>Conformance</th><th>Operation</th><th>Documentation</th></tr></thead><tbody><tr><td><b>SHALL</b></td><td><a href=\"OperationDefinition-Align.html\">$align</a></td><td><div><p>Align a patient to an ACCESS participant for a specific track. Requires at least one Condition resource. Enforces 3-month lock-in period. Supports provider switching with switchConsentAttestation parameter after lock-in expires. Automatically creates notification subscriptions upon successful alignment. Returns alignment status from ACCESSAlignmentResultVS: aligned, aligned-switch-approved, not-aligned-control-group, not-aligned-already-aligned, not-aligned-not-medicare, not-aligned-services, or not-aligned-diagnoses. Implements asynchronous processing with HTTP 202 Accepted response containing Content-Location header for status polling.</p>\n</div></td></tr><tr><td><b>SHALL</b></td><td><a href=\"OperationDefinition-SubmissionStatus.html\">$submission-status</a></td><td><div><p>Poll the status of a previously submitted alignment request. Returns HTTP 202 while processing or HTTP 200 with result when complete.</p>\n</div></td></tr></tbody></table></div></div></div></div></div></div>"
      },
      "url" : "https://globalalliantinc.com/access/CapabilityStatement/ACCESSAlignmentAPICapabilityStatement",
      "version" : "0.9.0",
      "name" : "ACCESSAlignmentAPICapabilityStatement",
      "title" : "ACCESS Alignment API Capability Statement",
      "status" : "active",
      "experimental" : false,
      "date" : "2026-01-23",
      "publisher" : "Global Alliant, Inc.",
      "contact" : [
        {
          "name" : "Global Alliant, Inc.",
          "telecom" : [
            {
              "system" : "url",
              "value" : "https://globalalliantinc.com"
            },
            {
              "system" : "email",
              "value" : "david.h@globalalliantinc.org"
            }
          ]
        }
      ],
      "description" : "Describes the expected capabilities of systems implementing the ACCESS Alignment API for aligning patients to ACCESS participants.",
      "jurisdiction" : [
        {
          "coding" : [
            {
              "system" : "urn:iso:std:iso:3166",
              "code" : "US",
              "display" : "United States of America"
            }
          ]
        }
      ],
      "kind" : "requirements",
      "fhirVersion" : "4.0.1",
      "format" : [
        "json",
        "xml"
      ],
      "implementationGuide" : [
        🔗 "https://globalalliantinc.com/access/ImplementationGuide/cms.fhir.us.access"
      ],
      "rest" : [
        {
          "mode" : "server",
          "documentation" : "The ACCESS Alignment API supports aligning patients to ACCESS participants for specific tracks (eCKM, CKM, MSK, BH).",
          "security" : {
            "cors" : true,
            "description" : "Implementations SHALL use TLS 1.3 and implement OAuth 2.0 Client Credentials flow for authentication. MBI and other PHI must be protected according to HIPAA requirements."
          },
          "resource" : [
            {
              "type" : "Patient",
              "documentation" : "Patient resource for ACCESS alignment operations",
              "operation" : [
                {
                  "name" : "align",
                  "definition" : "https://globalalliantinc.com/access/OperationDefinition/Align|0.9.0",
                  "documentation" : "Align a patient to an ACCESS participant for a specific track. Requires at least one Condition resource. Enforces 3-month lock-in period. Supports provider switching with switchConsentAttestation parameter after lock-in expires. Automatically creates notification subscriptions upon successful alignment. Returns alignment status from ACCESSAlignmentResultVS: aligned, aligned-switch-approved, not-aligned-control-group, not-aligned-already-aligned, not-aligned-not-medicare, not-aligned-services, or not-aligned-diagnoses. Implements asynchronous processing with HTTP 202 Accepted response containing Content-Location header for status polling."
                },
                {
                  "name" : "submission-status",
                  "definition" : "https://globalalliantinc.com/access/OperationDefinition/SubmissionStatus|0.9.0",
                  "documentation" : "Poll the status of a previously submitted alignment request. Returns HTTP 202 while processing or HTTP 200 with result when complete."
                }
              ]
            }
          ]
        }
      ]
    }