When considering installing CAREWare the best practice is to ensure there is at least a test server installed along with the production server, where clinical data is stored. 

A test server for CAREWare can provide a number of benefits:

• It creates an environment users can access, that prevents damage or alterations to real medical information.
• It creates a training environment for new staff.
• It provides an opportunity to install and review new features.
• It allows for access to CAREWare features and functions in a newer build without having to upgrade the live server.
• It allows for a test run of the upgrade process which can identify a number of issues that may have to be addressed before upgrading production.
• It can be used to test server level settings or security changes that may affect the application in the live environment.

As long as the test server is installed in the same way as production and that test server uses a copy of the data from the production server, users should be able to replicate any changes made in the test server on production. Any issues that arise on the test server could be expected to arise in the production server, should CAREWare be upgraded.

In order to create a test server for CAREWare, CAREWare should be installed on a separate, however similar server, as the production server. Ideally the OS and the SQL instance should be the same. Although the versions of Windows software could also be tested on the test server to see how upgrading the OS or upgrading the database may affect the application as well.

Here are some things to consider when installing CAREWare on a test server.

In order to complete the installation process for a test server, the general practice involves the same steps that are required for migrating CAREWare to a new server, which are explained here. The general idea is that a backup of the production database is going to be created, moved to the server used for testing, and then CAREWare is to be installed using that backup file.

There are a few things to establish prior to installing CAREWare on a test server:

• How are users going to connect to the test server? Does it need to be publicly facing like production or should access be restricted to local connections only?
• Is the test server going to have the same features enabled as production,  limited to simply a replication of the client level data, or further limited to a blank slate to test the application unchanged. Ideally a test server should include a real client table for a complete test, however some providers use the test server to test new set up options or features not used in production.
• Is the test server going to be limited to specific staff as opposed to all CAREWare staff.
• Is the test server going to allow data imports from inside the network or from external sources like Lab Corp or EPIC?
• Is there a requirement for a Single Sign On application for connections to apps in general, which means this needs to be configured for the test server independently from production?
• Do features need to be disabled in the test server due to network access or user level limits to access to the test server?

The Test Server connection:

Make sure the URL is unique enough that user can easily tell which server they are connecting to. If the URL starts with CAREWare for both and they have the URL’s saved in their browser, they may connect to the wrong one and accidentally make changes to the production server or enter client data in the test server.

Make sure the database connection string connecting the CAREWare Business Tier to the CAREWare database server is significantly different and ideally that both are different from the default settings. Those fields include the SQL Server Instance server address, database name, SQL Login, and the SQL login password.

Make sure that CAREWare server level features are installed and configured for the test server specifically. Examples include the CAREWare FHIR Interface, CAREWare HL7 Interface, SQL imports/exports, Single Sign On Applications, CAREWare API’s, etc. In order to preserve the configuration of the test server for those features, the cw_common_storage table may need to be archived and restored separately after the test server database is restored from a production backup. Here are instructions for managing that task.

Once these questions are resolved, the necessary features are enabled, and the test server is working, users now have access to an environment that can be reset, updated, or altered at any time without impacting users access to the CAREWare application. In cases where users need access to a report in CAREWare that was fixed in a newer build they can run those reports in the test environment given that the data set in production and the test server are the same. Users can also access changes to the CAREWare application, possibly months in advance of their normal upgrade timeline. This gives users an opportunity to test the new features, report how those new features affect their use of CAREWare to jProg, and they can train their staff on those features or develop user documentation in advance before users have access to those features. Having a test server has many benefits for the users, can reduce downtime for upgrading CAREWare, and can protect live patient data from changes in the application or errors that may arise from an upgrade.