The reference model classes that are presently archetyped in the openEHR Framework are described below. There are a set of principles governing the creation of archetypes that apply in addition to choosing the most appropriate reference model class. Other resources that may be helpful in the decision making process are:

Composition

The level of committal to the EHR is always a Composition UML. This is a document or any container of information that will require a medicolegal status, knowing who committed it to the EHR and when. This includes any note entered in the EHR, any report, any letter and any other piece of information that will be self-contained. A report archetype (of a Composition) could be used for laboratory results, an annual medical that is to be sent to an employer or any other purpose requiring the features in a report archetype.

Section or Entry?

Most standard parts of medical and nursing recording will be best expressed as sections UML as they may form only part of a complete note made at one consultation - examples are antenatal visit when the person requests care for an unrelated issue, or physical examination which varies greatly depending on the setting. Further, sections can vary widely without changing the meaning of the information (which is determined at the level of the Entry).

What type of Entry?

The Entry classes UML are the expression of clinical statements in the EHR - the meaning of an Entry is the same no matter what Section it is in nor in what Composition. There are five types of Entry - so you need to understand the reference model a little to choose the most appropriate class. I will consider their features in order of complexity. This helps the decision making.

ENTRY

This parent class is abstract - which means that it does not occur in data - all subsequent classes of Entry have the features of the ENTRY class. The features of this abstract class are:

Information attributes
- Subject of care - who the information relates to (mandatory - self, or the record subject, is the default)
- The information provider - who supplied the information (optional - only required to be explicitly stated)
- Other participations (optional - recording of who was involved and in what manner with this information)
Technical attributes
- Language - the language of this entry (optional - normally only included if different from language of composition)
- Encoding (optional and again normally that of composition UTF-8)
- Workflow identifier which allows a workflow engine to track information (optional)

ADMIN_ENTRY

Information attributes
- Data (mandatory)
  The administrative entry has no features of clinical information and is restricted to:
  This entry can be used for any structured administrative information in the health record and has no predetermined structure.

CARE_ENTRY

This class is also abstract - which means that it too does not occur in data - all subsequent classes have the features of the CARE_ENTRY as well as its parent ENTRY class. The features of this abstract class are:

Information attributes
- Protocol - a set of data that is about how this information was collected or other 'clutter' that will not be required for safe clinical interpretation of the data itself (optional)
Technical attributes
- Guideline ID - allows linkage to a clinical guideline (optional)

The following classes are all special types of care entry, that is to say they are used for recording information about the health of the person.

Evaluation

The evaluation class is the simplest of the care oriented Entry classes. It is therefore the most able to handle diverse data. The other classes are designed to meet specific requirements. The result is that the Evaluation class is best suited for information deriving from other observations where the information is of a more long-standing nature than minute to minute observations. This class also lends itself to summary or review information. Dates and times have to be explicitly represented in this class (as part of the archetype).

Information attributes
- Data (mandatory)

Action

The Action class is for recording that something was done for a person. It has a single date time and relates to the time it was done. It may or may not relate to an Instruction.

Information attributes
- Time - time of the action (mandatory)
- Description - the description of what was done (mandatory)
Technical details
- Instruction details - the instruction to which this action relates (optional)
- Instruction state machine (ISM) transition - information about the consequent state of the (logical) instruction following the action (mandatory)

Instruction

The Instruction class is for recording that an action is to be carried out in the future and the timing of that instruction.

Information attributes
- Narrative - the instruction in narrative form (mandatory)
- Expiry date - the time that the instruction will no longer be active based on longevity (optional)
- Activity(ies)
  - Timing of the activity (mandatory)
  - Description - description of what the activity involves (mandatory)
Technical attributes
- Workflow definition - information about workflow (optional)
- Action archetype ID - the ID of the archetype used to record the action specified in the activity description (mandatory)

Observation

The Observation class is for recording information that varies over a short period of time. The class has features which allow time series of information to be recorded as well as aggregrate data over a period of time such as maximum, totals etc.

Information attributes
- History - the event based time series (mandatory)
  - Event - point in time or interval (mandatory)
    - Data (mandatory)
    - State (optional) - information about the person at the time of the observation that is important to consider when interpreting the data (e.g. Fasting in relation to blood sugar)
- State - an event based time series with intervals for State data (optional)

Understanding Observation and Evaluation

Some more detailed analysis of these types is described in the Entry type FAQs.

Browser not supported