Design Overview

The openEHR Extract model uses two design ideas. Firstly, the notion of a Request and an Extract (the reply) are distinguished. Extracts may include a copy of the Request to which the Extract is a reply, indicating what is actually in the Extract, which may differ from what was requested. Secondly, the common semantics of Requests and Extracts are modelled in a generic way, with a number of specialised Request and Extract types being based on the common classes. Different concrete types of Extract are thus used to satisfy particular groups of requirements, rather than trying to make one kind of Extract perform all possible tasks. The figure below illustrates key Extract communication scenarios, along with the various concrete Extract types defined by the model.

The EHR Extract is just one concrete type of Extract. The other types include:

Other types of Extract may be defined in the future.

The pattern of requests and replies may be controlled in time. The simplest situation is single request, single reply. Other variants include:

The general situation of any environment from which content needs to be extracted and sent to another system is that three categories of data may be needed: the 'key' clinical and administrative information, typically EHR content (e.g. patient blood pressure history); demographic information (indicating who the patient and professionals are that are mentioned in the clinical information; and relevant meta-data. These types of information almost always reside in different parts of the source system environment, but need to be combined within the Extract. The model defined in this specification allows for content to be flexibly aggregated in an Extract. The model therefore consists of a generic Extract containment structure into which specific archetyped content can be plugged, with the whole structure being templated. Each such template corresponds to one extract type, i.e. one message type. This is visualised in the figure below.

The templates can be used to generate content in at least two ways. The default approach is to use the template for a given extract type, say 'referral', to create standard openEHR content according to the published openEHR EHR Extract schema (which largely re-uses the main openEHR EHR and demographic schemas). In this approach, every Extract message conforms to the standard schema - an XML Extract document is 'standard generic openEHR XML' in this case.

An alternative approach converts each template into its own schema, to which all instances of that template conform. Different templates, e.g. discharge summaries and referrals define distinct schemas. In this method, the XML of any message is specific to its own schema. If changes are required in the message content, the schema usually has to be re-generated. The two methods are illustrated in the following figure.

Which method is used depends on the requirements of the environment and other factors, such as the stability of the template structures. The sections of this document describing specific kinds of extract show details of the concrete data representations involved.

The rm.extract package defines the semantics of Extracts from openEHR data sources, including EHRs. The UML diagram below illustrates the package structure of the rm.extract package.

The sub-packages are as follows: