Yes I reproduced it and as above it appears the act of forwarding a chart before signing it off either enters any 'new' medication from the 'Plan' into the current med list as a current medication or if you deleted an Rx in the 'Plan' it is removed from the current med list before signing off the chart. Guess that will be a version 8.3 fix.

This appears to be a serious issue if the above is the case. We know that double clicking on the meds section will have the newly prescribed med in it if the chart was forwarded to self to be completed later, but it does not show up in the final note when the note is closed. This has always been the case in previous versions. I am using v8.02 and am skeptical to upgrade further if the above will be happening.

This would likely be a difficult thing to pick up in beta testing. I would let them know about the bug, and I am sure they will fix it. it's kind of a big thing.

Hello, users. I am a server technician who was hired to alleviate the unresponsiveness of the 8.2.2 program for a practice in the Midwest. What I've learned so far is this.
Disk I/O is at a premium. Even with a single SSD, disk reads were well below what the drive was capable of simply because the program is not requesting the data in the most efficient way.
Switching from one SSD to three working together (RAID) provided a noticeable increase in performance. (1-2 second increase in "pull chart" function, ~1 second increase switching between tabs, 2-3 second increase closing patient chart)
But there was still a significant delay.
Further digging proved the SQL Server Express 2012 that installs with Amazing Charts to be the culprit. with the disk I/o maximized, we discovered that the program was only taxing a single processor core.
This was tracked back to SQL Express.
it is here that I am now, as I am unable to test with full sql over the weekend to see if it will utilize all available cores for database requests.

Does anyone know if there is a way to push DB requests to SQL without calling Amazing Charts support?

Good info Chi a while back I questioned AC support about going to full sql for 6.6.7 and got a lukewarm response: "could be done but should look at other issues", then version 8 came along and brought delays to another level.
This info needs to be directly addressed by AC.

First caveat: I am not even close to being a SQL expert. I agree that pushing data rather than pulling it can be faster. I doubt that AC support would be able to help there as they don't tend to have SQL technician support.

As far as koby is concerned, there are practices which have used Standard versions of SQL and had a significant increase in performance. Especially large practices. But, SQL Server 2012 Standard is $2,800 with 10 CALs. There is simply no way 8,000 users are going to be able to swing that.

We will be putting out a more systemic approach to this, but the short answer to the progression after an upgrade that raises performance issues is this:

<1>Review the system, network, configuration, disk i/o, server configuration
<2>64bit SQL Express upgrade - no licensing costs, labor costs for the work (FYI - we learned doing one this weekend that you need to verify that the directories are uncompressed or the un-install will lock the Microsoft software state) Another example of why our crew does this on weekends
<3>Full SQL - there are cost and benefits. We always run our clients through this process before actually doing this.

Depending on several factors, practices with 10 or more computers should start with #1 BEFORE upgrading, or Physician/Provider unhappiness may ensue.

There have been some performance issues with Updox-AC scheduling syncing that hopefully will be resolved as early as this week.

As a general observation, for those moving from version 6.x this year will find that upgrading just hardware may prove frustrating.

The number of practices that need/afford full SQL will be a sub-set of the installed base, but as one practice expressed, upgrading to full SQL is less expensive and disruptive than changing EMRs.

AC and we are announcing several things; I commend John Squire and AC for embracing the option of using full SQL as this enables them to extend the reach and capability of Amazing Charts.

Some people may not know that our largest AC client has between 45-70 users with ~150 desktops. At scale, performance is a holistic activity that requires several significant and distinct skill sets for success.

That said, I hear from AC a serious focus on fixing and improving performance and long-standing influences the balance of 2015. We wish them success in that, even as we take a more active hand in helping practices adequately prepare for upgrades.

Great to have the resident geniuses offering SQL upgrade knowledge if needed. Over 10 users sounds like SQL upgrade may be a factor.

AC does a pretty good job overall, given MU and ICD10 requirements that have taken their development focus for the last 3+ years.

There has to be code optimization that will help, no? That's "free" with no SQL nor hardware upgrade. Hopefully AC has some time and resources to do that as mentioned in other posts. We should gently but firmly ask for it more than any "feature" add.

A lot of us run small scale (<10 users) on modern, fast server/clients, SSDs, plenty of RAM and still hit pauses/lags. They are tolerable but interface snappiness makes the computer transparent to workflow. Small lags disrupt concentration and cause frustration and clinically proven slow buildup of physician computer rage;)

AC in my office under my control is far better than the alternative. My local hospitals run EPIC on VMs. They allocate resources just fast enough to run the program but not fast enough to be snappy: 1-20 second pauses and delays all over the place not to mention the repeat RSA key password signins for every order. They just don't care - it "works" and didn't cost them too much... I'm dreading the day I might have to use EPIC on a VM connection for daily office use.

Could be wrong again, but I don't see where the Standard version, which allows much more memory for caching is going to be that much faster until you get to a much larger amount of users.

My main reason for making my statement is above is to allow people to understand that AC can't just use Standard with its product. It can only package it with Express.

