Home Forums Discussions Problems v6.0.10 slower than 6.0.9

1987. Started practice at a very small Community Health Center in a very small community in south central Pa. Hot dangerous new drugs were Mevacor (everyone afraid to use this, required slit lamp exams twice yearly), Losec (anyone know what this was renamed and why) (also scared to death to use), and Prozac. Intense competition between Augmentin and Ceftin, both branded. No computers in office, no faxes in office. Notes were dictated and typed, on a typewriter.

As Leslie said, even this was past the golden era. But it just seemed so much simpler. The goal was to help the patient, and avoid malpractice.

Maybe just too many years gone by, maybe too tired, maybe things really have changed a lot. But I do miss those days.

And I complained about off topic posts earlier today?

Gene

Ahhhhhhhhhhhhhh...the memories! The purple pill Prilosec sounded too much like lasix. Prozac was a no-no around here (Louisville area) because of the massacre at Standard Gravure by a man who was taking it. But they were good times until the insurance companies decided they were going to drive the bus.

@Gene

I was thinking the same thing about off topic while I was reading your post, lol.

@Leslie

Love will keep us together (Capt and Tennille -- not you and I)

I thought the purple pill was Nexium?

Prilosec was originally "Losec." When prescribers scrawled this on a rx pad, it sometimes got filled as Lasix as both come in 20mg strengths. So Losec's name was changed to Prilosec :-)

2 winners to the (Pri)Losec trivia! Remember when you could NEVER EVER take it for more than 6 weeks?

On topic: All afternoon I have been watching meds load line by line on my Win7Pro i5 laptop.

Gene

Oh, yeah. (Pri)Losec gonna give you gastric tumors like when given megadoses in rats! Ironically now they sell Prilosec OTC like candy in the drug stores.

On topic: I need a Prilosec after using 6.0.10

Now, you just go with TALLman or whatever is called, so it would be:

LaSIx

@Gene

Now, everyone knows you need at least an i7, lol.

The other new development. Today, for the first time, I could hit erx button (final step) and have a pause up to 30 seconds. Internet and network speed normal. Most other times this is just about instantaneous. Gene

David (et. al) - you are right and we really do appreciate all the constructive criticism. The unconstructive criticism is a bummer, but is deserved given our lack of any reasonable response to all the concerns being voiced here.

Over the past number of months since V6 was released, we?ve become aware of performance issues affecting a sizable minority of our practices (i.e., about 10%). If you are one of the practices that has been affected, we sincerely apologize for the frustration, inconvenience, and stress these issues likely are causing you, your staff, and perhaps even your patients. We also apologize for not posting this information sooner.

Below is a summary of the most pressing issues that are being reported to our support team, and which we also understand from the board:

Prescription Writer
A number of practices are finding that the prescription writing process has slowed dramatically in V6.0. The effect is most often manifested with the medication window appearing to get stuck while opening. By far the most significant slowdown is when the medication window is opened for the first time after starting the program, taking up to 10 seconds for many ? and even longer for some. After the first time the window is opened, subsequent openings are better (in the 1-5 second range), but even a second or two for a window to open adds up over the course of the day and is definitely not what we would consider as "usable."

There are a number of workarounds which can increase the prescription window opening speed (including turning off Interaction checking, increasing the computer?s RAM, upgrading servers, turning off hardware acceleration where possible, or even purchasing better computers). Of course many of these options simple aren?t feasible. And although this can make the problem tolerable for the users affected with slow window openings, it does not address the underlying issue that we believe are related to the way our program handles all the ?stuff? it has to do to write a prescription ? nowadays -that conforms to the rules, regulations, and laws now required by Surescripts, CCHIT, and the DEA. (FYI - we hate adding all this extra stuff too, Leslie, but it is required for us to remain an ongoing concern.)

We are currently obtaining additional objective data (e.g., window opening speeds on different databases) to determine exactly where and how the slowdowns are occurring (though it is most likely multifactorial and related to the way we do Interaction checking).

