Remote device monitoring for MedTech, engineered around the obligation that visibility creates rather than only the dashboard it produces.
Before a fleet was connected, a device degrading in a hospital was invisible and nobody could have known. Afterwards the signal exists, it was in your platform, and the question of whether anybody noticed and what they did about it has an answer. That is the actual change remote monitoring makes. The dashboard is the easy part, and the hard part is deciding what you will watch for, who will respond, within what time, and what happens when nobody does.
A green dashboard does not mean every device is healthy. Which makes alerting the product, and the dashboard the thing people look at afterwards.
A monitoring platform that generates several hundred alerts a day across a fleet trains the people receiving them to dismiss without reading. That is a rational response to an unmanageable volume and it is also the mechanism by which the one alert that mattered gets closed along with the rest. In a consumer product that is an operations problem. In a device company it means a degradation nobody acted on, visible in the platform, with a record showing the alert was raised and acknowledged.
The second problem is that monitoring is frequently specified by what the device can report rather than by what somebody would do about it.
Alerts are specified from what the device can emit
Rather than from what a person would act on, which produces volume without usefulness.
Nobody owns the response
An alert routed to a distribution list is an alert routed to nobody in particular.
Dismissal becomes the default
Once volume exceeds what a team can assess, triage replaces response and the dangerous alert goes with the rest.
Absence produces no alert
A device that stopped reporting generates nothing, which is the failure mode most likely to matter.
Health statistics exclude the devices that stopped reporting
A platform can show excellent fleet availability because disconnected units were removed from the calculation.
Visibility creates an expectation of response
Once the signal exists, the organization is answerable for what it did with it.
Count the alerts nobody acted on last month.
Pull the alert history, establish how many were acknowledged without an action following, and look at what they were about. In most device monitoring deployments the proportion is high enough to be uncomfortable, and the pattern is informative: specific alert types nobody has ever acted on should be removed or retuned rather than left generating noise. That exercise takes an afternoon, immediately reduces volume, and makes the remaining alerts meaningfully more likely to be read.
The useful design question is not what the device can tell you. It is what somebody would do differently if they knew. Working backwards from the action to the signal produces a small number of alerts people respond to, while working forwards from available telemetry produces a large number they learn to ignore.
Step 1
Define the response first, since an alert with no corresponding action is a notification rather than a control.
Step 2
Name the owner per alert type, because a distribution list is not an owner and nothing routed there is anybody job.
Step 3
Set the response expectation explicitly, covering hours, time to acknowledge and what happens if nobody does.
Step 4
Define the device state model before any rule, since connected, disconnected, active, idle, faulted, unavailable, unknown, stale, monitoring disabled and retired are not one flag.
Step 5
Alert on absence with an expected reporting rate, since a stopped device produces no error of its own.
Step 6
Separate clinical urgency from operational urgency, so the two never compete in the same queue.
Step 7
Design escalation, so an unacknowledged alert goes somewhere rather than aging quietly.
Step 8
Tune against a volume budget, because an alerting system without a ceiling becomes unreadable within months.
Step 9
Give every alert enough context to act, since an alert requiring investigation before action is a research task.
Step 10
State monitoring coverage, because conclusions drawn from the connected subset are not fleet conclusions.
An alert nobody owns is telemetry, and an alert nobody can act on is noise.
Two tests settle whether an alert should exist. Is there a named person or role whose job includes responding to it, and when it fires, do they have enough information to do something without investigating first? Alerts failing the first test accumulate in shared mailboxes. Alerts failing the second get acknowledged and deferred. Applying both tests before an alert is created, rather than after the volume becomes a problem, is the difference between a monitoring system that works and one that gets muted.
Connectivity, ingestion and fleet management are covered on our connected platform pages. These are the capabilities specific to detecting a condition and getting somebody to act on it.
Watch and Detect
Device Health Monitoring
Operating state, error conditions, consumable status and performance indicators, scoped to what somebody would act on.
Absence Detection
Expected reporting rate per device so a stopped stream raises something, which is the failure mode that otherwise produces silence.
Degradation and Trend Detection
Conditions developing over days rather than crossing a threshold instantly, which is where intervention is still possible.
Remote Diagnostics
Logs, fault history and device state available to service without a site visit, with access governed and recorded.
Route and Close
Alert Design and Tuning
Severity reflecting consequence, volume held to a budget, and every alert tested against ownership and actionability.
Routing and Escalation
To a named owner with a stated response expectation, and onward when nobody acknowledges rather than ageing in a queue.
Clinical and Operational Separation
Two queues with different urgency, so a consumable warning never sits alongside something affecting patient care.
Response Capture
What was done and by whom, which is both the improvement signal and the record that the obligation was discharged.
Integrate and Sustain
Service Workflow Integration
Alerts becoming service requests with device context attached, rather than an email somebody re-enters by hand.
Coverage Reporting
Which devices are actually monitored, since conclusions from the connected subset are not fleet conclusions.
Alert Performance Review
Acted-on rate per alert type, with the ones nobody uses removed, which is the only thing keeping volume manageable.
Monitoring Reliability
Whether the monitoring itself is working, because a silent monitoring system and a healthy fleet look identical.
What CaliberFocus does, and does not do?
Real-time monitoring requires an explicit definition of real time. A measurement recorded five minutes ago, transmitted after an outage and displayed now is not a current reading, and the platform should preserve event time, transmission time and ingestion time rather than collapsing them.
Monitoring signals differ in urgency, in who should respond and in what happens if nobody does. The third column is the response path, and designing one queue for all six is how a consumable warning ends up competing with something clinical.
| Signal | What It Indicates | The Response Path It Needs |
|---|---|---|
| Device Stopped Reporting | Unknown state, which may be anything | Investigation, since silence has several causes and each differs. |
| Active Fault Condition | The device has detected a problem itself | Service, with device context attached and a stated response time. |
| Degradation Trend | Something developing toward failure | Planned intervention, which is where monitoring pays for itself. |
| Consumable or Wear Status | Routine replenishment approaching | Logistics. Low urgency and high volume, so it belongs elsewhere. |
| Clinical Delivery Failure | Data is not reaching a care team | The highest urgency, covered on our reliability page. |
Degradation Trends Are the Only Signal That Pays for the Platform
A fault alert tells you a device has already failed and somebody is already affected, which is useful and is not prevention. A device stopping tells you something happened. The signal that justifies the investment is a condition developing over days where an intervention is still possible: a consumable degrading faster than expected, an error rate climbing, a measurement drifting within tolerance.
Monitoring systems fail silently more often than loudly, because the absence of alerts is indistinguishable from a healthy fleet. The third column is how each failure presents, which is usually as nothing at all.
| Failure | What Happened | How It Presents |
|---|---|---|
| Ingestion Stopped | Telemetry is no longer arriving from part of the fleet | Fewer alerts, which looks like a quiet period. |
| Alert Delivery Failed | The alert was generated and nobody received it | Nothing, since the system believes it alerted. |
| Rule Disabled During Tuning | Somebody muted a noisy alert and never restored it | Silence on exactly the condition that was noisy. |
| Device Stopped Reporting | Connectivity, decommissioning or failure | An absence, unless an expectation exists to compare against. |
| Threshold Drifted Out of Relevance | Firmware or usage changed and the limit no longer fits | Either silence or noise, depending on direction. |
| Coverage Gap on a New Generation | New devices shipped before monitoring was extended | Normal operation, with a growing unmonitored cohort. |
Monitoring a Fleet Is Not Monitoring a Data Centre
Infrastructure monitoring assumes the thing being watched is reachable, consistent and under your control. A device fleet is none of those: units go offline legitimately, report at different cadences, run different firmware with different telemetry, sit behind networks you cannot reach and are switched off for entirely normal reasons.Â
Monitor the monitoring
Alert volume and ingestion rate against expectation, since both falling silently is the common failure.
Verify alert delivery, not just generation
Covered on our reliability page, and the gap between the two is where alerts disappear.
Give every mute an expiry
A temporarily disabled rule without an end date is a permanently disabled rule.
Carry device generation and firmware into the rule
Since a threshold valid for one configuration may be meaningless for another.
Extend monitoring with the product, not after it
A new generation shipping without monitoring creates a cohort nobody is watching
Attach enough context for action
Device, location, configuration, recent history and the suggested next step, or the alert becomes a research task.
A quiet month is either good news or a broken monitoring system.
When alert volume falls, the natural reading is that the fleet is performing well. The alternative reading is that ingestion stopped for part of the fleet, a rule was muted during tuning, or alert delivery has been failing since a configuration change nobody connected to it.
Monitoring changes the organization position in a way that is rarely discussed at design time. A condition that was previously undetectable is now recorded in your platform, with a timestamp, and whether anybody acted is a matter of record. That is appropriate and it is also a commitment, and the scope of what is monitored should be chosen deliberately rather than expanded by whatever telemetry happened to be available.
Scope and obligation
- What is monitored defined deliberately, since each addition creates an expectation of noticing
- Response expectations stated per alert type, including hours of coverage and escalation
- Alert and response history retained, since the record of what was raised and what followed will be asked for
- Reassessment when a monitoring capability drifts toward clinical significance through use
Security
- Remote diagnostic access governed and recorded, since it is privileged access to a device in clinical use
- Monitoring must never acquire control capability by proximity, covered on our remote device management page
- Device identity and credential lifecycle, covered on our identity and device security pages
- The hospital network treated as untrusted, since you neither control nor can rely on it
Privacy
- Patient-associated data in telemetry and logs handled to the obligations your counsel defines
- Diagnostic log content reviewed, since logs are a common unplanned store of clinical information
- Data residency addressed per market, since a global fleet reports into several jurisdictions
- Access to device data scoped by purpose, since service and commercial use are different grants
Regulatory
- Engineering controls capable of supporting the frameworks that apply, which may include FDA regulation, IEC 62304, IEC 81001-5-1 and ISO 13485
- Applicability, classification and validation strategy determined by your quality and regulatory functions rather than by us
- Where a monitoring output informs a clinical decision, the boundary assessed rather than assumed
- Complaint-relevant information surfaced by monitoring routed into the quality process rather than closed in service
Monitoring will surface things that belong in the quality process.
A fault pattern across a cohort, a failure mode nobody anticipated, a degradation that affected a patient: monitoring finds these before anybody files a complaint, which is the point. The risk is that they get resolved within service as an operational matter and never reach quality, because the person who saw it was fixing a device rather than assessing reportability.
Monitoring programmes report alerts generated, devices monitored and uptime. None of those indicate whether the system is working, because a system generating thousands of ignored alerts scores well on all three. The measure that matters is the proportion of alerts that resulted in an action, tracked per alert type, because it tells you which rules are earning their place and which are training people to dismiss.
Acted-on rate per alert type
The core measure, and the basis for removing or retuning everything that nobody uses.
Time to acknowledge and to act
Against the stated expectation, since an expectation nobody measures is an aspiration.
Alerts that should have fired and did not
Established retrospectively from incidents, which is the only way to find detection gaps.
Alert volume against budget
Because volume creep is gradual and the system becomes unreadable before anybody notices.
Monitoring coverage by generation and customer
Since a cohort nobody is watching is invisible in every other measure.
Monitoring system health
Ingestion rate, rule status and delivery confirmation, because silence is ambiguous.
The Service Engineer Already Knows Which Alerts Are Worthless
The fastest route to a usable alert set is not an analytics exercise, it is a conversation with the people receiving the alerts. Field service engineers and support staff can name, immediately and without hesitation, which alert types they have learned to ignore, which ones arrive too late to act on, which lack the context to be useful and which they wish existed.
Silent device disconnection the platform never recognized. A stale dashboard loading successfully with outdated information. Missing events after reconnection, where buffered telemetry transmitted only partially. Duplicate events from retry or replay. Clock drift distorting investigation timelines. Alert flooding from a transient condition. Missed critical conditions from poorly configured rules. And a reconnection surge creating ingestion delay and monitoring disruption.
Review alert performance quarterly
Remove the rules nobody acts on, since they are actively damaging the ones that matter.
Investigate incidents for missing alerts
Every event that surprised you is a detection gap with a specific cause.
Treat volume as a ceiling, not an output
A fixed budget forces prioritization and keeps the system readable.
Report coverage alongside findings
So conclusions from the monitored subset are never read as fleet conclusions.
Monitoring is usually reported as devices connected and alerts generated. The outcomes that matter are whether alerts lead to action, whether problems were caught before they became failures, and whether anybody would notice if the monitoring stopped.
| Category | What We Measure | Why It Matters |
|---|---|---|
| Explain What the Platform Knows | For one device, whether it is expected to report, when it last connected, when its latest event occurred, whether telemetry is current, whether events are missing or out of order, what its last known state is and whether that state is observed or inferred, who receives notifications, and whether monitoring failure can be distinguished from device failure | If these cannot be answered the platform is displaying confidence it does not have. |
| Acted-On Rate | Alerts resulting in an action, by alert type | The only measure that distinguishes monitoring from notification. |
| Prevented Failures | Interventions following a degradation trend rather than a fault | Where the platform pays for itself, and the hardest part to build. |
| Detection Gaps | Incidents that no alert preceded, with the cause identified | Found retrospectively, and the only route to better coverage. |
| Alert Volume | Total against the agreed budget, trended | Volume creep makes the system unreadable before anybody notices. |
| Monitoring System Health | Whether a quiet period is good news or a broken pipeline | Silence is ambiguous and the ambiguity is dangerous. |
What an initial assessment may reveal
An assessment may reveal incomplete device coverage, unreliable last-seen status, stale telemetry presented as current, missing or duplicated events, inconsistent state definitions, excessive false alerts, missed fault conditions, limited diagnostic information, weak service workflow integration, insufficient monitoring of the platform itself, inadequate reconnection testing or unclear clinical and operational boundaries.
We will measure the acted-on rate per alert type, identify rules that have never led to an action, review recent incidents for the alerts that should have fired, check whether alert delivery is verified, and establish which monitoring findings currently route into the quality process.
Bring us a specialty or clinical setting where clinicians are spending too much time creating notes. We will assess where ambient documentation fits, what must remain clinician controlled, how it should integrate with your EHR, and how to measure whether it is actually reducing burden.
One conversation with people who have run these deployments, and a written readiness view you can use with or without us.
- AI Agents and Workflow Automation
- Voice and Conversational AI
- Document AI and Intelligent Processing
- Generative AI and Enterprise Copilots
- AI Strategy and Governance
- HCC and Risk Adjustment Analytics
Security & Compliance
