eClinicalWorks IT Best Practices

BEST PRACTICES FOR IT An informational guide for maintenance of eCW servers (Rev. 3)

© eClinicalWorks, Westborough, MA. All Rights Reserved. Rev B, March 2008.

CONTENTS

Backup Procedures ____________________________________________ 4

About Backups ___________________________________________________________________ 4 Database Backup: Offline vs. Online _________________________________________ 4

Offline Backup ___________________________________________________________________ 4 Online Backup ___________________________________________________________________ 5

Backup Details__________________________________________________________ 5 What Should I Back Up? ___________________________________________________________ 5 Backing up FTP Files ______________________________________________________________ 6 Location of Files to be Backed Up ____________________________________________________ 6 Backup Restore and Data Verification _________________________________________________ 7 Other Backup Options _____________________________________________________________ 8 eCW-Managed Disaster Recovery ____________________________________________________ 8

Managing Disk Space on eClinicalWorks Servers _____________________ 9

Scheduled Tasks _____________________________________________ 10

Performance ________________________________________________ 11

Replication _____________________________________________________________________ 11 Clustering of the Servers __________________________________________________________ 12 Load Balancing__________________________________________________________________ 13

Auto Upgrades (APU) Functionality ______________________________ 14

Data Corruption _____________________________________________ 15

Corruption Prevention ____________________________________________________________ 15 Preventing Data Loss after Corruption _______________________________________________ 16

Firewalls, Antivirus, and DLL Registration Issues____________________ 17

Firewalls and Antivirus Issues ______________________________________________________ 17 Dll Registration Issues ____________________________________________________________ 17

Server Crash and Reinstall _____________________________________ 18

2

Server Crash Event_______________________________________________________________ 18 Reinstall _______________________________________________________________________ 18

Linux Servers _______________________________________________ 19

Server Maintenance __________________________________________ 20

Maintaining the Server____________________________________________________________ 20 Optimizing the Database __________________________________________________________ 20

Frequently Asked Questions ____________________________________ 22

Appendix A – Hardware Specifications ____________________________ 24

Appendix B – MySQL Parameters ________________________________ 25

Appendix C - TCP-IP Parameters/Tomcat Memory Settings ____________ 28

TCP-IP parameters_______________________________________________________________ 28 Tomcat Memory Settings __________________________________________________________ 28

Appendix D – eCW Architecture _________________________________ 30

eCW Architecture ______________________________________________________ 30 Client Server Architecture _________________________________________________________ 30 ASP Architecture_________________________________________________________________ 32

3

Backup Procedures

About Backups It is critical that every practice save a backup their data at least once per day. Each practice may have their own preferred procedure for backing up the data, such as tape, hard disk, or DVD backup options. eCW recommends the f to minimize the impact in the case of data loss or hard disk/server crash.

During the initial installation of the eCW software for all customers, a backup schedule task is created to backup the MySQL database; however this backup should not be relied upon for true data backup.

The possibility exists that this scheduled backup data could become corrupted or may not be retrievable. Also, this scheduled task may stop functioning if the customer changed the password for the administrator login needed to create the backup task.

Creating data backups is a crucial practice responsibility. Clients are advised to read this document thoroughly and save backups of the files noted in the section titled What Should I Back Up?

Note: Do not back up the data on to the hard disk of your server. If for any reason the server crashes or the hard disk fails, the data and all saved backups on the disk will be lost.

Backups should always be saved to an external hard disk or a tape drive.

When in doubt, contact eClinicalWorks Support for details regarding data backup.

Note: Keep the copy of the backup for at least 15 - 30 days before you choose to overwrite the tapes.

Database Backup: Offline vs. Online One important thing to determine when it comes to backup of data is to make a choice of offline backup versus online backup.

Offline Backup eCW recommends the safest way to save a backup of a database is to take the MySQL service offline and make a copy of the database to a tape or network location.

Backup Procedures 4