Restarting Amazing Charts
Although quitting or shutting down the Amazing Charts program appears to happen quickly, it actually takes about 30 ? 60 seconds during which time if a user tries to restart the program they get a message that Amazing Charts is ??in the process of starting up or shutting down.? There are no workarounds for this issue as even using the Windows task manager (ctrl-alt-delete) doesn?t speed things up -it still takes a many seconds and the user is forced to wait before restarting.

Imported Items
The Imported Items module has a number of problems, some of which have been around in prior versions and were not adequately addressed for V6. These include an issue when clients sign-off their Imported Items faster than Amazing Charts can process the changes. In this situation, the program is still processing a prior command but allows another command to be entered causing the program to unexpectedly crash with a runtime 91 error (or a message that the item can?t be found). Another issue occurs when trying to delete an imported item that has been accidentally saved to the wrong chart by somebody in the practice. In this quirky issue, a non-specific ?no-permission? error can appear, requiring the user to click elsewhere on the screen and try again.
But the biggest frustration with Imported Items occurs when trying to open patient charts that have quite a few imported items (e.g., in the twenty neighborhood) ? which, of course, happens the longer a practice uses an EHR. While faster computers and wired internal networks make this tolerable for most, the real solution is a complete overhaul of the Imported Items module. In the meantime, we are looking at where we can get the best improvements with simple changes that can be incorporated sooner.

Orders
As discussed extensively on the board and at ACUC 2011, we know the Orders module still has a lot of room for improvement. Adding to the mediocre design of this module in past versions, we?ve now added the ability to reconcile and track orders as part of the Meaningful Use Wizard ? which can slow the orders process dramatically, resulting in the program appearing to hang for upwards of 20 to 30 seconds when opening the Orders window. Making this even more frustrating, since it appears that Amazing Charts has frozen, users commonly try to quit and restart the program leading to the frustrations described in the Restarting Amazing Charts issue above.

Once the orders window does open, the process to reconcile an order with a result is also slower in V6. If one tries to reconcile or close multiple orders at the same time, some users are even experiencing a runtime error 91, after which Amazing Charts simply shuts downs (aka: it crashes).

This is not related to how many orders remain outstanding or have not been completed and those clients experiencing this problem find it will occur not only on local computers, but also on the main (server) computer (although it is worse on the local computes). There is no adequate workaround, other than the hardware improvements of faster computers, wired networks, and more RAM.

Messaging
Moving from the Amazing Charts message Inbox to a group box can be quite slow and can even cause the program to crash in some cases and for some users. This appears to be related to a mailbox becoming too full ? which happens more now since we no longer automatically delete, deleted messages, after many users complained they were inadvertently losing charts attached to messages. Unfortunately, if the deleted message box gets too full, it can slow down messaging in general. The workaround is to turn back on the automatic deletion of deleted messages that is under the Edit | User Preferences menu on the main Amazing Charts Desktop screen.

Automatic Backup
For some clients, the Amazing Charts Automator, which controls automatic backup of Amazing Charts, may inexplicable stop functioning. Automatic backups will run at the set time for awhile, but may fail to update the ?next run time,? resulting in no automatic backup being completed. Other than manually performing backups using the Backup Utility, there is no workaround ? and we?ve yet to determine why this is happening to those it affects.

Star Micronics TSP printer
This worked in V5, but stopped in V6. We are still investigating the cause and possible solutions, although I see some workarounds have been posted on the board already.

Admin Services Not Running Error
We are hearing that a significant number of clients are receiving a message on their local computers that "admin services is not running" on the main computer. We are still investigating.


Take Home Message:

