Stream: conformance
Topic: Coding.code - why is it 0..1 and not 1..1?
Vassil Peytchev (Sep 10 2020 at 19:34):
The specification is quite explicit on the intent that the Coding datatype is used when there is a code to be represented, and therefore it is not suitable in most cases to represent "real life" concepts, as often they need to be represented using textual values. That is why almost everywhere in the core specification we see CodeableConcept, where CodeableConcept.Coding.code is used for the coded value, and CodeableConcept.text for the textual value, if a code is not available.
Further, in the discussion for Coding.display, there is the following normative language:
If the 'display' element is populated, the string used in display SHALL be one of the display strings defined for that code by the code system
This implies that a Coding without Coding.code cannot have Coding.display. Is it possible then to have a Coding with only Coding.system, and if so, what purpose would it serve? If not, should Coding.code be 1..1?
Grahame Grieve (Sep 10 2020 at 20:00):
I think there's a corner case where it can be null, but this is normative, anyway
Grahame Grieve (Sep 10 2020 at 20:01):
it's certainly a corner case
Vassil Peytchev (Sep 10 2020 at 20:29):
What is the corner case? Maybe we can add a description, as it is a bit unclear what a corner case might be
Chris Moesel (Sep 10 2020 at 21:18):
Just a guess here, but maybe if an existing system had a code that doesn't match FHIR's requirements for the code type ("Technically, a code is restricted to a string which has at least one character and no leading or trailing whitespace, and where there is no whitespace other than single spaces in the contents") -- then the system might be present and an extension w/ valueString might be used to represent the code??? I don't really know -- I'm just guessing.
Vassil Peytchev (Sep 10 2020 at 21:50):
Ohhh, if there is a Coding.extension, there is no need for code...
Are there other corner cases?
Even with the extension, Coding.display can still only be present if Coding.code is present, correct?
Grahame Grieve (Sep 10 2020 at 21:56):
y
Grahame Grieve (Sep 10 2020 at 21:57):
I think there's some uses where you want to sat there's a system and version but not code. I think they are replicating some weird v2 thing
Lloyd McKenzie (Sep 11 2020 at 02:52):
Systems might occasionally have the display value but not the code - but it's known as a display value, not just text.
Vassil Peytchev (Sep 11 2020 at 03:42):
Still, even in such a case, Coding.display cannot be populated without Coding.code, so an extension is necessary.
Lloyd McKenzie (Sep 11 2020 at 04:06):
Where do you see that rule @Vassil Peytchev ?
Vassil Peytchev (Sep 11 2020 at 04:18):
http://hl7.org/fhir/datatypes.html#Coding
If the 'display' element is populated, the string used in display SHALL be one of the display strings defined for that code by the code system.
and
The Coding data type is used directly when there is certainty that the value must be selected directly from one of the available codes, and the list of possible codes is agreed to by all participants.
Lloyd McKenzie (Sep 11 2020 at 05:23):
I don't read either of those as saying the code must be present
Lloyd McKenzie (Sep 11 2020 at 05:24):
And the validator certainly doesn't force it to exist
Lloyd McKenzie (Sep 11 2020 at 05:24):
It has to be a display string for a code in the system - but nothing says the code must appear in the instance.
Lloyd McKenzie (Sep 11 2020 at 05:24):
@Grahame Grieve - thoughts?
Grahame Grieve (Sep 11 2020 at 06:57):
I think at Vassil is right, in that
If the 'display' element is populated, the string used in display SHALL be one of the display strings defined for that code by the code system.
means that you can't use a display if there's no code. (we could have phrased that differently to avoid that implication).
And because it's an implication, I missed this in the validator - if there's a code present, it makes it a warning if it's not one of the displays (could be an error, but life is more complicated). But if there's no code, it doesn't check the display
Lloyd McKenzie (Sep 11 2020 at 13:23):
Do we need a tracker item to either remove that implication, or alternatively make the implication explicit?
Grahame Grieve (Sep 11 2020 at 16:11):
well, to do something about that. not sure what
Lloyd McKenzie (Sep 11 2020 at 16:29):
I'll raise a tracker - for Vocab I guess
Lloyd McKenzie (Sep 11 2020 at 16:31):
Rob Hausam (Sep 11 2020 at 16:36):
I haven't read the tracker yet (I will), but I'm not sure if this is really too much of an issue. It doesn't really make sense to populate display without also populating code, but as long as the code actually does exist in the code system and the display string is one that is published by the code system for that code, then it shouldn't matter for conformance whether the code is populated or not. That's my take at this point.
Lloyd McKenzie (Sep 11 2020 at 16:45):
Sending display without the code would happen if that's what the sending system has stored. Key thing is that we need the rules clarified.
Rob Hausam (Sep 11 2020 at 16:46):
I agree - clarity is always good.
Vassil Peytchev (Sep 11 2020 at 17:22):
I disagree that sending the display without a code makes much sense. Code A and Code B can have the same Display names - which code is the display name referring to? There is a hierarchy in the data elements explicit in the definition: "one of the display strings defined for that code".
If there is an exceptional case where there is value of exchanging the display name only, this is extension territory - that way, the consumer of the data knows that it is a valid exception, and not a misconfigured server.
There is already a mechanism to send CodeableConcept.text in cases where a coded value is not available, but a textual representation is.
Lloyd McKenzie (Sep 11 2020 at 18:37):
If you've just got a display, then you don't necessarily have something that can be resolved to a unique concept. I'm not saying it's good practice. I'm saying there are system that do it, and we need to be able to share what they have. coding.display and CodeableConcept.text aren't the same notion.
Vassil Peytchev (Sep 12 2020 at 19:25):
If you don't know what the code is that the display came from, conceptually all you have is CodeableConcept.text. It is one of the reasons for existence (and for the encouraged use in the specification) of CodeableConcept.
Lloyd McKenzie (Sep 12 2020 at 19:35):
If you know you have the display value of a code, you don't have to know the code for it to be coding.display. CodeableConcept .text is what the user typed/saw, which isn't necessarily the same thing.
Vassil Peytchev (Sep 12 2020 at 19:44):
How do you know you have the display value of a code if you don't have the code? I think without real life examples these seem to be thought experiments. I don't think the purpose of the core specification is to cover every single corner case, that is why we have extensions. The current text is quite clear, if not necessarily explicit, and it is normative.
Lloyd McKenzie (Sep 12 2020 at 19:57):
If a system stores the display value but not the code, they can know it is a display value without having the code available. I agree it's an edge case. However, I expect that if we start enforcing the rule, it's going to break some systems - and I don't think the current text in the spec is as straight-forward as you assert. At minimum, we need to be clearer - which is what the change request asks for.
Grahame Grieve (Sep 12 2020 at 20:56):
I don't think the purpose of the core specification is to cover every single corner case, that is why we have extensions
This is true, but doesn't apply so much when it comes to invariants, since these can easily rule the corner cases out, in ways that can't be fixed with extensions. So weird corner cases are admissible for discussion on this invariant.
Having said that, it's not particularly persuasive that you can have a display because you have a code, but also, you don't have a code. Given that it's only in weird v2 edge cases (because that is a thing I've seen plenty in v2), the validator at least should make it a warning with strong language
Last updated: Apr 12 2022 at 19:14 UTC
