Lesson 0008

Version Coverage Without Rewriting History

The practical product skill: model insurance changes across time so old visits, eligibility checks, and submitted claims stay auditable.

Your Tangible Win

After this lesson, you should be able to choose the safest write pattern when insurance facts change: EFFECTIVE, OBSERVED, SNAPSHOT, or CORRECT.

Primary source to read after the lesson: CMS Electronic Health Care Claims.

The Core Idea

Insurance data has at least three clocks. A coverage fact has an effective date range. An eligibility response has an observation time. A claim has a submission time and submitted payload. Bugs happen when a product overwrites one clock with another.

CMS describes claims moving through front-end edits, implementation-guide edits, coverage/payment edits, correction, rejection, denial, and acknowledgment workflows (CMS Electronic Health Care Claims). That workflow only stays explainable if the product can reconstruct what facts were true for the service date, what the payer said during eligibility, and what was actually submitted.

The Four Write Patterns

Pattern Use When Invariant
EFFECTIVE A coverage fact changes over real-world dates: member ID, payer, plan, relationship, priority. Never overwrite the old range if an old visit still depends on it.
OBSERVED A payer or clearinghouse returns eligibility, claim status, rejection, or remittance data. Store what was observed, when, from whom, and the raw response.
SNAPSHOT A claim leaves your system or enters an external adjudication path. Freeze the submitted insurance facts for that claim version.
CORRECT A submitted claim was wrong and must be fixed. Create an explicit corrected version or resubmission path; do not mutate the old submission silently.

Three Clocks

Service Date

The date the clinical service happened. Coverage active checks must answer: active for this date?

Observed At

The moment your system received an external response. Eligibility is evidence captured at this time.

Submitted At

The moment a claim version was sent. The submitted payload should remain reconstructable.

Mini Case

A patient has payer A for January and payer B starting February 1. Registration updates the coverage in March. A January claim rejects because the product generated it from the current coverage row and sent payer B.

Product diagnosis: this is an effective-date and snapshot failure. Coverage should have date-bounded versions, and claim generation should choose coverage by service date before freezing the submitted claim snapshot.

Design Rule

Use append-only history for external-facing facts. If a downstream party saw it, or a past service date depends on it, preserve it and create a new version for change.

Question Safe Answer
Which coverage applies to this encounter? Coverage version whose effective range contains the service date.
What did eligibility say? The dated raw and parsed response from that payer check.
What did we send? The immutable claim insurance snapshot for that claim version.
How do we fix a submitted error? Create a corrected claim version linked to the earlier submission.

Scenario Practice

Choose the safest model action. These are harder than recall: each question asks which invariant prevents a subtle revenue-cycle bug.

1. A January claim was submitted. In March, registration updates the coverage record. What prevents the January claim from appearing to have used March's data?
2. Member ID changed on February 1. January visits must use the old ID; March visits must use the new ID. Which write pattern fits?
3. A biller validates an old encounter from January while working in April. Which date should drive active-coverage selection?
4. A 271 says coverage appears active, but the claim later denies for missing authorization. How should the 271 be modeled?
5. A claim was submitted with the wrong subscriber relationship. The payer rejected it before adjudication. What is the safest model action?
6. Support asks, "What exactly did the clearinghouse return before we parsed it?" Which storage pattern answers that?

What to Ask Me Next

Ask follow-up questions when you want this translated into implementation. Good next questions: "What SQL constraints enforce these clocks?", "How should claim versions relate to coverage versions?", or "What should correction workflow states be?"

For review, keep the temporal insurance model nearby.