Stream: workflow
Topic: request.status = completed
Eric Haas (Mar 31 2020 at 19:24):
request.status = completed definition "The activity described by the request has been fully performed. No further activity will occur."
this is focused more on the requested event than the state of the request.
- Does this imply that the completed request means the requested activity is complete?
- Why doesn't it address the status of the request since the request could be completed and the activity not completed or not even done for some other reason?
- Does the request status substitute for an event status when there is no event resource?
I think it needs to be clarified and somehow de-conflate the request from the requested activity.
@Lloyd McKenzie ?
Lloyd McKenzie (Mar 31 2020 at 19:31):
It means the requester believes the requested activity is complete. If the authorized action is still happening, typically the authorization needs to remain active.
Lloyd McKenzie (Mar 31 2020 at 19:32):
The key difference is that the 'event' could be complete but the request has not yet been determined to be complete - maybe the requester won't be happy with what was done and want it to be done again.
Lloyd McKenzie (Mar 31 2020 at 19:36):
A referral is 'complete' when all of the activity being referred to is done, the referring clinician has any resulting reports and is satisfied that what needed to be done is done. If no feedback is expected, what typically happens is that the order transitions to 'completed' on a timeline when the ordering system "presumes" the task is done. E.g. with prescriptions, if you order 30 days supply, then you might transition the order to 'completed' sometime soon after the 30 day mark. The order being complete essentially means no further action is authorized, so you don't want to transition it too soon.
Eric Haas (Mar 31 2020 at 19:39):
what if the activity is aborted or never started because of some other reason? it's essentialy done the request is done does "fully performed" apply here too?
Eric Haas (Mar 31 2020 at 19:41):
Does the request status substitute for an event status when there is no event resource?
Vassil Peytchev (Mar 31 2020 at 19:44):
Eric Haas said:
Does the request status substitute for an event status when there is no event resource?
No, the request status (generally) follows the state machine for the Request pattern: http://build.fhir.org/request.html
You use Task to keep track of the activity.
Lloyd McKenzie (Mar 31 2020 at 19:48):
If it never started, then it would be odd to mark the request as 'completed'
Eric Haas (Mar 31 2020 at 19:57):
the request is still open but the activity is not started ever. what happens to the request it has to time out. is it passively revoked
Vassil Peytchev (Mar 31 2020 at 19:59):
No, the timeout causes it to be marked as cancelled. The system that owns the request should manage that.
Vassil Peytchev (Mar 31 2020 at 19:59):
statusReason explains why
Eric Haas (Mar 31 2020 at 20:02):
http://build.fhir.org/valueset-request-status.html has no cancelled so need a tracker to align the state machine with the VS
Eric Haas (Mar 31 2020 at 20:03):
which is correct?
Vassil Peytchev (Mar 31 2020 at 20:08):
I don't know, but yes, they should be aligned.
Lloyd McKenzie (Mar 31 2020 at 21:09):
It has revoked or completed - Former is if the action wasn't fully/sufficiently done, latter is if it was
Vassil Peytchev (Mar 31 2020 at 21:12):
Yes, but the state machine has cancelled, not revoked.
Lloyd McKenzie (Mar 31 2020 at 21:41):
Work groups have the right to rename states if they feel it's clearer. We could revisit the pattern if you think Revoked is better
Vassil Peytchev (Mar 31 2020 at 21:45):
It think we are talking about the pattern. The value set in the definition doesn't match the state machine. I think they should.
Lloyd McKenzie (Mar 31 2020 at 21:51):
The value set for the Request pattern is different than for ServiceRequest
Lloyd McKenzie (Mar 31 2020 at 21:51):
They aren't required to be the same
Vassil Peytchev (Mar 31 2020 at 22:28):
The expansion of the value set for the request pattern doesn't match what is in the definition table
Lloyd McKenzie (Apr 01 2020 at 02:44):
Ah - so the issue is the short description. I thought the tooling was supposed to check that. Can you submit a technical correction Jira issue?
Vassil Peytchev (Apr 01 2020 at 13:53):
Last updated: Apr 12 2022 at 19:14 UTC