However, if the practice cannot afford the downtime involved with backing up offline, then backing up online would be a suitable solution.

Online Backup MySQL provides different options to make an online copy (sometimes referred to as a "hot copy") of the database without taking the MySQL service offline. The options include mysqldump, mysqlsnapshot, or similar MySQL backup tools. eCW has an option to create a mysqldump file and can retain a copy of this file for backup.

Note: Do not perform a backup on a live database. This could result in corruption of the database tables. A tape backup of the mobiledoc folder should be run only when the MySQL Service is stopped.

The alternative is to use the mysqlsnapshot or mysqldump to create the copy of the database to a separate folder and then back this data to tape.

Backup Details

What Should I Back Up? This is a common question asked by nearly all new practices. The following folders are crucial and must be backed up.

Database – All patient records and data entered into eCW are stored here

FTP documents – Documents that are scanned and attached to patients

Tomcat files – Static data that only changes when an upgrade is performed

IMPORTANT! The folders listed above can reside on different servers or different drives with different names, depending on the setup of the servers. Be sure to locate and back up the proper files.

If you have any questions about these files contact eClinicalWorks Support.

Backup Procedures 5

Backing up FTP Files The file size of the FTP folder can be extremely large depending upon the number of documents attached to the patients and the number of documents scanned by the practice. eCW recommends saving a copy of the FTP files on a daily basis.

Backup of the FTP folder must be incremental; only the modified files or new files added from the last full backup should be backed up. This will ensure a complete copy of the FTP documents without having to copy the repetitive data each time a backup of the FTP files is taken.

Location of Files to be Backed Up Everyone might have a different architecture, depending on the size of the facility and the requirements of the customer. The setup could be a single server where all these data is stored or there will be multiple servers where the data is distributed and stored.

If you have a single server which hosts MySQL, Tomcat, and FTP services, then the data that you need to backup is located on the same server under different folder names.

Typically eCW Client side files will be found in the following locations:

C:\program files\eClinicalWorks\

C:\ecw

For Data (Daily Backup) File Name:

D:\eClinicalWorks\mysql\data\mobiledoc

Description:

Mobiledoc is the name of the folder. This contains database files and can be stored with a different name.

Patient Documents (Incremental Backup) File Name:

D:\eClinicalWorks\ftp\mobiledoc

Description:

This folder contains the files that are scanned and/or attached to the

Backup Procedures 6

patient documents section from the eCW application, and can exist with a different name.

Tomcat Folders (Before and after an Upgrade) File Name:

D:\eClinicalWorks\Tomcat5\Webapps\mobileodc\jspWEB-INF

xslconf

Data in the Tomcat5 folder is static and is not changed unless there was an upgrade. eClinicalWorks recommends saving a backup of the Tomcat5 folder before an upgrade is performed and after the upgrade is complete.

The AutoUpgrade utility used for upgrades performs the automatic backup of the required files to be modified during the upgrade.

Perform the backup during off hours when eCW application is not being used. Please review the scheduled tasks on the server under Control Panel to determine when the MySQL service is offline on your server, and then schedule the backup to run during that interval.

Backup Restore and Data Verification eCW recommends monthly verification of the data that has been backed up to ensure data integrity. Restore verification should be done on a system other than the production servers. eClinicalWorks recommends the following process for data restore and verification:

1. You can restore the backup preferably to a different computer other than the server or to a temporary location on your server. Compare the size of the database that is restored with the original database and it is normally of the same size.

2. Compare the restored file size with the corresponding production files. There could be a minor or no difference in the file sizes depending on how current the restored backup is. When restoring and verifying immediately after the backup is complete, there should be no difference in the file size or modified date on the files.

3. Run Mysqlcheck with the –C option on the restored database.

For example:

Backup Procedures 7

mysqlcheck –c <<databasename>> -u<<dbuser>> -p<<dbpassword> >-P<<dbport>>

4. Mysqlcheck should return OK on each table giving an indication that MySQL is able to read those tables.

