Overview
Based on recent discussions in CIMI in which an 'ENTRY_GROUP' class has been proposed, 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:
| Context type | Class(es) | Optionality |
|---|---|---|
| EHR commit bucket; business event context | COMPOSITION | M |
| Documentary | DOCUMENT_ITEM, SECTION | O |
| Workflow | ENTRY_GROUP | O |
| Clinical statement | ENTRY | M |
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