optimizing 64bit sql express sounds like where this is going,
that being said does anybody with good understanding of tcp connections and using resource monitor make a comment about why so many AC tcp connections sql tcp connections and how does this play into performance lag,

What other versions have this lag? And, is opening and closing the chart the biggest time issue?

I recently teamed some NICs on my server and got a bump in performance. Don't forget that option with networks.

There is also a memory leak with AC that may have been fixed by now. When the amount of memory gets up there, the machines really slow down. But I have my main computer run the following every 5AM to clear the memory. Looking at the performance monitor will show you the memory cleared up with this.
NET STOP MSSQL$AMAZINGCHARTS
NET START MSSQL$AMAZINGCHARTS

What is the highest amount of memory you have seen?

I've seen the memory use drop from 7 GB to 2.5 GB.

And, you are using SQL Express?

Using the 64-bit sql express

As an FYI, versions of SQL which are Express only use one core. This is the major reason that non-Express versions out perform Express versions, other than the memory increase.

Due to the one core usage if there are multiple users querying the database at the same time, then there can be performance degradation.

One should also be sure to have the latest Service Packs.

If the new ICD-10 codes are causing issues with certain screens, then we can find out on ways to tune it provided we have SQL Server Standard or Enterprise edition.

Change to SQL Server Standard is not a plug and play operation. The only thing I don't know is when you upgrade, if it is no issue.

I have also noticed new databases in the AC chart. I have no idea if this has anything to do with it.

PartnerTranactions.mdf and Log.log

CAN SOMEONE LOOK AT THE MOST RECENT VERSIONS GOING BACK THROUGH THE 8.0S TO THE 7.0S AND SEE WHEN THIS CHANGE TOOK PLACE.

I can then look into that.

Wow, wonder if there will be a 'quick' fix short of full 'cost a buck or 2,800' SQL to get this slowness resolved.
Getting used to slowness in the meantime doesn't sit very well.

The problem is which I brought up to AC is that moving to standard may fix the issue at $2800 a pop, BUT what has changed other than ICD-10 and some other databases?

I suspect slowness problem, especially for small offices, is some inefficient coding issue rather than lack of SQL standard and that greater processor speed and more memory are being offered as solutions.

Hi Ken,

What do you mean by inefficient coding issues...

Greater processor speed and more memory shouldn't be the problem. I mean I have tons of memory and i7s all around with Cat6 and 1GB of cable, switch, and NICs. Everything was very good speed. Then 8.2.2, and it's slow. It's pure coding.

I think that SQL Standard can help, but offices can't run out there and purchase SQL Standard. Plus, it isn't simple to add. You can do tweaks with Standard that the average user can't do.

I just set up my sandbox and network consisting of ONE computer, and I am getting six seconds to open a chart. And, that is with one person opening a chart or doing ePrescribe or closing a chart.

Just sayin' At this point, I can't see making the switch even for ICD-10.

Agreed with Bert. We should all be asking AC for program code improvement for performance.

For "small" users it's not the hardware nor SQL.

BTW did the NET STOP, NET START AC SQL as suggested by Kevin didn't seem to impact the slowness any, darn.

Rebooting will do the same thing. Just gives all the memory back to the server. I really don't think it is a memory issue.

Patience Grasshopper

That went way over my head. And, I never missed an episode with David Carradine.

Are people noticing major differences in performance with SQL 64 Bit? I'm not seeing any difference.

SQL 2012 Express Limitations:

• Limited to lesser of 1 Socket or 4 cores
• 1 GB maximum memory per instance
• 10GB max database size

There shouldn't be any noticeable difference between 64 bit and 32 bit SQL EXPRESS. You're still limited to 1GB per instance. While SQL has other components that can push it over 4GB. The database instance is limited to 1 GB. Also, it shouldn't be restricted to 1 core but 4 cores. It's one reason why people with i7 Processors have better performance than Xeon users due to the higher clockspeed of the 4 cores. SQL full is multi-threaded, but SQL Express benefits from higher clocked cores.

I will be checking this soon, but it could be possible that in the new AC version it has been restricted to 1 core instead of the normal 4 cores or it may be seeing quad core processors and 4 separate processors and applying the single socket limitation.

Was talking to myself mostly; although the overall angst over the s-l-o-w-n-e-s-s addressed in this thread is palpable; so then the Eastern-flavored-Hollywood manta perhaps spoken by Carradine

As per discussion with the tech support, the bug about the new medication showing up in the current medication list is reproducible and is expected to be fixed inversion 8.3

Continue to have issue with templates falling in bottom of note
Reported this in 8.02 but not fixed
Now that Ac has survived triple witching with mu2 icd 10 and practice mgmt
It is users turn to have simple requests filled
Does the Advisory board have any say and can our requests be sent to practicing docs rather than programmers??

