Introduction and
System Administrator’s Guide
RW CAREWare 4.0
Release date: Fall/Winter 2004
From stand-alone to wide area
network: A scalable software application for managing and monitoring HIV Care
Section
1 Overview |
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.
IMPORTANT NOTE: As with current upgrades, your CAREWare database will be automatically converted to the appropriate format when you apply version 4.0. However, version 4.0 will not convert CAREWare databases from any version prior to 3.6, so please upgrade to the latest version now!
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.
NEED-TO-KNOW: Version 4.0 will have a great deal of flexibility with regard to granting and denying access to which users can view and/or edit data. Users on the network access client data on a “need-to-know basis”-that is, they can see and share client data when it is necessary, and be denied access to client data when it is unnecessary. This arrangement is obviously a critical data privacy feature of version 4.0.
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.
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.
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.
Table 1. Summary of version 4.0 Roles, User types, Rights and Permissions
Role in RW
CAREWare 4.0 |
User Types |
Possible
Rights and Permissions |
Real-Time Central Administrator |
Grantees, Data Directors, Computer Administrators |
Read/Write access to all domain contact information in system Create/Edit central and provider domain user accounts |
Store and Forward Central Administrator |
Grantees, Data Directors, Computer Administrators |
Read/Write access to current Grantee contact information |
Real-Time Provider Administrator |
Provider, Data Directors, Computer Administrators |
Read/Write access to provider domain contact information Create/Edit provider domain user accounts |
Store and Forward Provider Administrator |
Provider, Data Directors, Computer Administrators |
Read/Write access to current provider contact information Create/Edit provider domain user accounts |
Central User |
Data Entry, Data Monitor, Care Givers |
Read/Write access to certain client data modules of assigned domain(s) client data |
Provider User |
Data Entry, Data Monitor, Care Givers |
Read/Write access to certain client data modules of current domain client data |
Installation/Maintenance personnel |
System Administrators, Network Administrators, Applications Administrators, |
|
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
Section
2 System Administrators |
Background
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.
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.
|
|
|
|
|
|
Recommended |
Minimum |
Hardware |
Server |
512 MB RAM, 1GHZ or faster processor, 10GB of hard drive space. |
128 MB RAM, 166mhz processor, 250mb of hard drive space, display resolution 800X600. |
Client |
96 MB RAM, 1GHZ or faster processor and 1GB of hard drive space |
32 MB RAM, 133mhz processor and 50mb of hard drive space |
|
Software |
Server |
|
Windows® version: 2000 Professional, 2000 Server (both with SP2 or later), NT 4.0 Server (with SP5 or later), XP Microsoft Data Access Components (MDAC) 2.7 Microsoft .NET Framework |
Client |
|
Windows® 98 and up Microsoft Data Access Components (MDAC) 2.6 Microsoft .NET Framework |
|
Technical Knowledge |
Server |
IT
experience with networking and Windows® skills. |
Personnel
with moderate computer skills required for multi-user setup. |
Client |
|
Personnel
with minimal computer skills. |
3-Tier Architecture
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.
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:
NOTE: We ran a battery of tests on the same database stored on SQL Server and MSDE, and found that sometimes MSDE is 15% slower when processing more than five concurrent queries (as opposed to a 5% difference when processing five or fewer queries). Other times, though, there was no performance difference, regardless of the number of queries involved. RW CAREWare Version 4.0 helps with the concurrent performance issue by utilizing a queuing system to throttle query submission. In our tests, queries that were run consecutively were actually more efficient than those run concurrently.
These limitations will affect only the largest RW CAREWare installations,
however. Most RW CAREWare 3.x data
files range from 3 MB to 40 MB; a grantee with 50 providers could use up 2
GB only if all 50 providers averaged 40 MB worth of data. (This is a rough estimation. Current RW CAREWare data files can only be loosely
compared to a Version 4.0 database. For
example, a Version 4.0 database will save space by sharing demographic data
but will use extra space by maintaining a change log.)
Also, organizations with sufficient resources will be able to upgrade MSDE to MS SQL Server, which is not limited in the way that MSDE is. As of August 7, 2002, SQL Server licensing fees are as follows. Source:
www.microsoft.com/sql/howtobuy/production.asp
By Processor (allows unlimited number of connections)
n
n Standard: $4,999
n RW CAREWare 4.0 will work on the Standard Edition, although Network Administrators may have other reasons to need the Enterprise Edition.
By Client Access License (
n
n Standard, 5 CALs: $1,489
n Standard, 10 CALs: $2,249
See Network Traffic and Storage on page 11 for more information usage estimates.
The business Tier acts as the communication manager for Careware 4.0. It is run as a Windows service, and is built on the .NET framework This tier provides secure communication to and from the Client Tier, and reliable transportation of data to and from the database. This tier also manages data encryption, as well as the checking of the credentials of the client attempting to contact the database and enforcing the business rules.
The Business Tier utilizes .NET Remoting as its means of communication with the Client Tier. When shipped, RW CAREWare uses HTTP for Remoting because this protocol is more robust, particularly in regards to firewalls, which will commonly be encountered between the Business and Client Tiers.
When the Business Tier is started as a service, it sets up a listener that awaits requests from a client. Whenever it receives a request, if the request has the proper credentials (see Permissions Management) on page 11, then the Business Tier fills the request and sends an appropriate response to the client. Note that all data sent to and from the client is encrypted (see Client tier < - > business tier communication channel on page 13 ).
The file RWCAREWareRemoting.config, which is located in the installation directory of the Business Tier holds the connection information to the Client, including the port number that the business tier will listen on.
The business tier ships using five standard SQL Server connections to communicate to the data tier of the program. These connections are created under the authority of the CWBT (Care Ware Business Tier) SQL Server user. These two tiers are intended to reside behind the same firewall, whether on a single machine or separate.
The settings for the SQL connection information are in the file BusinessTierSettings.xml under the DataTierAddress setting. This file will be installed (and must remain) in the installation directory for the Business Tier.
RW CAREWare’s query throttling technology insures that the
business tier administrator can specify the maximum concurrent queries that
will be submitted to the MSDE/SQL Server during peak periods. It also allocates the
queries by purpose. In the default
configuration, one query is allocated for updates, two are allocated for select
queries related to data entry screens and program operation, and two are
allocated for reports. Under this
default setup, if there are three users are trying to run reports at the same
time, the third report request will experience a pause until one of the
preceding report queries finishes, but the data entry related activities will
continue like normal, and the MSDE will not purposefully slow down. If you are using the MSDE as your data tier,
it is recommended that you do not change these default settings, but if you are
using the full version of SQL Server, you will most likely want to allow the
business tier to use more connections and submit more simultaneous queries
during peak periods. You can do this by
adjusting the NumReportConnections, NumSelectConnections,
and NumUpdateConnections values in
BusinessTierSettings.xml.
NOTE: The default ports that are used can be changed by modifying these files, but you must be sure to change the port on the client config file as well (or the setup of the MSDE database connection on the database if it is changed); Otherwise the program will not work, since there will be no communication through the business tier.
NOTE: The business tier and data tier have a one to one relationship. For a number of reasons, the business tier keeps data cached in memory, and assumes that it is the only entity changing data in the CW tables on the data tier. For this reason you should never configure two CW business tiers to point to the same data tier. If you are contemplating inserting data into the data tier directly from a third party application, you should first contact CW technical support to discuss required techniques to insure the integrity of the business and data tiers.
RW CAREWare employs an extensive custom permissions module to exercise control over access to features. Users need to have different permissions to view, or edit, or add, or delete data, and different permissions based on which data they would access (See the System Administrator’s section of this Guide for detailed information on these permissions).
The Business Tier acts as the manager for this permission system. Any time a user makes a request to access the database, the Business tier verifies that the user is a valid user, that they are logged into the system, and that they have the necessary permissions for the requested data access. If all these criteria are met, then the Business Tier fulfills the request. Otherwise, an appropriate error message will be sent to the client describing why the request was denied.
The business tier also manages data encryption for the program, including encrypting data streams to and from the client, and the encryption of identifying information on the data tier. This encryption is covered more in Encryption Technology on page 12 .
The Client Tier is the user interface for Careware. It is composed of all the forms and the code that is used for requesting, submitting, and presenting data in the program. The interface uses Windows Forms technology, written in Visual Basic .NET. This allows us to deploy and use secure and user-friendly client systems that users will be able to setup and use with ease.
For information about installing and updating these 3 components, see Deploying and Maintenance.
Security
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.
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.
.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.
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.
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.
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.
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.
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.
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
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.
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 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.
Sample RW CAREWare Network Configurations
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
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
Network Traffic and Storage
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).
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.
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.
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.
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.
Setting up the Data TierDeploying the Version 4.0 data tier involves three steps:
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.
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.
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.
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.
The following technical information might be helpful for users installing the data tier manually.
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.
C:\[PathToSetupFolder]\setup.exe
BLANKSAPWD=1
SECURITYMODE=SQL
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.
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:
osql –S [servername]\VSdotNET
–U sa –P –Q “EXEC sp_addlogin ‘cwbt’, ‘cwbt100’”
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:
osql –S
[servername]\VSdotNET –U sa –P –Q “EXEC sp_attach_db ‘cw_data’, ‘C:\Program
Files\Microsoft SQL Server\MSSQL$VSdotNET\Data\CW_Data.mdf’,
‘C:\Program
Files\Microsoft SQL Server\MSSQL$VSdotNET\Data\CW_Log.ldf’”
To make the cwbt account the owner of CW_Data, use the sp_changedbowner stored procedure. Here’s how it might look:
osql –S
[servername]\VSdotNET –U sa –P -d cw_data –Q “EXEC sp_changedbowner ‘cwbt’”