Stream: implementers
Topic: Sending a ServicesRequest on behalf of another
Tim Berezny (Oct 01 2019 at 16:32):
In a scenario where a ServiceRequest is being authorized/created by one person, but then sent by another (e.g., ER physician creates a referral that is sent by a discharge planner), what is the best way to communicate that relationship to the referral?
Current we have ServiceRequest.requester as a 0..1, but I don't see any concept that would split out author/owner/etc... (which is included in other resources like Task and MessageHeader).
Would adding a "sender" extension be a good approach? (the next best approach I can think of is using MessageHeader.sender, but we lose some RESTfulness there...). Are there other approaches that have been used or are recommended?
Lloyd McKenzie (Oct 01 2019 at 16:46):
SerivceRequest represents the authorization. In pure REST, Task would be used to manage the request for fulfillment. MessageHeader takes up a lot of the functions of 'Task' in the message space - but that does indeed mean that you tend not to be able to perform RESTful queries on the state of the fulfillment.
Tim Berezny (Oct 01 2019 at 17:04):
I was considering Task as well for this as we do use the Task resource. However, we're using Task for fulfillment workflow management, not the sender/requester management. i.e., the owner of the task is the person that receives the referral.
I guess in this case that "Task.requester" could be the person that "submits" the referral and the "ServiceRequest.requester" could be the person who "authorizes" the ServiceRequest ... would that make sense?
Lloyd McKenzie (Oct 01 2019 at 18:07):
Exactly. Request.requester is the one that authorizes. Task.requester is the one who seeks fulfillment. Fulfillment may be sought multiple times (and initiated by different people) for all or a portion of the activity authorized by the Request.
Last updated: Apr 12 2022 at 19:14 UTC
