At PIH, we have some existing laboratory functionality in lieu of a separate lab information system, in which we support the ability for staff at the laboratory to:
“Receive” patients who have pending lab orders, and record a “specimen collection” encounter that is associated with one or more of these orders.
At the same time, or at some later point in time, record results for each test as it is performed
Optionally perform patient or order-level operations (notify patient that results are ready, print out summary of all test results, etc)
In order for this system to function, it has to be able to associate a “fulfiller encounter” with each order that the encounter fulfills. This allows each order to be associated together and for us to link the specimen collection encounter with the orders that it is based on, prior to any actual result observations being available.
For years, we have done this by creating observations at the time this encounter is created that contain each “order number” in the obs value text, as well as directly linking back to the order via the “order_id” property on the obs.
This works, but it contributes to the bloat of our Obs table, while also not really storing a true patient observation, but just using the fact that Obs contains the necessary foreign keys to achieve this association.
Given that FHIR has a basedOn property on Encounter that can point to (among other things) 0-N ServiceRequest references ( Encounter - FHIR v5.0.0 ), I am wondering if a model where we add a fulfillerEncounterId property to Order would be a reasonable evolution of the core data model to support this requirement in the future without requiring this less ideal obs-style linkage. This would fit in somewhat nicely alongside the existing fulfillerStatus and fulfillerComment columns on Order.
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.
Interested in what others think, but I’d be fine with adding or fulfillerEncounterId (and potentially @ibacher 's approach pulling everything out into a separate order_fulfillment table).
I’m not opposed to this at all, but figured it would be more straightforward and consistent with the existing code to add one more additional nullable property to encounter than to have to create an entirely new table, especially because to create the clean data model you envision, we should really migrate the existing fulfillerStatus and fulfillerComment fields from encounter into this, which has a lot of backwards-compatibility implications that I don’t really want to immediately contend with if we can avoid it.