About SourceTrac

SOURCETRAC DESIGN
SOURCETRAC is designed as a secure web-based system that is accessed by authorized users over the internet or intranet from either wired or wireless devices. In the event of total network failure, SOURCETRAC can be used in an offline mode using a laptop or other computer that can be re-synchronized with the host system once network connections are re-established.

The SOURCETRAC architecture allows each State to have an instance of the system installed and hosted in an appropriate data center - ideally the same data center that hosts the EOC’s CIMS product, as these data centers often support secure access, backup power, and systems redundancy.

SOURCETRAC is designed from the viewpoint that support agencies and NGO’s dealing with resources and people need a collaborative database that allows these resources to be tracked, categorized, and shared. More importantly, information about these resources is searchable, allowing informed decisions on the best resource to allocate for each request.

SOURCETRAC FUNCTIONALITY
SOURCETRAC allows local agencies to manage resources and people independently and privately on a day-to-day basis, as well as making these resources available for general allocation (assignment) when an incident occurs. They are able to report on and manage their inventory. Resources can include volunteers, materials and equipment (promissory, purchased, temporary, or loaner), and cash assets. Agencies can maintain multiple documents such as operating procedures, waivers, and MOUs for each resource. Localities and their agencies can prepare for any incident by building pre-planning checklists based on historical data from previous incidents or operational experience. These checklists define what resource classes (types) and quantities are needed for specific hazard types and compare these requirements to the inventory.

When an incident occurs, the system allows the appropriate resources to be located and allocated quickly and efficiently. Requests can be based on the resource type, the purpose, duration of need, quantity and location. These requests are programmatically forwarded to the appropriate administrators for the localities involved in the incident. The administrators can search for the most appropriate resource to allocate to the request. The requestor is notified of the allocation and the system tracks the resources and costs associated with those resources that are allocated. At any time the resources can be returned to inventory or written-off due to use or damage as appropriate.

RESOURCE MANAGEMENT
Resources and people have characteristics that can be used to help manage their usage in emergency situations. For example volunteers have characteristics such as training, skills, languages, and availability. Goods have properties such as shelf life, location, availability, and capacity. The DHS National Incident Management System (NIMS) has defined this as “resource typing” and provides standards for this function. SOURCETRAC uses the NIMS typing model for all resources and volunteers.

Preparedness for any particular hazard helps reduce the time to respond. In the area of resource management it is critical for planners to understand what resources are needed and when they are needed for different types of emergencies. SOURCETRAC not only allows preplanning to take place before various hazards occur, but also creates a historical knowledge base that models real world experience to help ensure the right mix and availability of resources and people.

REPORTING
Facilities exist that allow the capture and generation of incident situation and after-action reports. These reports not only include information about what resources and people are used, but are tied to FEMA approved cost lists and reimbursement forms that can be used to recover incident costs if appropriate. At any time, administrators are able to review the incident for what resources are allocated to what requests and where the resources are located.

COLLABORATION
The key to giving emergency managers a system for coordinating and interfacing with resources and people is to provide simple, but effective collaboration between the various jurisdictions, while still allowing individual agencies (and organizations) within these jurisdictions to mange their people and resources independently.

SOURCETRAC supports individual agency operations by locality. Each agency within a locality (e.g. jurisdiction) has administrative rights to manage their independent resources. An agency of the same type that has a presence across multiple localities can appoint an agency monitor who can view the agency’s state-wide resources for reporting purposes.

The state administrator exists in order to define the state’s localities and is able to coordinate state-level incidents across all localities and agencies within the state.

Regional incidents involving multiple localities from multiple states can be coordinated through the involved locality administrators.

SOURCETRAC recognizes the need to coordinate and manage local resources, not only within a state, but also across localities of multiple states. SOURCETRAC allows administrators to make resources visible and accessible and to allocate them to requests as needed and where needed.

How Collaboration Works
SOURCETRAC allows an incident to be managed collaboratively or independently by the administrators of the relevant jurisdictions with individual support agencies deciding on what resources are visible at any given time.

When there are multiple local administrators collaborating on an incident, SOURCETRAC provides the appropriate level of data integrity (locking) to allow allocation of resources to be synchronized within the database.

The power of the collaboration capabilities of SOURCETRAC can be illustrated by the four types of request processing for incidents that may occur in the system.

1. single location
For a single locality incident, only support agency users and local administrators of the same locality can make a request for resources, regardless of the ESF designation and support agency settings of their user ID.

Submitted requests always appear in the local administrator’s request queue. Request queues are visibly color-coded and can be sorted based on various properties of request such as priority, resource class requested, status (open, fulfilled, rejected, etc.).

Resource allocation can only be done by locality administrators and the only resources that are available for allocation are those local resources that have been made visible by the agencies for the locality.

2. multi-location within state
For a multiple locality incident, the incident creator is any locality administrator or, as necessary, a state administrator. When the multiple locality incident is created, the creator must specify which localities are involved in this incident. When an Administrator creates a “multiple locality” incident, the local administrators of the involved (specified) localities are notified.

Requests against multiple locality incidents can be made by any involved agency user, any involved locality administrator or, as necessary, the state administrator.

Additionally, independent operations capabilities still exist for each agency within the localities whereby they can operate independently and their locality administrations can redirect requests to the most appropriate agency for resource allocation.

3. state-wide (all locations)
For a state incident, the incident creator is always the state administrator. When the state administrator creates a state incident, all localities for the state are automatically involved. State level incidents imply automatic collaboration between all state localities. Independent operations capability can also be given to the individual localities and then to their individual agencies. These options provide total flexibility to assign allocation rights to the most appropriate administrators and maintain the agency’s resource privacy as needed.

A state-wide incident can also be operated as a multiple locality incident — in other words, all localities are involved. Only state administrators can create a state-wide incident. Requests can be submitted by any support agency user or local administrator from any locality.

4. regional (multiple locations across multiple states)
For a regional incident, the incident creator can be a local or state administrator. Regional incidents involve localities from across states. An example is the Washington National Capital Region (NCR) that includes surrounding localities from Virginia and Maryland together with DC.
When a regional incident is created by a state or locality administrator, the incident will automatically include all the localities defined within the regional definition of that state’s SOURCETRAC system.

Once the regional incident is created in one state’s SOURCETRAC database by an administrator, SOURCETRAC will automatically invoke a web-service call to the URL for every other state included in the regional definition. This web-service call will automatically cause the same incident definition to be created in each of the other state’s databases using the local jurisdictions defined in that state’s regional definition.

This allows the same incident to be defined programmatically for all the participating states’ SOURCETRAC system. Effectively, the result is that each state has an incident that could be considered as a multiple locality incident, but the incident name, hazard type, and other relevant data is exactly the same and provides a way to consolidate inter-state incident reports and activities.

A regional incident display screen is available that summarizes the active regional incidents, showing what states and what localities from those states are participating. If there are active regional incidents, any locality or state administrator from one state’s SOURCETRAC system can click on another state from this display and be programmatically passed through (with implied logon) to the other states’ SOURCETRAC system allowing collaboration between administrators across the participating states.

News

06/01/2007 Release of version 2.3

EastBanc Technologies announced the release of version 2.3 of the SOURCETRAC product.

02/06/2006Release of version 2.2

EastBanc Technologies announced the release of version 2.2 of the SOURCETRAC product.