Each data element has an optional TransactionType attribute. This attribute can be one of Insert, Update, Remove, Upsert, or Context.
A TransactionType of Insert means that the data entity is new (does not currently exist in the study) and must be added to the study data along with all the properties provided. It is an error if the data entity already exists, or if the data entity's parent does not exist.
A TransactionType of Update means that the data entity already exists and must be modified to have the new properties provided. Properties not mentioned are not modified. It is an error if the data entity does not exist.
A TransactionType of Remove means that the data entity already exists and must be deleted along with all its properties and children. It is an error if the data entity does not exist.
Note: The use of the word "delete" in this section does not imply that all records of the data entity are expunged, just that the next transaction on that entity (if any) must be an Insert rather than Update or Remove.
A TransactionType of Upsert is the same as Update if the data entity exists, and the same as Insert otherwise.
Note: Upsert allows the sender to ignore whether the data entity exists or not. (A capability that may be needed by certain data collection systems.) This capability is potentially dangerous and may be removed in future versions of this standard.
A TransactionType of Context means that the data is explicitly being resent for context purposes only. An example of this would be sending an ItemGroup containing demographic data every time (with a TransactionType of Context) to permit matching and checking of Patient IDs between the sender and receiver systems.
A child element that does not specify its own TransactionType inherits the TransactionType of its parent. The TransactionType of a top level data element must be explicit.
Transaction processing proceeds in the order in which data elements appear in the ODM document. If two transactions for an entity are included in an ODM document, they are applied in the order in which they appear.
An entity having a TransactionType of Remove may include descendents. Each such descendent must also specify a TransactionType of Remove, or else not specify a TransactionType attribute (in which case the descendent inherits the TransactionType of the parent). A program that processes ODM files should look ahead far enough to determine if an element breaks this rule before processing the element. Note that data corresponding to such descendents may have been deleted via a cascading effect resulting from the deletion of the parent. In such cases, the processor may or may not have generated an audit trail entry for each descendent data entity deleted.
If a Snapshot document includes a TransactionType, only TransactionType=Insert is permitted.