Eligibility & Enrollment Guide

End-to-end guide to eligibility and enrollment in Cloud Health Office — from 834 enrollment file processing through real-time 270/271 eligibility verification, PCP assignment, and member coverage lifecycle management.

Overview

Cloud Health Office eligibility and enrollment spans four interconnected areas that manage the full member lifecycle from initial enrollment through real-time eligibility verification:

Eligibility data is the foundation for every downstream process in Cloud Health Office. Claims adjudication begins with an eligibility check (Step 1), prior authorization validates member coverage before evaluating clinical criteria, and premium billing relies on accurate enrollment counts for invoice generation.

1. Member Enrollment

Member enrollment creates and maintains the member records that drive eligibility, claims, and financial processing. Members are enrolled through multiple channels, with the X12 834 EDI file being the most common high-volume source.

Enrollment Channels

Enrollment Source	Format	Typical Volume	Processing SLA
834 EDI File (Sponsor)	X12 834 Benefit Enrollment	100–50,000+ members per file	24 hours from receipt
834 EDI File (Exchange)	X12 834 via CMS/state exchange	Varies by open enrollment period	24–48 hours
Portal Manual Entry	HTTPS (portal UI)	1–50 members per session	Real-time
FHIR API	FHIR R4 Patient + Coverage	1 member per API call	Real-time
State Medicaid File	State-specific flat file or 834	10,000–500,000+ members	48 hours

834 Processing Pipeline

When an 834 enrollment file arrives, the system processes it through a five-step pipeline:

1. File Receipt — 834 file picked up from the configured SFTP directory or received via API. A file-level acknowledgment is generated immediately.
2. Parsing — X12 834 transaction parsed into individual member enrollment records (INS/REF/DTP/NM1 loops). Each member’s maintenance type code (INS01) determines the action: add, change, reinstate, or terminate.
3. Member Match/Create — Parsed records are matched against existing members using configurable match criteria (SSN + DOB, or Member ID, or name + DOB + address). New members are created; existing members are updated.
4. Coverage Activation — Coverage records are created or updated with effective dates, term dates, benefit plan assignment, and coverage tier. PCP assignment is triggered if the member did not select a PCP.
5. 834 Acknowledgment — A response file is generated for the submitting entity confirming successful processing or listing errors for individual records that failed validation.

File Receipt (SFTP / API) → X12 834 Parsing → Member Match / Create (SSN + DOB or Member ID) → Coverage Activation (effective dates, plan, tier, PCP) → 834 Acknowledgment

Member Data Model

Each member record contains comprehensive demographic and relationship data:

Data Category	Fields	Source
Demographics	Name (first, middle, last, suffix), Date of Birth, Sex, SSN (masked), Race/Ethnicity (optional)	834 NM1/DMG segments
Contact	Address (street, city, state, ZIP), Phone (home, mobile, work), Email	834 N3/N4/PER segments
Identifiers	Member ID (system-assigned), Subscriber ID, Medicaid ID, Medicare HICN/MBI, SSN	834 REF segments / system-generated
Relationship	Subscriber/dependent flag, relationship to subscriber (self, spouse, child, other)	834 INS02 segment
Coverage	Benefit plan, coverage tier, effective date, term date, PCP assignment	834 HD/DTP segments

Subscriber / Dependent Hierarchy

Enrollment follows a hierarchical structure:

• Subscriber (policyholder) — The primary enrollee who holds the coverage relationship with the sponsor group. Assigned the subscriber-level Member ID.
• Spouse / Domestic Partner — Dependent enrolled under the subscriber’s coverage. Assigned a unique Member ID but linked to the subscriber’s coverage.
• Child Dependents — Children enrolled under the subscriber. ACA requires coverage of dependents up to age 26. Each child receives a unique Member ID.

All dependents share the subscriber’s benefit plan and coverage tier but maintain individual records for claims, accumulators, and eligibility verification.

Retroactive Enrollment

2. Eligibility Verification (270/271)

Real-time eligibility verification allows providers to confirm a member’s coverage status, benefit plan details, and cost sharing information before rendering services. Cloud Health Office processes inbound X12 270 Eligibility Inquiry transactions and returns X12 271 Eligibility Response transactions.

Verification Flow

1. Provider submits 270 inquiry — Contains member identification (name, DOB, member ID), provider NPI, and the type of eligibility information requested (service type code)
2. Clearinghouse routing — Inbound 270s arrive via Availity, Change Healthcare, or Optum and are routed based on the submitter ID and payer ID in the ISA/GS segments
3. Member lookup — System matches the 270 inquiry to an enrolled member using the submitted identifiers
4. Eligibility evaluation — Coverage status is checked as of the service date; benefit plan details, cost sharing, and PCP information are assembled
5. 271 response generated — Response returned through the originating clearinghouse channel

