Revising and Renewing Orders

[mseaton (Mike Seaton)]

@burke

For example, when an order is revised, we void the prior version of the order and issue the new one. The revision (the order) would be sent to other systems (e.g., via HL7 messages), but not the internal void operation

Whoa - hang on @burke Are you saying that a REVISE operation should void the previous order? That is not what the API currently does - the API stops the previous order. If the revising order has a dateActivated of T, the API sets the “dateStopped” of the previous order to “T - 1s”. So the result is that you have 2 non-voided orders in your history, with the first stopping 1s prior to the second.

I assumed this was the way the API was supposed to work, but I’d be very interested to hear if it isn’t, as that would make it much easier to support these retrospective use cases. eg:

Editing = issuing a ‘REVISE’, which voids the old order and creates a new order with action = ‘REVISE’, and sets it’s previousOrder to the voided order

Changing = issuing a ‘DISCONTINUE’ of the existing order, followed by a ‘NEW’ of the new Order

Or is that not what you meant @burke?

(Incidentally, where the current API causes problems with setting dateStopped on the previous order is where the dateActivated of the revised Order is the same as the dateActivated of the previous Order, because this leads the previousOrder to have dateStopped < dateActivated by 1 second).

Mike