One thing I found surprising was that accession number was not whitelisted as one of the mutable properties of an order, so I added it… from previous discussion it seems clear that accession number is meant to be fulfilled by a downstream system, and therefore would need to be mutable:
Sorry to comment on this old conversation. I am currently working on the esm-laboratory by the Uganda team and I wanted to ask if it would be a good idea to update fulfillerDetails to also include specimenSource for lab orders. This is specifically necessary since the property is updatable by the fulfiller when receiving an order.
Thanks for the response, @mogoodrich. My proposal is based on a practice/workflow where specimen source is documented by a lab person after an order is made. A clinician will most probably request for a viral load/malaria test without specifying from which source. Another example is with covid where a clinician orders for a COVID test without specifying the specimen source. The specimen source then becomes an update when fulfilling/acting on an order and not during the time of ordering by a clinician. Which workflow do you support in your facilities?
I’m inclined to say that this is probably a bad idea. The purpose of an order is to communicate between the clinician ordering a procedure, test, drug, etc. and the person fulfilling that order. In general, we do not allow fields on orders to be updated. This is because an order can be an authorization to perform a particular service and, from a legal perspective, it is important to preserve that authorization in the form it was given.
Moreover, allowing the lab to update the specimenSource is inconsistent with the reason that certain fields on an order are updated, specifically, those fields we allow to be updated are those which represent a communication between the order fulfiller and the ordering physician, e.g., things like “We cannot process this order because we need X, Y, or Z” or “This test will take longer than usual because our COVID-19 testing equipment is not functioning and we had to send it off-site”. Things like that.
What I would suggest doing here instead is to introduce a new domain through a backend module that can handle this; maybe something similar to the FHIR Specimen resource (which allows linking specimen’s to the order they relate to). That way the lab frontend can happily add a new specimen linked to an order without needing to update the order in any way.
Basically, the order domain is not intended as a domain for tracking the work done in response to the order; it simply represents a request or authorization. This is similar to how we handled things with the dispensing module; medication dispenses happen in response to valid drug order, but the dispense domain itself (which is what the pharmacy module mainly uses) is detached from the orders.
Thanks, @ibacher. This is comprehensive and am well guided. It makes sense to introduce a new domain for order specimen. What do you think about order attributes? What kind of information can they be used for?
Mostly the same kind of information I described, just things that for whatever reason we don’t have on the order core. One possibility, though, could be to use an attribute to tie to some kind of “fulfiller state tracking”, if that’s appropriate.
