1 / 64

WSN Project: Student Level Data Collection and Reporting for NCLB Compliance

Learn about the WSN project and how it facilitates student level data collection and reporting to meet the requirements of the No Child Left Behind (NCLB) Act. Discover the benefits of using WSNs and how they protect privacy while facilitating efficient data reporting. Find out about the WSN work-flow process and the importance of implementing WSNs for NCLB compliance.

rosaj
Download Presentation

WSN Project: Student Level Data Collection and Reporting for NCLB Compliance

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. WSN Presentation 18 December, 2003

  2. Overview of WSN Project

  3. Why WSN?

  4. Why WSN? • No Child Left Behind (NCLB) requires extensive new data collection and reporting. • Meeting NCLB report card mandate requires a student level data collection. • Student numbers protect privacy and facilitate student level data collection and reporting.

  5. NCLB requires extensive new data collection and reporting • Outcomes of interest include test results, attendance, graduation, and dropout rates. • Outcome data must be disaggregated by gender, race/ethnicity, disability, economic status, migrant status, and English language proficiency • Disaggregation=2X5X2X2X2X2= 160 distinct combinations/groups for aggregate reporting. 40 groups if you don’t count gender and migrant status. More groups are required to report by grade, primary disability and English language proficiency level.

  6. NCLB requires extensive new data collection and reporting. • States must report on the acquisition of English proficiency by English language learners. • Reporting of test results is for students enrolled for a full academic year. • States and districts must distinguish between dropouts and transfers.

  7. NCLB requires extensive new data collection and reporting. • Requirements apply to DPI, districts, and schools. • Wisconsin data fall short of meeting NCLB requirements. DPI and Wisconsin school districts need to modify existing data systems to fill the gaps. • Meetings were held with selected legislators and staff. Wisconsin hired national experts to help gather input from internal and external groups and to analyze options

  8. Meeting NCLB requires a student level data collection • No Child Left Behind (NCLB) Act requires that we monitor the movements and progress of students and student groups over time. • The only efficient way to collect these data is at the student level. • Wisconsin schools receive over $250,000,000+ annually under NCLB but data requirements must be met. • All states in the Midwest and almost all states nationwide have already moved or are moving in this direction. • Wisconsin will design and implement a individual student enrollment system (ISES). The WSN Locator System is the first phase of ISES.

  9. Student numbers protect privacy and facilitate reporting • WSNs help protect privacy because • They can be used in lieu of names in the student level report card data collection (i.e., the individual student enrollment system, also known as ISES). • WSNs will contain no embedded meaning. • Social Security Numbers will not be used or collected. • WSNs will be stored in encrypted form in the report card data base at DPI. Names will not be included in this data base. • Only authorized persons will have access to this data base.

  10. Student numbers protect privacy and facilitate reporting • WSNs facilitate reporting because • They can be used to efficiently combine data about a student stored in different collections and over time. Combining data is critical for meeting NCLB requirements. • It is possible to store student data once and use/submit the data for multiple reporting purposes.

  11. Why WSN? • No Child Left Behind (NCLB) requires extensive new data collection and reporting.Wisconsin gets hundreds of millions of dollars for schools through NCLB. • Meeting NCLB report card mandate indirectly requires a student level data collection.Other states have moved or are moving in this direction. This is a major shift for DPI and for many districts. We are working to design a system that will provide value to schools for school improvement purposes. We will provide multiple options for WSN Locator System use to recognize the variety of local student information systems in place. Training and support will be available through our WSN contractor (TDS) and DPI. Extensive information will be provided on the ESEA report card web page. We are working to minimize the burden, but some time and money will be required for implementation. Vendors are encouraged to begin work now to minimize effort for districts served. • Student numbers protect privacy and facilitate student level data collection and reporting.WSNs may be used locally if treated as confidential. Security and privacy are our number 1 concerns. More will be said about this later in the presentation. Local IDs may continue to be used.

  12. WSN Requirements • Student ID Process • Student Identifier • Student ID Initial Assignment • Yearly Assignment for Kindergarten Student • Request New WSN Student ID Individually (Via. Web) • Student Locator • Exit Process

  13. WSN Work-Flow Overview • How Schools will use WSN Locator System • Initial Load • Assign WSN • Locate Students • Resolve Duplicates

  14. WSN Work-Flow Overview (continued) • How to Resolve Duplicates • New School Requests Exit Confirmation • Current School Verifies Status of Student • Current School Approves or Declines Exit • Request WSN If Match Not Found

  15. WSN Work-Flow Overview (continued) • Schools Assign/Locate WSNs 4 Ways • Using a CSV File • Using a XML File • Using a Mass Entry Screen in the WSN Locator System • Using an Individual Request Screen in the WSN Locator System

  16. Option 1

  17. Option 2

  18. Option 3

  19. Option 4

  20. Archiving Student Data at the End of the School Year

  21. Archiving Student Data at the End of the School Year • 2003-04 Requirements • Any student who was enrolled in the district at any time between the third Friday in September 2003 and July 2004 should be included in the initial WSN file unless the student transferred to another public school district, private school, or state- or district-approved educational program. • This means that the initial file should include the following students: • students enrolled at the end of the 2003-04 school term, • students who completed high school anytime during the 2003-04 school year, and • students who stopped attending school at any time during the 2003-04 school year but did not transfer.

  22. Archiving Student Data at the End of the School Year • 2003-04 Requirements • Any student whose primary educational services are directly supervised by your district should be included in the initial file. • Services may be provided by district employes or by third party public or private contractors. • Examples include technical colleges, community-based organizations, nonprofit-nonsectarian agencies, school to work program providers, etc. if the student is enrolled in your district.

  23. Archiving Student Data at the End of the School Year • 2003-04 Requirements • WSNs and ISES-required data for all students in the initial WSN file who are no longer enrolled after the 2003-04 school year must be archived locally. • These data must be included with 2003-04 ISES high school completion and 2003-04 ISES dropout data in the fall of 2004. • A list of ISES-required data will be available this spring at the ESEA report card Web page.

  24. Archiving Student Data at the End of the School Year • Thinking ahead to 2004-05 • Archive WSNs and ISES-required data for all students who were enrolled AT ANY TIME during the 2004-05 school year at least through fall 2005 ISES reporting EVEN IF students transfer out. • These data will be needed for 2004-05 ISES attendance reporting and more in fall 2005. • A list of 2004-05 ISES-required data for fall 2005 will be available at the ESEA report card Web page.

  25. Interface Specification forSchools Information Systems

  26. eXtensible Markup Language (XML) • What is XML? • Why do we use it?

  27. Interface Specification Sections … • Transaction Set Envelope • Student Load Transaction • WSN File Transaction • WSN Transaction Result Report • WSN Student Load Duplicate Report

  28. Escaping Characters • These are characters that cannot appear in their literal form but can be sent in as Entity References: • Example: Andre’ would be represented as Andre'

  29. Document Type Definition (DTD) • DTD is to used define the legal building blocks of an XML document • Defines the document structure with a list of legal elements • The WSN Locator System will utilize an external DTD • Optional Elements are identified with “?” • Multiple Elements are identified with “+”

  30. Testing XML with DTD • XMLcheck.html

  31. Errors found in the XML file • No errors found in the XML file

  32. Comma Separated Value (CSV) • The WSN Locator System accepts three distinct header types: 01 – Header record 02 – Student Detail records 03 – Trailer record. These header types tell the WSN Locator system what type of data and in what format to expect to find the data in the row

  33. Comma Separated Value (CSV) cont… • Same business rules and edits apply to the CSV transactions • Quoted string valuesExample:“02”, “DOE”, “JOHN”, “”, “01/01/1990”

  34. XML vs. CSV • Advantages to using XML • XML format can be easily read by a user • Current with emerging technologies • Increased flexibility in data collection • Unlimited occurrences of data like ALIAS and GUARDIAN • Ease of adding / modifying fields

  35. Certification Process • Generating a VALID School Student Load transaction (passing the DTD validity check consistently) • Submitting a VALID School Student Load transaction to the WSN Locator System via FTP to a designated server at DPI • Successfully passing the WSN Locator edit checks and business rules • Loading the assigned WSN Id back into the School’s Student Information System and matching the WSN Id back to the correct student • Only do this if you have a TEST database.

  36. Advantages of being Certified • Positive publicity in the state that your software can meet the DPI guidelines to participate with the WSN Locator System • Instant notification to your clients that you are certified via the DPI WSN Locator website where the Certification matrix is displayed • Future business opportunities with schoolsthat would be looking for a package

  37. WSN Standards • Three code tables will be used during the validation edits in the XML/CSV code and the application code • Gender Code table • Race Code table • State Code table

  38. WSN Standards continued… • File Naming Conventions • Six data elements and a file extension • Send or Receive Tag – 1 character • District Code – 4 characters • School Code – 4 characters • Transaction Date – 2 month, 2 day, 4 year values • Transaction Type – 3 characters • Sequence Number – 5 digit number • File extension (XML, CSV, or HTML) • SendReceiveTag_DistrictNumber_SchoolNumber_MMDDYYYY_Type_SeqNumber.csv • S_0001_0002_01012004_SST_00001.csv

  39. Where to BEGIN….. • Update your Student Information Systems to contain the DPI Code tables • Apply the WSN Locator System business rules to your software • Generate the XML/CSV School Student Load transaction • Run the stand-alone Document Type Definition test using the xmlcheck.html • FTP the Pilot Student Load transaction to the FTP folder • If WSN IDs were assigned, update SIS with WSN IDs • Only if you have a Test database • If WSN IDs were not assigned, check the results reports, correct the data, and resubmit • Inform your clients when you have been certified and distribute software changes/patches

  40. Security for the Exchange of Electronic Data • Privacy (Follow State & Federal Law) • Managing access to data • Managing user “identities” or accounts

  41. Security Solutions inDPI’s WSN Locator System • Privacy • To keep the conversation private and confidential between the State’s server and the WSN Locator client at a school or district office, the standard mechanism of strongly encrypted SSL shall be employed. • All modern, popular web browsers are capable of conducting conversations over strongly encrypted SSL.

  42. Security Solutions inDPI’s WSN Locator System (Continued) • Managing access to data • To ensure that only authorized users may access the WSN Locator System and its data, the State’s Web Access Management System (WAMS) will be employed. • When granting or denying access to a web browser’s request, WAMS bases its decisions on • 1. proof that the user holds an authentic account and • 2. membership of the user in an appropriate “role”.

  43. Security Solutions inDPI’s WSN Locator System (Continued) • Managing user accounts • To facilitate the creation and maintenance of user accounts and the assignment of users to roles, WAMS consists of production-proven tools and procedures that shall be employed. • A carefully engineered and supported WAMS infrastructure was implemented in 2001, which includes web applications for users to manage accounts. For role assignments, strict procedures are followed from the school level and on to the State level.

  44. Further Information aboutManaging Access When the WSN Locator System responds to a web browser’s request, it does so within the context of the user’s account information. In having the WSN Locator System utilize WAMS, the user’s account information is added to security audit trails. These security audit trails help prove that the WSN Locator System is used in a secured manner by only those persons with the authority to do so.

  45. Managing Access • When someone submits a web request of the WSN Locator System, WAMS will always perform two steps: • 1. Authentication • 2. Authorization

  46. Managing Access (Continued) • Authentication • When a user has not yet proven the possession of authentic user account information, WAMS will interrupt the request by prompting the user for a userID and password. Upon successfully authenticating the supplied information, the user is not interrupted again for subsequent requests. This is accomplished through use of an in-memory (a.k.a. transient or “session-based”) cookie in the user’s browser: one of the few browser requirements for using the WSN Locator System.

  47. Managing Access (Continued) • Authorization • For every user request of the WSN Locator System, WAMS will seek out the necessary membership for that user in a role that has been entitled to that request. To illustrate, here is an example only.

  48. Renee IS MEMBER OF ENROLLMENT OFFICERS FILE UPLOAD Jim IS MEMBER OF ADMINISTRATORS Managing Access - Example An enrollment officer is entitled to upload a file of person data while an administrator is not so entitled. Assume the user Jim is a member of the administrator role and Renee is a member of the enrollment officer role. Upon requests to upload a data file, Jim is denied access, and Renee is granted access.

  49. Managing User Accounts Creation and Maintenance of User Accounts The following series of screen shots illustrate some of the web applications in the WAMS toolset that allow individuals to manage their own account information.

More Related