Connecting to Outside Agencies
Over the past several years, one frequently asked for request we receive has been if we are able to connect student data with outside organizations not directly related to education (our framework already handles those related to education natively). Connecting with these organizations is possible but not as simple as connecting with educational applications for many reasons including but not limited to the following:
The following are examples that have come to us in
Department of Health
Department of Justice
Department of Family Services
This has been a pressing need for many years. Every state has established guidelines for incident reporting to be followed by child caretakers, both paid and volunteer. Many require extensive background checks and provide very specific instructions about things to look for and who to notify if a child care worker sees or hears something that might be an abuse warning sign. Most or all of these efforts are active, however — they require that the child care worker see or hear or otherwise be in contact with the child.
The issue that is brought to us regularly is: can something be done if something that should happen doesn't? In our specific case, the student normally attends class. If the school knows that the child lives in an abusive or otherwise dangerous home and that doesn't arrive at school safely, it may be a warning signal as well — this would be a passive warning sign.
How this works
At a high level, here's how it would work. First, we make two basic assumptions:
- At the school district, there is typically a Student Information System (SIS) application of some sort and most of the commercially available products have SIF (Schools Interoperability Framework) adapters — these allow them to exchange data with other education applications is a standardized way
- At the DoFS supervised endpoint (this could be a case worker, law enforcement officer or other person, depending on the laws and structure set up by the state), the detailed information about the protected children is available
If the first assumption isn't true, the district could use a product such as our Mimic product to SIF-enable applications as simple as Excel or Access if that's where they maintained student information, so the second assumption is really the only mandatory requirement for this to work.
How the Data Moves
The following diagram gives a high-level view of where the data moves when attendance is taken:
Things begin when the teacher takes attendance using his or her Student Information System. The application takes all of the attendance information for the class and sends it to the hosting center in a record that looks something like this:
14584C1416224C4687F07B4C78F58036 2016-03-25T15:05:21 SIS_Provider PPPPPPPPPPPPPPAPPPPPPPAPAPPPPPTPPPXPPPP ...... PPPPPTP
NOTE: The line that has "AttendanceValues" would have one value for each student in the school. The Student Information System would know which position in that string corresponded to which student as would the childcare worker system — it would know the position offsets of the children for whom it is caring.
So, for example, one DHS worker's application would be set to look for the 34th, 179th and 341st position in this string to have values other than "P" (for Present). It would also know to look for certain other values that must be present in certain other positions (used for integrity checking). It wouldn't have any idea what the other characters in the string were for except that they were for other students.
- The only system with all information for all of the positions is the Student Information System.
- The Hosting Provider doesn't have information on any of the students.
- The child care endpoints only have information on the small number of students they supervise.
- The amount of information transmitted on a daily basis is very small (the private and bulky information was transferred once, beforehand, only for supervised students).
What about Security?
There are two levels of security needed to run this application:
- One level when the application is being initialized — this is a higher level because during this phase a small amount of personal information will need to be passed through the system — enough for the two endpoints to be able to synchronize students. Once this is done, the only messages that will be passed through the system will look like the one above.
- A second level will be a normal security level that most mobile apps use to protect the user's device.
In the world of security, there are, in general three levels of network security:
- Pretend security: the user is asked to trust the web site because the web site says it is safe to do so (completely unacceptable)
- Normal security: the user trusts a web site because an authority (such as Verisign, Thawte, or a number of others) has checked the credibility of the company hosting it and has verified that they are a real company and have at least paid for the certificate from a commercial vendor. It doesn't guarantee that the company is ethical.
- High level security: both parties communicating have certificates and
Have People Tried to do This Before?
Yes, several times, but always something similar to this and always took different approaches.
The "Simple" Approach
- Local control
- Simple to explain
- S (districts) x W (workers) connections; each of them could be a place where sensitive information could potentially be compromised
- Complex logic (application) needs to be maintained at each school district (new application)
- No standard — requires vendor integration with district Student Information Systems
- High cost
The Replication Approach
This approach has been tried, and many thought it it was the only way this problem could ever be solved. In general, this approach involves creating a large centralized database that contains all the information that will be needed to solve the problem and using it to control actions and alerts. In a sense, the data looks something like this:
A new collection application was created at a central hosting facility that collected information from all school districts, including student demographics, student enrollments and attendance information. That application also maintained lists of which students were "at-risk" and which conditions caused them to this. Along with this information, this application stored agency contact information for each of the students. There were variations on this approach, but most of the were pretty much the same — the hosting application warehoused information stored a significant amount of information about either all students in the district/county or at least a significant amount of information about the at-risk students.
In any case, receiving attendance information was always troublesome because the volume was always too much, received too quickly, from too many different Student Information Systems.
So, What's Different?
Although the goal is primarily the same, the way to get there is very different:
- In most cases, our solution can use the existing Student Information System software at the school district with no modifications or additional software.