Stream: implementers
Topic: Communication and CommunicationRequest
Elliot Silver (Mar 22 2017 at 18:52):
Can/should a Communication resource be used to record a failed/attempted communication? The Scope and Boundaries seem to indicate no ("a communication that has occurred."), but the elements seem to indicate yes.
Michelle (Moseman) Miller (Mar 22 2017 at 18:56):
I think that's fine to use Communication for failed/aborted communications -- as you said, the status, notDone, notDoneReason elements all support that. We may need to tweak the introduction to make that more clear (if you want to log a tracker).
Elliot Silver (Mar 22 2017 at 19:11):
So, is it reasonable to expect that each CommunicationRequest that has been acted on in some way, will have a matching Communication?
Lloyd McKenzie (Mar 22 2017 at 19:24):
No more than expecting every MedicationRequest will have associated MedicationDispenses. It totally depends on the workflow. Some systems will capture what was done in response, others won't. And there are often exceptions that don't get tracked as well. Certainly there's no exepctation in FHIR that there *must* be a matching Communication for each CommunicationRequest.
Elliot Silver (Mar 22 2017 at 19:38):
If a sytem was capturing what was done in response, what sort of exceptions would lead to there not being matching CRs/Cs?
Lloyd McKenzie (Mar 22 2017 at 19:43):
The request not getting properly delivered, the Communication getting lost, one communication covering multiple requests but getting linked to all of them. Obviously if have a direct correlation is "important", exceptions can be minimized. But I don't know that many systems treat requests for communication with the same degree of importance as med and diagnostic orders - and thus the chances of things matching up consistently is probably less.
Grahame Grieve (Mar 22 2017 at 20:05):
you would expect that if the systems have a closed loop - closely linked - there would be C for every CR. But as soon as you start aggregating...
Elliot Silver (Apr 04 2017 at 17:03):
If I have a communication from A to B as result of a finding noted in a DiagnosticReport, and B wants to respond back to A, is there a way to link the follow-up CommunicationRequest and Communication to the original Communication? I assume all CRs and Communications include the triggering DiagnosticReport as a topic. Should the second CR.topic and C.topic point at the original Communication?
Paul Knapp (Apr 05 2017 at 09:19):
I would expect the second C to refer to the CR it is responding to. The issue, I think, is referring to the original C which resulted in a CR - I would think you would use CommunicationRequest.topic to refer to the original C and Communication.topic to refer to the CommunicationRequest.
Lloyd McKenzie (Apr 05 2017 at 13:43):
Communication will use "basedOn" to point to the CommunicationRequest that authorizes/requests/suggests it. "topic" is used to describe what you're talking *about*. So creating a CommunicationRequest with a "topic" of a past Communication only makes sense if you're same something like "Please tell John Smith that last week I told something to Mary Smith". If you want to have a CommunicationRequest that points to a past Communication as a "reason" for the new Communication "Please tell John Smith about X because last week I told something to Mary Smith", that would be an extension right now. Though you could certainly propose some sort of a "sequencing" link on Communication - say "inResponseTo".
Elliot Silver (Apr 05 2017 at 16:17):
The specific use case is notifiying a referring physician to schedule a follow-up within a certain period of time, and the referring physician refusing to accept responsibility for scheduling that. So, it is a variation of your example: "Please tell Dr. A that I'm not accepting responsibility for what she told to me last week. " To me that feels like two CR and two C, since the operations will be done asynchronously.
I feel that the Communications should link to each other directly (not through the CR), in part since a CR seems like a transitive thing that might be purged from the system once completed, but a C is more permanent.
Added GF#13167.
Paul Knapp (Apr 06 2017 at 06:33):
Sorry yes .basedOn not .topic, the examples I included in STU3 with the resource use .basedOn. Some documentation would aid implementers.
Lloyd McKenzie (Apr 06 2017 at 14:49):
Feel free to submit a change request around what documentation you think is needed too :)
Last updated: Apr 12 2022 at 19:14 UTC
