Stream: implementers
Topic: Response to a CommunicationRequest?
Jean Duteau (May 30 2019 at 21:03):
If I am sent a CommunicationRequest, is the "response" always expected to be a Communication resource or could it be something else like a DocumentReference (if I'm sending back a document as a result of the request) or some other Resource?
Lloyd McKenzie (May 30 2019 at 22:19):
CommunicationRequest isn't actionable unless it's got a tag that says it is or there's a Task requesting fulfillment. In terms of what would satisfy the CommunicationRequest, it's certainly ok to satisfy it by just sharing the relevant resource(s). Communication is when you want a formal record of what was shared and with whom that can be part of the record (unlike AuditEvent which generally isn't part of the record or accessible to most users).
Jean Duteau (May 30 2019 at 23:26):
CommunicationRequest isn't actionable unless it's got a tag that says it is or there's a Task requesting fulfillment.
Umm, I don't see why you would say that. The Scope and Usage seem to clearly say that it is an actionable request:
A computer-based decision-support system requesting a reminder or alert be delivered to a responsible provider
I was basically referencing the line where it says:
The performance of a CommunicationRequest may result in a Communication resource.
and wondering whether the performance of a CommunicationRequest had to result in a Communication resource - which you confirmed is not the case.
Lloyd McKenzie (May 31 2019 at 00:15):
No request is actionable without a tag. Someone posting a resource to your server isn't necessarily saying "do this". It might be an "FYI". It might be there awaiting a request for action. The workflow section makes clear how to differentiate actionable from non-actionable request resources.
Tim Berezny (May 31 2019 at 00:29):
@Lloyd McKenzie I understand what you mean by making it actionable with a Task resource, but what exactly do you mean by "tag"? What element represents the tag?
Tim Berezny (May 31 2019 at 00:36):
@Jean Duteau You probably want to avoid "CommunicationRequest", it doesn't mean that you are asking somebody to communication something back to you, by my understanding it means that you are recording that you asked somebody to communicate something to somebody else. e.g., a doctors requests that a nurse communicate with public health to inform them of an infectious disease in a patient.
So, you should probably stick with the communication resource ... and attach a task with the resource saying what you want done with the communication (e.g., you want a response of some sort). The response could be anything you define the workflow to be. e.g., another communication, a documentReference, A communication WITH a documentReference, etc...
(at least ... this is what i'm doing with a similar process)
Lloyd McKenzie (May 31 2019 at 00:51):
Resource.meta.tag (http://hl7.org/fhir/resource.html#Meta)
Lloyd McKenzie (May 31 2019 at 00:51):
CommunicationRequest can be to request something to be communicated to you or to someone else. Communication is used to record what has actually been communicated (and occasionally is used as the delivery mechanism itself)
Tim Berezny (May 31 2019 at 01:30):
Ok, now I'm uncertain about the approach i have in my spec. I've got a methodology that uses the Communication resource itself as the delivery mechanism. Let's say I send a ServiceRequest to a provider. Then the provider wants to send me a little chat message asking me a question about the patient's social history, and expects a response from me.
I can think of a few paradigms to approach this:
1) The provider sends me a Communication resource with a task asking me to respond. I respond with a Communication answering his question.
2) The provider sends me a Communication resource tagged as actionable. I response with a Communication answer his question
3) The provider sends me a CommunicationRequest tagged as actionable. I respond with a Communication answering his question
4) The provider sends me a CommunicationRequest tagged as actionable AND a Task. I respond with a Communication answering his question
My CURRENT plans are to use option 1). Is that the most appropriate approach?
Lloyd McKenzie (May 31 2019 at 02:09):
Why would they wrap the Task in a Communication? Why not just send a Task and update the Task with the answer (ideally having them poll or subscribe to see the change.
Lloyd McKenzie (May 31 2019 at 02:11):
Keep in mind that everything in FHIR is communication of some sort. The Communication resource is really about maintaining a record of information disclosure/sharing as part of the clinical record. I.e. "I gave the patient this brochure" or "I shared the lab result with Dr. Jones". It's used when the audit event isn't enough or appropriate (e.g. the sharing a brochure). You don't need to wrap every bit of data sharing you do in a Communication.
Jean Duteau (May 31 2019 at 04:37):
No request is actionable without a tag. Someone posting a resource to your server isn't necessarily saying "do this". It might be an "FYI". It might be there awaiting a request for action. The workflow section makes clear how to differentiate actionable from non-actionable request resources.
Here is a direct quote from the workflow pattern page: All requests with an intent of "order" authorize something.
That sounds very much like a request with the intent of order is actionable.
Jose Costa Teixeira (May 31 2019 at 10:17):
Seems that the word 'actionable' is crucial. What I read from Lloyd's statement: the server knows that something needs to be done but may not know if that is just a FYI. If I get a FYI prescription, I will not act on it and intent is still 'order'
Lloyd McKenzie (May 31 2019 at 12:10):
An example is probably most useful.
Imagine that a clinician sends an 'active' MedicationRequest to a pharmacy. Should that pharmacy start counting out pills for the patient?
Answer: Absolutely not. It's entirely possible that the prescription was sent as an FYI (for use in subsequent drug-drug interaction checking or for other reasons) and that the prescription is actually being filled elsewhere.
Even if the pharmacy is identified as the target performer by the order, that doesn't necessarily mean the pharmacy should start the dispensing process. Orders are sometimes created on a basis of "here's a prescription. If the symptoms don't get better in the next 3 days, go get it filled.
The prescription is indeed an active authorization. It is not, however, also an implicit request for fulfillment. The workflow project has identified a number of mechanisms for differentiating "Here's an order to store but not action yet" vs. "Here's an order, please fill it". One of those is to stick the 'actionable' tag on the Request resource. Others involve using Task, messaging or operations (e.g. the Claim/$submit operation).
Systems cannot assume that a ServiceRequest or any other kind of request is intended to be actioned merely by the fact that it was posted to their system.
John Silva (May 31 2019 at 13:41):
That's why in V2 there are 'state transition' fields that communicate these intentions. But in FHIR, I guess this now moves to the Task pattern.
Lloyd McKenzie (May 31 2019 at 14:59):
FHIR separates the state of the "authorization" from the state of a particular request for fulfillment against that authorization. (There can be numerous fulfillment requests associated with one order - either because systems are asked and refuse or because the fulfillment requests are only seeking partial fulfillment.)
Last updated: Apr 12 2022 at 19:14 UTC
