How Can We Help?
For years, people have been talking about the need for sending alerts in the context of a SIF framework when, in reality, the SIF specification itself has very little to support alert messages except:
- in SIF 2.*, a medical alert element that may accompany a StudentPersonal object
- in the NorthAmerican SIF 3.* data model, a general purpose alert has been added to the medical alert for the Student object
There are two issues with the way these alerts are maintained and transferred in the context of a large organization (such as a state):
- only students may have associated alerts (not schools, bus routes, teachers, etc.)
- if the alert applies to a large number of people or objects, individual objects need to be sent with updates for each of these people or objects and the receiver is never sure when all the updates have been received
At a district or state level, there are many partners who may need to be alerted from time to time when events occur. Examples of these organizations might be local law enforcement, after school programs, health and human services offices or offices of child protective services.
- These partners need to be able to receive alerts about students, teachers, schools, bus routes, or other objects as they are happening
- The events may include combinations of objects (teachers and students, for example)
- The event transmission must be very fast (one or two messages)
- The event message itself must contain no personally identifiable information, but must be easily converted into meaningful information by the receiver
- Receiving partners should only see information about students and teachers about which they have a need to know
The school organization would establish a secure connection to receiving partner organization and, through the use of element-level filters, send the receiving partner the information they need to know about the entire student (or teacher, or school bus, …) population. This might include only a very small subset of the entire collection of information maintained by the school district in the SIS. This transmission of this static data would be done at the beginning of the school year or as changes are made to student records, but not as an emergency is happening. Included with each record would be a unique identifier (a GUID) that would have no meaning to an outside onlooker.
This message would be delivered to receiving partners who subscribed to alert events. These receiving partners would receive information about all events, even if they related to objects for which they did not maintain detailed information. This may pose privacy concerns (to be investigated further). If this is a concern, we may want to break up this object into several different objects, one for each class of alert, so that the ZIS can control who subscribes to them.
The Alert Message
|Element / @Attribute||Char||Description||Type|
|CompactAlert||This object sends a compact alert message to a receiving partner application|
|RefId||M||The GUID of this compact alert message||IdRefType|
|ObjectIdList||MR||A repeating list of objects for a given alert type||IdRefType|
|ObjectIdList/@ObjectIdType||M||The SIF Object type||xs:date|
|ObjectIdList/@AlertType||M||The alert type||encoded list of alert types|
|ObjectIdList/Description||O||Description — additional information||xs:string|
|ObjectIdList/ObjectRefId||MR||The RefId of the object in the list||IdRefType|