NOTE: A FEW UPDATES HAVE BEEN MADE TO THIS MANUAL. FOR THE MOST RECENT VERSION, DOWNLOAD THE PDF FILE.

RW CAREWare is undergoing a major transformation. The current version of CAREWare is built in Microsoft Access 2000 and runs as a stand-alone application (on one PC) or on a local area network or LAN (a handful of users in one building, for example).  In version 4.0, CAREWare will be re-created in an entirely different format called .NET (dotNet) and will be designed to run on a wide area network or WAN or over the internet, although it will not run through your browser (such as Internet Explorer or Netscape, see below).  You will still be able to run version 4.0 on a single, standalone PC, as many users do now in version 3.x.  In addition, there will be a “store and forward” option that will allow providers to remain disconnected from the network but send data in batch to the central administrator on a regular basis.

But the major new feature of version 4.0 of CAREWare is that it will run on a wide area network or over the internet, thus enabling the real-time connection of providers within a grantee.  Such a connection will clearly facilitate the sharing of important treatment and service data, allow for referral messages to be sent directly to network provider participants, and eliminate the need to re-register clients each time they enroll at a new provider on the network.  For the grantee, the centralized database will be a rich source of unduplicated client information for immediate analyses of the quality of care, needs assessment, and the rapid creation of aggregate reports such as the CADR.

Providers that currently run CAREWare version 3.x on a LAN and who experience data corruption problems will also benefit from version 4.0, which will be infinitely more stable.  Part of this increased stability is due to the fact that the database in Version 4.0 will be built in Microsoft SQL server and not in MS Access.  SQL Server is designed to serve many simultaneous users. 

Changes introduced by Version 4.0 obviously affect the HIV data collection world a great deal, introducing a number of data sharing and reporting features that will be of benefit to clients as well as the many reporting and quality management needs of providers and grantees.  However, because sensitive, personally identifiable health information will now be stored centrally on one computer or server - likely to be managed by the grantee - a number of new security and confidentiality issues also arise that must be managed properly and carefully.   Below we discuss briefly the implications of HIPAA for the network version of CAREWare.

Main Features / Requirements

CAREWare version 4.0 will look and “feel” like the current version, but the new data sharing arrangement will, as noted, alter things considerably, and will likely require greater coordination and communication among participating providers; Grantees’ roles will expand as they will now also serve as central database administrators.

Sharing Data and Granting Access Rights

First, let’s review how data will be shared in the new version, and how access rights to the system and to specific data will be granted and administered.  As an example, we’ll consider an (imaginary) Title II grantee that funds 30 providers across their state; these providers offer the full range of services funded by the CARE Act.  In the part of the state with a higher prevalence of people living with HIV, there are multiple primary care providers, substance abuse and mental health agencies funded by the CARE Act.  There are also likely a handful of providers in this state that do not want to join the network, perhaps because they already have a well-established health information system in their hospital or clinic. 

Grantee and Provider Domains: Who does what

In this section we refer to two domains: the central domain, typically the grantee - and the provider domain.  In conjunction with providers, the grantee administrator will create users ids and passwords at the provider level, but it is the grantee administrator that ultimately has the authority to create (and revoke) user IDs, and expand or limit how an individual user at a provider may access data.

Providers will designate their own administrator; the provider administrator will have full read/write access to the data entered at their agency only while the grantee administrator will manage the full central database contributed to by all providers on the network.  The provider administrator will, in turn, assign users and determine access rights at their own agency, but all rights at the provider level are ultimately controlled by the grantee administrator.

In version 4.0, there will be a great deal of flexibility in creating user accounts.  Certain users may have full read/write access to their agencies’ data, while access rights of other users may be more restricted to entering or viewing only certain parts of the data such as demographic and service screens or case notes only. (Note that read access means that you can only view the data and cannot edit it; write access means that you can change or edit the data.)

Grantees will obviously play a number of important roles overseeing the daily technical functioning of the network; they will also be charged with overseeing the proper use of the system, examining audit trails of how the system is being used and who is using it. Provider administrators also play a critical role in overseeing the daily functioning of their agency’s database operations and use of the system.

Important rules and security

Before we move on, it is important to clarify some important features of data sharing in version 4.0. 

