WSN

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
• Disaggregation2X5X2X2X2X2 160 distinct
  combinations/groups for aggregate reporting. 40
  groups if you dont 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-nonsectar
  ian 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
  Andreapos

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

• No errors found in the XML file

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 valuesExample02, 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
  Schools 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_MMDDYYY
  Y_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 inDPIs WSN Locator System

• Privacy
• To keep the conversation private and
  confidential between the States 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 inDPIs WSN Locator System
(Continued)

• Managing access to data
• To ensure that only authorized users may access
  the WSN Locator System and its data, the States
  Web Access Management System (WAMS) will be
  employed.
• When granting or denying access to a web
  browsers 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 inDPIs 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 browsers request, it does so within the
  context of the users account information. In
  having the WSN Locator System utilize WAMS, the
  users 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 users 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
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.
50
(No Transcript)
51
(No Transcript)
52
(No Transcript)
53
(No Transcript)
54
(No Transcript)
55
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
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.
• Etc.

57
Browser Requirements

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

58
Implementation Timeline?

• Report Card Data must be publicly
  disseminated by 2002-03. Were late.
• Good-faith effort must be made to meet all
  the requirements at the earliest possible date

59
WSN Timeline
60
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
To Make WSN a Reality

• Final Steps
• Develop
• Deploy
• Train
• Support

62
Risk Management

• WSN Risk Areas
• User Buy-In and Ownership
• School Information System Packages (Vendors)
• Network Infrastructure
• Security
• Integration of Other Systems
• Others?

63
For More Information

• DPIs NCLB Report Card Web site
• http//www.dpi.state.wi.us/dpi/dltcl/lbstat/eseada
  ta.html

64
Open for Discussion