The 
and 
fields in the 
enable the use of a "log style" append-only data model to track all changes to each 
, providing full traceability. Once released, a row in any of these files will always remain unchanged. Historic data is supplied in the 
dating back to the first release in 
format in 2002.
In order to change the properties of a current a new version of that component is created with the same identifier. This done by adding a new row to the relevant release file, with the column values updated to represent the changes. The field must be set to true and the timestamp in the field indicating the nominal date on which the new version was released. Note that the existing row is not changed in any way.
To inactivate a 
a new row is added, containing the same data as the final valid version of the but with the field set to false and the timestamp in the fi the nominal date of the release in which the final version ceased being valid. Note again that the existing row is not changed in any way.
Where editorial policy does not allow a particular property of a to be changed whilst keeping the same 
the as a whole is inactivated (as described above), and a new row added with a new id, the set to the nominal date of the release in which this version of the became valid, and the field set to true.
It is thus possible to see both the current values and any historical values of a at any point in time.
New content, changes and inactivations must have the for the release that it appears in. Pre-releases for testing may set the effectiveTime as the date of the future scheduled release but in general the effectiveTime must not be later that the scheduled release data, Where there is a business requirement for specifying a future activation date for some 
this may be represented using 
example demonstrates how the history mechanism works on the 
, but the same rules apply equally well to the 
and 
member files. In this example, the 
associated with the 
and 
have been shown in place of their 
values.
A new 
(101291009) is ad 2007:
History Example - Concept Added |
In the following release (on anuary 2008), the is moved from |Module 1| to |Module 2|. Because the moduleId field is not immutable, the may be updated simply by adding a new record with the same Id.
History Example - Module Change |
Id |
| |
|
|
|---|
101291009 | 20070701 | 1 | | |
101291009 | 20080101 | 1 | | |
In the following release (on 1st July 2008), the is changed from being 
to being 
History Example - Definition Status Changed |
Id |
| |
|
|
|---|
101291009 | 20070701 | 1 | | |
101291009 | 20080101 | 1 | | |
101291009 | 20080701 | 1 | | |
In the following release (on nuary 2009), the is deactivated:
History Example - Concept Made Inactive |
Id |
| |
|
|
|---|
101291009 | 20070701 | 1 | | |
101291009 | 20080101 | 1 | | |
101291009 | 20080701 | 1 | | |
101291009 | 20090101 | 0 | | |
Notes
At no stage in this process are previously written records ever amended. Once a record has been released in a 
it will continue to be released in exactly the same form in future 
Changes are only recorded at the point of release in the If a record is changed a number of times between releases (during an edit and review process), only the most recently amended record will be appended to the not individual records showing each separate edit to the released 
In the last example, as well as inactivating the concept (active=0), the is changed from 
to 
. In practice this change is not essential since the value of data columns is ignored when a is inactive. Although the change is unnecessary and insignificant, it typically occurs since all the relationships of an inactive concept must also be inactive, and as a result, from the perspective of the authoring environment the concept cannot be regarded as 
.
Related Links