CIMI Entry-in-Entry Discussion

The concept of Entries in Entries has generated a lot of discussion. Some posts made on the CIMI list reproduced here.

Ian McNicoll - 13 / Jan / 2014

Hi Cecil,

Ian McNicoll - 08/Jan/2014

I have been lurking in this discussion for a while and I thought I
should clarify how we currently model Lab Tests in openEHR, and how
(with some provisos) it is possible to have consistent querying for
lab panels vs. single analytes.

A simplified representation of the base Lab Test archetype is

ENTRY lab_test
   ELEMENT Name = "Test Name" (The ordered test) Value = xxx
   CLUSTER
       ELEMENT Name = "Result value"  Value = yyy
       ELEMENT Name = Comment Value = zzz

A. For a single analyte this would become

ENTRY lab_test
   ELEMENT Name = "Test Name" Value = "Blood glucose" - normally a
coded term e.g LOINC code
   CLUSTER Name = "Result"
       ELEMENT Name = "Glucose"  Value = 11.2 - the analyte 'name is
epxressed as an override of the original "Result Value" and normally a
coded term.
       ELEMENT Name = "Comment" Value = ""

The query path to the analyte is

ENTRY lab_test/"Result"/"Glucose"/value

B. For a single panel this would become

ENTRY lab_test
   ELEMENT Name = "Test Name" Value = "SMAC" - normaly a coded value
e.g LOINC code
   CLUSTER Name = "Result"
       ELEMENT Name = "Urea"  Value = 11.2
       ELEMENT Name = "Comment" Value = ""
   CLUSTER Name = "Result"
       ELEMENT Name = "Glucose"  Value = 6.3
       ELEMENT Name = "Comment" Value = "Improving"

The query path to the blood glucose analyte remains

ENTRY lab_test/"Result"/"Glucose"/value

Of course you can assume that all analyte and test names would come
from a ref terminology like LOINC or SNOMED.

This pattern gives the flexibility to construct 'fixed' panels - an
example being the Lipid studies panel that Thomas used, where there
does appear to be pretty strong consensus on content , but in the main
the panels are constructed dynamically art run-time, in response to
the content of the lab message, by specialising the original "Result"
cluster and the Analyte name element.

As long as we use a consistent terminology, the analyte results are
iso-queryable, irrespective of whether they are recorded as single
analytes or as a panel.

One drawback of this approach is that we are dynamically allocating
the datatype to the analyte element as it is received from the lab.

The NEHTA path_test archetype which we are thinking of adopting
internationally, does things a little differently but the base
principle is identical.

One option that appears not to have been considered is to use ELEMENT
archetypes to represent the analyte

e.g.

ELEMENT lab_analyte,v1
 specialised to carry the datatype, units etc as well as the
appropriate term-bindings.

These ELEMENT archetypes would really be treated much more like a
reference terminology - essentially carrying the same knowledge as
LOINC but in an immediately implementable format, pluggin in to the
parent lab_test ENTRY archetype


ENTRY lab_test.v1
   ELEMENT Name = "Test Name" Value = "Blood glucose" - normally a
coded value e.g LOINC code
   CLUSTER Name = "Result"
       SLOT
           ELEMENT.lab_analyte.v1 Name = "Glucose"  Value = 11.2
       ELEMENT Name = "Comment" Value = ""


In this way panels can also be constructed as specialisations or at
run-time, but additional knowledge is captured in the archetype.


I hope I have not further added to the confusion!

I also agree with William and Daniel that we should be trying to
devise 'Common Shared Models of Use' which happen to make use of some
\Models of Meaning' in the use of reference terminology. Trying to do
this kind of exercise as pure 'Models of Meaning' is, I agree with
Daniel, almost impossible.

An initial analysis by T Beale 10/Jan/2014

Labs....

When it comes to labs, the openEHR clinical modellers have treated them somewhat like ENTRYs, where groups of lab analytes have been modelled e.g. cholesterol result is an OBSERVATION containing the data points LDL, HDL, triglycerides, ratio, total.

If we want to make something like a Chem 20 using this style of lab observation archetypes, it would be like the encounter example above - there would be multiple OBSERVATIONs put together, depending what was in the starting set of lab archetypes.

Stan does it differently. In his approach, there is one CEM for each lab analyte, with all attendant possible context information. He can then create a Chem 20 or a cholesterol test in the same way - everything is a panel. I suspect this is probably the right way to go, especially in modern times, when (as I understand it) a single blood sample can be tested for many more things than once was the case.

So if we were to adopt that style in openEHR & CIMI, what would it look like?

Solution 1 - each lab analyte = 1 ENTRY (OPTION 1)

In this solution, every key lab analyte would now be its own OBSERVATION (ENTRY in CIMI). The potential problem in openEHR is that now we have on each OBSERVATION its own context. This is normally correct, since in the ante-natal encounter example, context information can (and does) differ between e.g. BP measurement and heart rate measurement.

