Open paulolaup opened 3 hours ago
Commenting on solution 1:
We could prioritize the newer version to resolve the display
value ambiguity. However that approach would likely not be very easily applicable when we have to deal with changes in the concept hierarchy. Though one could maybe identify the affected subtree (if we only care about general parent-child relationships) and use values from the newer version.
Maybe it would be best to identify situations were support for concepts from multiple code system versions just does not make sense and should indeed not be supported.
In FHIR a
ValueSet
resource can contain concepts from multiple code systems (represented asCodeSystem
resource) and even concepts multiple versions of the same code system. The Ontology Generator currently does not support the latter since it is not clear how such cases should be handled. For instance, changes between versions could introduce display value conflicts, hierarchy inconsistencies etc. Especially changes in an underlying concept hierarchy or relations in general can impact not just concepts that received the changes directly but also other concept which are related to them. Although generally concepts are not removed but rather deprecated, there is no guarantee that code system maintainers will use this approach reliably. These issues have to be considered in order to safely navigate such occurrences.Thus, future version will have to either: 1) Find some solution that accounts for multiple versions of the same code system and represent them in the ontology accordingly OR 2) Forbid profiles featuring such occurrences