NIH Directory Project
Steering Committee Meeting Minutes
May 25, 1999
Participants:
Akinyele Akinyelu (Junior)-CIT
Tom Bodine-CIT
Bob Borah-CIT
Bonnie Cramer-NINR
Keith Gorlen-CIT
Andrea Hobbs-NIAAA
Rob Malick-CIT
Diane O'Neill-ORS
Donna Pearman-NCRR
Doug Price-NHLBI
Tina Roark-NHLBI
The meeting consisted of a fourth demonstration of the Fast Track Directory user web interface. As part of the demonstration, we simulated the registration process for a new FTE with information being entered into the interface by an AT. The request was then submitted to an AO for review, approved, and added to the directory. As usual, in addition to comments regarding the interface itself, there were numerous related discussions centering on current NIH business practices and how to accommodate them within the context of the Fast Track.
The question was raised as to whether the NIH SAC should be a required attribute (currently it's not). It was agreed that the SAC attribute in the directory could be "null" (not required), but that it would be a required field as far as the Fast Track interface is concerned. The possibility of providing a drop down SAC list was brought up, but the group decided that this would be too long and in many cases, SACs are already known by the AO. However, the interface will be designed so that the AO/AT has the option of clicking on a button next to the SAC field that will bring up a list of SACs for that particular IC. Clicking on a SAC from the list will insert it into the field. It was suggested that it might be worth checking out the Office of Education web site.
Also relating to SACs was a discussion concerning how to determine which AO is responsible for approving changes entered into the Fast Track interface by a given AT. Until now, it had been assumed that changes entered by an AT would be reviewed by a single AO. As it turns out, ATs will be called upon to input data with the responsibility for review falling on multiple AOs within an IC. Thus, a model that better reflects the existing business practice is to use a person's SAC as the key for determining which AO is responsible for the review and approval of a Fast Track entry. This functionality will need to be designed into the Fast Track user interface.
With respect to AO review of requests submitted by ATs, it was indicated that there would be a need for "primary" and "alternate" AOs. As currently designed, the interface only allows a single AO to review change requests for a particular directory entry. This would be problematic in instances where the AO was out of the office and an entry needed to be created or updated before the AO returned. As a result, one or more "alternates" will need to be designated for each "primary" AO. Alternates will have the ability to access and approve/reject queued requests for directory entries normally under the purview of the primary AO. Ideally, queued requests for primary and alternate AOs will be grouped separately in order to provide easy access.
It was suggested that visual indication of queued requests be provided on the main menu when an AO logs on to the interface, or possibly even the names of persons with entries to be reviewed listed. Another opinion was that a visual cue isn't necessary since AOs will receive email notification when an AT submits a change. In the end, it was decided that an unobtrusive message would appear in the lower left-hand portion of the main menu indicating that there are pending requests for review.
It was suggested that the layout of the "review details" screen be redesigned to mimic the data entry screens (i.e, those used during registration and update). The benefit of the current format is that it shows "old" values and "new" or changed values side by side, which might be difficult to do using the data entry screens. The objection to the current format appeared to be stronger in the case of a registration because so much data is listed. In an update scenario, it is far less likely that the displayed review list will be as long. In any event, this issue will be explored to come up with a viable solution.
Another issue pertaining to the review process is that currently an AO must accept or reject all changes, and that once rejected, all data that had been entered by the AT is lost. AOs were okay the concept of a simple acceptance or rejection of a request, but felt strongly that there be a way to store the entered data somewhere so that an AT would have the option of reentering only selected information before resubmitting the request to the AO. This presents some potentially challenging technical issues, but all agreed that it is an important capability of the Fast Track. Options will be explored and reported on at a future meeting. Finally, AOs suggested that it would be useful to be able to provide an explanation to the AT as to why a request was rejected. This seems feasible in terms of allowing the AO to type a message that would be included in an email to the AT saying that the request had been rejected.
The subject of email notification to AOs when an AT has submitted changes for review initiated a more in-depth discussion of email notification in general. The belief was expressed that email is not an effective notification tool since some people are already inundated with useless email messages and additional messages would simply exacerbate the problem. Nonetheless, there seemed to be a consensus that email notification was a good thing. Present plans call for email notification as follows:
 | AOs will receive notification when an AT submits a change for review (change is defined as an update to an existing Fast Track entry, including a change of status, or the registration of a new worker). As mentioned above, the SAC of the person whose entry is being changed would determine which AO received the email. |
| Following AO approval and updating of the Fast Track, email notification would be sent to the person whose entry was affected as well as to the AT who originally submitted the change. If a change is entered and submitted without an AT's involvement (i.e, done by an AO), only the affected user would be notified. |
| Alternate AOs will not receive email notification for changes made to directory entries under the purview of a primary AO |
There was a discussion regarding whether it was necessary to bring back the manager attribute for the issuance of PKI certificates. It was determined that this is not necessary since AOs already serve as de-registration officials.
The issue of multiple IC affiliations was raised during the meeting. While the number is very small (approximately 15 people within all of NIH appear to be affiliated with more than a single IC), the question was posed as to whether it's necessary for the Fast Track to accommodate this phenomenon. There was unanimous consent among committee members that it is not. Aside from the fact the number is small, it was felt that in almost all instances it would be possible to identify a single IC as the person's primary affiliation. Similarly, it was deemed acceptable to designate a single office location, phone number, and employee type designation (e.g., FTE, contractor) in instances where a person had more than one.
A couple of issues were raised with respect to data entry. First, it was suggested that the contractor affiliation and phone number fields be grayed out except in instances where employee type = contractor. This will be looked into. In addition, someone inquired whether it would be possible to have dashes automatically inserted in phone number fields to make them easier to proof. The answer is yes, however, the area code, exchange and number would need to be in separate fields thus requiring users to tab or mouse from one field to the next. As it stands, users have the option of entering phone numbers without dashes, which are automatically inserted upon clicking on the update button. Thus, phone numbers are displayed with dashes on the "Update Confirmation" screens. This possibility of having "floating" dashes within a single field will be investigated. Finally, the feasibility of providing a mechanism such as a lookup table for GS Series Codes will be explored.
------------------------------------------------------------------------------------------------------
Next Meeting:
Tuesday, June 8,1999
2:00 pm - 4:00 pm
Building 12A, Room 4039