Mobile Data Terminals (MDTs) and CAD-to-CAD Integration: Practical Basics

What an MDT actually is

A mobile data terminal is a screen and a data connection in the vehicle. That is the honest short version. Historically it was a ruggedized laptop or a fixed dash unit; today it is just as often a tablet in a mount, running an application supplied by your dispatch software vendor over a cellular or radio data link. The hardware is not the interesting part. What makes it an MDT rather than a browser on a tablet is that it talks to your computer-aided dispatch (CAD) system, so the unit in the field and the dispatcher at the console are looking at the same incident record.

Strip away the marketing and an MDT is doing three basic jobs. It receives information from dispatch. It sends status back to dispatch. And it gives the crew a way to reach reference material without keying a radio. Everything else layered on top is a variation of one of those three.

What it does on a call

Here is the workflow most crews recognize once the novelty wears off. A call comes in. Instead of, or alongside, the voice dispatch, the incident lands on the screen: address, call type, any notes the dispatcher typed, and often a map with the unit's position and a route. The crew acknowledges. As the call progresses, the officer or driver taps status buttons instead of transmitting each change: responding, on scene, transporting, available. Each tap timestamps the record on the dispatch side without occupying the channel.

The common capabilities break down like this:

• Receiving the dispatch. Address, call type, cross streets, caller notes, and any hazard flags the dispatcher attached, delivered as text you can re-read rather than a voice transmission you heard once.
• Status buttons. The big one for radio traffic. Enroute, on scene, clear, and so on, logged with a timestamp. This is where a lot of the real time savings live, because status changes are constant and repetitive.
• Mapping and routing. Seeing your own position, the incident location, and a suggested route. Useful in an area you do not know well, and useful for the second-due unit that needs to stage or approach from a different direction.
• Mobile access to records. Pre-plans, hydrant locations, occupancy notes, standard operating guidelines, and previous incident history for an address, all reachable from the cab or on scene without a phone call back to the station.

That last item is where an MDT stops being a dispatch convenience and starts being an operational tool. A pre-plan that shows the sprinkler connection, the knox location, and where the hazardous storage sits is worth more on the way in than it is filed in a binder at the station. But that only works if the pre-plan exists, is current, and is actually loaded into the system the screen can reach. Hold that thought, because it is the theme of the whole article.

CAD-to-CAD and why mutual aid cares

Everything above assumes one agency, one dispatch center, one CAD system. Real incidents do not respect those boundaries. You run mutual aid into the next jurisdiction, or they run into yours, and now two dispatch centers each have their own CAD, their own unit list, and their own picture of the same incident. CAD-to-CAD integration is the attempt to connect those two systems so the incident data crosses the line.

When it works, the value is straightforward. A neighboring center can send an incident directly into your CAD instead of relaying it by phone, which is faster and loses less in translation. Your units responding on their call can show up on their board with real status. Both centers can see which apparatus is committed where, which matters a lot during a large event when everyone is drawing from the same pool of trucks. For a small department that leans on automatic and mutual aid to fill out an assignment, this is not a luxury feature. The whole point of an aid agreement is that the closest appropriate unit responds regardless of whose patch it wears, and CAD-to-CAD is the plumbing that lets the two dispatch systems coordinate that without a human reading addresses over a phone line.

Why interoperability is harder than it sounds

Now the honest part. CAD-to-CAD interoperability between neighboring agencies is real, it exists in the field, and it is uneven and frequently difficult to stand up. Do not walk away from a vendor demo believing it is a checkbox.

The trouble starts with the fact that two agencies rarely run the same dispatch software, and even when they do, they configure it differently. Call types do not match. Your structure fire code is their working fire code. Unit naming conventions differ. Status definitions differ, so your on scene and their arrived may not map cleanly. Address formats and the underlying map data differ, which means a location that geocodes cleanly in one system can land in the wrong spot or fail to validate in the other. Every one of those mismatches has to be translated, and somebody has to build and maintain that translation.

There are shared data standards and messaging conventions that make this more achievable than it was a decade ago, and the broader move toward next-generation 911 (NG911) infrastructure is pushing centers toward more interconnected, data-oriented systems that can pass richer information, including better caller location data, between agencies. That direction is real and helpful. But standards describe how systems can talk; they do not guarantee that two particular centers, with two particular vendors, on two particular budget cycles, have done the integration work and keep it maintained. Governance, cost-sharing, and who owns the connection when it breaks are as much of the project as the technology. A regional approach, where multiple neighbors agree on conventions together, tends to work far better than two agencies bolting a link between themselves in isolation.

• Mismatched call types and codes that have to be mapped agency to agency.
• Different unit naming and status definitions that break the shared picture if translated carelessly.
• Inconsistent address and map data that can misplace or reject a location across the boundary.
• Ongoing maintenance, because a config change on either side can quietly break the link.
• Governance and cost, which are usually the real reason a promising integration never ships.

