Note: This document references Azure Logic Apps, which were the original orchestration runtime. CHO has since migrated to Argo Workflows on AKS — see ADR-004 for details.

CMS-0057-F Compliance Guide

Cloud Health Office - Comprehensive Support for CMS Prior Authorization Rule

Executive Summary
What is CMS-0057-F?
Cloud Health Office Support
API & Resource Breakdown
Implementation Guides
Compliance Deadlines
Configuration Steps
Payer Compliance Checklist
Technical Specifications
Resources & References

Executive Summary

CMS-0057-F (Advancing Interoperability and Improving Prior Authorization Processes) is a final rule that requires payers to implement specific FHIR APIs to improve prior authorization workflows, reduce provider burden, and enhance patient care coordination.

Cloud Health Office provides a CMS-0057-F implementation accelerator: FHIR R4, SMART-on-FHIR, Da Vinci prior-authorization, Bulk FHIR, consent, and payer integration building blocks that can be deployed beside an existing core administration platform. Production compliance still depends on payer configuration, source-system integration, operating procedures, and legal / compliance attestation.

Key Capabilities

✅ FHIR R4 APIs - Complete implementation of required FHIR APIs
✅ Da Vinci IGs - Support for PDex, PAS, CRD, and DTR profiles
✅ Prior Authorization - End-to-end prior auth workflows (X12 278 ↔ FHIR ServiceRequest)
✅ Claims & EOBs - Full claims lifecycle (X12 837/835 ↔ FHIR Claim/EOB)
✅ Timeline Compliance - 72-hour urgent, 7-day standard response tracking
✅ USCDI Support - Complete USCDI v1 & v2 data class coverage
✅ OAuth 2.0 - Secure authorization with Azure AD integration
✅ Bulk FHIR - Efficient data export for regulatory reporting
✅ Security Foundation - HIPAA-oriented controls, tenant isolation patterns, audit logging, and observability building blocks

Deployment Time

<10 minutes from configuration to live FHIR APIs using Cloud Health Office CLI wizard.

V2 Implementation Status

Readiness note: This guide predates the canonical cross-service readiness matrix and should be read as a technical implementation guide, not a legal compliance attestation. For current status, gaps, and buyer-safe wording, see ../compliance/CMS-0057-F-READINESS-MATRIX.md.

Compliance Dashboard

Requirement	Status	Tests	Implementation Date
Patient Access API	Integration required	FHIR controller and SMART tests	See readiness matrix
Provider Access API	Integration required	Provider directory and SMART tests	See readiness matrix
Payer-to-Payer API	Phase 2 required	Bulk FHIR and consent building blocks	See readiness matrix
Prior Authorization API	Implemented / integration required	PAS/CRD/DTR tests	See readiness matrix
72-Hour Urgent Response	Implemented / integration required	PAS and compliance checker tests	See readiness matrix
7-Day Standard Response	Implemented / integration required	PAS and compliance checker tests	See readiness matrix
USCDI v1/v2 Coverage	Integration required	Resource mapping coverage varies by service	See readiness matrix
Da Vinci IG Conformance	Integration required	PAS/CRD/DTR technical support	See readiness matrix

Total Tests: 45 FHIR-specific tests (100% pass rate)
Total Platform Tests: 355+ tests (100% pass rate)
Security Vulnerabilities: 0 in core mappers

V2 FHIR Transformation Coverage

X12 Transaction	FHIR Resource	Profile	Status
X12 270 Eligibility	Patient, CoverageEligibilityRequest	US Core 3.1.1	✅ Production
X12 837 Claims	Claim	Da Vinci PDex	✅ Production
X12 278 Prior Auth	ServiceRequest	Da Vinci PAS	✅ Production
X12 835 Remittance	ExplanationOfBenefit	Da Vinci PDex	✅ Production
X12 275 Attachments	DocumentReference	US Core	✅ Production

Timeline to Compliance Deadline

