I am wondering how to handle mapping to SNOMED CT when importing data from a source system into our CDR. More specifically how and where to store:
The original value from the source system
The SNOMED CT code
Potentially the SNOMED CT term
One possible approach is
Using DV_TEXT.value to store the original value from the source system.
Using TERM_MAPPING, with its associated CODE_PHRASE, as target term, to store the mapped SNOMED CT code, and possibly also the SNOMED CT term. We would also use TERM_MAPPING.match to indicate the relationship between the original text and the SNOMED CT concept.
I guess that Archetype designer does not support setting constraints on TERM_MAPPINGS, is that correct? Is it a planned feature? (ping @borut.fabjan or somebody else at Better)
@OscarKarlsson can you supply the template and the list of mappings that you want to be able to add to a template node? Then perhaps somebody OET/ADL savvy (or an AI) could show how to modify/enrich the raw ADL (or OET?) to include TERM_MAPPING based constraints.
Does any OET/ADL expert in the forum know it this would work fine in both ADL 1.x (OET?) and ADL2.x templates?
No, I donāt believe it does..
The attribute I want to map is ārouteā (āadministreringsvƤgā).
In the template, I have added a value set to this attribute. The value set contains the different administration routes available in the source system. I have added it as a list of strings.
So ADL2 supports someting like that if i remember.
Some vendors render Term bindings into the TERM_MAPPING, including Better.
Problem is there are no template based term bindings (adl2 does have it tho).
Something we need to tackle this year.
Yes, this seems like a good approach for this use case. At least theoretically.
Thereās some downsides to that, basically redundancy. So as a base line I wouldnāt. Unless you think one of the synonyms has some value over the fully qualified name, then you could explicitly persist that. But it may be useful for practical reasons. Not terrible to do either I would say.
I have limited practical experience.
What adl2 adds is, term mapping in the template, I donāt think you need this for this use case. is āterm bindingsā. And āterm bindingsā, which is mostly useful for modelling and translating archeype node ids (e.g. an observation or an element) to snomed codes, so you can combine querying on snomed in AQL. Also doesnāt seem too relevant for your use case.
I can see this useful for replicating a āuserSelectedā kind of thing: what the user was presented on the screen when chose the snomed code. Could also be useful for translations
