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 Evaluation Archetype: Adverse reaction risk [Apperta UK Clinical Knowledge Manager]
- 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:
- 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.
- 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.
So my archetypes are in a presentable state. Please don’t share or use them without prior consent from Nedap.
(some Dutch, still working on English versions, let me know if it’s a problem)
The design considerations are as follows:
TLDR: An archetype to share a base structure among care plans for different sectors in our EHR, with the following structure:
-problem(s)
–goal(s)
—action(s)
The requirements of different plans:
- A mental healthcare treatment plan consists of: a diagnosis(problem), goal(s), action(s). There is usually one problem for wich the patient is treated. Often this problem has multiple facets e.g. mood+anxiety but the usual recording structure is a single diagnosis textfield.
- An elderly care doctors care plan consists of: 1 reason for admission (problem) with a main goal. And multiple problems each with one (or multiple) goals, with eacht goal containing one (or multiple) actions. Problems are classified according to SFMPC domain.
- An elderly care nurses care plan consists of multiple 'problems) which each have one (or more) goal(s). Each goal goal contains one (or multiple) actions. The problems are classified by domain. There are different commonly used domain structures. (omaha, mikzo, 4 domais etc)
Common structure
De commonality between these plan is the structure "problem-goal-action). In mental healthcare there is usually a ‘single’ problem. In elderly care theres usually multiple problems. So I modeled a common archetype on this structure.
To model this problem-goal-action structure and there relations (containment) of which each layer can have one or multiple occurrences depending on sector and individual patient, I choose sections. Each layer has it’s own section. The first layer (after the care plan layer) is a problem-goal-action-combination-section. This contains one or more problems (international problem/diagnosis) and a goal-action-combination-section.
- The mental healthcare (GGZ) template is about a single problem so it constrains this section to allow for only one problem. This will make the relation between goal (-s section) and problem explicit. -
- If you want different goals to be about different problems you create different -problem-goal-action-sections, each with 1 problem and the goal(s) that is/are about this problem
- if you want different goals to be about multiple problems, you record different problems in the same -problem-goal-action-section.
Same goes for goals-actions relationships.
(use links between other structures e.g. actions that are also about a different problem)
The advantage of these shared archetypes is 1 frontend code reuse and 2 integrating a mental healthcare plan into a elderly care plan. This allows the client and the caregiver to get a single overview of all the problems and their care.
These common archetypes have been modeled to allow maximum freedom to change the structure per use-case. For example 1 or multiple problems per plan.
Evaluation reports
In elderly care (but not yet in mental) it is common to write reports ‘on’ a problem/goal. The structure and context of this report closely resembles a normal dossier report. So it was chosen to model these reports on problems/goals as dossier report, independent from the plan. Next a link will be recorded between this report and the plan (problem/goal). This still allows the current screen design. It will still be possible to add a report from a problem in the plan that will then automatically record a link to that problem. But it allows more freedom to create specific structured reports to be showed in the dossier timeline.
Domains
In the current structure problems are contained by a single domain. So a domain-problem-goal-action seemed sensible. But after further thought, domain is more an attribute of the problem. So it was chosen to model this more precisely by giving a problem a domain label element. This still allows for our current screen design that shows problems per domain. Moreover it allows linking problems to multiple domains and to multiple domain systems. E.g. the same problem (Diabetes) can be classified and shown to a doctor as an S (Somatic) problem and classified as “physical wellbeing” domain in the nurses care plan.
Feedback is most welcome.
open questions/todo
- should this stay an archetype or become a template? I’m leaning to template because template overlays on the shared level could be nice.
- implement main problem and goal on this level
- update ‘betrokken behandelaren’ to use the new person cluster.
- translate to english
Archetypes: GitHub - joostholslag/archetypes
Hi Joost,
might be an idea to put those archetypes in a little Github repo, since then it is easy for anyone using ArchetypeDesigner to just see them (of course, they’d need to fork to be able to make changes). Just a thought.
1 Like
Smart idea. Done, edited the original message.