┌─────────────────────────────────────────────────────────────────┐
│                    CMS-0057-F Timeline                          │
├─────────────────────────────────────────────────────────────────┤
│                                                                   │
│  ██████████████████████████░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░  │
│  ▲                                                           ▲    │
│  │                                                           │    │
│  Now (Nov 2024)                                 Deadline (Jan 2027) │
│  V2 Complete                                                      │
│                                                                   │
│  18 months ahead of deadline                                      │
│  401 days remaining                                               │
│                                                                   │
└─────────────────────────────────────────────────────────────────┘

Quick Start for V2 FHIR APIs

# Clone and build
git clone https://github.com/aurelianware/cloudhealthoffice.git
cd cloudhealthoffice && npm install && npm run build

# Run FHIR compliance tests
npm run test:fhir

# Deploy with interactive wizard
npm run generate -- interactive --output config.json --generate

# Validate CMS-0057-F compliance
node dist/src/fhir/examples.js

Release Notes: See site/release-notes.html for complete V2 feature breakdown.

What is CMS-0057-F?

The Advancing Interoperability and Improving Prior Authorization Processes final rule (CMS-0057-F), published in March 2023, establishes new requirements for Medicare Advantage, Medicaid, CHIP, and QHP issuers on the federal Marketplaces.

Key Requirements

Patient Access API (FHIR R4)
- Claims and encounters data
- Clinical information via USCDI
- Available within 1 business day of adjudication
Provider Access API (FHIR R4)
- Claims, encounters, clinical data
- Accessible with patient authorization
- Real-time or near-real-time updates
Payer-to-Payer API (FHIR R4)
- Patient data exchange between payers
- 5-year historical data requirement
- Triggered by patient enrollment
Prior Authorization API (FHIR R4)
- Real-time prior auth status
- Supporting documentation via attachments
- Decision rationale and clinical guidelines

Response Time Requirements

Urgent Requests: 72 hours maximum
Standard Requests: 7 calendar days maximum
Extensions: Only when medically justified

Who Must Comply?

Medicare Advantage (MA) organizations
Medicaid Fee-For-Service (FFS) programs
Medicaid managed care plans
CHIP FFS programs
CHIP managed care entities
Qualified Health Plans (QHPs) on federal Marketplaces

Cloud Health Office Support

Cloud Health Office provides end-to-end CMS-0057-F compliance through integrated FHIR R4 APIs, X12 EDI processing, and Azure-native infrastructure.

Architecture Overview

┌─────────────────────────────────────────────────────────────────┐
│                    Cloud Health Office Platform                  │
├─────────────────────────────────────────────────────────────────┤
│                                                                   │
│  ┌──────────────┐      ┌──────────────┐      ┌──────────────┐  │
│  │   X12 EDI    │ ───> │ FHIR Mapper  │ ───> │  FHIR R4 API │  │
│  │ 837/278/835  │      │   Engine     │      │  (Da Vinci)  │  │
│  └──────────────┘      └──────────────┘      └──────────────┘  │
│         │                     │                      │           │
│         │              ┌──────▼──────┐              │           │
│         │              │ Compliance  │              │           │
│         │              │   Checker   │              │           │
│         │              └─────────────┘              │           │
│         │                                            │           │
│         ▼                                            ▼           │
│  ┌──────────────────────────────────────────────────────────┐  │
│  │          Azure API for FHIR / Azure Health Data          │  │
│  │        Services (Optional FHIR Server Integration)        │  │
│  └──────────────────────────────────────────────────────────┘  │
│                                                                   │
│  ┌──────────────────────────────────────────────────────────┐  │
│  │  Azure AD OAuth 2.0 │ Key Vault │ Application Insights   │  │
│  └──────────────────────────────────────────────────────────┘  │
│                                                                   │
└─────────────────────────────────────────────────────────────────┘

Core Components

1. FHIR Mapper (`src/fhir/fhir-mapper.ts`)

Bi-directional transformation between X12 EDI and FHIR R4:

import { mapX12837ToFhirClaim } from './src/fhir/fhir-mapper';

// X12 837 → FHIR Claim
const claim = mapX12837ToFhirClaim(x12_837_data);

// X12 278 → FHIR ServiceRequest (Prior Auth)
const authRequest = mapX12278ToFhirPriorAuth(x12_278_data);

