RM additions for workflow process

Overview

A problem the community has been looking at in openEHR for some time is how to deal clearly with order-related meta-data (typically: requestor and receiver ids of various sorts). The topic of 'orderables' has been mentioned in some recent discussions in CIMI, and as a result, some model changes proposed. One is the addition of an 'ENTRY_GROUP' class. A similar idea may be useful in openEHR. The problems it could address include the following:

• provide a clear place to put order-related information
• better match for Panel/Analytes in Lab data
• provide a container structure that matches Order Sets

Design

An ENTRY_GROUP class is added, which enables nested groups of ENTRYs to be formed. In almost all cases it is expected that only one level is needed. ENTRY_GROUP has a process_info attribute that connected to an abstract class whose specialisations would represent different types of process-related meta-data, e.g. order-related etc.

In this design, the SECTION class is considered a documentary element, and a new class DOCUMENT_ITEM is added as the ancestor of SECTION and CONTENT_ITEM.

Abstractly, the design corresponds to the following concentric context levels:

The following UML diagram shows the changed model.

This structure enables the following hierarchical structures to be instantiated:

• COMPOSITION - ENTRY[*]
• COMPOSITION - SECTION[*] - ENTRY[*]
• COMPOSITION - ENTRY_GROUP[*] - ENTRY[*]
• COMPOSITION - SECTION[*] - ENTRY_GROUP[*] - ENTRY[*]
• variants containing SECTION[*] - SECTION[*]
• variants containing SECTION[*] - ... - SECTION[*] - ENTRY_GROUP[*] - ... - ENTRY_GROUP[*]
• variants containing ENTRY_GROUP[*] - ... - ENTRY_GROUP[*]

But it would not allow ENTRY_GROUP to contain SECTION.

Consequently, current openEHR 1.0.3 structures are preserved, but new instance structures including ENTRY_GROUP could be created.

Archetype Structures