Notifications
Clear all
Topic starter
This just started happening this past week. Two of our providers go to their own desktops and click on the documents section. Everything loads fine, but when they double click on the document to get redirected into the chart, it locks up and freeze all of CPS. It is only with their logins... cause I can login as myself, go to their documents in the document view and double click on it works fine. I tried restarting the Database server / JBoss / individual PC and nothing. And it is not limited to their own PC either, i tried on several others and same thing... it has something to do with their logins. The weird thing is, the week before their the meds were disappearing from their charts and had to reboot CPS for it to function properly again. Not sure if it is has anything to do with it or not... has anyone else had this issue?
Posted : December 3, 2012 12:52 am
Topic starter
Oh, forgot to add--- I have been on hold for GE support for over 1 hour to try to resolve this...
Posted : December 3, 2012 12:53 am
We've had quirky user issues somewhat like this, the most common is a system error when opening a chart after a user changes their network password (we use Active Directory).
What fixes user specific errors and issues like these on our end, is from Centricity > Administration >System > User Management, remove the user's security groups, save, and then re-add the same groups. Than have the user log out of everything and back in.
Posted : December 4, 2012 3:10 am
Topic starter
We fixed the issue, it is a glitch within SP3. I found out that running this script with the users PVID fixes it. But it is only a temp fix cause it could happen again.
DELETE FROM UI_LAYOUT
WHERE PVID IS NOT NULL AND PVID = 'INPUT USERS PVID HERE'
you can get the PVID from the users like this:
SELECT PVID
FROM USR
WHERE LOGINNAME = 'INPUT USERS LOGIN NAME HERE'
Posted : December 4, 2012 3:18 am
We have been experiencing this issue as well. It's not new since SP3, but it hasn't gotten any better either. The solution mentioned by acantu works, but does not seem to be permanent.
Has anyone had any success determining WHY this happens either on their own or with GE? I'd rather not be executing manual deletes on the SQL database a few times a week to mask a problem. It would be better if we could identify the root cause and fix it.
I have a hunch that this ui_layout table is storing window sizes/positions, but it's doing it on a per user basis and not a per client (thick or thin) basis so if a user goes from a 20 inch monitor to a tablet, the stored window position might not be available since the resolution is so much less. Remembering windows size/position would be nice - if it worked. But when you have users roaming between different devices as we do, I'd rather if it just started maximized or in some default window size/position that would work in any situation.
-Matt
Posted : December 19, 2012 11:45 pm
Topic starter
mdoak said:
We have been experiencing this issue as well. It's not new since SP3, but it hasn't gotten any better either. The solution mentioned by acantu works, but does not seem to be permanent.
Has anyone had any success determining WHY this happens either on their own or with GE? I'd rather not be executing manual deletes on the SQL database a few times a week to mask a problem. It would be better if we could identify the root cause and fix it.
I have a hunch that this ui_layout table is storing window sizes/positions, but it's doing it on a per user basis and not a per client (thick or thin) basis so if a user goes from a 20 inch monitor to a tablet, the stored window position might not be available since the resolution is so much less. Remembering windows size/position would be nice - if it worked. But when you have users roaming between different devices as we do, I'd rather if it just started maximized or in some default window size/position that would work in any situation.
-Matt
Hi Matt,
Yes, that table stores windows size on a per user basis. Besides using this script, currently there is no other way of fixing it unless you can get GE's source code because that is where the problem is. The purpose of the table is meaningless as all they have to do is store it in the application itself. There is no way of resizing the portions of the screen to stay a certain way. If you have studied the way CPS communicates to the database and the codes they used, you will be wondering why they do a lot of stuff... and i do mean a lot of stuff that just doesn't make sense. And you will see why there is always issues a performance lag. Not very good coding.
Posted : December 20, 2012 12:44 am
I would be interested in what code acantu is able to look at. I am particularly interesting in their code for clinical list functionality since we have noticed buggy behavior when running traces.
One example: in one trace I noticed that the ORDERS_NEW() call returned an 8000+ character string, which included orders done in the patient's chart that were not entered in the current update but instead were entered in other notes done by other users. In fact the user whose note was having the problem had not done any orders at all yet.
Another example and even more serious one: the problem list in CPS 10's Chart Summary view does not list a problem as active if in CPS 9 the ICD code wasn't changed but the problem description did. One scenario for this is a patient was first be diagnosed with HIV INFECTION (ICD 042). Then in a later note the problem was changed to HIV DISEASE (ICD 042) and then in a later note the problem is changed to AIDS (ICD 042). We have been told by GE this is fixed in 10 SP3 (we are currently on 10 SP2). Until we upgrade we have told users to use the Update Problems view (accessible by the Organize button) to review the problem list because it is displayed there correctly.
Posted : December 20, 2012 11:40 pm
Topic starter
Good Morning JNordberg,
The code i refer to is not really code, but how and what the application is doing with the database. This is pretty simple to do, if you have access to your sql server, you can run SQL Server Profiler and select your CPS database... and you can see all the craziness that goes on and how it communicates with the server. You will be mind-blown to see how many times process run. I created a test database and only I have access to and have done this. And to see how many times the same script is run and the way it is done, will make you realize that these people really do not know what they are doing. It looks like they care more about the look, than performance and functionality. I, myself, as a programmer, like to make my apps look good, but i care more about how it works and allow it to work in ways that all users can actually use it.
Posted : December 21, 2012 12:05 am
I know exactly what you mean. I am by no means a SQL programming expert, but we did identify something just like what you are talking about on the PM side of CPS 10, reported it to GE, and actually got them to address it in a service pack (after several months). At the time, we had one site rolled out on EMR with potential for three more so we sort of used that as leverage and told them we'd go with another product unless they addressed the issue.
We used to be able to run CPO 2004 (and before that, Millbrook) in a fat client WAN environment with only 1.5mbps in between sites, but performance took a huge dump when we upgraded to CPS 10. We've since gone to thin client environment at our EMR sites, but that presents a whole seperate set of challenges (half assed printer preference tracking in CPS, difficulty with cameras, scanning, etc).
Basically, when opening a patient's profile (demographic screen), the app was querying for the ENTIRE doctorfacility table and the entire thing was being returned over the network. In our case since we have many thousands of referring doctors, this was several megabytes transmitting needlessly over the network. Only a couple of rows were actually needed - the ones that pertained to that patient - his doctor, PCP, and referring doc, but GE was returning several thousand rows of data (about 10 megabytes in our case).
I have no doubt there are countless other examples of this kind of thing throughout the application. We've been dealing with random SEH errors on the PM side for 7 years now that are always supposed to get better with each service pack, but they never do. They always want to blame it on the network (even when the errors still happen on a LAN) or have us throw more hardware at the problem, but the truth is, it won't make a difference. We're on our third hardware iteration since I started and it's the same thing still. They need to pay more attention to quality control.
My hope is that since they are discontinuing the Oracle version and moving forward only with SQL, that they will start to address some of these quality issues. If they don't, they might lose those Oracle customers. From Oracle customers that I've spoken to, they seem relatively okay with the reliability/stability of the product. The CPS people seem to be the opposite. Constantly working around problems, rebooting servers, etc to keep things running.
-Matt
Posted : December 21, 2012 12:34 am
Topic starter
Yes Matt,
There is tons more... the worst one so far is loading the desktop view... in the charts... it is crazy. But yes, the surely do not know how to use a database accurately... this is why CPS runs so slow. And using it via web based technology, makes it even worse. They really jumped the gun and feel they need to go back to the drawing board and get some real database and programmers that understand this stuff to build something that actually functions the way it should.
Posted : December 21, 2012 12:40 am
Thanks acantu and Matt for your helpful information
Posted : December 21, 2012 12:51 am
I know when we "upgraded" to CPS 10, my code in the patient banner had to be adjusted to account for the fact that the patient banner runs THREE times on EACH chart load when it only ran once in 9.5. I haven't figured out why it's triggered multiple times and haven't had the time to look either.
Posted : December 21, 2012 1:25 am
