Opensource cad

From IHRIS Wiki
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.
Indicator Tickets CAD Invert911 opendispatch MobileCAD
Software License
Maturity of Software
Last code commit
Standards compliance
Programming Language
Manual and documentation availability
Communications support
Call Handling
CAD Incident / Event Types
Update Call for Service Event Data
Determine Dispatch Need
Utilize Incident Disposition
Assign Incident Classification and Priority
Check for Duplicate Incidents
Incident Information
Determining Capture Locations
Location Verification
Retrieve Incoming Calls
Involved Person Information
Involved Vehicle Information
Premises Hazards and Previous History
CAD Event Creation
Determining Response Agency & Service Area
Alarm Processing
CAD Event Routing
Ability to Route to a “Decision Dispatcher”
Dispatch Support
Unit Rotation (aka: Unit Load Balancing)
Special Dispatch Areas
Emergency Medical Dispatch / Incident Triage
Dispatch Units
Resource Alerting
Move Up (aka: “Fill-In” or “Station Fill”)
Staffed vs. Unstaffed Units
Cross-Staffing / Crew Counting / Shared Staffing Crew
Additional Unit Status
Rostering
Scheduling
Mileage Tracking
Hydrant Location and Status
Additional Unit Dispositions
Exception Reason Tracking
Geo-fencing
Station Dispatch
Pre-Release or Pre-Alerting
Vehicle / Unit Change
Automatic Driving Directions / Routing
Bypassed Units
Post-Dispatch Response Re-evaluation
Display of Incident / Event Data
Update Incident Status
Dispatch Resource Decision
Update Assigned Resources
Update Supplemental Resources Tracking
Assign Units
Update Incident Data
Assign Records Management System Incident / Case
Transfer Basic Incident Data to the Records Management
Display Additional Incident Data
Reopen Incident
Add Destination Locations
Hospital Status / Availability and Hospital
Patient Tracking
Linking an Audio File to a CAD Event
Multiple Simultaneous Incidents to Single Unit
Scheduled Events
Secondary Incident Location
Single Discipline Incident to a Combined Discipline
Determine Incident / Event Status
Utilize Incident Management
Determine Report Functionality
Record Disposition
Send Data to Records Management System
Assign Agency-Specific Report Numbers
Geofile Maintenance
Security
Logging
Configuration
Table Maintenance
System Functions
Notifications
Contact List
Premises Information / Hazards
CAD Workstation-to-CAD Workstation Messaging
Incident Command Support
Narrative Field “Shorthand” / Auto Text
Command Line / GUI
Date/Time Stamps
Unit Status Transitions Matrix
Single Sign-on for CAD and CAD Sub-systems
Server applications have native 64-bit support.
The software shall be able to associate codes to more than one location or panel when the same validation table entries are used in multiple locations.
The system shall provide the ability to quickly and easily assign default agency-defined status codes.
The system shall provide the ability to enter a unique building and unit number to clearly identify the location (e.g. 100 West Ave., Bldg. 2, Unit 1).
The system shall enable CAD users to select the appropriate incident/event type from a pre-defined list of codes based upon information received from reporting party.
The system shall include the following fields for all records containing an address as applicable: street number; apartment/suite number; street; road type (Drive, Avenue, Street, Alley, etc.); pre-direction; post-direction; city.
The system shall allow authorized users to store multiple names for businesses and tenants for a given street address.
The system shall organize the display of possible address matches in an ergonomic, easily understood manner that aids users in identifying valid incident locations.
The system shall allow authorized users to configure their tactical map display to show jurisdictional boundaries (e.g. city boundaries) and to display potential valid incident locations by jurisdiction.
The system shall provide the ability to enter a partial street name, with a minimum number of characters, and be presented with a list of possible matches to pick from for an exact match.
The system shall provide the ability to enter a misspelled street name and be presented with a list of possible matches.
The system shall provide the ability to enter an incorrect street address for a correct street name and be presented with a list of valid ranges.
The system shall provide the ability to override the CAD system’s geofile by manually entering valid response area data.
The system shall provide the ability to enter a reason for an overridden location.
The system shall provide the ability to generate a report of geofile overrides.
The system shall provide the ability to display the incident location in relation to other active incidents on the system’s tactical map display during the CAD event entry process.
Data entry fields containing an address shall follow the NENA Standard for NG9-1-1 GIS Data Model (71-003), Section 3.5 (GIS Database Model Layers) and should, at a minimum, include the data elements contained in the Site/Structure Address table.
The system shall support the creation of new CFS events by either call takers or dispatchers depending on the source of the event information.
The system shall allow each address or commonplace name to have an unlimited number of alias names.
The system shall allow the user to upgrade or downgrade the CFS event to fit the reported event by changing the priority for the event.
The software should utilize self-cleansing windows to allow users to open and use multiple (minimum of 20) child windows simultaneously and be able to tile and/or cascade the child windows.
The software should have a tabular design, allowing access to multiple layers within the system.
The software shall allow authorized user(s) to define the screen layout (e.g., position and size of windows) and save the individual configurations based on the user’s login.
The agency staff should be able to adjust commonly altered variables such as codes, tables, report parameters, etc., without the services of a professional programmer.
The software should provide a table look-up capability for frequently entered information; once the data is selected the information will automatically populate the user’s data record.
The software should provide the ability to verify the quality of data entered into the database by performing immediate error checking, prohibiting invalid data to be stored in the database.
The software shall provide the ability to input, access, and store an agency-defined level of historical data online.
The software shall have the capability to be used in a multi-jurisdictional, multi-department environments.
The software shall provide the ability for multiple users to be on the system and in the same applications simultaneously
The system shall use consistent validation table (drop down list) processing.
The system shall allow for agency-defined validation tables.
The software shall have the ability to enter multiple units via command line or mouse.
The software shall provide a one-time, single-point of data entry that allows information to be accessible from other applications. All applications must integrate tightly with each other to provide the greatest operator and system efficiency.
The software shall provide an online help feature available for all functions, including data entry, search/inquiry, menu, form and report generation.
The system administrator and other authorized personnel shall be able to identify an individual who last entered or updated any transaction as well as the date and time of the modification.
The software shall provide the ability for a user to create and store ad-hoc reports.
The software shall provide the ability to directly output from a data search to a printer upon user request and schedule reports to print.
The software shall provide the capability to add unlimited narrative to records, ensuring critical information is captured.
Each agency shall be able to maintain its own tracking number (ORI) separate and specific from other agencies in the system.
The dispatch center shall be able to maintain a separate ORI from all other agencies.
The system should allow for the editing of all commands to follow the dispatch center naming conventions and the ability for the system administrator to add new commands.
The system shall support command line, function key and drag and drop mouse capabilities for all dispatch functions.
CFS shall be automatically routed to the appropriate Law Enforcement, Fire or EMS Dispatcher, based on the incident type entered by the Call Taker and/or Dispatcher.
The system shall use a combined call function that can create a single call to handle multiple Law Enforcement, Sheriff, Fire and EMS agencies. The ORI must be retained for each agency and dispatch center.
Each Call Taker and Dispatcher position shall be able to define the filter it sorts and determine how many to sort for the call control panel.
The software shall provide a separate message screen that shows all Call Taker, Dispatcher and MDT/MCT (mobile unit) messages sent to the Call Taker/Dispatcher position.
The software shall provide automatic date/time stamping and user ID tracking of all Call Taker and Dispatcher processes to track call and unit activity and all command processing.
The software shall log all Call Taker/Dispatcher activity that can be printed or queried.
All cleared calls shall be automatically transferred to the appropriate RMS.
The system shall allow an incident/call number to be quickly created (quick call) by entering the following minimal information: incident type, location and priority of call (if not pre-populated based on the incident type).
The system shall provide the capability for any name entered by a Call Taker/Dispatcher to be associated or added to the RMS master name database.
The Call Taker/Dispatcher position should be capable of being either local or remote.
The system shall flag all incidents/calls that require a report submitted by the officer.
The software shall separate CFS from reportable offenses – incidents vs. cases.
System users shall be able to access a command line with one keystroke from anywhere in the system.
The system shall provide the ability to attach special response information to any call for service type desired by the agency. This must be automatically displayed when the specified call type is selected.
The system shall provide the ability to view cleared calls.
The system shall provide appropriate security for cleared calls, defined by the agency, to prevent unauthorized modification and viewing.
The system shall have the ability to reactivate/reopen cleared calls and allow additional activity/dispatching of units to the original incident number.
The CAD Data Entry Window shall show the closest cross streets.
The CAD Data Entry Window shall allow jacket and global vehicle processing.
The CAD Data Entry Window shall visually indicate (such as checkmarks) on the tabs if the tab contains information.
The CAD Call Control Panel shall allow users to customize the tool bar.
The software shall have a list of values that can be used to facilitate the data entry process, such as abbreviations, directions, case status codes, weather codes, etc.
The CAD Unit Status Control Panel shall allow users to customize the toolbar.
The CAD should allow calls to be merged together and or un-merged if they needed to be.
The CAD should allow the users to relate a separate PD or FD call to an existing CFS.
The CAD should allow the users to relate multiple calls to an existing CFS from another department.
The system shall display a notification of the event update at each appropriate CAD position whenever an active event record is updated, as determined by the system’s configuration.
The system shall create an automatic time/date stamp for every transaction related to an event, and shall store the responsible operator’s identification (ID), the console ID, and the nature of the change.
The system shall add audit records to the event history or store audit records in the CAD system’s audit log file in chronological order; and, shall provide a complete historical audit of all event activity (e.g., comments, unit status changes, license plate information, field updates).
The system shall store old entry information, with the appropriate date, time, operator ID, and console stamps if the new entry replaces existing information in the event record.
The system shall enable the audit information to be retrieved and printed in both summary and detailed formats when incident information is displayed.
The system shall create a permanent audit trail for all information recorded related to an event, whether or not that information is later modified or deleted.
The system shall support ease of entry for supplemental event information and changes to existing event information.
The system shall allow the user to display a data entry screen to change information previously entered into a CAD event by specifying either the event number or a unit assigned to the event.
The system shall allow the user to display a supplemental data entry screen by specifying either the event number or a unit assigned to the event.
The system shall allow the user to update any field in the CFS event record (except user-designated fields, such as application-generated times and date stamps, operator identification information, ANI/ALI information, and CAD position that completed a CAD transaction).
The system shall document all changes and supplemental information in the event history.
The system shall provide an event update/change data entry screen.