CIMI Entry-in-Entry Modelling Pattern

Requirement

The CIMI group proposed in late 2013 to change the reference model to allow 'Entries in Entries'. There was some debate about this, which led to a better analysis of the actual requirement. Two documents have been created during numerous telecons:

• A PPT showing various ways that 'atomic' and 'panel' content could be achieved
• A requirements document created by Dr Stan Huff

In late Jan 2014 we agree to create some example models to illustrate if & how 'Entry in Entry' might make sense.

The key requirements in Stan's document are as follows:

1. Support a 'panel' concept:
   1. a 'panel' is a collection of independent discreet (i.e. logically 'atomic') observations
   2. each observation has its own specific context (a la Intermountain modifiers, qualifiers etc)
   3. a panel is 'orderable', not just an ad hoc collection of results
   4. a panel is not a Section; it has specified and fixed [potential] content
   5. meaning of panel observations is not changed by what panel they appear in
2. We need panels-in-panels e.g. a 'CBC with diff' panel = a panel that contains a CBC panel and a Differential panel
3. Need to allow data elements that are data about the whole panel, e.g. overall status of panel, comments on whole panel
4. A given 'atomic' observation e.g. creatinine level could appear in a) a renal panel and b) a creatinine clearance panel.
5. Recognise [i.e. logically identify] queryable indivisible units of information
   1. e.g. by considering such units to be 'Entry' instances, where Entry is a type in typical models like CIMI, 13606, CDA, openEHR etc
   2. such an information unit should be considered indivisible for safe querying, i.e. you can't safely get just a piece of it
6. Consistent query paths - ensure that the paths to query targets, i.e. Entries, is consistent regardless of whether they appear standalone e.g. patient pulse, or within a panel, e.g. pulse oximeter data 'panel'
7. Simple navigation - it should be simple for a query engine and other software to navigate from the panel [root] to each test result Entry
8. Make the pattern for panels also work for generalised clinical observations, i.e. 'everything is a panel'

Panel-in-Panel Requirement

Various examples illustrate requirement #2 above:

• BMI: a BMI clinical model would presumably make use of existing Height and Weight models, which could be used on their own. One would expect the ability to create a BMI model that included the BMI calculated element as well as the Height and Weight items
• Hematocrit in a blood panel; Hematocrit obtained by nurse with fingerstick sample at bedside.

Model Solutions

The following models have been created to illustrate various model approaches to making panel models work as required:

• example model (BMI) using the COMPOUND_ENTRY / INDIVISIBLE_ENTRY solution (Linda Bird / Michael v.d. Zel; archetypes by T Beale)
• example model (FBC & 'bedside' panel) using a CLINICAL_DATA_GROUP class (T Beale)
• archetypes based on the ENTRY in COMPOSITION solution have been created, but not documented on the wiki (model proposed by G Freriks; archetypes by T Beale)

All the archetypes can be found here on GitHub.

Discussion

Not everyone agrees with the Entry-in-Entry idea, because in openEHR and 13606, an 'Entry' corresponds to a 'situation' i.e. a conjunction of time/place/actor(s)/event. This is realised in the context attributes of the ENTRY class, particular subject, timing information and protocol (in openEHR), which indicates what was done. So on that logic, an ENTRY can't contain an ENTRY, because situations don't 'contain' each other. On the other hand, 13606 and openEHR don't model some basic requirements that well, e.g. the BMI example. 

See here for some discussion list posts on issues with these different modelling styles.