Stream: workflow
Topic: Communication and CommunicationRequest
Virginia Lorenzi (Jan 25 2021 at 00:15):
At the connectathon, we imagined a conversation chain that could be supported using the Communication resource that would emulate secure messaging. It would look like the following (this is an example scenario conversational scenario which stops and starts back up over time):
Party A creates a text message to Party B and embeds in Communication resource 1.
Party B creates a text message to Party A and embeds in new Communication resource 2 with a pointer to Communication resource 1.
Party B creates a second text message a little later and embeds in new Communication resource 3 with a point to Communication 2.
Party A create a text message to Party A and embeds in new Communication resource 4 with a pointer to Communication resource 3.
Party A a while later creates an additional text message and embeds in new Communciation resource 5 with a pointer to Communication resource 4.
I learned from @John Moehrke and @Lisa Nelson that this is not how a communication would work with FHIR and that instead you would need combinations of CommunicationRequest and Communication, which feels very unnatural for me for this use case. I do not want to request that someone communicates and then record that communication occurred and its not necessarily a request/response thing. One side could talk and the other side could just listen for example. @Jeffrey Danford @Lloyd McKenzie @Vassil Peytchev
In general I have a hard time with the use cases for CommunicationRequest except for the idea that I request that someone else communication with a third party. @Debi Willis
Lloyd McKenzie (Jan 25 2021 at 03:21):
It can absolutely work that way. The linkage would work using Communication.inResponseTo. It would actually be inappropriate to use CommunicationRequest. CommunicationRequest is used to say "please share the following information with 'someone'". It would not be appropriate to use that if all you're doing is the equivalent of a secure email. CommunicationRequest would make sense if you wanted to say "please share lab result X with Dr. Jones"
Lloyd McKenzie (Jan 25 2021 at 03:23):
The tricky bit with using Communication and REST is that you're essentially saying "please store this Communication resource on your server" - where it can subsequently be queried by anyone with permission. So it's not quite as 'private' as an email. Obviously, the data would only be something that could be seen by users with permission to see the patient record, but that could be a lot of folks.
Virginia Lorenzi (Jan 25 2021 at 07:44):
I'm not sure about that. I think that it depends how fhir "secure inboxes" are defined. It already is kind of like that with portals. Usually there are multiple people who can look at the doctor's inbox in the EHR.
Vassil Peytchev (Jan 25 2021 at 13:42):
We should also consider that the actual back-and-forth doesn't have to be "pure FHIR" - just like CDS Hooks is based on FHIR, but goes a little bit outside it, a patient-provider or patient-covered entity communications could be its own specification, for example based on the Signal protocol, and still have touch points with FHIR.
Lloyd McKenzie (Jan 25 2021 at 15:52):
There's no such a thing as an 'inbox' in FHIR. All resources - allergies, conditions, prescriptions, Communication are exposed through end-points. Communication is no different than any other. You can ask for resources to be created or updated and you can search on what's already there.
Lloyd McKenzie (Jan 25 2021 at 15:53):
If we're looking at defining something other than that, we're looking at defining custom operations or going outside the FHIR spec entirely.
Lloyd McKenzie (Jan 25 2021 at 15:54):
(And if we're doing the latter, I'm not sure why 'Direct' doesn't meet the requirements, at least in the US)
Virginia Lorenzi (Jan 26 2021 at 05:19):
I understand there isn't an inbox concept. This is what I was thinking:
Requestor can post Communication resources to the Fulfiller.
Fulfiller (server) "responds" by creating another Communication resource linked to the first Communication resource in the server. Requestor, just like with Task learns of the response by querying for Communication resources.
So Requestor (client) does Post and Read/Search of Communication resources. Fulfiller accepts Posts and Read/Search.
I think this is similar to the use of Task.notes.
The benefit of this is you could, in a more formal and richer way log actual correspondence as well as log evidence of correspondence (called patient on Friday and discussed X).
But again, I think Task.note works for this OK. I do not think its good for official correspondence such as the response that shows patient their correction request has been accepted and corrected and shows evidence or that it has been denied, explains why, and explains patient's right to disagree, I think that Task.output would be more appropriate for that
Lloyd McKenzie (Jan 26 2021 at 14:50):
Yes, you can do that. The key thing is that when you're done, you have a bunch of Communication resources sitting on the server that can be queried by anyone with permission. With email, there's a presumption that you can only read emails that list you as a recipient. There's no similar presumption with Communication.
Lloyd McKenzie (Jan 26 2021 at 14:51):
Agree that "formal statement of disagreement" or "formal rejection decision" should be outputs.
Last updated: Apr 12 2022 at 19:14 UTC
