Stream: implementers
Topic: Communication.recipient referencing a HealthcareService
Tim Berezny (Jun 27 2018 at 01:31):
Currently Communication.recipient can reference Device | Organization | Patient | Practitioner | PractitionerRole | RelatedPerson | Group | CareTeam
Since HealthcareService is a parallel concept to PractitionerRole in the sense of targeting a service, and similar to Organization/Group/CareTeam in the sense of targeting a non-unique individual, I suggest the HealthcareService also be a valid reference target.
Conceptually, a use case could be that i am sending an inquiry to a HealthcareService about a client, and the target recipient is unknown to me. Organization is too broad, and the target does not have a Group or CareTeam concept.
Yes/no? Should I submit a change request?
If so, this would be directly applied immediately to the Canadian eReferral specification project for usage of the Communication resource.
Lloyd McKenzie (Jun 27 2018 at 05:20):
@Brian Postlethwaite ?
Tim Berezny (Jul 05 2018 at 14:37):
Added tracker #17448 for this.
https://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=17448
@Brian Postlethwaite , thoughts?
Brian Postlethwaite (Jul 11 2018 at 12:20):
Seems a little strange, and would have thoughts you'd be sending a communicationRequest to the healthcareservice.
As such I would have thought that requester and sender should be able to be completely switched between Com and ComRequest. (to handle the reply part)
Brian Postlethwaite (Jul 11 2018 at 12:25):
The CommunicationRequest.sender does contain the HealthcareService reference type.
Brian Postlethwaite (Jul 11 2018 at 12:27):
The Communication resource is the one that has the actual requested details in it, not the request side.
Tim Berezny (Aug 05 2018 at 15:36):
By my understanding of "CommunicationRequest", we would be using communication instead of communication request (in the world of eReferrals). In the definition of "CommunicationRequest": [CommunicationRequest] is a record of a request for a communication to be performed. A communication is a conveyance of information from one entity, a sender, to another entity, a receiver
The way I recall @Lloyd McKenzie explaining CommunicationRequest to me is that I'm asking somebody for information VIA somebody else. Or, when i'm asking somebody to fetch me information. (Nurse, please find the lab results for this patient). But in the case where I'm communicating or asking for information directly, I would use communication.
Let's say I send a ServiceRequest out, and no provider has been assigned to that ServiceRequest yet. I might later want to send a follow-up communication about that serviceRequest to the HealthcareService with additional info about the patient. Currently, there is no mechanism to do this.
Lloyd McKenzie (Aug 05 2018 at 15:40):
If you want to send information "about" the service request, the simplest is to update the ServiceRequest instances with additional supportingInformation. Keep in mind that everything we do in FHIR is "communicating". Communication is best used when you want to just record record of what was shared (e.g. I disclosed x to the patient's mother; I provided the patient with a brochure) or when your communication event isn't handled by a straight create/update of another resource.
Tim Berezny (Aug 05 2018 at 15:48):
Updates to referrals often come with some kind of narrative. e.g.,
Recipient (DoctorY): "An AssessmentX is required to complete this referral, and is missing from the initial referral package. Please send within 7 days".
Sender: "As requested by DoctorY, here is assessmentX"
So my thought was that these types of actions would send communications to capture the narrative, and the communication would be added to the ServiceRequest.supportingInfo. the AssessmentX would be attached to the communication.
Lloyd McKenzie (Aug 05 2018 at 15:51):
In the REST world, when you POST a Communication, all it does is store the communication and make it available for query. You can't assume the information will cause an update to any other record.
Tim Berezny (Aug 05 2018 at 15:58):
Ok, to accomplish the same thing here is a re-state the last sentence:
So my thought was that these types of actions would send communications to capture the narrative, and the Communication.basedOn would reference the relevant ServiceRequest. Also, AssessmentX would be attached in Communication.payload
Lloyd McKenzie (Aug 05 2018 at 23:47):
I think the challenge is in the use of "I'm sending" as opposed to simply updating something and, if relevant, capturing the "why" in provenance. In REST we're in a world where multiple clients are collectively maintaining shared objects. That's different from the world of messaging we've come from.
Last updated: Apr 12 2022 at 19:14 UTC
