Open the website of almost any diagnostic connectivity vendor and you’ll see a similar story. The product takes results from devices and routes them to the systems that need them — LIS, EMR, registry, dashboard, however the customer maps it. The implicit value proposition: diagnostic data flows where it needs to go.
That framing isn’t wrong. It’s just not the problem most programs spend most of their time on.
Programs running real distributed diagnostic fleets — across hundreds of sites, multiple countries, varied conditions — don’t ask “did the result get there.” They ask:
- Which devices are alive right now?
- Which are running outdated firmware?
- Which sites will run out of test cartridges next week?
- Which operators are skipping calibration?
- Where are the silent devices, and how silent is silent — quiet for an hour, a day, three weeks?
- What’s the trend line on quality metrics across the network?
These aren’t routing questions. They’re fleet questions. And answering them is fundamentally different work from moving a result across a network.
The reframe
Diagnostic connectivity, as a category, is currently described in routing terms because routing is the part that’s easy to ship and easy to demo. A diagram. A network. Arrows from a device to a destination. The customer can picture it. Procurement can score it.
Fleet operations is harder to ship because it requires opinions about how the fleet should be managed — what’s a reasonable consumables runway, what’s a healthy device-up percentage, what’s the right protocol-compliance threshold. Vendors who treat the work as routing dodge those opinions. Vendors who treat the work as fleet operations have to take positions, build dashboards that show the right things, and stand behind those positions when programs push back.
The result is that programs end up doing fleet operations themselves — usually in spreadsheets, usually via reports pulled out of multiple systems, usually by a small team that becomes the institutional memory for what the network is actually doing. The connectivity vendor moves results. The program builds operations on top, by hand.
What changes when you treat it as a fleet problem
When the work is framed as fleet operations, several things follow.
Results are one stream of data, not the only one.
You also need device telemetry — heartbeat, error logs, firmware version, calibration state, environmental signals where available. You need consumables data — what’s been used, what’s on hand, what’s been ordered, what’s in transit. You need operator data — who ran which test, when, with what outcome, with what protocol adherence. None of this is routed in the traditional sense. It’s collected, normalized, and surfaced as views.
The dashboard is the product, not an accessory.
If the product’s job is fleet management, then the interface where the fleet manager actually does that work is the central artifact. It needs opinions about hierarchy (which view do you start at — country, region, site, device?), about alerts (what gets escalated, what stays quiet), about scope (do operators see only their site, or peer comparisons too?). Vendors who treat the dashboard as a deliverable downstream of “real” engineering ship products that look generic and feel hollow.
Field operations enters the platform.
On-site visits, troubleshooting, replacements, training cycles, audit visits — none of these traditionally lived in the connectivity stack. But all of them generate data the fleet manager needs, and most of them benefit from being scheduled, tracked, and assessed in the same system that holds the device telemetry. Pulling these into the platform turns a connectivity product into a true operational system.
Quality programs become first-class.
External quality assessments, in-run QC, calibration cadences, control charts — quality isn’t routed; it’s run. A fleet-oriented platform makes quality a built-in workflow, not a downstream report. That’s a meaningful change in stance.
What this means for the people doing this work
For programs: stop evaluating connectivity products by how cleanly they move results. Evaluate them by how clearly they answer the fleet questions above — and how much of that answer requires you to do additional work in spreadsheets, in shadow systems, in your head.
For vendors: realize that the customers ahead of you aren’t asking for better integrations. They’re asking for someone to take a view on fleet operations, ship that view, and stand behind it. Routing is the table-stakes layer. Fleet management is the product.
For us: this is how we’ve thought about the work since the first program we ran, and it’s the design center of ConneX Core. Operations and analytics aren’t an additional feature on top of routing. They’re the point.
Building or buying for a diagnostic fleet? Talk to us