...
The identification of elements within Extracts is a somewhat tricky topic. One job of the Extract is to transport existing artefact (e.g. document / Composition) identifiers from the source system. However, an Extract needs a way of identifying items within the Extract itself. What this means concretely is that the internal referencing system within the Extract has to work, regardless of how it is implemented in the source system.
The key place references occur within an Extract are from Participation nodes within the main data, to demographic entities, which may or may not be included in the Extract (since they may already be available in a service visible to all Extract-using systems in the overall environment of communication). To achieve this, an Extract specific variant of the openEHR PARTICIPATION class, called XEXTRACT_PARTICIPATION is used ; see the common package UML, below. To accommodate this properly in the existing openEHR RM common.generic package, a modification is required to the model, in which the PARTICIPATION class is redefined to an abstract type, and the current concrete idea of PARTICIPATION (used e.g. in Entry.other_participations) is now represented by S_PARTICIPATION. 
This change has the effect that any attribute in the openEHR RM whose statically declared type is a PARTICIPATION, could be set at runtime to instance of S_PARTICIPATION (within systems) or X_PARTICIPATION (within Extracts). As can be seen from the common package UML model below, X_PARTICIPATION uses a simple String identifier for the performer attribute rather than the object structure used in the system S_PARTICIPATION formfor participation information built on the fly.
Note: further work is required to identify the possible impact on data in current openEHR systems, and what schema evolution facilities might be required.
...
The common package defines features common to all kinds of extracts, and has the following UML model.
The Extract consists of 'chapters', each of which carries either subject-related information (e.g. EHR clinical information) or demographic information. Demographic information is completely optional, and would not be used in environments where a global demographics service or registry is available.
...
A typical data structure according to this model follows:
Generic / 13606 / CDA equivalent Extract
A second variant is defined to represent data exported in 13606 or CDA format. This model is more permissive and takes account of the version and document semantics of 13606 and CDA. The following model shows the information content for this type of Extract; as for the EHR Extract, this is combined with the common package to define the overall semantics of such extracts.
A typical instance view is as follows:
...