People Database Status Update

BACKGROUND

STUDY

Based upon input from school and center information managers, a 
proposal was developed to address the highest priority issues: SSN 
integrity, information privacy, redundancy.  The proposal contained 
three alternatives for solving "the people data problem", and was 
presented to the Data Policy Committee (DPC).

Alternative A.

	A top down approach where all people data would be collected 
and disseminated from a central source.  Presented as the ideal 
solution to the problem.  This would result in need for a new or re-
arranged organizational structure, as well as require significant 
change to existing operational systems.  Characteristics of this 
alternative include:

¥	Defining an organization structure responsible for managing the 
People database on a day to day basis.
	
¥	Building a new application to capture and manage people data 
using a unique PENN identifier.

¥	Convert existing systems to use PENN identifier as person key 
or institute a centrally controlled and distributed SSN change process.

¥	Programming of interfaces to the people database to either 
redundantly store people data in existing systems or provide direct 
access for existing systems to the people database.

¥	Disabling of screens that capture common people data.

¥	Disruption in processes and procedures for many users.  (i.e., 
send people to the people data office for address changes or train 
users to use the people database interrupting current work flow)

¥	Most costly alternative.

Alternative B.

	A combination of top down/ bottom up where existing 
operational sources of people data would continue as they are, 
uploading data to the people database (Payroll, Human Resources, 
Alumni).  People without existing sources of data (i.e., guests, HUP 
Employees) and attributes about people not captured in existing 
systems, would be entered directly into the People Database.   
Characteristics of this alternative include:

¥	Define an organization structure responsible for managing the 
People database on a day to day basis.

¥	Build a new system to capture and manage people data using a 
unique PENN Identifier.

¥	Institute a centrally controlled and distributed SSN change 
process.

¥	Existing systems and procedures are not disrupted (except for 
SSN changes).

¥	Instead, they would upload data as in PENNcard, but subject to 
a rigorous data cleansing process.  (New people, name changes, 
address changes, etc.)

¥	As existing systems are replaced(i.e.,SRS & Payroll), they will 
be made to conform with the people database as a requirement.

¥	a more moderate price tag.

Alternative C.

	Essentially status quo (Penncard), but with rigorous 
enforcement of a central SSN change process and incorporation of 
data on HUP employees.  People without PENNcards would still be 
shutout.

Alternative B was recommended by the DPC because:  It allows us to 
obtain our objective over time, and is less costly, thus stands a 
chance of being funded.


WHAT WILL APPROACH B BUY US?

At a minimum it will give us a single source for the most common 
data items:

¥	unique identifier.
¥	SSN
¥	name.
¥	gender.
¥	ethnicity.
¥	affiliation (student, employee, alumni, guest, HUP)
¥	Physical location.
¥	Contact Information

What are the possibilities?

¥	Network id
¥	E-mail address(es)
¥	Working Titles

CURRENT STATUS

¥	A recommendation by the Data Policy Committee that funding 
be obtained for implementing alternative B.

¥	The project does not have an executive sponsor.  Dr. Patton and 
Jeanne Curtis are in search of sponsorship.  Therefore, it has no 
budget or staff assigned.

¥	Once started, the project is estimated to take 12-18 months to 
complete at a minimum.

¥	In the mean time - Data Administration is making an inventory 
of university-wide problems with people data.  Doing some 
preliminary data modeling and requirements analysis.  We will work 
closely with sponsors to make sure that the identified problems are 
addressed by the project.

WHAT DOES THIS MEAN FOR PAS?

PAS effort will likely be well underway or completed before the 
people database.

Much detailed analysis is yet to be done, and questions such as 
composition of the PENN ID have not been addressed.  What we can 
do here is develop requirements for a unique identifier from the PAS 
perspective, for consideration by the People Database requirements 
analysis.

If I could offer a best guess at this time on the format of a unique 
identifier, without a thorough analysis of the requirements I would 
say it would be a nine position numeric field.   My basis is what I 
have seen of the Oracle applications, and the mandate that we not 
modify purchased software. It satisfies the basic criteria for a unique 
identifier: 

¥	it is not the SSN.
¥	contains no personally identifiable information.
¥	provides adequate room for growth.
¥	if only the significant portions are used (i.e., printed on the 
PENNcard for example) its not likely that we will see more than 6 
digits in our lifetime.   It will be shorter, and presumably easier to 
remember than the SSN.

The likelihood of a PAS generated unique id surviving in the long run 
is small, but possible.  The assignment of the numbering scheme will 
ultimately reside with the steward of the People database.  However, 
there are advantages it could provide internally to the PAS database 
especially if coordinated with a rigorous SSN change process.  For 
instance,  managing people without PENNcards.  

With the SSN properly maintained, PAS can always migrate to a 
unique PENN ID whenever it becomes available from the People 
Database.  However, people with missing or incorrect SSN's will 
obviously require special handling.