Stream: implementers
Topic: Multiple Connected ServiceRequests
Tim Berezny (Oct 22 2019 at 23:28):
Let's say I have a lab order with Urine Analysis, Bloodwork, and stool sample. My understanding is that since each of these can be processed separately, it should be 3 ServiceRequests - with the option to connect them via the ServiveRequest.requistion identifier element.
However, much of the info in these 3 ServiceRequests is the same between these 3 connected ServiceRequests. Is there a model where these three ServiceRequests would be a basedOn a parentServiceRequest to connect them and hold the shared data vs. connecting them via the requisition element? What is the preferred practice for these multiple ServiceRequests (i.e., ServiceRequest.requisition vs. some other mechanism to link them together like ServiceRequest.basedOn)?
Lloyd McKenzie (Oct 23 2019 at 00:23):
Shared data is always repeated in FHIR because each resource needs to be shareable independently. Most of the shared data is lightweight references, so it's not a huge imposition.
Lloyd McKenzie (Oct 23 2019 at 00:24):
Note that "basedOn" means "fulfills", not "part of". The only whole/part relationship in the Request space is RequestGroup - and if you use that, then the statuses of the individual requests become moot and the whole collection must be managed with a single state - that on the RequestGroup.
Lloyd McKenzie (Oct 23 2019 at 00:25):
(And even if you use RequestGroup, you'd still have to repeat the subject, author, dates, etc. on each of the child orders)
Grahame Grieve (Oct 23 2019 at 00:28):
check the note on MedicationRequest page about multiple items in a prescription - the same principles apply
Tim Berezny (Oct 23 2019 at 00:39):
Ok I think I see, this page you mention is very useful. https://www.hl7.org/fhir/request.html#compound
I don't think that I want to lose the ability to track the statuses of the individual requests. which I think leaves me with the ServiceRequest.requisition.
Let's say I want have another resource (e.g., a Communication) that is related to the whole requisition rather than individual ServiceRequests, would I use Communication.basedOn.identifier to point to the requisition identifier?
Lloyd McKenzie (Oct 23 2019 at 00:45):
That identifier doesn't really represent a 'request', though I guess it's not prohibited. What sort of 'Communication' would be done in fulfillment of the requisition (which isn't doing anything other than grouping a bunch of independent orders)?
Tim Berezny (Oct 23 2019 at 00:58):
For the use case in question, the provider wants to communicate a summary of the handling of all the requests once they've all been handled, or may want to create a CarePlan that is based on the set of requests rather than any individual request in the set.
Lloyd McKenzie (Oct 23 2019 at 01:18):
You might tie that to a Task that seeks fulfillment of all of them. The CarePlan wouldn't need to involve a Communication. It could simply be basedOn all of the requests.
Tim Berezny (Oct 24 2019 at 17:38):
Related to multiple requests and ServiceRequest.requisition... there is a desire to have a "reason for referral" that is overall across ALL of the connected ServiceRequests. ServiceRequest resource has some reason fields, but that would be for a single component of the set of Requests.
Some ideas I have thus far on how to capture "Reason for Referral" for a requisition with Multiple ServiceRequests:
1) Extend the requisition element on ServiceRequest
2) Have "SupportingInfo" for each serviceRequest point to another resource that holds the "Reason for Referral".
3) Use MessageHeader.reason.text. (This one seems inappropriate as it wouldn't be friendly to a parallel RESTful approach when looking at your referral data)
4) Slice ServiceRequest.reasonCode or ServiceRequest.reasonReference somehow... (i'm new to slicing)
5) Other?
Lloyd McKenzie (Oct 24 2019 at 19:08):
Just specify the reason on each request. SupportingInfo is intended to contain information relevant to the execution of that request - not a reason for the request. MessageHeader information isn't generally exposed to end users. (And you should avoid tying your solution to messaging where possible.)
Vassil Peytchev (Oct 27 2019 at 03:14):
If you adopt a Task-centric approach, many of these questions have possibly simpler answers, for example the ability to have multiple Tasks be partOf a top-level Task, where that Task.reasonCode or Task.reasonReference contains your reason for referral. Or, as Lloyd suggested, have a single Task that is basedOn all service requests (if you don't need to track the fulfillment of each Service Request individually).
Of course, if you need to have the individual ServiceRequests by themselves directly contain the reason, then you'll have some duplication...
Tim Berezny (Oct 30 2019 at 13:00):
That sounds plausible - I'm going to explore that idea of an overarching task vs. duplicating reason across ServiceRequests in depth. Thanks for the ideas. Generally "Reason for Referral" is pretty open text-y, would it be accurate to say that Task.reasonCode.text is a more suitable spot to use than task.reasonReference.display?
Lloyd McKenzie (Oct 30 2019 at 13:36):
Remember that each ServiceRequest might be seen totally on its own. If the reason is relevant, it should be repeated. While you might be designing a message where everything is sent at once, the resource content should always be constructed presuming that every resource is shared independently.
Last updated: Apr 12 2022 at 19:14 UTC