n        If you elect to share data with another provider, you share data ONLY on the clients that you have in common with that other provider; in short, I can never see information on clients served at your agency that I don’t also serve; that would clearly not meet the need to know criteria.

n        Providers can never edit another provider’s service (and most other) data for shared or common clients; this information is “owned” by the provider that rendered the service. Some data, though, are shared. (See below for an outline of common/shared data.)

n        In network configurations, all data, including personal identifying information such as names, dates of birth, addresses, etc. are stored centrally on the grantee administrator’s database server (the data tier). Of course, as we will outline below, all data transmitted in version 4.0 will be encrypted and will require a public/private key to decrypt this information.  Client-identifying data will also be further encrypted on the central data tier as well.  Please refer to the accompanying system-administrator document for technical information on encryption of data in CAREWare4.0.

n        TO SHARE OR NOT TO SHARE: Upon setup of the network version 4.0, each provider must determine which (and whether) other providers, or provider types, can view their own service data when they share a client.  In addition, there are some important differences in how service and demographic/clinical information and case notes are handled.  These features are outlined below.

Data Sharing Configurations

For service records, there are 3 levels or data-sharing configurations available to the individual provider:

n        Level I: All other providers can view your own agency’s service records; this is obviously the most open setting.

n        Level II: A provider shares service records only with other providers that offer the same service type; for example, a primary medical care provider would share service records with other medical providers (a service “need to know” basis) on the network.  However, if a primary care clinic also offers mental health services, a second primary care provider that does not offer mental health services would only be able to view medical care services and not the mental health service records from the other agency for the clients they share.

n        Level III: Do not share service records with any other providers.

Client-by-client option

To accommodate special client requests, providers using either Level I or II may also share services on a client-by-client basis.  Providers who choose this option will grant specific providers permission to see specific clients’ service records.  Other providers may request to view a particular client’s service records, and the original provider, in conjunction with the client, may grant or deny permission.  

n        Requests made of other providers on the network - for example to view data or make a referral - can be made through a convenient internal messaging system.

How Demographic & Certain Clinical Data Are Handled

Unlike service records, which are “owned” by each provider that renders services to a given client, demographic and certain clinical data will have common ownership. 

Demographic Data

By definition, each unique client appears only once in the central network database; there is no duplication.  Furthermore, there is only one demographic record per client; even if a client is served by multiple providers in the network, there is only one demographic record for that individual.  If a provider with appropriate access rights changes a client’s name or address, those changes will be seen by another provider when that client’s record is brought up the next time.  There are 2 exceptions here: the client ID field, which is customizable and often used by providers to store their own unique client identifier, and enrollment status. These two fields are not “common” and may differ, of course, across providers.  It is quite likely, for example, that a client is active at one provider and inactive at others in the network.

The obvious benefit of having common demographic data is that once a client is registered in the system, this information does not need to be re-entered. 

Common Clinical Data

Like demographic data, the following clinical information is common to all providers who have rights to view and edit that data:

n        Medications

n        Diagnosis history

n        Immunizations

n        Pregnancy history

n        Annual data in the Clinical Review section of CAREWare

Again, by common data, we mean that the information in these clinical fields is not “owned” by specific medical providers.  For example, there would not be ten medication records for a given client, each for the ten medical providers that might have prescribed antiretrovirals to a given client in the network.  Rather, there will be one medication file.  The clear benefit of this is that duplicate or contradictory information on medication history (or history of diagnoses, or pregnancies) across different providers is avoided; the client’s complete record capturing this info is stored in one location, and the client would not need to recall his/her medication history each time they were seen by a new clinician in the network.  It is also important, of course, that only specific users at a provider are granted the right to view and/or edit these common clinical data types.

Provider-specific Data Types

Unlike the common data outlined above, the following data do maintain a unique relation to the provider that entered the information, and version 4.0 restricts other providers’ access to these data:

n        Service Data (described above)

n        Enrollment Status, Client ID, provider eligibility (described above)

n        Vital signs

n        Labs

n        Screening Labs

n        Screenings

n        Case notes (see below)

n        Referrals

The example of John Doe

