CIMI CLINICAL_DATA_GROUP Model

Owned by Thomas Beale
Last updated: 10-Mar-2014Version comment
7 min read

Overview

Another approach to solving the panel-in-panel (aka Entry-in-Entry) problem. We start from the following assumptions:

  • a panel is 'orderable', not just an ad hoc collection of results
  • an individual lab result (e.g. HGB, HCT) is a 'panel item', and can appear in a panel
  • panels can have internal hierarchy, i.e. panel items can appear in a CLUSTER structure
  • but a panel item cannot appear inside another panel item
  • ENTRY is the root point of context, in particular:
    • temporal status - i.e. actual, proposed, excluded etc
    • subject - i.e. patient or other
  • panel items are 'query root' points for content
  • ENTRYs are query root points for context & retrieval

The archetypes used in the example below can be found in the CIMI archetypes Git repo on Github.

Remaining CIMI questions

This page addresses just the structural panel modelling problem. As a reminder, the following questions remain to be addressed.

Category of nodes:

  • Intermountain's types: Data / Qualifier / Modifier / ...
  • openEHR categories: data / state / protocol / justification

Timing

  • clinical assertion time / observation time

Linking e.g. BMI connects to an old height rather than one measured at the time of asserting BMI. The need here is to allow a model node, e.g. slot filler to stand for a data item that may be in another location, i.e. part of another ENTRY.

Reference Model options

Basic premise

The introduction of a 'clinical data group' concept, either as a class or in some other way. A Clinical Data Group is:

  • a coherent self-contained clinical structure
  • doesn't contain other Clinical Data Groups, 
  • is contextless i.e. needs to be part of an ENTRY to get its context

In this approach, an ENTRY is a contextualised clinical statement, and the Clinical data group is the content of that statement.

Design Considerations

My view is that changes to the RM are perfectly acceptable - the CIMI RM is not in use at the moment by any outside party. The main design consideration is clarity, such that conversion of CIMI archteypes to archetypes based on other RMs is best enabled. It is not the intention here to propose a model that is a mimic of any current RM for purposes of convenience, but instead to prioritise clarity and archetype convertability.

Alternative #1

The following shows one set of possible reference model additions to enable these requirements.

Here we have added one new concrete class CLINICAL_DATA_GROUP. This class is a 'root' object for any data that goes in an ENTRY. An ENTRY can have multiple CLINICAL_DATA_GROUPs. A CLINICAL_DATA_GROUP has as its items ITEM instances, i.e. ELEMENTs and CLUSTERs. However, it is not a kind of ITEM or CLUSTER (otherwise it could contain other CLINICAL_DATA_GROUPs directly). Therefore a new abstract parent of CLINICAL_DATA_GROUP and ITEM is introduced, called ENTRY_CONTENT.

  • drawback: the above model does actually allow CLINICAL_DATA_GROUP to contain, via CLUSTER, more CLINICAL_DATA_GROUPs. We don't want to allow this in reality, but a UML model to prevent this is more complex.

This is the model that was used to build the examples below.

Alternative #2

A simplified version of this would have CLINICAL_DATA_GROUP as a sub-type of CLUSTER, and no ENTRY_CONTENT and CLUSTER.item: ITEM, as it is in the DSTU model.

  • drawback: in this case, CLINICAL_DATA_GROUP could contain other CLINICAL_DATA_GROUPs directly.

Alternative #3

Ian McNicoll suggested an alternative whereby no new classes at all are added, but the CLUSTER class is given an extra attribute is_clinical_data_group: Boolean, to enable the same effect as a CLINICAL_DATA_GROUP_CLASS. Note that this would make clinical data group archetypes and nodes less visible in current tooling because the class is the basis for node visualisation (since icon, editing actions, context menu are based on class name).

Alternative #4

The simplest UML model that can enforce the following:

  • CLINICAL_DATA_GROUP to consist of only CLUSTER/ELEMENT hierarchy AND
  • a hierarchy of structure containing CLINICAL_DATA_GROUPs at different levels AND
  • no containment of a CLINICAL_DATA_GROUP by another (direct or indirect)

is as follows:

This model has not been implemented here.

Archetype Example 1 - blood panel