• We understood some of these issues existed, but were not aware to what extent they were causing misery. Based on the total number of support contacts we receive, we estimate that one or more of the issues above affects about 10% of our clients.
  
  
• We are currently analyzing what can be done programmatically to improve these performance issues STAT.
  
  
• We are confident that we can find one or more solutions that will have a positive impact, and therefore are now planning to add a rapid-release build to get these solutions released ASAP (i.e., within a month).
  
  
• This will likely impact our ability to release the Practice Management module in Q1 2012 (which is the reason we have delayed addressing the known issues that have been described on the board and at ACUC).
  
  
• We will find a better way to acknowledge and communicate the status of significant (or possibly significant) issues like these in the future.

Again, please accept my sincere apology for not better communicating these issues, and have confidence that we are working hard not only to get a working solution to those affected as soon as possible ? but also keep you informed of what?s going on at Amazing Charts.

Jon, as originator of this thread, I can't tell you how much I appreciate your post. Of course I will be patient, knowing that you are working on it. I, for one, will vote for making the current product totally clean before expanding its horizons.

I would like to echo David's sentiments. Amazing Charts has always been the best EMR due to your philosphy of what an EMR should be and williness to listen to your customers.

Thanks Jon.

I agree with the comments echoed above - I have used Version 6 for a long time and find the slowdowns irritating, but not a deal breaker. I am glad that Jon came on and gave this information and look forward to improvements.

Jon,
You know that I do not blame you for all the government stuff...I abhor IT, not you or your program. I have defended you in the past for delays in the arrival of the PM because of having to comply with all this blubber. As Ron Paul said last night, we need less government (sorry for the political intrusion). I will hang in here with you.

@Bert, Prilosec was purple before purple was even cool.

Jon, thank you for this update. It is good to know that you and your team are working on some of the problems that have crept into AC as alot of rapid development occured.

Jon,
Thanks for the update. I think it is all that we care about-that you are aware of an attempting to address the issues. I look forward to trying V6 when the update comes out. I would also like to echo what the others have said: I will gladly wait for the PM module pending the fixes on the current release.

Dear Jon,

New member of the forum and your reply is very reassuring. Our group of 8 physicians will be meeting tonight to discuss implementing and choosing an EMR. I will share your response with my partners, but hope to be an official AC user soon. jimmie

Hi. Regarding the Prescription Writer causing very slow painting of the window (minutes long for our XP SP3 clients), I recently sent to one of your Help Desk supervisors (via email) a very long description of some of the "under the hood" issues that seem to be causing this problem.

In our case, it has to do with the AC client spewing out hundreds of SMB packets to the server, and I stated that I believed that all such packets referred to a request by the client to either "lock" or to "read" the tiny file on the server which is stored (on our server) at C:\AmazingCharts.xml
I also reported that "something" is causing this file to get continuously corrupted. Three binary bytes (non-ascii characters) get inserted at the very start of the file.

I offered to help anyone on your staff to debug this issue further, to run whatever tests you want me to run, etc., but so far I have not heard back from anyone. I also supplied my direct contact email address. More than a week has passed since I sent my first email directly to you, Dr. Bertman (via the account of Dr. Westafer), and we are nearing one week since I sent a second email containing all the details to a Help Desk supervisor who promised to send it along to the developers.

I now know that I should have used the AC facility for submitting a bug report, and I apologize for going through you and the Help Desk to pursue this issue, because I was ignorant of the "report a bug" facility offered directly within the client itself. Having said that, I sure would like to know if you would be willing to take advantage of my time and expertise to find out precisely why so many packets fly out of the client and why the C:\Amazing Charts.xml on the server is continually getting corrupted. E.g. did you know that even after the Prescription Writer finally settles down, that a simple mouse movement within that window once again causes hundreds or thousands of the same packets mentioned above, to once more fly out of the client and over to the server?

I will be more than willing to help, given that my doctor and her staff have suffered from this problem ever since January, 2011 ... and I am sure therefore that this problem did not begin with the release of Version 6.

Personally, I suspect the .NET framework that was targeted for your code during the build process. But I have no way of verifying that.

