HomeMy WebLinkAbout2016-09-27; City Council; Resolution 2016-200RESOLUTION NO. 2016-200
A RESOLUTION OF THE CITY COUNCIL OF THE CITY OF CARLSBAD,
CALIFORNIA, APPROVING AMENDMENT NO. 1 TO THE MASTER SUPPORT
AGREEMENT BETWEEN THE CITY OF CARLSBAD AND TIBURON
EXHIBIT 1
WHEREAS, the Police Department uses a Computer Aided Dispatch and Mobile system
{CAD/Mobile) that allows dispatchers to enter calls for service and officers to receive and send call data
from the field; and
WHEREAS, on March 2, 2016 the City entered into an agreement with Motorola Solutions Inc.
to provide a Police Records Management System (NetRMS) that will allow officers to store all crime
reports in electronic form in a central database; and
WHEREAS, the Police Department desires to implement an interface that will transfer basic call
data from CAD/Mobile system into NetRMS thereby eliminating the need for duplicate data entry; and
WHEREAS, the City entered into an agreement with Tiburon on December 9, 2014 for annual
support services; and
WHEREAS, the City Council of the City of Carlsbad, California has determined that it is in the
best interest of the City to execute and amendment to the Master Support Agreement to add services
for the implementation of an interface; and
NOW, THEREFORE, BE IT RESOLVED by the City Council of the City of Carlsbad, California, as
follows:
1. That the above recitations are true and correct.
2. That funds for this increase are currently budgeted in the innovation account in the
General Fund.
3. That the City Council of the City of Carlsbad approves Amendment No. 1 to the Master
Support Agreement between the City of Carlsbad and Tiburon, Inc. attached hereto as
Attachment A.
4. That the Mayor for the City of Carlsbad is authorized to execute Amendment No. 1 to
the Master Support Agreement between the City of Carlsbad and Tiburon, Inc.
EXHIBIT 1
PASSED, APPROVED AND ADOPTED at a Regular Meeting of the City Council of the City of
Carlsbad on the 27th day of September, 2016, by the following vote, to wit:
AYES: Hall, Wood, Schumacher, Blackburn, Packard.
NOES: None.
ABSENT: None. ~JU/ MA TI HALL, Mayor
(SEAL)
AMENDMENT NO. 1 TO MASTER SUPPORT AGREEMENT
TIBURON INC.
Amendm nt No. 1 is entered into and effective as of the a~ day of
---=~¥~w...Jl...!...._.l..)!,.~~.------' 2016, amending the agreement dated December 9, 2014
(the "Agree ent") by and between the City of Carlsbad, a municipal corporation, ("City"), and
Tiburon Inc., ("Contractor") (collectively, the "Parties").
RECITALS
A. On December 9, 2014 the Parties executed an Agreement for support services
that was effective July 1, 2014 relating to the Police Departments Computer Aided Dispatch and
Mobile system previously developed and implemented by Contractor; and
B. The Parties desire to alter the Agreement's scope of work to include services to
(1) move the currently installed Computer Aided Dispatch(CAD) system from a physical to a virtual
server, and (2) implement an interface between the CAD system and the Police Records
Management System (NetRMS); and
C. The Parties have negotiated and agreed to a supplemental scope of work and fee
schedule for services to move the CAD system to a virtual server, which is attached to and
incorporated by this reference as Exhibit "A", Scope of Services and Fee to Move CAD to a Virtual
Server.
D. The Parties have negotiated and agreed to a supplemental scope of work and fee
schedule for the CAD to NetRMS interface, which is attached to and incorporated by this reference
as Exhibit "B", Scope of Services and Fee for a CAD to NetRMS Interface.
NOW, THEREFORE, in consideration of these recitals and the mutual covenants
contained herein, City and Contractor agree as follows:
1. In addition to those services contained in the Agreement, as may have been
amended from time to time, Contractor will provide those services described in Exhibit "A".
2. That the fixed price fee for services to be provided pursuant to Amendment
Number 1 is sixty one thousand two hundred and twenty five dollars ($61 ,225) as further set forth
in Exhibit A and Exhibit B.
3. That the annual maintenance fee for the CAD to NetRMS interface is four thousand
five hundred dollars ($4,500) and will be prorated and paid at renewal of the existing support term
to adjust the term to be co-terminus with the existing annual term that begins on the first of July
of each calendar year according to the Agreement.
4. Contractor will complete all work described in Exhibit "A" within nine (9) months of
the Effective Date of this Amendment Number 1. The work described in Exhibit "B" herein will be
scheduled to commence at a mutually agreeable (City, Contractor, and City's RMS vendor) date.
5. All other provisions of the Agreement, as may have been amended from time to
time, will remain in full force and effect.
City Attorney Approved Version 1/30/13
Item #6 September 27, 2016 Page 5 of 35
6. All requisite insurance policies to be maintained by Contractor pursuant to the
Agreement, as may have been amended from time to time, will include coverage for this
Amendment.
7. The individuals executing this Amendment and the instruments referenced in it on
behalf of Contractor each represent and warrant that they have the legal power, right and actual
authority to bind Contractor to the terms and conditions of this Amendment.
CONTRACTOR
By:
(sign here)
Blake Clark, Chief Financial Officer
(print name/title)
By:
(sign here)
(print name/title)
CITY OF CARLSBAD, a municipal
corporation of the State of California
ATTEST:
~ &.lli-: o6{ BARARAENGLESON~
City Clerk
If required by City, proper notarial acknowledgment of execution by Contractor must be attached. If a
corporation, Agreement must be signed by one corporate officer from each of the following two groups:
Group A
Chairman,
President, or
Vice-President
Group B
Secretary,
Assistant Secretary,
CFO or Assistant Treasurer
Otherwise, the corporation must attach a resolution certified by the secretary or assistant secretary under
corporate seal empowering the officer(s) signing to bind the corporation.
APPROVED AS TO FORM:
City Attorney Approved Version 1/30/13
2
Item #6 September 27, 2016 Page 6 of 35
EXHIBIT "A"
SCOPE OF SERVICES AND FEE TO MOVE CAD TO A VIRTUAL SERVER
Remotely, Tiburon will provide the services to move the current product Computer Aided Dispatch
server from a physical server whose name is SCCADAPP01 (CADLIVE) to a virtual server (VM).
All work will be completed remotely during Tiburon's normal business hours Monday through Friday
(0800 -1700). All work will be supervised by a City of Carlsbad employee.
Requirements:
• Virtual Machine that runs the CAD Application may not share its DataStore with other VM's
vDisks.
• New VM Datastore has 15k spindles on that datastore. This is implied by the doc but not
specified.
Tiburon Responsibilities
1. Stage CommandCAD including all interfaces residing on SCCADAPP01 (CADLIVE) to new VM
provided by the City.
2. Test interfaces where feasible.
3. Cut over to new CAD Server.
4. Upon Client's testing, correct any discrepancies in operation based on the Scope Description.
Client Responsibilities
1. Designate a person to be the principal point of contact for all technical questions and
administrative arrangements relating to this Proposal.
2. Provide supervised remote access to Tiburon.
3. Create a new VM machine following the attached Guidelines and adhering to the Requirements
above.
4. Test CommandCAD on new VM after Tiburon installs CommandCAD on new VM.
5. Test interfaces if possible (may require switching an interface from Live to the VM machine).
6. Client is responsible for swapping any physical interface connections from old to new server.
7. Client will adhere to CAD Network guidelines document with regard to Firewalling, Backups and
Antivirus on new server.
8. Client will ensure NIC conforms to CAD Network Guidelines and appropriate ports are open for
CAD join operation and communication with database.
9. As required, coordinate the participation of non-Tiburon provided third parties and outside
agencies.
10. Complete testing of the modified code within ten (10) business days from receipt of Tiburon's
notification the code is ready for testing to ensure conformance with the Scope Description.
Fee and Payment Schedule
Item Description Fee
Move CAD to Virtual server 2,800
Project Management 875
Total $3,675
3 Item #6 September 27, 2016 Page 7 of 35
Payments will be made upon the following milestones at the listed percentages
Milestone Percentage
Delivery of statement of work 50%
Cutover to new CAD Server 50%
Completion Criteria
This work will be considered complete ten ( 10) business days after Tiburon has provided Client with
written notification that virtual CAD server is in production. If Client does not confirm completion with a
sign off letter presented by the Tiburon project manager within ten (10) business days of submittal of
such letter, or otherwise notifies Tiburon in writing why completion sign-off has not been provided any
final invoice(s) will be issued and will be payable in accordance with the payment terms of this
Proposal.
4 Item #6 September 27, 2016 Page 8 of 35
EXHIBIT "B"
SCOPE OF SERVICES AND FEE FOR CAD TO NETRMS INTERFACE
Scope Description
Tiburon will provide the services to create an interface from CAD to NetRMS according to the
specifications attached in Exhibit "C", NetRMS Interface Requirements Document.
All work will be completed remotely during Tiburon's normal business hours Monday through Friday
(0800 -1700). All work will be supervised by a Carlsbad Police Department employee. The City will
assign a Project Manager to act as the primary point of contact for the City for this project.
Assumptions
• Interface is uni-directional, CommandCAD to NetRMS.
• Data is sent as it exists in CommandCAD and does not include any translation or modification.
• Does not include any changes to CommandCAD database field sizes.
• Transfer is configurable via settings in File Maintenance Agency table "Transfer At" field. The
A enc can select three from the below choices: r 90 -Transferred at case assignment r 80 -Transferred at first call dispatch 1 r 70 -Transferred at first call onscene r 60 -Transferred at unit onscene r 50 -Transferred at first call okay r 40 -Transferred at unit okay r 30 -Transferred at first call transport comr r 20 -Transferred at unit transport complete r 1 O -Transferred at unit clearing r 5 -Transferred at call closure
• Only data available in CommandCAD will be sent. If NetRMS has data fields that do not exist in
CommandCAD, the data will be empty in the xml.
• Does not include any logic related to fields such as "if field x = y, then do something".
• Does not include logic to interrogate the CommandCAD data to satisfy a field in NetRMS. For
example, if NetRMS requires a flag or indicator to be set to Y or N, and CommandCAD does not
have that indicator but data exists within the data that could be interrogated to set a Y or N, that
interrogation logic is not included.
• Does not include adding text to xml data. Motorola's IRD v2 in Section 4.6 talks about sending
multiple Cases for a single CAD incident. Tiburon needs to clarify that if multiple Cases are
assigned to a single CAD incident, Tiburon CAD will send separate INC01 and INC02 files for
each Case. Tiburon's CAD does not have the ability to combine the multiple cases within a
single INC01 and INC02 as it seems that the specification is requiring.
• If data in CAD, such as Personnel number for example, must match corresponding table entries
in NetRMS, then Client will ensure the table values match. However, field sizes in
CommandCAD will not be changed to match NetRMS field sizes.
Tiburon Responsibilities
1. Provide the interface per the Scope Description.
5 Item #6 September 27, 2016 Page 9 of 35
2. Install the interface in Client's test environment.
3. Upon Client's testing, correct any discrepancies in operation based on the Scope Description.
4. Install the interface in Client's production environment.
Client Responsibilities
1. Designate a person to be the principal point of contact for all technical questions and
administrative arrangements relating to this Proposal.
2. Provide VPN access to Tiburon.
3. Coordinate the participation of non-Tiburon provided third parties and outside agencies.
4. Complete testing of the interface within ten ( 10) business days from receipt of Tiburon's
notification the code is ready for testing to ensure conformance with the Scope Description.
Fee and Payment Schedule
Item Description Fee
NetRMS Interface 25,000
NetRMS Interface Implementation Fee 24,500
Project Management 8,050
Total $57,550
NetRMS Annual Maintenance 4,500
Payments will be made upon the following milestones at the listed percentages
Milestone Percentage
Milestone 1: Delivery of statement of work 50%
Milestone 2: Ten (10) days after installation in 50%
the Client's production environment without
any issues rendering the interface inoperable.
Issues not caused by the Tiburon interface, or
not under Tiburon's direct control shall not
be considered as causing the interface to be
inoperable.
Completion Criteria
This work will be considered complete ten (10) business days after Tiburon has provided Client with
written notification that Milestone 2 is complete. If Client does not confirm completion with a sign off
letter presented by the Tiburon project manager within ten (10) business days of submittal of such
letter, or otherwise notifies Tiburon in writing why completion sign-off has not been provided any final
invoice(s) will be issued and will be payable in accordance with the payment terms of this Proposal.
6 Item #6 September 27, 2016 Page 10 of 35
EXHIBIT "C"
This Interface Requirements Document (IRD) describes the uni-directional interface between CAD
and Motorola's NetRMS Records Management System for Agency. The purpose of this interface is to
transfer CAD Call for Service (CFS) information to NetRMS.
In this document, the following references shall apply:
"Customer" shall refer to the City of Carlsbad.
"CAD" or "CAD system" shall refer to the Computer-Assisted Dispatch ("CAD") system
Customer uses CAD to manage incident information, including dispatch and call for service requests.
The uni-directional interface described in this IRD defines an interface that will allow for the
transmission of CFS data from CAD to the NetRMS application. No manual intervention will be
required to initiate the CFS data exchange.
CAD provides dispatch services to Customer in response to calls-for-service received. Many of the
calls-for-service result in a dispatcher's initiating an "incident" in CAD, which generally requires a
response by Customer. During the time that each incident is open (being worked by a call-taker or
dispatcher), the CAD application collects the incident related data entered by the users. Once the
incident is closed, all incident data is stored as a CFS record.
Customer uses the Motorola N etRMS to maintain a central repository of Incident Records and other
records management related data
Following entry of the appropriate Call for Service information, the CAD system will send the CFS
record to NetRMS. NetRMS will then populate a CFS record with the data received from CAD, as
defined further in this IRD.
Motorola Responsibilities
1. Installation and configuration of the NetRMS components required to support this interface.
2. Provide technical support to Customer or to a third-party as required to implement this interface
on the CAD side.
Customer Responsibilities
1. Providing Local Area Network (LAN) connectivity between CAD and the N etRMS system.
2. Insure CAD is configured to provide a combined XML file (Call and Unit data) for CAD
incidents.
3. Ensure that support is provided from other vendors, as required for interface integration.
Other Assumptions
1. This IRD is written with the assumption that the interface will provide CAD Incident Records to
7 Item #6 September 27, 2016 Page 11 of 35
the NetRMS upon incident creation, when an incident is updated by the below recommended
triggers, and after the incident is closed in CAD.
2. The CFS Record created by the interface will be read-only in the NetRMS system.
3. Mapped Code Table field values must match between CAD and NetRMS.
Application Versions
NetRMS vl.94.2 or later San Diego Build.
Acronyms and Definitions
ARJIS -Automated Regional Justice Information System
CAD -Computer Aided Dispatch
CFS -Call For Service
IRD -Interface Requirements Document
LAN -Local Area Network
RMS -Records Management System
TCP/IP -Transport Control Protocol/Internet Protocol
XML -Extensible Markup Language
NTFS -New Technology File System
References
633607978333695000 5604.xml CAD Export XML file
The communication of incident related data from CAD to NetRMS occurs automatically and is
transparent to the CAD and NetRMS users.
Logical Interconnection
The data exchange between CAD and NetRMS takes place via an XML file.
The CAD server creates an XML file that contains the incident data when the incident in closed in the
CAD application. Incident Data will include the CAD INCOl record and an INC02 entry for each unit
involved.
8 Item #6 September 27, 2016 Page 12 of 35
CAD
,---------------I
' CAD ' ' ' Client ' ' ' Workstations _ -·
LAN based File System Environment II,,. -CAD .... NetRMS
Server
Figure -1. CAD to NetRMS Interface, Logical Data Flows
Equipment Interconnection
The CAD Server transmits data to the NetRMS CAD Interface via a shared file folder accessible on
Customer's network by both systems.
There is no physical interconnection between the two systems. The CAD Server shall "drop" files
containing the CAD Call for Service information into the shared folder, from which they will be
retrieved, processed, and then deleted by the NetRMS CAD Interface process.
The exact location of the shared folder is configurable in the NetRMS CAD Interface and is up to
Customer to determine. The NetRMS CAD Interface simply requires that the folder be accessible as
a Windows NTFS folder and be read/writeable by the CAD Interface software.
Functional Description
Data exchange between CAD and the NetRMS systems takes place via the creation of an XML file by
the CAD server. This XML file will be written into a Windows-based NTFS shared folder. This
folder will be located in the LAN environment that can be accessed by CAD and NetRMS.
The NetRMS interface components will monitor the designated folder share and will detect the
creation of the XML CAD export file. Upon detection, the NetRMS interface components will open
the XML file and parse the data into a NetRMS CFS record according the specified field mapping.
Upon successful creation of the NetRMS CFS record the CAD created XML incident file will be
deleted.
The CAD export record can be created upon multiple different conditions on the CAD system. At a
minimum, the CAD system must create and forward the XML file as soon as possible when any of
the following conditions occurs:
• Assignment of a Case Number to a CAD Incident (whether this is the first Case Number or
9 Item #6 September 27, 2016 Page 13 of 35
any subsequently assigned Case Number); note that this also applies to any CAD Incident
that is re-opened and has one or more new Case Numbers added to the Incident;
• Closure of a CAD Incident previously reported to NetRMS (i.e., where at least one Case
Number has been assigned to the Incident); note that this also applies to any CAD Incident
that is re-opened and then re-closed, if at any point that Incident had one or more Case
Numbers assigned.
It is recommended, but not mandatory that the CAD Incident data is also transferred to NetRMS when
an Incident already being reported has any change of assigned Units.
It is recommended and acceptable, but not required, for all CAD Incidents to be reported to NetRMS,
whether or not the Incident is ever assigned any Case Numbers.
It is recommended and preferred, but not required, that CAD only send an XML message for a
particular Incident when one of the following conditions occurs:
• There is a new Case Number assigned to the Incident
• The Incident Status is changed to Closed
• There is a change of Units assigned to the Incident
• ( optionally) A new Incident is created
The interface will analyze the CaseNo field in the XML export and if a value is present the system
will query the cases table to determine if a case with the same case number exists. If the case number
already exists the system will continue with the CFS creation and associate the CFS with the existing
case. If the case number does not already exist the system will create a new Case Folder with the
provided number and then continue with the CFS creation processes and associate the new CFS with
the newly created Case Folder. Multiple Case Numbers may be included for a single incident. For
multiple Case Numbers each number will be evaluated separately and a Case Folder created for each.
Note: Only one CFS record will be created for calls with multiple reports.
The following is a general overview of the processing of an XML file:
1. Retrieve the next available XML file from CAD (in date/time order)
2. Validate the XML and field values
3. If the Call for Service (CFS) incident Identifier does not exist in NetRMS, then create a new
CFS record
4. Update the CFS record with the data from the XML (Note~ any previously existing
information in the CFS record is completely overwritten with the new data.)
5. If the XML contains one or more Case Numbers, then
a. If the Case Number does not exist, then create a new Case folder
b. Associate the Case folder with the CFS record
6. If the XML contains one or more INC02 record(s) with Personnel numbers, then for each
Personnel record included in the XML
10 Item #6 September 27, 2016 Page 14 of 35
a. If the Personnel record is not already associated to the Case folder, associate the
Personnel record to the Case
7. If the XML was processed without errors, commit the changes to the NetRMS database and
move the XML file to the "processed" folder (from which it will be automatically deleted
after a configurable period of time)
8. If the XML was unable to be processed successfully, discard the NetRMS changes and move
the XML to the "failed" folder (Note~ this folder is not automatically monitored or reported.
It is Customer's responsibility to inspect this folder if there are indications that any CAD
messages failed to arrive at NetRMS.)
11 Item #6 September 27, 2016 Page 15 of 35
CAD Incident XML DATA
CAD Incident XML data shall consist of two types of Incident data records, referred to as Incident
(INCOl) and Incident Unit (INC02) data records. Each XML file shall consist of one INCOl record,
and each INCO 1 record may include zero or more INC02 records ( one INC02 record for each Unit
assigned to the Incident).
Any field with a "Field Type" of "constant" must be present and must contain the XML tag and field
values shown.
Any field designated as any other type ( e.g., "int", "varchar xx", etc.) may be omitted entirely if there
is no associated value available to provide, or may be included as just the Begin and End Tags ( e.g.,
"<division></ division>").
Any field designated as "datetime" must contain a valid XML date/time value ("xs:dateTime" type),
of the format: yyyy-mm-ddThh:mi:ss (e.g., "2015-09-13Tl5:42;19"). The time component must be
in 24-hour format.
Any field designated as "varchar" should not include any leading or trailing spaces.
Any field designated as "bit" should contain either a "O" or a "l" character ( or no character if the
value is not being provided).
NOTE -these record formats include many fields which are not used in the NetRMS CAD Interface.
The complete field list is included below, and unused fields may be included in the messages, but
unused fields will be ignored by the interface if present. In the following record definitions, required
fields will be shown in BOLD text, and unused field will be italicized. Fields that are neither Bolded
nor Italicized contain additional information that will be recorded in the NetRMS Call For Service
records, but are not required to be supplied in every message. Note that some "not required" fields
are in fact critical to proper operation, such as the "casenumbers" field, which is required in order
cause the NetRMS CAD Interface to automatically open a NetRMS Case and perform officer
assignments to the Case. However, these fields may not have data available at all times (such as
between initiation of a CAD Incident and subsequent assignment of a Case Number to that Incident),
and are thus not mandatory/required in every message.
12 Item #6 September 27, 2016 Page 16 of 35
Incident Data (INC01)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
The Incident Data (INCOl) record shall contain the information about the incident, using the fields
and XML tags as defined below.
rmsiteml constant <?xml
version="l.0" ?>
rmsitem2 constant <Doc>
rmsitem3 constant <HEADER>
rmsitem4 constant <MESSAGE TYPE Update </MESSAGETYPEI
ID> D>
rmsitemS constant <DESTINATION RMS </DESTINATIONN
NAME> AME>
rmsitem6 constant <P ACKETTYPE> INCOl <IP ACKETTYPE>
rmsitem7 constant <MESSAGELOG CurrentTime </MESSAGELOGTI
TIME> ME>
rmsitem8 constant </HEADER>
rmsitem9 constant <ROW>
id int Record ID of the <id> response_ master_ </id>
response master incident.id
incident
master incident n varchar Number uniquely <master incident response_ master_ </master incident n - -- ---umber 20 identifies incident number> incident.master i umber>
ncident number
custom _jur _ number varchar Custom number <custom _jur _ numb CusN </custom _jur _ number
20 generated by interface er> >
or incident
rim_ custom _jur _ n varchar Custom jurisdiction <prim_ custom _jur _ PrimCN </prim_ custom _jur _ n
umber 20 number generated by number> umber>
interface
response_ date datetime Date incident was <response_ date> response_ master_ </response_ date>
created incident.response
date -
agency_ type var char Agency in which the <agency_ type> response_ master_ i </agency_ type>
30 call was created ncident.agency _ ty
pe
jurisdiction varchar Jurisdiction of the call <jurisdiction> response_ master _i </jurisdiction>
30 ncident.jurisdiction ** Not Supported**
division varchar Division of the call <division> response_ master _i </division>
30 ncident. division
battalion varchar Battalion of the call <battalion> response_ master _i </battalion>
30 ncident. battalion
beat* varchar Beat Number <beat> Beat number* </beat>
30
sector* var char Beat Number <sector> Beat number* </sector>
30
13 Item #6 September 27, 2016 Page 17 of 35
,ft~;"' I jW 0: =; f if,ici~ ~1~/z"~-3;,A~"Jf:~"" ": / °' u)< ""~ ; 0 " "
0%0 0 $ 0 0 0 A --0 e 0 A 0 0 00
~~e;t" =: JllieliilU&e1 "WI 0--~ t~J@ef!JII!S!~iBlttlm
0
" r : "~"!Begim~agip" -Jirira1:ll;lnei:0 . ;Bual fflag: , 0 ]
~~"'-'"* :::*1 -~ ~"' "'_&0:@ 11::":._~i~'lt 1r:"';'0=j d""~ bk\~:::"'}::~ -f fif!vfigJ "":,m2 @! 1 -= $$ ,;= '110 ~ = »~ "",;;; "5'"' ==rrc ~~ *~ " 0 0'. B\@ =
21 station varchar Station code of the <station> station code </station>
30 !Primary unit
22 response_ area varchar Geographical <response_ area> response_ master _i </response_ area>
30 boundary defining ncident. response_ a
which units and rea
!Personnel are
responsible for an
incident
23 response _time_ crite date time The mandated <response _time_ cri response _master _i </response _time_ crite
ria response time from teria> ncident.response _t ria>
dispatch to arrival on-ime criteria -
scene
24 response _ylan varchar Plan which specifies <response _ylan> response_ master _i </response _ylan>
30 units VisiCAD should ncident. response _y
recommend for an Zan
incident
25 incident_ type var char Incident type to which <incident_ type> response_ master_ i </incident_ type>
30 problem nature of ncident.incident_ ty
incident belongs pe
26 problem varchar Incident problem <problem> response_ master _i </problem>
30 nature ncident.problem
27 priority_ number int A number representing <priority_ number> response_ master _i </priority_ number>
the incident's priority ncident.priority _ nu
mber
28 tpriority _ description varchar Description of incident <priority_ descripti response_ master _i <!priority_ description
30 priority on> ncident.priority _ de >
scription
29 location name var char Premise location <location name> response_ master_ i </location name> ---50 ncident.location n -
ame
30 housenumber varchar Incident address <house_number> response_master _ </house_number>
10 house number incident.house nu
mber
31 house number suffi varchar Incident address house <house number suf response_ master_ i </house number suffi ------
X 10 number suffix fix> ncident.house nu x> -
mber suffix -
32 prefix_ directional var char Incident address prefix <prefix_ directional response_ master_ i </prefix_ directional>
22 directional > ncident.prefix _ dire
ctional
33 name_ component varchar Address street name <name_ component response_ master _i </name_ component>
40 component > ncident.name com -ponent
34 post_ directional var char Incident address post <post_ directional> response_ master _i </post_ directional>
22 directional ncident. post_ direct
ional
35 street_type var char Incident street type <street_ type> response_ master_ i </street_type>
15 reference ncident.street_ type
14 Item #6 September 27, 2016 Page 18 of 35
l,4= ~-~~;: ~s£~s % ;""= ,;_""lf'r•% i"" 4; 0"7::0 /0= '° -"~-=y:/; ~:'':: :*~;88 =~~!;~>+~ ::~4~;::~~;,:,,;,;::~~J = «"";:~"~~:7!f;Yff:':wffj;:z:,irJ:;::t,,;J~~
~~llgjN Bw ilielQ;Re~0 ' r:; !0 ))lJiefqiUesi10iil:1iom* ~0:;: ':iflegin,!lag;:: ~: :::qielitw"l"iilu~" f v~~vlmli<Jmii::0 ~'*'~ ~ % :::~"',,~ ,,;~ ~ *! ;, «/ vvi Sf::: v:11ftq~f; :"''::"'1Vi;Jt::v:':°'~~;/4=,2ffJ%,/:/ ,i °' f,,= ~ =B::~'0;""';; ; "'=V ;:: :sfJt:::JP?f~:~vv:'h~~:#:sf~:"~G~""""" :~~~;:iv:::~::~::JPS=
36 apartment varchar Incident address <apartment> response_ master _i </apartment>
10 apartment ncident.apartment
37 city var char City in which incident <city> response_ master_ i </city>
35 occurred ncident.city
38 state varchar 5 State/province in <state> response_ master _i </state>
which incident city is ncident.state
located
39 postal code var char Postal code for <postal_ code> response_ master_ i </postal_ code>
10 incident address ncident.postal_ cod
e
40 county varchar County in which <county> response_ master _i </county>
30 incident address is ncident. county
located
41 location_ type varchar If premise, type of <location_ type> response_ master _i </location_ type>
30 premise (e.g., hospital, ncident. location_ ty
school, bank, etc.) tpe
42 longitude int Alphanumeric <longitude> response_ master_ i </longitude>
characters indicating ncident.longitude
longitude boundaries
of degrees minutes and
seconds for the
address of the incident
43 latitude int Alphanumeric <latitude> response_ master _i </latitude>
characters indicating ncident.latitude
latitude boundaries of
degrees minutes and
seconds for the
address of the incident
44 map_info varchar Incident address map <map_info> response_ master _i </map _info>
JO page and grid ncident.map _info
reference (mapbook ** Not Supported
lookup) **
45 cross street varchar Closest cross street to <cross street> response_ master _i </cross street> --80 incident ncident. cross stree -
t
46 methodofcallrcvd varchar Way in which <methodofcallrcvd> response_ master _i </methodofcallrcvd>
30 emergency call was ncident.methodofc
received ( e.g., 911, allrcvd
walk-in, etc.)
47 call_ backyhone varchar Calling party's call <call_ back _yhone> response_ master _i <lcall _ back_yhone>
20 back phone number ncident.call back -
phone
48 caller_ type varchar Type of caller (e.g., <caller_ type> response_ master _i </caller_ type>
30 lfamily member, ncident.caller _type
doctor, member of the
1,public, etc.)
49 caller name var char Name of calling party <caller name> response_ master_ i </caller name> --30 ncident.caller nam -
e
15 Item #6 September 27, 2016 Page 19 of 35
50 caller_location_nam varchar If calling from a
e 50 premise such as a
hospital, name of the
premise
51 caller _address varchar Address of calling
80 party
52 caller_apartment varchar If calling from an
10 apartment, apartment
#
53 caller _city varchar City in which calling
35 party is located
<caller _location_na
me>
<caller _address>
<caller _apartment>
<caller _city>
response_master _ </caller _location_na
incident.caller _loc me>
ation_name
response_master _ </caller_address>
incident.caller _ad
dress
response_master _ </caller _apartment>
incident.caller _a pa
rtment
response_master _ </caller_city>
incident.caller _city
54 caller state varchar 5 State in which calling <caller state>
party is located
response_ master_ i </caller_ state>
ncident.caller state
55 caller _postal_ code var char Postal code for the
10 address associated
with the calling party
56 caller_ county varchar County in which caller
30 is located
57 caller _location _pho varchar Phone at caller's
ne 20 address
58 time _phonepickup datetime Timestamp for phone
pickup
59 time firstcall datetime Timestamp for first
keystroke was entered
for the incident
60 time_ callenteredque date time Times tamp for when
ue call was saved in
waiting incident queue
61 time_ calltakingcom date time
lete
Timestamp for when
call taking was
completed
62 time incident under datetime Timestamp for when
incident was under
control
63 time callclosed datetime Timestamp for when
incident was closed
<caller _postal_ code response_ master _i </caller _postal_ code>
> ncident.caller _post
al code
<caller _county> response_ master _i </caller_ county>
ncident.caller cou
nty
<caller _location _ph response_ master_ i </caller _location _pho
one> ncident.caller loca ne>
tion_phone
<time _phonepickup response_ master _i </time _phonepickup>
> ncident. time _phon
epickup
<time firstcall> response_ master_ i </time firstcall>
ncident.time firstc
alltakingkeystroke
<time_ callenteredq response_ master _i </time_ callenteredqu
ueue> ncident. time calle eue>
nteredqueue
<time_ calltakingco
mplete>
response_ master _i </time_ calltakingcom
ncident. time call ta lete>
kingcomplete
<time _incident _und response_ master _i </time incident unde
er> ncident.time incid r>
ent under control
<time call closed> response_ master_ i </time callclosed>
ncident.time callcl
osed
16 Item #6 September 27, 2016 Page 20 of 35
64 time senttoothercad datetime
65 time first unit assi datetime
gned
Timestamp for when
call transferred to
remote CAD, used in
CAD2CAD interface
Timestamp for when
the first unit was
assigned to the
incident
66 time _first_ unit _enro datetime Timestamp for when
ute the first unit was
enroute to the incident
67 time first unit arri datetime
ved
Timestamp for when
the first unit arrived at
the scene of the
incident
<time senttootherc response_ master _i </time senttootherca
ad> ncident. time sentt d>
oothercad
<time first unit as response_ master _i </time first unit ass1
signed> ncident.time first gned>
unit_ assigned
<time _first_ unit_ en response_ master _i </time _first _unit_ enr
route> ncident. time _first_ oute>
unit enroute
<time_ first_ unit_ arr response_ master _i </time first unit arri
ived> ncident.time first ved>
unit arrived
68 elapsed_callrcvd2in datetime Elapsed time between <elapsed_callrcvd2 response_ master _i <lelapsed _ callrcvd2in
ncident. elapsed_ ca queue>
llrcvd2inqueue
queue when call was inqueue>
received and call was
saved in the waiting
incident queue
69 elapsed_callrcvd2ca datetime Elapsed time between <elapsed_callrcvd2
ltakdone when the call was caltakdone>
received and call
taking was completed
70 elapsed_inqueue_2_ datetime Elapsed time between
1rst call was saved in the
waiting incident queue
and the first unit was
assigned
<elapsed _inqueue _
2_first>
response_ master _i <lelapsed _ callrcvd2c
ncident.elapsed_ca altakdone>
llrcvd2 caltakdone
response_ master _i </elapsed _inqueue _ 2
ncident. elapsed _in _first>
queue_ 2 _firstassig
n
71 elapsed_ callrcvd2fir datetime
stassign
Elapsed time between
call was received and
the first unit was
assigned
<elapsed_ callrcvd2 response_ master _i <lelapsed _ callrcvd2fi
72 elapsed_ assigned2fi datetime
rstenr
Elapsed time between
call was saved in the
waiting incident queue
and the first unit went
enroute
1rstassign> ncident.elapsed_ca rstassign>
llrcvd2firstassign
<elapsed_ assigned
2firstenr>
response_ master _i </elapsed_ assigned2fi
ncident. elapsed_ as rstenr>
signed2firstenrout
e
73 elapsed_enroute2fir datetime Elapsed time between <elapsed_ enroute2f response_ master _i </elapsed_ enroute2fir
stat 1rst unit went enroute
and first unit was at
scene
irstat> ncident.elapsed_en stat>
route2firstatscene
74 elapsed_callrcvd2ca datetime Elapsed time between <elapsed_callrcvd2
llclosed when call was callclosed>
received and when call
was closed
75 calltaking_performe varchar Name of user <calltaking_perfor
d_byt 25 performing call taking med_ by>
17
response_ master _i <lelapsed _callrcvd2c
ncident. elapsed_ ca all closed>
llrcvd2 call closed
response_ master _i </calltaking_performe
ncident.calltaking_ d _ by>
performed_ by
Item #6 September 27, 2016 Page 21 of 35
76 callclosing_yerform varchar Name of user who
ed_by 25 closed the call
77 calldisposition _yerf varchar Name of user who
armed 25 entered call
disposition
78 zxed _time _yhonepi datetime
ckup
Read-only time stamp
or time phone was
ickedup
79 zxed time callenter datetime Read-only time stamp
edqueue or time call entered
80 zxed time calltakin datetime
gcomp
Read-only time stamp
or time call taking
was completed
81 zxed time callclose datetime Read-only time stamp
d when call was closed
<callclosing_yerfor response_ master _i </callclosing_yerform
med_by> ncident.callclosing ed_by>
___performed_ by
<calf disposition _ye
rformed>
<fixed _time ___phone
ickup>
response_ master _i </calldisposition _yerf
ncident.calldisposi armed>
tion _ye1formed _ by
response_ master _i </fixed _time _yhonepi
ncident.fixed_time ckup>
_yhonepickup
<fixed _time_ callent response_ master _i </fixed _time_ callente
eredqueue> ncident.fixed_time redqueue>
_callenteredqueue
<fixed _time_ calltak response_ master _i </fixed _time_ calltaki
ingcomp> ncident.fixed_time ngcomp>
_ calltakingcomplet
e
<fixed _time_ callclo response_ master _i </fixed _time_ callclos
sed> ncident.fixed_time ed>
call closed
82 zxed time senttoot datetime Read-only time stamp <fixed _time _sentto response_ master _i </fixed _time _senttoot
hercad when call was othercad> ncident.fixed _time hercad>
83 emd used
84 cis used
85 determinant
86 roqa _ casenumber
87 senttobilling_jlag
88 ani number
89 ali_info
int
int
varchar
JO
varchar
JO
bit
varchar
20
varchar
50
transferred to remote senttoothercad
CAD
Incident ProQA <emd used>
reference, indicated
PROQA was used for
call
Incident protocol <cis used>
reference, indicates
VisiCAD protocol was
used for call
Incident's PROQA <determinant>
determinant
Incident's PROQA <proqa _ casenumbe
case number r>
Incident sent to billing <senttobilling_jlag
ag >
Incident automatic <ani number>
number identification
information
Incident ALI <ali_info>
(automatic location
information)
18
response_ master _i </emd used>
ncident.emd used
response_ master _i <leis used>
ncident.cis used
response_ master _i </determinant>
ncident. determinan
response_ master _i <lproqa _ casenumber
ncident.proqa _ cas >
enumber
response_ master _i <lsenttobilling_jlag>
ncident.senttobillin
g_jlag
response_ master _i <Jani number>
ncident.ani numbe
r
response_ master _i </ali_info>
ncident. ali _info
Item #6 September 27, 2016 Page 22 of 35
varchar
30
channel
Primary tactical
channel for radio
communication on the
incident
92 alternate tac chann varchar Alternate to primary
el 30 TAC channel
93 call_ disposition varchar Disposition by which
30 call was closed
94 cancel reason varchar Reason why call is
30 cancelled
95 late_flag varchar Flag to indicate if call
1 was late and response
time criteria was not
met
96 whichqueue varchar Indicator for which
1 VisiCAD queue
incident is currently
97 confirmation_ numb varchar Confirmation number
er 20 or patient transport
98 building varchar Building in which
10 incident occurred
99 caller_ building varchar Building from which
10 calling party is making
the call
100 certification _level varchar Incident certification
10 level
101 base _response_ num varchar Response number for
ber 20 zrst unit assigned to
incident
102 call is active int Flag to indicate if call
is active
103 call source var char Where call originated
30 ( e.g., doctors office,
public phone, etc.)
104 multi _patients int Indicates multiple
patients for a
transport
response_ master _i
ncident.command >
channel
<primary _tac_ chan response_ master _i </primary _tac_ chann
nel> ncident.primary _ta el>
c channel
<alternate tac cha response_ master _i </alternate _tac_ chan
nnel> ncident.alternate t nel>
ac channel
<call_ disposition> response_ master _i </call_ disposition>
ncident.call_ dispos
ition
<cancel reason> response_ master _i </cancel reason>
ncident. cancel rea
son
<late _flag> response_ master _i </late _flag>
ncident. late _flag
<whichqueue> response_ master _i <lwhichqueue>
ncident. whichqueu
e
<confirmation_ num response_ master _i </confirmation_ numb
her> ncident. confirmati er>
on number
<building> response_ master _i </building>
ncident. building
<caller _building> response_ master _i </caller _building>
ncident.caller buil
ding
<certification _level response_ master _i </certification _level>
> ncident. certificatio
n level
<base _response_ nu response_ master _i </base _response_ num
mber> ncident. base _respo ber>
nse number
<call is active> response_ master _i </call is active>
ncident.call is act
ive
<call source> response_ master _i </call source>
ncident.call source
<multi _patients> response_ master _i </multi _patients>
ncident.multi _patie
nts
19 Item #6 September 27, 2016 Page 23 of 35
105 call_ back _phone_ ex varchar Extension number of <call_ back _phone_ response_ master _i </call_ back _phone_ e
t 9 call-back phone ext> ncident. call back xt>
number
106 num aniali calls int Count of duplicate <num aniali calls response_ master _i </num aniali calls> - -
ANIALI calls received > ncident.num aniali
calls
107 delay _reason varchar Reason entered for <delay _reason> response_ master _i </delay _reason>
30 why unit is delayed ncident.delay _reas
on
108 remiseid varchar Premise location code <premiseid> response_ master _i </premiseid>
30 ncident.premiseid
109 casenumbers** function Case numbers for the <casenumberlist> delimiter: </casenumberlist>
incident. Please note <casenumber>
there could be multiple
case numbers for a
single incident.
110 responsecomments Start oflncident <commentlist>
comments.
Please note there could
be multiple comments
for a single incident.
Individual comment <comment> Comment text </comment>
within the list
End oflncident </commentlist>
comments.
111 ackid pass-m <ackid> Passin: AckID </ackid>
112 unit_ assignment pass-in Placeholder within <units_ assigned> INC02 records </units _assigned>
INCOl message to
build INC02 structure
113 row end constant </ROW>
114 docend constant </Doc>
* Beat_Number -The Beat Number must exactly match a Beat defined in NetRMS. Note that Beat numbers may have
leading zeroes, in which case the the leading zeroes must be included in this field. Beat "01" is not the same as Beat "1 ".
For historical reasons, the Beat should be included in both the "Beat" and "Sector" fields to ensure proper processing.
** Case Numbers -Case Numbers must be exactly as they are to be entered/referenced in the ARJ/5 system. There is no re-
formatting of Case Numbers in NetRMS. If a Case Number is received from CAD as "15-00012345", it will be used
throughout NetRMS and be transmitted to ARJ/5 as "15-00012345".
t "calltaking_performed_by" -if present, this must contain a valid NetRMS Personnel No value from the Personnel table.
This is similar to the "emp_id" field in the INC02 record.
20 Item #6 September 27, 2016 Page 24 of 35
Unit Data (INC02)
An INC02 record will be included for each Unit assigned to the incident.
] jurisdiction pass-in <jurisdiction> CusNuml </jurisdiction>
** Not Supported
**
: custom _jur _ nu varchar Unit's jurisdiction number <custom _jur _ num response_ master _inci </custom _jur _ num
mber 20 her> dent.master incident her>
~ radio name --varchar Unit's radio call sign
JO
<radio name>
number
response_vehicles_ass </radio name>
igned. radio_ name
L1 time_ assigned date time Times tamp for when unit
was assigned
<time_ assigned> response _vehicles_ ass </time_ assigned>
igned. time_ assigned
: date_ assigned datetime Timestamp for date unit was <date_ assigned>
assigned
E time_ enroute datetime Timestamp for when unit
went enroute
<time enroute>
' date enroute datetime Timestamp for date unit went <date enroute>
enroute
E time_ arrivedat datetime Timestamp for when the unit <time_ arrivedatsc
scene arrived at scene ene>
S date_arrivedat datetime Date of when the unit
scene arrived at scene
1 ( time time con datetime Time unit made patient
tact contact
11 date time con datetime Date unit made patient
tact contact
1: time_ depart _s date time Times tamp for when unit
1:
IL
1:
cene departed scene of the
incident
date_ depart _s datetime Date unit departed the scene
cene of the incident
time _staged datetime Timestamp for time unit was
staged at the incident
date _staged datetime Date when unit was staged
at the incident
<date arrivedatsc
ene>
<time time conta --ct>
<date time conta
ct>
<time_ depart _see
ne>
<date_ depart _see
ne>
<time _staged>
<date _staged>
21
(hh:mm:ss)
response_ vehicles_ ass </date_ assigned>
igned.time _ assigned
(mm/dd/yy)
response_ vehicles_ ass </time enroute>
igned. time_ enroute
(hh:mm:ss)
response _vehicles_ ass </date enroute>
igned. time_ enroute
(mm/dd/yy)
response_ vehicles_ ass </time arrivedatsc
igned. time_ arrivedats ene>
cene (hh:mm:ss)
response _vehicles_ ass </date arrivedatsc
igned. time_ arrivedats ene>
cene (mm/dd/yy)
response_ vehicles_ ass </time time cont a
igned. time_ contact ct>
(hh:mm:ss)
response_ vehicles_ ass </date time conta
igned. time_ contact ct>
(mm/ddlyy)
response _transports. ti </time_ depart _see
me_depart_scene ne>
(hh:mm:ss)
response _transports. ti </date_ depart _sce
me_depart_scene ne>
(mm/dd/yy)
response_ vehicles_ ass </time _staged>
igned. time _staged
(hh:mm:ss)
response_ vehicles_ ass </date _staged>
igned. time _staged
(mm/dd/yy)
Item #6 September 27, 2016 Page 25 of 35
estination
Timestamp for when unit
arrived at transport
destination
response _transports. ti </time_ arrive_ dest
me arrive destination ination> - -
(hh:mm:ss)
1 date arrive d date time Date when unit for when unit <date_ arrive_ dest response _transports. ti </date_ arrive_ dest
estination arrived at destination ination> me arrive destination ination>
(mm/ddlyy)
1 time time del datetime
ayed _ availabil
ity
1 date time de! datetime
ayed _ availabil
ity
Timestamp for when unit
went to delayed available
status
Timestamp for the date the
unit went to delayed
available status
2 time call clea datetime Time unit cleared call
red
2 datetime Date unit cleared call
2 odometer enr oat Odometer value of vehicle
enroute to scene
2 odometer atsc oat Odometer value of vehicle at
ene scene
2 odometer bac oat Odometer value of vehicle in
kinqtrs quarters
2 number_ of_ vie int Number of patients seen
tims seen
2 primaryunit* * bit Flag indicating if unit is
primary unit assigned to
incident
2 officers start constant
2 emp_id* varchar Personnel ID of officer
30 assigned to the vehicle
2 officers end constant
3 pass-m
3 id int
<time _time_ delay
ed _ availability>
<date _time_ delay
ed _ availability>
<time call cleare
d>
<date call cleare
d>
<odometer enrout
e>
<odometer atscen
e>
<odometer backin
qtrs>
<number _of_victi
ms seen>
<primaryunitflag>
<officers>
<emp_id>
<ackid>
<master incident
id> -
response_ vehicles_ ass </time _time_ delay
igned. time_ delayed_ a ed _ availability>
vailability (hh:mm:ss)
response_ vehicles_ ass </date _time_ delay
igned.time _delayed_ a ed _availability>
vailability (mm/dd/yy)
response_ vehicles_ ass </time_ call_ cleare
igned. time_ call_ clear d>
ed (hh:mm:ss)
response_ vehicles_ ass </date_ call_ cleare
igned. time_ call_ clear d>
ed (mm/dd/yy)
response_ vehicles_ ass </odometer enrou
igned. odometer_ enrou te>
te
response_ vehicles_ ass </odometer atscen
igned.odometer _atsce e>
ne
response_ vehicles_ ass </odometer backi
igned. odometer_ backi nqtrs>
nqtrs
response_ vehicles_ ass </number _of_victi
igned.number _ of_ vie ti ms seen>
ms seen
response_ vehicles_ ass </primaryuni tflag>
igned.primaryvehiclef
lag
NetRMS </emp_id>
PersonnelNo value
from the Personnel
table*
</officers>
AckID </ackid>
response_ vehicles_ as </master incident
signed.master _incide id>
nt id
* The 11emp_id" field must contain a string that must exactly match the assigned PersonnelNo value in the NetRMS
22 Item #6 September 27, 2016 Page 26 of 35
Personnel table for the assigned officer. This is typically a combination of an agency prefix and a 4-digit ARJIS identifier,
such as "EC1234", "SH0443", etc. If no match is found, the officer specified in the record will not be assigned to the Case by
the Interface.
** If no "primaryunit" field is received with a "1" value, the first officer in an INC02 record will be assigned as the primary
officer in NetRMS.
CAD Incident to NetRMS CFS Record Data Mapping
'
C lla'a~e;
0 Wame
0
0
Call For
Service
The following table defines the data mapping between the CAD incident record XML data and its
corresponding NetRMS data field.
The "Seq Ref' and "CAD Field Value" column entries refer back to the corresponding numbered
fields in the INCOI and INC02 record definitions above.
All other fields in the NetRMS VI .94 San Diego Build CFS DM should default to empty values and
not be required entries.
0 --
_ ~iia ~ieW:iaE:!ep -: i][atalei !lame ~ --'-CeltllmE'ii ~ Se!!t , C~l1DHiftrer€1 ~allile -~ama: ' / s0 ;y'* ;,, -: Rel 0 --------/ --,'l ' / / ' / 0 0 -0/ -~ -
Event ID CFS CFS No 11 master_incident_number
Received CFS Received 59 time_firstcall
Dispatched 65 time_first_unit_assigned
Arrived CFS Arrived 67 time first unit arrived -- -
Cleared CFS Cleared 63 time call closed
Event Created CFS CFS Date 14 response_date
Dispatcher CFS DispatcherlD 75 calltaking_performed_by
Source CASO CFS CallSource 103 call source
Location CFS Location location_name
--
0 -
CASD_CFS StreetNumber 30/ house_number I house_number_suffix
31
StreetDirection 32 prefix_directional
StreetName 33 name_component
StreetD i rection Su 34 post_ directional
ffix
StreetType 35 street_ type
23
-,_
-
0
Item #6 September 27, 2016 Page 27 of 35
CASO CFS
City Code CASD_CFS
csz CFS
Grid
Beat
Jurisdiction Jurisdiction
Map
Coordinate X
Coordinate Y
Longitude CASD_CFS
Latitude CASD_CFS
Reporting Party CFS
Address CFS
csz CFS
csz CFS
csz CFS
Phone CFS
Call Type CASO CFS
Event Type
Reported Offense CFS
Verified Offense
Disposition CASD_CFS
24
apartment
CommonPlaceNa
me
CityCode
City
State
Zip
Grid
Sector
jurisdiction
Map
xCoord
yCoord
longitude
latitude
Contact
ContactAdd ress
ContactCity
ContactState
ContactZip
ContactPhone
CallType
EventType
ReportedOffense
CID
Offense
CFSDisposition
36 response_ master _incident_ apartment
29 location name
city
37 City
38 State
39 Postal_code
19
20 Beat
16 jurisdiction
42 longitude
43 latitude
49 caller name
50-Caller_location_name; caller_address,
52 caller_ apartment
53 caller_city
54 caller_state
55 caller_postal_code
57 caller_location_phone
46 methodofcallrcvd
25 incident_type
93 call_disposition
Item #6 September 27, 2016 Page 28 of 35
Subject
Information
Notes
Priority CASO CFS Priority 27 priority_number
Classification Classification CID
Vehicle Vehicle
Vehicle License Vehiclelicense
Tow Company TowCompany
Agency Agency agency_type 15 agency_type
Controlling Organization ID
Organization
Cases CASD_CFSCa Case ID 109 CaseNumber
ses
Deputies Officers
Officers Officer emp_id 28 emp_id
Name FullName
Address Address
csz csz
Notes Notes Commentslist 110 Comment
Note: Data from CAD will include all Units/Personnel referenced to the incident. In addition an
indicator will be required to denote the primary unit of the incident
Business Rule: Only Call/Incidents containing Case Numbers will result in a NetRMS Case folder
being created and/or officers assigned to the Case associated to the Incident. Calls received without a
Case Number will be recorded in the Call For Service (CFS) table, but will not generate any Case
folders or Case assignments.
Business Rule: The Report Number format/mask will be accepted by NetRMS as received in the
XML file. Changes in the mask, sequence, and/or format of the number are outside the scope of this
interface.
Business Rule: The interface will analyze each CaseNo provided in the XML export and determine if
a Case with the same case number exists within NetRMS. If the case number already exists, the
system will continue with the CFS creation and associate the CFS with the existing case. If the case
number does not already exist, the system will create a new Case Folder with the provided number
and then continue with the CFS creation processes and associate the new CFS with the newly created
Case Folder
25 Item #6 September 27, 2016 Page 29 of 35
Business Rule: For multiple Case Numbers included with an Incident/Call, each Case Number will
be evaluated separately and a Case Folder created or linked as determined by the evaluation. Case
identifiers associated with a given call are stored in CASD CFSCases.
Business Rule: For incidents with multiple units involved an INC02 record will be embedded in the
INCOl record for each involved unit.
Business Rule: All Officers associated with Units (INC02 Records) will be validated against the
Personnel Table ofNetRMS and entered into the Officer grid within the CFS DM ofNetRMS.
Business Rule: Call data received in the XML file for existing CFS records will be considered an
update to the CFS record. All previously received CFS information will be overwritten with the
updated call data.
Note: Previously created case Folders will be updated as necessary with the updated call data.
E
Performance
The following performance specifications apply as noted in two different conditions:
Normal Operation (no "backlog", Interface is running, processing CAD Incidents as they
arrive from CAD)
When in normal operational mode, incoming CFS messages from CAD should be
processed within 1-2 minutes of the completed delivery to the NetRMS Interface. As
long as there is no pre-existing "backlog" of records, no incoming CFS message should
take more than 5 minutes to be completely processed by the Interface.
"Processed" means that the NetRMS CFS record(s) have been created and/or updated,
any NetRMS Case Folders have been created for any Case numbers contained in the
CAD CFS records, and any associated Officers in the CFS records have been assigned to
the Case in NetRMS.
Interface Service Restart after outage
The NetRMS Interface may experience "outages". These may be caused intentionally
(planned system outages or upgrades), or be the result of system, application, or even
Interface error conditions.
When the NetRMS Interface is restarted after an outage of any duration, or initially
started, there may be CAD CFS messages awaiting processing by the Interface. To
ensure that no information is lost, these messages must be processed in the order in which
they were delivered by the CAD system. This is considered a CFS "backlog".
Processing the "backlog" can take several seconds per message, up to 30 seconds each,
depending on the content of the messages. Further, the size of the backlog is entirely
dependent on how many CAD CFS messages have been forwarded from the CAD system
and the arrival of additional messages while the Interface is processing the backlog.
Therefore, the time before the "backlog" is fully processed and normal operations resume
cannot reasonably be predicted.
26 Item #6 September 27, 2016 Page 30 of 35
While a "backlog" is being processed, incoming CAD CFS messages will stack up in the
backlog and cannot be processed until all records preceding the new messages have been
processed. Thus, Case Folder creations and Officer assignment record creations will be
delayed.
Note: All Performance information above is contingent on all incoming CAD CFS messages
being fully compliant with the Interface specification. If any CAD CFS messages are
received that are malformed or contain data inconsistent with the specification, processing
of those messages and any subsequent messages may be delayed and/or interrupted as a
result. Also, should CAD send excessive numbers of messages (i.e., more than one
message per CAD operator action), and these excessive messages continue for any
significant time period, this could artificially create a "backlog" and result in delayed
processing of the messages.
Monitoring
Security
Normal monitoring of the CAD to NetRMS interface is the responsibility of Agency. This
would include monitoring that the CAD system is forwarding information to the NetRMS
system and that the N etRMS CAD interface is operational.
There are no notifications associated with the interface. If the interface shuts down, or is
terminated, there are no notifications generated. It is the responsibility of Agency to
implement any automated detection of interface status and/or notifications.
In particular, any XML messages received from CAD that cannot be successfully processed
are automatically moved from the incoming shared folder to an error folder. There are no
automated notices should this occur. It is Customer's responsibility to monitor this folder,
either manually or with some automated detection system.
E
Testing of the CAD to NetRMS interface requires the entry of sample incidents into CAD and
the verification that the incident information is transferred correctly to NetRMS
This test plan may be revised prior to final signoff.
1. Verify assignable roles of Create; Delete; View; Edit and Search for Call for Service
Records.
Navigation
1. Verify Navigation links from Lobby under Operations/Uniform Patrol Division to the
Call for Service data view.
Call for Service Record Transfer from CAD
1. Enter an incident on CAD. Make sure that all applicable fields that are mapped to
27 Item #6 September 27, 2016 Page 31 of 35
NetRMS as identified in Section 4.3.5 (Data Mapping) are completed in the incident
record.
2. Add a Case Number to the Open Call
3. Navigate to the CFS (Call For Service) data view in NetRMS
4. Verify the main CFS data view opens properly. Select the "All Calls for Service" data
view
5. Verify that the CFS record previously entered on CAD is visible in the data view.
6. Open the CFS record previously entered on CAD. Tab through fields to verify that all
CFS parameters identified in Section 4.3.5 are in the CFS record and are identical to the
parameters entered on the original incident record in CAD. Close the NetRMS CFS
record.
7. From the CFS Data View verify the Case Number(s) are visible.
8. Select a Case Number and verify the link to the Case Folder.
9. Verify the Case Folder information is correctly populated based on the CFS data.
10. Close the incident record on the CAD system.
11. Navigate to the CFS data view in NetRMS.
12. Select the "All Calls for Service" data view
13. Verify that the CFS record previously entered on CAD is visible in the data view.
14. Open the CFS record previously entered on CAD. Tab through fields to verify that all
CFS parameters identified in Section 4.3.5 are in the CFS record have been updated
based on the updated (Closed) call received from CAD. Close the NetR._\1S CFS record.
15. Repeat Steps 7 - 9 for Case Number I Case Folder verification.
The following Notes are applicable to the interface.
1. If the CAD interface is capable of sending multiple Cases for a single CAD incident (i.e.,
multiple Case Numbers issued against a single Call-for-Service), as each Case Number is
issued, the CAD system must insert a text line in the incident Comments that identifies
the added Case Number. The text line must contain at least the two following text
fragments in the sequence shown, which must occur on the same line (i.e., not be
interrupted by a carriage return, line feed, or other end of line/end of field character):
• "Case Number"
• "<CaseNumber>" -e.g. "13001234"
28 Item #6 September 27, 2016 Page 32 of 35
The fragments must each be preceded and followed by at least one space character,
and/or must begin or end the text line. Fragments are not case sensitive. Examples of
acceptable format strings are:
• "Case Number 13001234 issued on incident 130012223"
• "Issued CASE NUMBER to Unit 1A12 -13001234"
• "CAD Incident 13-0020035, Dispatcher 1B32 Attached Case Number -13012345 to
unit 1A12"
2. Beat number strings must exactly match the Beat numbers as entered in NetRMS. If
Beats are entered in NetRMS with leading zeroes, the Beat numbers passed from CAD
must contain the same leading zeroes. Beat "012" is not the same as Beat "12", and Beat
"A 15" is different from Beat "AO 15".
3. Agency Personnel identified in messages ( officers and dispatchers) must be defined in the
NetRMS Personnel database table, and the Personnel identifier value sent in the XML
from CAD must exactly match the PersonnelNo in the NetRMS Personnel table. These
fields are the "Emp _ ID" and "DispatcherID" fields in the XML. Any prefixes/suffixes
used in the NetRMS Personnel table must be included in the field as sent from CAD (i.e.,
if the Personnel table has "LM1234" in the PersonnelNo field, the CAD system must
send "LM1234" in the DispatcherID and/or Emp _ ID fields in order for the records to be
properly linked to users.
4. Map information and Jurisdiction fields are not supported from non-Motorola CAD
systems. These fields expect special contents only provided in a Motorola CAD/Records
suite.
H ENTS
Sample export XML file (Copy file and paste onto local hard drive to open.)
NetRMS 10091213442
6.46.xml
29 Item #6 September 27, 2016 Page 33 of 35
ACTION BY UNANIMOUS WRITTEN CONSENT
OF THE BOARD OF DIRECTORS OF
TRITE CH SOFTWARE SYSTEMS
The Undersigned, constituting all of the members of the Board of Directors ofTriTech
Software Systems, a California corporation (the "Corporation"), pursuant to Section 307(b) of
the California Corporations Code, hereby adopt by unanimous written consent, the resolution
attached hereto as Annex 1.
This Action by Unanimous Written Consent may be signed via facsimile and/or in one or
more counterparts, each of which shall be deemed an original, and all of which shall constitute
one instrument. This Action by Unanimous Written Consent shall be filed with the minutes of
the proceedings of the Board of Directors of the Company.
IN WITNESS WHEREOF, the undersigned have executed this Action by Unanimous
Written Consent effective as of February 24, 2016.
Chris Mal~J ey
Chairman
Tony Eales
Director
Blake Clark
Director
Page I of2
Item #6 September 27, 2016 Page 34 of 35
ANNEXl
RESOLUTION OF
THE BOARD OF DIRECTORS OF
TRITECH SOFTWARE SYSTEMS
SIGNATURE AUTHORITY
WHEREAS, TriTech Software Systems, a California Corporation (the "Corporation") prepares
and submits written proposal documents for the sale and license of its products and services in
accordance with formal procurement procedures required by prospective clients and exiting
clients; and
WHEREAS, the Board of Directors (the "Board") of the Corporation desires to clarify and
document the signature authority of certain executive officers for the limited purpose of signing
said proposal documents and resulting sales contracts.
NOW, THEREFORE, BE IT RESOLVED THAT, the Board authorizes and grants
signature authority to Tony Eal es, President and Chief Executive Officer, or in his absence,
Blake Clark, Chief Financial Officer, limited to the submission of proposal documents prepared
in response to Requests for Proposal (RFP), Requests for Tender (RFT), Requests for Quotation
(RFQ), or Requests for Information (RFI); and the resulting client contract related thereto
entered into by the Corporation; and
RESOLVED FURTHER, that the officers of the Corporation be, and each of them
hereby is, authorized and directed, for and on behalf of the Corporation to take such further
action and execute such additional documents as each may deem necessary or appropriate to
carry out the foregoing resolution.
Page 2 of2
Blake Clark
Secretary
Date I /
Item #6 September 27, 2016 Page 35 of 35