I've finished my preliminary analysis of the performance differences between V667 and V8. Bottom line is that it's only slightly more demanding and if you have a good server from the last 3-4 years. You should be okay, but I would recommend switching to SSD-based storage. Cloud Users may experience delays as your host may need to dedicate more resources to each instance running a newer version. Clock speed is more important that number of cores with SQL express. A 4.0 GHz Quad Core i7 will outperform a 10 core Xeon at 2.4 GHz. The new version appears to require additional processing power and disk IO. This may come at an additional cost.


Read more at: http://ltmedical.net/?p=2357

That is an impressive analysis and at the level we have come to expect from you. And I mean the following to come across in no way condescending.

Now the actual bottom line is what a good many of us are seeing in our offices. I am comparing v6.1.2 with v8.2.2 on the same client and server. Basically, at a crucial point of use, namely opening and closing a chart, the earlier version is 6X and 4X as fast, respectively. It is, in short, unusable and the burden to fix it is not on the 10,000 users but on AC.

Are you doing this test over the network. I had no issues on my virtual machine. It was only when accessing the database with just one machine that I had the issue.

How's the speed on the main computer? Are you using Solid State or Hard Disk storage? What were the specs of the VM's? 6X and 4X are big differences.

I was just outlining that with ideal conditions (fast processor Xeon E3/i7 with SSD), the performance seems to be the same. I plan to do further testing with hard drives. In the field, it's mainly the people with HDD's that are suffering significant performance issues. I was referring to our 2012 Solo+ server in the article which has some impressive specs even by today's standards. Bottom line was that if you had a similar processor and sufficient memory, try switching to SSD and the performance should be fine. I suspect the performance will degrade significantly when using hard disks as opposed to SSD's. The specs of the VM's aren't anything too crazy.

Also as mentioned earlier we have optimizations like flushing of the database that keep the SQL Database cache lean. If yours is maxed out, it does not matter if you have an SSD.

In my setup, I was using a server with a Xeon E3 Processor, 24GB of RAM and a 10,000 RPM HDD. The client was using a 240GB 6Gbps SSD with an Intel i7 processor with 8GBs of RAM.

This is plenty good enough for eight work stations, and the test I ran was with no one in the office.

I don't know about everyone else, but I am not going to upgrade my server to higher specs just to run an AC upgrade. I should not need more than 24GBs of RAM.

ALSO FOR EVERYONE OUT THERE....on the client machine, I have installed v8.2.2 with one patient, with one progress note, no meds, no past encounters and no Imported Items. So, the possibility that has been mentioned that the program is pre-caching all of the past encounters and, therefore, patients with large charts would be slower would not be the case.

To answer your questions, this is with a completely rebooted server. I have also run it standalone in a VM. It is nearly as fast on the VM as on the server. The client is connected to the server.

There is also slowness such as 2.5 seconds vs less than 1 second on opening ePrescribe.

Yes, definitely, using HDDs and not SSDs. I would expect a significant performance boost with SSDs anyway, although I understand your point that it may solve the issue.

The problem is if you have a BMW that is running well, and you upgrade to a Ferrari, and suddenly you can only go 0 to 60 in 15 seconds, then they need to fix the Ferrari and not expect me to repave all of the roads.

Not all 8,000 users are going to have performance issues for whatever reason. But for those that do, you can't expect them to all run out and get SSDs.

My time schedule is October 1st for implementing ICD-10. I plan to purchase a new Dell T420 soon, which will run all SSDs likely in a RAID 10. But, that will be on my time schedule and not on ACs.

Any chance you can use an SSD in the server? That client would make a good server too.

RAM isn't a big deal. I used 5GB in my test with a full production database. 1000+ messages in the inbox. 10 years in practice with AC.

10K RPM HDD's only have IOPS in the 125-150 range. SSD's have them in the 60K+ range. Most likely AC just needs more IOPS to run. You can either RAID HDD's or get an SSD. I used a <$100 Kingston 256GB SSD. Beats the $2000-$3000 SQL upgrade people are recommending.

I guess I see the issue as more of a consequence of using SQL Express rather than poor optimization. AC could force everyone to use full SQL and all performance issues would likely disappear. The hard drive speed has always been an issue for many practices. This new version pushes it to the limit. However, adding an SSD is not a bad alternative. I sent this recommendation to Chris Conrad in an email. Making SSD's part of the hardware requirements would help them more than anything. Most other EHR's require you to purchase the full version of database software. E.g. Praxis makes you buy Oracle DB for $5,000 on top of the $10K licensing cost for the EHR. SQL Express is severely capped by disk I/O.

ICD10 has 60K+ codes. These are going to take a toll on your setup. There's only so much you can optimize before improved hardware is needed. People had to upgrade hardware to go from XP to Win 7. I think of this as a similar situation. I mean if they are forcing everyone to upgrade, might as well just get the SSD's. I was seeking a solution to the problem rather than waiting for them to fix it if even possible. They may not be caching the charts but all the new stuff like ICD10 codes which could cause some significant slowdown. It would be trivial for someone on the dev team to track down what it is exactly, but will require some significant time investment on my side to figure out what it is exactly. I wonder if it has anything to do with the new AuthService/network encryption.