Note: Do not inadvertently restore the data to the original location from where you backed up. By doing so, the backup will overwrite the original data and there is the possibility of data loss.

Other Backup Options In a proactive approach to prevent accidental data loss, eCW has been deploying the use of binary logs. The binary logs keep a log of all data entered into the database in the binary log files. These logs can be used to restore your data incase of data loss.

In the event of a hard disk crash, the data cannot be restored from these files or any other backup files that eCW creates. We strongly recommend that the customers perform their own independent backups to an external backup source.

The binary logs generated can be used to build a slave database server (Database Replication) for the customers who are interested to invest in the slave database server. This slave server will serve as a backup server as well in case the data on the master server is corrupted or the master server crashes. (However this slave server will only provide the replication of the database and not the FTP files.)

eCW-Managed Disaster Recovery eClinicalWorks offers a backup service option for clients where the practice data is backed up offsite. This is a paid service offered by eCW. Contact the eCW Sales Department for more details.

Backup Procedures 8

Managing Disk Space on eClinicalWorks Servers Recommendations:

eClinicalWorks recommends that the server should have at least 3 GB of free disk space on the operating system drive. Less than 3 GB of free disk space on this drive may result into degradation in system performance.

eCW recommends having SAN (Storage Area Network) for large practices as this option provides the opportunity to allocate additional disk space as required. Smaller practices should refer to the hardware specifications in Appendix A – Hardware Specifications to calculate the approximate usage of hard disk depending on the number of providers, and then purchase their hardware accordingly.

eClinicalWorks recommends that the database/FTP servers should have at least 1 GB of free disk space on the data drive at all times. All drives on the server should be defragmented at regular intervals. The eClinicalWorks distribution folders contain files that are needed for the eClinicalWorks software to function and therefore should not be deleted.

However, the following files/folders should be cleaned periodically:

Managing Disk Space on eClinicalWorks Servers 9

Scheduled Tasks eCW employs the built-in Windows Schedules Task utility to set up tasks to backup the database, stop and start the services for the backup, as well as schedule the Auto Upgrade utility. The Auto Upgrade utility will check for any available version upgrades from the central Auto Upgrade server available at the eCW Data Center.

Typical scheduled tasks and their established server frequencies are displayed below:

Scheduled Tasks 10

Performance Performance of the application is a relative term; it may seem to some users that the application is responding slowly while others may not be experiencing any performance issues at all. It may also be performing slowly on some wireless computers while workstations connected to the Ethernet are working faster, all within the same practice.

eCW has taken several steps to achieve optimal performance of the application:

We continuously optimize queries programmatically to attain optimal performance

We index the tables in the database We point the reports to run from the reports server if available

Performance-optimizing steps for the practice to follow: eCW suggests running reports on a separate Reports server if it is

a large practice with a large number of users. Check the DSN entries for eClinicalWorks in ODBC settings and

make sure that the settings point to the Reports server (if available).

For smaller practices without a Reports server, eCW suggests running reports either at the end of the business day or during non-peak hours.

If wireless laptops or tablets are slow or freezing, check the wireless router or the network adapter on your computer. Problems in the wireless connection can also be associated with MTU size set on the network adapter.

To set the MTU size and other parameters after performing the tests, use a utility call TCP Optimizer. This free tool can be downloaded from the Internet.

Optimal MTU size for the adapters using wireless a, b, and g is 1500.

Replication MySQL has an option to replicate the data with one master database or multiple slave databases. This allows a practice to take a copy of

Performance 11

its database in real-time with out delay on a backup server. eCW makes use of this option to setup the slave MySQL on a different server to serve as a backup copy of the database, or this server can be used as a report server. This would allow all reports run on the database to be pointed to the slave server, thus reducing the load on the master database and improving the speed and performance of the application.

MySQL replication is real-time. The data written to the master database is replicated in real-time to the slave server, increasing the availability of database in case of disaster and thereby reducing the risk of data loss.