Sincerely,

Greg (MaxJammer)

Thanks for the much needed update on AC version 6. I also echo the comments above that many of us would appreciate the bug fixes more than an earlier version 7.

Thanks for your post. Could you rephrase what you meant by "targeted for your code"

I am glad that there are users out there who don't find the Prescription Writer slowdown to be a "deal breaker". Unfortunately for us, we have suffered with this problem since January, 2011, as I previously stated. I believe that this slowdown started with either 5.0.29 or 5.1.7; I am not completely sure.

It is incredibly painful for us because we have many exam rooms and nurse's stations that still must use Windows XP SP3 because we simply cannot afford to upgrade our computers all at once. I am not exaggerating when I say that it takes minutes (not seconds) to paint that window. And this has caused an immense amount of stress for our doctors and for our nurses. We have already upgraded some of the machines, so these machines can now run Windows 7 and they do NOT experience the problem. We will continue to attempt to replace all of our old equipment, but we cannot afford to do more than a few per month, at the best. Given that the problem has been around as long as it has (at least since January, 2011), I, for one, would like to see it fixed, and I am more than willing to help.

Sincerely,
Greg (MaxJammer)

Hi. Thanks for that question, because it also cleared up some things in my own mind.
I was talking about the "build process" that occurs at the company itself, that is performed by the developers or some "build team" that exists for no other reason than to compile all the source code and --eventually -- to create the latest version of the Amazing Charts client.

I should have been more clear, because I now realize that I am talking about two different processes that almost certainly occur at the company itself in order to create the client: Development and Build.

Nowadays, everyone uses some IDE (Integrated Development Environment) to write the code for their programs. The Amazing Charts client is almost certainly no different. And when the AC developers are writing the AC Client code, they are almost certainly making calls to a Windows API that is known as the .NET Framework, which you can think of as "already compiled code" that is supplied by Microsoft. In fact, you can go to the Microsoft website and download various versions of the .NET Framework (various releases, I mean).

Microsoft has made several releases of the .NET Framework. The two most recent, and the only two that we need to talk about here are 3.5 and 4.0 (I think that those are the version numbers). There is some possibility that the AC developers were using (in their IDE, this would be called "targeting") 3.5 for a long while and then suddenly switched to using 4.0, maybe some time around January 2011. Or, to be more precise, there is some possibility that AC versions 5.1.9 and upward were all compiled using the .NET Framework 4.0 framework. And this might be the source of the problem. It could be that .NET Framework (as distributed by Microsoft) is "broken", and then again it could be that the AC program itself is "using" some functionality in .NET Framework 4.0, and they are using it incorrectly.

But this is all just a guess! I have to remember that not only is the client behaving "badly", but also the C:\AmazingCharts.xml on the file is getting corrupted by "something". Is that "something" in the client? Or is it in the Server?

My guess, however, is that even THAT problem (the file corruption) is due to something going wrong in the AC client. And that "going wrong" could be occurring in the AC developer team's code, or it could be occurring in the .NET Framework 4.0.

By the way, a few weeks ago, a Help Desk person told me (via Chat) that .NET Framework 4.0 comes "bundled" with the AC client installer when you download the installer. He claims that the AC client now needs 4.0 (can no longer just use .NET Framework 3.5) because of something having to do with Crystal Reports; I know nothing about Crystal Reports, and I don't really care, I think.

The problem that I had with this claim (that .NET Framework 4.0 comes bundled with the latest release(s) of AC Client) is that I KNOW for a FACT that .NET Framework 4.0 did NOT get installed when I installed any of the versions 6.x of the AC Client onto my XP boxes. There was no trace of .NET Framework 4.0 on my machine after I ran the AC Client installer.

Is that part of the problem? I don't know! I don't know if the Help Desk guy was even correct in telling me that .NET Framework 4.0 DOES get installed when you install the AC Client! So, since I still did not have the .NET Framework 4.0 installed on my machine, what I did was to go out to the Microsoft website to download .NET Framework 4.0 and to install it.