Let’s say Provider #1 in the network first sees a client named John Doe in 2002.  Provider #1 offers primary care and mental health services. In the next year, Mr. Doe enrolls at primary care Provider #2 across town, but also in the network.  Let’s also say that these 2 providers were already set up to share service information (Level II described above). (If they hadn’t been, provider #2 may have requested from provider #1 the right to view but not edit this data—you can never edit another provider’s service data!)

Now, when the data administrator at provider #2 with read/write access to John Doe’s record finds his record following a database search, a couple things occur. First, Mr. Doe’s demographic data are completed, but could be changed if this were deemed necessary. For example, maybe his address had changed, or his race was entered incorrectly. Remember, these edits are possible at provider #2 because a) demographic data are common fields and 2) the user accessing the system has been granted the appropriate rights to edit these fields.  Note that through an audit trail, the central administrator can track how often specific fields are modified; this is an important way of overseeing the integrity of the database and ensuring that records are not being unnecessarily changed or modified.

Now say that provider #2 goes to the service tab.  Because service records are not common, but owned by the provider, provider #2 may add services and view the services Mr. Doe received at the Provider #1, but cannot edit any of the services entered by another provider.

Case Notes

Because of the additional sensitive nature of case notes, the network version of CAREWare will allow the following sharing arrangements:

n        Rule-based sharing: users at other providers will be able to view case notes if they are granted sufficient permissions

n        No sharing: no other providers can view the case notes entered by a specific provider

Store and Forwarding

For agencies electing not to join the real-time network, version 4.0 will allow for store and forwarding of data.  Store and forwarding simply means that the agency will export all or part of their database to the central domain on a regular basis.  This will ensure that the main database stored on the grantee’s server will contain the client level data from all providers, whether or not they are joined to the network.  However, the provider electing to store and forward their data will not, of course, have access to other providers data in real time as they are not connected to the CAREWare network.  Grantee administrators will be able to establish read only access accounts for store and forward providers.

n        An internal network messaging system that will enable providers to send referrals and other messages such as system updates to contributing network members.  A bulletin board will also allow the grantee administrator to send messages across the network.

n        Controlling Contract expenditures for each service: Grantees will have the ability (from the central domain) to create contracts that limit spending by service type.  The following options will be available:

Subservice cut-off: Grantees can decide that providers who reach the annual expenditure limit for a subservice will no longer be able to enter data for that subservice.

Nag screen: Some grantees may not want to prevent data entry.  They will, though, be able to implement a warning message that appears evrry time the provider enters a record for a service whose annual limit has been reached.

HIPAA Compliance

The network version of CAREWare has a number of features that will ensure compliance with HIPAA in a variety of ways.  But it is important to remember that the data privacy and security requirements of HIPAA require the trust of the individuals running and managing and using the system at the provider and grantee level; it’s not ONLY the responsibility of the computer hardware and software!

Nevertheless, there are many features of version 4.0 that are critical to maintain the security of the data, and ensure that only authorized individuals see only the information they need to see to provide services.

n        Passwords which limit access to view or edit data

n        No access after three failed logon attempts

n        Grantee can set a number of days after which passwords must be changed

n        Role-based and need-to-know access: Very flexible data sharing system to restrict user access to and ability to view only specific parts of the database

n        Full data encryption over the network through the .NET system

n        Client identifying information-name, date of birth- is encrypted in a string when it is stored in the database

n        Audit trails that enable the grantee administrator to oversee who was logged in and made specific changes to the database

This section is designed to provide System Administrators the information they will need to design and manage a computer system on which to run RW Careware 4.0. It will:

n        Give system requirements, both hardware and software.

n        Provide and overview of the 3-tier architecture used in RW Careware.

n        Discuss security of client information, including encryption techniques used in storing and transmitting data.

n        Give example configurations for a variety of systems - from a simple stand alone workstation to large scale WAN installations.

n        Give estimates of network traffic (bandwidth) and storage requirements. This will be important in deciding whether to use the included MSDE data engine or to upgrade to MS SQL Server, as well as deciding what types of connections will be needed between computers.

n        Provide considerations for firewall configurations.

n        Discuss deployment of Careware, and the automatic update system.

n        Detail what needs to be backed up in order to be able to recover Careware from a catastrophic failure.

 There are a couple topics that are outside the scope of this document, and so will NOT be covered:

