CMS Compliance
This guide helps you understand the requirements of CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F) and how the Orchestrate platform helps you meet them.
Note
This guide reflects capabilities of the Orchestrate platform as a whole. Compliance with specific CMS requirements will depend on which Orchestrate APIs you use and your overall system configuration/workflows.
Summary of Requirements
The CMS regulations specify the required APIs and their capabilities, which include the United States Core Data for Interoperability (USCDI) data set.
| API |
Requirements |
| Patient Access API |
Claims/encounters. USCDI clinical data, and prior authorizations. Dates of service on/after Jan 1, 2016. |
| Provider Access API |
Claims/encounters, USCDI clinical data, and prior authorizations. Dates of service on/after Jan 1, 2016. |
| Payer-to-Payer API |
Claims/encounters, USCDI clinical data, and prior authorizations. Dates of service within 5 years of the request by the new/concurrent payer. |
- Each API must include “all data classes and data elements included in a content standard at 45 CFR 170.213 (USCDI)” that the payer maintains.
- Currently, 170.213 incorporates USCDI v1 (valid until Jan 1, 2026) and USCDI v3.
- After Jan 1, 2026, payers must make available all data classes and elements in USCDI v3.
The cross-cutting capabilities of the Orchestrate platform provide a solid infrastructure that can be adapted and extended when real-world needs arise. These capabilities include:
SMART on FHIR Authorization
Patient-mediated access uses SMART App Launch (OAuth 2.0 Authorization Code with PKCE). System-to-system access uses SMART Backend Services (JWT client assertion). OAuth endpoints are discoverable from each FHIR endpoint’s CapabilityStatement.
Discovery & versioning
Each FHIR endpoint advertises a CapabilityStatement listing versions, auth endpoints, resources, and operations. We support FHIR R4 (4.0.1).
Bulk Access
For provider-facing and operational use cases, Orchestrate supports patient-bulk-export and group-bulk-export operations with NDJSON output, consistent with the HL7 Bulk Data Implementation Guide.
Provider Directory
The Provider Directory API (FHIR R4) allows payers to meet their requirements for a public directory of network providers.
Audit Trail Integrity
The AuditEvent resource reports discrete events, including HTTP requests, creation/modification of FHIR resources of system objects, issuing an access token, etc. Modification of AuditEvent is disallowed to preserve the audit trail.
Terminology Services
The Orchestrate Terminology API provides classify/translate operations over standard value sets and concept maps. The Orchestrate Server does automatic terminology mapping. This ensures consistent coding in Patient Access payloads, aligned with USCDI expectations.
Identity & Attribution Support
The Orchestrate platform uses the Identity API to perform Privacy-Preserving Record Linking (PPRL) using HMAC/SHA-256 with client-specific keys. Demographics are irreversibly hashed at rest and can be blinded client-side. This supports member matching for Payer-to-Payer and Provider Access flows.
Normalization Pipeline
Leveraging the Convert API, Orchestrate can ingest HL7 v2, C-CDA, X12, and other formats, and output FHIR R4 bundles. Consolidate/combine bundles and uplift maintain a coherent longitudinal record before exposure via the APIs.
USCDI Clinical Data Requirements
Orchestrate supports FHIR R4 resources, including those defined by the FHIR US Core Profiles (Patient, Encounter, etc.). US Core provides the FHIR representation of USCDI clinical data required for CMS-mandated APIs, as described in the FHIR USCDI guide.
Payer Data - Claims, EOB, Prior Authorization
Orchestrate supports payer-focused resources such as Claim and ExplantionOfBenefit, which are defined through implementation guides like CARIN Blue Button and Da Vinci PDex. Orchestrate can also surface prior authorization information when present in the payer’s systems (via ExplanationOfBenefit resources), including when the payer is utilizing Da Vinci PAS for electronic prior authorization.
Standards Currency
CMS permits the use of updated standards and implementation guides when certain conditions are met. Orchestrate’s R4/US Core posture and CapabilityStatement-driven discovery fit this forward-compatible model.
CMS-0057 Capabilities
The following table summarizes how Orchestrate meets the system capabilities required by CMS-0057.
| Capability |
Orchestrate Implementation |
Standards / Implementation Guides |
| Clinical data - Patient Access |
Exposes payer-maintained USCDI data via US Core resources available for DOS on/after Jan 1, 2016. |
45 CFR 170.213 (USCDI v1 → v3), US Core IG on FHIR R4 |
| Clinical data - Provider Access |
Shares payer-maintained USCDI data with in-network providers available for DOS on/after Jan 1, 2016. |
45 CFR 170.213, US Core IG |
| Clinical data - Payer-to-Payer |
Exchanges USCDI data between payers for requests within 5 years. |
45 CFR 170.213, US Core IG |
| HL7 Bulk Data, Claims & EOB for Patient Access |
Supports ExplanationOfBenefit, Claim, Coverage, and Encounter resources. |
FHIR R4, CARIN mappings where applicable |
| Prior authorization data |
Exposes prior auth status/reason fields when available. |
FHIR R4, Da Vinci PAS (where implemented) |
| Patient/member-facing FHIR API |
Offers FHIR R4 endpoints, with OAuth discovery via CapabilityStatement. |
FHIR R4 (4.0.1), SMART App Launch, OpenID Connect 1.0 |
| OAuth2 / SMART app auth |
Provides discoverable endpoints for user apps with Authorization Code (+PKCE). |
SMART App Launch 1.0.0, OAuth2, OIDC |
| Server-to-server auth |
Implements SMART Backend Services (with JWT client assertion). |
SMART Backend Services |
| API discovery |
CapabilityStatement advertises auth endpoints, resources, and operations. |
FHIR CapabilityStatement |
| Bulk/population access |
Offers patient and group bulk export (NDJSON). |
HL7 FHIR Bulk Data (Flat FHIR) - recommended for scale |
| US Core alignment |
Implements US Core IG (the USCDI mapping surface). |
US Core IG (maps USCDI to FHIR) |
| Source → FHIR normalization |
Converts HL7v2, C-CDA, X12 to FHIR R4 Bundle, including combining bundles and uplifting data. |
HL7 v2, C-CDA, X12, FHIR R4 |
| Terminology normalization |
Provides classify/translate operations to standard vocabularies |
FHIR Terminology resources (CodeSystem, ValueSet, ConceptMap) |
| Provider directory |
Provides access to list of network providers. |
FHIR R4 |
| Audit trail & provenance |
AuditEvent and Provenance resources provide a robust audit trail. |
FHIR R4 AuditEvent, Provenance |
Security Program
CareEvolution is dedicated to building a platform you can trust. Our systems, trusted by customers in government and industry, are designed to meet rigorous security and privacy standards including:
- NIST SP 800-53 Rev. 5 (FISMA Moderate + Privacy)
- HITRUST Certified (e1)
- HIPAA
- FDA 21 CFR Part 11
- NIH Authorization to Operate
For more details on our security program, visit our Trust Center.