Examples of non-timeline data

Before going on to look at timelines in more detail, a cautionary note about data that tends not to be suitable for timelines.

Certain types of data are not suited to timelines, as the data does not vary over time. Common examples include:

Unique identifiers
One of the features of a unique identifier is it intentionally does not vary over time, for example each person might be assigned a unique social security number. The social security number should be modeled as a Number, not a Timeline<Number>. By contrast, a person's name may vary over time, e.g. due to marriage or change of name by deed poll, which is one of the reasons it is a poor choice as an identifier (along with lack of uniqueness);
Dates
Data of type date does not vary over time¹. For example, a person's date of birth is one particular date, and so should be modeled as a Date, not as a Timeline<Date>. Dates may be used to construct a Timeline (e.g. a person's date of birth and date of death would be used to construct a Timeline<Boolean> for whether the person is alive, but the dates themselves are not Timelines).
Point-in-time data
Some data intentionally captures data which applies to a particular date only. For example, a data item for surnameAtBirth should be modeled as a String, not a Timeline<String>. A data item for incomeAtRetirement should be modeled as a Number, not a Timeline<Number>

CAUTION:

It is very important when modeling data to be clear about whether the data item does indeed vary over time. Only use Timeline for data items where the value can vary over time.

¹ In Cúram, certain pieces of data, such as Evidence, may have two kinds of history stored:

A history of successions of data regarding changes of circumstances in the real world, i.e. where an event occurs in the real world which means the system's representation of that data is now out-of-date, e.g. a change in a person's income due to a pay rise; and
A history of corrections to data held on the system, where the system is found to have an incorrect representation of real-world circumstances, e.g..a person's start date of employment is found to have been recorded incorrectly.

As such, for data items of type Date, the data may be corrected in the system, but never succeeded. Thus there may be a correction history for the data item, but this correction history (i.e. the dates on which the data item was created) is rarely of interest when creating CER rules.

Typically, data types used in CER rules should model real-world circumstances, rather than corrections to the system representation. Use Timeline where those real-world circumstances can change over time; and do not use Timeline where the real-world data cannot vary over time.