Problem with language in defining_code assumed value


When I have this:
ELEMENT[id22] occurrences matches {0..1} matches { – Certainty
value matches {
DV_CODED_TEXT[id58] matches {
defining_code matches {[ac2; at23]}

I can check the value_set if it is possible, that is OK, and then
This must lead to CodePhrase with the TerminologyId connected to the ac2, and the codestring to at23.

How can I retrieve these, I understand I should look in the term_definitions, but which language should I use? How can I find out. I did not find it in the specs, maybe I missed it.





Thomas Beale
April 4, 2016, 9:06 AM

Actually the terminology idea will be 'local' in the current specification, i.e. all archetypes are considered to be from the internal (= 'local') terminology of the archetype. Although I see why you thought it might be 'ac2', which does make sense as well, and maybe we should consider that change in ADL2.

The codestring will be at23; at23 (and ac2) has to be defined in the term_definitions list. You have to work out which language you want to use, but you can always use 'original_language' if you don't have another way of choosing. Does that answer the question?

Bert Verhees
April 4, 2016, 9:20 AM

I must read it again, this week, I come back to this

Bert Verhees
April 14, 2016, 9:50 AM

Yes, it is all well defined this way.

It is only a problem for the implementation, because at pre-validation-time (creating a validator-definition in schematron) it is not known which language is going to be used at validation-time. But it is an implementation issue, not a definition issue. There are elegant solutions for that possible.


Bert Verhees




Affects versions