The function that seeks to be addressed by this specification is the efficient booking and conducting of clients meeting with professional staff performing a number of functions at a number of locations, and then the efficient generation, maintenance, and security of data associated with the results of the meetings of clients with staff.
The system is to be computer based. Each professional staff and support worker shall be able to access the system via a TCP/IP based client communicating with a server system. Access of all staff users is to be controllable via a table of accesses at different levels to the functions the staff member belongs to.
The main components of the CDB system are to be Booking, Communications, and Client Data and Notes.
Booking: The system is to maintain a list of days for which each staff member is available at each locality. Clients should be booked to see staff at certain times and locations. Bookings should be able to be made by any staff member with system access.
Communications: When clients arrive at their appointments where there is a reception function, their arrival should 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 press a pre-allocated function button on the client software to communicate to other predetermined staff members during the consultation, e.g., for someone to phone back. 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).
Staff Access Control: Supervisors for each function should be able to access the staff access control screen via the staff list, to be able to allocate the appropriate access levels (i.e., which screens they can access) for all their staff members and their functions.
The client system will need to present a number of screens on which to view and enter data.
Timetable: The timetable screen will either display a weekly or a daily view. In the weekly view, staff are to see one column per day for each locality that they may be booked for with the heading for each column to list the staff reference and the location. In the daily view, the timetable may be cycled through the available locations, with each location’s screen showing all available staff and the heading for each column to show a reference to a staff member. The dates on each screen are to be easily stepped forward or backward. This screen is to become the launching pad for most other screens.
Name: The name screen is to be reached by entering minimal data in the Timetable screen Name fields. New names may be entered here or an existing name selected. In either case, the client name may then be used to make a booking on the timetable screen, enter the demographic screen, or enter the client’s visit list.
Client List: Where the user has full access, the timetable screen will provide a button to link to that staff’s client list.
Staff List: The staff list links the timetable screen to the availability calendar screen. It is entered through the availability button and in turn generates the calendar screen for the selected staff member.
Availability Calendar: The availability calendar screen is to show all locations and days in a month that the selected staff member might be booked for. Buttons are to step into past and future months. Clicking on a date for a location will flip the system between selecting and not selecting that date. Additional icons will allow the user to select days of the week or a whole week or month at once. Columns in the timetable screen will only be shown if the staff member has been selected for those days in this calendar availability screen.
Demographic Data: Personal particulars of a general nature will be shown on the demographic data screen, one for each client. This screen should show when the timetable entry for that client is clicked or from a selection on the Name screen. Data will be presented in a number of fields, comprising text fields, yes/no boxes, dates, numeric and drop down combo boxes. Data will only be saved when the user presses the save button or responds positively to a "Do you want to save?" request on exiting the screen.
Visit Table: All visits by one client will be listed in a table on this screen for all functions that the staff user is a member of. Users should be able to view and edit administrative details about all listed visits, saving any changes immediately.
Visit Data: The Visit Data screen should allow the user to view and edit clinical detail/notes about a visit session. For counselling, two drop down combo boxes are to be provided to record the issues and two similar boxes for the academic issues involved. A text area control is to be provided to allow unlimited entry of free text representing the notes for that session.
Data is to be stored in a relational manner.
A client table is to list the demographic details for each client. Separate entries in the visit table should list all administrative aspects of each appointment. Notes are to be stored in a specially constructed table allowing for privacy and fast retrieval.
Tables of Symptoms and other sensitive aspects of client assessment are to be listed in separate tables and numerically accessed from each client's visit record. All entries in the Client and Visit tables are to be checked for corresponding entries in the lookup tables.
The bulk of information will be 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 should be encoded into a limited character set.
The data will reside in a set of tables in a database on the server. The database is to be accessed by the server system via an ODBC driver. This data will be as secure as the server's hardware and software access will allow. IT support persons should be able to bring up the database and examine it but all sensitive data should be privacy encoded. No queries on the access database may allow casual aggregation of data. Only the CDB server software is to aggregates relational data. Network access is to be 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. A simple substitution algorithm could be used 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 the user is inactive 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.
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 to be by TCP/IP. Communications will consist of question and answer sessions between the clients and a server. Each transmission is to be error checked and encrypted with a pseudorandom key.
User documentation will consist of a word document showing how to action all features in all screens. An index will be provided.
System documentation will be automatically produced by a documentation program be applied to the source code. This will glean 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 this 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.