// X12 835 → FHIR ExplanationOfBenefit
const eobs = mapX12835ToFhirEOB(x12_835_data);

Supported Mappings:

837P/I/D → Claim: Professional, Institutional, Dental claims
278 → ServiceRequest: Prior authorization requests and renewals
835 → ExplanationOfBenefit: Remittance advice with adjudications

2. Compliance Checker (`src/fhir/compliance-checker.ts`)

Validates FHIR resources against CMS-0057-F requirements:

import { validateCMS0057FCompliance } from './src/fhir/compliance-checker';

const result = validateCMS0057FCompliance(fhirResource);

console.log(`Compliant: ${result.compliant}`);
console.log(`USCDI Classes: ${result.summary.uscdiDataClasses}`);
console.log(`Timeline Compliance: ${result.summary.timelineCompliance.compliant}`);

Validation Coverage:

Required FHIR elements per resource type
USCDI v1/v2 data class coverage
Timeline requirements (72hr urgent, 7-day standard)
Da Vinci IG profile conformance (PDex, PAS, CRD, DTR)
US Core IG v3.1.1+ requirements

3. Logic Apps Workflows

Production-grade Azure Logic Apps for EDI processing:

ingest278: Process incoming 278 prior auth requests
process_authorizations: Orchestrate authorization workflows
auth_request_outpatient: Outpatient authorization handling
auth_inquiry: Real-time authorization status checks
rfai277: Request for Additional Information (RFAI) outbound
ingest275: Attachment processing for clinical documentation

4. CLI Deployment Wizard

Zero-code deployment in <10 minutes:

# Interactive wizard mode
npm run generate -- interactive --output my-config.json --generate

# Deploys:
# - FHIR API endpoints
# - Prior authorization workflows  
# - Compliance validation
# - OAuth 2.0 security
# - Azure infrastructure

API & Resource Breakdown

Patient Access API

Purpose: Provide patients access to their claims, encounters, and clinical data.

Applicable To: MA, Medicaid managed care, CHIP managed care, QHP issuers

Deadline: January 1, 2027

Supported FHIR Resources

Resource	Description	CHO Support	Da Vinci Profile
Patient	Demographics, identifiers	✅ Full	PDex Patient (US Core)
Coverage	Insurance coverage details	✅ Full	PDex Coverage
Claim	Professional/Institutional claims	✅ Full	PDex Claim
ExplanationOfBenefit	Adjudicated claims with payment details	✅ Full	PDex ExplanationOfBenefit
Encounter	Healthcare encounters	✅ Full	US Core Encounter
Condition	Diagnoses and problems	✅ Mapped	US Core Condition
Procedure	Clinical procedures	✅ Mapped	US Core Procedure
MedicationRequest	Prescriptions	🔄 Roadmap	US Core MedicationRequest
Observation	Lab results, vitals	🔄 Roadmap	US Core Observation

Implementation:

X12 837 Claims → FHIR Claim (via mapX12837ToFhirClaim)
X12 835 Remittance → FHIR ExplanationOfBenefit (via mapX12835ToFhirEOB)
X12 270 Eligibility → FHIR Patient + Coverage (via mapX12270ToFhirEligibility)

OAuth 2.0 Security:

