Stream: implementers
Topic: Change Workflow status names
John Hatem (Dec 06 2017 at 18:57):
Follow-up to Workflow discussion this week. Are there any concerns if Workflow renames Cancelled and Suspended values in the Request.status value set. The proposed name changes would be:
'Revoked' would be used instead of 'Cancelled'. Rationale for change: Revoked is generic and does not distinguish between whether the Order was actually started. In some systems it is important to just state the order is not to be carried out and it doesn't matter ( or is unknown) whether the order has started.
1.Another issue to be discussed separately is that in other systems it is important to distinguish between Cancelled e.g. with my Pharmacy hat on, the use of cancelled would mean the order is cancelled prior to any administrations occurring; and Stopped e.g. with my Pharmacy hat on, the use of stopped would mean the order is stopped at some time after 'some' administrations have occurred.
2.On-Hold would be used instead of Suspended
1.Rationale for change: On-Hold is the more common name in use.
1.Are there any concerns if Workflow renames Aborted and Suspended in the Event.status value set. The proposed name changes would be:
1.Stopped would be used instead of Aborted
1.Rationale for change: Stopped is more commonly used.
2.On-Hold would be used instead of Suspended
1.Rationale for change: On-Hold is the more common name in use.
Eric Haas (Dec 06 2017 at 19:07):
From my perspective, the workgroups will still decide what makes the most sense in their domains and would not change what the current status names to follow these patterns. Bottom line from a committers perspective is we map them to set of statuses in the build which I don't think is aligned to workflow statuses. It would be nice if the workflow statuses were aligned there.
Lloyd McKenzie (Dec 06 2017 at 19:20):
Workgroups absolutely need to decide on what makes sense, though if they diverge, they should chat with the workflow group. The question John is asking whether "on-hold" would be a better name than "suspended". On our call, I thought the proposal around stopped/cancelled for orders was to use "revoked" as the general term and pharmacy would add the notions of "cancelled" and "stopped" but those wouldn't be for general use because they require knowledge of the state of the event, which the authorization generally shouldn't have.
Jose Costa Teixeira (Dec 06 2017 at 19:22):
The status of the request is not intended to capture the status of execution (except a few notable exceptions like "completed"). So i think we should keep the pattern
Jose Costa Teixeira (Dec 06 2017 at 19:24):
I think workgroups should enrich the spec, but not deviate from the notion that request.status is not workflow status
Jose Costa Teixeira (Dec 06 2017 at 19:27):
so on John's question Stopped vs Cancelled, these are workflow statuses.
Stopped can mean "after some administrations have occurred", but could also mean "after dispensing has started". I don't think we can dictate those definitions at the standard level.
Lloyd McKenzie (Dec 06 2017 at 19:31):
Right. "Completed" is a call the requester makes once they have the results which we do allow for. On the workflow call we suggested that Pharmacy see whether they cared about any of the other Task statuses and whether it might be better to have a contained Task within the order if there's a need to convey significant information about workflow state. However, if the determination is that they only need "cancelled" and "stopped", that it's legitimate for them to add those - they would both map to the "revoked" request state.
We can't treat adherence to the workflow patterns as having higher priority than meeting business needs - though when there's a need to diverge, that should be discussed with the workflow group to make sure there's an understanding of the requirement and to see if we can find a way to meet the need and align.
Last updated: Apr 12 2022 at 19:14 UTC
