Storing codes of two external terminologies

for e.g. trying to find out how to traverse the list and get the code_string for ‘snomed-ct’ (This is an addition to my post showing the mappings as a list)

I’m a bit wary of the value of even the broad match categories. the degree of ‘match’ is highly contextual and not solely a function of the codes themselves but of the direct downstream usage of the codes.

1 Like

Right - but you can’t outguess every subsequent use, and we also have to let openEHR users work such things out for themselves. We are not the terminology-matching police after all :wink:

But I would say that there are rational reasons for us to be that in the future.

1 Like

Goes to wardrobe, looks for old uniform from military service days…

2 Likes

Do you do the same for archetype development?

2 Likes

Hi… Just updating that I couldnt use the ‘match’ for storing a number, The field accepts only a single character. Will figure out some other attributes. Do share, if any recommendations.

You are right @Seref - and I have recently come across the need to set this constraint at design time.

In our system we can query a terminology service and get back the terminology with mappings. But for some use-cases I want to add the terminology as local to the archetype or template with bindings. This will be useful for self-contained deployment of an OPT with some UI or integration resources without the need for a specific terminology service.

I would love to see a solution for this in the modelling domain.

4 Likes

I think this probably needs some extra thinking at SEC, as this is different from setting bindings. I’m not clear how it would be supported in ADL/ADL2 right now.

3 Likes

Hi David,

Coming back to this topic, let me see if i understood correctly:
The use case that I am trying to express is the CODED_TEXT validation that happens when storing a code_string into the CDR and terminology_id is checked to see if it contains the code_string.

Having a term (codi_string) that for different reasons may have seen its term set (terminology_id) modified over time, in order to capture all possibilities in the design time, using AD it is necessary to add as many CODED_TEXT as terminology_id for that term?

Hello Pau,

I will make the assumption that when you say “terminology_id is checked to see if it contains the code_string”, you are literally saying that you want to check if the code comes from the terminology, and not checking if the code is part of a specific subset or reference set.

If it was the latter case, there is no mystery: just add as many terminology binding in the archetype as you need for every subset you have. And then you could check if the code is part of any of them.

But, following the initial assumption, you are saying that the terminology_id is modified over time. So, for example, you have a terminology identified as “MY_TERMINOLOGY_ORIGINAL_NAME” that at some point was renamed as “MY_TERMINOLOGY_NEW_NAME”. So, in the data instances you might have stored values as CODE_X::MY_TERMINOLOGY_ORIGINAL_NAME or as CODE_X::MY_TERMINOLOGY_NEW_NAME

To represent that, one option is what you said, add as many DV_CODED_TEXT as you need, one for each terminology_id. Bear in mind that you would also need to constrain the parent items attribute cardinality to 0…1 so that this is interpreted as alternative DV_CODED_TEXT and not as multiple instances.

Another option would be to just add one DV_CODED_TEXT and specify multiple terminologies for it. I have never done this with the Archetype Designer, but I think it is something like this:

1 Like

Hi! Thanks for the answer David.

Let me explore a bit more this option that you mentioned

This seems a possibility which I didn’t know AD is able to do. However, when creating a template, it seems to be necessary to select one or the other

This is what the OPT for that template says - it does not mention catalog_2.

In the use case of having to check one code in more than one value set (in my screenshot “catalog_1” and “catalog_2”), are we back to having to implement as many CODED_TEXT as terminology_id?

Thanks!

You are right, I just did it myself and it seems that the AD don’t like to leave open alternatives in templates. I can’t remember if that is explicitly forbidden in the specifications. Anyone has a clue?

Hi Pau,

I’m still not quite sure what you are asking here.

Using the FHIR Terminology naming we have a

Codesystem - the full set of unique terms in a terminology i.e the whole of SNOMED-CT or the whole of a local data dictionary Codeset like Gender.

Valueset - a subset of one or more Codesystem terms, organised in to some sort of use-case specific list e.g DiabetesDiagnoses

I would not expect the terminology_id (Codesystem id) to change but the Valueset may well change over time.

The terminology_id is captured in the CDR but not the Valueset from where it originated.

Did you really mean that the terminology_id might change? Could you give some examples?

1 Like

I don’t know the specific case that @Pau_Corral is facing, but if we look at the specifications, the terminology_id attribute is of type TERMINOLOGY_ID, that at the end is just a String value. But that string has a specific formatting that includes the version of the terminology:

So, at least in theory, for every new version of a terminology, we will have a new terminology id. Probably it’s not the intended functionality, but that’s what I can interpret from the spec.

PD. I love when we dig into such small details :sweat_smile:

1 Like

Hi Silje,

term_mapping (RM) or term_binding (AM), that is the question :grinning:

In AD you can define term_binding(s) for data structure elements or value sets.

Screenshot 2024-04-29 at 16.52.04

Screenshot 2024-04-29 at 16.50.36

This is supported for quite some time :wink:

1 Like

¿ How to model the use case of allowing a System to accept for the SAME ELEMENT, TWO DIFFERENT TERMINOLOGIES, that CAN NOT BE MAPPED?
In our use case there is a functional need to record diagnostics either with ICD-10 or ATIC.
ATIC Terminology is used in Catalonia as nursing vocabulary in electronic health record, development of care standards, and data analysis on the provision of nursing care.
The thing is, there is NO MAPPING between both terminologies (at least not bidirectional), as ATIC is more specific and granular. There is a partial mapping from ATIC to ICD-10, but not from ICD-10 to ATIC, as it is not always possible to have a 1 to 1 correspondence.
There are ICD-10 with NO ATIC correspondence.
On the other hand, (n) ATIC could match one single ICD-10. But by doing the conversion you would lose granular information.

So, can you indicate to the implementer something like this?

This would be like indicating / saying ?
Accept values for ICD-10 OR ATIC terminologies. Both are valid terminologies.

Or… are we saying… both terminologies are equivalent / mapped. (Which we do NOT want).

As a plan B we where tempted to do this in the TEMPLATE

But probably this would be modelling based on visualization arguments.
Any feedback or other solutions for that use case would be welcome.

I have some comments.

The first thing to consider is that a mapping in a DV_TEXT is not necessarily 1-to-1. You can use the “match” attribute of the TERM_MAPPING to define the type of the mapping (even if there is not known mapping at all). So, that should not be a worry for you.

The second thing is that a mapping is always linked to an original value, that would be the DV_CODED_TEXT.defining_code. With your proposals I understand that you want to allow that the original value can be either an ICD10 or an ATIC code. And then you can make a partial mapping to the other terminology. That is certainly a valid approach, but you have to be aware that it can complicate the future querying and use of the information, since you will always have to support or duplicate queries for both terminologies.

I guess that it is not possible to decide for just one reference terminology (the most granular one) in the defining_code, and add the other one in the mapping when possible/necessary. But that would be in my opinion the best approach.

2 Likes