I did so. I then ran the AC Client again ... and we still have the same problem.

But there is yet another (very) stick issue here: I have no idea how to verify that my AC CLient on XP is actually USING the .NET Framework 4.0 that is now installed on my machine. I have many other .NET Frameworks also installed on that same machine, e.g. 3.5 ... and the AC Client might be using the 3.5 rather than the 4.0

I simply do not know how to determine which .NET Framework a program is using when you run that program. However, I have heard that some of this depends on which .NET Framework the "developers" use (target) when they are writing and compiling the AC Client code. And I sure would like to find that out.

At the very least, I would love to know if the development team is now "targeting" .NET Framework 4.0 when they develop the code, and I would like to know if the "build" team is in fact including .NET Framework 4.0 in the AC Client installer.

Ideally, I woud like very much for a developer from AC to call me or email me, so that we can test out whether or not the Version 6 (even 5.1.9) clients running on XP are using the .NET Framework that was "targeted" during the development and build cycles at the company. AND to find out whether or not it is really true that ".NET Framework 4.0 ships with the AC Client". It does make sense that it should; otherwise, if you install the AC Client and try to run it, if the AC Client needs 4.0, it simply won't work. Then you (the end user) would have to go to the Microsoft website, download 4.0 and install it yourself! So, yes, I certainly could believe that the .NET Framework 4.0 does ship automatically "inside" the AC Client installer when you download it. But like I said, when I ran those installers for the 6.x versions, I still did not see any .NET Framework 4.0 on my machine. I still had only .NET Framework 3.5

Greg (MaxJammer)

My last post was so long that I decided to try to summarize it:

Where might the problem(s) lie?
(a). There could simply be a bug in the AC Client code.

(b). There could simply be a bug in the .NET Framework 4.0 as distributed by Microsoft.

(c). There could even simply be a bug in the AC Server code whereby, when the client attempts to access "C:\Amazing Charts.xml", the server-side bug corrupts that file. This could then trigger the AC Client to "go crazy". It might be trying and trying to access a "correct" version of C:\Amazing Charts.xml on the server, only to find, time and time again that the access is failing. So, maybe it tries hundreds of times before it gives up.

d. There could be a bug in the "development and build" cycles, whereby the developers are developing with one version of .NET Framework but the "builders" are then building and releasing an AC Client version that is built with some other .NET Framework.

Honestly, only the AC people can check out these possibilities.

(e). But I am SURE that if AC is supposed to be shipping .NET Framework 4.0 with each release of the AC Client, I am SURE that there is a bug there! I say this because, as I stated before, when I install the AC Client, the .NET Framework 4.0 does not magically appear on my system! Their installer might be installing it in the "wrong" place. They might be installing it, but not installing it with the proper registry keys. The fact is that 4.0 does NOT show up with 3.5 and all the frameworks in the Windows Registry.

In order to determine if my AC Client will use .NET Framework 4.0 if it is installed (by me), I might have to resort to the one thing that I did not want to try:
I might DELETE all the other versions of .NET Framework that exist on my system, and leave only .NET Framework 4.0 there. Then, I can try to run the AC Client one more time, just to see what happens.

(f). What I am getting at is that there is some possibility that for every client machine that is suffering from a very slow paint for Prescription Writer, the following is true: They downloaded and installed AC Client 6.x (even 5.1.9), and the installer noticed that .NET Framework 4.0 was not yet on their system. So, the installer then "tried" to install .NET Framework 4.0 ... and it failed! If the AC Client is now only designed to "run properly with .NET Framework 4.0", then each such client machine on which 4.0 was not correctly installed might (might!) have the slowness problem.

