I have a provider complaining about the slowness of documenting in one of his patient’s chart. The patient chart is very large, has a lot of visits, large list of active medications and problems, large number of test results, etc. GE support has looked at the chart and made a couple of suggestions but none has helped. They confirmed that it is not a server or hard issue but is due to the amount of data in this patient chart. Has anyone had this problem and found a solution? The provider wants to create a second chart. Has anyone gotten to the point of creating a second chart for a patient because of a chart size problem? If so, any suggestions on how to create and populate the second chart?
We have a lot of data in our charts as well. We utilize the "archive obs" script that GE built back in ~2003. This only works with Oracle however. I'm not sure how this is accomplished with the CPS line. When the time comes for us to covert to CPS, this will be top on our list of questions!
If you have Oracle, I would contact GE Support and ask about this script.
We did run that script against the patients chart but it didn't seem to help much. Our problem seems to be more after the chart is open and a new update is started. It takes a long time for the update to open and also going between some forms in the encounter. I'm thinking it is also slow when adding meds and problems.
Slow on Meds and problems sounds like a potential issue w/ the service layer (jBoss). Any chance you see this server max on CPU or something when you open this chart?
Also, is the chart only slow the first time you open? .. databases cache information, so its possible that opening it once before you have to use it might improve things.
Have you tried reducing the document display view? Our charts are huge too and reducing the document display view (to one year) helped with loading and documenting.
eglopez said:
Have you tried reducing the document display view? Our charts are huge too and reducing the document display view (to one year) helped with loading and documenting.
How did you change the date range? Are you on CPS10?
bboswick said:
eglopez said:
Have you tried reducing the document display view? Our charts are huge too and reducing the document display view (to one year) helped with loading and documenting.
How did you change the date range? Are you on CPS10?
Never mind. I figured it out. Options->Preferences->Patient Chart->Documents then change the number of months you have listed in the chart. Thanks for jogging my memory about this preference.
You're welcome. Hope it helps. Happy Holidays!
UConnFamMed said:
Slow on Meds and problems sounds like a potential issue w/ the service layer (jBoss). Any chance you see this server max on CPU or something when you open this chart?
Also, is the chart only slow the first time you open? .. databases cache information, so its possible that opening it once before you have to use it might improve things.
Hello, I read you post about "slow meds and problems sound like a potential issue with service layer (jBoss)". We are having a problem with meds refreshing slowly and sometimes not displaying. Do you have any recommendations for troubleshooting and identifying a problem with jBoss? We are working with GE and they have not been able to identify the problem.
Thanks,
Matt Johnson | Fisher-Titus Medical Center | [email protected] | 419-660-2888
Matt,
We found out that jBoss (on the application server) just needs to be restarted... I just set up a scheduled task to reboot jBoss every 4? or 6? hours, starting at 4am. It doesn't seem to disrupt any activity, but it sure seems to help keep the meds tab working... I don't think we tweaked anything else.
Thanks for the response Ed. I thought restarting jBoss stops the website and kills the client application. Are you stopping the service?
-matt
Restarting jBoss doesn't seem to help with our problem. Slow opening the chart, slow starting an update, slow going between forms in the encounter. Only have problem on charts that have very large amount of meds, problems, visits etc.
We've seen that too. A provider can work on a new patient and fly through the update, but then sees a patient with MANY problems and meds and performance in the update suffers greatly. A lot of it has to do with CCC and so many of the functions reading the problem and med lists over and over and over again. It looks like functions recalc even when you aren't on the form that contains those functions.
David Shower
OU Tulsa School of Community Medicine
Matt-
We run the EMR (oracle version) through Citrix, so it isn't web based. My scheduled task calls a bat file to stop, then start the jBoss service.
... We also had to check the jBoss RAM allocation, and make sure it had enough RAM, and could actually use it. IIRC, there is a setting in jBoss that dictates how much RAM can be used (e.g. if flag is set to 2GB, and server has 20, it doesn't automatically use up to 20).
... We don't use CCC, so we don't have that extra overhead. Might be more noticeable as David mentions.
DavidShower said:
We've seen that too. A provider can work on a new patient and fly through the update, but then sees a patient with MANY problems and meds and performance in the update suffers greatly. A lot of it has to do with CCC and so many of the functions reading the problem and med lists over and over and over again. It looks like functions recalc even when you aren't on the form that contains those functions.
David Shower
OU Tulsa School of Community Medicine
David, are you a CQIC member or did you just purchase the CCC forms from GE? We are beginning the implementation of the CCC forms from GE so I'm curious to know if this may be something that we will have to deal with as well.
Thanks,
Linda Keith
West Texas Medical Assoc.