Companion application development for MedTech, engineered around the dependency that makes these products different from any other software you build.
A companion application makes your medical device dependent on an operating system you do not control, maintained by a company that has never heard of your product, which ships changes to background execution, Bluetooth handling, permissions and power management on its own schedule. When one of those changes affects you, it affects the entire fleet at once, within days, and the first indication is usually a support call rather than a notification. No other software your organization builds carries that exposure.
A patient with an unpaired device has a product that does nothing. Bluetooth pairing is also one of the least reliable interactions in consumer software: it depends on permissions the patient has to grant, radio behaviour they cannot see, a device that may be asleep or out of battery, an operating system that may be restricting the application in the background, and a phone that may have remembered a previous pairing incorrectly. When it fails there is frequently no useful error, and the patient concludes the product is broken or that they are.
Underneath that sits a mismatch nobody designs for: the device lasts a decade and the phone does not.
These two problems also interact. A platform change that degrades background connection presents to the patient exactly as a pairing problem, so support receives connection complaints and the engineering team investigates the pairing flow while the actual cause sits in an operating system release three weeks earlier. Without cohort data showing the failures concentrated on one platform version, that misdiagnosis can run for months.
Pairing fails for reasons nobody can see
Permissions, radio state, battery, background restriction and stale bonds all present to the patient as it not working.
A platform release can break the fleet at once
Background execution, Bluetooth handling and permission behaviour change on a schedule you do not set.
The device outlives several phones
A ten-year device meets handsets, operating systems and app frameworks that turn over far faster.
The app is part of the device and lives in a store
Which puts a platform review process between a clinical fix and the patient who needs it.
Synchronization fails silently
Measurements stay on the device, duplicate, arrive late or appear transferred when they were not, and nothing in the interface says so.
Support cannot see what went wrong
A failure on a patient handset leaves no diagnostic trail unless the application was built to capture one.
The first pairing is the easiest connection you will ever test. In development it happens with a known device, a supported phone, a clean install and an engineer who knows what to expect. In the field the device may be bonded to a previous phone, Bluetooth may be off, permissions may have changed and the patient cannot tell whether the problem is the device, the app, the phone or the network.
The architecture that survives treats operating system behaviour as an external dependency that will move rather than as a stable foundation. That means testing against beta releases, keeping platform-specific behaviour isolated, buffering on the device rather than relying on the app being alive, and having a route to tell patients something when a change breaks a function you cannot fix the same week.
It also means accepting a cost most product plans do not carry: a recurring engineering commitment for the life of the device, sized not by the features you intend to add but by the platform changes you will have to absorb. A companion application is never finished while the device is in service, and the maintenance line in the business case is usually drawn from consumer software assumptions that do not apply to a product with a ten-year obligation behind it.
Step 1
Instrument the pairing flow completely, since this is where most patients are lost and the causes are invisible otherwise.
Step 2
Buffer readings on the device rather than in the application, so a platform restriction loses nothing.
Step 3
Isolate platform-specific behaviour, because the parts that break are the parts that touch the operating system.
Step 4
Test against beta releases of both platforms, since that is the only advance warning available.
Step 5
Design re-pairing as a first-class path, as phone replacement is routine and loses patients permanently when unhandled.
Step 6
Specify the firmware to mobile contract in writing, covering protocol versions, command and response definitions, error codes, device state transitions, data formats, timing assumptions, version compatibility, unsupported combinations and recovery behaviour.
Step 7
Define the compatibility matrix as a living artifact listing device models, firmware versions, handset classes, operating system versions, app versions, known limitations and verification status.
Step 8
Capture diagnostics the support team can actually use, because the patient cannot describe what happened.
Step 9
Establish the regulatory position before architecture, since it governs release cadence for the product life.
Step 10
Plan for the oldest handset and operating system in the population rather than the current one.
Step 11
Build the patient-facing explanation for connection problems, since they will happen and silence makes them worse.
Buffer on the device, because the application cannot be relied upon to be running. An operating system can suspend your application, restrict its background activity, terminate it to reclaim memory or stop it entirely because the patient swiped it away. A device that stores readings locally and uploads whenever the application next connects survives all of that. One that transmits at the moment of measurement loses whatever happened while the application was not available, silently, and the patient has no indication anything was missed. Device-side storage costs memory at hardware design and removes the platform from the critical path for data retention, which is the single most effective reliability decision in a companion product.
Cloud ingestion and the patient gateway problem are covered on our Device-to-Cloud Integration page, and product engagement on our Digital Health Applications page. These are the capabilities specific to the application that talks to the device.
Pair and Connect
Pairing and Onboarding Engineering
The flow instrumented end to end, designed for somebody unwell and non-technical, with every failure mode given a specific recoverable message.
BLE and Connectivity Engineering
Bond management, reconnection, background behaviour and the platform differences that make the same code behave differently on each.
Re-Pairing and Device Transfer
Phone replacement, device replacement and account recovery treated as supported paths rather than as exceptions.
Connection State Communication
Telling the patient honestly what is connected, what is syncing and what is wrong, since they are the only person who can fix it.
Sync and Configure
Data Synchronization
Ordering, deduplication, backfill after days offline and the distinction between measurement time and upload time.
Device Configuration
Settings changes delivered to the device, with authorization proportionate to whether the setting affects clinical behaviour.
Firmware Update Delivery
Over the air through the companion application, covered further on our remote device management page, including interruption and recovery.
Compatibility Management
Which firmware works with which app version on which operating system, maintained explicitly rather than discovered in support.
Operate and Support
Diagnostics and Support Tooling
Capturing enough from a failed interaction that support can resolve it without the patient describing what they saw.
Platform Change Monitoring
Beta testing, release tracking and a defined response when a platform change affects a function you depend on.
Fleet and Cohort Monitoring
Connection success and sync completeness by handset, operating system version and app version, since regressions appear unevenly.
Lifecycle Management
Supporting the oldest device, firmware and operating system in the population for as long as patients are using them.
The third column is how often the device and application have to find each other, which is the property that determines how hard the companion application is to build and how often it will fail in the field.
One further variable cuts across all six: whether the patient chose the device or was given it. Somebody who bought a wearable has motivation to persist through a difficult pairing. Somebody handed a monitor at discharge, who did not ask for it and may not fully understand why they have it, has none. The same connection difficulty produces very different completion rates across those two populations, and a product designed around the first will underperform badly when deployed to the second.
| Device type | How it is used | Connection pattern and difficulty |
|---|---|---|
| Continuous wearables | Worn constantly, measuring continuously | Persistent connection. Hardest, and most exposed to background restriction |
| Episodic home devices | Used once or twice a day at a fixed point | Reconnect per use. Each session is a fresh chance to fail |
| Occasional home diagnostics | Used weekly or on symptom | Reconnect after long gaps, where stale bonds and forgotten steps dominate |
| Therapy delivery devices | Delivering treatment on a schedule | Persistent or frequent, with configuration changes adding authorization needs |
| Implanted device readers | Interrogating an implant periodically | Short, high-stakes sessions where a failed read matters clinically |
A successful upload does not mean the measurement is correctly accounted for. After an offline period the application still has to establish which measurements were captured, which already transferred, whether timestamps are valid, whether they belong to the correct device and patient, whether any are missing, whether retries created duplicates and whether the cloud accepted them. A transmission success response answers one of those.
These are behaviours your application requests and the platform grants, withdraws or modifies at its discretion. The third column is what happens when the platform changes its mind, which it does, and the point of the table is that none of these are things you can engineer around permanently.
| Behaviour | What you depend on | What a platform change does |
|---|---|---|
| Background execution | The app running when not in the foreground | Readings stop arriving and nothing in the app indicates why |
| Bluetooth permissions | Access granted and retained | A prompt appears that patients decline, or access silently lapses |
| Power management | Being allowed to wake and connect | Sync becomes erratic in a way that looks like a device fault |
| Bond and pairing handling | The phone remembering the device | Bonds clear, and every patient has to pair again without warning |
| Notification delivery | Reminders and alerts reaching the patient | Delivery becomes unreliable or is batched into irrelevance |
| Background networking | Upload completing without the app open | Data queues on the phone until the patient opens the application |
Run the platform betas, because that is the only warning you get. Operating system vendors publish beta releases months ahead and almost no medical device team tests against them, which means the first encounter with a breaking change is in production across the whole fleet. Running your companion application against each beta cycle on a representative device, specifically exercising pairing, background sync and notification delivery, converts a fleet-wide incident into a planned piece of work. It costs a small amount of recurring effort, it is the only advance notice available, and the alternative is learning from patients that their device stopped working the week the update shipped.
Where the application displays a measurement a patient acts on, configures the device, delivers firmware or is the only route by which data reaches a clinician, it is participating in the device function rather than supporting it. That has consequences for verification, change control and release cadence, and the boundary is frequently clearer to a regulator than to a product team that built the application with a mobile development process. The determination belongs to your quality and regulatory functions and it has to precede the architecture.
The practical difficulty is that the application is usually built by a mobile team working at mobile pace, and the classification arrives after the architecture. A function added in a sprint because it improved the experience, such as showing a derived value or letting the patient adjust a setting, can be the thing that moves the application inside the device boundary. Reviewing classification at each release where the application gains a function, rather than once at the start, is what keeps this manageable.
Scope and classification
- A recorded determination of which application functions participate in device function and which do not
- 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 where possible, so non-device functions are not held to the device cadence
Security
- Device authentication rather than a connection anybody in range can establish
- Credentials stored using platform-provided protection, not application storage
- Configuration and firmware commands authorized independently of the data connection
- Pairing designed so a device cannot be claimed by somebody other than its intended user
Privacy
- Patient data handled to the obligations your counsel defines, including HIPAA where applicable
- Local cache minimized and cleared, since the handset may be shared, sold or lost
- Diagnostic logs reviewed for content, as these routinely accumulate more than the specification intended
- Third-party SDKs audited for what they transmit, which on a health application is health data
Lifecycle
- Supported operating system versions, handsets and firmware combinations published and maintained
- A defined response when a platform change breaks a function, including what patients are told
- Device retirement and credential revocation when a patient leaves or a device is replaced
- End of support for the application planned, since patients depend on it and withdrawal needs a clinical plan
Companion applications are tested in offices with strong signal, current handsets, charged devices, clean Bluetooth environments and engineers who know what the application expects. Patients use them in homes with thick walls, on handsets several generations old, alongside a dozen other paired devices, with the medical device under a pile of post or in a drawer at twenty percent battery. The difference is not marginal, and the failures that matter only appear in the second environment.
The single most valuable test is also the simplest and almost nobody runs it: give the device and the printed instructions to somebody from the target population, in their own home, on their own phone, and watch without helping. Thirty minutes of that produces findings no laboratory session will, and the instinct to intervene when they struggle is exactly what has to be resisted, because nobody will be there to intervene in production.
The real handset distribution
Old hardware and old operating system versions, in the proportions your population actually runs.
Reconnection after long gaps
Weeks rather than minutes, which is where occasional-use devices actually fail.
Crowded radio environments
Several paired devices, interference and the conditions of an ordinary home.
Permission revocation and recovery
Including the case where the patient declined at onboarding and needs to be brought back.
Interrupted firmware update
Where the patient walks away mid-update, which happens and must not brick the device.
Platform beta releases
Each cycle, exercising pairing, background sync and notifications specifically.
Companion applications are usually reported as downloads and devices activated. The outcomes that matter are what proportion of patients got paired at all, how many are still syncing months later, and whether a platform change would be noticed before patients report it.
| Category | What we measure | Why it matters |
|---|---|---|
| Follow one measurement to its destination | Whether the patient can pair the correct device, whether the device captures it, whether the app receives it correctly, whether device and patient association hold, whether timestamps are right, what happens offline or when the app closes, whether interrupted sync resumes, whether duplicates and gaps are handled, whether the destination acknowledges, and whether the patient can recover after replacing the phone | If these cannot be answered the gaps are in connectivity, synchronization or recovery engineering |
| Pairing success rate | Patients who completed pairing against patients who started, by failure point | The largest loss point, and invisible without instrumentation |
| Sync completeness | Readings received against readings expected, per patient | The measure that reveals background restriction and connection decay |
| Re-pairing survival | Patients still reporting after a phone change or device replacement | Where patients are lost permanently and nobody counts it |
| Cohort variance | Success by handset age, operating system version and app version | A platform regression appears in one cohort before anywhere else |
| Platform change lead time | Whether a breaking change is found in beta or in production | The difference between planned work and a fleet-wide incident |
We will instrument and analyse your pairing flow, measure sync completeness by cohort, review buffering against platform dependence, assess your compatibility matrix and beta testing practice, and examine what support can actually see when a patient reports a failure.
CaliberFocus is a MedTech engineering partner delivering companion application development for medical devices that depend on operating systems they do not control. From instrumented pairing and BLE connectivity engineering to device-side buffering, explicit compatibility management, platform beta testing and support diagnostics, we build companion apps that get patients paired, keep data arriving and recover when the platform changes underneath them.
- Pairing instrumented end to end before it is built
- Readings buffered on the device, not dependent on the app running
- Platform betas tested every cycle to catch breaking changes early
- Diagnostics support can use without the patient describing the fault
Security & Compliance
