Christi Bengard (SC), Ann Dobson (BK), Jim Dolgonas (OP), Jann Fong (BK), Debbie Lauriano (DV), Helen Lee (BK), Trish Lyons (RV), Dan Maria Cui (SF), Bob Merryman (SD), Benny Min (OP), Michael Strizich (SF), Vance Vaughan (BK), Jerry Wilcox (OP), Don Worth (LA)

Issues (supplementing issues raised at prior meetings) and Conclusions:

• BK, DV, SD, and SF campuses reported that either they had received word that the proposed student interface specs were acceptable and/or had not heard back of any problems; RE: the latter group, more formal confirmation would be pursued with their respective student offices
  
  
• new, additional Student Status values were accepted for inclusion:
  • B - blocked students
  • F - filing fee students
  • W - students who had withdrawn
  
  
• new, additional Student Type value was accepted for inclusion:
  • P - professional schools including JD, MD, and DDS

    note: would not include MBA (which would still be considered a Masters Candidate (M))

  
  
• a new Student Term Eligibility End Date field will be included on the interface; this will allow for those campuses who wish to effect a "grace period" for potential services to be extended while still maintaining the integrity of the Student Term End Date field; those campuses not wishing to effect such a period can simply pass the same value in this field as posted to the Student Term End Date field

  note: the eligibility "begin date" would simply be the same date passed in the Student Term Begin Date field
  
  

• the length of the Student College and Student Major fields would be revised to a length of 50 characters; however, those campuses wishing to adhere to the current length defined in the Corporate Student System may still elect to follow those standards
  
  
• the length of the Student Local Address 1, Student Local Address 2, and Student Local Address City fields would be revised to a length of 32 characters
  
  
• a new Student Plus 4 Zip Code field will be included on the interface, analogous in function to the "Plus 4 Zip Code" field on the latest "directory" interface specs

  note: campuses can pass this data with or without a leading dash as the database load process will address uniform formatting
  
  

• a new Campus ID field will be included on the interface; data passage will be optional and will accomodate the potential need of campuses who are in the process of implementing a campuswide unique value, but who have not updated their student systems to house this value in the student registration number field or their payroll systems to house this value in the employee number field, for example
  
  
• it was reconfirmed/clarified that student data was generally not to be deleted; that is, Record Code "D" (delete) records passed on the interface would normally only be passed for student data that had been erroneously passed; otherwise, data for a student who attended school for only one term, for example, would not be deleted during subsequent terms

  note: it was not yet determined for how long records would be kept in the University Directory for students such as those cited in the example above as well as for others no longer registered, etc.
  
  

• no further revisions were requested to be applied to the Student Release Flag document (09/22/98 draft)
  
  
• "multiple Net IDs" per person issues were raised again; while there are a slew of ID numbers (SSN, employee number, student registration number, Campus ID, etc.) requested on the various interfaces, it was noted that it would still be likely that 100% data integrity would respect to the "multiple Net IDs" would never be reached; further, administrative procedures would need to be developed to address processing such cases, analogous to processes already in place at some campuses who have implemented a unique, "Campus ID" at their location

  Previous discussions were also cited again where the general consensus had been that there was generally more concern with the "multiple Net IDs" issue within a campus and less so, relatively, with the issue universitywide
  
  

• timetable was again cited where those campuses who are ready, could submit daily student interface files as of the first working day in January 1999, while the remaining campuses should plan to submit their daily student interface files no later than the last working day in March 1999
  
  
• question was raised as to who would be receiving the finalized student interface specs when they are to be officially submitted to the campuses; it was noted that these would likely be sent to JOG members with cc's to the functional office, i.e., student registrars
  
  
• following another meeting last week with General Counsel, Jim was apprised to expect written communication this week; however, text may simply cite "risks" involved in using social security number in this process rather than providing formal approval
  
  
• after the student interface specs are finalized, coding can begin on the utility to generate "add, change, delete" daily interface files for campuses whose student data can only be readily generated in daily full volume extracts; a timetable for making this optional utility available to campuses would also be provided
  
  
• discussion resumption of the "directory" interface specs will be deferred until the student interface specs can be finalized

• distribute updated draft for proposed new student interface specs, meeting notes, and proposed dates/times for next conference call to group in the next couple days



• additional policy documents should be written to clarify usage of student interface data elements

Return to Meeting Agendas & Minutes Page