“Is this covered?” sounds like a lookup. It is four unresolved questions wearing a trench coat: which member, covered under which plan on which date, against which version of the claim, from which provider.
- Business problem
- “Is this covered?” sounds like a lookup. It is four unresolved questions: which member, under which plan on which date, against which version of the claim, from which provider.
- Why it matters
- Member identifiers change while the person does not. Eligibility is an interval, not a flag. Claims restate themselves after the fact, and provider identity is its own resolution problem. Leave those unsettled and no model recovers — member-facing AI answers confidently and wrongly.
- Architecture response
- Canonical member and provider identity, bitemporal eligibility and claim history, storage that preserves restatements instead of overwriting them, field-level provenance, and context assembled for a stated purpose. Settle those four questions and most member-facing AI questions become answerable.
- What Databright Cloud Solutions does
- We design canonical member and provider identity, bitemporal eligibility and claim history, restatement-preserving storage, field-level provenance, and the purpose-scoped context assembly member-facing AI depends on.
We have written at length about why fragmented property records defeat AI: identity, semantics, temporal truth, provenance, evidence, and rights.5 Member data fails the same way. The vocabulary differs; the structure of the failure does not.
A member is not one identifier
A single person accumulates identifiers relentlessly. A member ID from the plan. A different one after the employer changed carriers. A subscriber ID that belongs to a spouse. A medical record number per health system, sometimes per facility. A claim-level patient reference. A pharmacy identifier. None is stable across all of them, and several change while the person does not.
The consequences are concrete. Continuity of history breaks at every carrier change, so a member with eight years of history appears to have two. Dependents get merged with subscribers because the subscriber ID is the join key that was available. Two records for the same person diverge, and an AI assistant answers confidently from whichever it retrieved.
The resolution problem is familiar from any domain where the identifier is not the thing.3 What is specific here is the cost asymmetry: a false split loses history, while a false merge discloses one person’s information to another. Those are not equivalent errors, and the matching threshold should not pretend they are.
Eligibility is an interval, not a flag
Systems love a boolean. Coverage is not one.
A member is covered under a plan for a span, with a start, sometimes an end, and frequently a retroactive adjustment. Terminations get backdated to the last day worked. Enrollment gets applied weeks after the fact. Plan years change benefits mid-relationship. A member can be simultaneously covered under two plans with a coordination-of-benefits order that itself changes.
That is the same bitemporal problem that governs any record where facts and knowledge of facts arrive on different schedules.4 A current-state eligibility table cannot answer a question about a service six months ago, and an AI assistant reading one will answer anyway.
Claims restate themselves
A claim is not an event. It is a sequence of assertions about an event, and later assertions supersede earlier ones.
Claims are submitted, rejected, corrected, resubmitted, adjusted, reversed, and reprocessed. Amounts change after the fact through coordination of benefits, retroactive eligibility, and payment integrity review. The version that is current today may not be the version that was current when a member was told something on a call.
Collapse that history into a current-state table and two capabilities disappear at once: you cannot explain why a member was told something different in March, and you cannot audit a decision made against the data as it stood. Both are routine requests.
Provider identity has the same problem
The other side of the claim is no simpler. A practitioner has a national identifier. So does the organization. A practitioner works at several locations, bills under multiple group arrangements, joins and leaves networks, and appears in directories with inconsistent names and addresses.
“Is this provider in network?” therefore decomposes into a specific practitioner, at a specific location, under a specific contract, on a specific date — and answering it with an entity-level lookup produces a confident answer that is wrong for the member standing in the office.
The member’s own history is a source
Member communications — calls, secure messages, letters, portal activity — are usually treated as operational exhaust. For member-facing AI they are primary context, and they are the only record of what the member was actually told.1
An assistant that can see the claim but not the three calls about the claim will contradict the organization’s own prior answers, which is worse than being unable to answer at all. Bringing that history into scope has to respect purpose and minimum necessary, which is a governance design as much as an integration one.26
The same questions, a different domain
Identity, time, versioning, and provenance are not property-data problems or healthcare problems. They are what it takes to make any consequential record answerable by a machine.
The encouraging consequence is that the work transfers. A canonical entity model, bitemporal storage, retained restatements, and field-level provenance are the same capabilities whether the record describes a parcel or a person — and they are what turns a member-facing assistant from a demo into something an organization will stand behind.
Resolve the person before the identifier, and weight a false merge far more heavily than a false split. Store eligibility as intervals with the dates you learned them. Keep every claim restatement rather than the latest. Resolve providers at the practitioner-location-contract-date level. Then bring the member’s own communication history into scope, under an explicit purpose.
Sources and industry references
- HHS Office for Civil Rights — HIPAA Privacy Rule guidance materials
- HHS — Minimum Necessary Requirement: reasonable efforts to limit use, disclosure, and requests for protected health information
- Databright Cloud Solutions — The Property Identity Problem: why an identifier is not the thing it names
- Databright Cloud Solutions — The Temporal Truth Problem: what was true, when it became true, and when we knew it
- Databright Cloud Solutions — The Data Intelligence Gap: six gaps between raw records and trusted intelligence
- Databright Cloud Solutions — Redaction Is Not Governance: running AI workflows on PHI
This article provides data-architecture and engineering perspectives. It is not legal, compliance, clinical, benefits, or regulatory advice, and nothing here describes how any specific plan, benefit, or eligibility determination should be made. Obligations and data handling requirements depend on your role, your agreements, and facts this article does not address; consult qualified counsel and your privacy officer.