Overview

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.

Note: This user guide is a brief explanation for installing a CAREWare Test Server. For a more detailed explanation for setting up a CAREWare Test Server, click here.

Benefits of a CAREWare Test Server

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 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 uses a copy of the data from the production server, users should be able to replicate on production any changes made on the test server. Any issues that arise on the test server could be expected to arise on the production server should CAREWare be upgraded.

Create and Configure a Test Server

In order to create a test server for CAREWare, CAREWare should be installed on a separate, but similar, server as the production server. Ideally, the OS and the SQL instance should be the same. 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.

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 created, moved to the server used for testing, and then CAREWare is installed using that backup file.

Questions to Answer Before Installation

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, be limited to a replication of the client-level data, or be further limited to a blank slate to test the unchanged application? Ideally, a test server should include a real client table for a complete test; however, some providers use the test server to test new setup 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 LabCorp or Epic?

•  Is there a requirement for a Single Sign-On application for connections to apps in general? If so, 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 on access to the test server?

The Test Server Connection

Make sure the URL is unique enough that a user can easily tell which server they are connecting to. If the URL starts with CAREWare for both servers and users have the URLs saved in their browsers, they may connect to the wrong server 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. Ideally, both should be different from the default settings. Those fields include the SQL Server instance server address, database name, SQL login, and SQL login password.

Make sure that CAREWare server-level features are installed and configured specifically for the test server. Examples include the CAREWare FHIR Interface, CAREWare HL7 Interface, SQL imports/exports, Single Sign-On Applications, CAREWare APIs, 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.

After the Test Server Is Working

Once these questions are resolved, the necessary features are enabled, and the test server is working, users have access to an environment that can be reset, updated, or altered at any time without affecting users' access to the CAREWare application. In cases where users need access to a CAREWare report 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, 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 users, can reduce downtime for upgrading CAREWare, and can protect live patient data from application changes or errors that may arise from an upgrade.

Related References