Notifications
Clear all
Sorry for the late reply, but yes we found this issue too.
We identified the PRINTHANDOUT issue in the previous 12.3 release candidate and there is still a problem with the final GA version in test. The only thing that changed is that in the prior release there was a crash to desktop event and in the GA version it just hangs the chart module indefinitely.
Hopefully the issue can be resolved within Windows or print queue configuration, but we haven't had a chance to try to isolate and develop a fix/workaround yet.
Posted : January 15, 2018 4:58 am
We upgrade from 12.0 t0 12.3 on earlier this month. Overall went well. We are still having a couple of issue in the Billing module. Collection Status does not stick when entered, font change, List of Supervising providers, missing J codes, insurance company address isn't visible unless you hover over the field.
We are also having an issue with Service Provider (External) when Changing an order. The box is grayed out.
Out biggest issue right now is freezing and crashing in Registration when taking a patient picture. Are there any CPS 12.3 customers experiencing this?
Thank you for any assistance,
Jill
Posted : January 17, 2018 9:19 am
Jill we are having some of the same issues. Collection Status does not stick when entered, font change, insurance company address isn't visible unless you hover over the field. We also have an issue with submitting claims when lots of users are on the system. It just freezes during the Error Check most of the time.
We are also having an issue with Service Provider (External) when Changing an order. The box is grayed out.
Fix - If you click the Create Transition of Care Document first, you should be able to change to External. You can unlick TOC after your finished if you want to.
Posted : January 22, 2018 4:13 am
Upgraded from CPS 12.0 to 12.3.
A number of users with freezing/crashing problems, mostly billing, but not entirely.
So far the efforts at troubleshooting the problem feel a lot more like guesswork, shots in the dark, and I'm jumping through hoops. Have not found a cause quite yet, but still working on it.
Posted : February 1, 2018 8:56 am
Welcome to the club, getting a GE representative on the phone for at least cataloging the issue it has proven to be a titanic task.
Ill provably will come to the end of my time before I can get some GE representative on the line.
Posted : February 6, 2018 7:04 am
Billing people clicking on lots of entries repeatedly can crash the system predictably. Every entry opened consumes another ~4MB RAM. This increases total memory used by the process until between 550 and 700MB, when it crashes or freezes and then crashes. Happens with any version of Windows, 7-10, every time. Even if you open the same billing record repeatedly. RAM is not released even if you close the billing module, or even if you log out, until you fully close the application.
I tracked this down and gave it to our vendor, who then installed a version of the software on a test machine with the debugging turned all the way up, and he collected some additional crash data when I reproduced the crash. Supposedly that will go to GE. It can't get much easier for them to fix this.
I would really rather our vendor did that testing in their own lab, though, considering I already found the problem and told them how to reproduce it. We shall see if this leads anywhere.
Also the original EXE does not have the Large_Address_Aware flag set. If the application is working properly, it should generally run 200-300MB, so that is probably not a problem. But our vendor told me that the software specs call for 3.2GB RAM, so I thought I would mention it.
Posted : February 6, 2018 7:15 am
Just got off the phone with GE Centricity personnel and there seems to be a patch for the freezing issue..
i will install in my test environment and verify if it work for the printhandout issue.
Posted : February 6, 2018 7:29 am
For everyone that is having the printhandout() freeze or crash (or possibly other stability issues), GE came out with a fix for this on March 5, I just found out yesterday after having a case open for many months. It doesn't appear to be available on the support portal anywhere, but the latest version is now 12.3.0.2838. Here is a link
https://data.gehealthcare.com/fs/v.aspx?v=8c6a6a89586471b66ea9
I tested the handout issues in our test database and they seem to be resolved. There are other stability fixes mentioned but I can't speak to whether or how those were addressed.
Posted : April 12, 2018 4:08 am
Was this applied in your production environment as well? Just curious if you noticed any new potential problems once you went live. Thanks.
Posted : April 12, 2018 5:11 am
No in production we are still 12.2.2, with this fix in place though we are going to move forward with the upgrade, unless someone finds something else catastrophic. It will probably be at least 4-5 weeks before we schedule it, but after the upgrade I can report back.
Posted : April 12, 2018 5:52 am
We upgraded to 12.3 last weekend. Is anyone else seeing extreme slowness with LinkLogic processing Lab results? We get thousands of labs/day (almost 200 providers) and our LinkLogic queue used to be processed very rapidly, hardly ever a backup. Now there's always files waiting. And when I resolve errors I often sit and wait and wait and wait for it to process the result (gets "stuck" on Phase 3 for up to 45 seconds on some Labs). Documents still process VERY rapidly. Just Labs seem to be having an issue
Posted : May 9, 2018 2:33 am
Might not have anything to do with your LinkLogic problem, but how big is the cross reference file on your Lab Results task? Is the slowness on all of the different Lab Results tasks or just one? Have you looked at the Activity Log to see if there are any errors? Particularly related to the cross reference file. Just a wild guess. I ask this because the cross reference file is the biggest difference between a Document import and a Lab Results import (other than writing to the obs table).
Posted : May 9, 2018 4:58 am
The slowness is much more pronounced on our LabCorp interface than our Cerner interface, but both are slow processing files. The XREF files are comparable size 8 & 7k respectively. I did look at the Activity Log and there's warnings for the usual items: can't auto-complete orders (neither interface is bi-directional) and some values we don't map to OBS terms. Nothing unusual since the upgrade though. We've had these interfaces and XREF files in place for years and I've never seen them run this slowly
Posted : May 9, 2018 6:04 am
You might try running a SQL trace when you are manually resolving a lab reports error. Could be some info there. If you have opened a case with GE you might send that to them too. Could compare it when running a document error too.
Posted : May 9, 2018 7:22 am
Page 2 / 2
Prev
