The prototype works. The enclosure is approved. A pilot site is interested. Then somebody on the team asks what happens after the device goes home with the patient.
How will the person know whether setup was completed correctly? Where will they record discomfort or an unexpected experience? How will they remember the next use? Can the study team see whether a daily diary was completed? What happens when Bluetooth stops pairing on a Sunday morning?
Those questions are easy to postpone because they do not look like the device itself. In practice, they shape whether the device can be used consistently outside the clinic.
In brief: a medical device companion app can handle onboarding, reminders, device-use logs, symptoms, patient-reported outcomes, educational content and support. If it controls the device, analyzes device data or provides patient-specific treatment output, its regulatory and technical scope may be very different.
That distinction should be made before the team chooses a vendor, writes a specification or promises a launch date.
What can a medical device companion app do?
The phrase sounds specific, but it is used for everything from a digital instruction booklet to software that directly changes how a regulated device operates.
| App role | What it may do | Why the distinction matters |
|---|---|---|
| Support companion | Onboarding, instructions, reminders, FAQs, contact details and routine education | Usually lower technical complexity, although claims and data handling still need review |
| Tracking companion | Device-use diary, symptoms, comfort, adherence, photos, measurements and patient-reported outcomes | Requires a clear protocol or program workflow, usable data and assigned review responsibilities |
| Connected companion | Receives device data, shows device status, synchronizes measurements or supports troubleshooting | Connectivity, data integrity, cybersecurity and failure handling become central |
| Control or analysis function | Changes device settings, controls operation, analyzes device data or provides patient-specific directives | May be a device software function and may be within the focus of FDA oversight |
A project can contain more than one role. The problem starts when the team describes all four as "the app" and assumes they have the same evidence, testing and release requirements.
Follow the patient from the box to the follow-up visit
The most useful product workshop is not a tour of possible features. It is a walk through what the intended user does from the moment the device arrives.
Before first use
The person may need to confirm eligibility, create an account, understand what the device is for, review warnings, prepare the device and know when not to use it. A caregiver may be involved. A clinic may have already enrolled the user, or the app may need to link the person to a study or program.
During first use
The app may explain setup, show a short sequence, confirm that a step was completed and make support easy to reach. This is where a technically correct workflow can still fail if the wording is unclear or the user cannot tell whether the device is ready.
Between uses
The person may need reminders, a treatment or device-use log, symptom tracking, a comfort score, a short questionnaire, cleaning instructions or a record of consumables. The app should ask only for information that the program will use.
When something goes wrong
The app needs a defined response to missed use, pairing failures, unexpected readings, discomfort, damage and possible adverse events. "Send an alert" is not a complete workflow. Somebody must know who receives it, when it is reviewed and what the user is told to do in the meantime.
At follow-up
The useful output may be a simple timeline: when the device was used, what the patient reported, what changed and which entries were missing. The clinician or research team should not have to reconstruct three months of use from screenshots and support emails.
What data should a medical device companion app collect?
A companion app makes it tempting to collect everything. More data can also mean more participant burden, more review work and more ambiguity about what the organization is responsible for monitoring.
A focused home-use or device-study workflow may include:
- date, time and duration of device use;
- completion or non-completion of the planned session;
- comfort, tolerability or ease-of-use ratings;
- symptoms before and after use;
- functional or quality-of-life measures;
- photos when the protocol or care workflow requires them;
- device status or measurements received through an agreed integration;
- reasons for missed or interrupted use; and
- free text for information that does not fit the structured fields.
The app should also distinguish a normal result from no result. A missing diary entry is not a symptom score of zero, and a failed device sync is not proof that the device was not used.
Build, white-label, use ePRO or start with a portal?
| Approach | Often a reasonable fit when | Main trade-off |
|---|---|---|
| Forms or lightweight portal | The pilot is short and needs only occasional reporting or support | Recurring engagement, reminders, longitudinal context and device integration remain limited |
| Focused ePRO or electronic diary | The main requirement is scheduled patient-reported data for a study or follow-up program | May not provide the broader branded product experience or device-support workflow |
| White-label patient companion app | The company needs its own brand, recurring tracking and a maintained mobile foundation | The project must work within real configuration boundaries and scope custom integrations separately |
| Fully custom app | The app experience, device connection or algorithm is central to the product's IP | The manufacturer owns engineering, validation, security, releases, support and lifecycle maintenance |
| Device SDK inside an existing app | The company already has a stable patient app and only needs device connectivity | An SDK does not solve onboarding, reminders, reporting, support or study operations by itself |
A medical-device startup does not need to prove its ambition by rebuilding every common mobile feature. It does need to identify the functions that are inseparable from the device and keep appropriate control of them.
When does a companion app become part of a medical device?
The FDA's approach is function-specific. It does not depend only on whether the software runs on a phone or whether the team calls it a companion app.
FDA guidance identifies software functions that control a connected medical device or analyze medical-device data as functions that may be the focus of device oversight. Patient-specific analysis that produces directives for diagnosis, treatment, mitigation or prevention can also carry a different regulatory scope from a simple diary or reminder. Review Step 7 of the FDA Digital Health Policy Navigator.
Practical boundary: recording that a person used a device is not the same function as controlling the device. Displaying a patient-entered comfort score is not the same function as analyzing a device signal and directing treatment. Scope each function separately.
Manufacturers should involve regulatory and quality teams before the technical architecture is fixed. Waiting until store submission to decide whether a feature belongs inside the regulated product boundary is an expensive way to answer the question.
The phone screen is part of the user experience
For a home-use device, the user interface is not limited to the buttons and display on the hardware. It may also include the app, packaging, instructions and training materials the person relies on to prepare, operate and maintain the product.
FDA's August 2026 human-factors guidance focuses on reducing use-related risk and confirming that intended users can use a device safely and effectively in the intended environment. That makes the companion workflow relevant to human-factors planning when it contributes to setup, operation, feedback or maintenance. Read the FDA guidance on human factors and usability engineering.
A polished screen is not enough. The team needs to observe whether users understand the state of the device, recover from common errors and know when they need help.
Connectivity creates a lifecycle, not a one-time integration
A Bluetooth proof of concept is not the same thing as a supported connected product.
The release plan should account for pairing, reconnection, duplicate or delayed records, phone replacement, background permissions, operating-system updates, device firmware, time zones, offline use and what happens when the app and device disagree.
Cybersecurity scope also depends on the product. FDA's February 2026 final guidance addresses cybersecurity design, labeling and recommended premarket documentation for devices with cybersecurity risk, including obligations that may apply to cyber devices under section 524B of the FD&C Act. Review the FDA medical-device cybersecurity guidance.
A vendor can provide secure product infrastructure, but the manufacturer still needs to determine the regulatory boundary, threat model, update responsibilities and evidence required for the intended product.
Research and post-launch programs need different wording
A feasibility study may ask participants to complete a daily diary. A commercial support program may ask customers about device use and comfort. A regulated clinical investigation may use an outcome measure to support a specific endpoint.
The screens may look similar, but the protocol, consent, data controls, review process and claims are not interchangeable.
FDA's final guidance on digital health technologies for remote data acquisition discusses the use of hardware and software to collect data remotely in clinical investigations, including considerations such as selection, validation, usability, risk and data management. Read the FDA guidance on remote data acquisition in clinical investigations.
The app should say what is being monitored and what is not. A daily diary does not create continuous clinical supervision unless a staffed service is genuinely reviewing it that way.
For patients or study participants who find this article: a companion app may help you set up a device, remember planned use, record symptoms or share information with a program. It should clearly explain who receives your information, how quickly anyone reviews it and what to do when you need urgent help.
Keep AI behind a clearly defined task
AI can help organize support requests, summarize a longitudinal diary for human review, classify free text or identify incomplete records. Those are different uses from interpreting device signals or directing treatment.
The manufacturer and software partner should agree on the exact function, input data, output, limitations, monitoring and responsible reviewer. "Add AI" is not a product requirement.
If the output changes what a patient or clinician is expected to do, the intended use and risk analysis need to reflect that function rather than the marketing label placed around it.
What to settle before choosing a platform
| Decision | Questions the team should answer |
|---|---|
| Intended users and environment | Patient, caregiver or clinician? Home, clinic or study site? What accessibility or language needs apply? |
| App function | Support, diary, data display, device connection, control, analysis or a combination? |
| Device boundary | Which software functions are part of the regulated product, and which are separate support functions? |
| Patient workflow | What happens at setup, first use, recurring use, failure, support and follow-up? |
| Data collection | Which fields inform a defined decision, endpoint, service or product-learning question? |
| Connectivity | How does the device communicate, what is authoritative and how are delayed, duplicate or missing records handled? |
| Review and escalation | Who sees patient-reported concerns, within what time frame, and what is the participant told? |
| Integration | Is a CSV export enough, or is ongoing API, FHIR, EDC or device-cloud synchronization required? |
| Quality and evidence | What usability, validation, cybersecurity and regulatory documentation is required? |
| Ownership and support | Who owns store accounts, signing keys, support, releases, patches and continuity if the partnership ends? |
Where might CareClinic fit in a medical device companion app?
CareClinic is an established patient-facing platform for longitudinal health tracking rather than a device-control SDK. It already supports common companion workflows such as symptoms, medications, measurements, mood, sleep, activity, journals, assessments, reminders, care plans, reports and configurable sharing.
For a medical-device company, that can provide a starting point for a pilot, device-use diary, patient-reported outcome workflow, support program or branded companion experience.
Device connectivity is scoped separately. A project that needs Bluetooth communication, a device-cloud integration, device control, signal analysis or regulated patient-specific output should not assume those functions are included simply because the patient app exists.
CareClinic's white-label model can cover app identity, selected tracking areas, onboarding, program content and organization-facing workflows. Configuration, integration and genuinely custom development should be separated in the implementation scope.
For a study whose primary requirement is a recurring participant diary, see Electronic Patient Diary Software Beyond Traditional ePRO .
Related CareClinic guides
- Before You Build the Patient App
- Electronic patient diary software beyond traditional ePRO
- Health diary for recurring patient records
Start with the device workflow
Tell the CareClinic team what the device does, who uses it, what the app needs to collect, whether it connects to the device, what staff must review and where the resulting data needs to go.
Discuss a Medical Device Companion App
Choose OEM or White Label for a branded patient experience. Choose Patient Reported Outcomes (ePRO) when the main requirement is a clinical-study diary or assessment workflow. Do not include patient information in the inquiry.
Frequently asked questions
What is a medical device companion app?
It is a mobile or web application used alongside a medical device. Depending on its intended function, it may provide onboarding, reminders, educational content, device-use tracking, patient-reported outcomes, device data, troubleshooting, control or analysis.
Does every medical device need a companion app?
No. A companion app is useful when it improves a defined user or operational workflow. A device that is simple to use and requires no recurring digital interaction may not benefit from adding an app.
Is a companion app automatically a medical device?
No. Regulatory status depends on each software function's intended use. Software that controls a device, analyzes device data or provides patient-specific directives may have a different scope from software that provides general education, reminders or simple recordkeeping.
Can a companion app collect patient-reported outcomes?
Yes. It can collect symptoms, comfort, function, quality of life, adherence and other patient-reported information. The measure, schedule, review process and intended use should be defined before collection begins.
Can CareClinic connect directly to our medical device?
Device connectivity is evaluated project by project. The required protocol, SDK or cloud API, data ownership, failure handling, cybersecurity and regulatory boundary must be reviewed before the integration is scoped.
Can we use CareClinic before commissioning a branded app?
Yes. A smaller team can begin with the existing CareClinic app for a focused pilot or workflow evaluation, then use what it learns to decide whether a white-label deployment is justified.
What is the difference between a companion app and ePRO?
ePRO focuses on collecting outcomes reported directly by participants. A companion app can include ePRO while also providing onboarding, reminders, product support, education, device status, care-plan tasks or other recurring functions.
Who is responsible for monitoring patient entries?
The program must define that responsibility. The app should not imply that a clinician or safety team is continuously monitoring entries unless the service is actually staffed and operated that way.
How long does a medical device companion app take to launch?
Timing depends on the intended functions, branding, content, device integration, app-store readiness, usability work, validation, cybersecurity, languages and regulatory scope. A credible plan is based on the agreed functions rather than one universal timeline.
Educational information only. This article is not regulatory, legal, clinical, quality, cybersecurity or medical-device advice. Manufacturers and research organizations should assess their intended use, device classification, quality system, jurisdictions, data flows and evidence requirements with the appropriate professional advisers.
