Connected medical device platform engineering, built around the obligation that begins the day the first unit comes online and ends when the last one leaves service.
A connected product launch is usually planned as a programme with a delivery date. What actually starts is a standing commitment: to operate the platform, to support every protocol and firmware generation in the field, to maintain security for devices designed years ago, and to keep all of it running while customers build clinical workflows on top of it. Once a hospital depends on remote visibility you cannot withdraw it, and the oldest unit in service sets the retirement date for everything underneath it.
Connecting a device is easy. Keeping it connected, secure and supportable is the engineering. And the platform you design for generation one is the one you operate when generation four ships.
A device company that has shipped for a decade has several hardware generations, more firmware versions, at least two connectivity approaches and probably an acquired product line with its own protocol, all in service at once. Each new generation adds to that set rather than replacing it, because devices in the field are not upgraded on your schedule and some will never be upgraded at all. The platform therefore accumulates compatibility obligations continuously and sheds them only when the last unit of a generation is decommissioned.
The second problem is that connectivity in a hospital is not something you control, and the platform has to work without assuming it.
Every generation stays in service
New versions add to the supported set rather than replacing it, and the oldest unit sets the obligation.
You cannot withdraw a capability customers depend on
Once remote visibility is in a clinical workflow, removing it is a product change with customer consequences.
Hospital networks are not yours
Firewalls, proxies, segmentation and IT policy differ per site and change without notice.
Connectivity is intermittent by nature
Devices move, lose signal, sit behind equipment and get switched off, so disconnection is normal rather than exceptional.
A device can work perfectly and be invisible to you
Operating for years without reporting utilization, software version or fault history, which is the default rather than the exception.
Acquisitions arrive with their own platforms
And consolidating them is harder than building one, because the installed base cannot simply be migrated.
Decide what you are promising before the first device connects
Connected capability is usually scoped as features and delivered as a commitment. Establish explicitly what you are undertaking to provide, for how long, to which generations, with what availability and under what circumstances it could change.
The design decisions that matter are the ones that are expensive to change once hardware is in the field: the protocol, the identity model, the update mechanism and the data contract. Everything in the cloud can be rewritten. The device side cannot, which means platform design is really a question of what you are prepared to commit to permanently.
Step 1
State the connectivity commitment explicitly, covering scope, duration, generations and availability, before building.
Step 2
Design the device identity model first, since it has to outlive everybody who set it up, covered on our identity page.
Step 3
Make the update mechanism the most robust thing on the device, because it is the control every later fix depends on.
Step 4
Treat disconnection as the normal state, with buffering, reconnection behaviour and backoff designed rather than assumed.
Step 5
Version the data contract from the first message, since the fleet will carry several versions simultaneously and permanently.
Step 6
Plan multi-generation support explicitly, because the compatibility matrix only grows.
Step 7
Design the hospital network position, since you do not control it and cannot require changes to it.
Step 8
Separate clinical paths from operational ones, so analytics load never competes with data somebody is treating a patient on.
Step 9
Build the fleet view early, covered on our installed base page and needed from the first deployment rather than the hundredth.
Step 10
Start with one device family and one objective, such as reliable connectivity status, firmware visibility across the fleet or measured utilization, before extending to other products and geographies.
The update mechanism is the only decision you cannot fix later.
Every other device limitation can eventually be addressed by an update: a protocol gap, a security weakness, a data format problem, a behavioural defect. All of that depends on being able to deliver and apply an update reliably to a device that may be behind an unfamiliar firewall, on intermittent connectivity, running firmware several versions behind.
Connection and ingestion engineering is covered on our Device Connectivity page, command and configuration on our Remote Device Management page, and telemetry analytics on our IoT platform page. These are the platform-level capabilities that span them.
Connect
Device Identity and Provisioning
Credential issuance, rotation and recovery designed to outlive the people who configured it and to work at manufacturing scale.
Connectivity Architecture
Protocol selection, gateway strategy and hospital network accommodation, designed for environments you do not control.
Edge Design
What the device decides alone, what it buffers and for how long, which determines behaviour when the platform is unreachable.
Onboarding at Scale
Getting devices connected without a service visit, since onboarding friction determines connected fleet proportion more than anything else.
Operate
Fleet Management
Status, configuration, firmware distribution and health across generations, covered further on our remote management page.
Remote Monitoring and Diagnostics
Device state and diagnostic access, with clinical paths isolated from operational and analytical ones.
Multi-Generation Compatibility
Serving several hardware and firmware versions simultaneously with a versioned data contract and an explicit support matrix.
Scale and Surge Handling
Reconnection bursts, campaign load and fleet growth, which are the load events that actually break device platforms.
Update and Sustain
Update Delivery Engineering
Reliable, resumable, verified updates with rollback, since this is the capability every future fix depends on.
Campaign Management
Staged rollout, cohort control, confirmation and halt, covered in depth on our remote device management page.
Security Sustainment
Certificate lifecycle, vulnerability response and component inventory, covered on our device cybersecurity page.
Platform Lifecycle Planning
What is supported for how long, what happens when a generation retires, and how a legacy platform is eventually consolidated.
What CaliberFocus does, and does not do?
The platform should know what it knows and what it does not. A device that has not reported recently is not automatically failed, inactive or retired, and observed state should never be silently replaced by inferred state. We also ask what you are committing to before we design anything, because connected capability is scoped as features and delivered as a permanent obligation.
Connected capabilities differ in whether they are operational conveniences or part of what the device does clinically. The third column is the commitment each creates, and the distinction matters because two of these are very difficult to withdraw once customers rely on them.
| Capability | What It Delivers | The Commitment It Creates |
|---|---|---|
| Fleet Status and Inventory | Visibility of what exists and where | Internal. Withdrawable, and the foundation for everything else. |
| Remote Diagnostics | Fault investigation without a site visit | Service expectation. Customers plan around it quickly. |
| Software and Firmware Updates | Fixes and capability delivered remotely | Permanent. Every later fix depends on this path existing. |
| Remote Configuration | Settings adjusted without attendance | Significant, since a setting may change clinical behaviour. |
| Clinical Data Delivery | Readings reaching a care team | The deepest. A clinician relies on it and cannot be told to stop. |
The Moment Clinical Workflow Depends on It, the Platform Is Part of the Device
A fleet dashboard is an internal tool. A platform delivering readings a clinician checks before making a decision is something else: it participates in care, its availability has clinical consequence, and an outage is not an IT incident.
Cloud architecture can be rewritten. Device-side decisions persist for the service life of the hardware, which means they deserve disproportionate attention at design time. The third column is what it costs to change each one after shipping.
| Decision | What It Determines | Cost of Changing It Later |
|---|---|---|
| Update Mechanism | Whether any later fix can be delivered | Catastrophic. Without it every fix is a service visit. |
| Identity and Credentials | How the device authenticates for its whole life | High. Requires an update, which requires the update path to work. |
| Protocol and Data Contract | What the device can say and how | High. The old version must be supported indefinitely alongside the new. |
| Buffering Capacity | How long an outage can last before data is lost | Fixed at hardware design. Sets your real recovery objective. |
| Edge Decision Scope | What the device does when unreachable | Moderate, and only if the update path is sound. |
| Security Primitives | What cryptography the device can support | Very high. Frequently bounded by hardware chosen years earlier. |
Version the data contract from the first message
Because the fleet will carry several versions at once and the first one never retires cleanly.
Design backoff and jitter into firmware
The cheapest place to absorb a reconnection storm is the device, covered on our Kubernetes page.
Assume the hospital network will change without notice
Ports close, proxies appear, segmentation is introduced, and none of it is announced to you.
Keep the clinical path isolated
Analytics, campaigns and bulk operations must never compete with data somebody is treating a patient on.
Plan for the acquired platform
Consolidating two connected estates is harder than building one, and the installed base cannot simply migrate.
Make the support matrix explicit
Which firmware works with which platform version, published internally and maintained rather than inferred.
Your real recovery objective was fixed when somebody chose the buffer size.
Availability targets are usually set from an infrastructure conversation. For a connected device the binding constraint is how long the hardware can hold data before losing it, which was decided at design and cannot be changed in the field.
A platform showing fleet inventory is ordinary enterprise software. The same platform computing a derived clinical value, delivering an alert somebody acts on, or changing a setting that affects how a device behaves is participating in the product. The components frequently sit in the same codebase and the boundary is not visible in the architecture, which is why it has to be drawn deliberately with your quality function rather than inferred by engineering.
Boundary and classification
- Each platform component assessed for whether it participates in device function, with the determination recorded
- Engineering controls capable of supporting the frameworks that apply, which may include FDA regulation, IEC 62304, ISO 13485 and electronic record expectations
- Applicability, classification and validation strategy determined by your quality and regulatory functions rather than by us
- Reassessment when scope drifts, since a capability introduced as operational can become clinical through adoption
Security
- Device identity, credential lifecycle and revocation, covered on our identity and device security pages
- Component inventory per firmware and platform version, with vulnerability response mapped to deployed devices
- The hospital network treated as untrusted, since you neither control nor can rely on it
- Authorization on any device-affecting action, with the command path treated as the highest-privilege surface you operate
Privacy
- Patient-associated data handled to the obligations your counsel defines, covered on our privacy page
- Data residency addressed per market, since a global fleet reports into jurisdictions with different requirements
- Customer and clinical information protected under the relevant agreements and access scoped by purpose
- Retention aligned to obligation rather than to storage cost, covered on our device data engineering page
Lifecycle
- Supported generations, firmware versions and protocols published and maintained rather than inferred
- Platform change assessed against every generation in service rather than only the current one
- End of support defined and communicated, since customers plan around capability you have not committed to withdraw
- Acquired platform consolidation planned deliberately, because the installed base cannot be migrated on your schedule
A remote update is not an ordinary web application deployment when it can affect device function
Eligibility, package integrity, authorized deployment, installation verification, failure recovery, rollback feasibility, safety implications and update status traceability all apply, and the frameworks that may be relevant extend to IEC 62304 and IEC 81001-5-1 where your quality function determines they apply.
Connected proportion is usually treated as a customer adoption question and is mostly an onboarding design question. Every step requiring a hospital IT ticket, a firewall change, a service visit or a password somebody has to find loses a percentage of the fleet permanently. The devices that never got connected are not a marketing problem, they are the ones invisible to every capability the platform provides, and they accumulate quietly.
Steps requiring hospital IT involvement
Each one introduces a queue, and some never clear.
Whether onboarding needs a service visit
Which turns connection into a cost decision somebody can defer indefinitely.
Network assumptions the device makes
Outbound-only, common ports and proxy tolerance determine how many sites work without negotiation.
What happens when onboarding fails
Whether anybody is told, and whether the attempt is retried or silently abandoned.
Whether the benefit is visible to the person installing
Since the installer is frequently not the beneficiary and has no reason to persist.
Re-onboarding after a site change
Networks get rebuilt and devices drop off, and nobody notices without expected-value monitoring.
Device registration failure, where provisioning cannot complete
Extended disconnection while the device keeps operating. Reconnection burst overwhelming ingestion. Duplicate or out-of-order events distorting sequences. Clock drift making history unreconstructable. Firmware compatibility failure, where an update reaches an incompatible configuration. Credential expiration or revocation failure, where devices lose access or retain it wrongly. And incorrect lifecycle status, where transferred or retired devices stay in the active fleet.
Measure connected proportion as a primary metric
It bounds every other capability and degrades silently, covered on our reliability page.
Treat a dropped device as an event
Not an absence, since silence has several causes and each needs a different response.
Stage every campaign and confirm
Covered on our remote device management page, and the discipline that prevents a fleet-wide incident.
Exercise recovery including the reconnection surge
Because a restored platform meets the whole affected fleet at once.
Connected platform programmes are usually reported as devices onboarded and features shipped. The outcomes that matter are connected proportion, whether an update can actually reach the fleet, and whether the commitment you made is one you can sustain.
| Category | What We Measure | Why It Matters |
|---|---|---|
| Reconstruct One Connected Lifecycle | For a single device, whether you can state its identity, customer and location, configuration, last connection, whether the last reported state is current, what telemetry was missed while offline, whether delayed events reconstruct in order, who may access it, whether credentials can be rotated, how updates are authorized and what happens if one fails | If these cannot be answered the gap is identity, connectivity and lifecycle engineering rather than tooling. |
| Connected Proportion | Devices reporting within a recency window against devices shipped | Bounds every capability the platform provides, and degrades silently. |
| Update Reach | Proportion of the fleet an update can actually be delivered to | Determines whether any future fix is a release or a service campaign. |
| Onboarding Completion | Attempts that result in a connected device, and where the rest fail | The main lever on connected proportion and usually unmeasured. |
| Clinical Path Isolation | Whether analytics or campaign load can affect clinical delivery | The separation that determines what an outage means. |
| Recovery Including Surge | Time from restoration to the fleet being current | The part of an incident that still affects patients. |
Honest Expectation Setting
An assessment may reveal inconsistent device identity, unreliable connectivity status, incomplete telemetry history, missing offline buffering, duplicate events after reconnection, limited diagnostic visibility, fragmented version tracking, unclear credential lifecycle ownership, incomplete retirement processes, weak field service integration, insufficient monitoring, inadequate scalability testing, unclear update controls or rising telemetry cost.
We will measure connected proportion and update reach, examine where onboarding fails, review which capabilities have become clinical through adoption, assess the support matrix across generations, and establish whether your stated recovery objective is achievable for the oldest hardware in service.
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
