Link between goals and other clinical concepts

Clinical (archive)
1

Hi, if I want to establish a goal for body weight, I think there’s a need of linking the goal concept with the body weight concept, but the body weight archetype is for measuring the weight not to specify a goal for it.

I understand the difference between a goal (what you want to achieve, fixed value) and the measures (to control your progress and compare with the goal, variable value through time).

Also, I think the target measurement from the goal archetype will depend on the specific concept I’m creating a goal for (body weight), I mean the magnitude and units constraints should be inherited someway from the concept I’m measuring (body weight) into the goal archetype.

Does anyone has an idea of how will be a good way of modeling a goal related to another concept like weight or BP?

Thanks!

2

Hi all, does my previous message make sense?

3

Hi Pablo,

I think that you need a higher level model to link the two things together. openEHR is about modelling the clinical content at the level of what do we want to record in our systems. When we start thinking about workflow, careplans, etc, we need to utilise data within a higher level construct that manages these things.

At the moment, openEHR doesn't have these kind of higher level models but may go there at some stage. We have done a lot of work in care planning and have a system that enables problems with a list of goals and targets. These are all archetyped and captured in compositions based on templates that are constructed from the base archetypes. This gives us a way of recording the data points we need, however the workflow and management of these things is done in software.

Hope that helps.

Regards Hugh

4

Pablo,

It does make sense, but one should consider a third concept - psychology - that keeps off the goal concept from empiric ground and fosters the body weight concept to a real target measurement.

Hi all, does my previous message make sense?

5

Hi Pablo,

Is it safe to assume that you’ve seen the current archetype for Goal? It is here: http://www.openehr.org/ckm/#showArchetype_1013.1.124

In it we have a data element that specifically identifies the archetype and path of the specific node that should be used to capture the actual measurement, eg the weight or height or systolic blood pressure.

This combination of the EVALUATION.goal archetype with various target OBSERVATIONs for recording the actual data is being used in implementations in Australia as part of a personalised care plan, as Hugh has indicated. The correlation with magnitude and unit constraints would be nice to have, but is not currently easy to achieve.

Regards

Heather

6

Hi Heather!

Yes, I was evaluating the goal archetype. Great, now I get what the “Target archetype node” is for.

About that I have a question, what’s the role of the “Target measurement”? My understanding was that’s the value set for the goal (e.g. target body weight), not the measurement to be evaluated against the goal (e.g. current body weight). If that value is the measurement, where should the value for the goal be set? Or the idea is not to set a value like quantity but set a text in “Target”.

My question was focused on the relationship between the value set for the target goal and the archetype used to record the measurements to be compared with the value of the goal. Because the goal and the measurements should comply the same constraints (magnitude, units, etc)

Also, what about when you have a goal for the BP and you need to specify a value for systolic and diastolic? Should I create two instances of the goal? (One for systolic and one for diastolic).

Thanks!

7

Hi Marivan, I don’t fully understand your comment, can you elaborate? Thanks!

(attachments)

image002.gif

8

Hey Hugh! How are you?

I was afraid to reach that conclusion and hoping to an openEHR native solution.

One thing I was thinking of was to specialize the current goal archetype to create, lets say, a body weight goal, is that a valid approach?

About what you do in your care planning app, that’s exactly what we need to do in a small mobile app. I will publish the outcomes later.

Thanks!

9

Hi Pablo,

Comments inline

Heather

10

Hi Pablo
In cardiovascular decision support for critical care, we found that we needed to define a goal or target zone defined by upper and lower limits for both arterial blood pressure and cardiac output. You might like to consider this sort of situation as well as you develop your openEHR constructs.
Best wishes
Mark

11

Hi Mark, good catch. Yes, we already have ranges for each individual goal and also time frames + versioning, because the goal can change in time and you want to save previous values set for the same goal type (BP, weight, …) to be compared with previously recorded values in different time frames.

Thanks!

12

there will be one sooner rather than later, or at least the serious conversations to define it - this comes under the rubric of ‘second order’ clinical structures. Some work has been done on this already, and needs to be brought into the open - I’m going to try to do that in the next little while. - thomas

13

another thing to note - there are thoughts of how we might add a proper ‘epistemic status’ field to the reference model, which would allow any observation data based on archetype X (e.g. BMI, BP etc) to be marked as ‘actual’, ‘planned’, ‘target’, etc etc. I’ve been working on and off on an , which may provide some ideas. - thomas

14

Hi Thomas, is that status similar to the mood idea of HL7 v3 / CDA in Acts?

