EHS Training Interim System

Jim Repa - 9/20/2002

I. Two-phase plan

The EHS Training subteam decided on a two-phase plan for implementing systems for training. We expect that the long-term training delivery and record keeping system at MIT (Phase II) will be an integrated campus-wide system based either on software being developed under the Open Knowledge Initiative (OKI) or on the training module within SAP. However, neither OKI nor the SAP module was judged to be sufficiently mature to support the 2002-2003 requirements for EHS training, so an interim solution (Phase I) was necessary.

The two phases can be summarized as follows:

Phase I. (2002 until at least the summer of 2003)
Phase II. (some point after the summer of 2003, timing to be determined later)
The remainder of this document will discuss the Phase I (interim) training solution.

II. Why do we need a separate server (EHSWEB) in addition to Traincasters?

The EHSWEB server, housed and managed at MIT, is a front-end to the Traincasters system. Users go to EHSWEB first to record some information about their affiliations with DLCs and PIs or supervisors, and fill out "needs analysis" information, i.e., a list of activities they perform that are associated with training requirements. The EHSWEB server then determines each user's web based training needs and automatically redirects the user to Traincasters to actually take the web-based courses.

There were several reasons for the decision to use a separate front-end server at MIT in tandem with the Traincasters system to support training. The reasons for this decision are the following:

  1. Getting around records and reporting limitations in Traincasters system
    We know that it is common for people in the research community to simultaneously work in more than one lab under the supervision of more than one PI and more than one DLC. Training reports should reflect this, allowing a person to appear under more than one PI or more than one DLC where appropriate. The Traincasters system works under the model of tracking each person to a single "group".

    We also expect to be merging records for classroom-based training and web-based training in our training reports. Handling this in Traincasters would also involve custom modifications.

    It was determined that it will be less costly to MIT to use a front-end server to keep track of the multiple-PI or multiple-DLC connections for people, in addition to classroom-based training information, rather than pay Netcasters to do significant modifications to their system.

  2. Avoiding unnecessary dissemination of MIT employee and student information to an outside vendor
    The registration process for a user can leverage information available for that person in MIT's Data Warehouse, filling in information about the person's Email address, and at least partial information about the person's Department affiliations. The information about a person from the Warehouse can be put up on a screen automatically once a person connects to the EHSWEB server using their MIT certificate. If we did not have the front-end EHSWEB server and had users register directly at the Traincasters site, either (i) we would have to give the outside vendor access to employee and student information for all 25,000+ people at MIT, or (ii) we would need to have each person rekey his/her Email address, DLC affiliation, etc. from scratch in Traincasters. Option (i) is not desirable - generally we discourage dissemination of MIT information on all 25,000+ people in the MIT community to outside vendors. Option (ii) is also problematic because it requires trainees to enter data that is already available in the Data Warehouse.

    (Note: We do send Email address, course requirements, and other items of information required by Traincasters, but only for registered users of Traincasters, not the whole MIT community.)

  3. Limiting outside vendor custom development during the prototyping phase for the needs assessment
    Starting in the summer of 2002 and extending over the next 3-6 months, we will be deciding on the rules for training, i.e., what factors trigger a person's need to get training, and what specific courses or other requirements must each person complete. During this period, we will be prototyping a system to manage training needs assessment. It was determined that it will be less costly to MIT to do this prototyping work at MIT rather than paying Netcasters to make continuing modifications to their system.
  4. Getting a simple needs assessment and registration solution working quickly, yet allowing flexibility for phasing in a more sophisticated solution
    Traincasters expects each user to be registered for the specific courses that they require. The decision for which courses a person needs is made in the local MIT front-end system (EHSWEB) as the person registers, and the information is passed onto Traincasters when the person is automatically redirected to Traincasters. This mechanism was put in place in June, 2002, so that trainees could start to register and take the first 3 training modules made available in Traincasters. We will continue to evolve the needs assessment and add other course modules in the coming months.

    Having the needs assessment component of the software on MIT's local EHSWEB server allowed us to do a quick and simple needs assessment for the first few modules, and to continue to evolve the needs assessment within our own control, without having to schedule repeated software changes with corresponding charges from Netcasters. Thus, we have been able to economically install the first needs assessment system and to continue to evolve it with very low cost to MIT, and without the need to coordinate each prototype change with the outside vendor.

III. How does the EHSWEB server work to support training registration and needs assessment?

The EHSWEB includes a database; Perl scripts to get data from the Warehouse, the Roles Database, Traincasters and other sources; Perl scripts to send data to other sources; and a web server with various CGI scripts. Some CGI scripts are interfaces for updating the database; wherever the database is updated via a CGI script, there are PL/SQL stored procedures enforcing authorization and data integrity rules.

Summary of components:

IV. Decisions, analysis, and development in the interim system

A. The Data Model for training requirements, in a nutshell

We propose a data model for defining training requirements that includes the following entities:

In addition to the general rules for who needs to obtain various certification types and what requirements are associated with each certification type, we will need to keep track of data for each person, e.g.,

B. Separation of issues

I'd like to point out that there are some separate training-related issues to be resolved that do not have to be resolved at the same time.

The following three issues, though related, are separate and do not need to be resolved all at the same time:

  1. What are the general types of criteria that will be considered in determining a person's certification type requirements (and thus, a person's course or other requirements)?
    Here, we are interested just in the general types, not all the specific requirements. So far, we expect to be looking at (i) activities a person performs, (ii) DLC affiliations, (iii) proximity to certain hazard types, (iv) job titles (for people in a few departments only), (v) enrollment in certain lab courses. Once we know that we've got a reasonable starting set of general kinds of requirements, we can build a prototype system to store and evaluate these requirements. To build the system, we do not need to know all the specific rules, but just what kinds of rules we need to support.
  2. What are the specific rules for certification types, and the course or other requirements for each certification type?
    Here we want to list the actual specific rules. Once there is a prototype system to store these rules, we can start putting them into the system and trying them out.
  3. How are we going obtain information about people, either by deducing it from other data, or by directly collecting it, so that we can apply the rules and determine people's training requirements?
    Once we have an idea what the criteria are for determining certification and training requirements, we need to determine how we will know who fits these criteria. There could be a combination of self-reported data, data collected or at least reviewed by supervisors or "C-level" people, and data deduced from other sources. To satisfy the spirit of the Consent Decree, and to satisfy auditors who will review our systems in the future, we need to be able to show reasons why our process for collecting or deducing this information is reliable and auditable.