Citations and references - BMI example

Clinical
1

(Older discussions here and here.)

Following the discussion on today’s SEC call re: supporting linking in Archetypes, it became clear we needed a more sophisticated idea of what kinds of links / citations are needed just in the data. @ian.mcnicoll gave the example of BMI and nested problem list. @joostholslag has described care plans with links (so have I). I’ll ping @siljelb, @heather.leslie and @erik.sundvall here as well in case they have things to say.

I’ll just try to address the BMI example here for now. The challenge is that BMI is logically (in most doc’s minds) a data group consisting of 3 items - height, weight and the BMI (which will all be ELEMENTs containing DV_QUANTITYs, under a CLUSTER). The ‘problem’ we have in openEHR is that height and weight are separate archetypes, since those two things are regularly recorded for all sorts of reasons, not just BMI.

Additionally, recording a BMI might or might not involve measuring and recording weight or height - it might involve a weight measurement, and the (adult) patient might just say their height (since it doesn’t change for decades for most people), or there might already be a height somewhere in the EHR.

So recording a new BMI might involve just recording the BMI value itself (an OBSERVATION), or the BMI + weight, or the BMI + height + weight. Height and Weight are always separate Observations, but if captured with the BMI, they will be in the same Composition; if not, then they will be in previous Compositions.

What @ian.mcnicoll wants to support is to make it always look like the BMI consists of the 3 items, but to allow the height and weight to really be references (aka citations) of the real height and weight ELEMENTs inside their original OBSERVATIONs, wherever those may be in the EHR (i.e. same COMP or not).

I have summarised the intention and a couple of solutions graphically:

bmi
bmi1071×731 110 KB

I have proposed two ways of referencing, see the lower half of the diagram.

I think Solution B is what is needed, i.e. the reference needs to point to a meaningful container (an ENTRY or something higher, e.g. a COMPOSITION), and then it needs to pick out the specific data element needed in the citing location, e.g. an ELEMENT - but it might also be an entire OBSERVATION, or CLUSTER etc.

I’ll show how these kinds of references could be modelled later on. But I’d like to know if our clinical modellers agree with the general characterisation of the need above.

2 Likes
2

Here’s what solution B would look like for the BMI source variables in other Compositions.
bmi2

3

Imho
Two main types:
1- Explicit link to a specific Instance
2- Implicit link to a result of a Query

GF

4

There’s a few more than that - here’s an analysis from a few years ago on the content types that could potentially be in a ‘report’.

I wasn’t originally thinking to try to cover query results in the question of references/citations but quite possibly we should. I’ll keep it in mind.

5

I agree.
I think what we need for this is

  1. A way to constrain a model of a link (DV_EHR_URI) to only be allowed to reference a weight (for the BMI archetype, probably in the protocol section? We discussed this recently and thoughts were going towards regexes. I’ve had trouble working with those, but agree it seems the only solution. And tools should solve be able to solve most issues here.
  2. A way to cite specific instances of data, link already does most of this by allowing to cite data in a version container, but we probably want to allow storing of a copy of the data for record keeping purposes, especiallly of the cited data is in another CDR (without duplicating the data and making it show up twice in AQL’s)
  3. A UI that helps the user pick an existing weight or enter a new one (based on the regular Obs.weight) and creating the citation. There might be some logic in the template to facilitate this behaviour, to capture the AQL that would return all possible/most probable weight measurements.
  4. (Maybe an incoming links standardised rest api, to facilitate safe deletion of cited weights. )

Some intesting usecase is for ZIB modelling (dutch national information models): Where they often refer to another model: e.g. the ‘procedure’ models refers to the ‘problem’ model for its ‘indication’ field. Though I don’t know if they distinguish between including in the model (use_archetype) vs citing a data instance (link). @pieterbos do you know?