One of the gaps that I am experiencing is not being able to constrain/enforce mappings at template-level.
e.g. I may have an internal code list which needs to be mapped to a set of SNOMED terms ( The bindings may or may not be available in the underlying archetype) but either way, I have no means of ‘forcing’ the mappings to be carried at run-time.
We also need to be able to constrain a mapping to be expressed against a text value or default text value.
I don’t think we can rely on bindings as these may not be complete, many be incorrect (or out of step with local guidance).
This also relates to my next post which is about managing external terminology which may be split between defining_code and mappings.
1 Like
I’m assuming ADL 2 templates, and not the XML OPT or OET formats?
If the mappings aren’t available in an archetype, you can create a term binding in a specialised archetype or even the template for the term - I don’t think there’s any validation that prevents that? So binding an internal code list in a template to SNOMED terms should already be possible.
I have a few questions about your use cases: Why do we need to define an explicit mapping? When is it not enough to use local codes and to rely on terminology bindings in the archetype, even if they are only defined in a local template? Are there situations where the template data is no longer present?
Also I’m not sure what you mean with ‘to constrain a mapping to be expressed against a text value or default text value’, could you explain?
Hi Pieter,
There is not an unqualified direct connection between a binding and a mapping.
-
A binding carried in a child archetype may not be appropriate at template -level e.g. we do not use or want LOINC mappings, or they may not have been formally Q/Ad and published.
-
Even when published, it is not uncommon for local mappings to be required. As an example I am doing Covid-19 mappings and will need to use a local UK SNOMED CT code in some cases, even though an international equivalent is available - there is good, practical reason for this ( temporary!). Also getting consensus is sometimes impossible.
In some cases we might want to record a plain text default value but have that mapped into SNOMED-CT, though I see that as largely going away in ADL2 when I would expect in most cases to use atCoded template-level codes. (some iDCodes as well).
We also may need to be able define other mappings attributes like ‘match’ and ‘purpose’ as it is going to be important o easily cross-query for SNOMED-CT codes recorded as amappings but with an equivalent match or perhaps flagged as ‘exact synonyms’ so that they can be picked up whether record as defiing_code or as a mapping (perhaps with a convenience function in AQL that can look in both places). This will be a very common issue, where depending on the exact application, there will be disparity between primary use of SNOMED-CT vs. recorded as a mapping.
I guess one possibility might be to expand ‘bindings’ to include the other TERM_MAPPPING attributes and to regard bindings carried explicitly in templates as being mapping directions, which could optionally pull-through bindings in underlying archetypes.
@ian.mcnicoll we had a long discussion on structured info for term bindings, e.g. provenance, ‘strength’ and so on. There is a CR for this as well, although it doesn’t currently carry the discussion info, which I need to dig out. But I would suggest any specific suggestions about adding structure (i.e. extra meta-data) to bindings go in that CR (at least eventually).
1 Like
Here is the link to one of the long discussions on the old technical mailing list about bindings with more meta-data.
1 Like