Proactive Updates, Part 4
Time and Time Again
Information Management Online, April 3, 2009
Note: A glossary of technical terms used in these articles can be found on the Web sites of the authors. The URLs are MindfulData.com and InbaseInc.com.
In previous columns, we completed a proactive update transaction against an open episode. This time, we complete our discussion of a proactive update against a closed episode.
Figure 1 shows a closed episode, with a known effective end date. It is the same as the effective end date of its most current version, which happens, in this case, to also be its only version. The episode begins in effective time, on January 1, 2008 and ends on December 31 of that year. The current time in the example is May 1, 2008.
Advertisement
Figure 1: A Closed Episode and a Proactive Update - Before Image
This transaction will do a couple of things. First, it will update the episode's type and co-pay amount, effective August 1. Next, it will extend the effective time of the episode out to March 1, 2009. These are the two override dates specified on the transaction. But because no override is specified for the assertion begin date, these changes will be asserted immediately.
Let us be clear about what is happening. The changes to type and co-pay are not going to take effect immediately. Also, the extension of the episode to March 1 is not going to take effect immediately. What will happen immediately is that we will begin to assert that the current episode of policy P861 will have a type of point of sale and a co-pay of $10 beginning on August 1 (three months from now). And, on that same date, the end date for this episode of the policy will change from December 31 to February 28.
If this were a conventional table, we would talk about the policy itself. And so our discussion of these transactions may be a little easier to follow if we talk about their targets as policies rather than as episodes of policies. This terminological shorthand, however, doesn't really change anything. There is no such thing in an asserted version table as an object with no episode; there cannot be a policy but no policy episode. Additionally, if there are multiple episodes of an object, we always know which episode we are talking about, because the three asserted version dates that are specified or defaulted to on a transaction will always pick out a unique episode.
With this in mind, we can rephrase a couple of the things we said above as follows. This transaction will update the policy's type and co-pay amount, effective on August 1. Next, it will extend the effective time of the policy out to March 1, 2009. And, what will happen immediately is that we will begin to assert that policy P861 will have a type of POS and a co-pay of $10 beginning on August 1, and on that same date, the end date for that policy will be changed from December 31 to February 28.
Withdrawing the Current Assertion
Figure 2: A Closed Episode and a Proactive Update - Current Assertion Withdrawal
We begin to implement the original update transaction with the first temporal transaction resulting from the mapping of that original update. This first temporal transaction withdraws an assertion currently in the table that is no longer true. As Figure 2 illustrates that assertion is the one made by row 1 - the assertion that the business data in that row describes policy P861 from 1/01/08 to 12/31/08. Because the original update transaction specifies changes that will take effect on 8/01/08, the assertion made by row 1 is no longer true.
We withdraw row 1 on the same date that we begin to assert what is going to replace it. That date is the current date, 5/01/08. The withdrawal is carried out by overwriting the assertion end date that was on row 1 and replacing it with the date 5/01/08. This says that we stopped making this assertion yesterday, on April 30.
We continue the graphical convention described in earlier articles, with respect to withdrawn assertions. The box representing that row is moved up into the gray area over the calendar line, and because the assertion time no longer extends into the indefinite future, we change its representation from an arrow to a line. That assertion line is shown ended on 5/01/08.
Asserting Its Before-Image Replacement
Having withdrawn our assertion of the current version of the episode, we now insert its replacement. We are going to replace it with a version that extends to when the new version will go into effect (August 1). The business data will be the same as it was on the version we just withdrew, because the update leaves that data unchanged until August 1. This before-image replacement is shown in Figure 3.
Figure 3: A Closed Episode and a Proactive Update - Before-Image Replacement
Page 1 of 2.
