Medication Search Problems in Clinical EMR - Slow Response Times
Posted: Sat Aug 10, 2019 10:42 am
Hi,
Reaching out to others who have Medisoft Clinical. Our office has noticed a severe slowdown in searching for certain medications when in patients' charts. These slowdowns are causing decrease in productivity. I am going to rule out network and workstations at this time since I can reproduce the slowdown on the server itself which is a Dell PET430 running server 2012 R2 with 32GB of RAM with two (2) 3.00 GHz Intel Xeon E5-2623 v3 processors. C drive has 38GB free of 100 GB and P Drive has 1.40 TB free of 1.80 TB. According to our VAR, our EMR is up-to-date and we just updated the RX database that would expire in August. Archived scans in three folders for employees that scan total 15,000 files at about 4 GB total. PPART Directory on P drive is 265 GB. Medidata folder on P Drive is 12.8 GB. We have one MD and one NP in clinic along with three front office staff and myself. All Workstations running windows 7 Professional.
The example I can give is the drug Lyrica, As a neurological clinic, we use this drug a lot! When in a patient chart, click on RX/medications tab in patient chart, click new, NOT using the template search box but using the Rx: search box, I type in Lyrica. I then click the "..." and the next window that is suppose to pop up takes 10-20 seconds I have determined over the past week. This 10-20 seconds on the server becomes 20-30 seconds at times on workstations. If I get impatient while the cursor wheel is spinning on the server, I get a "windows not repsonding" label at the top of the active window. I then have to wait for the active windows to resolve itself and display the drug Lyrica and its alternative drugs in the bottom half of the active window. On my workstation, if I get impatient like I did on the server, I get a "windows not responding" pop up dialog box, different than the server, and I can either "close the program" or "wait for the program" to respond, If I wait, the Lyrica Drug window eventually pops up and behaves as normal. I tried a few of the impatient tries on my workstation and one time, I got even a .NET Framework unhandled expcetion error message to appear. I clicked continue and the Lyrica drug and EMR behavior was normal.
Back to the server, is this normal behavior or is there something with surescripts or a database somewhere that is not working correctly? This slowdown never existed when we first purchased the EMR. According to staff, the slowdown started in the spring of 2018, yes, 1.5 years, and then we really started having issues after drug database upgrade in Feb/March of 2019. My staff also says that as we get closer to the 12 week notification or time to update drug database, the medication searches get worse. After the drug database update, searches are quicker, but as time goes on over the next 12 weeks, things start to get progressively worse. I have not seen this myself, but and reporting information only.
We are having a few other issues with regards to slowness but this error/problem is the most concrete example I can give right now to consultants for help. Some drugs appear quickly using the "..." Rx feature, but other drugs really take a long time. We were given a solution to just use the templates, but we can't template every drug, especially other drugs of outside doctors. Besides, to get the drug interaction feature to work, every drug needs an NDC, so when a patient mentions a cancer drug that is not in a template, then we have to search anyways for the drug which sometimes can take 10-15 minutes for an employee entering outside medications for a patient. This is where the productivity part comes in... I feel this suggestion is not a good workaround, and our office knows about workarounds after another EMR for 10 years.
Questions:
1. is this behavior normal on the server?
2. if answer to questions 1 is no, what is normal response time and how do we go about fixing
3. If yes to questions 1, is anything being done to solve these problems and is someone aware of the issue.
4. if yes to questions 1, do we at least know why this is happening?
Thanks,
-S
Reaching out to others who have Medisoft Clinical. Our office has noticed a severe slowdown in searching for certain medications when in patients' charts. These slowdowns are causing decrease in productivity. I am going to rule out network and workstations at this time since I can reproduce the slowdown on the server itself which is a Dell PET430 running server 2012 R2 with 32GB of RAM with two (2) 3.00 GHz Intel Xeon E5-2623 v3 processors. C drive has 38GB free of 100 GB and P Drive has 1.40 TB free of 1.80 TB. According to our VAR, our EMR is up-to-date and we just updated the RX database that would expire in August. Archived scans in three folders for employees that scan total 15,000 files at about 4 GB total. PPART Directory on P drive is 265 GB. Medidata folder on P Drive is 12.8 GB. We have one MD and one NP in clinic along with three front office staff and myself. All Workstations running windows 7 Professional.
The example I can give is the drug Lyrica, As a neurological clinic, we use this drug a lot! When in a patient chart, click on RX/medications tab in patient chart, click new, NOT using the template search box but using the Rx: search box, I type in Lyrica. I then click the "..." and the next window that is suppose to pop up takes 10-20 seconds I have determined over the past week. This 10-20 seconds on the server becomes 20-30 seconds at times on workstations. If I get impatient while the cursor wheel is spinning on the server, I get a "windows not repsonding" label at the top of the active window. I then have to wait for the active windows to resolve itself and display the drug Lyrica and its alternative drugs in the bottom half of the active window. On my workstation, if I get impatient like I did on the server, I get a "windows not responding" pop up dialog box, different than the server, and I can either "close the program" or "wait for the program" to respond, If I wait, the Lyrica Drug window eventually pops up and behaves as normal. I tried a few of the impatient tries on my workstation and one time, I got even a .NET Framework unhandled expcetion error message to appear. I clicked continue and the Lyrica drug and EMR behavior was normal.
Back to the server, is this normal behavior or is there something with surescripts or a database somewhere that is not working correctly? This slowdown never existed when we first purchased the EMR. According to staff, the slowdown started in the spring of 2018, yes, 1.5 years, and then we really started having issues after drug database upgrade in Feb/March of 2019. My staff also says that as we get closer to the 12 week notification or time to update drug database, the medication searches get worse. After the drug database update, searches are quicker, but as time goes on over the next 12 weeks, things start to get progressively worse. I have not seen this myself, but and reporting information only.
We are having a few other issues with regards to slowness but this error/problem is the most concrete example I can give right now to consultants for help. Some drugs appear quickly using the "..." Rx feature, but other drugs really take a long time. We were given a solution to just use the templates, but we can't template every drug, especially other drugs of outside doctors. Besides, to get the drug interaction feature to work, every drug needs an NDC, so when a patient mentions a cancer drug that is not in a template, then we have to search anyways for the drug which sometimes can take 10-15 minutes for an employee entering outside medications for a patient. This is where the productivity part comes in... I feel this suggestion is not a good workaround, and our office knows about workarounds after another EMR for 10 years.
Questions:
1. is this behavior normal on the server?
2. if answer to questions 1 is no, what is normal response time and how do we go about fixing
3. If yes to questions 1, is anything being done to solve these problems and is someone aware of the issue.
4. if yes to questions 1, do we at least know why this is happening?
Thanks,
-S