Patient authentication via Azure AD B2C (configurable)
SMART on FHIR scopes: patient/*.read
Token-based access control

Provider Access API

Purpose: Enable providers to access patient data with authorization.

Applicable To: All impacted payers

Deadline: January 1, 2027

Supported FHIR Resources

Same as Patient Access API, plus:

Resource	Description	CHO Support
ServiceRequest	Prior authorization requests	✅ Full
Task	Prior auth decision tracking	🔄 Roadmap
DocumentReference	Clinical documents, attachments	✅ Full

Implementation:

X12 278 Prior Auth → FHIR ServiceRequest (via mapX12278ToFhirPriorAuth)
X12 275 Attachments → FHIR DocumentReference (ingest275 workflow)

OAuth 2.0 Security:

Provider authentication via Azure AD
SMART on FHIR scopes: user/*.read, system/*.read
NPI-based authorization

Payer-to-Payer API

Purpose: Exchange patient data when enrolling with new payer.

Applicable To: MA, Medicaid managed care, CHIP managed care, QHP issuers

Deadline: January 1, 2027

Implementation

Cloud Health Office supports payer-to-payer exchange via:

FHIR Bulk Data Export ($export operation)
5-year historical data retention (configurable via Azure Data Lake lifecycle policies)
Automated data transfer on enrollment events

Configuration:

{
  "payerToPayerExchange": {
    "enabled": true,
    "dataRetentionYears": 5,
    "bulkExportEnabled": true,
    "triggerOnEnrollment": true
  }
}

Prior Authorization API

Purpose: Real-time prior auth status and supporting documentation.

Applicable To: All impacted payers

Deadline: January 1, 2027

Da Vinci Prior Authorization Support (PAS)

Cloud Health Office implements the Da Vinci PAS IG:

Feature	Description	CHO Support
ServiceRequest	Prior auth request	✅ Full
Claim	Auth context (for updates)	✅ Full
ClaimResponse	Auth decision response	✅ Full
Task	Workflow tracking	🔄 Roadmap
DocumentReference	Supporting clinical docs	✅ Full

Response Times:

Urgent: 72 hours (tracked via compliance-checker.ts)
Standard: 7 calendar days
Automatic timeline validation and alerting

X12 Integration:

Inbound: X12 278 Request → FHIR ServiceRequest
Outbound: FHIR ClaimResponse → X12 278 Response
Attachments: X12 275 → FHIR DocumentReference

Implementation Guides

Cloud Health Office aligns with the following HL7 Da Vinci Implementation Guides:

1. PDex (Payer Data Exchange)

Purpose: Standardized FHIR profiles for payer-sourced data.

Version: 2.0.0+

CHO Implementation:

US Core Patient profile v3.1.1+
PDex Claim and ExplanationOfBenefit
Coverage and MedicationDispense
Full USCDI v1 & v2 data classes

Profiles Used:

http://hl7.org/fhir/us/davinci-pdex/StructureDefinition/pdex-claim
http://hl7.org/fhir/us/davinci-pdex/StructureDefinition/pdex-eob
http://hl7.org/fhir/us/core/StructureDefinition/us-core-patient

2. PAS (Prior Authorization Support)

Purpose: Streamline prior authorization exchange between providers and payers.

Version: 2.0.1+

CHO Implementation:

ServiceRequest for authorization requests
ClaimResponse for authorization decisions
DocumentReference for attachments
Timeline compliance (72hr urgent, 7-day standard)

Profiles Used:

http://hl7.org/fhir/us/davinci-pas/StructureDefinition/profile-servicerequest
http://hl7.org/fhir/us/davinci-pas/StructureDefinition/profile-claim
http://hl7.org/fhir/us/davinci-pas/StructureDefinition/profile-claimresponse

3. CRD (Coverage Requirements Discovery)

Purpose: Inform providers of coverage requirements during workflow.

Version: 2.0.0+

CHO Integration:

CDS Hooks support (roadmap)
Real-time coverage rules
Documentation requirements discovery

4. DTR (Documentation Templates and Rules)

Purpose: Automate clinical documentation collection.

Version: 2.0.0+

CHO Integration:

Questionnaire-based data collection (roadmap)
FHIR Questionnaire and QuestionnaireResponse
Automated form generation from payer rules

Compliance Deadlines

Timeline Summary

Requirement	Applicable Payers	Deadline	Cloud Health Office Status
Patient Access API	MA, Medicaid MC, CHIP MC, QHP	January 1, 2027	Integration required
Provider Access API	All impacted payers	January 1, 2027	Integration required
Payer-to-Payer API	MA, Medicaid MC, CHIP MC, QHP	January 1, 2027	Phase 2 required
Prior Auth API	All impacted payers	January 1, 2027	Implemented / integration required
Prior Auth Decisions API	All impacted payers	January 1, 2027	Implemented / integration required
72-Hour Urgent Response	All impacted payers	January 1, 2027	Implemented / operational integration required
7-Day Standard Response	All impacted payers	January 1, 2027	Implemented / operational integration required

Implementation Recommendations

18 Months Before Deadline (July 2025):

✅ Complete Cloud Health Office deployment
✅ Configure Azure AD OAuth 2.0
✅ Test FHIR API endpoints
✅ Validate compliance with compliance-checker

12 Months Before Deadline (January 2026):

✅ Integrate with existing authorization systems
✅ Train provider partners on FHIR API access
✅ Establish monitoring and alerting
✅ Conduct end-to-end testing

6 Months Before Deadline (July 2026):

✅ Production deployment and hardening
✅ Load testing and performance optimization
✅ Compliance audit and documentation
✅ Provider onboarding campaigns

January 1, 2027:

Payer-specific CMS-0057-F production posture validated, attested, and operational

Configuration Steps

Prerequisites

Azure subscription with appropriate permissions
Azure AD tenant (for OAuth 2.0)
FHIR server (Azure API for FHIR or Azure Health Data Services) - optional
Node.js 18+ and npm
PowerShell 7+ (for deployment scripts)

Step 1: Clone and Install

git clone https://github.com/aurelianware/cloudhealthoffice.git
cd cloudhealthoffice
npm install
npm run build

Step 2: Configure Azure AD OAuth 2.0

2.1 Create Azure AD App Registration

# Create app registration for Patient Access API
az ad app create \
  --display-name "CHO-PatientAccess-API" \
  --sign-in-audience "AzureADandPersonalMicrosoftAccount" \
  --web-redirect-uris "https://your-app.azurewebsites.net/oauth/callback"

# Note the Application (client) ID
APP_ID=$(az ad app list --display-name "CHO-PatientAccess-API" --query [0].appId -o tsv)
echo "Application ID: $APP_ID"

2.2 Configure API Scopes

Add custom scopes in Azure Portal:

Navigate to App registrations → Your app → Expose an API
Add scopes:
- patient/*.read - Read access to patient data
- user/*.read - Provider read access
- system/*.read - System-level access for bulk operations

2.3 Configure Authentication

Patient Access: Azure AD B2C with social identity providers
Provider Access: Azure AD with organizational accounts
System Access: Managed identity or service principal with client credentials flow

Step 3: Deploy Infrastructure

# Deploy using interactive wizard
npm run generate -- interactive --output payer-config.json --generate

# Or deploy from existing config
az deployment group create \
  -g your-resource-group \
  -f generated/infrastructure/main.bicep \
  -p baseName=cho-prod environment=prod

What Gets Deployed:

Azure Logic Apps Standard (FHIR API endpoints)
Azure Data Lake Storage Gen2 (PHI storage)
Azure Service Bus (event-driven workflows)
Azure Key Vault (secrets management)
Application Insights (monitoring)
Integration Account (X12 processing)

Step 4: Configure FHIR Server (Optional)

If using Azure API for FHIR:

# Create FHIR service
az healthcareapis service create \
  --resource-group your-rg \
  --resource-name cho-fhir \
  --kind fhir-R4 \
  --location eastus

# Get FHIR URL
FHIR_URL=$(az healthcareapis service show \
  --resource-group your-rg \
  --resource-name cho-fhir \
  --query "properties.authenticationConfiguration.audience" -o tsv)

echo "FHIR URL: $FHIR_URL"

Configure managed identity access:

# Grant Logic App access to FHIR
LOGIC_APP_IDENTITY=$(az webapp identity show \
  --resource-group your-rg \
  --name cho-logicapp \
  --query principalId -o tsv)

az role assignment create \
  --role "FHIR Data Contributor" \
  --assignee $LOGIC_APP_IDENTITY \
  --scope /subscriptions/{sub-id}/resourceGroups/your-rg/providers/Microsoft.HealthcareApis/services/cho-fhir

Step 5: Deploy Workflows

# Deploy Logic App workflows
cd logicapps
zip -r ../workflows.zip workflows/

az webapp deploy \
  --resource-group your-rg \
  --name cho-logicapp \
  --src-path workflows.zip \
  --type zip

# Restart Logic App
az webapp restart --resource-group your-rg --name cho-logicapp

Step 6: Configure X12 Integration

# Configure Integration Account with X12 schemas and agreements
./setup-integration-account.ps1 -ResourceGroup your-rg -IntegrationAccountName cho-ia

# Configure trading partners
./configure-x12-agreements.ps1 -ResourceGroup your-rg -ConfigPath config/trading-partners.json

Step 7: Validate Compliance

# Run compliance validation
npm run build
node dist/src/fhir/examples.js

# Test FHIR endpoints
curl -H "Authorization: Bearer $TOKEN" \
  https://cho-logicapp.azurewebsites.net/api/fhir/Patient/12345

# Validate compliance
npm run test:fhir

Step 8: Enable Monitoring

# Configure Application Insights alerts
az monitor metrics alert create \
  --name "Prior-Auth-Timeline-Violation" \
  --resource-group your-rg \
  --scopes "/subscriptions/{sub-id}/resourceGroups/your-rg/providers/Microsoft.Web/sites/cho-logicapp" \
  --condition "avg customMetrics/PriorAuthResponseTime > 72" \
  --window-size 1h \
  --evaluation-frequency 15m \
  --action-group alert-action-group

Payer Compliance Checklist

Pre-Implementation

Identify applicable requirements based on payer type (MA, Medicaid, CHIP, QHP)
Assess current systems for FHIR readiness and X12 integration
Allocate resources for implementation (budget, personnel, timeline)
Select FHIR server (Azure API for FHIR recommended)
Establish Azure environment (subscription, resource groups, networking)

Technical Implementation

Deploy Cloud Health Office via CLI wizard or Azure Deploy button
Configure OAuth 2.0 with Azure AD for patient and provider access
Set up X12 integration with trading partners (Clearinghouse, Navinet, etc.)
Deploy FHIR endpoints for Patient Access, Provider Access, and Prior Auth APIs
Implement payer-to-payer exchange with bulk FHIR export
Configure response timelines (72hr urgent, 7-day standard)
Enable compliance validation using compliance-checker.ts

Data & Content

Map data sources (claims system, authorization system, clinical data)
Transform X12 to FHIR using mapper module
Validate USCDI coverage (demographics, diagnoses, procedures, medications)
Populate historical data (5-year requirement for payer-to-payer)
Implement decision rationale for prior authorizations
Add clinical guidelines references for denials

Security & Compliance

HIPAA compliance (PHI encryption, audit logging, access controls)
OAuth 2.0 security (patient consent, provider authorization)
Data retention policies (7-year minimum, lifecycle management)
Penetration testing and security audit
Disaster recovery and backup strategies
Compliance audit trail in Application Insights

Testing & Validation

Unit testing for FHIR transformations
Integration testing for end-to-end workflows
Load testing for production scalability
Compliance testing with validation suite
Provider UAT with sample scenarios
Patient UAT with test accounts

Monitoring & Operations

Application Insights dashboards for FHIR API metrics
Timeline monitoring for prior auth responses (72hr/7-day SLAs)
Error alerting for failed API calls
Performance monitoring for response times
Compliance reporting for regulatory audits
Incident response procedures

Provider & Patient Enablement

Provider onboarding documentation and training
Patient education materials for accessing data
API documentation (Swagger/OpenAPI specs)
Developer portal for third-party app integration
Support channels (help desk, technical support)

Regulatory & Documentation

CMS attestation of compliance (as required)
Implementation Guide alignment documentation
Privacy policies updated for FHIR APIs
Terms of service for API access
Audit trail documentation for regulatory review

Technical Specifications

FHIR Version

FHIR R4 (v4.0.1)
Intentionally not using R4B or R5 for compatibility with Da Vinci IGs

Supported USCDI Versions

USCDI v1 / v2: a FHIR R4 read path exists for each clinical data class below. That is resource coverage, not certified conformance: US Core profile validation and the US Core SHALL search set are not implemented, and are not claimed.
USCDI v3: Roadmap (future support)

USCDI Data Classes

Read this column as "is there a real read path?", not as a conformance claim. The clinical rows are served as valid FHIR R4 with no US Core profile declared — see clinical-fhir.md §15 for why that distinction is drawn explicitly rather than papered over.

Data Class	FHIR Resources	CHO Support
Patient Demographics	Patient	✅ Served; US Core Patient profile declared and asserted
Problems / Health Concerns	Condition	✅ Served (read + `patient`/`subject` search); R4, no US Core profile claimed
Procedures	Procedure	✅ Served (read + `patient`/`subject` search); R4, no US Core profile claimed
Medications	MedicationRequest, MedicationDispense	✅ Served (read + `patient`/`subject` search); R4, no US Core profile claimed
Laboratory	Observation, DiagnosticReport	✅ Served (read + `patient`/`subject` search); R4, no US Core profile claimed
Vital Signs / Smoking Status	Observation	✅ Served (read + `patient`/`subject` search); R4, no US Core profile claimed
Allergies and Intolerances	AllergyIntolerance	✅ Served (read + `patient` search); R4, no US Core profile claimed
Immunizations	Immunization	✅ Served (read + `patient` search); R4, no US Core profile claimed
Care Team	CareTeam	✅ Served (read + `patient`/`subject` search); R4, no US Core profile claimed
Assessment and Plan of Treatment	CarePlan	✅ Served (read + `patient`/`subject` search); R4, no US Core profile claimed
Goals	Goal	✅ Served (read + `patient`/`subject` search); R4, no US Core profile claimed
Unique Device Identifiers	Device	✅ Served (read + `patient` search); R4, no US Core profile claimed
Clinical Notes	DocumentReference	✅ Served (via X12 275)
Provenance	Provenance	✅ Tracked in resource metadata (`meta.source`, `meta.versionId`); no `Provenance` resource is served
Health Insurance Info	Coverage	✅ Served
Coverage	Coverage, ExplanationOfBenefit	✅ Served

What "served" does and does not mean for the clinical rows. Every clinical resource CHO serves today arrived through a Payer-to-Payer exchange — no CHO component authors native clinical data yet, so a deployment with no prior-payer history has no clinical data to serve. Search support is _id, patient and subject where R4 defines it; category, code, status and date searches are not implemented and are not advertised in the CapabilityStatement.

Coding Systems

System	Use Case	CHO Support
ICD-10-CM	Diagnoses	✅ Full
CPT	Procedures	✅ Full
HCPCS	Procedures, supplies	✅ Full
LOINC	Lab tests, vitals	🔄 Roadmap
RxNorm	Medications	🔄 Roadmap
SNOMED CT	Clinical concepts	🔄 Roadmap
NUBC	Claim types	✅ Full
X12	Transaction codes	✅ Full

Security Standards

OAuth 2.0 with SMART on FHIR
TLS 1.2+ for transport encryption
AES-256 for data at rest encryption
Azure Key Vault for secrets management (HSM-backed)
HIPAA Security Rule compliance
HITECH Breach Notification compliance

Performance Requirements

API Response Time: <500ms (p95)
Bulk Export: <1 hour for 1M resources
Concurrent Users: 1,000+ supported
Prior Auth Timeline: 72hr urgent, 7-day standard (automated tracking)
Uptime SLA: 99.9% (Azure Logic Apps Standard)

Resources & References

CMS Regulations

CMS-0057-F Final Rule: Federal Register
CMS Prior Authorization Overview: CMS.gov
CMS Interoperability Roadmap: CMS Interoperability

HL7 FHIR Specifications

FHIR R4 Specification: http://hl7.org/fhir/R4/
US Core IG v3.1.1: http://hl7.org/fhir/us/core/STU3.1.1/
US Core IG v6.1.0 (latest): http://hl7.org/fhir/us/core/
USCDI v2: ONC USCDI

Da Vinci Implementation Guides

PDex (Payer Data Exchange): http://hl7.org/fhir/us/davinci-pdex/
PAS (Prior Authorization Support): http://hl7.org/fhir/us/davinci-pas/
CRD (Coverage Requirements Discovery): http://hl7.org/fhir/us/davinci-crd/
DTR (Documentation Templates and Rules): http://hl7.org/fhir/us/davinci-dtr/
CDex (Clinical Data Exchange): http://hl7.org/fhir/us/davinci-cdex/

X12 Standards

X12 837: Health Care Claim (Professional, Institutional, Dental)
X12 278: Health Care Services Review (Prior Authorization)
X12 835: Health Care Claim Payment/Advice (Remittance)
X12 275: Additional Information to Support a Health Care Claim (Attachments)
ASC X12: https://x12.org/

Azure Documentation

Azure API for FHIR: Microsoft Learn
Azure Health Data Services: Microsoft Learn
Azure Logic Apps Standard: Microsoft Learn
Azure AD OAuth 2.0: Microsoft Identity Platform
SMART on FHIR: https://smarthealthit.org/

Cloud Health Office Documentation

FHIR Integration Guide: docs/FHIR-INTEGRATION.md
Security Hardening: ../SECURITY-HARDENING.md
HIPAA Compliance Matrix: docs/HIPAA-COMPLIANCE-MATRIX.md
Deployment Guide: ../DEPLOYMENT.md
Config-to-Workflow Generator: docs/CONFIG-TO-WORKFLOW-GENERATOR.md

Industry Resources

HL7 International: https://www.hl7.org/
Da Vinci Project: http://www.hl7.org/about/davinci/
CARIN Alliance: https://www.carinalliance.com/
ONC (Office of the National Coordinator): https://www.healthit.gov/

Support

For questions about CMS-0057-F compliance with Cloud Health Office:

GitHub Issues: https://github.com/aurelianware/cloudhealthoffice/issues
Documentation: https://github.com/aurelianware/cloudhealthoffice
Community: Join discussions on implementation strategies and best practices

Cloud Health Office – Production-Ready CMS-0057-F Compliance

Source-Available | Azure-Native | FHIR R4 | Da Vinci IGs | <10 Minute Deployment

Uh oh!

FilesExpand file tree

CMS-0057-F-COMPLIANCE.md

Latest commit

History

CMS-0057-F-COMPLIANCE.md

File metadata and controls

CMS-0057-F Compliance Guide

Table of Contents

Executive Summary

Key Capabilities

Deployment Time

V2 Implementation Status

Compliance Dashboard

V2 FHIR Transformation Coverage

Timeline to Compliance Deadline

Quick Start for V2 FHIR APIs

What is CMS-0057-F?

Key Requirements

Response Time Requirements

Who Must Comply?

Cloud Health Office Support

Architecture Overview

Core Components

1. FHIR Mapper (src/fhir/fhir-mapper.ts)

2. Compliance Checker (src/fhir/compliance-checker.ts)

3. Logic Apps Workflows

4. CLI Deployment Wizard

API & Resource Breakdown

Patient Access API

Supported FHIR Resources

Provider Access API

Supported FHIR Resources

Payer-to-Payer API

Implementation

Prior Authorization API

Da Vinci Prior Authorization Support (PAS)

Implementation Guides

1. PDex (Payer Data Exchange)

2. PAS (Prior Authorization Support)

3. CRD (Coverage Requirements Discovery)

4. DTR (Documentation Templates and Rules)

Compliance Deadlines

Timeline Summary

Implementation Recommendations

Configuration Steps

Prerequisites

Step 1: Clone and Install

Step 2: Configure Azure AD OAuth 2.0

2.1 Create Azure AD App Registration

2.2 Configure API Scopes

2.3 Configure Authentication

Step 3: Deploy Infrastructure

Step 4: Configure FHIR Server (Optional)

Step 5: Deploy Workflows

Step 6: Configure X12 Integration

Step 7: Validate Compliance

Step 8: Enable Monitoring

Payer Compliance Checklist

Pre-Implementation

Technical Implementation

Data & Content

Security & Compliance

Testing & Validation

Monitoring & Operations

Provider & Patient Enablement

Regulatory & Documentation

Technical Specifications

FHIR Version

Supported USCDI Versions

USCDI Data Classes

Coding Systems

Security Standards

Performance Requirements

Resources & References

CMS Regulations

HL7 FHIR Specifications

Da Vinci Implementation Guides

X12 Standards

Azure Documentation

1. FHIR Mapper (`src/fhir/fhir-mapper.ts`)

2. Compliance Checker (`src/fhir/compliance-checker.ts`)