If others who are experience "really dramatic" slowness (not 2 or 3 seconds) want to check if they have .NET Framework 4.0 installed, that might help to answer this question. Nevertheless, I guess I will have to muster the courage to DELETE all other versions of .NET Framework, and see what happens.

Greg (MaxJammer)

I have to agree with Greg, I also have noticed that the version 6 AC installer did NOT install .NET Framework 4.0 on my XP computers. This was reported back in early August.

Thanks for that information. I apologize that I have not yet searched the forums, which I should have done, in order to avoid duplicating information that was reported previously.

Geez, for all I know, the entire .NET Framework issue itself has been dealt with ad nauseam! I hope not. I hope that I am not leading anyone down an old track that leads to nowhere.

Greg (MaxJammer)

Greg,

I don't think that anyone did much more than notice that 4.0 was not being installed on XP machines. We all downloaded .NET Framework 4.0 from Microsoft directly and installed it, but it didn't make a difference for most. I am sure that you are the first to raise the issue of what version of .NET that AC version 6 is trying to use. And also went the extra step of getting AC tech support involved.

Let us know if it helps to uninstall earlier versions of .NET, if you take that step.

I most definitely will. I should be able to test this out in the next three days, Saturday at the latest.

Greg (MaxJammer)

John,

Thanks for pointing me to the link where the .NET Framework was previously discussed as being a (or "the") possible culprit. http://amazingcharts.com/ub/ubbthreads.php/topics/33489/Greased_lightning_V_6_0_9#Post33489

After reading all the posts there, I became concerned that some are coming to the conclusion that there are "multiple fixes" to the slowness problem. I can only say that if there are multiple fixes, then I would bet that there are multiple problems, and that one person's fix for their machine won't work as the correct fix for someone else's machine(s).

I already know something quite definitive regarding the under-the-hood source of the problem on ALL of my XP machines (every one of them), and that is what I mentioned at the start: When I ran a packet analyzer (Wireshark) to examine what kind of communications were going on between client and server while the screen was being drawn slower than paint can dry, I saw TOO MANY, just way too many SMB requests spewing out of the client. And this phenomenon could be seen even after the screen was completely painted. After it settles down, if I so much as move the mouse over certain graphical regions of the window content, I see the same bunch of packets spewing across again, and the screen slowly repaints itself again, and I think that this was all due to one simple thing: When I moved the mouse over some particular region, AC wanted to show me a "balloon" at that pixel position. So, even to just draw that balloon, the entire screen had to be repainted, and this need then caused thousands of packets to spew over to the Server.

For anyone who has the means of doing so, it would be cool if you could try the same thing (running a packet analyzer) on one of your "slow" clients right after you click the menu item to show the Rx screen.

Of course there might be various sources for the "slowness" problem, given that different people have posted different solutions that apparently worked for them. But for me, for right now, I am going to assume that all this SMB packet spewing IS the source of MY problem, and possibly the source of the problem for many other people, and that there is really only one legitimate fix: To stop the spewing.

That is the road down which I will continue to travel until something stops me dead in my tracks.

