Stream: implementers
Topic: Coding slice size restrictions
Nick George (Feb 20 2019 at 11:53):
Hello - obscure question here - I noticed a delta between stu3 and r4 with regards to coding slices, like Observation.code.coding:BPCode (xref: http://hl7.org/fhir/bp.html, http://hl7.org/fhir/STU3/bp.html, also tracker item 20409 for bug in the differ)
Nick George (Feb 20 2019 at 11:57):
in STU3, these fields are listed as 0..., but in R4, they're listed as 1...1 . Given that the slicing is open in both cases, it seems like you'd be able to have multiple codings in either case that match those profiles, so I'm curious what the effective differences is. Those are kind of a weird case because I dunno why you'd want multiple codings with the same system AND code, but you could imagine a different case where it were JUST system that were fixed. It seems to me that having Coding slicing be 0.. and 1...1 are effectively the same, since you can always add additional Codings to a CodeableConcept, does that sound right?
Nick George (Feb 20 2019 at 11:58):
erhm, looks like stars go italics, 0...\* above
Nick George (Feb 20 2019 at 11:59):
I guess another way to phrase this question:
if a CodeableConcept has a open slicing for a Coding with a fixed system (e.g., loinc.org), and a size of 1...1, is it illegal to have multiple codings with loinc.org? I guess would be "no" since it's open slicing, it's just that only one of them would "be" the slice (and it doesn't matter which one, as long as there is at least one.
Lloyd McKenzie (Feb 20 2019 at 16:02):
The intention of the slicing is to say "there must be one code that looks like this" - thus the correction in R4. The upper cardinality of "1" will ensure that there's at most one slice with that code and system. We want to support the possibility for other codings as well - including potentially other LOINC codings. It's common for there to be more detailed LOINC codes that you'd want to maintain.
Nick George (Feb 20 2019 at 17:11):
thanks Lloyd, that mostly makes sense. so to be clear, when you say, "The upper cardinality of "1" will ensure that there's at most one slice with that code and system." does that mean that a record with TWO codes with that code any system would be invalid? I know it's a weird and unlikely case, just trying to make sure I understand the implications
Nick George (Feb 20 2019 at 17:13):
and similarly, if ONLY the system were specified but not the code (i.e., "This code MUST have a LOINC code, but we're not saying what it has to be"), and the slice cardinality were 1...1, would a record with TWO LOINC codes be invalid?
Lloyd McKenzie (Feb 20 2019 at 17:17):
The slice is matching the combination of code + system. It's totally fine if there are other codes from the same system
Nick George (Feb 20 2019 at 17:17):
it's the upper bound I'm asking about though
Nick George (Feb 20 2019 at 17:19):
if two records matched (code X system) would that be invalid
Lloyd McKenzie (Feb 20 2019 at 17:22):
Only if you were slicing only by system. If you're slicing by code and system and the 1..1 slice defines a fixed value for code and system, then the cardinality constraint of the slice only applies to repetitions in the instance that match that slice.
Lloyd McKenzie (Feb 20 2019 at 17:22):
I.e. the instance repetition would have to match the system AND the code to be considered a member of the slice and count towards the max cardinality.
Nick George (Feb 20 2019 at 17:23):
ok that makes sense, so even though the slicing might be "open", the max cardinality constrains the max number of records that can match that slice
Nick George (Feb 20 2019 at 17:24):
thanks Lloyd!
Nick George (Feb 20 2019 at 17:26):
is there any restriction you know of that says that (code X system) must be unique? e.g., if I have two identical LOINC codes from the same system, but with potentially different other metadata (e.g., display, user_selected, etc.) would that be legal? weird, definitely, but legal?
Nick George (Feb 20 2019 at 17:26):
(again, thank you so much for being so responsive, it makes a huge difference)
Lloyd McKenzie (Feb 20 2019 at 17:32):
There's no rule that prevents the same code + system pair from being present, though you could define an invariant if you wanted to. We didn't define such an invariant because duplicate codings don't cause harm and there are theoretical use-cases where it might be useful. For example, someone might do that because they want to convey multiple display names. You might also have dumb code that injects translations and doesn't check to see if the code is already there.
Nick George (Feb 20 2019 at 17:39):
makes sense, thanks!
Last updated: Apr 12 2022 at 19:14 UTC
