I. INTRODUCTION AND
REMARKS
Marion Dilbeck
I. INTRODUCTION AND
REMARKS
Reintroduce Ourselves
Purpose of UDS Coordination
– Advise the State Regents Office in management of
the UDS system.
– Point of contact in revising, correcting and updating
the UDS system.
Renewing Acquaintance
and Moving Forward
– We have not met formally for several years. Issues
have accumulated that must be addressed.
– Regulatory changes from Washington bear on our
data collection and require us to reexamine our
dataset and methods.
– Our new administration at the State Regents Office
wants more timely and specific information.
– New internal auditor.
– Technology evolves.
II. IPEDS UPDATE
Michael Yeager
III. NATIONAL STUDENT
UNIT RECORDS UPDATE
– UDS was one of the first student unit record systems
in the country. Only California's and Wisconsin's State
University Systems antedate ours. In
comprehensiveness of elements collected and
institutions included, UDS is still among the best.
– NCHEMS/Lumina Foundation study:
http://www.dataqualitycampaign.org/files/publication
s-critical_connections-010107.pdf
Peter Ewell’s
Presentation
Statewide Unit Record Databases
in Higher Education: Growth and
Application
Peter Ewell
National Center for Higher Education Management
Systems (NCHEMS)
PESC Annual Meeting
April 29, 2008
State-Level “Unit Record”
Databases in Higher Education

Established and Maintained by Public University System and SHEEO
Offices

Several Decades of Experience at this Point

Originally Designed to Drive State Funding Formulas for Public


University Systems
Used More Recently to Calculate Student Retention and Graduation
Rates for Accountability Purposes (“Student Right to Know”), and to
Track Students from One Institution to Another (“Enrollment Swirl”)
Federal Unit Record Proposal for Postsecondary Education
State Unit-Record Database
Inventory

Updated a Previous Inventory Conducted in 2003

Looked at 49 Databases in 42 States

Contents Cover 81% of Nation’s Headcount Enrollment

Growing Number of Independent Colleges are Included

Reasonably Compatible Data Structures and Definitions
for Core Data Elements (Largely Based on IPEDS and the
“Common Core of Data”)
Some Common Features
Across States


Multiple Databases in Some States
Growing Experience with Linking Data to Other State
Databases (K-12, UI-Wage, DMV, etc.), but this is Still a
“Frontier” to be Explored

Virtually All Still Use SSN in Some Form as Key Link

FERPA and Privacy Issues are Major and Growing Concerns

Many Systems Getting Old and Hard to Maintain, and State
Money to Do This is in Short Supply
Some Specific Features




23 SURs Contain Transcript-Level Detail
17 SURs Have Data on Placement Test Scores and
Participation in Developmental Education
25 SURs Have Contain Financial Aid Records
23 SURs Now Have Mode of Delivery Indicators (e.g.
Distance Delivery, etc.)
Commonly-Reported
Challenges

Data Quality and Data Audit Functions

Lack of Analytical Capacity and Analytical Staff

Non-Credit Activities


Non-Traditional Calendars and Teaching/Learning
Environments
Political and Organizational Issues
Typical Reports Generated
Through SURs

Basic IPEDS Reporting

Multi-Institutional Retention and Graduation Reports (InState Only)

Reports on the Effectiveness of Developmental Education

High School Feedback Reports

Reports on Workforce Placement, Earnings, and Return
on Investment
SUR System Components
Needed for Effective
Longitudinal Tracking




Broad Coverage of the State’s Postsecondary Institutions
(2-Year, 4-Year Public, Independent)
Agreed-Upon “Key Links” for Merging Term Records to
Create Longitudinal Data Files (and the People to Do
This)
The Data Elements Needed to Construct Key
Performance and Outcome Measures
Paths to Link Longitudinal Data with External Databases
(e.g. High School, Employment)
Data Element Contents Needed
for Effective Longitudinal
Tracking




Basic Enrollment and Completion Data (Credits
Attempted and Earned, GPA, Program Enrollment,
Developmental Enrollment, Degrees Awarded)
Requires Census Date and End of Term Extracts
Demographic Data of Interest for Disaggregation
(Gender, Race/Ethnicity, Age, Location [Income])
Transcript-Level (Class-Level) Data is the “Gold
Standard” for Effective Tracking
Some State Examples of
Using SUR Data




Florida K-20 Data Warehouse and Associated FLCCS
Studies on High School and College Performance
Washington SBCTC Studies on Pathways to Success for
Low Skilled Adult Students
Validating Placement Testing Policies for North Carolina
Community Colleges
Data Sharing Among High Schools, Community Colleges,
and Four-Year Colleges (CalPASS)
Some Lessons from
Experience

