Stream: implementers
Topic: CommunicationRequest
Brian Postlethwaite (Jan 28 2018 at 20:18):
Trying to clarify the distinction between the sender and requester in the CommunicationRequest resource.
Is this to cover cases where a Dr (requester) asks a receptionist (sender) to send some information to a patient?
Lloyd McKenzie (Jan 28 2018 at 20:28):
A requests B to send C to D
Lloyd McKenzie (Jan 28 2018 at 20:29):
Requester should never be the same as sender (no need to request yourself, you can just do it.)
Lloyd McKenzie (Jan 28 2018 at 20:29):
Could be patient asking clinician to send something to themselves or another clinician. One clinician asking another clinician to send something to them or to the patient, etc.
Richard Townley-O'Neill (Jan 29 2018 at 00:46):
Makes sense, but the element definitions obscure that.
Lloyd McKenzie (Jan 29 2018 at 06:32):
Change request proposing clarifications to the definitions is certainly welcome :)
Tim Berezny (Jan 29 2018 at 16:58):
So in the base case where, It just A communicating with B, would i be using .sender then? (and leaving requester blank)? ... or the other way around?
Lloyd McKenzie (Jan 29 2018 at 18:01):
In that case, you'd be using Communication, not CommunicationRequest
Tim Berezny (Jan 29 2018 at 19:29):
Ah my brain just exploded. Re-orienting myself...
So using Communication for my use case would be ok, here is the scenario:
Person A is asking Person B for some information (e.g., "When should i expect the lab result to arrive"). The key factor about this is I am asking for a response. So, I was previously interpreting "CommunicationRequest" resource to mean, Person A is requesting a communication from person B(i.e., asking a question) and expecting a response in return with the answer (in the form of a communication).
If i send the initial question as just a Communication resource (instead of a communicationRequest), is there a way for me to flag that I'm expecting a response to it?
Lloyd McKenzie (Jan 29 2018 at 20:01):
Hope it didn't make too much of a mess :)
If you're using Communication for "email/texting over FHIR", there isn't currently a way to say "I expect a response". If you're actually wanting to say "please do something", you might look at Task - that's the way of asking for something to be done (and supports tracking of agreement to do it and linking to whatever was eventually done)
Eric Haas (Jan 29 2018 at 20:01):
Communication is an "event" where you are representing the question. It stands alone and not part of request-response chain. If you want - you can create an extension for that flag.
Elliot Silver (Jan 29 2018 at 20:05):
Actually, it can chain using Communication.inResponseTo, which identifies which Communication this one is replying to. But there is no way to indicate that you want a response.
Tim Berezny (Jan 29 2018 at 21:00):
Alright so:
Instead of using a "Communication Request" to "ask" a question, I could use a task to "ask" a question, i would expect a "communication" in response, which would be "based on" the task. @Elliot Silver I see communication.basedOn but not .inResponseTo on the resource, am i missing something?
https://www.hl7.org/fhir/communication.html
(Or create an extension for communication with an "expect response" flag)
Richard Townley-O'Neill (Jan 29 2018 at 23:19):
@Lloyd McKenzie
#14959
Lloyd McKenzie (Jan 30 2018 at 00:21):
Think of Task as throwing an item in someone's "todo" list. Think of Communication as sending someone an email. You can query tasks, see which are complete, mark them as done or on hold, etc. With communication, the message could contain anything under the sun - including a question (or 5 questions) and might be responded to or not and the responses might contain answers to some or all or none or questions back or all sorts of other things.
Lloyd McKenzie (Jan 30 2018 at 00:21):
Both can be useful, but their behavior is going to be fairly distinct.
Paul Knapp (Feb 26 2018 at 13:20):
@Tim Berezny If I want you to send me something then I'd send you a CommunicationRequest and you would send me a Communication (which would probably refer to my CommunicationRequest) which would contain or reference the thing being communicated.
Elliot Silver (Feb 26 2018 at 19:03):
@Tim Berezny, just noticed your comment to me -- inResponseTo was added about a year ago. It isn't in STU3, but will be in release 4
Josh Mandel (May 30 2019 at 01:48):
A requests B to send C to D
I'm still puzzled by this: is "C" a payload representing the body of a message for D, or is it the body of the request for B to read/process? The documentation seems to suggest that payload can somehow be used for both -- and indeed The only example uses payload to say "Please provide the accident report and any associated pictures to support your Claim# DEF5647." -- which is presumably the message that B would read in order to prepare the content in C... But the documentation indicates this would be the payload for C.
Josh Mandel (May 30 2019 at 01:48):
Should I be reporting an issue on the resource, or am I just confused about how this is supposed to work?
Josh Mandel (May 30 2019 at 01:50):
When using contentCodeableConcept, the CodeableConcept is what is being communicated and is not a categorization of the content.
Is not clearing things up for me
Lloyd McKenzie (May 30 2019 at 02:17):
C can either be the explicit content to send or a description of the type of content to send. If you think further clarification is needed, feel free to submit an issue.
Josh Mandel (May 31 2019 at 19:29):
I'm not sure I understand the intent -- "description of the type of content to send" would be "Accident report" (in some... codified way?). What the example shows is actually a message written from A to B.
Josh Mandel (May 31 2019 at 19:34):
I submitted GF#22648
Luan Garrido (Mar 24 2020 at 14:47):
Is is right to save sent e-mails, for example calling for telemedicine, as CommunicationRequest resources? The e-mail itself should be represented as Communication resource?
Example: A main Practitioner send a link by e-mails to a Patient and a Specialist.
In this case, I would have 1 CommunicationRequest (2 recepients) and 2 Communication (each e-mail itself).
Thanks =)
Lloyd McKenzie (Mar 24 2020 at 14:56):
Typically in FHIR, when you want to send information, you just send information - no need to wrap it in Communication. Communication is about maintaining a clinical record (as opposed to audit record) that data was shared. However, if you're trying to represent an email exchange using FHIR, Communication is the appropriate mechanism. In your scenario, there's no obvious need for CommunicationRequest. The email could be represented with a single Communication as multiple recipients are allowed within a single Communication.
Last updated: Apr 12 2022 at 19:14 UTC