n        Specific back up systems will not be discussed. While this document will detail what to back up, it will not discuss how to back it up.

n        System redundancy – this is highly contingent on how mission critical an installation of Careware is, and will not be a consideration in most cases. Network Administrators will need to assess the necessity of redundancy, and how to set that up should they deem it necessary.

RW CAREWare 4.0 utilizes a 3-tier architecture composed of 3 parts: the Data Tier, the Business Tier, and the Client Tier. In some cases, grantees will host the back-end database and business tier components while providers run front-end client components that will allow them to enter data and run reports.  In other cases, all three components of the software will run on a single PC.

Data Tier

The data tier is the database where the actual information is stored. This is a storage facility that holds all the data and fills requests for storing, retrieving, and modifying program data. It is composed of tables of data managed by a Microsoft MSDE database engine, which is based on core SQL Server technology. MSDE is freely distributed with Careware though a license which

is similar to the one that allows us to distribute older versions of RW CAREWare with Microsoft Access Runtime. 

Providers and grantees will not have to incur expense when setting up their data tiers if they use the MSDE. 

MSDE does have limitations: an MSDE database cannot be larger than two gigabytes, and according to online sources, if an MSDE database processes more than five queries at once, performance declines.  See:

http://www.microsoft.com 

The information captured by RW CAREWare is very private in nature, and so security is a very high priority. The program uses multiple layers of security to help protect client data; this section will talk about those.

Secure User Manager

RW CAREWare employs a custom designed user manager with a very sophisticated permissions system (which is managed by the Business Tier). Through this system, administrators can give very specific privileges to users, deciding what data users are allowed access to and what type of access they have to that data (Viewing, Adding, Editing, Deleting, etc.). This user manager is entirely separate from any Operating System user management system, and so does not depend on the version of Windows installed, whether Active Directory is used, etc. More information on managing users can be found in the RW CAREWare User Manual.

In addition to the permission system, RW CAREWare also uses an extensive logging system. There are 3 types of logging in RW CAREWare:

System Event Log – These entries can be found in the Windows Event Viewer. This logs any exceptions that are encountered by the program. These entries will generally be used by RW CAREWare support personnel to help correct problems with the operation of the program.

Security Violations – This log can be viewed in the administrative section of RW CAREWare. They are also presented to RW CAREWare administrators in the system messages section of the main menu.  It shows a history of any security violations in the program, which includes unsuccessful login attempts, any client trying to access data without the proper credentials, etc.  These types of violations are also written to the event log.

Change Log – This is also viewed under the administrative section of RW CAREWare and shows a history of all changes made to client data and services. It records information such as the user making the change, the time of the change, old value, new value, etc. Entries are made for each field on any record that is added, updated, or deleted. Obviously, over time as the program is used this file will continue to grow in size. For this reason, there will be a record-purging feature (also under the administrative options) to allow older Change Log entries to be purged from the table. The User’s Manual will have detailed information on all functionality provided in the Administrative section of RW CAREWare.  We recommend that you leave the change log active for auditing and export purposes unless lack of disk space, ore MSDE restrictions require a purge.

Encryption Technology

.NET’s cryptology library provides native encryption capabilities that can be used to secure communication streams used in n-tier applications.  RW CAREWare 4.0 (CW) will use these capabilities to enable Providers or Grantees (PG) to store, retrieve and transport the highly confidential Personal Identifying Information (PII) they may possess.  All remoting streams that will be used in RW CAREWare 4.0 will be encrypted using the RSA and DES encryption algorithms available in the .Net cryptology library. These encryption algorithms use Microsoft’s 128-bit High Encryption Pack and requires that all client machines install this high encryption package. 

The following encryption plan addresses three key areas where CW may store or transport PII.

Database storage of PII

In some larger implementations of CW, it is likely that the PG will house the CW data in large SQL Servers that are administrated and backed-up by network personnel who are not directly controlled by the PG.  PGs may also choose to store backups of their data offsite in case of fire.  To ensure confidentiality in these types of scenarios, the business tier will encrypt name, birth date, URN, and soundex information prior to storing it in the database.  This encrypted information will be concatenated and stored in a single binary field in the client’s record.  The data can only be decrypted with the private key that will be kept on the business tier.  This enables a PG to install the CW business tier on a computer that is secured by personnel they monitor closely.

