Link between goals and other clinical concepts

Ian McNicoll ian at mcmi.co.uk
Mon Jun 23 06:13:13 EDT 2014


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 ;-)

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



============================================
i Heather!

[PP:] 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),

[HVL:] Agreed. Perhaps we should refine the name/description to make
that clearer.

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)

[HVL:] Understood . That is what I was referring to with my comment
“correlation with magnitude and unit constraints would be nice to
have, but is not currently easy to achieve.” We would currently do
that manually in the template. Alternatively we could specialise the
goal archetype for each measurement, but that has lots of overheads as
well.

If we were to look at changing the modelling patterns to allow for a
common CLUSTER to be used within both the measurement OBSERVATION and
the EVALUATION.goal then we could achieve what you asked for. In the
current ADL 1.4 world that would be an enormous modelling overhead as
then no measurement model is standalone and ready to go but needs to
be combined with others in order to be used in every modelling
scenario.
It is not clear that the requirements for goal justify the changed
modelling pattern scenario. The value and clarity of the standalone
OBSERVATIONs is huge.

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).

[HVL:] Depends on what you are trying to achieve. You could do it the
way you describe, and then reaching each goal can be assessed
independently. Or if you want to reduce the BP as a whole, you could
set a goal of ‘Reduce BP’ and have two targets, one for Systolic and
the other for Diastolic

On 23 June 2014 03:48, pablo pazos <pazospablo at hotmail.com> wrote:
> Hi Ian / Thomas / Heather,
>
> That's weird, I didn't received Heathers' response email :)
>
> 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 :)
>
> 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.
>
>
> --
> Kind regards,
> Eng. Pablo Pazos Gutiérrez
> http://cabolabs.com
>
>> From: ian.mcnicoll at oceaninformatics.com
>> Date: Sun, 22 Jun 2014 13:41:47 +0100
>> Subject: Re: Link between goals and other clinical concepts
>> To: openehr-clinical at lists.openehr.org
>
>>
>> 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
>>
>> On 20 June 2014 06:32, Heather Leslie
>> <heather.leslie at oceaninformatics.com> wrote:
>> > Hi Pablo,
>> >
>> >
>> >
>> > Comments inline
>> >
>> >
>> >
>> > Heather
>> >
>> >
>> >
>> > From: openEHR-clinical
>> > [mailto:openehr-clinical-bounces at lists.openehr.org]
>> > On Behalf Of pablo pazos
>> > Sent: Friday, 20 June 2014 10:09 AM
>> > To: openEHR Clinical
>> >
>> >
>> > Subject: RE: Link between goals and other clinical concepts
>> >
>> >
>> >
>> > 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),
>> >
>> > [HVL:] Agreed. Perhaps we should refine the name/description to make
>> > that
>> > clearer.
>> >
>> >
>> >
>> > 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)
>> >
>> > [HVL:] Understood . That is what I was referring to with my comment
>> > “correlation with magnitude and unit constraints would be nice to have,
>> > but
>> > is not currently easy to achieve.” We would currently do that manually
>> > in
>> > the template. Alternatively we could specialise the goal archetype for
>> > each
>> > measurement, but that has lots of overheads as well.
>> >
>> >
>> >
>> > If we were to look at changing the modelling patterns to allow for a
>> > common
>> > CLUSTER to be used within both the measurement OBSERVATION and the
>> > EVALUATION.goal then we could achieve what you asked for. In the current
>> > ADL
>> > 1.4 world that would be an enormous modelling overhead as then no
>> > measurement model is standalone and ready to go but needs to be combined
>> > with others in order to be used in every modelling scenario.
>> >
>> >
>> >
>> > It is not clear that the requirements for goal justify the changed
>> > modelling
>> > pattern scenario. The value and clarity of the standalone OBSERVATIONs
>> > is
>> > huge.
>> >
>> >
>> >
>> > 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).
>> >
>> > [HVL:] Depends on what you are trying to achieve. You could do it the
>> > way
>> > you describe, and then reaching each goal can be assessed independently.
>> > Or
>> > if you want to reduce the BP as a whole, you could set a goal of ‘Reduce
>> > BP’
>> > and have two targets, one for Systolic and the other for Diastolic
>> >
>> >
>> >
>> > Thanks!
>> >
>> >
>> >
>> >
>> >
>> > --
>> > Kind regards,
>> > Eng. Pablo Pazos Gutiérrez
>> > http://cabolabs.com
>> >
>> > ________________________________
>> >
>> > From: heather.leslie at oceaninformatics.com
>> > To: openehr-clinical at lists.openehr.org
>> > Subject: RE: Link between goals and other clinical concepts
>> > Date: Wed, 18 Jun 2014 03:13:09 +0000
>> >
>> > 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
>> >
>> >
>> >
>> > From: openEHR-clinical
>> > [mailto:openehr-clinical-bounces at lists.openehr.org]
>> > On Behalf Of pablo pazos
>> > Sent: Saturday, 14 June 2014 5:21 AM
>> > To: openEHR Clinical
>> > Subject: Link between goals and other clinical concepts
>> >
>> >
>> >
>> > 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!
>> >
>> >
>> > --
>> > Kind regards,
>> > Eng. Pablo Pazos Gutiérrez
>> > http://cabolabs.com
>> >
>> >
>> > _______________________________________________ openEHR-clinical mailing
>> > list openEHR-clinical at lists.openehr.org
>> >
>> > http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
>> >
>> >
>> > _______________________________________________
>> > openEHR-clinical mailing list
>> > openEHR-clinical at lists.openehr.org
>> >
>> > http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
>>
>>
>>
>> --
>> Dr Ian McNicoll
>> office +44 (0)1536 414 994
>> fax +44 (0)1536 516317
>> mobile +44 (0)775 209 7859
>> skype ianmcnicoll
>> ian.mcnicoll at oceaninformatics.com
>>
>> Clinical Modelling Consultant, Ocean Informatics, UK
>> Director openEHR Foundation www.openehr.org/knowledge
>> Honorary Senior Research Associate, CHIME, UCL
>> SCIMP Working Group, NHS Scotland
>> BCS Primary Health Care www.phcsg.org
>>
>> _______________________________________________
>> openEHR-clinical mailing list
>> openEHR-clinical at lists.openehr.org
>>
>> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
>
> _______________________________________________
> openEHR-clinical mailing list
> openEHR-clinical at lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org



-- 
Dr Ian McNicoll
office / fax  +44(0)141 560 4657
mobile +44 (0)775 209 7859
skype ianmcnicoll
ian at freshehr.com

Clinical modelling consultant freshEHR
Director openEHR Foundation
Honorary Senior Research Associate, CHIME, UCL
BCS Primary Health Care www.phcsg.org




More information about the openEHR-clinical mailing list