OpenMRS’ patient merge functionality does not allow merging patient records with orders. So in case the patient has medications orders on both the records, system does not allow merging of both the records. Even if the drug order is stopped, the records are not allowed to be merged. In Bahmni, we are looking to leverage the merge functionality for one of our implementations. Our question is that shall we allow merging of records if the order is discontinued or only allow if the order is voided.
My recollection (and my memory could be wrong) is that @burke felt strongly it was important not to allow the merging of two records that have active orders, because this could lead to actions being taken that would directly harm the patient (carrying out two orders written without seeing each other).
I would assume we should allow patient records to be merged if only one of them has orders that are currently active. (I.e. to your exact question, discontinued is enough, we don’t need to require voiding.) But I’d like to hear @burke’s opinion on this.
Further, I think it would also be okay to introduce a new API method to allow merging even if two records both have active orders, as long as the caller of the method passes along info to show that “yes I am aware of these active orders and I want to merge anyway.”
What is the preferred user experience from the Bahmni client side in this case?
I agree that we should allow merge if one of the records has active orders but the other record should have discontinued/voided orders. Would like to hear @burke’s opinion on this.
One more question we had, how do we handle the bed management part (it is not a part of OpenMRS but a Bahmni entity)? I was thinking that we should allow merge if one of the records is assigned a bed but the other one should not have a bed assigned (or is discharged). Please pour in your opinions.
@akhilmalhotra do you think it will be helpful for @jthomas to schedule a design call for this?
1 Like
@akhilmalhotra, broadly the approach should be that “historical observations” can be merged (because anything recorded should be true for both records) but that things that indicate a current/future action cannot be blindly merged.
I agree with you in this case that if you have two records both of which are assigned to beds, you should alert the user of this (and prevent merging until they’ve dealt with this).
Do you know what merging code is being used behind the scenes? I.e. are you using the emrapi version of merging that allows for custom PatientMergeActions? Ideally while devs are touching this code they can incorporate this extensible feature into the merging code in openmrs-core.
1 Like
@jthomas when is the earliest that we can have a slot for design call?
@darius we are using the OpenMRS patient merging module. We have not done any development on it yet.
1 Like
@akhilmalhotra Monday’s design forum time is open (January 9th @4-5pm UTC. Would this work for you? Who all needs to be in attendance?
@jthomas It works for us. I would request @darius, @burke, @jteich to join. @darius Please invite if you think someone else should also be present.
1 Like
Hi @darius , Current Patient Merge module of OpenMRS (legacy UI) is using PatientService.MergePatients API. Hence we are not in a position to use PatientMergeActions currently.
1 Like
Discussed on 2017-01-09 Design Forum.
- As long as only one patient has active orders, then merging is fine.
…and this can be treated as a bugfix and addressed in the next platform 2.0.x maintenance release.
As of now, except the medication orders (which have an expiry date), all other order types remain active even if the order has been fulfilled/completed (the results for lab tests are recorded or the radiology image has been attached to the order). We can’t figure out if the order is still active or has been completed. So in many cases, this would cause conflicts and not allow the merge.
In the orders table, there is an “order_action” column which records “New, Discontinued and Revised” as status. Should we include a new status “Completed” if the order has results (lab orders) or image (radiology orders) attached to it?
Please suggest on how should we proceed.
We always say that the order entry API in OpenMRS only handles placement, revision and discontinuation of orders, it doesn’t address dispensing, inventory and fulfillment, if you wish to implement any of these, you need to do it in a custom module.
This was discussed on the design call on Jan 11th, you can find the notes here, we will be adding ways to have orders marked as expired as a work around in the short run and in the long run we can introduce statuses based on FHIR statuses that would allow one to mark an order as complete.
Specifically for @akhilmalhotra and @karrtikiyer to take back to the Bahmni team…
- We recommend that Bahmni should be setting an autoExpireDate on lab orders so they don’t appear to be open forever. Is this feasible, e.g. to set something like 1 week?
- It’s okay for you to change the merging behavior to be more permissive, and to do this as part of the next platform maintenance release. Specifically:
- patient records that both have active DrugOrders cannot be merged (same as existing behavior)
- for other order types, you cannot merge patient records if both have active orders for the same concept
- in other cases, it’s okay to merge patient records even if they both have active orders
- You need to create a ticket for the above (and work on it)
- I created a placeholder ticket about adding Order.status (not a priority, as far as I know): TRUNK-5011
- Once you’ve created a ticket for the above, let me know and I will create a placeholder ticket about making patient merge behavior configurable for each order type (not a priority, as far as I know)
This is a good idea and will help us with the older data also but I suggest that along with setting an auto-expire date, we also should update the order expiry date to be immediate as soon as the order is fulfilled (whichever happens first) so that the order expires immediately when the results arrive. This will avoid complications in terms of having to wait for a week to merge two records in case both of them have completed orders but the auto-expiry date is still a few days away.
As of now, we are considering order type for allowing/disallowing merge (if one patient record has an active lab order, the other patient record should not have an active lab order). Reason: When we order Panels, we do not specify what individual tests are ordered under that panel. So if one patient record has been ordered a panel and the other patient patient record has been ordered a test which is also a part of the panel ordered for the other patient, we have no way to figure out the conflict in this case. So it would be safer to resolve such conflicts manually.
Also, thinking purely from the functional perspective, it is unlikely in a hospital that two duplicate patient records are actively being used at the same time. This can happen in case of emergency visit though that the doctors did not bother to search for the patient and created a new record but this does not happen that frequently. So I think drilling down to checking at the concept level will be making the logic a bit too complicated unnecessarily.
1 Like
I don’t think this works because the underlying API would treat changing the autoexpiredate as a new revised order, and we won’t want this.
The correct fix for this is to introduce a status (TRUNK-5011). The workaround until we’ve done this is to give a good error message when trying to merge the patients, so that in this rare scenario the user knows to manually close the order in one record.
We were also thinking this on the design call, so we thought it makes sense to just be quite permissive of merging records with non-drug orders.
It’s going to be a very rare circumstance where this happen, i.e. two records actively being used for one patient, and one gets a panel ordered and the other gets an individual test ordered. And the patient harm of inadvertently doing a CBC and also a Hematocrit is negligible. So I would prefer to make the code more permissive and only prevent merging when both records have active orders for the exact same concept (for non-drug orders).
But if you prefer to be less permissive, and force a user to do manual reconciliation if both records have active lab orders, that’s fine too. Either way, you have a green light to loosen the restrictions on patient merges as discussed here, and to treat this as a bugfix that can be backported to maintenance releases.
1 Like
Just to confirm, does everybody agree that we should allow merging patients with orders of the same concept as long as they are not drug orders?
1 Like
@wyclif could you clarify/expand this comment?
Particularly, what is being proposed that is different from what I mentioned in this previous comment?
1 Like
@darius, For now, we want to be less permissive as discussed below.
The implementation for which we are rolling out this functionality wants to do a manual reconciliation if both records have active lab/radiology orders.
1 Like