CIMI panel in panel example - BMI

This page shows various standalone and panel style archetypes and templates showing how the Entry-in-Entry concept could work. The archetypes / template source is here on the openEHR adl-archetypes GitHub repo. NB: these archetypes are ADL 1.5.1 with new identifier system, and won't compile in the beta 9 release of the ADL workbench. A new release is coming imminently.

Reference Model

First, we need to know what the CIMI Reference Model (RM) looks like for this. Here is the important bit:

Notice we have the classes ENTRY, and two new children, COMPOUND_ENTRY, INDIVISIBLE_ENTRY. COMPOUND_ENTRY's contents can be part: ENTRY [1..*] as well as data: ITEM [1..*]. INDIVISIBLE_ENTRY can only contain data: ITEM [1..*].

Archetypes

The collection of archetypes:

Height Archetype

Here's a simple CIMI height archetype, derived / hacked from a Results4Care model (ADL source on Github):

Structural view	Structural view + RM types + codes

The main thing to note about this is that the RM class is INDIVISIBLE_ENTRY, i.e. we view a 'height' as a logically atomic statement, so it has to be an INDIVISIBLE_ENTRY. This means we can use it on its own in data, and it will have sufficient context, and be identifiable by a query service as a 'proper' clinical statement, and not just some sub-item of some other structure.

Weight Archetype

Here's a simple CIMI weight archetype (Github source):

Structural view	Structural view + RM types + codes

Similarly to Height, the RM class is INDIVISIBLE_ENTRY. 

Weight Template

Now the simple case: we want to just record a Weight on its own. We do that with a Weight template (remember in ADL/AOM 1.5, a template is needed for a data-set, even in the degenerate case where the only contents are just one archetype) (Github source):

Source	Flattened - same as archetype	Paths

Here we can see that the path to the weight value is /data[id2|BodyWeight|]/value[id13]/value. Inside a COMPOSITION or even as a 'naked' ENTRY, this would be seen by an AQL query processor as [CIMI-Core-INDIVISIBLE_ENTRY.t_body_weight.v1.0.0]/data[id2|BodyWeight|]/value[id13]/value.

BMI - as an Archetype with direct references to Weight and Height

The most obvious way to model BMI is probably as an archetype that contains its own BMI data point(s), plus direct inclusions (i.e. not via slots) of the Weight and Height archetypes. We'll need a template as well. Let's look at the archetype first (Github source).

Structure	ADL Source

We now have a compound structure, so the root RM type is a COMPOUND_ENTRY. It contains under 'parts' the two INDIVISIBLE_ENTRY Height and Weight archetypes.

Now the template, in source and flattened form (Github source).

Template ADL source	Flattened structure	Flattened paths

Here we can see the whole resulting structure, with the key RM types and domain meanings highlighted.

Note that the path to the weight value is the same as it was above, but now embedded in the COMPOUND_ENTRY:  [CIMI-Core-INDIVISIBLE_ENTRY.t_body_weight.v1.0.0]/data[id2|BodyWeight|]/value[id13]/value. This means an AQL query processor could find the weight using the same path as was used for a standalone weight; therefore a single query could be written to extract weights out of data based on standalone and compound structures.

Building Panels

What if we want to build a lot of 'panels', where each panel has generically the same structure, and panel-wide data items, but can be configured to include the atomic analyte items needed for each particular panel e.g. lipids, CBC, Chem20 etc?

The first thing we would need would be a panel archetype, containing slots for inserting panel item archetypes. Here is a somewhat contrived one - a 'GP' panel (Github source). 

'GP' Panel Archetype structure

Now we need to define an actual panel 'GP physical exam' - this will be a template that 'fills' the slots with a particular choice of archetypes. Here we'll use height, weight, and another archetype I have on hand, heart rate (Github source).

'GP phys exam' panel structure	Flattened

Above you can see the source and flattened form of the template. So it's a 'panel' containing a body weight and a heart rate, and some panel-wide items.

Discussion

Context

One of the things we need to contemplate with respect to Entries-in-Entries is nest context. In openEHR, we don't nest Entries, because the Entry is the definitive root point of context for the nexus of subject/time/protocol (i.e. what was done). This is essentially what is known as a situation in epistemology. Ontologically you can't nest that. To illustrate the issue, I have added the 'subject' and 'info_provider' context elements to the copy of the CIMI RM I used above, to show what happens with Entries in Entries.

Physical exam panel with RM attributes

Here we can see that the subject attribute reappears 4 times, when the panel is intended to contain data relating to only one subject. Presumably, it should also have the same timing information. The panel does establish overall order information in common, which makes sense. But the other context items present a problem: are they replicated data? Are there rules to make sure they can't be different? 

Perhaps a more basic question is: what is an ENTRY in CIMI anyway?!