But in labs, you presumably want some/most of the same context for all of the analytes. However, if each lab analyte = 1 ENTRY (giving us mix and match ability) then how do we get common context?

Let's assume it is true for now - let's assume that most of the context information for all the Chem 20 analytes is the

So this is where the ENTRY-in-ENTRY question comes up. It looks like we want ENTRYs in ENTRYs to deal with this problem, leading people to want an OPTION 6-like approach. However we don't! That destroys the idea of what an ENTRY is (an indivisible unit of context and data). It means that this modelling approach is not quite correct given an RM based on the ENTRY concept.

Solution 2 - each lab analyte = 1 CLUSTER (OPTION 2b)

In this solution, each key lab analyte is modelled as its own CLUSTER, and uses a patten like that shown in option 2b on the slides (I would just name the CLUSTER with the analyte name, and delete the first ELEMENT in every case. But that's a detail). [This is basically Ian's solution, as posted the other day.]

You still have to get the CLUSTERs into the ENTRY. That's done by having a lab panel ENTRY archetype containing a 1..* slot for lab analyte CLUSTERs. To build a lab panel, you template this and define exactly what lab analytes you want in there. If it happens that you consciously know that you have 2 or more separate 'panels' (e.g. separate samples, lab processing), you create an ENTRY for each panel.

But each panel ENTRY can contain exactly whatever you consider to be the 'panel'.

If the data is just a single key item, e.g. a Hematocrit, then you have an ENTRY containing just one CLUSTER (being the Hematocrit result CLUSTER). If you have a larger panel containing Hematocrit, it's the same, but now there are sibling CLUSTERs for the HGB, and other analytes.

So the querying for Hematocrit is identical in each case. In my view this solves the problem. I would also think that openEHR might investigate this kind of modelling for labs.

Non-Lab Information

Now comes the confusing bit. Stan would like to model a heart rate or a systolic BP as if it were a lab analyte, and be able to combine these non-lab data items in the same free way as above - in 'panels'. Now, while I understand that a nurse might get a Hematocrit, patient temp, and oxygen sat level at the bedside, I don't agree that this is a 'panel'. These are 3 different things, measured by completely different methods (all buried in sophisticated devices whose functioning mere mortals don't understand). They are potentially done at different times (maybe second apart, maybe minutes apart, maybe hours apart). They could easily be done by different people, if two nurses were there, or training was occurring.

So my view is that pretty much all other clinical data should be modelled more or less as we have it in openEHR - 1 ENTRY (OBSERVATION) = 1 observed phenomenon & observation protocol at one (or a concurrent series of) point(s) in time.

Why?

In general, these other data items have innate structure, specific to the measurement - and that includes the 'context' items specific to the measurement - protocol, patient state etc. An Apgar is what it is - always 5 x 0-2 score + 0-10 final score. You can't have an Apgar with only 4 of the sub-scores. A BP is always some structure containing sys+dia | MAP | PP | CVP | other weird BP + patient position, measurement location, cuff type/size etc. That whole structure is specific to BP measurement. Even the body position value set is different from body position for other measurements that care about body position. You can look through CKM to see many other examples. Docs here might disagree with specifics in some cases, but I think it's pretty clear that non-lab analyte data has its own interior structure.

Pattern Library

So in terms of 'patterns' I suggest that there are the following:

Components

Mix'n'match Lab analytes

Each analyte is a CLUSTER archetype containing what it potentially needs - looks a lot like OPTION 2b, and also Intermountains CEM library. We would potentially re-engineer or map current openEHR lab models to this pattern.

Non mix-n-match Lab results

Complex results like Microbiology are their own ENTRY archetype. Looks like an openEHR OBSERVATION (and I would think an HL7 OBSERVATION) structure.

Other Clinical observation data

Each data group is its own ENTRY archetype. Looks like openEHR OBSERVATIONs.

All other clinical information

Diagnoses, orders etc - these work mostly on a per-ENTRY basis as well, but let's leave this group for another day...

Collections

Lab Panel

Is one ENTRY, containing 1..* CLUSTERs each representing an analyte. Common context on the ENTRY is common to the whole panel; but each CLUSTER can include specific context items as needed.
Defining an actual panel means:

• create a template of cimi-rm-ENTRY.lab_panel archetype
• fill the 'panel items' slot with CLUSTERs representing the analytes
• remove any items you don't want

this just gets you to the 'panel' stage - we don't yet have a 'lab report'! See below.

Health system events - data created for encounters, visits, lab reports, discharge summaries etc

A health system event is when a health professional(s) does something for the patient that can be considered a distinct event, that would cause information to be committed to the EHR. In openEHR, any such action will rsult in one or more COMPOSITIONs being committed or updated on the EHR. Updates can occur to care plan, discharge summary, meds list etc, as well as any other item where an error is being corrected.

A lab report - containing the panel results - plus all the lab order information - is a COMPOSITION.

COMPOSITIONs capture EHR commit audit information, attestation information, and are versioned and UID identified. They allow the EHR to be viewed as a version controlled information base.