Provider submits X12 270 → Clearinghouse Routing (Availity / Change Healthcare / Optum) → Member Lookup → Eligibility Evaluation (coverage, benefits, cost sharing, PCP) → X12 271 Response returned

271 Response Content

The 271 response provides comprehensive eligibility and benefit information to the requesting provider:

270 Element	271 Response Element	Source	Notes
Subscriber/Member ID	Member identification echo	Member record	Confirms the member was found
Service Type Code	EB01 — Eligibility/Benefit Info	Coverage record	Active Coverage, Inactive, etc.
Date of Service	Coverage dates (DTP segments)	Coverage record	Effective and term dates for the coverage
N/A	Benefit plan name	Benefit Plan	Plan name and plan ID returned in REF segment
N/A	PCP name and NPI	PCP assignment	Returned in NM1 loop if PCP assigned
N/A	Copay amounts	Cost sharing rules	Per service type (PCP visit, specialist, ER, etc.)
N/A	Deductible remaining	Accumulator (Redis)	Current individual deductible balance
N/A	OOP max remaining	Accumulator (Redis)	Current individual OOP max balance
N/A	Prior auth required flag	Auth-required config	Indicates if the requested service needs prior auth

EB01 Segment Handling

The EB01 (Eligibility or Benefit Information) code in the 271 response indicates the member’s coverage status. Key codes used by Cloud Health Office:

EB01 Code	Meaning	When Returned
1	Active Coverage	Member has active coverage on the date of service
6	Inactive	Member was enrolled but coverage is not active on the date of service (terminated or not yet effective)
I	Non-Covered	Service type requested is not covered under the member’s plan
R	Other/Additional Payer	Member has other insurance; COB information returned
W	Other Source of Data	Eligibility information is available from another source (e.g., state Medicaid portal)

Key Configuration Points

• PCP loop inclusion — Configurable whether PCP name and NPI are included in the 271 response. Some clearinghouses require this; others do not expect it.
• Date qualifier mapping — Maps internal coverage date types to X12 DTP qualifier codes (e.g., 346 = Plan Begin, 347 = Plan End, 348 = Benefit Begin)
• EB01 code mapping — Maps internal coverage statuses to EB01 codes. Customizable per clearinghouse if specific clearinghouses require non-standard mappings.
• Accumulator inclusion — Configurable whether real-time deductible and OOP balances are included in the 271 response (requires Redis accumulator lookup)

FHIR Coverage API

In addition to X12 270/271, Cloud Health Office exposes real-time eligibility via the FHIR R4 Coverage resource:

• FHIR Coverage read — GET /fhir/Coverage/{id} returns the member’s coverage record including plan, period, and class (group, plan, subplan)
• FHIR Coverage search — GET /fhir/Coverage?beneficiary={patient-id}&status=active returns all active coverages for a member
• Da Vinci CRD integration — The CRD CDS Hooks service uses the FHIR Coverage API internally to check eligibility during the order-sign hook evaluation
• Provider Access API — The CMS-0057-F Provider Access API uses FHIR Coverage for member eligibility queries

3. PCP Assignment

For HMO and POS plans (and some Medicaid programs), each member must be assigned a Primary Care Provider (PCP). The PCP serves as the member’s primary point of care and, in HMO plans, the gatekeeper for specialist referrals.

Assignment Methods

Assignment Method	Trigger	Effective Date	Constraints
Member Selection	Member selects PCP during enrollment (834 or portal)	Coverage effective date	PCP must be in plan network; panel must have capacity
Auto-Assignment	Member does not select PCP within configured window (e.g., 15 days)	Coverage effective date	System selects based on proximity, capacity, language, specialty
PCP Change (Member)	Member requests PCP change via portal or phone	1st of following month (configurable)	New PCP must be in plan network; one change per month (configurable)
PCP Change (System)	Current PCP leaves network or terminates	Immediate or end of month	System auto-reassigns; member notified of change

Auto-Assignment Logic

When a member does not select a PCP, the auto-assignment algorithm evaluates candidates based on a weighted scoring model:

1. Geographic proximity (weight: 40%) — Distance from the member’s residential address to the provider’s practice location. Closer providers score higher.
2. Panel capacity (weight: 25%) — Percentage of the provider’s maximum panel that is currently filled. Providers with more available capacity score higher.
3. Language match (weight: 20%) — Whether the provider speaks the member’s preferred language. Exact match scores highest; partial match (e.g., bilingual staff) scores medium.
4. Specialty match (weight: 15%) — For specific populations (e.g., pediatric members assigned to pediatricians, pregnant members assigned to OB/GYN-capable PCPs).

The highest-scoring eligible provider is assigned. If all candidates in the member’s area are at capacity, the assignment is escalated to the enrollment operations team for manual resolution.

Panel Capacity Tracking

Each PCP has a configured maximum panel size that limits the number of members who can be assigned:

