Project Child HANDS - Federating Virginia's Child Data

Project Child H.A.N.D.S.

Child Care Subsidy, Health and Early Education: Helping Analyze Needed Data Securely

Project Information

Home Description Child Care Data Community Data Federation Data Surveys & Reports Wave 1 Demonstration Wave 2 Demonstration Child Data Resources

Project Team

Virginia Tech Dr. Aaron Schroeder Senior Research Scientist, Institute for Policy & Governance
Dr. Isabel Bradburn Research Director, Child Development Center for Learning and Research
Nancy White Research Associate, Institute for Policy & Governance
Caitlin Faas Research Assistant, Human Development
Kimberly Day Research Assistant, Human Development Virginia Department of Social Services Kathy D. Gillikin Manager, Quality Child Care Program
Todd Areson Senior Research Associate, Office of Research Virginia Department of Education Dr. Deborah Jonas Executive Director, Research & Strategic Planning
Bethann Canada Director, Information Management Project Sponsor

US Dept Health & Human Services Administration for Children & Families, Office of Planning, Research & Evaluation

For more information, or to arrange for a presentation to your group, please contact:
Isabel S. Bradburn, Ph.D. Project Co-Director isbrad@vt.edu Phone: 540-231-1863

Data Federation

Data Federation vs. Data Integration vs. Data "Fusion"

Project Child HANDS Data Fusion Approach

Meeting on an annual/semi-annual/quarterly basis, working under the auspices of the Office of Early Childhood Development in its (FERPA-Compliant) role under the Department of Education, an “ID Table Creation Team” would go through a process of linking new child records. This process would likely be semi-automated. That is, a processing algorithm of some sort would be used to link data records, but those in question would be left for manual verification by the team.

Once all records are linked, the ID Table would be stripped of all fields except the individual record IDs (see conceptual diagram below). In the example, this would be the Client ID, Student ID, and Patient ID.

The Virginia Tech team would handle the initial population of the ID Table. Moving forward, annual or semi-annual updates would be the responsibility of the team (although, as a state educational agency, Virginia Tech could also be contracted to manage this function).

The ID Table would be housed by a third party “technical support” partner responsible for server and database maintenance (e.g. VEAP). Ideally, this third party would be another state with recognized authority as an “enterprise” database shop. The idea is to use the third-party agency as a "many-to-many" data table. In a database management system, if you need to relate two data tables to each other, and each record in one data table could be related to many records in the other (and vice versa), you create a third data table to relate the other two. In this third table you only have two fields (columns) that store the unique identifiers of the two tables.

The “third-party” would have no access to personally identifying information. They would only house the IDs and the queries (stored procedures) for linking them to their respective tables on demand (via the XML web services). Secure access to the ID table and queries would be limited to the appointed “analytical authority” (as opposed to technical); currently, Virginia Tech. The analytical authority creates/edits/maintains the system of queries and reports.

Additionally, there will be a system of queries and reports for this system that will also need to be maintained. As these types of "tools" are generally programmed within and stored within a host database management system, it makes sense to have them housed and stored along with the unique ID tables by a database-savvy entity.