1. WSNPresentation 18 December, 2003

2. Slide 1 Overview of WSN Project

3. Slide 2 Why WSN?

4. Slide 3 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. Slide 4 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. Slide 5 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. Slide 6 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. Slide 7 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. Slide 8 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. Slide 9 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. Slide 10 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. Slide 11 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. Slide 12 WSN Work-Flow Overview How Schools will use WSN Locator System – Initial Load – Assign WSN – Locate Students – Resolve Duplicates

14. Slide 13 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. Slide 14 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. Slide 15 Option 1

17. Slide 16 Option 2

18. Slide 17 Option 3

19. Slide 18 Option 4

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

21. Slide 20 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. Slide 21 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. Slide 22 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. Slide 23 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. Slide 24 Interface Specification for Schools Information Systems

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

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

28. Slide 27 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&apos; Entity NameNameSymbol <Less than< >Greater than> &Ampersand& &apos;Apostrophe‘

29. Slide 28 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. Slide 29 Testing XML with DTD XMLcheck.html

31. Slide 30 No errors found in the XML file Errors found in the XML file

32. Slide 31 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. Slide 32 Comma Separated Value (CSV) cont …  Same business rules and edits apply to the CSV transactions  Quoted string values Example: “02”, “DOE”, “JOHN”, “”, “01/01/1990”

34. Slide 33 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. Slide 34 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. Slide 35 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 schools that would be looking for a package

37. Slide 36 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. Slide 37 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. Slide 38 Where to BEGIN….. 1.Update your Student Information Systems to contain the DPI Code tables 2.Apply the WSN Locator System business rules to your software 3.Generate the XML/CSV School Student Load transaction 4.Run the stand-alone Document Type Definition test using the xmlcheck.html 5.FTP the Pilot Student Load transaction to the FTP folder 6.If WSN IDs were assigned, update SIS with WSN IDs  Only if you have a Test database 7.If WSN IDs were not assigned, check the results reports, correct the data, and resubmit 8.Inform your clients when you have been certified and distribute software changes/patches

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

41. Slide 40 Security Solutions in DPI’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. Slide 41 Security Solutions in DPI’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. Slide 42 Security Solutions in DPI’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. Slide 43 Further Information about Managing 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. Slide 44 Managing Access When someone submits a web request of the WSN Locator System, WAMS will always perform two steps: 1. Authentication 2. Authorization

46. Slide 45 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. Slide 46 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. Slide 47 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. Managing Access - Example IS MEMBER OF Renee Jim ADMINISTRATORS ENROLLMENT OFFICERS FILE UPLOAD

49. Slide 48 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.

50. Slide 49

51. Slide 50

52. Slide 51

53. Slide 52

54. Slide 53

55. Slide 54 Managing User Accounts Role Assignment After a person has created an account in WAMS by using the Self-Registration web site, a responsible and authorized officer or agent of the school or district must request that the new user account be made a member of the appropriate WSN Locator System role. The identity of the school or district must also accompany the request so that the user may work on behalf of that organization. Only the data for that organization will then be available within the WSN Locator System to the user.

56. Slide 55 WAMS User Acceptance Agreement Your User ID and password are your keys to the State of Wisconsin over the Internet; they should be considered as important as your signature. Do not share your User ID and password with anyone. It is your obligation to protect it by keeping it confidential. Your user account must have a unique e-mail address. Your user account must have a unique e-mail address. Etc.Etc.

57. Slide 56 Browser Requirements (X.509) Must accept a valid State of Wisconsin certificate (X.509) Must accept session cookies Must accept session cookies If a proxy server is used, it must pass cookies to your browser If a proxy server is used, it must pass cookies to your browser Some applications may require enabling JavaScript and Pop-up Windows Some applications may require enabling JavaScript and Pop-up Windows

58. Slide 57 Implementation Timeline? Report Card Data must be publicly disseminated by 2002-03. We’re late. Good-faith effort must be made to meet all the requirements at the earliest possible date

59. Slide 58 WSN Timeline

60. Slide 59 To Make WSN a Reality Next Steps School/District Vendors Commit to the Project Check email, web DPI/TDS Vendor support Start an Approved process for SIS Vendor(s) assignment of WSN Vendor Training for School/District personnel Vendor deploy new software with WSN enhancement Address any issues of Hardware Connectivity to State LAN Review Policy and Procedure changes for WSN process

61. Slide 60 To Make WSN a Reality Final Steps Develop Deploy Train Support

62. Slide 61 Risk Management WSN Risk Areas – User Buy-In and Ownership – School Information System Packages (Vendors) – Network Infrastructure – Security – Integration of Other Systems Others?

63. Slide 62 For More Information DPI’s NCLB Report Card Web site http://www.dpi.state.wi.us/dpi/dltcl/lbstat/eseadata.html

64. Slide 63 Open for Discussion