Stream: implementers
Topic: Use case Communication vs Composition
Kenneth Myhra (Sep 17 2019 at 07:37):
I'm trying to figure out which resource to use in the following scenario.
1. A national citizen portal where citizens (patients) can communicate with healthcare personell
2. One feature of the portal is to convey messages between the citizens and healthcare personell
3. These messages will have a title and a body of text
4. These message can also have references to other FHIR resources as well as documents and images (binaries)
-
I have looked at Composition and profiled something that could work, I have also looked at Communication and initially didn't feel it would fit since it is missing the title in 3. above, there is also IMO not a good way of adding a text body like there is in Composition.section.text and using an associated loinc code for it.
Any input or clarification would be appreciated.
Lloyd McKenzie (Sep 17 2019 at 11:11):
Title would be Communication.subject.text. The body of text would go in Communication.payload.contentAttachment. (You would have to base64-encode it though.)
Jose Costa Teixeira (Sep 17 2019 at 11:14):
Title would be Communication.subject.text. The body of text would go in Communication.payload.contentAttachment. (You would have to base64-encode it though.)
for simple text, I would (will) use payload.contentCodeableConcept
Jose Costa Teixeira (Sep 17 2019 at 11:16):
is that wrong? most common case for us is to send a string of text. Besides, we want to limit the message length to 320 characters, which is hard to do if we base64-encode it.
Jose Costa Teixeira (Sep 17 2019 at 11:20):
Communication.subject.text (you mean display?) would work in some cases, but could we have a dedicated field ?
"Subject" can mean "subject of care" as it does today in Communication. But it can also mean "subject of this email, or subject of this thread" and those are two different elements IMO. They could even be different in classification (one is PII, the other not so much)
Lloyd McKenzie (Sep 17 2019 at 12:58):
I'm not sure why CodeableConcept is there actually. On CommunicationRequest, CodeableConcept is used to indicate what "kind" of information you want shared - e.g. a document code. However, in the Communication you'd always want the actual data. @Michelle (Moseman) Miller, what's the usecase for CodeableConcept in the Communication itself?
Grahame Grieve (Sep 17 2019 at 12:59):
sending people a code
Grahame Grieve (Sep 17 2019 at 12:59):
e.g. "Code Blue"
Kenneth Myhra (Sep 17 2019 at 13:07):
Title would be Communication.subject.text.
That should probably be Communication.topic.text? Initially that seemed a bit hackish to me, but if that's the intention
The body of text would go in Communication.payload.contentAttachment. (You would have to base64-encode it though.)
Or Communication.payload.contentString? The only thing I'm missing here is some way of coding it like I would do with Composition i.e: Communication.payload.code.coding.code = 'instructions' or some similar code.
Michelle (Moseman) Miller (Sep 17 2019 at 13:21):
CodeableConcept was added per GF#20770
Communication.payload.content[x] comment summarizes the use case.
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.
Michelle (Moseman) Miller (Sep 17 2019 at 13:22):
I think @Lloyd McKenzie meant that title can be Communication.topic.text (not Communication.subject.text)
Michelle (Moseman) Miller (Sep 17 2019 at 13:28):
FYI -- We have an outstanding tracker, GF#22648, that we need to resolve. This tracker deals with payload differences between Communication and CommunicationRequest. If payload has differences in meaning between Communication and CommunicationRequest, then Patient Care will consider either beefing up the descriptions to make those differences more clear OR possibly rename the elements to mitigate confusion (e.g. assumptions that the payload is the same).
Kenneth Myhra (Sep 17 2019 at 13:55):
Any thoughts on adding Communication.payload.code of type CodeableConcept like Composition.section.code so I can say something about the what the content is / intention of the content?
Kenneth Myhra (Sep 18 2019 at 12:04):
@Michelle (Moseman) Miller added a tracker item requesting to add some way of coding Communication.payload in a similar way as Composition.section.code. GF#24661
Jose Costa Teixeira (Sep 18 2019 at 12:18):
Communication. payload may benefit from the CodeableReference discussion
https://chat.fhir.org/#narrow/stream/179166-implementers/topic/Proposal.20for.20a.20new.20type.20ConceptReference
Last updated: Apr 12 2022 at 19:14 UTC
