Loading...
HomeMy WebLinkAbout2016-09-27; City Council; ; Approve Amendment No. 1 to the Master Support Agreement between the City of Carlsbad and TiburonCITY COUNCIL Staff Report Meeting Date To: From: Staff Contact: September 27, 2016 Mayor and City Council Kevin Crawford, City Manag~f Maria Callander, Information Technology manager maria.callander@carlsbadca.gov or 760-685-0320 CARevie~ Subject Approve Amendment No. 1 to the Master Support Agreement between the City of Carlsbad and Tiburon Recommended Action Adopt a resolution approving Amendment No. 1 to the Master Support Agreement between the City of Carlsbad and Tiburon. Executive Summary 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. The CAD/Mobile system has been in operation since May of 2005. 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. 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. On December 9, 2014, the city entered into an agreement with Tiburon for annual support services. The proposed amendment to the support services agreement adds services for Tiburon to move the CAD system to a virtual server and implement the CAD/Mobile to NetRMS interface. Discussion On September 12, 2003, the city entered into an agreement with Tiburon, Inc. (Tiburon) to provide a fully integrated public safety information system that included a computer aided dispatch (CAD) system and a police mobile data system (Mobile). The CAD/Mobile system was successfully implemented and has been in operation since May of 2005. 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. Implementation of the Net RMS system is currently in progress and is expected to be fully operational by the end of 2017. Officers will create and edit their reports on-line directly within NetRMS. The proposed interface will automatically Item #6 September 27, 2016 Page 1 of 35 transfer incident data from the CAD/Mobile System into the NetRMS system so that the officers do not have to re-enter the data. The proposed amendment to the support services agreement adds services for Tiburon to implement the CAD/Mobile to NetRMS interface. In addition, the CAD system will be moved from a physical server to a virtual server in order to increase operational efficiency and provide redundancy. Fiscal Analysis On December 9, 2014, the City executed an agreement totaling $106,471 with Tiburon for annual support services. The annual support services agreement was renewed in 2015 for $105,417, and renewed in 2016 for $110,688. Amendment No. 1 for support services relating to the CAD to NetRMS interface is for $61,225. In addition, the annual maintenance fee for the CAD to Net RMS 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. Funds for this increase are currently budgeted in the innovation account in the General Fund. Next Steps After the amendment is approved by the City council, police department staff will begin to work with Tiburon and NetRMS to implement the proposed interface. Environmental Evaluation (CEQA) Pursuant to Puplic Resources Code section 21065, this action does not constitute a "project" within the meaning of CEQA in that it has no potential to cause either a direct physical change in the environment, or a reasonably foreseeable indirect physical change in the environment, and therefore does not require environmental review. Public Notification N/A Exhibits 1. A resolution approving Amendment No. 1 to the Master Support Agreement between the City of Carlsbad and Tiburon. Item #6 September 27, 2016 Page 2 of 35 RESOLUTION 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. Item #6 September 27, 2016 Page 3 of 35 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) Item #6 September 27, 2016 Page 4 of 35 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