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

2 Likes
  • 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

Our current implementation rely on FOLDER to collect entries belonging together. It sees like a nice trade-off for maintaining the connections between data, being able to track who committed which data and for querying.

Still this is hard to get right.

1 Like

Quick related question to the SEC members:

Do we have an API endpoint that allows to create links between existing LOCATABLES?

How are LINKs being created currently?

Best,
Pablo.

2 Likes

Hi Pablo,

how would you create a link without updating a locatable object, e.g. inside a composition? Or should the endpoint take care of this as an implicit operation?

1 Like

Hi Birger, by looking at the current model:

https://specifications.openehr.org/releases/RM/latest/UML/diagrams/RM-common.archetyped.svg

There are two options IMO:

  1. Consider LINK a first-class citizen in the model, so it could have it’s own endpoint in the API, thus, that endpoint should handle all params and make all the suitable links internally. IMO it’s up to the implementation if adding a link should or shouldn’t generate a new version of the source LOCATABLE.

For that I would consider if hte source LOCATABLE is COMPOSITION, versioning that is not an issue, but if the source LOCATABLE is another type, the consideration of some implementation not versioning at CONTENT_ITEM or DATA_STRUCTURE levels must be take into account.

  1. Consider LINK as objects depending on the existence of a LOCATABLE containing them, then the endpoint should be at the LOCATABLE level, like using POST /locatable/$uid/links to create links.

On that part there is also an challenge: should we use ‘locatable’ or the specific type in the URL?

If we use ‘locatable’, we’ll need to define a new set of endpoints, that will work over all LOCATABLE types, which might be worth considering for other purposes. But if we use the specific type of LOCATABLE, we will need to add a lot of new URLs, since currently the only LOCATABLE that has endpoints in the API (that I can remember) is COMPOSITION.

None of the above mentions the versioning issue, that should also be taken into account as in case 1.

Considering that analysis, my vote goes to 1. since it seems simpler than the considerations for 2., and in both cases the versioning should be taken into account. IMO the spec should leave that open to implementers, so one implementation can always version when a LINK is created/deleted/modified, the next might never version, and some might consider to version just COMPOSITIONs and not other types.

Not a simple topic, but this IMO was for years a big elephant in the room nobody talked about, which is a pity since LINKs could be a powerful tool.

2 Likes

A more advanced way of doing this will be with something like this model, and archetypes based on it. We need to add a meta-type of the archetype model that allows a constraint for a thing like LINK (or CITATION in the above-mentioned model) to have the RM type of its target constrained, i.e. to say ‘this thing must point to an instance of type X at runtime’.

We don’t have this today, but in the next 6 months, I’d like to see it in the specs.

1 Like

Thanks a lot Sebastian. Based on the advice in this thread, primarily yours and a valuable conversation with @ian.mcnicoll we are leaning towards using FOLDERs to structure and link (semantically and technically) the information in a plan.
I would like to link to (my reply) in this related topic for further context and for archiving purposes. Problem Oriented Medical Record

3 Likes

Any update on this?

See this new post.

1 Like

So after some experimentation and further thinks on the valuable responses given above, we are settling on a design. The approach is to create sections that allow (only) one problem EVALUATION and one or more ‘goal’ sections that allow one goal EVALUATION. This way there is a strict link between the goal and the problem defined by the composition(template). I think this approach makes sense and it seems to work well for building the application page.
This approach does make it a bit more difficult to view the goal for a problem outside of the context of the care plan. E.g. if you look back in the EHR notes where the problem is described (probably in a report composition) you want to easily ‘click through’ to see related goals. So we are planning to model an element to the goal archetype the contains a DV EHR URI referring to the problem. And automatically let the application fill this element based on the problem in the section above the goal entry.
I’ll share my archetypes when they are in a state that matches the descriptions above.

Any thoughts on:

  • specialising the clinical indication dv text ELEMENT into instead of adding a separate dv ehr uri ELEMENT?
  • in this approach the problems are recorded in the care plan composition. This implies the diagnosis is made at the moment of recording the care plan. While in reality the diagnosis is made in a different context. This is acceptable for now but expresses one of the motivations for: Cross-reference, citations and a solution for managed lists
  • we want to be able to record a progress report relating to the goal and/or problem. Should they be individual report composition instances, grouped in an episode FOLDER, with a link between the FOLDER and the goal?

You don’t need to specialise clinical indication - any ‘LOCATABLE’ node in the EHR - basically all archetype nodes and more, have an optional LINK attribute that carries a DV_EHR_URI. So that linkage can be made at run-time. What we don’r have in current tooling isa way to express that in a template.

Yes agree- though sometimes the ‘reason for the care plan’ is not exactly the same as the ‘formal diagnosis’ - here we get into the idea of ‘Contextual problem lists’ @johnmeredith . In a closely defined and constrained system it probably is possible to assert these direct references but becomes harder to govern as the contributing and colliding contextual use-case emerge. To make use of ‘universal problem lists’ requires very careful and clear clinical governance - this isa cultural and clinical problem not technical. So whilst a direct reference is the perfect answer, it may be that the best you can do is a local ‘in-line’ diagnosis with a link to the original diagnosis. But, yes this is definitely one of the use-cases for doing references better.

I haven’t used FOLDERS yet but this is exactly what Code24 and DIPS do, and it makes sense to me.