Stream: implementers
Topic: A Referral "Deferral"
Dave Barnet (Jun 12 2020 at 15:17):
This is a STU3 question. We have a use case where by a referring service can select a number of services that a Patient may refer to. The use case is that a Patient sees a clinician (normally their general practitioner), and a referral to a service is agreed. The GP brings up the available services across multiple providers. The Patient & GP select a number of service providers, and this gets stored as a "deferral" list. The patient is given a number/code, and makes the actual choice from this list at a later date using the number/code to identify the deferral list.
How should we hold the "deferral" list in FHIR STU3? We are thinking that we are making a ReferralRequest, but how do we hold the "deferred" nature of the Request. For example we could say the intent is just a propsal & hold the selected services in the recipient element, or we could create a new extension to hold the list of selected "deferred"services?
Vassil Peytchev (Jun 12 2020 at 15:40):
When you have multi-step workflow like this, using the Task resource will likely help. It would be the place to keep the deferred nature of the request.
Lloyd McKenzie (Jun 12 2020 at 16:27):
A ServiceRequest that represents a referral is just like a MedicationRequest. It represents an 'active authorization'. It doesn't mean anyone has been asked to action it yet. The requisition process is generally handled via Task. What it sounds like you have is a an active ServiceRequest with intent of 'order' and a set of candidate performers. However, you don't have any Tasks associated seeking fulfillment. Once a given performer is identified, you can create a Task to represent the request to fulfill. If the request is refused, you might then have a new Task asking one of the other candidates to fulfill. Once a performer has accepted a fulfillment request, then the referral would no longer be on the 'deferred' list because someone is actioning it. (Though in theory, it could perhaps go back on the 'deferred' list if the accepting provider later cancels because of inability to deliver the service?)
Kevin Mayfield (Jun 13 2020 at 05:17):
Slight digression but I want to ensure I follow @Dave Barnet question for MedicationRequest. Is this correct?
If a MedicationRequest is sent to a queue/store, the pharmacists act of claiming the MedicationRequest would be a Task.
Lloyd McKenzie (Jun 13 2020 at 06:20):
Typically the request that someone act on the MedicationRequest would be a Task. It could then be claimed by a pharmacy. A MedicaitonRequest by itself is an authorization but additional activity (creation of a Task or some other workflow behavior) would be necessary to solicit someone to act on it.
Last updated: Apr 12 2022 at 19:14 UTC