The encryption will be accomplished using the .NET TripleDESCrypto-ServiceProvider functionality.  TripleDESCryptoServiceProviders GenerateIV() and GenerateKey() methods will be used to randomly create strong private keys during the CW installation process.  These keys will be stored on the business tier computer in an encrypted file (see Key Protection on page 14).  With the use of these keys, the business tier will encrypt PII prior to saving to a database and decrypt it after retrieval.  The encrypted data (encompassing several fields, as is explained above) will be packaged together and stored in one MS SQL Server VARBINARY field.

Store and Forward

A solid understanding of CW Store and Forward (S&F) is required to understand its encryption scheme. For an explanation of the overall concept of S&F, see the related section in the Requirements Definition Document (RDD).

CW allows disconnected providers to enter data and then periodically create export files that are then transported to the grantee for importing.  CW will implement an RSA public/private key scheme ensure confidentiality of data during transport.  Each installation of CW will have its own randomly generated public/private key pair that will be stored in an encrypted file on the data tier (see Key Protection on page 14  for details).  When a provider first wishes to transport data to a grantee, the provider will need to import a grantee-created setup file that contains the grantee’s RSA public key.  From then on, data sent to that grantee will be encrypted using that public key.  Once the data has been transported to the grantee, the grantee’s business tier will use its RSA private key to decrypt the data.

The .NET RSACryptoServiceProvider functionality will be used to generate the public and private keys during the CW installation process and to encrypt export data and decrypt for import.

S&F Import Adapter

Before data can be imported, a CW administrator will setup an S&F import adapter.  From that adapter they can create a small configuration file that among other things will have the public key for their CW installation.

S&F Export Adapter

When the provider wishes to export to a grantee (or any other CW installation) they can create an S&F Export Adapter from the configuration file sent to them by the grantee.  At that time they will read the grantee’s public key and store it in their database with other export adapter information.  Any export files sent to the grantee will be encrypted with the grantees public key.

Client tier <-> Business tier communication channel

CW uses .NET remoting for all communication between the client and business tier.  When a new channel is first established, the client generates a random RSA public/private key pair and sends the public key to the business tier.  The business tier then responds by generating a new random private DES SharedKey and SharedIV key that is encrypted with the public key and sent to the client.  From then on, both the client and the business tier use the same private DES SharedKey and SharedIV key to encrypt and decrypt the data that is communicated across the channel.  These random keys are unique to each channel and are discarded once the communication channel is terminated.

Business tier <-> Data tier communication channel

CW does NOT encrypt channels between the business tier and the data tier because in most installations they both will be located behind the same firewall and possibly on the same server, and because key demographic data is encrypted at the application lever prior to sending it to the data tier.  If you are installing CW in an environment where you have determined these channels should be encrypted, it will be up to you to implement the solution. 

If your business and data tier are both running on Windows 2000 Server or above, you may want to consider using IPSec to secure this channel.  Information on how to configure Windows 2000 Servers to communicate using IPSec can be found at:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/SecNetHT18.asp

If you have the data tier using MS SQL Server 2000 or above, you may want to consider using its SSL capabilities to encrypt the communication channels.  Information on how to configure MS SQL Server 2000 to use SSL can be found at:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfsystemio.asp

Key protection

Each installation of CW will have its own set of strong, randomly generated private keys.  All private keys will be stored in a password-protected configuration file on the computer where the business tier resides.  This configuration file will be encrypted using .NET TripleDESCrypto-ServiceProvider functionality.  A key that will be used to decrypt the private keys will be generated from a GP-provided password.

Automatic vs. Manual GP password retrieval

Given that the private keys are required for the business tier to operate and that they are protected by a GP-supplied password, the business tier will require that the password be retrieved before it services client requests.  CW will allow GPs to choose between manual and automatic GP password retrieval.  Manual password retrieval will require a designated user to enter the GP-provided password prior to servicing client requests anytime the business tier is started or re-started.  Automatic key retrieval allows the business tier to read the GP password from a configuration file at startup.  CW will ship with automatic key retrieval enabled; this system will use a default password much like ‘cw_temp’.  GPs will then be able to configure key protection based on their own established procedures.

