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: s-critical_connections pdf

Peter Ewell’s 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 Established and Maintained by Public University System and SHEEO Offices Several Decades of Experience at this Point Several Decades of Experience at this Point Designed to Drive State Funding Formulas for Public University Systems 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”) 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 Federal Unit Record Proposal for Postsecondary Education

State Unit-Record Database Inventory Updated a Previous Inventory Conducted in 2003 Updated a Previous Inventory Conducted in 2003 Looked at 49 Databases in 42 States Looked at 49 Databases in 42 States Contents 81% of Nation’s Headcount Enrollment Contents Cover 81% of Nation’s Headcount Enrollment Growing Number of Independent Colleges are Included 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”) 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 (In- State 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 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.

0 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-semester- based 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 31 st. 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