University Directory (aka Demographic Database) Meeting Notes
April 15, 1998 Conference Call
Participants:
Barry Cunningham (SB), Jim Dolgonas (OP), Richard Drake (SF), Kathy Keller (OP), Debbie Lauriano (DV), Helen Lee (BK), Trish Lyons (RV), Ed Martinek (SF), Bob Merryman (SD), Benny Min (OP), Caroline Rider (IR), Richard Tamm (BK), Vance Vaughan (BK/OP), Jerry Wilcox (OP), Don Worth (LA)
General Announcements:
- 04/30/98 reconfirmed as Phase I due date for production deployment of University Directory including start of Net ID generation by University Directory and Campus Authentication Interface from University Directory
- General Counsel verbally confirmed in 04/13/98 meeting with Stuart Lynn et al that use of Student ID (a.k.a. Registration Number) for University Directory project would be FERPA compliant; formal write-up would be issued after receipt of additional write-up from Jim to General Counsel (Jim sent this to General Counsel on 04/16/98)
Issues (supplementing issues raised at prior meeting) and Conclusions:
- more clearly defined data element definitions need to be developed, e.g., Campus Mailing Address should be an address that would be supported by the US Postal Service for a mailing and not just for intra-campus or inter-campus mailings
note: it should also be clarified which data elements can house multiple values, e.g., there is one social security number per individual, but there are one-to-many addresses per individual
- what are disclosure rules, procedures RE: data access to those outside the University Community, e.g., campus issues a certificate to a student who uses it to access a vendor system or database
- the "Working Title" data element is currently maintained differently at different campuses, e.g., UCLA and UCSD support multiple "Working Titles" per employee whereas UCI supports a single "Working Title" per employee; thus, again, need to clarify which data elements can house multiple values
- employee self-service (ESS) application update processes should be heavily scrutinized before determining which fields will be allowed to be updated, especially in light of the ramifications of what will be passed on their corresponding interface back to campus-run systems such as Payroll, e.g., Employee Name, Department Name, Alternate Address fields
- supplementing daily payroll and student interface processes, a daily "directory" interface may be required
- generation of Net IDs for students by the University Directory was requested not to be limited to students who actually enroll and pay registration fees at a campus; supplementing this population objective is the inclusion of all students who are admitted to any UC campus
note: simply applying, however, will not require the University Directory to issue a Net ID, i.e., the student must still be admitted to a UC campus; further, the University Directory must still be able to distinguish between those students who have and who have not paid registration fees
- a new Educational Testing Service (ETS)-to-University Directory interface may be developed to support the above item; given the "central clearing house" functionality provided by ETS, this process would also provide the benefit of reducing the generation of multiple Net IDs by the University Directory in the case of a student who was accepted by multiple UC campuses; this is due to the existing ETS process whereby a unique ID is established by ETS for an applicant, regardless of the number of campuses to which the student applies; this ID would be passed on the ETS-to-University Directory interface; the University Directory would, in turn, generate a Net ID and pass the Net ID as well as the ETS ID to the Campus Student Systems on another interface
note: further details are required RE: the ETS ID, e.g., is it unique across multiple terms and/or academic years; also, the ETS interface may well only entail undergraduate data and/or other caveats, e.g., only for the fall term
- production daily interfaces of Campus Student System data to the University Directory will not be required for implementation in calendar 1998; UCLA and UCSD reported that 1999 would be the earliest that they would want to commit to any such timetable; however, UCLA noted that it is considering a pilot test in fall of 1998 that includes campus students and so, requested that initial Campus Student System-to-University Directory interface specifications be distributed prior to fall of 1998 so that UCLA would have the option of implementing its pilot test that utilizes the interface
- though administration details have not yet been determined, a "release flag" process should be developed which supports data element access controls for an individual that are administered by the individual for the following data elements:
- Name
- Address
- Phone Number
note: it was reported that the UCB Student web application which provides varying of levels of data on its student population, e.g., student name, actually does not include its entire student population; that is, it does not include those students who had declined inclusion in the web application's database; this raised again the issue of someone being "disadvantaged" by not being in the University Directory, even if by explicit choice
Next Steps:
- distribute meeting notes to group
- distribute General Counsel write-ups (initial response available; awaiting second response) to group
- participants would follow-up with campus system contacts on issues raised during conference call, e.g., check with Payroll Managers to determine if their campus' Payroll System maintained "work address" information and in what format, i.e., what data elements are maintained
- provide more detailed information as to the design of the University Directory (database)
- propose next conference call ideally to be held in May 1998
Return to Meeting Agendas & Minutes Page