Ad1 there not much against storing it anyway, right? For example, policy might change to do work with loinc, and historical data with loinc codes would then be a pro. Or you might share data internationally with an institution that does appreciate loinc codings.
Ad2 I think loinc bindings that have not been published (you mean the code itself right, not the binding? how does that work in loinc?), should then probably not end up in archetypes.
My gut says you’re right that it’s very useful to have term bindings as suggestions only. But I’d like to get a better feel for the cases. And I also expect we could do more term mappings at archetype level. (At least if you disregard the licensing problem)
Big thanks for all the sum up @ian.mcnicoll !!!
I think the term mappings are the way since they cover also the values as ian pointed out.
We should make this a best practice (some vendors already do that). @damoca so instead of defining code, using the term mapping seems to be a better fit.
I think the important point here is, in general, that we should find a way to apply terms (e.g. term-mapping) as part of the model, otherwise it will be hard to maintain and work with if this is always added later on or e.g. as part of the application that creates the compositions. I think this will lead to quite some inconsistencies.
Terminbindings are something we have already established and carry the potential to do that, at least in theory, I think we either have to come up with something similar or extend their usage as said above. About the constrains, ADL2 supports bindings on template level already ?
@joostholslag i mean if we have the option in the end (mapping_directives), using these bindings as suggestions or not is for me a simple setting in platform config. Also with directives you can edit them.
In fact, according to the specifications, defining_code should only be used if the DV_CODED_TEXT.value is exactly the rubric of the terminology code. Otherwise, DV_TEXT and mappings must be used.
Exactly, for e.g. Problem/Diagnose name we go for the DV_CODED_TEXT, dont think makes sense here to save a plain text and add a term_mapping to it.
Maybe attach a term_mapping for LOINC e.g.
For anythings else we go with term_mappings, since they cover that, e.g. Systolic BP, DV_ORDINALs etc.
In fact, according to the specifications, defining_code should only be used if the DV_CODED_TEXT.value is exactly the rubric of the terminology code. Otherwise, DV_TEXT and mappings must be used.
Actually I think that is incorrect, especially now that we can also carry preferred term. We frequently have situations where we have modelled e.g a list of SNOMED terms but the clinicians want a slightly different UI. As long as that is done under ‘informatics control’ I think ti is more correct to carry the SNOMED code as the defining_code but alongside the text value. That is also identical (IMO!) to the CodeableConcept approach in FHIR
Yes, it is probably too strict for most terminologies, but in SNOMED CT tend to be more permissive, and not think only in the FSN or the preferred term, but accepting any synonym (that could be in the national/local extension) as the value. But of course the specifications could be more clear around this.
I don’t see exactly where is that so explicit defined that the value corresponds the code. I do agree with @ian.mcnicoll that it should also consider preferred term - in fact I read in specs (at Data Types Information Model) that:
The model of DV_CODED_TEXT is designed to capture the actual term chosen by the user or software at runtime, i.e. preferred term or synonym (for terminologies supporting synonyms), or a post-coordination of underlying distinct terms if an expression was chosen as the term (such as an expression supported by SNOMED CT). A DV_CODED_TEXT instance is used if the final textual value chosen by the user is the exact term text (preferred or other) returned by the terminology service for the key (i.e. code_string value). If the user makes even the slightest modification during data entry, a mapping (see Section 5.1.5) to a DV_TEXT should be used instead.
I am not sure I understand how you see this used then. Are you suggesting to ‘decouple’ the value from the code (or preferred term)? How should we ensure that the meaning of the code matches semantically the value entered? how should any validation work if the code is saying ‘A’ but the value is rather a ‘B’ - which one is ‘wrong’, if you get to a point of validating?
I think that decision on whether the local UI is a semantic match for any associated underlying term, has to be the responsibility of the implementer. Particularly as we make increasing use of SNOMED and LOINC, (a good thing) there will also be a need to localise text terms in the UI.
We obviously need to record exactly what the user entered i.e. the DV_TEXT.value but I would argue that if the the system closely couples the UI value and an associated term, then it is legitimate for that to be regarded as the defining_code. The user has no control over this.
So in a End of Life scenario
The UI has a field: ’ Does the patient wish to be resuscitated Y/N ’ but under the hood we use a
CPR decision element in the Advance Intervention archetype, and let’s say the answer is ‘No’
So I definitely need to record ‘No’ as the text value but where to put the SNOMED-CT code which indirectly was selected by the user, because of system design issues. I would argue that the template designer is forcing selection of the SNOMED code and therefore this is legitimately the defining_code and not just another mapping.
I would also like to be able to assert those local terms in the template i.e constrain the local terms so that it is part of the templated definition, not left to agreement with the UI devs.
Yeah, we had this problem in several projects, where the terminology server in the openEHR platform did validate the value and failed since we .e.g. missed from SNOMED the fever (finding).
In the FHIR Bridge when we map a FHIR coding we always GET the term server and replace the existing displays provided by FHIR, because of that.
Usually you have a fixed set of answers for this questions. These ones are provided by the model, if modelers make a mistake here matching the No String to an Yes Snomed code, thats i think a human error that we cannot prevent. I think that’s a risk that we can take. Human error on the modeling side, isnt something we can anyways prevent.
Just some dump theory:
What if we use term_mappings instead, lol.
When we annotate a text like NO with a SNOMED code, in the end that the exact same like a termmapping isnt it ?
Would that not be more consistent + make the AQL part easier + we can use the model bindings (as suggested above) + annotate also LOINC ?
