Stream: implementers
Topic: Request Status Code
Paul Watt (Jan 16 2018 at 01:29):
How would Request Status Codes be used when a request is passed to an intermediary system which then brokers the request? The codes appear to be for a request (say a ServiceRequest or ReferralRequest (STU3)) to be sent from the requester to the performer. For example there's no code to say that the request is "submitted" and then "accepted". How would Request Status be used in this instance or is this somewhere else I've missed?
Eric Haas (Jan 16 2018 at 02:22):
That sounds like a task for Task
Paul Watt (Jan 16 2018 at 02:37):
The Task would reference a ServiceRequest (in \\Task\basedOn\)? This would mean that 2 resources would be required and then updated together as the request is performed.
TaskStatus definitely has a better set of codes for this use case.
This is a more complex than having the codes available in the ServiceRequest.
Eric Haas (Jan 16 2018 at 04:01):
The set of statuses are separated because they represent different things. See the discussion of workflow patterns here: http://build.fhir.org/workflow-communications.html
Lloyd McKenzie (Jan 16 2018 at 04:53):
The request just represents the status of the authorization. Task represents the status of the negotiation for fulfillment. You might have numerous tasks tied to the fulfillment of the same authorization. For example, the first few candidates might say "no" - each resulting in an end state of "rejected" while the third one says "yes" and eventually gets to completed. The Request resource (the authorization) remains active throughout until the creator of the authorization confirms they're comfortable with the completion. (Other scenarios include requests for partial fulfillment - first month, first repetition, etc.)
Lloyd McKenzie (Jan 16 2018 at 04:55):
If you're in an environment where Task and Request are totally intertwined and inseparable, you could look at using "contains". And in a messaging environment, you'd convey both. In a pure REST environment, you share the task and point to the previously posted Request.
Lloyd McKenzie (Jan 16 2018 at 04:56):
Take a look at the workflow.html page for some of the different exchange patterns and what you can and can't do with each of them. (And feedback if you think we've missed something or are making things harder than necessary is welcome too.)
Paul Watt (Jan 17 2018 at 02:08):
Thanks Eric and Lloyd. I'll review the workflow page and see if that fits.
Last updated: Apr 12 2022 at 19:14 UTC
