We have been having an issue with some charts exceeding 40 medications and several hundred documents. These charts are very slow to load and prevent the provider from being able to interact in a reasonable time frame. Overriding medication interactions is especially challenging. I was able to set the document view filter to only load the last x number of months but this only improves initial chart load speed.
How are others addressing very large charts? Thank you in advance.
Limit the timeframe of document display on the main document windows by up to 12 month.
also run the archive obs utility on the database and limit the OBs term loaded when you open the patient chart initially. Will help greatly improve preload issues.
Patient with 40 medications at once? that is unlikely, Have your doctor do so Meds reconciliation and have them remove some of those medications. If not possible have some staff preferable some RN, Nurse practitioner or Trained Medical assistant review those medication with the patients.
A simple call from now a then asking which medication they are still taking, which one they stopped and why, would do wonders
Interesting question. We are actually also reviewing 'slow loading' charts. And while unusual, I also see some patients with 40+ items on the med list; keep in mind, items other than prescriptions will often be here - vitamins, herbals, assistance devices, etc...
Something that we stumbled upon was that some of our patients had a significant number of contacts (duplicates) in the Contact tab. We have been working with GE on a remedy for this. So, if you are seeing this, perhaps contact GE for assistance.
One thing you need to look at is custom forms. Many times, there will be functions/watcher expressions that are constantly looping through the clinical lists, and when problems or meds get long, they really slow performance. You need to code a test into the function(s). I've done functions where I've set a variable to the size of PROB_AFTER() and I compare that saved value to the current size. If it hasn't changed, don't loop through again. Only way to figure this out is by looking at traces.
I gotta throw this in.
Make sure your sql server, j-boss, and terminal/citrix servers are on SSD or flash storage.
That was the best answer for general hardware performance.
Our DB server is all on SSD and we generally do not have performance problems even before we were limiting documents and OBS. The exception I have found is once we upgraded 2 weeks ago to SP13, things slowed down drastically.
Thanks very much for the feedback!