And it would be much to my benefit to know if anyone else sees that their XML file on the server (I believe it's either C:\AmazingCharts.xml or C:\Amazing Charts.xml) is corrupted.
The easiest to way to see the corruption is in a DOS window (a DOS prompt). Just use the "type" command to print the file to the screen. If you see three weird looking characters at the very start of the file, then you will know that you probably have the same problem that I have.

WARNING: Opening that XML file in a text editor gives no conclusive results. Even if the binary characters are there, you will most likely NOT see them in the text editor window. If you have a Linux box or if you have any Unix tools on your Windows machine, you can always use the trusted "Octal Dump" program that has been on Unix since Day One. Just do "od -c <filename>", where <filename> is the precise name of the AmazingCharts.xml file. Or transfer the XML file over to your Unix/Linux box and run the "od -c <filename>" command there.

As I said, the "corruption" always occurs in the first three characters. I even think that they are always identical. I believe that they are always the following, which I have displayed in their various formats (base 10, octal, and hexadecimal)
Decimal: 239 187 191
Octal: 357 273 277
Hex: EF BB BF
Decimal nibbles: [14 15] [11 11] [11 15]

I will try to verify that my claim is true that they are always the same. If so, then this should give a HUGE leg-up for the AC developers in finding the source of the corruption issue.

Well, I will look into this as deeply as I can in the next few days, and of course if I find anything at all interesting and/or promising, I will post it immediately.

Greg (MaxJammer)

I would like to chime in here. In our practice we have the following:

Amazing Charts is a 3.2 Gigabyte Database
50 Gig of Imported Items.
16000 patient records

Server
Windows Server 2003 R2 Service Pack 2 (32 Bit)
DELL 2900 Dual Core Intel Quad processor (3 yeards old)
4 Gigabytes of memory.
146 Gig 10K RPM Raid 1 (Mirrored Hardisks)
Gig Network Cards (Active on Gig Port)

Desktop
Windows 7 (32 Bit)
Dell Optiplex 780 Intel Dual Core Processor (4 Months Old)
4 Gig of Memory
Gig network Card

We are stiil having the same issues after the 6.10 upgrade. One consideration has to be moving away from MYSQL to SQL 2008 and a Web based client.

We have done all of the hard stuff to ensure we get goog performance.

Gene,

I think you must have angered the eRx gods.

Bert,

Can they be appeased by bringing them a shrubbery?

This morning has had some of the slowest screen painting since early August, both hard wired and i5 wireless laptop.

Gene

No, they hate shrubbery. And, this is further confirmation that they slow Rx opening strikes everyone no matter their WEI score.

Ferdinand, thanks for pointing that out.
If you can do so, definitely download Wireshark from the web and just make sure that it's running (tracing packets) before you click on the button that brings up the Medications list or the Rx Writer.

What I just wrote is misleading in the sense that you know already how to set things up for tracing packets after Wireshark starts up. Although it is extremely easy after you do it once, the problem is that it can seem very mysterious as to what to do the first time.

If I get a chance, I will try to compose a very short tutorial on:
1. Where one can download Wireshark
2. What settings you need to establish (very few) in order to get it running.
3. What "filter" you should establish so that you don't have to view ALL packets, but rather only those packets that pertain to your client's communication with the Windows Server.

One of the reasons why it's important for me to encourage others to trace the communications using a packet tracer is very simple: You "slowness" issues might not be caused by the same anomaly. Offhand, I would have to suspect that Ferdinand's problems are NOT the same as mine. I only say this because our Windows 7 boxes have NO problems whatsoever, and yet Ferdinand's Windows 7 boxes DO experience a slowness problem.

So, it's important that other people attempt to trace the packets, in order to see if, right after clicking to get the Rx Writer or Meds List, you see thousands of packets flying by between your machine and the Windows Server.

Another possibility (if you want to trace the packets) might be to use wireshark and to look for a "quick tutorial" on the web, maybe even on YouTube. But I will try to find the time to write something up.

Greg (MaxJammer)

I can remember the first ACUC in Branson. Jon was addressing the issue of the CCHIT standards. A paraphrase of what he said was, "I can continue to develop AC into an even better EMR, or I can build a CCHITY (pronouned shity) one." The room leaned in favor of what we have.

I appreciate Jon's response to this post also.

I still believe we have a very high quality product for a reasonable price. AC has dramatically improved my practice. Jon had no realistic choice but to join the MU rat race. Now, appropriately, he has redirected his efforts to improving what we have and is holding off on the next phase. Bravo, Jon.

Exactly how I feel.

Hi all,

Seems like this fits best in this thread. AS background, have been using AC for 3+ years. Upgraded to vers 6.09 2 weeks ago and have experienced the slow script writer from day 1. Got help from support on day 2, who told me to turn off graphics accelerator, etc.

After I read this thread and Jon's post, that in his estimation the slowing problem was significantly affected only 10% of users, I decided to let Tech Support know I was one of them.

Here's the conversation. i was satisfied. Note the statement made that "we plan to have a fix (for the slowing problem) in the next month". I do think they're working on it, simply because Jon seems to have been a straight shooter for the most part and I trust him. If anyone has any advice about the second problem I bring up - that of codifying meds and the problem with matching them to incoming refills - I'd love some advice.
Thanks, Jim


Text of my Online Tech Support this morning:

James Theis:
Slow prescription writer. I know that YOU know it's a problem - I read Jon Bertman's response on the user board last week. I just wanted to put in my $0.02 as well. I suspect this is a UNIVERSAL problem, and not just affecting 10% of users as Jon suggested. Probably only 10% of us took the time to complain. It's REALLY bad. Other than turning off graphics accelerator, upgrading RAM and buying new computers, etc is there anything else?

Call accepted by Russell.

Russell:
good mornng
James Theis:
Hi there
Russell:
That is everything we know of as of now
Russell:
we are sorry for this inconvevience
James Theis:
Gotcha. I unserstand you're working on it and we appreciate that. I did have one question about e-prescibing... some meds listed in the database seem "approved" for eprescriv=bing while others are not, and cannot be matched to. Is there any way we can clean up our med database and get rid of all the duplicates and ONLY have meds listed that are green lighted for eprescirption?
Russell:
The only thing you can try is running the Database tuner
Russell:
and make sure all meds are codified when e-prescribing
James Theis:
No, that doesn't work unfortunately. If a medication shows "green" for e-prescribing then it should not be a matching problem later when we get an incoming request from pharmacy, right?
James Theis:
Is that waht "codified" means? can you explain exactly what that is?
Russell:
When you codify a med it will give you the exact dose and name
Russell:
this is rewuired for renewals
Russell:
required sorry
James Theis:
It looks like any medication that was entered manually ever in the past (even misspellings) will shows up in the prescription writer as a potential choice. There are numerous duplications of the same med and same dose. Hard to know which will be "green" until you actually try it out and as slow as the prescription writer is, it is exceedingly time-consuming to fix on the back end.
Russell:
I understand and we should have a fix for the speed in the upcoming month
James Theis:
OK. I still have this question though: WHen I try and prescribe a medication it will either show up as "approved for e-prescribing" (in green lettering) or "approved for e-prescribing if not a controlled substance" (in red letters). If I get the green statement, does THAT mean it is "codified" and will be OK for renewals?
Russell:
No that jsut makes sure the script is fileld out correctly
Russell:
with sig and dispense
Russell:
and amount of refills
James Theis:
Ok. So how do I avoid writing scripts that cannot be matched when I get a renewal request? Is it Vitamin D 50,000 units or Vit D 50000 units or Vitamin D 50,000 capsules or Vitamin D 50000 caps...... all of these are potential choices in my script writer but when I get a renewal request, it's not always matchable.
Russell:
right click on the med in the script writer list of current meds
Russell:
and codify
Russell:
that will give you the proper format
James Theis:
Oh ho. Ok, that's news to me.
James Theis:
So my nurse can do that when checking patients in, theoretically, or can only an MD level provider codify?
James Theis:
I have a lot of meds to fix
Russell:
As long as your nurse has permission to prescribe under you she can do uit
James Theis:
Mmmm. Alright that's helpful. Thank you. And the main reason for this chat was to log myself in as one of the 10%. And I'm really glad that you're working on it. I love AC other than this new script writing kablosion.
Russell:
Anything else I can help youwith today
James Theis:
No, thank you. Have a good one.
Russell:
You too and thank you

There's an update from Dr. Bertman on the boards today addressing some of the Amazing Charts issues that users are experiencing.

Marty, it seems to be a re-posting of Dr. B's post above.

Opps, you're right David.