Demographics are updating to wrong patient

Updated to 6.0 and 6 different patients have had there fname, lname, dob update in demographics if the user had more than 1 window open. It happened a few times before the update but I blamed it on user error, assuming the user updated demographics to match whoever was coming up in the top window if different from the bottom but I noticed a pattern today.

Of course the users all said they did not update demographics and because it has happened so many times in the last 2 days, I am starting to wonder if it is a glitch. Has anyone had fields in the demographics change if the user had more than one window open with different patients?

Just got clarification that they are logging into the database on 2 different tabs 2 different times.

hi @tjbarr, patch 2 should help with this if you haven’t applied it yet.

Thanks, I applied the patch last evening.

1 Like

This is still occurring. I am going to apply patch 3 tonight. Any idea if it will help?

Help! I applied the patch 3 for 6.0 and I still have clients getting updated. It appears to happen when a provider moves directly from 1 client to the next and possibly leaves a tab open.

@stephenwaite @brady.miller @sjpadgett

I can’t re-create. I don’t get how demographics get changed across patients unless someone does a change/save.

Meanwhile if provider want to log in twice or more I’d try using a different browser other than the current logged in browser. E.g. FF for one log in and Chrome for the other. Otherwise you’ll need to try and pin down a scenario I can replicate the problem i.e. a ABC work flow for me to test.:slight_smile:

1 Like

only thing can think of is the weekend, i mean clearing the cache for the affected users

1 Like

The provider only logs on once as far as I know. You can get a situation where the top has one client and the bottom has another one on the main page.

Then what’s this about? And as @stephenwaite suggested, clear browser cache especially after a patch or upgrade.

This issue has been in OpenEMR for quite some time (I remember it in the 5.0 release). It is still there, and I have worked around it by going to faster instances that have a faster patient chart switch time (like t2.large for example - hopefully, t3.large will be enabled soon).

The problem is not one that developers would typically see on a test. It requires a system that is loaded with normal use (several users).

The issue is that some of the information (like the buttons for the encounter, etc.) will stay “connected” to the previously viewed patient chart when the patient is changed. The webserver will update the current chart and then the encounter, demographics, and other connections will update.

Between the time that the patient chart is changed to a new user and these other connected pieces of the chart switch to the new patient, if the user tries to edit something, they will be working in a different patient than what OpenEMR screen is showing them (the patient name and the patient that is pulled up when the user chooses demographics etc. will not be the same). I remember getting burned by this many times when I was using slower web server instances.

The problem gets even worse if you try to have multiple patients open with the same browser (stick to one patient per browser - open a different web browser to view a different patient) - with multiple patient charts on the same browser, the OpenEMR system can get into a state where the demographics, encounters, etc. are attached to a previous patient and never update at all (requires logout and login).

1 Like

This boils down to a session issue. Each new window you open creates a new session cookie. The browser switches to use session when window comes into view. Each session hold the pid that is used for save and fetches etc. Somehow these sessions may be getting crossed. Hard to catch and it may be tied to what the user is doing when this happens.

If anyone wants to track the sessions use your browsers console tools. For FF:

1 Like

Yes exactly! I have instructed the users to only open 1 client at a time.

1 Like

They can open other patients safely as long as they use a DIFFERENT BROWSER (e.g. Firefox for one patient and Chrome for another patient). Sometimes a provider will get interrupted while documenting on one patient, and it is a pain/wastes time to have to completely switch out of that session to answer a question about a different patient. By opening another browser, it avoids the session confusion issue entirely.

Another problem is that if the provider uses the calendar (and probably the flow-board as well, I cannot remember right now) to pull up and patient chart, OpenEMR will open a second patient within the same browser. This is just the way the system works. You have to manually close the previous patient.

I will take a look at the session cookies if I happen to encounter this problem.