Manual GP Password Retrieval

Manual retrieval requires a GP-designated staff person to manually enter the password that protects the private keys before the business tier services clients.

The benefit of this system is that it avoids having to store passwords on the disk of the business-tier and hence provides some additional protection if the operating system security of the business tier computer is breached.

The drawback of this system is that it requires human intervention when the system is started or rebooted, and it may cause more people to need to know the password.  It also carries the possibility that the password may be forgotten and/or lost.

Automatic GP Password Retrieval

With automatic key retrieval the GP-supplied password is stored in a configuration file that the business tier encrypts with a key that is stored in its programming code. The GP-supplied password is then read from this file when that business tier needs to decrypt the private keys at startup.  Because storing a key in software is a weak form of key protection, under this method, the GP would need to take steps ensure that their operating system security prevents unwanted access to the configuration file.  The GP would also need to ensure that they changed the CW-supplied default password to a password that contains a sufficient number of mixed letters and numbers that cannot be guessed.

The benefit of this system is that it allows the business tier to be started and rebooted without human intervention, which can be efficient after system failure.  It also may be desirable in single user installations where the user doesn’t have the technical skill necessary to use manual key retrieval. It most likely would require fewer people to know the GP password as well.

The drawback of this system is that if a hacker gains unwanted operating-system-level access to the business tier computer, he or she might find the password and key files and then hack the programming code and decrypt the password, which he or she could use to get the key.  But arguably if the PG’s security is lax enough to allow this, the revealing of this password may be the least of their worries.

The following illustrations depict a sample of possible configurations that RW CAREWare will support.

Figure 2.1 Sample Stand-Alone Configuration

In this illustration, all three tiers are installed onto one workstation.

Figure 2.2 Sample LAN Configuration

In this sample configuration, four workstations, using client tier software, are connecting to a server computer using encrypted .NET Remoting.  This server has both the data and business tier installed.

Note that the Data Tier and the Business Tier could be installed on separate servers if it better fits the specific network architecture.

Figure 2.3 Sample Normal WAN Configuration

In this sample configuration, two LANs from a clinic and a hospital are using .NET Remoting to connect to the server.  Each LAN site has dedicated lines that are directly connected to the server site.  At the server site, there is one workstation running the client tier software connecting locally to the network and another connecting to the network using dial-up. The server at this site has both the data and business tier installed.

Note that the Data Tier and the Business Tier could be installed on separate servers if it better fits the specific network architecture.

Figure 2.4 Sample High End WAN Configuration

This configuration is identical to figure 2.3 except that the data and business tier are separated into two server computers on the server site.

n        We are designing the business and data tier to reside behind the same firewall.  Therefore, the RW CAREWare 4.0 system will not encrypt the communication channel between these two tiers.

Figure 2.5 Sample Internet Configuration

This configuration details the transfer of data through the Internet.  LAN sites from a clinic and hospital are connecting to the server by making unsolicited requests for connections and transferring encrypted data using .NET Remoting through the Internet.  Firewalls are placed at each site to symbolize possible security measures taken by each site.

n        We are designing the business and data tier to reside behind the same firewall.  Therefore, the RW CAREWare 4.0 system will not encrypt the communication channel between these two tiers.

n        In normal operating conditions, it is ok to put the data tier and the business tier on the same server

When complete, this section will provide a summary of average network traffic and storage space usage.

As can be seen from the sample Network Configurations on page 19, firewalls are an expected component of the systems that RW CAREWare will run on. The business tier acts as a communications hub of sorts, since all client requests go through the Business tier to get to the data tier and all responses go back through the business tier to get to the client (See 3-Tier Architecture on page 9 for an overview of these components).

Business Tier < - - > Data Tier

The SQL Server database sets up a listener to handle requests, and the Business Tier makes its requests over the standard SQL Server port. The connection string information is located in the file BusinessTierSettings.xml under the DataTierAddress setting.

Business Tier < - - > Client Tier

