Linking in openEHR: goals and problems

I’m diving into the world of treatmen/care plan in elderly care and mental healthcare. Especially in elderly care there is a desire to link a goal to a problem. While translating the goal archetype: I noticed an element named ‘clinical indication’ that allows for a DV_TEXT entry. I wonder how does a live system link a goal to an actual problem/diagnosis based on the appropriate archetype. So that the system will be able to show an overview of all the goals per problem.
If the interface just shows a free text input field for the DV_TEXT it will be hard to consistently link that value to a problem list.

Hi Joost,

Your friend (sort of ) here is the LINK class.

Every node in an archetype can potentially link to anything else. This is part of the RM so is ‘hidden’ in the tooling but is available at run-time - which is what you have to do anyway since you need to hook up ‘actual’ data with other ‘actual data’ .

Having said all that maintaining all these links through updates, changes ,deletes over time is non-trivial (not just for openEHR) both technically and as a human effort, so be careful!! e.g what happens if someone alters the problem list. THis feels like a good idea but there is a significant overhead. I would also probably still put a code in the clinical indication, even if a link was also added to point to the original actual problem entry.

Heather and I did some work on this years ago for a Swedish project and I will try to dig out the mindmaps. THis was never implemented and perhaps you will see why!

1 Like

@sebastian.iancu might have some ideas here - Code24 make a lot of use of Care Plans.

I suspect I would probably push back on trying to maintain these links. I might suggest carrying a ‘Contextual Problem list’ in the context of a Care plan or other managed care situation , which itself ideally would be a subset of a global problem list for the patient (though this is also difficult to maintain). I’d then just label the Indication with one of the Contextual problems just as Text or codedText.

1 Like

Thanks @ian.mcnicoll the link class is what I was looking for I think.
I already suspected this would be a complex topic.
So reading the spec on the link class I believe I grasp what it does. It can store a link between two (or more) entries and describe the relation. I have a few followup questions:

  • How does one model that an element could potentially link to another element/archetype entry at design time? So the ‘indication’ element from EVALUATION.goal should only be linkable to an EVALUATION.problem_diagnosis. The main usecase for this constraint would be to be able to present the user with a selection list of problems from the COMPOSITION.problem_list. So how will you application know that for this field the problem list should be shown.
  • The target attribute of the link class allows for an DV_EHR_URI so this can record a link between (or from?) the ‘indication’ element for a ‘normal blood pressure’ EVALUTION.goal (in a care plan composition) and a ‘hypertension’ EVALUATION.problem_diagnosis. Semantically you want to link to the archetyped concept of problem_diagnosis I guess. But practically you want to display the value for the problem/diagnosis name element. How should this be handled?
    *The link class only seems a way to record a link. But actually in the described use case you want to not enter (manually nor programmatically) a name for the ‘indication’ you want to record that the value for that element is stored elsewhere. Or am I misinterpreting the link class?
  • Regarding the maintaining of links: Am I correct you can link to the ‘unversioned’ concept of a specific ‘hypertension’ EVALUATION.problem_diagnosis or can you only link to a specific version?
  • What do you mean by manually maintaining the link? If you link to the ‘hypertension’ value in the path for ‘problem/diagnosis name’ if that value is updated in a new version you can show the new value right? Furthermore if a problem is deleted/archived it makes sense to programmatically delete/archive all linked goals, right? Or is this non trivial and will it need manual maintenance?

Interesting suggestion, I will give it some more thought on a more awake moment of a day:)
Wondering now how this will simplify the maintanance of the links. Because every problem is stored within the care plan composition?

I think that if you need such a tight coupling between ‘goals’ and ‘problems’ you might consider a template in combination with ckm-published or self-made archetypes (if the use case is not covered by the ones already published). This will allow you to specify constraints that makes sense semantically, but also can be used (programmatically) by any application.
If on the other hand, the coupling is a bit less tight, use of LINKs are always an option. You could also point to specific version of a composition, even to specific node inside it. It comes down to the uri of the target node. But the semantic of this construction is always less transparent, often deferred to application logic.
The third option is to pack (an organize) all related compositions into a FOLDER (and a potentially subtree). You can also point here to specific versions, and you can also assign meaning to such linking by archetyping and naming folder accordingly. In RM 1.1.0 you also have the ‘other_details’ part, so …lots of options there. This way you maintain a certain level of semantic of goal/problem coupling, the structure is archetyped, while you also keep the whole structure machine-processable, and not so much application depended as the LINK variant.
At Code24 we use all these three variants, for various reasons and purposes, so I can confirm that all are ‘workable’.

  • How does one model that an element could potentially link to another element/archetype entry at design time? So the ‘indication’ element from EVALUATION.goal should only be linkable to an EVALUATION.problem_diagnosis. The main usecase for this constraint would be to be able to present the user with a selection list of problems from the COMPOSITION.problem_list. So how will you application know that for this field the problem list should be shown.

You probably can do this in theory in ADL but tooling does not support it and it would virtually always be done in templates. The Spec group is looking at how we might make this easier but for now, that just needs to be Implementation Guidance.

  • The target attribute of the link class allows for an DV_EHR_URI so this can record a link between (or from?) the ‘indication’ element for a ‘normal blood pressure’ EVALUTION.goal (in a care plan composition) and a ‘hypertension’ EVALUATION.problem_diagnosis. Semantically you want to link to the archetyped concept of problem_diagnosis I guess. But practically you want to display the value for the problem/diagnosis name element. How should this be handled?

The DV_EHR_URI is a path that can point to the specific element (just as we do in AQLs)

*The link class only seems a way to record a link. But actually in the described use case you want to not enter
(manually nor programmatically) a name for the ‘indication’ you want to record that the value for that element is stored elsewhere. Or am I misinterpreting the link class?

You are correct, so you could add the link to a different node (maybe even the root of the archetype, or we could also add a DV_EHR_URI element to the archetype alongside the textual indication. See the allergies archetype ‘Supporting clinical information’ element for an example https://ckm.apperta.org/ckm/archetypes/1051.32.285

  • Regarding the maintaining of links: Am I correct you can link to the ‘unversioned’ concept of a specific ‘hypertension’ EVALUATION.problem_diagnosis or can you only link to a specific version?

Indeed - this is where things get a little tricky - the versioning is actually at the composition level not the individual entry

  • What do you mean by manually maintaining the link? If you link to the ‘hypertension’ value in the path for ‘problem/diagnosis name’ if that value is updated in a new version you can show the new value right? Furthermore if a problem is deleted/archived it makes sense to programmatically delete/archive all linked goals, right? Or is this non trivial and will it need manual maintenance?

Exactly -it is all doable but adds a fair bit of clinical and technical overhead.

1 Like