FHIR APIs for Health Plans

The Cloud Health Office payer API reference: FHIR R4 APIs for CMS-0057-F interoperability, prior authorization, terminology, and administration workflows — with OpenAPI 3.1 specs, OAuth 2.0 / SMART on FHIR security, and Da Vinci-aligned resource profiles. Run them locally or deploy into your own environment.

What is the Cloud Health Office FHIR API?

The Cloud Health Office FHIR API is a set of HL7 FHIR R4 interfaces built for payer interoperability and administration, not a generic FHIR server. It exposes CMS-0057-F-oriented capabilities — Patient Access, Provider Access, Payer-to-Payer, and Prior Authorization — secured with SMART on FHIR/OAuth 2.0, together with FHIR prior authorization workflows (CRD, DTR, PAS), terminology services, and the eligibility, benefits, provider, authorization, and claims domains behind them. Because the administration logic lives in the platform, Cloud Health Office can operate alongside an existing payer core such as QNXT, Facets, or HealthEdge, or serve as the payer backend itself. The external FHIR contract stays the same in either model.

FHIR API Quick Answers

Direct answers to the questions payer architects ask about FHIR APIs, CMS-0057-F, and where Cloud Health Office fits. Each answer stands alone and links deeper where documentation exists.

Payer FHIR API Capabilities

The FHIR surfaces most relevant to health plans, with a readiness label for each. Labels follow the internal CMS-0057-F readiness matrix: Implemented means code and tests exist and the capability can be demonstrated; Integration required means the surface exists but production use depends on wiring payer sources and controls; Phase 2 means known work remains before it should be represented as production-ready.

FHIR Prior Authorization in Cloud Health Office

Prior authorization is a first-class workflow, not a single endpoint. A request flows from the provider's EHR through requirement discovery, terminology translation, and rule evaluation, into documentation and submission, and out to a recorded decision:

• Provider / EHR
• →
• CRD
• →
• Terminology
• →
• Prior Auth Rule Engine
• →
• DTR
• →
• PAS
• →
• Authorization Decision
• →
• Authorization Service

• CRD (Coverage Requirements Discovery) — at order time, tells the provider whether prior authorization and documentation are required, via CDS Hooks. Available for payer-specific rule configuration.
• Terminology services — translate clinical codes (SNOMED CT, LOINC) to the payer's CPT/ICD-10-CM code space via ConceptMap/$translate, so rules and benefits match the request. See the terminology crosswalk guide.
• Prior authorization rules — a rule engine evaluates coverage and medical-necessity policy against the (translated) request to drive the decision path.
• DTR (Documentation Templates and Rules) — collects required clinical documentation using FHIR Questionnaire and QuestionnaireResponse; available as an implementation module with payer-specific questionnaires.
• PAS (Prior Authorization Support) — submits the request through Claim/$submit (per PAS IG v2.1.0) and returns a structured decision; auto-adjudication and pended-status behavior are implemented.
• Authorization decision & service — approval, denial, or request-for-information outcomes are recorded and tracked by the authorization service; decision-window tracking and structured denial/status data are implemented, with payer denial taxonomy and reviewer workflow configured per deployment.

For the architecture in context, see CMS-0057-F with QNXT, Facets, or HealthEdge and the CMS-0057-F insights hub.

A FHIR API Is Only the External Contract

FHIR endpoints standardize how the outside world reaches a plan, but every endpoint is backed by payer business logic and data: eligibility, benefits, provider networks, authorization rules, clinical policy, claims, accumulators, terminology, identity and security, and audit. A FHIR server with no payer logic behind it cannot answer a coverage question or adjudicate a prior authorization. Cloud Health Office supplies that logic, in one of two deployment models.

Two deployment models

Connecting FHIR to Existing Payer Systems

Cloud Health Office does not ship one universal connector for every QNXT, Facets, or HealthEdge environment. Two payers on the same core can have very different data ownership, identity, and utilization-management topologies, so the payer-specific adapter is selected and configured during onboarding. Onboarding identifies:

• Authoritative member source
• Benefit source
• Provider source
• Authorization source
• UM platform
• Claims dependencies
• Integration middleware
• Available APIs
• Event and message infrastructure
• Required write-back

Environments

Environment	Base URL	Auth
Your deployment	https://api.your-domain.example/fhir/r4	OAuth 2.0 (Azure AD)
Hosted pilot	Assigned during pilot setup	Customer tenant identity
Local Dev	http://localhost:3000/fhir/r4	Bearer test-token

OpenAPI docs are available from the local or customer-deployed API surface. All requests require an X-Tenant-ID header for multi-tenant routing.

Authentication