Normal backups are performed during the off hours and the backup data is available only for the previous night, but replication provides the option for the customers to have a real-time copy of their database.

Clustering of the Servers Replication is a way of retaining a duplicate set of data on the same or a different server, whereas clustering offers one way of reducing the downtime for customers. By setting up a cluster environment, customers will be reducing the downtime that they may face in the event their server(s) fails.

Clustering is typically set up for the database servers and the FTP/File server. Clustering is two or more servers of similar configuration setup mirrored with the original setup. This configuration is established so that if one server goes down, the mirrored server will take over the operations without manual intervention and with minimal or no downtime.

To describe in detail, eCW can setup two servers with MySQL service running on both servers and there will be a shared data drive where the database is stored. The data drive will be accessed by the active server. At any point, only one server will be active and functional while the other server is in the passive mode.

If there is a problem with the active server that causes failure, the passive server will take over and serve as the active database server without resulting in a longer downtime for the customer.

By using this architecture, eCW can reduce the downtime for customers by configuring the failover/clustering between the database servers. It is important to note that clustering alone is not an optimal solution without the replication segment. In the cluster

Performance 12

setup, the weak link is that it only contains one set of data. If the data retained while clustering is corrupted, there is a risk of downtime until the data is retrieved from the backup. By setting up replication of the database on to a slave server, eCW has the option to use the slave database in the event of a problem with the database on the master server.

Load Balancing There are multiple ways to set up load balancing; hardware load balancing, software load balancing or the built-in failover option available within the eCW application. This failover feature also acts as load balancer for the application servers. To use the load balancing feature, you will need to have multiple servers (i.e., two or more application servers which can act as the nodes).

What are the advantages of load balancers?

By having a load balancer, the amount of traffic on the application server(s) will be reduced. The application server is the location where the Tomcat is installed and the server(s) acts as web-server(s). With a load balancer, the traffic on these servers is evenly distributed automatically.

Note: Refer to the eCW Architecture section in Appendix D – eCW Architecture for the distinguishing details of Application servers, Database servers, and FTP/File servers.

Performance 13

Auto Upgrade (APU) Functionality Auto Upgrade is the automated process of upgrading the existing version of eCW on your server(s). Typically, there is a scheduled task running on the practice's servers to check for any new upgrades. When there is an upgrade available, the Practice Administrator gets the notification in the message section of eCW application.

During the upgrade, the database will be modified to add new tables that are delivered with the upgrade, and the Tomcat files will be modified with newer jsp and class files.

IMPORTANT! It is important to make a backup of these files.

The client side files that must be downloaded to all the clients in the practice will be stored on the FTP server. These files will be downloaded to all the workstations in the office when you log in to eCW application on each client.

Auto Upgrade (APU) is typically performed on the App Server (Tomcat Server). For practices with a single server, the upgrade is a one-click process provided all the parameters are set correctly. eCW periodically releases updates to ICD codes, CPT codes, Multum (Drug Database) upgrades, special patches, and fixes through this APU tool.

For practices that host multiple servers, it may be required to transfer all the data to one server and then perform an upgrade. eCW performs these upgrades if required, but they must be scheduled in advance.

Note: If the Practice has an APU server designated for upgrades, then the upgrades are performed on this APU server, or eCW will use one of their existing App servers for the upgrade process.

Upgrades on Linux servers must also be performed by eCW staff and scheduled in advance.

Prior to any upgrade, a backup of the database and the Tomcat files should be performed. The practice should make sure there is enough free disk space available on the servers. It is good practice to plan to perform these upgrades when you can reach eClinicalWorks Support in the event of a problem.

Auto Upgrade (APU) Functionality 14

Data Corruption The MySQL tables consist of .frm, .MYD, .MYI files, which hold the table structure, data, and the indexes respectively. As long as the .MYD file is not corrupted, eCW will typically be able to retrieve the data. The Index file can be recreated as long as a clean .frm file exists, and .frm files are not prone to corruption.

