Bitemporal: Definition and Healthcare Context
Full name: Bitemporal Data Modeling
Bitemporal data modeling can record two time dimensions: valid time — when a fact applied — and transaction time — when it was recorded. Historical reconstruction works only when prior rows were actually retained. Fonteum's production history is source-specific, not a universal provider timeline.
- Source file
- Not reported
- Published
- Not reported
- Retrieved
- Not reported
- Snapshot
- Not retained for this reference page
- Data as of
- Not reported
How it’s used
- CMS NPPES NPI Registry: NPPES publishes weekly and monthly files, so a provider's recorded address has both a real-world effective date and a capture date Fonteum stores separately.
- A properly populated append-only store can retain prior versions instead of overwriting them; the presence of bitemporal columns alone does not prove that history exists.
- Fonteum as-of reads can return only captured versions after tracking began. On July 12, closed rows existed for UK sanctions, procurement awards, OFAC, UN sanctions, and a small provenance-claim set.
Frequently asked questions
- What is bitemporal data?
- Bitemporal data can track valid time and transaction time. History is reconstructable only for versions the system retained.
- What is the difference between valid time and transaction time?
- Valid time is when a fact actually held in the real world; transaction time is when the system learned and recorded it. They differ whenever data is recorded late or corrected after the fact.
- Why does provider data need bitemporal modeling?
- Federal sources can revise records. An as-of query helps only where prior captured versions exist; it cannot recreate dates before tracking or gaps in retained history.
Related terms
Explore in Fonteum
How Fonteum sources, resolves, and publishes data tied to this term.