The Business Tier uses .NET Remoting, which CW CAREWare ships using the HTTP protocol for communications with the Client tier. The Business tier sets up a listener for Client requests, and sends replies to these requests over a single port. This port information is stored in the file RWCAREWareRemoting.config. The Client has a similar file, called ClientTierSettings.xml that has its connection information (this file is always located in the bin folder in the same location the client.exe in installed). In both of these files, the communication port is specified, and this is the port that is used for all communications (the default port is 8124). If there is a firewall between the Business tier and the Client, then this port must be opened on the firewall and forwarded to the computer hosting the business tier.

Changing the default port (8124) on the Business Tier

The only way to change the port that the Business tier listens on is to manually open the RWCAREWareRemoting.config file and change the port setting. Note that once this is changed, any client that wished to communicate with that Business tier MUST use the new port. Changes to the configuration file will not take effect until the business tier service is restarted.

Changing the default port (8124) on the Client Tier

The port that the client file uses can be changed in two ways – either by manually editing the ClientTierSettings.xml file, or from inside RW CAREWare. The client keeps a separate entry in its config file for each server that it wants to connect to, along with the port information. Thus, a client can make connections to any number of servers over any number of ports (of course it can only use one connection at a time). The connection port is specified when the server connection is initially set up (the default value is still 8124), and can be changed anytime by a user with the appropriate administrative permissions. 

Backing Up Data

Microsoft’s MSDE database has built in procedures for backing up and recovering the data. RW CAREWare will provide functionality that will invoke the Transact SQL that creates the backup files from inside the program itself (Advanced users that still desire to back up the database manually using Transact SQL or SQL Server’s Enterprise Manager will still be able to do so, of course, but these tools will not be required). Using this functionality, a user will be able to specify where the backup will be placed. Then when the backup utility is run, it will save the backup files to the specified location, where they can be stored, archived, etc.

More information on backing up an MSDE database can be found on Microsoft’s website here.

If an installation is using SQL Server, the backup procedure is the same is it is for MSDE. SQL Server will provide more tools, including the Enterprise Manager. This provides administrators with many tools for managing the database that are not covered in this document.

Keeping RW CAREWare Up To Date

The RW CAREWare client tier helps with keeping itself up to date by using its self-updating technology. Using this, the Client automatically checks for updates from the Business Tier every time the program starts. If there is a new version, it is automatically downloaded from the Business Tier and installed. This ensures that the three tiers of the program will always be on the same version. This means that clients only have to be installed on a computer once, and from then on they will update themselves.

Any updates to RW CAREWare will come in the form of an *.msi installation package. This package will update all files that require updating on the Business Tier. The Business Tier will then automatically update the Data Tier as necessary, and have updates ready for download to clients that require them. Thus, whenever an update or new version of RW CAREWare is released, a user will simply run the setup file, and this will update the business tier, which will take care of everything else.

Overview

Deploying the Version 4.0 data tier involves three steps:

Installing and Configuring SQL Server or MSDE

Two parts of this process are worth noting here.  First, when installing SQL Server 2000 or MSDE, there are options for allowing only Windows Authentication and for allowing Windows and SQL Server Authentication.  RW CAREWare Version 4.0 uses SQL Server Authentication, so this security mode must be enabled.

Second, you must decide whether or not there should be a password for the default administrator login, “sa.”  If the user configuring SQL Server decides to create an sa password, then whoever manages the data tier for RW CAREWare Version 4.0 will need to know that password.

Configuring the CAREWare Business Tier Login Account (cwbt)

You will need to create the cwbt login account and assign a password to that account.  If the password is different from the default cwbt password, then you will need to modify the business tier settings.

Copying and Attaching the Database Files and Making cwbt the owner of CW_Data.

The Version 4.0 data files are CW_Data.mdf and CW_Log.ldf.  These need to be copied to a location that can be accessed by SQL Server.

SQL Server needs to be made aware of the existence of the data files before any further actions can be taken.  Attaching the RW CAREWare data files to SQL Server adds a reference (“CW_Data”) to SQL Server’s list of known databases.

Finally, the user needs to make the cwbt account the owner of the CW_Data database.

Automated Installation

RW CAREWare Version 4.0 will be used in a broad range of situations.  Statewide Title II grantees with many real-time providers likely will have more complicated configuration demands and (hopefully) will have experienced staff who will want to configure the data tier manually.  However, smaller providers using a standalone configuration might have no staff with expertise in this area.