I would recommend following this approach for CIMI - it works well in practice.

Conclusion

I think the key point I want to make here is that we can't treat things like Hematocrit and other potentially self-standing mix-n-match lab analytes in the same way as systolic BP, adverse reaction substance, or the many other data items that belong to data groups that have their own innate structure. As long as we stick to that, we have a nice solution for a pattern library.

Reading Thomas’ thoughts:

1-

Or we come to the conclusion that there are different kinds of things we want to group and each gets its preferred pattern.

How many different groups and preferred pattern can we think of?

Kinds of groupings I see:

- Lab panels,

- Finding panels (e.g. Blood pressure, …)

- Lists of Differential Diagnosis, lists of Diagnosis, health Issues, health problems, FOLDER stuff, etc.)

- Protocols/multi step procedures, pathways

- Concepts/constructs derived from other statements (BMI, …)

- Questionnaires with and without calculated results

- Scales with or without calculated results

- ...

- Panels consisting of any of these

Gerard

Agree on the general premise. But, I don't agree with the last line - 'Panels' consisting of any of these. I think a 'panel' is a specific thing, and 'collections' of heterogeneous things is something different. I think this particular issue is causing us real trouble in CIMI right now.

I think what's important are the abstract structures. I am going to try to reclassify below, but first I want to distinguish two kinds of 'context':

• situation context - who / where / when - information about situation, i.e. places, people, time
• specific context - information items that are not the key datum, but are typically required along with it, e.g.
• patient state - exertion, position, etc
• method/protocol - e.g. instrument, measurement protocol, device etc

On that basis a possible partial classification:

I haven't treated computed / summed data items that appear in e.g. Apgar or BMI as special here, because I don't think they change the structure categories. They do of course require special features internal to their respective structures, but I think that's a separate question.

I think Lab results and Questionnaires should be treated as special kinds of collections, whose members are logical atoms of a standard mould, whereas most other clinical data is not like this - each thing is its own structure. There are probably other special kinds of collections as well.

You might not agree exactly (or at all) with the above but I think we have to live with the ontological reality: not everything is the same, and we need to identify the structure of information in the real world in order to find appropriate modelling patterns.

2-

Or we come to the conclusion that there are too many different things to group that depend on local and ever changing needs, we do not care in CIMI.

well the above analysis sort of says that - but it excepts Lab and Questionnaires, Orders etc as specific cases. There are good ontological reasons for this: the structure is always the same, and it's the content that changes within the structure. In the general clinical information case, each type of information is a different structure. It seems to me that that's the nature of reality.

So we can still have a pretty good modelling handle on the clinical information world, even if there is a large category for which each statement = its own structure.

And model these groups as one ENTRY per item and one ENTRY per group total.

Groups that are defined in an external resource/catalogue (Option 4)

Groups that are locally defined in an external resource/catalogue (Option 5)

In real life we need both Option 4 and 5 at the same time because inside an EHR-system Option 5 will work.

But in an EHR-Extract we need to explicitly define what is in the catalogue.

3-

I add to this, that in essence -in real life and to be explicit and correct- healthcare providers execute processes all the time and we should be modeling the data involved in these processes.

I would call clinical process a second or higher order 'structure', and suggest it needs to be modelled by linking / chaining / referencing items in the above table, in process-specific structures. I think this category of modelling is the key to enabling clinical care processes and pathways to be informatised. But we need to solve the basic categories above first.

- The process of ordering (a group with) items. The group is ordered at a point in time. 

- Optionally the process of the execution of that order (The group and at a deeper level with more details the items are executed at other points in time)

- The process of the Result collection (observation) of the individual results per item (Each item is reported on and entered individually at a specific point in time. During Result collection data from the execution can be provided)

- The process of making an Assessment of the group (of lab tests); qualifying the group result.

Yep. This bit is what we modelling in openEHR with Instruction and Action chains. There is now a second order structure called an Instruction index to capture these execution chains.

This is what happens at different moments in time during any delivery of care.

This is the full and safe semantics using a Model of Meaning of a Statement stuff.

4-

When for practical purposes someone transforms these Statements because he needs to present them differently in a report or on a screen, that is fine.

They can make all those transformations, using the Models of Meaning as basis.

we need to treat 'transformations' (particularly into query results) as an explicit thing - they aren't the same models as models of data capture.

This is Template stuff (as Model of Use) that is handled locally outside of the scope of CIMI.

I think you are wrongly using 'model of meaning' v 'model of use' here.  Templates are data sets specific to particular business events; archetypes are specific only to the information types. Archetypes don't vary much, but they are still models of use, just quite stable ones. That's why we always distinguish between template = data-set and archetype = data-group / data-items.

I continue to think that the CIMI modelling approach should be an amalgam of the Intermountain style for Labs & panels, openEHR for general clinical, and we have to do some work to get some other categories like Questionnaires sorted. I think if we could get over this hump, we can really move fast on the model library.