CAD & RMS Integration

What this covers

Computer-aided dispatch and records management systems are the core of police and fire operations, but they rarely stand alone. Incidents need to flow to records, records to courts and prosecutors, and both to analytics and public reporting. HQT builds and maintains these integrations.

Typical activities

• Interface inventory and documentation of existing data flows
• Integration development using vendor APIs, data exports, or middleware
• Data mapping between systems with different incident and person models
• Address and location validation against the agency's GIS
• Monitoring, alerting, and reconciliation for each interface
• Coordination with platform vendors during upgrades

What you receive

Documented and monitored integrations, data mapping specifications, and runbooks for interface failures.

Considerations for public safety agencies

Criminal justice information handled in transit and at rest must meet CJIS Security Policy requirements, including encryption and personnel screening for anyone with access. HQT staff assigned to this work complete the required screening and training.

Signs an interface needs attention

Interface work is easy to defer because nothing looks broken. Signs that it should not wait:

• Records staff retype incident information that already exists in CAD.
• The state repository returns incident or NIBRS submissions with errors that someone clears by hand each cycle.
• An interface has no named owner, and you learn it stopped when a downstream user calls.
• A CAD or RMS replacement is in procurement, so every existing interface becomes a scope item and the ones nobody inventoried become change orders.
• A platform upgrade is scheduled and no one can say which interfaces it touches.
• Addresses that validate in CAD no longer match the address points GIS maintains, so incidents land in the wrong beat or response zone.
• An analytics or transparency extract was assembled once and has not been reviewed since.

What a sound exchange looks like, and how a weak one shows itself

A sound exchange has a written contract: direction, trigger, transport, field level mapping, expected volume, and the behavior when the receiving system rejects a message. Messages carry a stable key, usually the incident number plus an agency identifier, so a retry updates the existing record instead of creating a duplicate. Failures land in a queue that can be inspected and replayed rather than disappearing into a log file, with one named person watching it.

Weak implementations share recognizable traits. They push in one direction and never confirm that anything arrived. Their mapping rules live inside a proprietary script the agency cannot read or change. They drop records with unusual values, such as an offense code added after the interface was written, without reporting the loss. They rebuild the destination table nightly, so an earlier state cannot be reconstructed for an audit or a records request. And they are accepted on a scripted demonstration rather than a parallel run, so the first real comparison of counts happens long after go live.

Where this touches the systems and vendors you already have

CAD and RMS sit in the middle of a long chain. On the dispatch side: call handling equipment and, in a Next Generation 911 environment, the ESInet and the location data that arrives with a call; GIS road centerlines and address points; mobile data computers and vehicle location; station alerting; and CAD to CAD links with neighboring PSAPs, where the Emergency Incident Data Document published jointly by APCO and NENA offers a common incident format. On the records side: the state message switch that reaches NCIC and Nlets; jail and booking; electronic citations; court and prosecutor case management; the state repository that forwards incident data to the FBI in NIBRS format; NFIRS and NEMSIS reporting for fire and EMS; digital evidence management; and the analytics or open data layer.

Most of these depend on a vendor's cooperation, so plan the commercial side alongside the technical one: interface licensing or module fees, access to a nonproduction environment, and documented APIs rather than an ad hoc export. Where a second consumer of the same data is likely, ask whether the exchange can follow NIEM based structures, which exist to make such exchanges reusable.

What to require in a solicitation

• A specification for each interface as a deliverable, including mapping tables, not only working code.
• Agency ownership of mapping documentation, configuration, and custom code, with the right to hand it to a different vendor.
• Acceptance based on a parallel run and a reconciliation of record counts over a defined period, rather than a scripted demonstration.
• Named error handling: where failed messages go, who is notified, and how a message is replayed.
• A CJIS Security Addendum, executed through your state's CJIS Systems Agency, for any contractor whose staff will handle criminal justice information.
• An obligation to regression test each interface against vendor releases and to give notice of breaking changes to field definitions, API versions, or authentication.
• Nonproduction access on both the CAD and the RMS side, with test data that is synthetic or masked rather than a copy of live records.
• Interface maintenance priced separately from the build.

Working with HQT on this

HQT scopes this kind of work as a fixed-price or time-and-materials engagement with a written statement of work, named staff, and a defined acceptance process. We are candid about what we can take on and prefer a well-run project to an oversized one. Contact us to discuss a requirement, a draft scope, or an upcoming solicitation.

Frequently asked questions