Stream: implementers
Topic: Referral Implementation
Ivan May (Jul 23 2020 at 13:01):
Hi All... Busy with my first attempt at a fhir implementation. I am working with a client that spawns referrals from one practitioner to another practitioner. I had a look and a referral resource was included in v3 of the fhir specification and subsequently removed in v4. After some reading it appears that the ServiceRequest Resource might be the replacement for the referral request resource? However I did not see consultation as part of the list of examples. Hence me asking.
Vassil Peytchev (Jul 23 2020 at 13:26):
Yes, the ServiceRequest replaced Referral request. Presumably you could use ServiceRequest.code=3457005 (or one of its children) to indicate that this is a referral.
Note that the ServiceRequest resource only represents the authorization (order) for the referral. If you plan to manage the referral process, take a look at the workflow pages, starting at http://build.fhir.org/workflow-communications.html
Ivan May (Jul 23 2020 at 14:46):
awesome thank you! If I need to attach a questionnaire response to that, do I bundle them?
Lloyd McKenzie (Jul 23 2020 at 15:03):
Whether you use a transaction or batch or send the resources independently is up to you.
Ivan May (Jul 23 2020 at 15:14):
so if I send them independently how do i show the relationship between the resources?
Vassil Peytchev (Jul 23 2020 at 15:23):
"send" is a poorly defined term. Do you plan to use FHIR Messaging, or the FHIR RESTful API as the basis of your communication pattern? Once the communication pattern is established, the Workflow link above shows the use of the Task resource. Task.basedOn or Task.Focus will reference the ServiceRequest. The QueastionaireResponse can be referenced from ServiceRequest.supportingInfo (if that response was essential for the decision to order the referral) or from Task.input (if that response is essential to accept/provide the service) - in some cases it can be referenced from both.
Ivan May (Jul 23 2020 at 15:30):
good point, let me go read up on that for a bit
Ivan May (Jul 23 2020 at 15:30):
thanks for the help so far
Lloyd McKenzie (Jul 23 2020 at 15:30):
References are URL pointers - think of them like hyperlinks. So you create one page (resource) and then in your second page you include a link (Reference) to the location of the first page (resource).
Ivan May (Jul 23 2020 at 15:33):
:+1:
Rebecka Hansson (Oct 30 2020 at 10:53):
Hi! We are currently working on implementing ServiceRequest as a part of referral flow and have looked at the workflow page you linked to, @Vassil Peytchev .I have four questions that I hope any of you may be able to help with:
- How is the Task resource referenced from the ServiceRequest or vice versa?
- We have a need to express documentation/health issue that the requestor writes down before sending the referral. Where would be a good place to put this? This information is currently not structured and we can't be sure about what it contains.
- We have a need to express documentation that the receiver writes down before sending an acceptance/answer of the referral. Where would be a good place to put this? This information is neither currently not structured and we can't be sure about what it contains.
- From the workflow it looks like status of task is changed frequently during the flow. How is this connected to the ServiceRequest status and when will this status change? Which of this statuses should one refer to as the "referral status"?
Vassil Peytchev (Oct 30 2020 at 15:10):
Here is my take, I am curious what others think as well.
- Task.basedOn references the ServiceRequest
- This is likely to be part of the ServiceRequest - ServiceRequest.supportingInfo can be a reference to any other Resource. Alternatively, Task.input can have Task.input.valueString, or Task.input.valueReference or anything in-between
- This is likely to be expressed in Task.output, either directly, or as a reference to other Resources.
- Task.status, Task.businessStatus, and Task.statusReason together allow you to track a complex workflow. An example of that can be seen in the BSeR IG. Until Task.status is in a final state, ServiceRequest.status stays
active
.
Lloyd McKenzie (Oct 30 2020 at 15:38):
- Actually, Task.focus would point to the ServiceRequest (if the Task is saying 'please fulfill this ServiceRequest')
- They can either be in ServiceRequest.supportingInfo or in Task.input. The former if the information is tied to the authorization and independent of who you're asking to perform, the latter if you're adding them on as part of the dispatch process for a specific requested fulfiller
- Agree with Vassil, though there's also Task.statusReason
- The ServiceRequest is the status of the 'authorization'. The Task.status is the status of a specific request for fulfillment. One provider might refuse the Task, but that doesn't necessarily mean the authorization changes. Even when a Task is complete, the authorization might still be active - because that one Task didn't do everything that was authorized. E.g. a ServiceRequest might be for physiotherapy for a year. A Task might only cover a month.
Vassil Peytchev (Oct 31 2020 at 23:14):
Hmm, the current documentation for Task.basedOn states:
Description: Request fulfilled by this task
Definition: BasedOn refers to a higher-level authorization that triggered the creation of the task. It references a "request" resource such as a ServiceRequest, MedicationRequest, ServiceRequest, CarePlan, etc. which is distinct from the "request" resource the task is seeking to fulfill. This latter resource is referenced by FocusOn. For example, based on a ServiceRequest (= BasedOn), a task is created to fulfill a procedureRequest ( = FocusOn ) to collect a specimen from a patient.
The documentation of Task.focus states:
Description: What
task
is acting on
Definition: The request being actioned or the resource being manipulated by this task.
Since referrals (AFAIK) are typically authorizations, with the above definitions, wouldn't it make more sense that Task.basedOn will point to the ServiceRequest representing the referral order?
I also don't think that in general there there will be a secondary "request" for task.focusOn to reference (at least from the point of view of the request initiator). It makes more sense to use sub-tasks for parts of the original request, rather than expecting additional ServiceRequests. Example:
ServiceRequest: lab order for CBC Panel
Task 1: basedOn ServiceRequest, no focus, please fulfill order for CBC Panel
Task 2: basedOn ServiceRequest, focus Specimen, partOf Task 1, collect specimen
Created FHIR#29636 to add more clarification to these.
Lloyd McKenzie (Nov 01 2020 at 05:53):
The referral isn't authorizing the task that says "please fulfill this request"
Vassil Peytchev (Nov 02 2020 at 15:05):
I don't understand the distinction that is being made here. Can you elaborate?
Rebecka Hansson (Nov 19 2020 at 09:41):
Thanks a lot for your input! It helps us a lot in understanding the relation between these two resources. :)
Rebecka Hansson (Jan 21 2021 at 14:32):
Hi! :)
Adding a new question to this thread. We have gotten further with the FHIR profiling of ServiceRequest and Task for the referral scope. However we noticed that there is no subject element in task, though there are a few other elements such as for & focus which can reference any resources. In the referral workflow example, would you say that there is a need to include the patient in the task resource if it always references a ServiceRequest which references the patient?
If there is such a need, in which element does it best fit?
Lloyd McKenzie (Jan 21 2021 at 14:40):
subject is Task.for
Lloyd McKenzie (Jan 21 2021 at 14:41):
We didn't use the word subject because we were concerned there's be confusion between it and Task.focus
Rebecka Hansson (Jan 21 2021 at 14:54):
I see! Thank you for the quick response.
Rebecka Hansson (Jan 21 2021 at 15:46):
Do you have some input on how to model an referral assessment which includes the type of assessment and also some structured notes? By structured notes I mean that we have a need to devide the notes into items with multiple headlines and written texts. Is there a specific FHIR resource that could be used for this, e.g. Composition?
Lloyd McKenzie (Jan 21 2021 at 17:41):
If you just need to pass the discrete data (e.g. recent labs, past procedures, current care plan, whatever), that can just go as ServiceRequest.supportingInformation. However, if you really need control over order of presentation with section headings, etc. then you're looking at Composition. Be aware that if you pass stuff as a FHIR document, you're not going to easily have dynamic behavior of the ServiceRequest in terms of status (active, suspended, cancelled, etc.).
Kunjan Patel (Nov 16 2021 at 11:02):
(deleted)
Last updated: Apr 12 2022 at 19:14 UTC