patrick-werner
commented
5 hours ago Spricht etwas dagegen, bei den snomed-slices, die als discriminator nur ein valueset-binding haben, noch
^patternCoding.system = "http://snomed.info/sct"als weiteres Merkmal hinzuzufügen, um es etwas robuster zu machen für hapi-generierte Snapshots?
Dachte auch erst das wäre eine gute Idee. Aber leider führt das zu einem Problem: Damit matchen alle sct Codes auf den Slice, auch die außerhalb des VS
war ein Denkfehler meinerseits. Spec:
Each slice must use the element definition for the element(s) in the discriminator(s) to ensure that the slices are clearly differentiated by assigning an appropriate value domain, depending on the discriminator type. If the type is value, or pattern, then the element definition must use either:
ElementDefinition.fixed[x], or ElementDefinition.pattern[x], or if the element has a terminology binding, a required binding with a Value Set that enumerates the list of possible codes in the value set ("formally called an 'Extensional' value set") It is the composite (combined) values of the discriminators that are unique, not each discriminator alone. For example, a slice on a list of items that are references to other resources could designate fields from different resources, where each resource only has one of the designated elements, as long as they are distinct across slices.
Dann sollte der Slice aber streng genommen auch nicht matchen, weil er nur 1 von 2 discriminators matcht. Aber ich teste das gerne und füge es ein.
Grund: Ein slice[snomed] welches snomed als system definiert bietet keinen Mehrwert. In Downstream use-cases hat man zudem ein Problem wenn man ein weiteres SnomedCT Slice mit VS binding einführen würde, dann matchen 2 slices. Man könnte das auch mit re-slicing lösen, aber das wäre hier unnötig komplex.