Databases Reference
In-Depth Information
The next event in the life of this policy occurred in November
2011. It took place as part of the same event in which client C882
was reinstated. On that date, a second episode of client C882
began, and a second episode of policy P861 began also, and was
designated as a policy owned by C882. After that, three changes
occurred to the policy between November 2011 and January
2013, but none of them changed the ownership of the policy.
The fifth event in the life of the policy was that client C882
asked to terminate her relationship with our company as of
January 2013. Since she owned P861 at that time, and would still
own it on that termination date, the policy was terminated along
with the client.
Four months later, on May 2013, policy P861 was reinstated
and assigned to client C902. So a third episode of the policy
was created, P861-C. It was an open-ended episode, one with
an effective end date of 12/31/9999, and so the only owner that
could be assigned to it would be one with an open-ended epi-
sode that began on or before May 2013. Fortunately, client
C903 had such an episode, having been reinstated, after a
5-month absence, with episode C903-C.
With this information as part of our production data, we
know, at any point in the history of policy P861, who its owner
was and when and for how long she had been the owner.
For any claims submitted for medical services provided to either
C903 or C882, no matter how delayed the filing of those claims
may have been, we know exactly when each client was covered
by that policy and exactly when she was not covered by it—an
essential piece of information needed to pay claims correctly.
And we don't have to go digging in archival storage, or histor-
ical data warehouses, for that information—which, in a high
transaction volume claims processing system, is a very good
thing. That historical data exists in the same table as data about
current policies and their current owners. The service date on
the claim selects the correct version of the policy, and that ver-
sion points to its owner. If its owner is not the person for whom
the claim is submitted, the claim is rejected.
Foreign Keys and Temporal Foreign Keys
Before proceeding, let's remind ourselves of the difference
between (i) foreign keys (FKs), the relationships they implement
and the constraints they impose, and (ii) temporal foreign keys
(TFKs), the relationships they implement and the constraints
they impose.
