Logical relational database style table data structure, in which columns are named and ordered with respect to each other. Implemented using Cluster-per-row encoding. Each row Cluster must have an identical number of Elements, each of which in turn must have identical names and value types in the corresponding positions in each row.

Some columns may be designated key' columns, containing key data for each row, in the manner of relational tables. This allows row-naming, where each row represents a body site, a blood antigen etc. All values in a column have the same data type.

Used for representing any data which is logically a table of values, such as blood pressure, most protocols, many blood tests etc.

Misuse: Not to be used for time-based data, which should be represented with the temporal class HISTORY. The table may be empty.

Runtime name of this fragment, used to build runtime paths. This is the term provided via a clinical application or batch process to name this EHR construct: its retention in the EHR faithfully preserves the original label by which this entry was known to end users.

Design-time archetype identifier of this node taken from its generating archetype; used to build archetype paths. Always in the form of an at-code, e.g. at0005. This value enables a 'standardised' name for this node to be generated, by referring to the generating archetype local terminology.

At an archetype root point, the value of this attribute is always the stringified form of the _archetype_id_ found in the _archetype_details_ object.

Optional globally unique object identifier for root points of archetyped structures.

Links to other archetyped structures (data whose root object inherits from ARCHETYPED, such as ENTRY, SECTION and so on). Links may be to structures in other compositions.

Details of archetyping used on this node.

Audit trail from non-openEHR system of original commit of information forming the content of this node, or from a conversion gateway which has synthesised this node.

Physical representation of the table as a list of CLUSTERs, each containing the data of one row of the table.

Logical relational database style table data structure, in which columns are named and ordered with respect to each other. Implemented using Cluster-per-row encoding. Each row Cluster must have an identical number of Elements, each of which in turn must have identical names and value types in the corresponding positions in each row.

Some columns may be designated key' columns, containing key data for each row, in the manner of relational tables. This allows row-naming, where each row represents a body site, a blood antigen etc. All values in a column have the same data type.

Used for representing any data which is logically a table of values, such as blood pressure, most protocols, many blood tests etc.

Misuse: Not to be used for time-based data, which should be represented with the temporal class HISTORY. The table may be empty.

Physical representation of the table as a list of CLUSTERs, each containing the data of one row of the table.

Logical relational database style table data structure, in which columns are named and ordered with respect to each other. Implemented using Cluster-per-row encoding. Each row Cluster must have an identical number of Elements, each of which in turn must have identical names and value types in the corresponding positions in each row.

Some columns may be designated key' columns, containing key data for each row, in the manner of relational tables. This allows row-naming, where each row represents a body site, a blood antigen etc. All values in a column have the same data type.

Used for representing any data which is logically a table of values, such as blood pressure, most protocols, many blood tests etc.

Misuse: Not to be used for time-based data, which should be represented with the temporal class HISTORY. The table may be empty.

Runtime name of this fragment, used to build runtime paths. This is the term provided via a clinical application or batch process to name this EHR construct: its retention in the EHR faithfully preserves the original label by which this entry was known to end users.

Design-time archetype identifier of this node taken from its generating archetype; used to build archetype paths. Always in the form of an at-code, e.g. at0005. This value enables a 'standardised' name for this node to be generated, by referring to the generating archetype local terminology.

At an archetype root point, the value of this attribute is always the stringified form of the _archetype_id_ found in the _archetype_details_ object.

Optional globally unique object identifier for root points of archetyped structures.

Links to other archetyped structures (data whose root object inherits from ARCHETYPED, such as ENTRY, SECTION and so on). Links may be to structures in other compositions.

Details of archetyping used on this node.

Audit trail from non-openEHR system of original commit of information forming the content of this node, or from a conversion gateway which has synthesised this node.

Physical representation of the table as a list of CLUSTERs, each containing the data of one row of the table.