I think we simply add orders.order_status as an Enum. My concern is, if we stop there, we are leaving it up to clients to define business logic, which could end up making things unpredictable or brittle. When we add “draft”, “received” (aka “in process”), and “cosign” (aka “needs cosign”) as additional statuses in the future, a growing number of order-related addons and reports break with each change. Do we try to predict up front all possible statuses we’ll use in the future and ask people to code against them now? Or do we provide advice on working with existing statuses that will be relatively future proof if statuses change? We don’t need to work it all out here. Happy to discuss on a design forum… just want to make sure we have the discussion.
This is the received status I mentioned above. Other potential statuses not covered by FHIR include verbal (active but needs to be signed), needs cosign (needs to be signed before becoming active), and documented (retrospective entry of orders). As an example, here are some workflow diagrams from 2011 I created when we were working through this space at Regenstrief:
I’m not suggesting that we implement all of this up front. But I’m a little concerned about heading down a path that will prevent us from being able to eventually handle these types of workflows if our API stops at CRUD and the business of managing order status is spread across an indeterminate number of addons.