Data corruption can occur at any time to anyone. It is one of the inherent problems associated with the usage of any database storage engines. MySQL has built in utilities to repair the tables if there is corruption, and the process of retrieval of data is fairly simple in MySQL compared to any of the other database software.

Data corruption can occur if there is not enough free space on the hard disk to store the data, if there are problems with hard disk, if backups are performed while the database is in use, or if there is a unexpected Power Failure/Restart, etc. These are all reasons that may potentially cause corruption.

Corruption Prevention Although data corruption cannot be completely eliminated, there are steps that you can take to minimize the possibility of corruption:

1. Backup operations on the database should not be done while the database is in use: Offline backup is recommended. Refer to the section titled

Backup Procedures. If you prefer to make an online backup, the scripts that you

run should include performing a read lock on the tables before the backup of that table is performed. This is required to ensure that data is not being written to the table at the same time the back up is running.

2. Maximize the amount of free space on the hard disk where the database is stored: When a check is run on MySQL, or when optimization of the

tables is done as part of the database maintenance, these tasks create temporary tables and recreate the tables back after sorting the rows.

For these tasks to complete with out problem, twice the amount of free space as the size of the database will be needed.

Data Corruption 15

3. Hard disks should be periodically defragmented and checked for errors. Do not run the Defragmentation Utilities as a service to

continuously monitor the hard disks; this may result in performance issues.

Defragmentation tools should be run at night and off hours. We should make sure that there are no backups or database

optimization tasks running during this period. Practice can choose any Defragmentation utility of their choice

or they can use the default utility provided in the Windows OS.

Note: There should not be any task with mysqlcheck –r option scheduled to run on the database from scheduled tasks, as this might result in the corruption of the database and loss of the data. If you find any such task eCW recommends deleting that task immediately.

Preventing Data Loss after Corruption In the event of corruption, the possibility of data loss can be reduced by following some precautionary steps:

Stop the MySQL Service and instruct the users to stop using eCW application when it has been determined that one or more tables are corrupted. This will help eCW Staff retrieve the data from the tables without further corruption.

Take a backup of the tables before performing the repair operations on the corrupt table.

Having binary logs setup will greatly increase the chances of retrieval of data in case we cannot retrieve the data from the corrupted table.

Data Corruption 16

Firewalls, Antivirus, and DLL Registration Issues

Firewalls and Antivirus Issues If the practice has any type of firewall, either Windows firewall or firewalls from a third-party vendor, be sure to create exceptions for eClinicalWorks Applications to prevent possible blockage of eCW.

At times the practice could be notified that files downloaded from eClinicalWorks are infected by a virus. Generally this is a case of the practice's antivirus software falsely identifying a virus. If you are notified about a virus, be sure to scan the files with secondary antivirus software before reporting it to eCW. eCW recommends using Norton or McAfee for verification.

If eClinicalWorks is not functioning on one computer yet functioning fine from the other computers, there may be a firewall or antivirus that is blocking eClinicalWorks. System slowdown may occur if antivirus software is scanning the eCW application. It is recommended that you exclude the eCW folders from real-time virus scanning.

Dll Registration Issues When the eCW application is installed on a workstation, it stores the .dll and .ocx files in to the following locations:

c:/windows/system32

c:/program files/eClinicalworks

These .dll and .ocx files must be registered for eClinicalWorks to function properly. Copy and pasting the eCW folders will not work if you have to install eCW on to a new workstation. The setup file has to run for all of the registry entries to be made correctly.

Some software applications use the same .dll and .ocx files that eClinicalWorks uses. If these software applications are installed on the same computer where the eClinicalWorks application is installed, it may create conflicts and cause eCW to stop working.

Firewalls, Antivirus, and DLL Registration Issues 17

Server Crash and Reinstall

Server Crash Event While we do not want to be in a situation where the hard disk has crashed and we have to retrieve all the data from it, you should be prepared if this ever happens.

