@burke, following on from TRUNK-4702:
Then why are we avoiding concurrent duplicates in the API? If any orders, including concurrent duplicates for the same meds, can be stored, then all clients must deal with the ambiguity anyway and the validation in the API serves no purpose – i.e., essentially there are no business rules and all clients must deal with whatever comes (hopefully safely).
The genesis of this is:
- @burke feels strongly that for patient safety reasons (e.g. to avoid accidentally ending up with overlapping/duplicate active orders that lead to an overdose) that you shouldn’t be able to prescribe Drug X while the patient already has an active order for Drug X.
- this is what is currently implemented
- @jteich feels strongly that there are circumstances where two overlapping drug orders for Drug X is correct and necessary
- therefore on the April 29 design forum we compromised on the idea that we allow this, but make it hard to to do. From the notes: “In the API: the caller needs to acknowledge the overlapping orders you are aware of in order to make another overlapping order” (and you created TRUNK-4702)
The reason for settingup the API to discourage “concurrent duplicates” (I disagree with “duplicate”) is because you’ve said it’s an important patient safety issue, and we shouldn’t allow someone to place an order for Drug X unless they are explicitly aware that there’s already another order for Drug X and they knowingly decide to do it. It’s not a business rule that there’s always only one order at a time for a given drug, and client’s shouldn’t assume that.
Am I missing the point of the question?