About the values, I see “actual” and “target” as something useful, but what’s “planned” for? It seems to overlap a little with the concept of INSTRUCTION to be something to do in the future.

Thanks!

15

that’s true - and the existence of Observation / Evaluation / Instruction / Action deals with the coarse grained intentionality & epistemic status. However, at some point a somewhat more precise notion of epistemic status will be needed. E.g. to distinguish between the following for procedures:

16

Hi Pablo,

You can see an example of the Goal archetype in-use via the SHN Heart
Failure template at

http://www.openehr.org/ckm/#showTemplate_1013.26.14

This was my interpretation, which I think aligns with Heather's but
others may vary!

To answer Mark's point, I think the archetpye does support defining a
range of values via the Interval datatypes.

As Thomas has said, this is the subject of some discussion in the CIMI
world. Although some sort of epistemic status flag/mood code seems
attractive, it works very badly for Goal/Target. It is pretty obvious
that the contents of an archetype for Target Blood pressure is very
different for that ob the measurement itself. The only part of the
highly complex blood pressure measurement archetype which has any
value in the blood pressure target archetype are the systolic,
diastolic and perhaps MAP datapoints and even at that level the
original observation data point is a single value , whereas the target
is likely to be an interval. To make an epistemic flag work we would
need to model the original measurement as an interval, which is
entirely possible technically but requires us to further constrain the
measurement archetype at template level to make it useable.

As Heather has pointed out, it might be possible to re-model every key
data point as an individual cluster or even element archetype but that
imposes a very significant burden on the modelling work, particularly
clinical review, where we would again effectively have to re-create
the existing blood pressure measurement archetype as a template with
all of the additional constraints and aggregation. I don't think the
CIMI group have really taken this on-board.

In a sense, at least for the 'Target/Goal' scenario, all that we want
to do is to re-use the datatype and units from the original
'measurement' archetype. We probably need to use different SNOMED
bindings and convert the data type to its INTERVAL equivalent. So I
would question whether there is any real value in re-using the
original constraint pattern. Arguably the only attribute which is
actually copied intact is the unit.

I think it might actually be more sensible to use the current approach
where an existing archetype node is pointed to for information but
that this is then used by tools to replicate/adapt the original
constraints. i.e this is re-use via copy/paste/edit rather than direct
re-use/inheritance.aggregation.

I suppose it all comes down to the value of direct re-use. At least
for the Target/Goal scenario, I suspect the overhead of doing this far
outweighs any benefit, and I think may be another example of
informaticians trying to construct ontologically pure and elegant
solutions which actually just get in the way of implementation.

The eHealth record is fundamentally anti-pattern.

Ian

Ian

17

Hi Ian / Thomas / Heather,

That’s weird, I didn’t received Heathers’ response email :slight_smile:

I think the idea of reusing CLUSTERs is cleaner and simpler than my idea of specializing the goal archetype. What’s nice about that is if we add a slot in the current Body Weight archetype to a CLUSTER to hold the measurement record, the paths in the B.W. archetype may not change.

About Thomas proposal, I see a lot of overlapping between the Epistemic Status and OBSERVATIONs / INSTRUCTIONs, and also with the INSTRUCTION state-machine states. So, I’m not 100% sure if we need add that, maybe if we find some use cases that can’t be modeled otherwise, that would help.

About using intervals for the measurements, I think that’s overkill. A better idea would be just to reuse the constraints for units, magnitude and precision (if the target is DV_QUANTITY). So, if the archetype for the measurement defines constraints for those data fields, in the goal archetype I would set references to those constraints of each limit of the interval defined as goal. I don’t really know if that reference can be done via SLOTs because the reference is not only to an archetype, is to a specific/fine grained part of that archetype, so we might need the path in the SLOT.

Can this be done in ADL 1.4? Is planned to add this kind of fine-grained SLOTs to ADL 1.5?

About goals like “Reduce BP”, I think goals like that have implicit numeric semantics, and what we need are numeric values to be compared with measurements. When we specify “reduce” or “increase”, the next questions is how much? So we need a number. Also, if we set an x..y interval for a goal and the current measurement is z, if z > y, the goal is to “reduce”, but if z < x, the goal is to “increase” (that’s the implicit semantics I mentioned above). I fact to have “reduce/increase” goals was a requirement in a current project and when I mentioned the implicit semantics they removed that requirement, now we have just intervals and first measurement to now if the goal is to increase or reduce.

In general, and because this goal/measurement is really a pattern all over healthcare, I would like to find / define a “best practice” of modeling this using openEHR (maybe just a guide for ADL 1.4 but for ADL 1.5 we might propose some model changes for the IM or AOM to support this pattern as it support the HISTORY pattern and the INSTRUCTION/ACTION pattern to track state changes).