While discussing how to prevent a hard disk crash is out of the scope of this document, it is important to prepare for the possibility of a crash. It is also important to now the options for recovering the data if possible.

The following steps must be followed in the event of a data crash:

Do not reinstall the operating system on the crashed hard disk before retrieving all the data.

Make sure that the data that was retrieved is actually valid. There is a possibility that the retrieved data is not in a readable format.

Contact eClinicalWorks Support immediately after the hard disk crash so that the support techs can take precautions to ensure that they can retrieve as much data as possible. Since a crash can result in corruption of the database, the corrupted tables must be repaired to restore the data completely.

There are rare occasions where data retrieval companies can retrieve the database files even if the operating system is reinstalled or the hard disk was formatted.

Reinstall If the RAID controller has failed or hard disk has crashed, it will generally result in corruption of the operating system files and all the files on the hard disk. Once the data have been retrieved from the corrupted disk, and copy it to a different disk and reinstall the operating system. eClinicalWorks strongly recommends that you notify us as soon as you experience a failure so we can schedule the resources to help with server reinstall.

If your practice chooses to purchase a different server, be sure the server that meets the latest hardware specifications found in the section titled Appendix A – Hardware Specifications.

Server Crash and Reinstall 18

Linux Servers Practices that use Linux Servers for database or applications must follow all precautions routinely performed to maintain the server.

A backup of the database and FTP files must be taken. The default locations of the eClinicalWorks files that must be backed up are:

Database Location:

/var/lib/mysql/mobiledoc

FTP Documents Location:

/usr/local/eClinicalWorks/doctor

Tomcat Location:

/usr/local/eClinicalWorks/tomcat5/webapps/mobiledoc/jspWEB-INF

xslconf

FTP files are owned by the user “doctor” Tomcat5 service runs as “root” Database should be owned by MySQL Linux firewall should be turned off

Linux Servers 19

Server Maintenance

Maintaining the Server eClinicalWorks recommends that the following steps be performed to make sure that you are properly maintaining the eCW servers.

Make sure all servers have enough free space. We can delete the log files and backup files noted in the section

titled Managing Disk Space on eClinicalWorks Servers. Restart the Tomcat and MySQL services is recommended every

night and restart the servers once weekly.

Note: This is recommended for practices that do not operate 24/7.

For larger hospitals and practices that operate 24/7, it is recommended that they restart the servers at least once a week.

Do not enable routing, remote services, DNS, or Domain Controller services on your eCW servers as stated in the Implementation Guide (formally the Welcome Pak) as this may result in performance degradation and responsiveness of the server.

Refer to Appendix B – MySQL Parameters and Appendix C - TCP-IP Parameters/Tomcat Memory Settings to ensure the server has been configured with the proper parameters for optimal performance.

Please ensure your backups are running on a regular basis. Verify the integrity of the backups that have occurred to be certain they are usable if needed.

Keep the copy of the backup for at least 15 to 30 days. As a part of the database maintenance, your database should be

optimized periodically (quarterly).

Optimizing the Database Follow the steps below to successfully perform the optimization of the database.

1. Take a backup of the mobiledoc database from:

mysql/data folder

2. Browse to:

<Install Drive>:/eClinicalWorks/mysql/bin/

Server Maintenance 20

3. Double click on the batch file:

mysql_optimize.bat

4. Wait for the command window to close. This may take a few minutes depending on the size of the database.

Server Maintenance 21

Frequently Asked Questions Q: How do I choose the correct Server/Workstation?

A: If you decide to purchase a new server, refer to Appendix A – Hardware Specifications or contact eCW Support to get the latest hardware requirements.

Q: How do I set up the servers?

A: Based on the number of users and load on the servers, eCW recommends architectures for practices. Contact the eClinicalWorks Support Team for details on server setup.

Typically eCW does not recommend having any type of services such as domain controller, DNS, remote and routing services running on the servers.

Q: What are the space and hardware requirements on servers?

