I'm here with another long shot question about an issue that no one seems to have seen or know how to solve. I am so tired of our uniqueness.
We have identified ~5 patients who freeze Centricity whenever anyone tries to electronically renew their prescriptions or print a prescription. This happens only with these specific patients, regardless of the user or the computer/term server.
Has anyone experienced this? We can't find a single common thread to tie them all together.
Here's what we've found:
- we thought it was only patients with red interactions, but then 1 of 5 had a yellow
- then we thought it was patients with huge charts, but we removed all the problems and medications from one and it still crashed.
- we also loaded up a test patient with 20 problems and 20 medications, but they didn't freeze
- the freeze never causes an actual crash, so it never throws an error nor log an error in any error log
- the server log does display this error a few times: [UserInformationBO] MRU Patient list order is broken. PatientProfileId [328378] not in the MruPatientList.PreviousPatientProfileId for this user [1866386733609140], but the PID that displays isn't always a patient that causes the freeze
When we first upgraded to 12.2, we did have a problem where patients with abnormally large charts would freeze the system if the user tried to access them right at startup. It was a race condition issue, where two commands would be fired simultaneously, but certain charts would take so long to load that the second command would get ahead of the first and CPS wouldn't know what to do.
This feels like that, but at least there we had a workaround (open a light chart first, then go to the heavy one). This time, we just can't prescribe medications for a handful of patients, which is real bad.
Any thoughts, advice, or assistance is, as always, more than welcome. Thanks in advance!
Check in registration to see if any of those patients are marked as "sensitive". We had the same problem and the work around was to remove the sensitive toggle. This is not an issue in later versions of CPS.
That's good thinking, but none of them are, unfortunately.
What version of CPS are you on?
That does not ring any bells to me. Are you on 12.3.3? Have you tried different methods of prescribing, such as adding a med from new medication, using the change medication option in the update medication window, adding a medication with prescription via MEL? Is it all the same result?
I would also check SQL Server Management Studio the activity monitor for the server and see if there are any waiting tasks while the session is frozen.
Also do you know if the process is using any CPU wherever the client is running, or is 0%, and lastly, does it ever clear or timeout and come back to life, have you waited 30 seconds, 5 minutes, 30 minutes?
The other thing I would look at is the eRx Eligibility. We have had problems in the past where issues with that cause prescriptions for patients with the same PBM to all not all prescribing. See if there is any commonality there.
We are on 12.2.2. We did let it hang for maybe four minutes, but no longer than that.
We found a resolution, although it's not one I'm entirely happy with. We restarted the JBOSS server after hours last night, and that resolved the issue. We can now refill meds in every one of the reported charts.
So! If any of you encounter this, restart your server (not service, although that may have been a better place to start).
I had a similar issue with a few physician teams after we upgraded to 12.2, it was being caused by Rx renewals in Chart->Rx Renewals->Search the provider in the top left for pending renewals - once xyz patient had enough pending renewals in there it would break their chart.
Below is the fix if this is your issue:
select * from patientprofile where patientid='xxxx' -- get patient ID from registration
select * from ERXRefillRequest where PID=xxxxxxxxx -- fill in PID from SQL query above
begin tran
delete from ERXRefillRequest
where PID=xxxxxxxxxxx-- copy from above
commit
Hope this helps
Thank you! We ended up restarting our entire environment late one night and that fixed our issue, but it's nice to have a lead into an actual cause and solution other than "turn it off and turn it back on again".
I've taken that SQL script and put it into our knowledgebase for future reference. Considering I haven't seen this problem in the two years we've been on 12.2, we may not see it for two more years, but I've documented it anyway.
Thanks again!