What do you think about specifying how we all model the goal/measurement today to create a pool of real use cases, and then propose some openEHR friendly way(s) of modeling it? (as you notice I’m trying to avoid Hugh’s proposal to use a higher level model to link goal and measurements :slight_smile:

Personally, I have a couple of experiences with this, is not much but is something: one was a complete system design to manage patients with chronic pain and the other a system to manage celiac patients. Both with goals and result tracking.

18

Hi Pablo,
I have copied Heather's response below.

I will stick with my assertion that changing the basic modelling
approach to create CLUSTER or ELEMENT archetypes for every concievable
'targetable' datavalue will create a completely unmanagable set of
models. If the intention is to model data values + units + precision
in a contextless fashion, it would be far more efficient to do this
with a terminology like LOINC.

I also don't agree that every goal or even target has or needs a
quantifiable reduction. If you can forgive my stereotyping, that is
very much an 'engineering' view of the world, which translates pretty
poorly into clinical practice :wink:

Of course we do sometimes need to specify actual targets but broad
goals can be just as important, and often the only thing that can be
asserted.

Having said that, I can see the argument for 're-using' the systolic
blood pressure unit/precision/range constraints from an Observation
archetype in the context of a goal / target. I think that can be
acheived by treating the source archetype as a reference document/node
without the need for a major and very complex/costly use of cluster
and element archetypes by using tooling to point to the target
archetype and importing the quantity constraints at specialisation or
templating time.

There is a broader issue here about abstraction. We can always get a
more sophisticated about our re-use of generic patterns, in ways that
seem elegant and efficient, but in doing so we often leave behind a
significant segment of our clinical stakeholders , and indeed dev.
community who are largely outsiders to this strange world. If you ask
us to re-work every OBSERVATION archetype to use an ELEMENT or CLUSTER
to represent each 'key ' data element. you will force the creation of
at least 3 artefacts instead of 1 - The Observation container, 1
cluster/element for each data point, and a templated archetype so that
we can get clinicians to look at 'blood pressure' in a clinically
meaningful representation.

Ian

Ian

19

Hi Ian,

Yes, creating CLUSTERs for all the stuff than can be measured and we can potentially define goals is a. a big job, b. will change a lot of currently stable archetypes.

In this scenario, maybe the second option is to specialize the goal archetype for each specific measurement. This is a. less work compared to creating CLUSTERs, and b. but will create an implicit dependency to the measurement archetype (if that changes the goal archetype might need to be revised), but I think that is not going to happen too much.

About the quantifiable goals, I’m biased by my experience. As I said, I would like to propose the creation of a use case list to see which kinds of goals are more frequent and how different implementations are modeling this.

For not quantifiable goals, I don’t know if we need a correlation between the archetype of the specification of the goal and the archetype of the measurement. So maybe this discussion only applies to quantifiable goals. For other goals like “low sodium diet” that can’t be evaluated directly (the evaluation would be boolean: yes I’m following the diet, no I’m not following), but an indirectly evaluation can be made on a factor that depends on the diet like the BP: if the low sodium diet is followed by the user, the doctor can measure if the BP decreases. So instead of evaluating against the goal, this is evaluating other factors that depends on the goal and the compliance of that goal by the patient. To evaluate this kind of stuff, I agree with Hugh: we need a higher level on modeling, maybe something related to GDL.

I think the most important things here are:

a) find real use cases to be sure we can model them,
b) differentiate quantifiable and not quantifiable goals,
c) classify those goals in terms of “they can be modeled in openEHR” or “they need a higher level of modeling” (maybe by specializing the goal archetype, maybe with terminology, etc.).
d) create a small modeling guideline just for goals and measurements, maybe just for “quantifiable” and “can be modeled with openEHR” goals.

What do you think?

20

Hi Pablo,

** Yes, creating CLUSTERs for all the stuff than can be measured and
we can potentially define goals is a. a big job, b. will change a lot
of currently stable archetypes. **

Agree but the ongoing maintenance burden is even worse.

Specialisation is certainly a possibility. The problem is that the
potential targets are almost limitless and it would be difficult to
know how many common specialisations to build.

The Heart failure template gives several real world examples,
including a mix of quantifiable and non-quantifiable goals. I have
modelled the non-quantifiable examples as a goal without a target e.g
Goal = "Minimise heart failure related symptoms".

I like the idea of a modelling guideline document and of identifying
exceptions that cannot be handled by the current Goal archetype.

Ian

I like the idea of a modelling gui