...

My Database Will Call Your Database, But Can They Talk?

##AUTHORSPLIT##<--->

A Primer on Data Reporting Compatibility

Imagine a system for collecting vital data on a group of individuals, numbering in the millions, crucial to ensuring the future safety and success of our country. This system, while critically important to national security, rests on the shoulders of more than 16,000 different, isolated organizations. Each of these 16,000 organizations collects its own data on different segments of this group, employing diverse methods, programs and technologies for record keeping. When thousands of these individuals move from one location to another, scattering around the country, important information relating to them either d'es not follow, or comes later and is incomplete. Computer systems do not easily communicate with one another, and too often critical data is lost.

D'es this sound like a problem that is plaguing our country's immigration services or the Department of Homeland Security? Well, this scenario is not about immigration, terrorism or even the war on drugs. Instead, it is about the education of our children. The group I am referring to is the 47 million children enrolled in 90,000 public schools in more than 16,000 districts nationwide. Currently, we face a national dilemma in how to promote a seamless technology system for tracking and reporting on our students' educational histories, achievements and needs.

In addition, paperwork and data collection in education have grown at an exponential rate in the last 10 years, as accountability has increased. Although technology has helped in data-gathering and offered some relief, the value that information can offer to the education community has never been fully realized. Since current student information resides on many disparate, non-compatible data systems at the school, district and state levels, this data cannot be optimally used to understand where to target resources that boost student achievement. In short, education is data rich and information poor. And the No Child Left Behind Act is asking for all that to change.

New Data Reporting Rules

NCLB requires that states administer annual tests to measure student achievement levels, which are based on benchmarks set by adequate yearly progress (AYP) requirements. States must also collect and report the number and percentage of schools identified for improvement, including how long they have been in that category, then compare district and state student-achievement data. At the beginning of each academic year, school districts must report teacher qualifications; circumstances of the teacher's status; the level, type and subject area of teacher degree or certification; and qualifications for any paraprofessionals. But, few districts are ready to meet their responsibilities in complying with these data reporting demands from the states and NCLB.

Student data also must be disaggregated - i.e., reported in separate data sets of demographic subgroups by ethnicity, income and other categories. While disaggregated data will allow parents and other stakeholders to understand how each subgroup performs by itself and in relation to the school as a whole, few districts or states are set up to deliver data in this way.

However, NCLB requirements are not just about data reporting, they are also about data access. Schools will need access to information in order to establish progress targets for the school and for certain demographic subgroups. Teachers - who are being asked to make data-driven instructional decisions - will need access to more information than ever before, including district, state and national standards; individual student-performance information; and, of course, testing information.

In addition, NCLB sets high expectations for communicating with parents about student achievement. Thus far, the Web has been used by a limited number of schools to inform parents and students about progress, but this information has been confined mostly to class assignments and schedules.

These new data requirements aren't a "nice-to-have" request from Washing-ton. The information that the annual NCLB state report cards require will have an impact that may result in prescribed steps being taken. States with schools or districts that fall short in their AYP reports over a number of consecutive years will face actions that may lead to restructuring or other corrective measures.

New Data Protocols

Unfortunately for states, student information traditionally has resided at the school and district levels. State information has been collected, but only a handful of the data actually contains individual student information. State databases have normally been limited to district reporting for state or federal funding, as well as maintaining grades for the student transcripts. Only large districts typically maintain an extensive testing database, which is used primarily for internal analysis of student progress.

School districts must work within a state framework for data integration to be successful in complying with NCLB. The way districts have traditionally coped when they've had to report data residing in incompatible systems is by dual entry, which is a costly, time-intensive and sometimes politically explosive practice. Given the extent and complex-ity of the new federal data reporting requirements, dual entry is not a long-term solution.

Soup Up Your SIMS!

In order to make collecting this information as trouble free and accurate as possible, states and districts are (or should be) enhancing their student information management systems (SIMS) by creating a comprehensive relational database or purchasing commercial products to serve that purpose. These SIMS must be able to interface effectively with other systems. In this regard, the system must:

  • Be capable of importing and exporting data to and from third-party software;
  • Be able to interface with various third-party software packages;
  • Possess a published format for importing student, teacher and class registration data into the database without rekeying data;
  • Support data integration and data sharing with other computer systems or SIF-compliant applications and other industry standard protocols (see related story below);
  • Permit user definable import and export specifications for files;
  • Receive, accept and/or modify student data from a variety of sources such as scanning, keyboard entry, archived records, the Web or telephone;
  • Allow users to export data to statistical software that makes tables of specified data, as well as let users export in a variety of formats;
  • Be able to store specified export routines for later use and modification; and
  • Provide seamless integration with school, district or state curriculum management systems.

If these systems are to impact student achievement, they must possess a curriculum management component that helps the teacher identify individual students' strengths and weaknesses. Moreover, these curriculum management systems should be aligned with state standards and identify instructional practices and curricular resources that will address student needs. States are now in the process of seeking the best methods for developing data systems that provide seamless management of student information in a manner that is beneficial for schools and districts, as well as effective in meeting the goals of NCLB. The key to success is communication from the schools up to the district, as well as across the districts in each state.

Dave Brittain, the former director of educational technology for the Florida Department of Education, is a partner with MGT of America Inc. and directs the firm's educational technology practice. For more information on the services that MGT provides to schools and school districts in complying with NCLB, visit www.MGTofAmerica.com or e-mail brittain@MGTofAmerica.com.


Standard Interfaces & Protocols

Several protocols have been initiated in response to the challenge of disparate databases being able to exchange data. Following are four of the standard interfaces and protocols that are currently being used. If every school, district and state was compliant with these standards, U.S. education would be in a far different position to truly keep track of and promote the best interests of our students.

Electronic Data Interchange (EDI) is a precursor to the Internet as a means of exchanging data between various systems. The data exchanged (usually by direct computer-to-computer transactions) can include all or a portion of student information. It involves a one-to-one connection, most often via dial-up. Many states and districts that have relied on EDI for their student information transactions are now experimenting with Web-based forms to link them to smaller districts.

Open Database Connectivity (ODBC) provides a common application programming interface through which software can connect to other database systems, provided those systems are also ODBC-compliant. Many student information systems are being maintained by using ODBC between the district office and schools.

Schools Interoperability Framework (SIF) is being developed by software application companies that need a method for each of their different, and sometimes competing, software applications to talk to each other and share data. SIF-readiness could become a baseline measure of interoperability for all systems dealing with student information. SIF will allow student information to be transmitted more easily between schools or districts when students move from one location to another. Several companies are working toward SIF compliance, but many others need to embrace this protocol to make it fully successful.

Structured Query Language (SQL) is really a programming language designed to get information out of and then put it into a relational database. Queries are constructed from a command language that allows one to select, insert, update and locate data. SQL is a recognized standard that is used between schools, districts and state-level systems.

This article originally appeared in the 05/01/2003 issue of THE Journal.

comments powered by Disqus

Whitepapers