After sleeping on this a bit, there may be another approach.
@jteich makes a very valid point. Depending on sequencing of orders from the API along could be a very fragile and potentially dangerous approach (e.g., if the sequencing is not properly supported in all views).
An alternative would be to use order sets & order groups. We have anticipated sequencing (“sort weight”) within order sets, but hadn’t (until now) considered preserving the sequencing within order groups. (FYI – I use “order sets” to refer to the metadata temlpates of potential orders and “order groups” to refer to the data about orders that were actually placed within groups… there’s a lot of old design notes about it here).
So, protocols that require a specific sequence of orders could be defined as an order set and, when the orders are placed, this sequence could be preserved within the order group. If orders within that group are later revised/replaced, as long as the previous_order chain is used, the group could be presented in its original sequence. This could support @vsingh’s use case without the need for trying to preserve an arbitrary sequence for all of a patient orders (which could be viewed and revised in a a myriad of different views & contexts that might have different opinions about how the orders should be sequenced).
So, instead of adding orders.sort_weight (float), perhaps we could meet the same need in a better way by doing what we’ve previously discussed as a first step into order sets: adding order_group and including an order_group.sort_weight (float). Even without order sets in place, Bahmni could begin storing sequence information by defining order groups.