In legacy mapping scenarios (https://www.openehr.org/releases/RM/latest/docs/data_types/data_types.html#_legacy_mapping_scenarios) the recommendation is to 'create a new DV_TEXT whose value is "(not available)"'. As much as I love English, probably the recommendation should be to use a null_flavour instead of giving an arbitrary value to the DV_TEXT
I don't think I agree with the analysis in this PR. I think the original is probably correct, although it should indicate to put 'not available' in the local language. Alternatively, the rubric could be extracted from the original term, assuming it is available or can be looked up.
But I don't think it makes sense to use null_flavour - something was available, it's just a question of conversion.
However - system implementers should report their experience / preference on this one.
If can be translated into different languages then I think it has little sense to “force” it and probably the best is to leave the text empty. This would ease validation (i.e. what value do you test for if you want to know if the text is compliant with the expected legacy mapping?)
IMHO, leaving just codes would be fine, as it is what systems would try to understand anyway. My suggestion of null_flavour was not a null_flavour per-se, but a kind of code that could be used by systems to know that what happened in the conversion. (and not rely on texts)
Maybe that kind of “code” could be in the purpose attribute. For example, use “legacy conversion” for successful conversions and “not available legacy conversion” in cases where conversion was not available
(I can see the value by normalizing the purpose attribute values in case of successful legacy transformations)
edit: I’m assuming that rubric could end in the dvtext value if the code could be actualy translated by a service, and empty in other way