Extract.common Package

The extract_spec part of the Request applies to all content in the Extract. The attributes are as follows:

The criteria attribute defines in the form of generic queries (i.e. queries that apply sensibly to any record) which items are to be retrieved from each entity’s record. Each query is expressed as a DV_PARSABLE instance, enabling any formalism to be used. The openEHR archetype query formalisms (AQL) could be used for example. Query expressions use variables such as $ehr to mean the current EHR from the manifest list. Queries may be as simple as the following:

More sophisticated queries can be used to obtain items corresponding to a specific criteria, e.g.:

The update_spec part of the Request specifies how the Request is to be processed by the server. The default situation, requiring no update_spec at all, is a one-off request. Other alternatives include:

An ad hoc repeat of a request persisted earlier is made using an EXTRACT_ACTION_REQUEST with action set to |repeat|. This specifies only the identifier of a request previously specified using an EXTRACT_REQUEST. Since requests are uniquely identified for all time, there can be no error in the identification.

The manifest specifies the scope of records to be retrieved in an Extract. In the simplest case, only a single entity (e.g. patient) and no specific items will be identified (the content will be determined by the criteria in the EXTRACT_SPEC object); this will be used in the vast majority of single-patient request scenarios. However, some scenarios will be of a batch update nature, including pathology lab result update and situations where patient records are requested corresponding to a list of referrals received by a hospital since the last such update. In these cases, the request manifest may identify a number of entities (i.e. records or patients), each of which will be allocated a separate chapter in the resulting Extract.

The item_list of each entity manifest identifies individual items using OBJECT_REF instances each containing the HIER_OBJECT_ID identifier of a particular top-level object such as a Composition, or Party. This mechanism for identifying contents of an Extract is only expected to be used when a specific identifier is known, rather than when items corresponding to filtering criteria are requested. The latter are specified using the criteria attribute.

An Extract request in its simplest form has no version specification, corresponding to the assumption of 'latest available version' for each matched item. However, in some situations there is a need to retrieve previous versions, or information about versions. The version specification part of the Extract request allows this to be done. The possibilities available are as follows.

The EXTRACT consists of a request_id, an optional participations list, an optional specification and a set of chapters, containing the retrieved content. The participations attribute denotes parties that were responsible for creating the Extract. The specification takes the same form as the extract_spec of the EXTRACT_REQUEST, but in an EXTRACT instance, indicates the actual contents of the Extract. This will usually differ in from the request specification in that it will list in the manifest section the actual entities (and the identifiers they are known by in the receiver system) retrieved, whereas the request may not specify any entities (it may rely on query criteria), or it may specify a different set of entities than were retrievable in the receiver system.

The content of an Extract is contained within the chapters attribute, in the form of one of more instances of the EXTRACT_CHAPTER class or its subtype EXTRACT_ENTITY_CHAPTER. Within an EXTRACT_CHAPTER the content attribute contains a folder structure made of EXTRACT_FOLDER objects which in turn contain the content items. The folder structure is defined by archetypes, and can be used to separate the parts of a health record, or group items according to some other scheme e.g. episode. A specific kind of chapter, the EXTRACT_ENTITY_CHAPTER, is used to carry content associated with a single entity, i.e. patient. This means that an Extract may contain data relating to multiple entities, i.e. multiple patients.

The EXTRACT_CONTENT_ITEM class is subtyped in later sections of this specification to define metadata for specific kinds of content.