Examples of paper records that are used to determine SFST refresher training requirements were reviewed, along with the three computerized spreadsheets, mentioned previously, that were developed by DUI supervisors to help track SFST and other recurrent training. This review of documents, combined with procedural information obtained during the discussions, led to the identification of a preliminary list of data elements for the model SFST training management system.
Next, a computerized spreadsheet was configured, using the preliminary list of data elements as header titles, to evaluate the concepts and the appropriateness of candidate field names. Concepts and field names were modified in an iterative process to accommodate the desired system capabilities and incorporate human factors design principles. The results of this effort are, 1) the list of data elements, presented below, and 2) the system features described in the following paragraphs.
Because the primary purpose of the system is to alert officers and managers to SFST refresher training requirements, the key data element in the list is the Deadline for Next Refresher Training/Review.13 An optimum records management system would calculate this date automatically from the values entered in Refresher Course/Review Interval to Maintain Certification and either Initial Training Course Date or Date of Most Recent Refresher Training/Review, whichever date is more recent.
The system also should be capable of generating reports in response to queries, such as, "List of Officers Whose Deadline for Next Refresher Training Occurs in (specified) Month." This capability would permit systems administrators to periodically identify the pending refresher training requirements of individual officers, and if performed quarterly, would facilitate the scheduling of inservice courses for an agency. Further, the system could be designed to generate notifications automatically and send them to the Officer's Email Address.
The model system should be capable of generating reports of individual officer's training histories, for example, to be used to confirm credentials in court or assist in performance reviews. The system also should be capable of producing reports that are statistical summaries, for example, the numbers of officers who have received SFST initial training, or refresher training during a specified period. These and other prepared reports should be accessible from the system administrator's interface.
To be optimally useful, the system should include a relational database of modular design that would permit a law enforcement agency to track other periodic or recurrent training or certification requirements, in addition to those associated with SFSTs. That is, the system administrator's interface should include the capability to create additional modules devoted to other training requirements. The data element, or field, names listed previously appear to be sufficiently generic and comprehensive for this purpose. In this regard, the optimum design would permit the system administrator to select Create New Module from an administration menu, enter the name of the new module (e.g., First Aid, Tactical Driving), define the recurrent periodicity for training or certification, then populate the database with officer training information. The names of the training modules should be added automatically to the system's main menu as they are created.
Finally, the system should permit the importing of data from legacy systems, to facilitate initial data entry, and in other ways incorporate established human factors design principles. The system should permit the exporting of data so that agencies could periodically submit their SFST training information to a centralized, master database of practitioners and/or instructors. That is, the system must be scalable to permit use by individual agencies, as well as to serve as the central database by importing all agencies' SFST training information.
During the design process, it was found that a properly-configured spreadsheet could accommodate most of the capabilities and features defined for an optimum system. However, even skillfully-designed spreadsheets cannot provide the automatic reports and notifications identified as important system specifications. For this reason, a prototype system is being developed using Microsoft Access to create the relational database and administrator's interface. The prototype system is currently under development.