System performance is one of the biggest issues that I have seen in implementing an EMR. It seems that almost immediately after “going live” with an EMR implementation a sudden swell of enthusiasm is stopped in its tracks due to system performance. From my experience there are 3 main reasons an EMR may experience performance problems along with many less prominent reasons.
The three main reasons for EMR performance issues are:
- Underpowered EMR database server – I am not sure why EMR vendors don’t beef up their minimal system requirements. The requirements are as they say “minimal” and will give you just that; “minimal” performance. I guess the truth is, the faster the server the more expensive it is. EMR vendors try to minimize the expense to implement their product. My recommendation is to push back on the EMR vendor and keep asking them if the recommended server will provide good performance today and for the next 3 years. My gut feeling is they will be very non-committal on the server lasting 3 years but may push you to a more powerful server to hedge their bet. It is cheaper to spend the money upfront then to rip and replace in 2 years. Additional memory and processors can significantly improve performance.
- Slow disks or not enough disks in the EMR database server – An EMR database server is constantly hit with read and write functions. A slow set of disks or not enough disks can cripple the server and produce awful results and significantly impact performance. Without getting into too many technical details it is safe to say that you should put as many disks that you can into your database server. You should also buy the fastest disks you can (15K RPM). A significant amount of fast disks can add considerable expense to a database server especially if you are looking at an external cage of fast disks but the performance gains can be significant.
- System Performance across a wide area network connection - the third main reason for EMR performance issues is trying to run an EMR application across a network connection between 2 or more locations (Wide Area Network – WAN). The amount of data that is sent back and forth between the EMR client and the EMR server can be significant. In an scenario where the clients and the server are in the same building (Local Area Network) there many not be any performance impact. That is because there is a lot of bandwidth between the clients and the server (usually 100Mbps and up to 1000Mbps). But when the client is in one location and the server is in another location (separate building) there could be significant delay and performance problems. A typical T-1 has the bandwidth of 1.5Mbps which is significantly slower than LAN connections (again 100Mbps up to 1000Mbps). Increased bandwidth between locations can help but the expense can be significant. A better solution is to implement Citrix or Terminal Services to run the EMR client at the remote locations. Citrix requires 1 or more additional servers located next to the EMR server (on the same network subnet) but requires very little bandwidth between offices. Citrix performance can be as good as running the EMR client and server in the same location. In almost every implementation we have done, Citrix provided the best performance running an EMR across a WAN. The additional expense is well worth it. One note: if your EMR is web based and utilizes a browser to run the program then the bandwidth requirements would be very minimal and not require Citrix.
The take away from this is that in order to ensure you have good performance from your EMR, it is essential to purchase the right EMR database server. In addition, a Citrix solution for remote offices/locations should be explored.

