88 The 17 fields in staff files are:
The 18 fields in student files are:
Pupil_Number,Last_Name,First_Name,Second_Name,Last_Name_Suffix,Birth_Date,NorthAmeric an_ID_Number,Physical_Street_Address,City,State,Zip_Code,Grade,LEA_Code,Gender,Registrati on_Date,Email_Address,App_Entitlement,Mod_Date,
Data field values in files are tab-delimited.
In this sample data, the fictitious 10-digit "North American ID Number" is used as an imaginary identifier that is unique to every person and must be absolutely protected.
The staff file's "District_Code" and the student file’s "LEA_Code" are populated with a three digit code representing the LEA for that record.
The staff file's "Staff_Id" and the student file’s "Pupil_Number" are populated with a statewide UID, or unique identifier, for every individual in the system. The Staff_Id and Pupil_Number share the same address space, and the idea is that over time that number stays with an individual for life.
So pupils who become teachers would have the same value in "Staff_Id" as they have/had in
"Pupil_Number".
The "App_Entitlement" is a boolean value which when set to "true", would indicate that user is eligible to use cloud apps such as GoogleApps, MS Live @ EDU, etc. In these datasets, only a very small number of records have App_Entitlement set to true.
Data for PoC Demonstrations
In advance of each of the PoC visits, the evaluation committee shall identify one “big” and one “little” sample data directory for the Bidder to choose from to do their PoC
demonstrations. These directories are being shared in advance, in order to facilitate timely demonstrations at the PoC. This allows the vendor to prepare in advance for the PoC
demonstration, with the first time step of data (Time 1 data file as described above). For example, a directory can be pre-populated with the student and active staff populations prior to showing up at the actual demo. We expect this should allow for more effective use of the time allotted to the PoC.
Data for the subsequent time steps (step 2 and step 3) of the corresponding “big” and
“little” data directories, will be provided on the first morning of the PoC. Data for steps 2 and 3 can be used during the PoC to demonstrate proper handling of updates as described elsewhere in this document.
Rev 02/13/2012
89
a) Suggestions for Possible Data Transformations
When the authoritative source data is consumed for use in the actual IAM-MS, it is likely that various semantic interpretations of field codes, etc., will need to be done by the IAM-MS. For the purposes of this PoC, several possible transformations can be suggested.
i) From LEA_Code / District_Code -> Derive "LEA Name"
This field exists in both student (field is named “LEA_Code”) and staff (field is named
“District_Code”) data. Derive "LEA Name" from this field according to the following table. The 232 valid LEA codes (115 LEAs plus numerous charter schools) and corresponding names in the sample data files are:
Code Name 49A AMERICAN RENAISSANCE
32J Ann Atwater Community School 040 ANSON COUNTY
32K Central Park School for Children 681 CHAPEL HILL-CARRBORO
10A CHARTER DAY SCHOOL 19A CHATHAM CHARTER 190 CHATHAM COUNTY 209 CHEROKEE CENTRAL SCH
Rev 02/13/2012
60H CROSSROADS CHARTER HIGH SCHOOL 260 CUMBERLAND COUNTY
270 CURRITUCK COUNTY 280 DARE COUNTY 290 DAVIDSON COUNTY 300 DAVIE COUNTY
998 DEPARTMENT OF JUVENILE JUSTICE AND DELIQUENCY 49C DEVELOPMENTAL DAY SC 84B Gray Stone Day School 400 GREENE COUNTY
Rev 02/13/2012 01D NEW CENTURY Charter HS 650 NEW HANOVER COUNTY
Rev 02/13/2012
Rev 02/13/2012
93
980 WILSON COUNTY 19B WOODS CHARTER 34D WOODSON SCH OF CHAL 990 YADKIN COUNTY 995 YANCEY COUNTY
XXX For any NOT falling into these numbers, flag as "UNKNOWN"
Rev 02/13/2012
94
ii) From GRADE -> Derive "School Type"This field exists only in the student data. Derive "School Type" thusly:
0-5 -> Elementary School (where 0 represents Kindergarten) 6-8 -> Middle School
9-12 -> High School
Less than 0 -> Flag as "UNKNOWN SCHOOL TYPE"
Greater than 12 -> Flag as "UNKNOWN SCHOOL TYPE"
iii) Other
a) Each valid record in the student data set should result in an active record being created in the Person Registry - as long as no duplicate record is found (primary key based on the PUPIL_NUMBER field).
b) Each valid (and active) record in the staff data set should result in an active record being created in the Person Registry (primary key based on the Staff_Id field, along with a Active_Inactive_Indicator set to “A”) – as long as no duplicate record is found.
c) Each active staff user would ONLY be allowed to see data from their own LEA.
d) Delegated Administrators for an LEA would be permitted to deactivate a student record, but ONLY from their own LEA.
iv) Recommended Fields for Guest Records
The following fields shall be used for Guest Records. Additional fields may be added by the vendor if they feel they are needed for the PoC. Only some of these fields would be entered by the guest during self-registration. The others would be defaults, rule-based or auto-generated.
Last_Name,First_Name,Middle_Name,Name_Suffix,Birth_Date,Address_1,City,State,Zi p,NorthAmerican_ID_Number,Email_Address,Active_Inactive_Indicator,Last_Update,A pp_Entitlement,Sponsor_Staff_Email_Address,Sponsor_Staff_Id,
Account_Expiration_Date
References
IAM Plan: “Developing an Identity and Access Management Service for North Carolina Education Cloud”, http://cloud.fi.ncsu.edu/projects/iamdiagrams/20120229.nc.rttt.iam.plan.v5.0.pdf
Rev 02/13/2012
95
This page is left blank intentionally
Rev 02/13/2012