Notification (alert) or tickler systems are features that notify users of tasks coming due to help with planning their work and meeting deadlines. Notification or tickler systems focus on tasks, and are sometimes paired with calendaring systems, which focus on events. In Part C data systems, both are often placed on the main or home page, which may also include or be part of a dashboard. Notification systems can be used in a variety of ways, for example, to alert users of IFSPs that must be developed or reviewed within timelines. The information for this feature concerns the use of notifications with IFSP-related content, but they are equally applicable to all other aspects of the service system (e.g., referral or transition).

Connection to DaSy Data System Framework:

System Design and Development QI4: The Part C/Part B 619 state data system has the capacity to support accountability, program improvement, and program operations.

Potential Data Elements

By way of example, the data elements below could be included in a notification system about tasks related to IFSP development and implementation.

• Type of IFSP (e.g., initial, annual, 6-month review)
• Referral date
• Actual date of meeting/review
• Actual date signed by parent/guardian
• IFSP development/review due date

Functionality

• User interface
• Types of tasks due
• Timing/frequency of notifications/alerts

Key Considerations

• Notification or tickler systems are used to send alerts to users about various tasks coming due. For example, alerts could indicate that a child must have an initial IFSP developed by a certain date (to meet the 45-day timeline). Whereas a list of alerts and a list of child-level tasks may share content, the latter is simply a passive list that could become more useful when coupled with an alert or notification function.
• Alerts can be system generated and/or user generated. The former are automatically generated by the data system based on a known timeline or standard set of timelines (e.g., an initial IFSP meeting alert based on the date of referral or a review of the IFSP six months from the date of the initial IFSP). Some systems also allow users to add individually specific alerts or reminders, e.g., for the service coordinator to contact a pediatrician (with consent) to let her know that the child is eligible for Part C services and has an IFSP.
• Notification systems should be developed for specific user roles, such as service coordinator and administrator, as their needs will often be different. For example, a tickler system could have the ability to notify/escalate overdue items to managers/supervisors (i.e., manager gets a notification if a task is X number of days overdue).
• Consider adding dynamic interactive capabilities to the user interface, for example, allowing users to sort and/or filter alerts and tasks due. The system could also provide the user the ability to click on an alert to take them directly to the item/task that needs attention.
• When developing any type of alert system, it is important to take into account the complexities that result from children transferring from one local program to another and the resulting impact on timelines, IFSP follow-up dates, etc.

State Examples

Utah

Video demonstration (view 2:40-3:10, 3:50-4:14)
Shows child alerts for activities that need to be completed and pending notifications, for example, for referrals and transfers.

Colorado

This screenshot displays the system’s dashboard, which consists primarily of a list of tasks due and a calendar of events/activities.

Washington

Early Supports for Infants and Toddlers (ESIT) Data Management System (DMS) Replacement Training guide (v1.1) (see pages 73–76). This document identifies various ways the DMS has of reminding users of tasks and activities due, including a weekly calendar, lists of tasks and deadlines, and system-generated notifications. It also shows how to use the system to create both personal tasks and tasks associated with a child.