Data Systems Can Acquire a “Logic of their Own”

Data Use Drives Data Quality

Just “Having Good Data” Doesn’t Guarantee Good Policy

Secondary and Postsecondary SUR Development Still on
Parallel Independent Tracks
At the national level:
– FERPA regulations have been relaxed somewhat. This
leads us to expect that we can enhance our data
exchanges within our own system.
– K-12-Postsecondary alignment. This is a matter of
growing interest nationwide. We need to work on
this.
– State systems are grappling with the
semester/quarter/other categories. The standard
model doesn't describe new methods of delivery and
course scheduling practices very well.
– Everything is being done in XML.
IV. UDS UPDATE
When in the course of technical events it becomes necessary to
update out system and to dissolve the bands which connect us to
the punch card and mainframe past…
We haven’t had a significant update to our formatting for 15
years. The change from 80-column punch card format to 200
column was discussed in 1993 and 1994 and first collected as 200
columns records in 1995. Accumulated issues and technical
advancement call for another change now.
RECORD 1
– Full first name and middle name.
– Full birth date.
– College code of last college attended: quit using FICE
and use only IPEDS unitid codes.
– Financial aid: allow more than 5 codes and add
amounts. Collect as a new record type.
– Degrees conferred: uncouple from Record 1 and
collect as a new record type.
– WAVE student identifier. What can be done?
RECORD 2 (3,4)
Carthago delendum est.
In 146 B.C. the Roman Senator Cato declared that
“Carthage must be destroyed,” launching the Third
Punic War. Today I say
HEGIS delendum est.
– Replace HEGIS with CIP
– Bring the use of CIP up to CIP 2000 everywhere in our
system. We still find some CIP 1990 codes. NCES is
working on the next edition of CIP codes, which may
be released in the next couple of years. When it is,
we need to adopt that.
– End the repeated fields.
RECORD 0
– Increase size of course number and section number
fields?
– No more redefined fields.
– Examine method of delivery code set.
– New meeting time field to describe non-semesterbased courses?
RECORD 8
From numerous questions and discussions with
institutions, we suspect that our model may not describe
campus employment practices as well as it used to.
Updating the model probably needs to be done, but that
is a large project in itself, so we’ll defer that until other
changes are accomplished.
SCHEDULES AND
REFORMATTING
– Can we replace the preliminary enrollment report with
a preliminary UDS run? This would have no grades
and no degrees conferred.
– Can we separate financial aid and degree reporting?
Financial aid would be its own record type. Degrees
conferred would be its own record type and if
necessary could be due slightly later than the rest.
Join Record 0 and Record 2
This would resolve the ambiguity we encounter when
joining these tables ourselves. We could generate
from such records a course list (like Record O), a
course roster and reports on enrollment by location.
These last two are currently difficult and error-prone.
STUDENT RECORD:
– Like the current Record 1, but without financial aid or degrees.
ENROLLMENT RECORD:
– Record 0 plus SSN, grade and credit. There would be one of
these records for each student enrolled in each section.
FINANCIAL AID RECORD:
– Inst, semester, year, SSN, financial aid type, amount. One
record for each award to each student.
DEGREE RECORD:
– Demographic information and degree information sufficient to
report from directly, without joining to other tables. One
record for each degree conferred.
PROFESSIONAL STAFF:
– Unchanged for now. Is there any enthusiasm for an eventual
change to all staff along with an examination of the
employment model?
SCHEDULE
– Preliminary: two weeks after the end of add/drop?
– Final: same as current UDS collections except
degrees.
XML
And format it in XML. There’s no doubt whatever that
if we were creating the UDS system now, it would use
XML. Adopting XML is adhering to accepted best
practices.
HOW DO WE DO ALL
THIS AND ON WHAT
SCHEDULE?
– TRPs (Technical Review Panels) on each topic, conferring by
year’s end with the goal of producing a new UDS Data Request
Manual by December 31st. The TRPs would be composed of
State Regents and institutional staff.
– New Format first due date would be October 2009 for summer
2009 data.
Student Record TRP:
Enrollment Record TRP:
Degree Record TRP:
XML TRP:
The TRPS would report their conclusions to UDS Coordinators.
OEIS APPLICATIONS
Web-based OAS (Oracle
Applications Server)
Reports, graphs, some queries.
Tools:
Discoverer, a BI application;
Forms, an insert/delete/update application;
Reports.
V. DISCUSSION
VI. ADJOURNMENT