1. Member ID Is Scoped
A member ID is not globally meaningful. It must be scoped to payer, plan when known, subscriber, and coverage.
Lesson 0007
Model Insurance Facts with Invariants
The practical product skill: decide which entity owns an insurance fact so edits do not silently break eligibility, claims, or payment posting.
Your Tangible Win
After this lesson, you should be able to route common insurance facts into six data entities: PAT, SUB, COV, ELG, AUT, or CLM.
Primary source to read after the lesson: CMS MLN Claim Completion for CMS-1500 and 837P.
The Core Idea
The dangerous model is one table called patient_insurance that tries to own every insurance fact. It hides whether a field is about the patient, the subscriber, the payer coverage, a dated eligibility response, an authorization, or a submitted claim.
CMS separates successful professional claim submission information into health care professional or supplier information, patient information, and payer information (CMS MLN Claim Completion). CMS also treats patient identity, insurance card data, insured ID, eligibility, and prior authorization as distinct claim-prep facts (CMS patient information, CMS insurance and authorization).
The Six Entities
| Code | Entity | Owns | Must Not Own |
|---|---|---|---|
| PAT | Patient | Person who received care: name, DOB, sex, address, patient account. | Policyholder assumptions or payer-specific member identity. |
| SUB | Subscriber | Person whose insurance coverage is used when different from the patient. | Service dates, claim decisions, or payer benefit output. |
| COV | Coverage | Payer, plan, member ID, relationship, priority, and active date range. | Raw eligibility responses or final payment outcomes. |
| ELG | Eligibility Check | Dated 270/271 observation for a coverage, service date, and payer. | A permanent truth that the future claim will be paid. |
| AUT | Authorization | Payer-issued approval or reference number for a specific service context. | General proof that all services are covered. |
| CLM | Claim Snapshot | Frozen copy of the insurance facts submitted on a specific claim version. | A live pointer that changes when registration edits coverage later. |
Invariants That Save You
2. Service Date Rules
Coverage active checks use the service date. Do not use today's date when validating an old visit or corrected claim.
3. Eligibility Is Evidence
An eligibility check can update confidence and tasks. It must not flip a claim into paid or guaranteed state.
4. Claims Freeze Facts
When a claim is submitted, store a claim snapshot. Later registration edits should create a corrected version, not mutate history.
5. Authorization Is Specific
Prior authorization belongs to payer, coverage, service, and date context. It is not a permanent patient flag.
6. Raw Responses Stay Raw
Keep raw payer or clearinghouse responses alongside parsed fields so support can audit what the system actually received.
Mini Case
A biller submits a claim for a January visit. In March, registration updates the patient's coverage because the card on file was wrong. The product stores only a live coverage_id on the claim, so the already-submitted January claim now appears to have been sent with March's corrected insurance.
Product diagnosis: this is a claim snapshot invariant failure. The submitted claim needs frozen insurance facts, plus a separate correction or resubmission path if the old claim was wrong.
Minimal Model Sketch
| Table | Example Fields | Invariant |
|---|---|---|
coverages |
patient_id, subscriber_id, payer_id, member_id, relationship, active_from, active_to |
Cannot validate without payer, member ID, relationship, and service-date fit. |
eligibility_checks |
coverage_id, service_date, requested_at, raw_response, parsed_status |
Observation only. Never means adjudicated or paid. |
authorizations |
coverage_id, payer_id, auth_number, service_type, valid_from, valid_to |
Must be service and date scoped. |
claim_insurance_snapshots |
claim_id, payer_id, member_id, subscriber_json, coverage_json, eligibility_check_id |
Immutable after submission except through an explicit claim version. |
Retrieval Practice
Type the entity code from memory: PAT, SUB, COV, ELG, AUT, or CLM.
What to Ask Me Next
Ask follow-up questions whenever you want to turn this into implementation. Good next questions: "How would you design these tables in SQL?", "Which fields should be immutable?", or "How do I version coverage changes?"
For review, keep the insurance entity invariants reference nearby.