Who we serve › Health plans
Modernization means running old and new side by side for years, while the migration runs. Gaine resolves every entity across both, and keeps every system acting on the result.
Gaine HDMP
For health plans: Gaine HDMP, an operational health data management platform, resolves provider, member, claims, network, contract, enrollment and broker data across the systems you are running now, then delivers reconciled change to the systems that need to act on it.
Where this stops
Mid-migration
A new core admin system for commercial plans goes live for the new year. Members are migrated into it, and the old core stays in place for the runout of past claims.
A member of a health plan gets married to a person covered by the same health insurance company, but under a different product. The employer-sponsored plan that the newly married person is joining is administered in the new core admin platform of the payer, whereas their prior plan was still managed on the legacy platform.
The payer receives an EDI 834 enrollment for the qualifying life event.
The member updates their insurance at their PCP during a check-up, and the provider submits a new claim to the payer.
The provider also informs the patient that they owe $80 from a prior visit, because their insurance did not cover the full amount.
The member calls the insurance company to inquire about the $80.
OutcomeTwo claims systems, member enrollment, member services CRM and the EDW, all potentially misaligned over the course of just a few days because of a single qualifying life event and the inability of any single system to deal with the bigger picture.
Client: New claims system
The new member is enrolled in the claims system. At the end of the day the claims system updates the HDMP in a daily file.
New claims system to HDMP
The new member ID from the claims system is matched and linked to that member’s existing ID and profile in the legacy platform.
Client: Member services CRM
Member services subscribes to event notifications for member ID changes, and applies them to the CRM itself.
HDMP to Member services CRM
Gaine HDMP sends a notification to the member services team to update their CRM, linking the old and new member IDs to a single profile.
Client: New claims system
The new claims system sends its claims to Gaine HDMP in a daily file.
New claims system to HDMP
The new member’s PCP claim is correctly linked to the member’s single integrated profile in Gaine HDMP.
Client: Member services CRM
The CRM calls the HDMP API to show the member’s single profile during the call.
HDMP to and from Member services CRM
Because Gaine HDMP links the member’s old and new IDs to one profile, the agent sees the prior visit’s claim from the legacy platform alongside the new plan. They can explain the $80 in the same call, instead of transferring the member to the legacy team.
Client: EDW
The EDW takes a reconciled change file in its nightly upload.
HDMP to EDW claims analysis
The member spanning two systems, and the provider’s claims for that member, are correctly reconciled by effective date and sent to the EDW for the nightly upload. The EDW is not dependent upon the member services team to make its changes: claims reporting is aligned independently, as it should be.
OutcomeWith Gaine HDMP, the member is tracked across all systems, and downstream systems like CRM and EDW are kept aligned on an ongoing basis.
Illustrative. Each system connects the way it allows, so how far each one aligns differs.
Payer challenges
…the value comes when the corrected data reaches the systems and workflows where the work happens.
01 / Provider & network
Fewer claims affected by bad provider data, less roster rework, and stronger directory accuracy and network adequacy, including provider-directory requirements under the No Surprises Act.
Used for
02 / Claims
Less manual reconciliation, fewer payment discrepancies, and fewer avoidable disputes with providers.
Used for
03 / Member & enrollment
Fewer eligibility-driven claim issues, billing mismatches, call-center contacts and manual correction cycles.
Used for
04 / Broker & commission
Less commission leakage, fewer payment disputes and retroactive corrections, and less reconciliation work for finance.
Used for
Across the plan
Proof and scale
“Consider Gaine when payers want comprehensive, mature data management with an operational data layer that can distribute clean, harmonized data in real time to all of the organization’s systems in the way that they need to consume it.”
How it works
01 / Resolve
Against a healthcare ontology refined over more than fifteen years, without flattening the relationships that give the data its operational meaning.
02 / Reconcile
By rules your team defines, attribute by attribute. Losing values are kept, so anyone can see which value won and why.
03 / Deliver
By the route that system already uses, from direct synchronization to reconciled change files through your own change control.
Every route and gate, survivorship, merge and unmerge, and what happens after a change is suggested. On the architecture page →
Why not build it
A competent data team can write change files. What takes years is the healthcare ontology underneath: the practitioner-location-contract-network-product relationships, effective-dated, with a survivorship history that already absorbs entity types nobody planned for. Gaine has refined that model for more than fifteen years. Your systems integrator can deliver the program on top of it rather than rebuilding it.
Who runs it
Your team runs the platform. Stewards work the exceptions, conflicts where both values are defensible, not the routine flow. If you want help, Gaine or your systems integrator can provide it. Neither is required.
Yours if you leave
The identifiers, the crosswalk, the policies and the runbook belong to you. If you stop using Gaine, the identifiers your systems already carry stay valid. What stops is future resolution, not the record of what was resolved.
Worked example
The answer does not live in one system. It depends on four facts, owned by different systems and different executives, each with its own effective date. Analytics cannot settle the payment. The relationships have to be reconciled, and the payment system has to receive the change.
An agent answering a provider’s question about network status needs the effective-dated relationship between that practitioner, location, contract and network, and the evidence for it. A model is only as good as the record it reasons over: governed, lineaged, resolved in advance and grounded in a healthcare ontology.
Questions
Gaine resolves provider, member, claims, network, contract, enrollment, broker and partner data when old and new systems disagree, then delivers reconciled change to the operational systems that need to act on it.
No. HealthRules Payer, Facets, QNXT, EZ-CAP, credentialing platforms, partner feeds and legacy systems keep their operating roles while Gaine reconciles the data between them.
By the route each target already uses: direct synchronization with systems such as HealthRules Payer, Facets, QNXT, EZ-CAP, symplr and Salesforce; reconciled change files for proprietary systems or systems without an API, run through your own change control; events for systems that subscribe; and direct API access to the platform.
A warehouse can show that two systems disagree. Payer operations improve only when the disagreement is resolved with effective dating and provenance, and the resulting change reaches the claims, directory, enrollment, network or finance workflow that depends on it.
Your team does. Help from Gaine or your systems integrator is available if you want it; neither is required.