To ease installations at providers with less knowledgeable users, the Version 4.0 installation process will provide optional functionality that will automate the three steps described above.  However, the automated installation process will allow limited flexibility; for example, it will not work with existing SQL Server or MSDE installations.

Manual Installation

The following technical information might be helpful for users installing the data tier manually.

Installing and Configuring SQL Server or MSDE

SQL Server
Using the SQL Server Enterprise Manager, you can change the Security Mode and sa password after installation.  To change the security mode through the Enterprise Manager, right-click the server that will run the data tier, go to Properties, go to the Security tab, and select Mixed Mode.  Advanced users can also change the Security Mode by editing the registry key

“HKLM\Software\Microsoft\MicrosoftSQLServer\
Instance Name\MSSQLServer\LoginMode.”

Similarly, the sa password can be changed after installation through the SQL Server Enterprise Manager.  To do so, expand the relevant server, expand Security, select Logins, right click the sa account (visible on the right-hand side of the screen), choose properties, and then change the password.

MSDE

The MSDE Security Mode is established at installation.  The default is Windows Authentication, so users need to specify Mixed Mode by using the SECURITYMODE=SQL switch. 

The sa password is also established at installation.  To set a specific password, use the SAPWD=”sa_password” switch; if you want the sa password to be blank, use the BLANKSAPWD=1 switch.

Here’s a sample MSDE installation script that specifies Mixed Mode and a blank sa password.  This kind of installation can be run from a DOS prompt or by clicking Start and then Run.

Once MSDE is installed, it will be started the next time the computer is restarted.  To restart it manually, click Start à Settings à Contral Panel, double-click Administrative Tools, double-click Services, right-click the MSSQL$VSdotNET service, and choose Start.

Configuring the CAREWare Business Tier Login Account (cwbt)

In this step you will create the SQL Server account that the RW CAREWare business tier uses to connect to the data tier.  As a default, the business tier is configured to use ‘cwbt100’ as a password.  If you wish to use a different password, you will need to modify the BusinessTierSettings.xml file that resides in the ‘Server Application/bin’ folder on the computer running the business tier; look for “password” under “DataTierAddress” in the XML structure.

To create the cwbt account:

SQL Server

Using the SQL Server Enterprise Manager, expand the relevant server, expand Security, right-click Logins, and choose New Login.  Give the login the name ‘cwbt’.  Choose SQL Server Authentication and enter ‘cwbt100’ or the password that you have chosen.

MSDE

Once MSDE is installed, it can be manipulated with the SQL Server Enterprise Manager if that software is available.  Otherwise, setup duties will have to be performed using OSQL, a DOS-based application with limited features that is installed with MSDE.  There are many ways to use OSQL; for details, visit the following web sites:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/coprompt/cp_osql_1wxl.asp

http://support.microsoft.com/default.aspx?scid=kb;en-us;325003

OSQL is easier to use from within a DOS window (instead of running OSQL commands directly from the Start à Run box) because DOS will tell you if the script has been successful.  To open a DOS window, click Start à Run and type ‘cmd’.  Also note that OSQL scripts are case sensitive, so pay close attention to case when using this utility.

To create the cwbt login using OSQL, use the sp_addlogin stored procedure.  (For details on the stored procedures discussed in this section, see the following web site:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/tsqlref/ts_sp_ae-az_52oy.asp) 

Here’s an example of how it could look with the default password:

Copying and Attaching the Database Files and Making cwbt the owner of CW_Data.

Save the CW_Data.mdf and DW_Log.ldf files to a convenient location on the server.  The default location for SQL Server data files is the C:\Program Files\Microsoft SQL Server\MSSQL$VSdotNET\Data folder, but SQL Server does not require that its data files be in any specific folder.  Then, to attach the database:

SQL Server

Expand the relevant server, right-click on Databases, choose All Tasks, and choose Attach Database.  On the screen that pops up, indicate the path to the CW_Data.mdf file, and in the Attach As box type “CW_Data”.  Next to Specify Database Owner, choose the cwbt account.

MSDE

To attach the RW CAREWare database using OSQL, use the sp_attach_db stored procedure.  For example, the following script would work for the default path to the data files:

To make the cwbt account the owner of CW_Data, use the sp_changedbowner stored procedure.  Here’s how it might look: