Records

For some items, there can be multiple values for one individual in a registry, without the item being longitudinal in nature. For example, the item Affected family member relation describes the relation of an affected family member to the individual, but should allow multiple values to be stored; one for each family member. Furthermore, there are other items that also refer to the affected family members: Affected family member sex and Affected family member side. It is important to capture which values of these three items belong together. Therefore, they are grouped in a record, which is simply a collection of related items. Records are indicated with the symbol $$$ RECORD_SYMBOL $$$ For any record, there can be multiple record instances, which are collections of item values. In the example above, this would require a record instance for each affected family member. Each record instance would contain three item values; one for each of Affected family member relation, Affected family member sex and Affected family member side.

Just like an item, every record has a descriptive and stable textual ID that is unique among all records in this dataset. However, the IDs of records and items may overlap; i.e., there may exist a record and an item with the same ID.

Longitudinal records

While Affected family member is a record that captures information on multiple people, but all referring to the current situation, there are other types of records which are longitudinal in nature. For example, for the item Height it is important to know what measurement method was used for a height value. In order to make it explicit that the items Height and Height measurement method all refer to the same measurement, they are grouped in a longitudinal record, marked with $$$ LONGITUDINAL_BADGE $$$ Each instance of a longitudinal record must include a date which specifies the point in time when, depending on the nature of the record, a measurement was made, an event took place or a certain condition held. The same rules apply as for longitudinal items: Month and year are sufficient, and in many cases, the date of a longitudinal record may be assumed to be equal to the entry date (see above).

Episode records

While some records such as Height or Scoliosis surgery refer to measurements or events which are points in time, other records refer to conditions that hold true over a period of time. In this dataset, such time spans are called episodes and the records are marked with $$$ EPISODE_BADGE $$$ One example is Feeding tube usage episode, where registries should record when an individual started and, if applicable, stopped using a feeding tube in the past. In addition, if a condition currently holds true at the time of an entry, it is important to explicitly record this date as well, which is called the “ongoing date” in this dataset.

For each episode record, the following dates must be captured:

• Start date: The date when the condition described by the record started to hold, if known
• Stop date: The date when the condition ceased to hold, if applicable and known
• Ongoing date: The date on which the condition was known to hold, if applicable; this date generally may be assumed to be the date of entry or clinical examination on which the registry entry is based

The following consistency rules apply:

• All three dates must not be after the date of entry.
• Start date must not be after Stop date or Ongoing date.
• Only one of Stop date and Ongoing date may be provided; they must not both be specified.

Reference period records

Some items refer to a specific period of time. For example, a registry may ask about hospitalisations in a form using the question “Have you been admitted to hospital in the last 12 months?” or “Have you been admitted to hospital since the last registry update?”. Since the specific time frame may vary from one value or registry to another, and may not always be derivable from the entry date, it is important to explicitly record the time period. In this dataset, records which refer to a period of time are called reference period records and are marked with $$$ REFERENCE_PERIOD_BADGE $$$n For every reference period record instance, the following dates must be provided:

• Begin date specifies the beginning of the reference period.
• End date specifies the end of the reference period.

These dates do not refer to any actual event or condition, but only the dates which the question on a form referred to. The terms Begin and End are deliberately chosen to avoid confusion with the terms Start and Stop used for episode records. Unless otherwise noted, registries should use the following periods:

• At baseline data collection (i.e., when the information this record applies to is first collected for this individual), the time period is the last 12 months. That is, Begin date is the date of entry minus 12 months, and End date is the date of entry.
• At data updates, the time period is since the last update of this item. That is, Begin date is equal to the End date of the previous reference period, and End date is the date of entry.

The aim is to have a collection of reference periods which are consecutive and non-overlapping.