Member enrollment for health plans
A member changes plans. Their history should not split.
Each time a member moves between products, lines of business or core administration systems, a new system issues a new ID. Gaine HDMP cross-references every ID to one member, effective-dated, so claims, member services and the warehouse see one history while the old core runs out.
One member, every ID
| System | The ID it holds | Valid |
|---|---|---|
| Legacy core administration | Medicaid member ID | To December 31, 2025 |
| New core administration | Exchange plan member ID | From January 1, 2026 |
| State Medicaid | Medicaid ID on the state’s 834 | To December 31, 2025 |
| Prior health plan | Member ID from the member’s previous plan | Before 2024 |
| Member services CRM | Contact record | Throughout |
| Gaine HDMP | One member, with every ID cross-referenced and dated | |
Illustrative.
A change of plan, without and with Gaine
Without Gaine HDMP
- January 1
A member’s Medicaid coverage ends and they enroll in the plan’s exchange product, administered in the new core. The new core issues a new member ID.
- January 8
Member services sees two people: a Medicaid member on the legacy platform and a new exchange member.
- February
A claim for a December visit arrives under the old Medicaid ID. The warehouse counts two members, and neither record shows the whole history.
OutcomeOne person, two members, and no system can see their whole history.
The same change, with Gaine HDMP underneath
- January 1
The exchange enrollment arrives on an 834. Gaine matches it to the member’s existing profile and cross-references the new member ID to the old one, effective-dated.
- January 1
Member services receives an event notification linking both IDs to one profile. The warehouse receives a reconciled change file in its nightly load.
- February
The December claim under the old ID is linked to the same member, so their history stays whole while the old core runs out.
OutcomeOne member, two IDs, one history.
Illustrative. Each system connects the way it allows, so how far each one aligns differs.
The same idea across a core migration: one qualifying life event on the Health plans page →
What stays linked
- Every system ID. Old and new core administration, the state’s Medicaid ID, the member services CRM, and the member ID from a previous health plan.
- Subscribers and dependents. A dependent who moves to their own policy keeps their history.
- The claims behind each ID. When two member records merge, the records that refer to them are re-evaluated, which keeps an old claim attached to the member.
- A way back from a wrong merge. Gaine’s unmerge splits the records and restores each to its state before the merge. Every system that took the merged record is told.
During a migration the old core stays live for runout claims and appeals. The cross-reference keeps its IDs linked for as long as anything still refers to them.
How changes reach your systems
Gaine has built direct API connectors for HealthRules Payer, Facets, QNXT and EZ-CAP. Every other system, such as the pharmacy benefit manager, care management, the member services CRM or the warehouse, takes one of three routes:
- reconciled change files through your own change control;
- event notifications, for systems that subscribe;
- Gaine writes directly to the application API.
Each system can use a different route, on its own cadence. Every change carries the source, the rule and the date behind it, and core administration remains your system of record for eligibility.
Enrollment sources
- EDI 834: taken directly, or from your EDI gateway system.
- Custom member rosters: from employer groups and BPO partners.
- Government and exchange files: state Medicaid intermediaries, exchange platforms, and CMS monthly membership and transaction reply reports.
- Your own systems: old and new core administration, and the member services CRM.
Systems Aligned
- Core administration: HealthRules Payer, Facets, QNXT, EZ-CAP (direct API connectors).
- Downstream: pharmacy benefit manager, care management, member services CRM and the enterprise data warehouse, each by its own route.
Proof
Regional payer: member enrollment
EDI 834 and multiple custom member roster formats, absorbed through the gateway under strict data-quality audit. In place for open enrollment.
1M+ members · ACA and Medicare · 1,200 hours over 6 months
Further reading
Questions
Do we have to renumber members?
No. Each system keeps its own IDs. Gaine holds the cross-reference and sends it to the systems that subscribe.
What happens if two members were merged by mistake?
Gaine’s unmerge splits the records and restores each to its state before the merge. Every system that took the merged record is told.
Does this still matter after we switch the old core off?
Yes, for as long as runout claims, appeals and reporting refer to the old IDs.
More on member enrollment
Coverage by date
A state 834 ends a member’s coverage two months back. Gaine holds coverage as effective-dated spans, so every system receives the same end date, and the claims paid since are listed.
Explore →834 in, change out
Enrollment arrives as 834s, custom rosters and CMS reports. Gaine reconciles each against the member record and sends every system its change, while core administration stays in charge of eligibility.
Explore →