A: Please refer to Appendix A – Hardware Specifications.

Q: What kind of workstations can I purchase if I need eCW on additional computers?

A: Make sure that you purchase the workstations according to the hardware specifications in Appendix A – Hardware Specifications.

Q: What are the risks involved in adding new software?

A: Adding new software onto workstations where eCW is installed may result in conflicts and it is possible that eCW could stop functioning properly. If issues arise, remove the software that is causing the conflict.

Q: Can we install eCW on Apple® Computers?

A: Yes. It is required that the boot-camp software be installed on the Apple computer first, and then Windows Vista or Windows XP software is installed on top of your Apple OS.

Frequently Asked Questions 22

Q: Can eCW be installed on Vista Machines?

A: Yes. eCW supports Vista Business and Vista Enterprise editions at this time.

Q: Are server re-installs billable to the practice?

A: Yes. Please refer to your Labor Charge Sheet.

Q: Can eCW be installed on my old Celeron machines?

A: Yes. However, eCW does not recommend installing on computers with Celeron Processors as they may cause performance issues.

Q: What are the ports that need to be open on my server for eCW to function properly?

A: Normally Tomcat runs on Port 8080 and MySQL runs on Port 4928. These ports should not be open to the Internet; however they should be open internally in the network.

Note: Ports can be different at some practices; please verify with eCW Support if you are unsure.

Q: What ports are needed to be open for VNC connections?

A: eCW uses vnc1.eclinicalworks.com and vnc2.eclinicalworks.com to receive connections through VNC. Ports range from 9000 to 9500 (these ranges can increase so please check with eCW Support if you are unable to provide connections).

Note: These ranges can increase so please check with eCW Support if you are unable to provide connections.

Frequently Asked Questions 23

Appendix A – Hardware Specifications The eCW hardware specifications are updated frequently; therefore the most current version can be located on the eCW Support Portal at:

http://support.eclinicalworks.com/custcareportal/jsp/docdownload.jsp?filename=HardwareRequirements.pdf&folder=implementation

Appendix A – Hardware Specifications 24




Appendix B – MySQL Parameters MySQL Optimization Parameters: These parameters need to be set in the configuration file of the MySQL. This file is normally located in the c:\windows\my.ini or it can be at an alternate location you can find its location if you open the properties of the MySQL service under services.msc.

MySQL Mandatory Fields [mysqld] # These are mandatory fields. skip-locking skip-innodb skip-bdb lower_case_table_names = 1 query_cache_type = 1 tmp_table_size=1M wait_timeout=30 interactive_timeout=30 table_cache=1024 query_cache_limit=1M # Number of CPU's*2 for thread_concurrency The following parameter will change based on the number of CPUs. Some times the hyper threading is enabled which makes single processor look like dual, so Make sure that this is done properly. For single processor -> 2 Dual -> 4 Quad -> 8 thread_concurrency = number of CPU's*2 for thread_concurrency.

Memory = 1GB Memory = 1GB

Dedicated MySQL Server MySQL + Tomcat on same server (tomcat memory= 64Mb expandable to 128Mb)

key_buffer = 256M query_cache_size=128M max_allowed_packet = 1M sort_buffer_size = 512K read_buffer_size = 512K myisam_sort_buffer_size = 128M thread_cache_size=40

key_buffer = 256M query_cache_size=64M max_allowed_packet = 1M sort_buffer_size = 512K read_buffer_size = 512K myisam_sort_buffer_size = 128M thread_cache_size=40

Appendix B – MySQL Parameters 25

max_connections=100 max_tmp_tables=64

max_connections=100 max_tmp_tables=32


Dedicated MySQL Server MySQL + Tomcat on same server (tomcat memory= 128Mb expandable to 256Mb)

key_buffer = 512M query_cache_size=128M max_allowed_packet = 1M sort_buffer_size = 512K read_buffer_size = 512K myisam_sort_buffer_size = 256M tmp_table_size = 1M thread_cache_size=125 max_connections=150 max_tmp_tables=128