• Panel maximum — Configurable per provider (typical range: 1,500–2,500 for adult PCPs; 1,000–2,000 for pediatricians)
• Current panel count — Real-time count of active member assignments
• Capacity alerts — System alerts network management when a provider reaches 85% and 95% of panel capacity
• Hard cap enforcement — Assignments are blocked when the provider reaches 100% capacity (unless overridden by an authorized user)

PCP-to-Network Validation

The assigned PCP must be a participating provider in the member’s plan network. The system validates:

• Provider is in the member’s plan network on the coverage effective date
• Provider’s specialty qualifies as a PCP specialty (Family Medicine, Internal Medicine, Pediatrics, General Practice — configurable per plan)
• Provider is currently accepting new patients (not on a temporary enrollment hold)

4. Coverage Lifecycle

Coverage records track the full lifecycle of a member’s enrollment from initial activation through termination. The lifecycle supports standard enrollment, qualifying life events, COBRA continuation, and retroactive changes.

Coverage Statuses

Status	Description	Claims Processing	Premium Billing
Pending	Enrollment received but not yet activated (e.g., future effective date, awaiting premium payment)	No	No
Active	Coverage is in effect; member is eligible for services	Yes	Yes
Suspended	Coverage temporarily paused (e.g., non-payment grace period, pending eligibility redetermination)	Pend to queue	Yes (during grace period)
Terminated	Coverage has ended; member is no longer eligible	No (except runout period)	No

Effective / Term Dating

• Effective date — The date coverage begins. Can be first of the month, date of qualifying event, or retroactive date depending on enrollment rules.
• Term date — The date coverage ends. Null for open-ended coverage (member remains enrolled until actively terminated). For fixed-term coverage (e.g., annual Exchange plans), the term date is set at enrollment.
• Runout period — After the term date, a configurable runout period (typically 90–180 days) allows claims with dates of service during the covered period to be processed.

COBRA Continuation Coverage

COBRA (Consolidated Omnibus Budget Reconciliation Act) provides continuation coverage after a qualifying event (job loss, reduction in hours, divorce, etc.):

• Qualifying events — Voluntary/involuntary termination, reduction in hours, divorce/legal separation, death of subscriber, dependent aging out
• Election period — Member has 60 days from the qualifying event notice to elect COBRA continuation
• Premium — Member pays the full premium (employer + employee portions) plus a 2% administrative fee
• Duration — 18 months for most qualifying events; 36 months for divorce, death, or dependent aging out
• Tracking — COBRA coverage is tracked as a separate coverage segment linked to the original enrollment. The member retains the same benefit plan but changes to a COBRA-specific billing arrangement.

Special Enrollment Periods

Outside of open enrollment, members can enroll or change plans during Special Enrollment Periods (SEPs) triggered by qualifying life events:

Event	Coverage Action	Effective Date Logic	Downstream Impact
Marriage	Add spouse; change plan if desired	1st of month following event	Premium billing updated; new member eligibility created
Birth / Adoption	Add newborn/adopted child	Date of birth/adoption (retroactive)	Newborn auto-enrollment; retroactive claim reprocessing if needed
Loss of Other Coverage	New enrollment or plan change	1st of month following loss	COB records updated; eligibility effective immediately
Relocation	Plan change if new area has different plan options	1st of month following move	Network and PCP may change based on new service area
Medicaid/CHIP Loss	New Exchange/commercial enrollment	1st of month following Medicaid termination	60-day SEP window per ACA rules

Disenrollment

Members can be disenrolled (terminated) through several mechanisms:

• Voluntary disenrollment — Member requests to end coverage (e.g., obtaining coverage elsewhere). Effective end of month or per plan rules.
• Involuntary disenrollment (non-payment) — After the grace period is exhausted (ACA: 90 days for Exchange plans with APTC; varies by state for Medicaid), coverage is terminated retroactively to the end of the first month of non-payment.
• Involuntary disenrollment (fraud) — Coverage terminated upon determination of enrollment fraud. May be retroactive to the enrollment date.
• Retroactive disenrollment — Term date is set in the past (e.g., member was not eligible during a period). Triggers retroactive claim reversal for claims paid during the ineligible period.

Newborn Enrollment

Getting Started

Recommended setup order for a new health plan implementation:

1. Configure member ID assignment rules — Define the member ID format and auto-generation rules
2. Set up 834 file ingestion — Configure the SFTP path, sponsor/exchange mapping, and member match criteria
3. Configure 270/271 clearinghouse routing — Map submitter IDs and payer IDs for Availity, Change Healthcare, Optum, etc.
4. Define PCP auto-assignment rules — Set the assignment window, scoring weights, and panel capacity thresholds
5. Configure coverage lifecycle rules per LOB — Set grace periods, runout periods, COBRA parameters, and SEP rules
6. Process a test 834 file — Submit a sample enrollment file and verify member creation, coverage activation, and PCP assignment
7. Submit a test 270 and verify the 271 response — Confirm eligibility information, copay/deductible details, and PCP data are returned correctly

Related Documentation