Stream: implementers
Topic: CodeableConcept defintion and usage
William Jones DXC (Feb 16 2018 at 10:45):
@Grahame Grieve and others.
We are having a really good discussion on and working towards some really good profiles for acute and GP care with InterOpen.
I'd like your help in providing some guidance on the use of the codeableconcept data type.
Firstly, can you point me to the definition and guidance on usage of codeableconcept type element in a resource.
The argument has come about because one of the InterOpen members is creatively wanting to use codeableconcepts without codes and only using the codeableconcept.text without a codeableconcept.code. Not me, I may point out. I believe this is stretching of the use of codeableconcept.
Final question - is it allowable/desirable usage of the the FHIR standard to have a codeableconcept defined with only a text part and no codes?
Grahame Grieve (Feb 16 2018 at 10:50):
typo: " codeableconcepts without codes and only using the codeableconcept.text with a codeableconcept.code" ?
Grahame Grieve (Feb 16 2018 at 10:50):
yes, there are a few but important cases where you have text and no codings.
Grahame Grieve (Feb 16 2018 at 10:50):
that's an essential part of the definition of it.
William Jones DXC (Feb 16 2018 at 11:08):
yes, there are a few but important cases where you have text and no codings.
Can you provide a use case for this and examples of this, Graham?
In InterOpen it is proposed to use the condition.code codeableconcept with no codes because the codes would be different across systems. Would this be one of the cases when it would be allowable?
Grahame Grieve (Feb 16 2018 at 11:16):
our general advice across all the standards is that you should always preserve whatever codes you have, since the recipient might be able to pick them up. That's why we have both codes + text
Grahame Grieve (Feb 16 2018 at 11:17):
the typical situation where you have just text is where the UI has a pick list, and 'other:' with a text box
Lloyd McKenzie (Feb 16 2018 at 15:10):
The other is where the standard says "this can be coded" but a given implementation only supports free text.
Lloyd McKenzie (Feb 16 2018 at 15:11):
Agree that you should always send what codes you have if you have any. And also that if you send a code, you should send .text too as a fall-back for those who don't understand the code(s) provided.
Malgorzata Schwab (Apr 30 2018 at 23:03):
the Coding inside CodeableConcept would have the display value populated with the user's selection, so CodeableConcept.text can be left blank, can it not
Grahame Grieve (Apr 30 2018 at 23:31):
well, it depends what you mean by 'the user's selection'. The Coding.display is what is fixed by the code system. If that's the text the user had, then there's no need for CodeableConcept.text. But quite often, it's not the same text
Last updated: Apr 12 2022 at 19:14 UTC
