Stream: implementers
Topic: 1 ServiceRequest w X HealthcareService vs. X ServieRequests
Tim Berezny (Oct 08 2019 at 01:20):
We are trying to determine how to refer to multiple services at one target organization. We have two main options:
1) Many ServiceRequets, one for each ServiceRequest.performer.reference(HealthcareService)
2) 1 ServiceRequests with many ServiceRequest.performer.reference(HealthcareService)
ServiceRequests allows for * ServiceRequest.performer, but I feel like that's much less practical when referring to a HealthcareService vs referring to a Practitioner/PractitionerRole. The main problem with 2) is managing the subsequent workflow status (for example, what if one service gets cancelled and the other does not, how to set the status?) and tallying statistics for ServiceRequet volumes to different services.
What is the prevailing philosophy out the regarding including multiple performer HealthcareServices in a ServiceRequest? I feel like I want to restrict it to one service per referral, but want to understand the rationale behind the 0..* allowance first.
Lloyd McKenzie (Oct 08 2019 at 13:37):
What's your intention with respect to suspending/cancelling part of the order? Typically every individual thing ordered should be a separate ServiceRequest to allow them to be managed separately.
Lloyd McKenzie (Oct 08 2019 at 13:38):
(and resulted separately)
Tim Berezny (Oct 14 2019 at 23:31):
The use case is mainly concerned with sending ONE rather than many updates back to the requester ... but at the same time wants to progress the status of each request at different rates, AND potentially wants to add additional services that were not part of the initial ServiceRequest (and let the requester i.e., family doc) know all of that at once.
I'm puzzling trying to figure out how to put all these pieces together...
Lloyd McKenzie (Oct 14 2019 at 23:48):
The division across multiple resources should never be driven by how much you want to communicate at once. If you need to communicate more than one thing at once and don't want to sue something like _include queries, you're pretty much stuck with messaging. The division of content into one request vs. multiples is driven by what has independent state - and it sounds like in this case you have that.
Last updated: Apr 12 2022 at 19:14 UTC