Customer-deployed APIs use OAuth 2.0 with Azure AD (Microsoft Entra ID). The FHIR server publishes a SMART App Launch v2 configuration at /.well-known/smart-configuration with supported scopes including patient/*.read, user/*.read, and system/*.read.

# Discover SMART/OAuth endpoints and supported scopes
curl https://api.your-domain.example/fhir/r4/.well-known/smart-configuration

# Get access token (client credentials)
curl -X POST https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token \
  -d "grant_type=client_credentials" \
  -d "client_id={client_id}" \
  -d "client_secret={client_secret}" \
  -d "scope=api://cloudhealthoffice/.default"

# Read a FHIR resource with the token + tenant header
curl https://api.your-domain.example/fhir/r4/Patient/{id} \
  -H "Authorization: Bearer {access_token}" \
  -H "X-Tenant-ID: {tenant}"

Patient Access API

CMS-9115-F and CMS-0057-F oriented. Enables patients to access their own health data via FHIR, secured with SMART patient scopes.

Endpoint	Method	Description
/Patient/{id}	GET	Patient demographics and contact information
/Coverage?patient={id}	GET	Active benefits and eligibility
/Claim?patient={id}	GET	Claims history (X12 837 → FHIR Claim)
/ExplanationOfBenefit?patient={id}	GET	Payment details (X12 835 → FHIR EOB)
/Encounter?patient={id}	GET	Healthcare visits and services
/Condition?patient={id}	GET	Diagnoses and clinical conditions

Provider Access API

Gives in-network providers access to attributed members' clinical and claims data, with Da Vinci PDex-aligned resource profiles.

Endpoint	Method	Description
/Patient/$member-match	POST	Match patient across payers without sharing raw identifiers
/Group/{id}/$export	POST	Bulk FHIR export for attributed members

Prior Authorization API

Moves prior authorization from phone/fax to real-time FHIR, Da Vinci-aligned across PAS, CRD, and DTR, with bidirectional X12 278 mapping. The PAS Claim/$submit operation is implemented per PAS IG v2.1.0.

Endpoint	Method	Description
/Claim/$submit	POST	Submit prior auth request (X12 278 → FHIR)
/Claim/$inquire	POST	Check prior auth status
/Claim/{id}/$cancel	POST	Cancel existing prior auth
/Subscription	POST	Subscribe to auth status updates

# Submit a prior authorization (Da Vinci PAS Claim/$submit)
curl -X POST https://api.your-domain.example/fhir/r4/Claim/\$submit \
  -H "Authorization: Bearer {access_token}" \
  -H "X-Tenant-ID: {tenant}" \
  -H "Content-Type: application/fhir+json" \
  -d '{"resourceType":"Bundle","type":"collection","entry":[{"resource":{"resourceType":"Claim","use":"preauthorization"}}]}'

# Translate a clinical code to the payer code space (terminology service)
curl "https://api.your-domain.example/fhir/ConceptMap/\$translate?system=http://snomed.info/sct&code=44054006&target=http://hl7.org/fhir/sid/icd-10-cm" \
  -H "Authorization: Bearer {access_token}" \
  -H "X-Tenant-ID: {tenant}"

Payer-to-Payer API

Enables data exchange when members switch health plans, using Bulk FHIR $export and member matching. Payer-to-payer is a Phase 2 implementation workstream (see the capability readiness above), not a turnkey production claim.

Endpoint	Method	Description
/Patient/$member-match	POST	Identify member in source payer system
/Patient/{id}/$everything	GET	Complete member record transfer
/Group/$export	POST	Bulk transfer for member cohorts

# Initiate an asynchronous bulk export (FHIR Bulk Data Access)
curl -X POST https://api.your-domain.example/fhir/r4/Group/{groupId}/\$export \
  -H "Authorization: Bearer {access_token}" \
  -H "X-Tenant-ID: {tenant}" \
  -H "Prefer: respond-async"
# → 202 Accepted with a Content-Location header to poll for job status

Operational APIs

Claims Scrubbing

NCCI/MUE edit checking, CPT validation, diagnosis code verification, and custom payer scrub rules.

Risk Adjustment

HCC (Hierarchical Condition Category) coding and RAF (Risk Adjustment Factor) score calculation for Medicare Advantage and ACA risk adjustment.

Encounter Service

State and federal encounter submission management for Medicaid MCOs, including encounter data validation, submission tracking, and reconciliation.

Planning a Payer FHIR Implementation?

A payer FHIR architecture depends on your specifics: your existing CAPS/core, who owns each data domain, your identity provider, your utilization-management and provider systems, your CMS scope (Medicare Advantage, Medicaid, CHIP, or QHP), and your migration strategy. The FHIR contract is standard; the integration behind it is designed around those answers.