Is there anyone with experience on giving a [“Problem/Diagnosis name”] (Clinical Knowledge Manager) multiple names? Where different users see different names in the user interface for the same problem. E.g. nurse sees “broken ankle” in the care plan, while the surgeon see “Weber B ankle fracture” in the treatment plan. But we want to record only one instance of the problem diagnosis archetype.
I know it’s possible to record multiple Problem/Diagnosis names, but how do I record which name is relevant for which user?
IMO that’s a terminological problem, basically defining concepts and synonyms, like in SNOMED CT, one concept can have multiple names, and you can assign your local synonyms also. I don’t see any reason why those can’t be mapped to specific roles to show names per audience.
openEHR has the mappings for DV_TEXT but I don’t thing that is the right place to deal with this. A terminology server would be a better place to have those mappings / synonyms.
2 Likes
Hi @pablo thank you for your feedback.
I’m not sure I understand your advice correctly. Do you mean this should be /is solved by a terminology like snomed? Or do you mean it should be implemented in a terminology server?
Either way maybe I didn’t express myself well, but the requirements is to have different names for the same problem, but the names will not be consistent across instances of the problem in different patients. So it’s not a question of how do I map “weber B ankle fracture” to the lay mens term “broken ankle”. It’s about allowing different involved disciplines of caregivers to give a name to the same problem that fits their perspective, without break in the integrality of the problem and collaboration around that 1 problem. So instead of “broken ankle” the caregiver may want to call it “pain in the leg” or something that maps even worse to “weber b ankle fracture”.
And I think this should be stored in the composition, because the name a healthcare professional gives to a problem is highly relevant health information.
Although some of these issues might be solved by terminology synonyms, where there is a direct ‘translation’ e.g ‘Heart attack’ <> ‘Myocardial infarction’, very often there are issues of mismatched granularity and precision e.g ‘Heart attack’ <> ‘ST elevation myocardial infarction’
I would manage this by accepting that different professionals/patients may need to create their own problem lists, managed separately. This applies to inter-professionals also, where a complex cancer diagnosis, may not work well in a GP system.
OTOH, in the medication order archetype we do a carry both the Clinical indication ‘Essential hypertension’ and a patient instruction ’ To lower your blood pressure’, so there perhaps an argument for a new element to carry the patient-friendly description. For other professionals, I think it will be impossible to keep everything aligned. Not only the granularity is different but often nursing assessments have a ‘functional flavour’ rather than diagnostic.
I’d still use the problem/diagnosis archetype but in a different context.
I’m sure we can do better but for now, I think it is going to be extremely difficult to keep all of these contextual usages aligned.
Hi Ian,
Thanks you for your input. You very well put into words what the challenge is. It’s indeed not just a translation problem. But there’s indeed different aspects of the naming, including granularity and precision. But also scope: are related problems described separately, or under the general term e.g. “diabetic foot” could be a separate problem or part of “Diabetes” in the care plan),
naming schemes/classifcations: e.g. OMAHA, NANDA/NIC/NOC etc may have a finite list of what problems are called,
importance: e.g. diabetes is of minor importance for a physical therapist, but of major importance to a GP), responsibility: e.g. a dietician can be responsible for e.g. limited sugar intake, while the GP is responsible for managing more of the aspects of the disease.
All these factors influence how a professional will name a problem. Even though biochemically (biospsychosocially?) it’s the same desease entity.
So are there any ideas about possibilities to record a discipline with each name of the problem/diagnosis?
I agree the term mappings in DV_TEXT would be very hacky. A language in
I agree it’s more feasible to record them as separate instances of the problem/diagnosis archetype. And probably we’ll record a link between the two.
But since it’s conceptually about the same problem and since integrality is one of the core principles of our product I really want to make an effort to find a way to record one problem with different names for each discipline.
I agree the mapping in a DV_TEXT would be very hacky. The language or the formatting in the DV_TEXT would be other candidates but are still quite hacky.
Another strategy would be to replace the problem/diagnosis name ELEMENT in that archetype with a recurring problem/diagnosis name CLUSTER which contains both a name and a discipline ELEMENT. But that would be a breaking change to the archetype. And it would only solve this problem for this archetype while I suspect it will be relevant for many more, e.g. goal.evaluation.
So I’m really hoping for better options.
I honestly think that is impossible/inadvisable, simply because of the potentially significant differences in scope/ complexity/granularity - essentially it is ‘false integrity’ you are trying to enforce uniformity when actually none potentially exists. You will end up with even more data quality issues than you started with.
I don’t think you could even be clear what is the ‘primary’ problem e.g is the patient’s ‘primary problem’ Wet AMD, leading to significantly impaired vision or vice versa?
My limit would be to try to make use of the problem-diagnosis archetype for each contextual problem list, to make it easy to copy between them (plus linkages) but accept that each discipline is coming at the issue from very different directions and that any ‘simple’ answer is likely to mess things up for others.
1 Like
I could, though is more a mapping thing than something you do with one terminology. For instance, you might want to map your terms that don’t match exactly SNOMED CT terms, maybe because are at a different semantic level (e.g. the SNOMED CT term is very specific and your term is more generic, the SNOMED CT term would be “classified” by your term or “related” to your term, but are not the same).
The software component where the mappings between different terminologies, standard and/or local, should be a terminology server, since that is not a responsibility of the EHR per se, neither for the RM or archetypes.
This is by definition a terminology problem, and it’s solved via mappings. When people name things, it is called “interface vocabulary”, which is a constrained/refined vocabulary from “natural language”, and that could be mapped to a “reference vocabulary or terminology” like SNOMED CT.
This is a diagram of how this works, it’s in Spanish but you will get the idea.
So there are two problems, both related with terminologies:
- name things
- define mappings between names of things
Then you can annotate your names of things with the role that uses that term, which could be a third problem.
At the clinical data entry moment, the terminology server is used to search common terms in the “interface vocabulary”, if the term is not there, the EMR allows the clinician to input an “uncontrolled” term. That is flagged to be reviewed later by the “clinical terminology managers”, then it becomes a controller term, correctly mapped with the concept it describes, e.g. a SNOMED CT code. Then the data is actually in the COMPOSITION, but the mappings are in the Terminology Server. So when you want to analyze the data, the TS should be consulted, same for data entry.
This is not a trivial problem you are trying to solve, and involves processes, software components and people. Though there are experiences around this already, check http://www.clei2017-46jaiio.sadio.org.ar/sites/default/files/Mem/CAIS/cais-09.pdf