CAREWare Version 4.0 User's Guide

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.

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.

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.

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.

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.

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.

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

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.

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:

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.

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

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.

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 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 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 Discuss security of client information, including encryption techniques used in storing and transmitting data.