Southern Minnesota Regional Legal Services, Inc. Pika CMS Status Report August 2002 SMRLS recently switched from Kemps - Clients for Windows 98 to Pika Software. Switching from Kemps to Pika CMS was/is pretty scary. SMRLS staff were comfortable with Kemps and pretty much knew what we were doing with it. John and Marc were always helpful in resolving any problems I had with Clients 98. But, with 12 Kemps databases in local offices across Minnesota and North Dakota, centralization was badly needed. Aaron Worley, of Pika Software, came to Minnesota in September of 2001 and gave a very convincing presentation of an essentially non-existent program to our senior management team. We had, again, reviewed costs and features in other case management programs - Kemps ASP, Practice Manager, Time, Pro Law, and Legal Files. Each of these programs have their own particular advantages, but if Pika would perform as claimed, our senior management team considered it a "no-brainer" in terms of immediate and future costs for licensing, hardware, and technology resources. Pika's potential flexibility for connectivity and future expansion was also a consideration. Aaron was given the go-ahead to start building Pika for us in November 2001. Our first office converted in mid-february 2002 and the last office came on board in mid-april 2002. Multiple training sessions were held in each local office prior to conversions. Staff were provided with handouts for desktop reference and given access to the Pika public/training database. The public/training database has been a key item in the Pika implementation. New versions of Pika are setup there for testing before installation on the private system. Users can go to the public/training database at any time to practice or to test new features. Pika Casemanagement Software is written in "Open Source" programs, MYSQL and PHP, so it is reasonably priced. We purchased Pika Software based on an initial fee for the software and support and upgrades for one year. Aaron provides an optional subscription method for ongoing support based on the number of users. Payment of a yearly user fee includes upgrades and support for Pika Software. Internet access, a web-browser, an appropriate username and password are required to access the system. Even though SMRLS was the pilot program and we made many design recommendations (which Aaron graciously and patiently considered), Pika is designed to be a full featured legal services casemanagement program. During development and initial startup, Pika was hosted on a shared Unix drive at a Twin Cities data hosting center. While the data center was exceptionally reliable, they are also a large ISP operation. Activity on their system increased greatly at certain times of the day and Pika performance suffered. Aaron recommended we test Pika on a dedicated drive. A local consultant had been telling me we should do our own Linux data hosting and offered to loan us a server for 3 or 4 months just to prove it would work. The loaner server we tested was a single drive 600Mhz system. That worked flawlessly and we upgraded to a Caldera Linux, 1x ghz something, a Raid system with four hard-drives, internal tape drive, SSL, and firewalls. The 1
Linux server is physically located in our St. Paul Central office where approximately 50 of our 120 users are housed. Staff in the Central office connect to Pika directly across the LAN leaving Internet bandwidth free for staff in remote offices. Bandwidth in and out of St.Paul is 768k. Internet access speed at the remote offices varies from a shared 56k dialup to T-1. Most are at 256k. User Access Levels: Different levels of user access are built-in. We are not fully using these as yet. When this is implemented, staff will be provided with training and descriptions of the various access levels and explanations of user settings. Apparently, unlimited combinations of access levels can be defined. The basic levels are designed like this: Access levels: Using Pika CMS "Group" Permissions to Limit User Access to Data Pika CMS has security features which allow the system administrator to limit user access to data. Some data is unrestricted. Access to client, opposing party, opposing attorney, and any other type of contact records is not restricted in anyway. Access to cases which have not been assigned a primary attorney or a office are also unrestricted. In some cases, permission to view or edit data is determined by which account the user is logged in under. Users will always have full access, read and write, to any case where they are listed as the primary attorney or one of the co-counsels. Users will always have full access to any activity records that belong to them. In all other cases, a user's permissions are determined by which "group" they are assigned to. Currently, groups can only be added or modified by editing the groups table in the Pika CMS database. A group has the following permission options, which are inherited by any members of the group: read office This field contains a comma-separated list of office codes. A user has permission to view any cases assigned to an office that is listed in this field. No extra access to activity records is granted. Read all If this is enabled, members of the group may view all cases and all activity records. Edit office This field contains a comma-separated list of office codes. A user has permission to modify any cases assigned to an office that is listed in this field. No extra access to activity records is granted. Edit all If this is enabled, members of the group may edit all cases and all activity records. users Grants access to the User Account Management screen. pba Grants access to the Pro Bono Attorney Management screen. motd Grants access to the Message Board Configuration screen. LSC requirements and defaults: Pika collects all information required for LSC, SMRLS, and other funders. Using the same protocols as in Kemps, LSC recommendations for blank default fields are met. Warning flags serve as visual reminders to staff about missing information on possible conflicts, missing income, over income, missing assets, missing citizenship status, missing funding codes, and missing problem codes. Additionally, a standard set of queries/reports will be designed to run checks to pick up records where information is missing. 2
Reporting: LSC reports are complete except for "Other Matters": CSR done Age/Race done LSC Litigation Report done Other Matters (under development) Ad Hoc reporting. Desktop reporting is an ongoing (probably forever) and ever improving area. SMRLS staff want to be able to retrieve a variety of information without having to contact me. Both the Advanced Case Report and Advanced Activity Report allow choosing which fields to show on reports. Staff like being able to choose the information they want displayed on the report. Other Reporting: Complex reporting and other specific reports are done through an ODBC connection using Microsoft Access. Querying and reporting is performed on a "read only" copy of the current database -- just in case I happen to say "DELETE" all. Calendaring, casenotes, and timekeeping are integrated into one screen. Some nice features such as running totals on time and funding codes are included in the calendar section. Conflict checking is done automatically. Staff are encouraged to also search the Address Book (master contact list) as a double check for previous contacts and/or possible conflicts. Document Assembly: This has been designed for easy addition of new letters and forms. Documents are saved in a generic rich text format. SMRLS still uses WordPerfect, so Rtf version compatibility will take some tweaking. Envelope templates with logos work very well. Letter templates with lots of staff names sometimes fall apart. For now, we won't list staff names on the letterhead for larger offices. Document Assembly Documentation: Setting up Document Assembly/Generation To set up Pika's document generation, first create the form letters that will be used, then copy the form letter files to the "forms" directory on the Pika server. Creating Form Letters Pika Form letters are regular word processor files. To be compatible with Pika, they must be saved as RTF (all popular word processors, including Word Perfect and Microsoft Word support this file format.) Adding Template Codes Pika uses a list of "template codes" to determine where to insert information from the Pika database into a form letter. A template code is simply a code word, enclosed on each side by two percent signs and a bracket. For example, the template code to show the case number is %%[number]%%. To add a template code to a form letter, simply type it into the document, placing it where you want the information from the database to appear. 3
Here is an example that will display the client's name, address and primary phone number: %%[first_name]%% %%[middle_name]%% %%[last_name]%% %%[extra_name]%% %%[address]%% %%[address2]%% %%[city]%%, %%[state]%% %%[zip]%% (%%[area_code]%%) %%[phone]%% Every field from the cases table in the Pika database is available for use as a template code. Pika will also use every field from the primary client's record in the contacts table as a template code. Here are some additional template codes that are provided as a convenience: %%[client]%% - primary client's first and last name %%[opposing]%% - the opposing party's first and last name %%[counsel]%% - the primary counsel first and last name %%[opp_counsel]%% - the opposing counsel's first and last name %%[recipient]%% - first and last name of the person receiving the generated form letter %%[recipient_salutation]%% - the recipient's name, formatted for use in an opening salutation ("Ms. Smith", "Mr. Jones", etc.) Copy to the Server When the form letter is ready for use, save it and copy it to the "forms" directory in Rich Text Format on the Pika server. Once in this directory, the form letter will automatically be available the next time the Pika document generation system is used. Using Document Assembly/Generation To generate a form letter in Pika, first open the case for which the document is being created. Go to the "Documents" tab, you should see a section labeled "Form Letters". Choose which form letter you wish to use from the menu labeled "Available Forms". The other menus allow you to choose to whom the letter should be addressed, and which client, opposing party and opposing counsel should be used to fill in the form (this is useful if a case has more than one client, opposing party or opposing counsel.) Click the "Make New Doc" button, and the document will be generated and sent to your web browser. Depending on how your computer is configured, the document might open in your word processor application, it might be displayed in your browser window, or you might be prompted to save the document on your hard drive. To change this behavior, see your browser's manual. Document Management: Aaron plans to incorporate full document management and is currently working on this. Groupware - future item. At some point, email, program-wide calendaring and scheduling will be integrated into Pika. Pro bono sections are currently integrated in Pika. This area is currently being expanded to include tracking of Contract/Compensated cases. Future item -- a separate Pro Bono/Conflict database. Pika's proposed case transfer features would make this very workable. Aaron's proposal for a separate pro bono system is included below. 4
Separate Pro Bono Proposal: Proposal: Implementing a Separate Pro Bono CMS To eliminate certain conflict of interest issues, it may be advantageous to maintain a standalone Pro Bono CMS database separate from the Staff CMS database. To make this feasible for SMRLS, I propose adding a transfer function to Pika CMS. Under this configuration, the Staff and Pro Bono systems would operate off separate databases, and the new transfer function would be used to send case data back and forth. The transfer feature would consist of 6 components: 1. A function for transferring a case to a different Pika CMS 2. A network interface for receiving an incoming transfer case 3. A mechanism to allow only trusted hosts to access the transfer interfaces 4. A screen which will list all incoming transfer cases, and allow the user to accept or decline them 5. An "inbox" feature where transferred cases will reside, separate from other case data, before they are accepted or declined 6. Controls to limit access to transfer functions, integrated into the existing Pika CMS security framework Project Costs Labor estimate breakdown: Task Hours Required Design and implement prototype transfer function 32 User testing, and follow-up modifications based on user feedback 32 Installation of standalone Pro Bono CMS Installation covered under Pika subscription Migrating pro bono data from Staff system to Pro Bono system 4 Final testing and verification of Staff CMS <-> Pro Bono CMS transfer link 2 _ Labor costs: $3500 (70 hrs. x $50/hr.) _ Software & hardware costs: none The total cost to SMRLS for the project would be $3500, payable upon completion of the separate Pro Bono database. This is a fixed cost, schedule overruns will not affect this figure. System administration and maintenance features, as much as possible, are built directly into Pika. Some of these are: User Account Management - Configuration screen for easily adding users, assigning passwords, and enabling or disabling accounts. Configuration screen for adding fields to the tables. Changes to the front-end PHP forms are done through an html editor. Menu Configuration - Configuration screen for adding/changing picklists. Where possible, selections are made from a picklist to help improve data integrity. Ask if I like having consistent data! User Preferences section where users can choose their default office, case list length, and Pika screen colors. Backups: Covered in triplicate! A batch file backup runs remotely every night to the Mankato office; A script configured to backup across the Central office LAN runs nightly; and a 12/24 DAT backup to tape runs nightly. The most current backup tape is taken off-site each day. 5
SMRLS has been increasingly sharing attorney and intake staff resources among our offices in the last several years. Centralization of the database is making resource sharing even easier. We hope this will lead to even more efficient use of staff and even better service to clients. Pika is ideal for access from multiple locations. Users have adapted well to learning yet another program. Suggestions and requests for additions or changes are sent to me. All requests and suggestions are circulated to Aaron and a few SMRLS staff persons for discussion on whether to make the changes. Intake people find Pika quite easy to work with. They especially like being able to have multiple client records open at one time. Integration of case notes, timekeeping, and calendaring has encouraged staff to use all of these to a greater extent than previously. Aaron's skills, commitment, and patience have resulted in a very affordable, flexible, and workable legal services casemanagement system. Overall, making this major switch from Kemps to Pika CMS has been exceptionally successful. Respectfully submitted, Lolita Oorlog Technology Manager Southern Minnesota Regional Legal Services, Inc. Lolita@smrls.org 6