Health Insurance Business Information Model

A Provider Is Four Different Things Depending on Who Is Asking

Health Insurance Business Information Model is a structured inventory of the business data entities a health plan runs on — member, subscriber, group, plan, benefit, provider, claim, authorization — organized into foundational, transactional and informational layers, in an editable Word document with a guide to business data modeling.

Health plans carry two identity problems at once. On the member side, the person receiving care, the person who holds the coverage, and the person the employer enrolled may not be the same, and the relationship changes with every life event. On the provider side, the practitioner who delivered the service, the facility where it happened, the group that employs them and the entity that gets paid are four distinct things that plans routinely store as one.

The consequences are ordinary and expensive: a directory that lists a doctor at an address they left, a claim denied because the billing entity is not the credentialed one, an authorization approved for a member identifier that no longer resolves.

This model states those entities separately. It is a business information model rather than a database design — it names what the plan means, which is the layer where the confusion originates and the only layer where it can be resolved.

The Distinctions This Is Meant to Make

Three definitional problems specific to payer data.

Member, subscriber, or patient? The subscriber holds the coverage, the member is covered under it, and the patient received the service. A dependent is all three in different sentences, and plans that model only one field spend years reconciling the other two.

Provider, practitioner, facility, or payee? Credentialing applies to a practitioner, contracting to a group, service to a location, and payment to a tax entity. Collapsing them is the root of most directory and claim-routing defects.

Plan, benefit, or coverage? A plan is sold, a benefit is designed, and coverage is what applies on a given date for a given member. Effective dating belongs to the third, and is usually attached to the first.

Why This Matters Now

Interoperability requirements assume clean entities that most plans have never formally defined.

Directory Accuracy Is an Entity Problem

Provider directory requirements are enforced against data. Accuracy is not achievable while practitioner, location and payee live in one record.

Data Exchange Standards Need a Business Model Behind Them

Exchanging data in a standard format still requires knowing what your own entities mean. The standard specifies the envelope, not your definitions.

Core Administration Replacement Is Mapped, Not Migrated

Moving between administration platforms means reconciling two vendors' member and provider structures. A business model gives both a common target.

What Is Included

Two files:

Who This Is Built For

This model pairs with the Health Insurance Capability Model, which states what a plan does; the information model states what it does it to. Neither substitutes for the other.

How to Put It to Work

• Separate practitioner, location, group and payee in your provider data inventory.
• Attach effective dating to coverage rather than to plan, and see what that changes.
• Use it as the business-language target when mapping between administration platforms.
• Assign stewardship at entity level rather than by system or by report.

Where Plans Typically Start

What You Are Actually Buying Is Time

Producing this internally means definitional workshops across enrollment, network, claims and analytics — four groups whose working definitions genuinely differ because their jobs do.

• You edit rather than originate. The entities and definitions are drafted; your effort goes to your lines of business, your network arrangements, and your terminology.
• Arguing with a draft is faster. A workshop given a proposed definition converges quickly. The same workshop given a blank page spends its time on scope.
• It stays useful. The same model serves a directory program, a platform migration, and a governance rollout.

Those first two columns describe what comparable efforts tend to involve, not a quoted benchmark — your figures depend on scope and who does the work.

Built From Real Engagements

We are software entrepreneurs and business consultants who have delivered business architecture and transformation work across financial services firms. This model is the distilled, reusable output of that work rather than a theoretical exercise — which is also why it carries the limits described below.

An Honest Note on Fit

This is a generic model designed as a starting point. Customization is expected, not a sign that something went wrong.

Specifically:

Terms You Should Know Before Purchasing

Read the description above in full before you buy. Delivery is immediate and the files are yours to keep, which is also why we cannot take returns, issue refunds, or swap a purchase for a different product once it has been downloaded. What you receive is what is listed — no warranty beyond that, and no bundled customization, implementation help, or support. A Enterprise License covers everyone inside one organization; if you intend to reuse the material across several clients, the Consultancy License is the one you need. The full digital product terms govern the sale.