Reggie/CIS

From Moonlight Design
Revision as of 16:05, 24 September 2007 by Stevenlawrance (talk | contribs) (New page: right Reggie/CIS was a large 200-user multi-tenant three-tiered system that was used by all [http://hab.hrsa.gov/ Ryan White CARE]-funded [http://en.wikipedia.or...)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search
Applet-login.png

Reggie/CIS was a large 200-user multi-tenant three-tiered system that was used by all Ryan White CARE-funded AIDS service organizations in San Francisco, California in collaboration with the San Francisco Department of Public Health (DPH) AIDS Office and two partners to the San Francisco AIDS Foundation, where I worked for about five years. At its peak, this system was used by more than 100 organizations. It was eventually replaced with a third-party solution as a result of reduced commitment and institutional knowledge for Reggie at the DPH.

Motivations

Named after its champion, Reggie Williams, Reggie/CIS successfully centralized client registration data for AIDS service organizations in San Francisco, substantially easing the registration process for people living with HIV or AIDS who chose to share their registration data with other Reggie organizations when vising previously-unvisited AIDS service organizations. This meant that documents such as the letter of HIV diagnosis and CD4 count information were entered into the system by one organization and then immediately available to all other AIDS service organizations that the client registered with. Before Reggie/CIS, clients would need to present their paperwork at every AIDS service organization that they visit when initially registering, and San Francisco is notorious for having many small, specialized AIDS service organizations for various needs such as medical care, housing subsidies, food, legal advice, disability benefits counseling, mental health, and medication adherence assistance. Reggie/CIS put each client in control of their data, permitting clients to share or unshare their data with other Reggie organizations at any time.

For the DPH, the centralized data in Reggie substantially eased reporting requirements for the federal, state, and county governments. The data was actively kept unduplicated for reporting purposes while respecting each client's data sharing preferences, enabling duplication of data at the agency level while keeping clients unduplicated in reports for accurate reporting.

The San Francisco AIDS Foundation and two other collaborating partners used the "CIS" part of the Reggie/CIS system, which built upon the Reggie application and database to provide customized data applications suited for the collaboration's needs. This included data entry screens and reports for rental subsidies, volunteers, care plans, progress notes, and other needs. I was the active maintainer, administrator, and software engineer of the CIS extension from 2001 to 2005, though my colleague at the DPH and I often worked on each other's part of the system when implementing new functionality.

Architecture

Reggie/CIS consisted of two main systems -- data entry and reporting.

The data entry system was a Swing fat client that connected with the middle-tier business logic server using the common object request broker architecture (CORBA). The middle tier connected to a Microsoft SQL Server database using a third party JDBC driver (Microsoft did not offer a free JDBC driver during most of Reggie/CIS's lifetime). The database consisted of approximately 100 tables, a moderate number of stored procedures, and one-way replication to two reporting database servers.

Reggie/CIS's reporting system was originally written in Microsoft Visual Basic Script (VBScript) and published to a closed network using Microsoft classic Active Server Pages (ASP).

A CIS-centric deployment view of the system is depicted in the following diagram:

ReggieCISServers.png

The reporting system also followed a three-tiered pattern:

Reporting.png

The data entry client ran as a Java applet and, later, as a Java WebStart application. Installation of the applet was made easy with a web-based multi-stage JavaScript-based installer, though its ease of use was achieved with a rather complex implementation. When the applet starts up, it obtains a reference to a business server object that it uses for object manipulation when the user logs in. This is depicted in the following diagram:

Client.png