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:
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:
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.