This example is of a blood panel result containing 2 levels of panel items. The top level contains Haemoglobin and Red cell count; the 2nd level is for white cells; here we include just lymphocytes. The logical structure is (CDG = CLINICAL_DATA_GROUP):

  • ENTRY: FBC panel
    • ENTRY-level context items
    • CDG: Hemoglobin data group
    • CDG: Red cell count data group
    • CDG: Hematocrit data group
    • CLUSTER: White cell differential
      • CDG: Lymphocytes data group
      • etc

Each analyte (HGB, RCC, Lymphocytes) is modelled as an archetype of CLINICAL_DATA_GROUP. To be somewhat realistic, we have used the Intermountain pattern of 'StdLabObs' as a precursor archetype for the concrete types. Thus, our analytes are as follows.

  
The coloured icons are the
archetypes implicated in
this FBC panel model. 
Std Lab Obs archetype (copy
of Intermountain StdLabObsQuantified) 
Hemoglobin,
specialisation of std lab obs
Red cell count,
specialisation of std lab obs 
Hematocrit,
specialisation of std lab obs
Lymphocytes,
specialisation of std lab obs 
Lab result panel
FBC panel,
specialisation of Lab result panel
(source form) 
FBC panel,
flattened form 

Archetype Example 2 - Bedside 'panel'

This example is of a result panel obtained at the bedside, consisting of a BP and a hematocrit. The logical structure is (CDG = CLINICAL_DATA_GROUP):

  • ENTRY: Bedside panel
    • ENTRY-level context items
    • CDG: Hematocrit data group
    • CDG: BP data group
  
Blood pressure full archetype
Blood pressure overlay:
reduced version for bedside
template 
Bedside template
Bedside template flattened

What can can see above is that Hematocrit has been included in this bedside panel, alongside the complex data structure representing Blood pressure. 

How the paths Work

The challenge for querying is as follows. Imagine we use models like the above, and many more. Let's say we want to query for Hematocrit. We could query based on the archetype CIMI-Core-CLINICAL_DATA_GROUP.hematocrit.v1. This will return both bedside hematocrit and lab panel hematocrit. The hidden danger: we think we are querying for 'patient actuals' i.e. real measured values, and with the above models, this is probably true. But what if someone creates a template of a Care plan of some kind and includes a 'target hematocrit' or 'target BP'? If data built from those template are committed to the EHR, the naive hematocrit query will return actuals and targets!

Q: why isn't this a problem in openEHR?

Because in openEHR, the archetypes are based on ENTRY subtypes that designate the temporal status of the data, e.g. an Observation records an actual, whereas an Evaluation records a target and an Instruction records an order. Querying in openEHR is done on the basis of these archetypes, which designate both the content (e.g. BP, HCT) and the temporal status, e.g. actual, target, projected etc. 

The openEHR approach isn't flexible enough to do the mix'n'match modelling illustrated above however, which is why we are doing it in CIMI...

Q: how to make it work with a CIMI Reference Model?

One solution would be to query for ENTRY+CLINICAL_DATA_GROUP combinations, assuming that ENTRY archetypes know whether they are an Observation, target, goal, exclusion etc. This is easy to do in Archetype Query Language (AQL), although it will make queries longer. A query for actual BPs, that ignores target BPs would need to reference not only the BP archetype id & paths, but also the owning ENTRY archetype, e.g. something like CIMI-Core-ENTRY.BP_observation.v1

This approach would mean that the archetype CIMI-Core-CLINICAL_DATA_GROUP.blood_pressure.v1 would appear in more than one ENTRY archetype - e.g. a BP_observation one, a Hypertension_care_plan one and so on. 

Given the possibility of the BP CLINICAL_DATA_GROUP being some way down a hierarchy of Clusters inside the ENTRY, the CONTAINS AQL operator would be used. Thus, queries for BP actual values would be something like:

SELECT
    bp_cdg /item[id7|data|]/item[id5|Systolic|]/value[id1054|Quantity|]/value as systolic_bp
FROM
     EHR e [ehr_id/value=$ehr_id] CONTAINS
	 (ENTRY [CIMI-Core-ENTRY.lab_result_panel.v1] CONTAINS 
     CLINICAL_DATA_GROUP bp_cdg [CIMI-Core-CLINICAL_DATA_GROUP.blood_pressure.v1])