Cloud and edge integration for MedTech, designed from the only question that matters when connectivity fails: what can the device still do on its own.
Moving processing to the cloud is usually justified on development speed, maintainability and the ability to improve logic without a firmware release. All of that is true, and each move makes the device dependent on your platform being reachable. For a device in a hospital basement during a network incident, the explanation that the cloud was unavailable is not an acceptable account of why an alert did not arrive. The split between device and cloud therefore belongs to the clinical risk conversation rather than only the engineering one.
Cloud-side logic is easier to write, easier to fix and easier to improve, which is why functionality migrates there incrementally. A threshold calculation moves for maintainability. An alert rule moves so it can be tuned without a firmware release. A derived value moves because the device lacks the processing headroom. None of those decisions is wrong individually, and collectively they can turn a device that worked standalone into one that requires a network connection to do its job, without anybody making that decision explicitly.
The second problem is that degraded operation is rarely designed. It is whatever the device happens to do when the connection drops.
Dependency accumulates one convenience at a time
Each individual move is defensible and the cumulative effect is a device that cannot operate alone.
Degraded behaviour is default rather than designed
What the device does during an outage is frequently whatever the code happens to do, not a decision somebody made.
Edge headroom was fixed at hardware design
Processing, memory and power were specified years ago, and the logic you want to move may not fit.
Hospital networks fail in ways you cannot predict
Segmentation, proxy changes, maintenance windows and outages, none of which you control or are told about.
Different generations need different integration patterns
Legacy units, newer connected products and gateway-dependent equipment do not share communication or processing capability.
Synchronization conflicts have no obvious answer
When device and cloud both changed state during a disconnection, something has to resolve it and the rule is rarely specified.
Three functions, three different answers. The device performing its intended function may need to be independent of connectivity entirely. Telemetry collection can buffer locally and transmit later. Fleet analytics tolerates delay without consequence. Treating them as one cloud-dependent workflow creates risk nobody chose to take.
The architecture follows from one list: what must continue working when the device is alone. Everything on that list is edge responsibility regardless of how inconvenient that is, and everything else can live wherever it is cheapest to build and maintain. Reversing the order, by placing logic where it is easiest and discovering the outage behaviour later, is how device companies end up with clinical functionality depending on their uptime.
Step 1
Specify required offline behaviour first, with clinical input, since that list defines the edge boundary.
Step 2
Assess available edge headroom honestly, because the hardware was specified years ago and may not accommodate it.
Step 3
Place anything safety-relevant on the device, regardless of how much easier the cloud would be.
Step 4
Design degraded modes explicitly, so the user knows what is still working rather than inferring it.
Step 5
Make degradation visible to the clinician, because a product quietly operating in reduced mode is trusted as if it were not.
Step 6
Name which component owns the authoritative state per data type, since that answers most conflict questions before they arise.
Step 7
Choose delivery semantics deliberately, covering at-most-once, at-least-once, deduplication, idempotency and ordering, rather than assuming messages arrive once and in order.
Step 8
Buffer with a stated retention and a defined overflow behaviour rather than an undefined one.
Step 9
Version the device and cloud contract, because the two will be at different versions permanently.
Step 10
Keep device-affecting commands separate from data flow, covered on our remote device management page.
Step 11
Test the outage, including the recovery and the reconnection surge, rather than testing the connected path only.
A device operating quietly in a degraded mode is more dangerous than one that has stopped. When connectivity fails and the device continues working with reduced capability, the clinician sees an operating device and reasonably assumes full function. If an alerting rule now lives in a cloud that cannot be reached, the absence of alerts reads as the absence of problems. Making degradation visible at the device, in a way a clinical user understands without training, is a small interface decision that determines whether reduced operation is safe or silently misleading.
Connectivity, telemetry and fleet operations are covered on our connected device pages. These are the capabilities specific to deciding and building the division of work between device and cloud.
Split and Run
Edge and Cloud Boundary Design
The division decided from required offline behaviour and clinical risk rather than from development convenience.
Offline Operation Engineering
What the device does alone, for how long, with what buffering and what happens when the buffer fills.
Degraded Mode Design
Defined reduced states with the current capability visible to the user, rather than undefined behaviour nobody specified.
Edge Processing and Edge AI
On-device inference and local logic where latency, autonomy or safety require it, within the headroom the hardware allows.
Reconcile
Synchronization Engineering
State reconciliation after a disconnection, with conflict rules specified in advance rather than resolved by whichever side wrote last.
Buffering and Replay
Retention depth, ordering, deduplication and overflow behaviour, covered further on our connectivity page.
Contract Versioning
Device and cloud at different versions permanently, with compatibility maintained rather than assumed.
Reconnection Handling
The surge after an outage, which is the largest load event the platform experiences and the one most likely to break it.
Integrate and Operate
Cloud Platform Engineering
Device-facing services, APIs and data pipelines, with clinical paths isolated from analytical and campaign load.
Hybrid and Regional Architecture
Where residency, latency or customer policy requires processing to stay local, including on-premise gateway options.
Enterprise Integration
Service, quality, commercial and analytics systems receiving device information with the controls each requires.
Lifecycle and Update Management
Keeping both sides maintainable across generations, covered on our connected platform and remote management pages.
The third column is where the function has to live, derived from what happens if it is unavailable. The pattern is that anything a clinician relies on in the moment belongs on the device, and anything supporting a later decision can sit in the cloud.
| Function | What it does | Where it has to live |
|---|---|---|
| Clinical alerting | Notifies somebody of a condition requiring action | Device. An alert that depends on reachability is not an alert |
| Safety interlocks and limits | Prevents unsafe operation | Device, without exception, and never behind a network call |
| Core measurement and recording | The device doing its primary job | Device, with buffering for whatever cannot be transmitted |
| Remote diagnostics | Service investigation without a site visit | Cloud, since it serves a later decision rather than an immediate one |
| Predictive maintenance | Intervention before failure | Cloud generally, with on-device detection where latency demands it |
Put processing at the edge because the requirement demands it, not because the technology allows it. Latency, connectivity, privacy, bandwidth, cost and intended use decide processing location, and none of those is the availability of an edge runtime.
These are the decisions that determine behaviour during the conditions that matter. The third column is what happens if the question is left unanswered, which is usually that the implementation decides by accident.
| Question | What it determines | If left unanswered |
|---|---|---|
| What must work offline | The edge boundary | Logic drifts to the cloud and the device quietly becomes dependent |
| How long must it work alone | Buffer depth and local retention | The buffer size is whatever the hardware had spare |
| What happens when the buffer fills | Whether old or new data is lost | Something is discarded and nobody chose which |
| Who wins a synchronization conflict | State after reconnection | Last write wins, which is rarely the clinically correct answer |
| What does the user see when degraded | Whether reduced operation is safe | Normal appearance, which is the dangerous outcome |
| How do both sides stay compatible | Behaviour across versions | A cloud release breaks an older firmware cohort |
Recovery is part of the architecture, not an exception handler. A distributed platform is not reliable because it works when connected, and defined behaviour for delayed messages, restarting components, full storage and returning connectivity is design work rather than error handling added later.
Where a cloud component performs a function the device would otherwise perform, it is participating in the product rather than supporting it. That has consequences for change control, validation and incident handling, and the component frequently sits in a codebase and a release pipeline designed for ordinary web software. The boundary is not visible in the architecture, which is why it has to be drawn with your quality function rather than inferred by engineering.
Boundary
- Each cloud component assessed for whether it performs device function, with the determination recorded
- 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
- Separate release paths for components inside and outside device function, covered on our cloud platform page
Security
- Device identity and mutual authentication, covered on our identity and device security pages
- The hospital network and any gateway treated as untrusted, since neither is under your control
- Edge software included in vulnerability management and component inventory, not only cloud services
- Command paths separated from data paths with independent authorization
Privacy
- What the device transmits reviewed against what it was specified to transmit, covered on our telemetry page
- Data residency addressed per market, which may itself require edge or regional processing
- Patient-associated data handled to the obligations your counsel defines
- Local storage on the device and gateway treated as a data store with its own protection requirements
Lifecycle
- Edge software versioned and updateable, since logic on the device is harder to change for the product life
- Compatibility maintained across every firmware generation in service
- Degraded mode behaviour documented and validated rather than emergent
- Gateway hardware lifecycle planned, since it is infrastructure you own sitting in somebody else building
Integration testing concentrates on the connected path because that is the functionality being built. The behaviour that determines clinical safety is what happens during and after a loss of connectivity, and that is frequently exercised for the first time in production. Disconnecting a device deliberately, for longer than anybody expects, and observing everything that follows is the single most informative test available.
Behaviour during the outage
What still works, what degrades, what the user sees and whether they can tell.
Buffer exhaustion
What happens when local storage fills, and whether the choice of what to discard was deliberate.
Reconnection and replay
Ordering, duplication, and whether the backlog is processed without disrupting live traffic.
Synchronization conflicts
Where both sides changed, whether the resolution matches the specified rule.
The surge across many devices
Since a regional outage ends for everybody at once, covered on our Kubernetes page.
Time to a consistent state
How long after restoration before the device and cloud actually agree.
Integration programmes are usually reported as services delivered and devices connected. The outcomes that matter are what the device can still do without you, and whether anybody has tested it.
| Category | What we measure | Why it matters |
|---|---|---|
| Disconnect it and explain what happens | Which functions continue and which stop, what is stored locally, how long buffering lasts, what happens when storage fills, whether timestamps survive, how retries and duplicates are handled, what a gateway restart does, which component owns authoritative state, how conflicts resolve, and whether security controls hold offline | If these cannot be answered the architecture has undefined behaviour in the condition that matters most |
| Offline capability | What the device does alone, against what the product requires it to do | The gap between those two is the risk nobody wrote down |
| Degraded mode visibility | Whether a clinical user can tell the device is operating at reduced capability | Quiet degradation is the most dangerous failure mode |
| Outage tested duration | The longest disconnection the product has actually been tested through | Usually shorter than a real hospital network incident |
| Conflict rule coverage | Data types with a specified resolution rule against those defaulting to last write | Where silent inconsistency originates |
| Recovery to consistency | Time from reconnection to device and cloud agreeing | The part of recovery that is still affecting operation |
We will write the offline specification with your clinical input, compare it against what the device currently does alone, review degraded mode visibility, examine synchronization conflict rules per data type, and establish whether gateways are managed infrastructure or forgotten hardware.
CaliberFocus is a MedTech engineering partner delivering cloud and edge integration for connected devices that must keep working when the network does not. From offline requirement specification and edge and cloud boundary design to degraded mode visibility, synchronization rules and outage testing, we build architectures where safety-relevant functions stay on the device and the cloud makes it better rather than making it dependent.
- Edge and cloud split decided from required offline behaviour
- Degraded modes designed and made visible to clinicians
- Synchronization conflict rules specified per data type
- Outage, recovery and reconnection surge tested deliberately
Security & Compliance