None of this means CAD-to-CAD is not worth pursuing. It means you should treat it as a regional operational project with partners, not a feature you buy, and you should ask hard questions about who maintains it before you depend on it during a bad night.

The distraction problem nobody demos

A screen in the cab helps the crew and competes for the crew's attention at the same time. Both are true. The same MDT that lets a driver see the route also invites the driver to read caller notes, tap status, and study a map while the apparatus is rolling. Emergency response driving is already among the more dangerous things your people do, and a bright interactive display in the line of sight is a known distraction risk. Pretending otherwise does not make it safer.

The good news is that this is a manageable problem if you treat it as a policy and training issue rather than a hardware issue. The rig has a driver and an officer for a reason. The discipline that keeps a phone out of the driver's hands applies to the MDT: the person driving does not operate the screen, full stop. Interaction happens before wheels move, at a stop, or through the officer in the right seat. Some systems can lock down or simplify the display while the vehicle is in motion, and if yours can, use it. Mounting position matters too; a screen buried low or off to the side is worse than one placed where a glance does not mean looking away from the road for long.

The goal is to move routine work off the radio and onto data without moving routine work onto the driver's eyes. Get that balance wrong and you have traded a channel-congestion problem for a crash risk, which is a bad trade.

Curating what reaches the truck

More data is not the goal. The right data at the right moment is the goal. This is the mistake that turns a useful MDT into a cluttered one: the temptation to push everything to the screen because the screen can hold it.

Think about the actual moment of use. On the way to a call, the crew can absorb a handful of things: where it is, what it is, what is dangerous about it, and how to get in. That is roughly it. A dispatch note that reads clean and short is worth more than a wall of auto-populated history that nobody can scan while responding. A pre-plan that opens to the one page a first-due officer needs beats a forty-page document that has to be swiped through. Curation is the work of deciding, ahead of time, what earns a place in front of a crew that has seconds, not minutes.

• Keep dispatch notes short and structured. Hazards and access first. This is a dispatcher workflow and training question as much as a technology one.
• Make pre-plans skimmable. The first screen should carry the life-safety and access essentials; detail can live deeper for the crew that has time on scene.
• Prune the reference library. If a document is out of date, it is worse than absent, because people trust what the screen shows them.
• Match content to role and moment. What the driver needs, what the officer needs, and what is useful only after arrival are three different lists.

Curation is unglamorous and it is where most of the real value is won or lost. The hardware is the same whether the content behind it is disciplined or a junk drawer. Your crews will only trust the screen if what it shows them has been kept honest.

Is it worth it for a small department?

Straight answer: it depends, and the honest version of the answer is less exciting than the sales version. MDTs deliver the most where two conditions hold. First, you have enough call volume and radio traffic that moving status changes off the air genuinely relieves congestion and speeds things up. Second, you run enough into unfamiliar territory, or hold enough pre-plans worth carrying, that in-cab mapping and reference materially help the crew. A busy combination department covering a mix of districts gets more from an MDT than a low-volume department where every member already knows every road and every building by heart.

Against that, weigh the real costs, which are not just the tablets. There is the recurring data connectivity. There is the integration and configuration work with your dispatch center, which you may not fully control if you are dispatched by a shared or county center. There is mounting, power, and the reality that ruggedized gear in a vibrating vehicle has a service life. And there is the training and policy work to use it safely, which is not optional.

A reasonable path for a smaller department is to start narrow. Pilot on the busiest apparatus. Prove the status-button and mapping value first, because those are the capabilities that pay off fastest and depend least on you having a mature records library. Add mobile pre-plan and records access once you have the records worth pushing. Treat CAD-to-CAD as a separate, later, regional conversation with your dispatch center and your aid partners, not a day-one requirement. And be willing to conclude that for your call volume and staffing, a well-run radio and a good set of station binders still pencils out better than a screen program you cannot maintain. That is a legitimate answer, not a failure.

The part that matters more than the hardware

If there is one thing to carry away, it is this: the terminal is a window, and a window is only as good as what is on the other side of it. An MDT that shows a stale pre-plan, a miscoded call type, or a mapping error is not neutral. It actively misleads, because crews reasonably trust what the official screen tells them. Data quality and dispatcher workflow determine whether the whole investment helps or hurts, and both of those live upstream of any device you install.

That is why the mundane discipline matters more than the demo. Are your pre-plans current? Is your address and hydrant data clean? Do your dispatchers write notes that a responding crew can actually use in three seconds? Are your call types and unit statuses defined consistently enough to survive being shared with a neighbor? Get those right and even a modest MDT setup earns its keep. Get them wrong and the most capable terminal on the market just delivers bad information faster.