key_buffer = 512M query_cache_size=128M max_allowed_packet = 1M sort_buffer_size = 512K read_buffer_size = 512K myisam_sort_buffer_size = 256M tmp_table_size = 1M thread_cache_size=125 max_connections=150 max_tmp_tables=128


Dedicated MySQL Server MySQL + Tomcat on same server (tomcat memory= 512Mb)

key_buffer = 1024M query_cache_size = 128M max_allowed_packet = 1M sort_buffer_size = 512K read_buffer_size = 512K myisam_sort_buffer_size = 512M tmp_table_size = 1M thread_cache_size=250 max_connections=300 max_tmp_tables=150

key_buffer = 1024M query_cache_size = 128M max_allowed_packet = 1M sort_buffer_size = 512K read_buffer_size = 512K myisam_sort_buffer_size = 512M tmp_table_size = 1M thread_cache_size=250 max_connections=300 max_tmp_tables=150

Memory > 4GB Memory > 4GB Dedicated MySQL Server MySQL + Tomcat on same server Same as the settings for 4GB. DO NOT increase the parameters beyond the settings for 4GB as 4GB is the maximum memory a process running on a 32-bit system can access.

Same as the settings for 4GB. DO NOT increase the parameters beyond the settings for 4GB as 4GB is the maximum memory a process running on


a 32 bit system can access.

Notes:

Use the settings specified for (MySQL + Tomcat) if Tomcat, MySQL, and FTP, all three services are running on the same server.

Installing MySQL and FTP on the same server is not recommended (for > 50 users).


Appendix C - TCP-IP Parameters/Tomcat Memory Settings

TCP-IP parameters Copy the following content into a text file and name it as TCP.reg and you can double click on this file to merge these entries into the registry of the server. These TCP-IP parameters should be run on all the eCW servers.( APP server, DB Server, FTP server, Reports server etc.,)

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]

"Tcp1323Opts"=dword:00000003

"TcpWindowSize"=dword:00040000

"GlobalMaxTcpWindowSize"=dword:00040000

"TcpTimedWaitDelay"=dword:1e

"MaxUserPort"=dword:4e20

"KeepAliveTime"=dword:0000ea60

"KeepAliveInterval"=dword:000003e8

"TcpMaxDataRetransmissions"=dword:0000000a

Tomcat Memory Settings You can increase or adjust the amount of memory that can be allotted for Tomcat to use; typically eCW recommends allocating 512MB to 1024MB of RAM for Tomcat.

1. Browse to:

<install drive>:/eClinicalWorks/tomcat5/bin/

2. Open the following file:

tomcat5w.exe

3. Set the memory for Tomcat5 here as displayed below:

Appendix C - TCP-IP Parameters/Tomcat Memory Settings 28

Appendix C - TCP-IP Parameters/Tomcat Memory Settings 29

Appendix D – eCW Architecture

eCW Architecture eClinicalWorks has two principal types of deployments:

Client Server architecture ASP architecture

Client Server Architecture The three major components of eCW are the Tomcat, MySQL, and FTP services. These services can all run on one individual server or can be split in between multiple servers.

Depending on the additional requirements, you may require the following server needs:

A Fax server from where the faxes are sent and received. A Reports server where a slave MySQL is setup and the practice

can run all reports from this server without overloading the primary database server.

eHX (Electronic Health Exchange) server if you have opted for this feature.

Test Server Terminal Server Citrix Server

Appendix D – eCW Architecture 30

Typical Client Server Architecture:


ASP Architecture ASP architecture differs from Client Server architecture because ASP utilizes servers that are located at the eCW data centers. All computers at the practice connect to these servers through a VPN tunnel that is established between the doctor’s office and the ASP data center.

Typical ASP Architecture:


eClinicalWorks IT Best Practices

Documents

Transcript of eClinicalWorks IT Best Practices