Stream: implementers
Topic: Communication.payload.contentString change to CodeableConcep
Tim Berezny (Jul 23 2019 at 17:57):
I see in build.fhir.org that Communication.payload.contentString (type string) has been changed to Communication.payload.contentCodeableConcept (type codeable concept).
For those of us implementing the current contentString in FHIR4, for FHIR5 would this just map directly to Communication.payload.contentCodeableConcept.text?
Lloyd McKenzie (Jul 23 2019 at 18:44):
Yes
Geoff Ramsay (Jul 29 2019 at 21:30):
Hi @Lloyd McKenzie (and future readers)
I was discussing this with @Tim Berezny .
I realize that payload.contentCodeableConcept.text is structurally equivalent to payload.contentString, but is it conceptually the same?
As I understand, codableConcept is used to represent values that can be classified with particular terminologies or ontologies.
It seems unlikely to me that payload of a communication is a specific terminology. In our specific case, we intend to use it to capture a record of the sent message - usually a few sentences, or a paragraph.
My fear is that dropping the contentString creates a conceptual barrier to using this resource easily, in favour of reducing perceived complexity in the form the available usage options?
Am I being overly cautious?
Lloyd McKenzie (Jul 29 2019 at 23:44):
With CodeableConcept, there's an expectation that you can send free text when no appropriate codes are available. Everything as text is just a specialization of that case where no value set is defined.
Lloyd McKenzie (Jul 29 2019 at 23:45):
If the Communication.payload were a code, the code would be defining the type of information communicated - it wouldn't be indicating that the code was communicated
Geoff Ramsay (Jul 30 2019 at 13:50):
My fear is that we're using something designed to classify (codeableConcept) for the purpose of sending free text content, and that that will increase the cognative load required to use the resource. (Is that a silly fear? Do I just have PTSD from my HL7v3 implementation history?)
Will it be obvious to new FHIR users that they can use this resource for the purpose of transmitting textual messages?
Is there a large upside to eliminating contentString?
Geoff Ramsay (Jul 30 2019 at 14:25):
(deleted)
trc_slack_bot (Jul 30 2019 at 14:25):
Failure! Third party responded with 403
Lloyd McKenzie (Jul 30 2019 at 14:55):
The problem with allowing string and CodeableConcept is that there's then two different mechanisms to send free text that are semantically identical - valueString and valueCodeableConcept.text. Thus FHIR prohibits having a choice of CodeableConcept and string.
Lloyd McKenzie (Jul 30 2019 at 14:56):
@Josh Mandel do we know what trc_slack_bot is?
Geoff Ramsay (Jul 30 2019 at 15:26):
@Lloyd McKenzie (oops, that was me, I tried to pipe the discussion to a Slack channel to track updates, but the slack outbound webhooks in Zulip don't work! I've since deleted that bot)
Geoff Ramsay (Jul 30 2019 at 15:32):
FHIR prohibits? In principle?
Technically contentAttachment.title is a string.
Lloyd McKenzie (Jul 30 2019 at 15:51):
The FHIR publication tooling prohibits data type choices from containing both 'string' and 'CodeableConcept'. There's no problem having 'CodeableConcept' and 'Attachment'.
Geoff Ramsay (Jul 30 2019 at 18:09):
Can I browse those publication rules publically?
Lloyd McKenzie (Jul 30 2019 at 18:28):
I guess if you consider reading through the code on Github "publicly". :) The change to the tooling was approved as part of the resolution of a change request. I don't believe we have any further methodology documentation there though.
Josh Mandel (Jul 31 2019 at 13:31):
(deleted)
Diego Bosca (Sep 19 2019 at 11:28):
The FHIR publication tooling prohibits data type choices from containing both 'string' and 'CodeableConcept'. There's no problem having 'CodeableConcept' and 'Attachment'.
Doesn't Observation value and component allow both valueString & valueCodeableConcept? Or is this referring to something else?
Eric Haas (Sep 19 2019 at 23:26):
Here is the guidance for payload codes
The content can be codified or textual. As an example of codified content, when working with machine generated communications, the payload may be drawn from a finite, terminology defined set of communications, especially for short, status update kinds of communications where more of a natural language approach isn't appropriate. If the content isn't codified, contentCodeableConcept.text can be used. When using contentCodeableConcept, the CodeableConcept is what is being communicated and is not a categorization of the content.
I assume the codes could be for NLP or something like that but I personally
would prefer codeableConcept as an extension. I think text is more common
than codes and if the only reason to use
Communication.payload.contenCodeableConcept is to use the text element in many
cases then it should be a choice of text instead.
here is what is said about CodeableConcept.text:
A free text only representation of the concept without any coding elements is permitted if there is no appropriate code and only free text is available (and not prohibited by the implementation). For example, using text only, the Observation.valueCodeableConcept element would be:
I agree with the original poster. The CodeableConcept.text is not a
replacement for the actual content of the communication. For example, "Spoke
with patient Y about problem Z and discussed a plan" is not the same as a short
string representing a concept that could be be replace by a code which is the
situation the rule is trying to prevent. The example given in the specification
does exactly this and is seems wrong to me. Communication.payload.text is - as
pointed out implicitly by the previous poster - is IMO similar to the
valueCodeableConcept and valueString elements. they are not intended to represent the
same things. This is explained in the Observation Notes section.
Last updated: Apr 12 2022 at 19:14 UTC
