I think adding additional “fulfiller” attributes to the overall Order model kind of fights what the order was doing (basically an immutable record of a request to perform some clinical action or authorization to give a patient some medication). It turns the Order into a dual-use record and makes it a lot fuzzier to reason about.
In FHIR, these updates, etc. aren’t modeled as information stored on the order record, but as part of a Task associated with the order something that Bahmni seems to be moving towards too. I’d favour spinning out the fulfillment attributes from the order into a separate table order_fulfillment or something like that can store the fulfiller information, link to encounters, etc. and keep the data model relatively clean.
I do agree it makes sense to be able to tie orders to encounters that fulfill those orders, especially as with surgical procedures or imaging workflows we likely do have data that makes sense to record as part of the clinical record.
PS Sorry for slightly hijacking this, but I am concerned that we’ve moved the fulfiller model beyond just a couple of things tacked onto an order and it really makes sense to think of this as a somewhat separate domain.
@jayasanka I’d appreciate your thoughts on how this could be made to work with the recent Procedures work.