Device telemetry and analytics for MedTech, designed around the constraint that governs everything: the schema was set at firmware design and the questions arrive much later.
Telemetry is specified by firmware engineers solving a diagnostic problem, under memory and bandwidth constraints, years before anybody asks a reliability, utilization or product question. When those questions arrive, the field that would answer them either exists or does not, and if it does not the remedy is a firmware release to a fleet that updates slowly and incompletely. Your analytical capability is therefore bounded by decisions made for a different purpose by people who were never asked what analysis would need.
The most important analytics field may be the one the device never sent. Which makes the schema conversation worth having before the hardware ships, with the analysts in the room.
In an ordinary software product, instrumenting a new metric is a deployment. On a device fleet it is a firmware release that must be validated, campaigned, accepted by customers and applied to units that may update slowly or never. The practical consequence is that the analytical backlog is bounded by update cadence: a question asked today may be answerable in eighteen months, partially, for the portion of the fleet that took the release. Teams used to web analytics underestimate this by an order of magnitude.
The second problem is that what was instrumented serves diagnostics rather than analysis, which are different purposes with different data shapes.
New instrumentation requires a firmware campaign
Which is validated, staged and incompletely adopted, so a new field arrives slowly and partially.
The schema was designed for diagnostics
Fault codes and service logs answer why a device broke, not how it is used or how a cohort performs.
Analysts were not in the design conversation
Telemetry specification sits with firmware, and the people who will consume it are rarely consulted.
Generations carry different schemas
Which means a fleet-wide question is answered differently per cohort, or not at all for the older ones.
Data volume grows faster than analytical value
High-frequency telemetry raises storage and processing cost without improving the decisions the organization actually makes.
Definitions were never written down
What a field actually means is frequently known only to the engineer who added it, who has moved on.
Ask what question you could not answer last quarter, and why.
Collect the analytical requests that were declined or partially answered, and establish the cause for each: the field was never instrumented, it exists only on newer generations, the sampling rate is too coarse, the definition is ambiguous, or the retention window had passed. That list is the specification for the next firmware schema change, it is grounded in real demand rather than speculation, and it is the only input that reliably improves telemetry design for the next generation.
The cheapest telemetry improvement available is a conversation at design time between the people specifying what the device emits and the people who will be asked product, reliability and commercial questions about it. That conversation costs an afternoon, happens almost nowhere, and determines what the organization can learn from a generation for its entire service life.
Step 1
Collect the questions the organization wants answered, before specifying any schema, since that is the requirement.
Step 2
Bring analytics into firmware design review, because the schema is set there and revisited almost never.
Step 3
Document what every field means at the point it is added, since the engineer who knows will not always be available.
Step 4
Version the schema from the first message, as the fleet will carry several versions simultaneously and permanently.
Step 5
Decide sampling and resolution against analytical need rather than only against bandwidth.
Step 6
Carry generation, firmware and configuration with every measurement, so values are never compared across incomparable cohorts.
Step 7
Design retention as an option on future questions, covered on our device data engineering page.
Step 8
Normalize on ingestion while preserving the raw form, since mapping decisions get revisited.
Step 9
Define the metric before building the pipeline, since a technically correct pipeline still produces misleading analytics if the population, denominator or event definition is wrong.
Step 10
State what the data cannot answer, because a confident analysis on an unsuitable field is worse than a gap.
A field whose meaning nobody recorded is a field nobody can safely use.
Telemetry fields accumulate with names that made sense to the engineer who added them: a counter that resets under conditions nobody documented, a status code whose values were extended twice, a measurement whose units changed between generations.
Connectivity, ingestion engineering and monitoring are covered on our connected device pages. These are the capabilities specific to what gets measured and whether it can be analysed.
Specify
Telemetry Schema Design
Specified from the questions the organization will ask rather than only from diagnostic need, with analytics present at design review.
Field Definition and Documentation
Meaning, units, reset behaviour and applicable generations recorded at the point a field is created rather than reconstructed later.
Schema Versioning
Explicit from the first message, since the fleet carries several versions at once and the first one never retires cleanly.
Sampling and Resolution Design
Decided against analytical need as well as bandwidth, because resolution discarded on the device cannot be recovered.
Collect and Normalize
Ingestion and Time-Series Engineering
Volume handling, late arrival, out-of-order events and deduplication, covered in depth on our connectivity page.
Cross-Generation Normalization
Making values comparable where they legitimately are, and flagging where they are not, rather than silently harmonizing.
Context Enrichment
Generation, firmware, configuration, customer and location attached to every measurement so cohort analysis is possible.
Raw Preservation
The original form retained alongside the normalized one, since normalization encodes assumptions that get revised.
Analyse
Utilization and Performance Analytics
How devices are actually used, which is the most commercially valuable signal and the one most schemas were not designed to produce.
Fault and Reliability Analytics
Failure patterns by cohort, age and configuration, with exposure adjustment covered on our installed base page.
Fleet Cohort Comparison
Performance across generations and configurations, with comparability stated rather than assumed.
Analytical Feasibility Assessment
Establishing which questions the existing telemetry can answer honestly, which is frequently the most useful early output.
What CaliberFocus does, and does not do?
Preserve the raw event and govern the meaning. Normalized models improve consistency, and the original device events with their source context must survive, because normalization encodes assumptions that get corrected.
Each of these depends on specific telemetry existing at adequate resolution. The third column is what the schema has to contain, and the pattern is that the commercially valuable questions need fields diagnostic-oriented schemas rarely include.
| Question | What It Informs | What the Schema Must Contain |
|---|---|---|
| Is the Device Faulting | Service response | Fault codes and error events. Almost always present, since this is why telemetry exists. |
| How Much Is It Being Used | Commercial, reliability and service planning | Operating cycles or duration. Frequently absent, and the highest-value gap. |
| Is Something Degrading | Preventive intervention | Continuous measurements at adequate resolution rather than threshold crossings. |
| Does This Configuration Perform Differently | Engineering and product decisions | Configuration carried with every measurement, which is often not the case. |
| What Happened Before the Failure | Investigation and root cause | Retained history at the time of the event, which retention policy may have discarded. |
Utilization Is the Field Nobody Instruments and Everybody Wants
Operating cycles, run duration and active hours are rarely in a diagnostic schema because they do not help a service engineer fix anything. They are, however, the basis for consumable forecasting, reliability exposure adjustment, commercial account planning, service capacity modelling and product development prioritization.
Cloud-side architecture can be rebuilt. These decisions are fixed in firmware and in some cases in hardware, and they set the ceiling on what analysis is ever possible for that generation. The third column is what is permanently lost if the decision is wrong.
| Decision | What It Governs | What Is Permanently Lost |
|---|---|---|
| Which Fields Exist | The entire analytical surface | Any question requiring an uninstrumented field, for that generation. |
| Sampling Rate | Whether short events are visible at all | Transients shorter than the interval, which never happened as far as data shows. |
| On-Device Aggregation | Whether raw values ever leave the device | Distribution and variance, where only an average is transmitted. |
| Buffer Depth | How much history survives an outage | Everything older than the buffer during a long disconnection. |
| Timestamp Source | Whether event sequence can be reconstructed | Reliable ordering, where the device clock drifts. |
| Transmission Trigger | When data arrives relative to when it happened | Timeliness, and the ability to act on anything in near real time. |
Prefer raw over aggregate where bandwidth allows
An average discards the distribution, and the distribution is where most reliability signal lives.
Instrument a usage counter even without a current question
Because exposure adjustment underpins every reliability comparison you will eventually want.
Carry schema version in the payload
So the platform never guesses which generation it is parsing, covered on our connectivity page.
Treat sampling rate as an analytical decision
Not only a bandwidth one, since resolution discarded on the device cannot be recovered in the cloud.
Never compare across generations without checking comparability
Covered on our device data engineering page, and the commonest source of a wrong conclusion
Keep the raw payload alongside the parsed form
Since parsing encodes an interpretation and interpretations get corrected.
On-device averaging is the quiet decision that removes your best signal.
Transmitting an average rather than raw samples is a reasonable bandwidth decision and it discards the distribution. Variance, outliers, short excursions and the shape of a measurement are where early degradation usually shows, and an average smooths all of it away before the data ever leaves the device.
Diagnostic logs capture whatever the firmware writes, and over a decade that accumulates: timing patterns that reveal usage, error context containing fragments of clinical detail, configuration reflecting a specific patient setup, location implied by network characteristics. None of it was specified as patient data and some of it is. The question is not what the schema says is collected, it is what a motivated reader could derive from what arrives.
Privacy
- Log content reviewed for what it actually contains rather than what the specification intended
- Patient-associated data handled to the obligations your counsel defines, covered on our privacy page
- Derived inference considered, since usage timing and configuration can reveal more than the fields suggest
- Data residency addressed per market, since a global fleet reports into several jurisdictions
Security
- Telemetry treated as untrusted input on arrival, since the transport is outside your control
- Device identity and credential lifecycle, covered on our identity and device security pages
- Access to raw telemetry scoped by purpose, since service and commercial use are different grants
- Export and bulk access monitored, as the largest disclosure surface on a telemetry platform
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 telemetry-derived value informs a clinical decision, the boundary assessed rather than assumed
- Schema change treated as a device software change where the firmware is in scope
Data governance
- Field definitions versioned, since meaning changes between generations and nothing announces it
- Retention aligned to the obligation and to future questions, covered on our device data engineering page
- Derived metrics documented with their calculation, so a figure can be explained when challenged
- Comparability across generations stated in the data rather than left to the analyst
Read a year of your own diagnostic logs before deciding they contain nothing sensitive.
Log content is specified loosely and written by engineers solving immediate problems, which means it accumulates whatever was convenient to record: free-text error context, parameter dumps, identifiers nobody intended to transmit.
Gaps in device telemetry correlate with exactly the conditions that matter: devices in poorly connected sites, units that were switched off, periods of heavy use that drained a buffer, and failures that took the device offline before it could report. An analysis treating absent data as missing at random will systematically under-represent the worst-performing units and the most severe events, and produce a reliability picture that is optimistic in a direction nobody has quantified.
Reporting completeness per device
Against an expected rate, since gaps are informative and absence produces no error.
Whether gaps correlate with outcomes
Because if they do, every analysis on the complete records is biased and the direction is predictable.
Schema version distribution across the fleet
Since a question answerable on new firmware may be unanswerable on most of the installed base.
Field population rates
A field present in the schema and never populated is a question somebody will answer wrongly.
Clock drift and ordering integrity
Because sequence underpins most investigation, covered on our monitoring page.
Cost per device per year
The economic measure for a workload that scales with the fleet, covered on our Fabric page.
Report coverage with every analysis
So a conclusion from seventy percent of the fleet is never read as a fleet conclusion.
Investigate the gaps rather than excluding them
The missing records are disproportionately the interesting ones.
Version derived metrics
Since a changed calculation restates history across every report consuming it.
Tier storage by access pattern
Covered on our Fabric page, and the largest cost lever in a telemetry platform.
Telemetry programmes are usually reported as data volume ingested and dashboards built. The outcomes that matter are which business questions became answerable, which remain blocked and why, and whether the next generation will be better instrumented.
| Category | What We Measure | Why It Matters |
|---|---|---|
| Defend Every Number Behind One Metric | Which devices are included and excluded, the observation period, coverage completeness, what qualifies as a fault, whether the definition changed across firmware, whether duplicates are removed, whether delayed events land in the right period, whether exposure is available, whether generations are comparable, and whether another team would calculate the same result | If these cannot be answered the metric is a number rather than a measurement. |
| Questions Answerable | Business questions the current telemetry can honestly answer | The actual capability, as distinct from the data volume. |
| Blocked Questions and Causes | What cannot be answered and whether the cause is schema, resolution or retention | The specification for the next firmware revision. |
| Gap Correlation | Whether missing telemetry correlates with outcomes | If it does, every existing reliability figure is optimistic. |
| Schema Documentation | Fields with recorded meaning, units and applicable generations | A field nobody can explain is one somebody will misuse. |
| Analyst Involvement in Design | Whether analytics reviewed the next generation schema | The only intervention that improves future capability. |
Honest Expectation Setting
An assessment may reveal incomplete device coverage, inconsistent event definitions, duplicate telemetry, delayed or missing events, clock drift, fragmented device identity, missing operating exposure, unreliable utilization definitions, inconsistent firmware interpretation, weak lineage, limited enterprise integration, high processing costs or analytics that cannot be reproduced.
We will establish which questions your current telemetry can honestly answer, identify why the others are blocked, check whether missing data correlates with outcomes, review field definitions and generation comparability, and produce the schema requirements for your next firmware revision.
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
