Welcome to the NEW CHUG— your ultimate destination for cutting-edge insights and discussions at the intersection of healthcare and technology.

Our platform is dedicated to exploring the dynamic landscape of healthcare technology, empowering professionals, enthusiasts, and innovators alike with the knowledge and resources to navigate the rapidly evolving field.

From telemedicine revolutionizing patient care to the transformative potential of artificial intelligence in diagnostics, we delve into a myriad of topics shaping the future of healthcare delivery. Whether you’re a seasoned healthcare IT professional, an aspiring entrepreneur in the digital health space, or simply curious about the latest innovations, our curated content, expert interviews, and thought-provoking articles provide a comprehensive exploration of healthcare technology’s most pressing issues.

Join us as we navigate the forefront of innovation, driving forward the transformation of healthcare for a healthier, more connected world.

Have questions or suggestions? Please use the contact button below.

Notifications

Clear all

CPS hangs any time prescription is renewed or printed

Bugs, Known Issues, Open Cases

Last Post by Anonymous 1 second ago

8 Posts

4 Users

0 Reactions

81 Views

RSS

vrdlc

(@vrdlc)

Posts: 135

Estimable Member

Topic starter

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!

Posted : December 10, 2019 10:34 am

koby.bolton

(@koby-bolton)

Posts: 3

New Member

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.

Posted : December 10, 2019 11:00 am

vrdlc

(@vrdlc)

Posts: 135

Estimable Member

Topic starter

That's good thinking, but none of them are, unfortunately.

What version of CPS are you on?

Posted : December 10, 2019 11:31 am

gibsonmi

(@gibsonmi)

Posts: 827

Prominent Member

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?

Posted : December 11, 2019 12:57 am

gibsonmi

(@gibsonmi)

Posts: 827

Prominent Member

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.

Posted : December 11, 2019 1:45 am

vrdlc

(@vrdlc)

Posts: 135

Estimable Member

Topic starter

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).

Posted : December 11, 2019 3:21 am

mfretwell

(@mfretwell)

Posts: 14

Eminent Member

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

Posted : December 13, 2019 11:00 am

vrdlc

(@vrdlc)

Posts: 135

Estimable Member

Topic starter

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!

Posted : December 16, 2019 4:09 am

24 Forums
9,940 Topics
39.9 K Posts
1 Online
6,470 Members

Forum Icons: Forum contains no unread posts Forum contains unread posts

Topic Icons: Not Replied Replied Active Hot Sticky Unapproved Solved Private Closed