Data is stored in a relational manner.
A client table lists the demographic details for each client. Separate entries in the visit table list all aspects of each appointment.
Tables of Symptoms and other sensitive aspects of client assessment are listed in separate tables and numerically accessed from each client's visit record. All entries in the Client and Visit tables are checked for corresponding entries in the lookup tables.
The bulk of information is in the notes where privacy is the highest priority. Each set of notes has been broken into a set of short records so as to break up the continuity to the casual visitor the database (possibly an IT person). All special punctuation and control characters have been encoded into a limited character set.
The data will reside in a set of tables in an Access database on the server. This data will be as secure as the server's hardware and software access allows. IT support persons will be able to bring up the database and examine it but most data will be privacy encoded. No queries on the access database will allow casual aggregation of data. Only the server Java software aggregates relational data. Network access is only by password validated user accounts.
The notes are the main area to be protected from casual lookers. It is also the area where staff members expend the most effort so protection needs to be very reliable. I am developing a substitution algorithm so the notes will not look attractive to casual browsers or even prospective hackers.
Users (staff) will be asked to log on with a username and password. If no user activity for a specified time, the user will be asked to logon again before the system will action further commands. Most staff will keep the system continuously open on their timetable display when not working on the notes and therefore this screen should not time out.
Each user will primarily belong to only one functional group (Counselling, Housing, Medical, Finance, etc). They may also have secondary memberships of other functions so they can see all information about their own clients from those other functions. The data and notes they generate will generally only be accessible by their own function, but check boxes will be available in data and notes generating screens to make data and notes available to other functions that the staff member is a secondary member of.
Communications is by TCP/IP and will incorporate a Secure Socket Layer (SSL) protocol, a feature now available in the standard Java SDK. A certificate will be produced by the Java Toolbox and distributed separately to all user PCs.
The main components of the CDB system are Booking, Communications, and Client Data and Notes.
Booking: The system maintains a list of days for which each staff member is available at each locality. Clients are booked to see staff at certain times and locations.
Communications: When clients arrive at their appointments where there is a reception function, their arrival can be signalled by reception through the system to the relevant staff member who will receive a beep or a popup message. Similarly, a staff member may communicate to other predetermined staff members during the consultation, e.g., for someone to phone. The system will prompt each staff on the list in turn until one acknowledges to the system that the action will be taken.
Data and Notes: Personal details such as address and background information are maintained in an information screen for each client. More sensitive notes and analytical details are maintained in another information screen. Access to the more sensitive information is restricted to the staff with access to that function (Counselling, Housing, Medical, Finance).
User documentation will consist of a document showing how to action all features in all screens. An index will be provided.
System documentation will be produce by the Javadoc program being applied to the source code. This gleans documentation information from the source code and will be readable with links in a browser. All software procedures will be documented with usage, main interaction with other routines and functional explanation. The advantage of Javadoc is that the resultant html documentation is automatically updated when the source is updated and that all links are available to an html browser. There will also be an over view showing the interaction between client, network and server functions.
A similar system has been operating at RMIT for over three years. It was based on an Access database as the backserver and another linked Access database for shared access by clients. This technology worked well for up to about a dozen staff but would not scale well to a larger system.
The new CDB system has been tested on a 64 Mbytes RAM, 230 MHz Pentium II both serving and acting as a client. The time to move between screens was less than two seconds. Faster machines will produce proportionately faster screen refresh times. The server software is expected to be hosted on a much faster PC but even the slowest PC's should be ok as clients. Tests on a 1.6 GHz 256 Mbytes laptop show average turn around time on client requests to be less than 20 mS except for the initial sign on when the lookup tables are transferred which takes about 300 mS. Not all users will log on at the same second so for 30 users the wait for any client should be less than two seconds. If the system grows to more users a faster server could be found to install the server software on. PC Java programs can equally run on Unix systems so there is always a hardware upgrade path.
No measurements have yet been made of network congestion and its effect on user times.