Tried to find documents/wikis for my question but couldn’t get anything useful.
My question is - how does OpenEMR handles Record Locking? For example, If an existing user opens a patient’s demographic forms and enter information for this patient, it seems like the system doesn’t prevent another user from opening the same patient’s demographic forms and enter similar fields. This may/may not result in a conflict final result of the patient’s correct demographic information filed in the database.
Another example (may be more realistic) is that there might be multiple users working on the billing side and try to type in patient payment. If two of them are working on the same patient at the same time, this might be resulting in duplicate payment recorded in the system (but actually the patient may only pay once).
Any thoughts on how the system was designed to handle these scenarios?
In the first example, there is usually a one-to-one exchange between the patient and the receptionist at the point of check-in. There is no reason for multiple receptionists to enter data while that patient is standing in line. If the patient had previously entered the demographics through the patient portal, he certainly would know enough to inform the receptionist, should he be asked to fill out the patient information form once again. The same holds true for check-out.
In the second example, most medical practices are competent enough to establish division of labor early in the life of the practice. Small offices typically have just one person responsible for billing. Duplication of data entry is not expected in those cases. If there are multiple persons doing the billing, the work is divided. For example, one person does the claims, another the receipts and a third handles rejections. The office manager should have delegated the individual duties from day one.
Before EHR’s, efficient workflow existed when only pen and paper were available. If the workflow is chaotic to begin with, there is no amount of software refinement that will remedy the situation.
So the short answer is that the EHR should be a tool, not a nanny.
It is a legit problem. To make matters worse, since the system does not use objects but executes direct SQL updates, there are no easy fixes.
Demographic or billing are secondary functions but even in small offices single md and single clinician can pull up and update same or different sections of a SOAP/progress note and current setup will let the last update prevail. Depending on the type of information ‘lost’, this can be hazardous to everyone’s health - financial and physical.
One of the simpler helper feature we have considered is to provide a visual cue when either an encounter or a patient becomes ‘active’ - $pid or $encounter is set/changed - check a site-wide token and change background of top section. But it keeps getting pushed back in favor of new functions.
Rod did something towards this as I can remember. Hopefully he can weigh in where he did this in the codebase (I forgot). As I recall, his code was very form specific, but am guessing could be leveraged for other parts of the codebase.
Brady, thanks for the reminder that I need to commit this. I just did so.
What I did was design a type of MySQL query that will quickly generate a numeric hash of part of a table. This hash is put into the form as a hidden field. When the form is saved, the hash is recomputed and compared with what was there before. If they are not the same, the save is rejected with an error message.
That’s the general approach. The above-mentioned commit implements it for the Fee Sheet. Here it is:
Thanks folks - so it appears that MD support’s proposal is more generic but required more effort than Rod’s specific implementation to individual forms.