The problem
The company manufactures a non-invasive wellness device delivered through certified partner clinics, with a take-home version distributed to selected patients. Every part of the operation ran manually: a practitioner connected each patient to the device in person, and there was no software layer between the manufacturer, the clinics and the patients. We were engaged to design the platform that would let the model scale.
Clinics allocated therapy sessions to patients by hand, with no system to enforce session counts or expiry dates.
Take-home devices were distributed to patients with no way to track which unit sat with which patient.
The manufacturer had no central visibility of device activity, session completion or clinic performance across the network.
Patient progress and session outcomes were not captured in any structured form.
There was no mechanism to deactivate a device remotely or transfer it between patients.
What we designed
We designed a three-tier platform separating the manufacturer, the clinic and the patient, each with its own permissions and interface, delivered as a single cross-platform mobile application over a microservices backend. Because clinics would store patient health information, we treated HIPAA as a design constraint from the outset rather than a later addition. We deliberately scoped the partner-app ecosystem into a later phase after establishing it was comparable in size to the core platform itself.
Three-tier permission model
Who can see and do what
Tier 1
Manufacturer
- Network-wide reporting
- Clinic management
- Override any device or session
Tier 2
Clinic
- Allocate sessions with expiry
- Patient profiles
- Usage monitoring
Tier 3
Patient
- Start and pause sessions
- Track progress
- Request more sessions
Administrator console
Network-wide reporting, clinic management, global settings, and override of any device or session
Clinic portal
Session allocation with time-bound expiry, patient profiles, usage monitoring, and follow-up scheduling
Patient application
Session initiation, countdown and pause control, progress tracking, and session requests
Session engine
Allocation, expiry, preset session packages, and override rules
Device management
Unit registration by serial number, patient assignment, status monitoring, custody transfer, and remote deactivation
Notification service
Session reminders, expiry warnings, and approval alerts
How it works
From trigger to result.
How the system works
7 stages
01Clinic portal
TriggerCreates the patient record and allocates a session package with an expiry window.
02Session engine
DataThe single source of truth for what each patient is entitled to.
03Patient app
ResultBiometric login. Shows remaining sessions and expiry.
04Device session
LogicEntitlement validated, then a timed session with pause limits.
05Write-back
LogicBalance decremented, clinic notified, history updated.
06Device management
DataTelemetry, custody transfer and remote deactivation.
07Administrator console
PersonNetwork-wide reporting. Can override any device or session.
A significant part of our work was separating what the device could genuinely support from what the wish list assumed. We flagged that automatic session control over the device depends entirely on the hardware exposing a documented connectivity protocol, and scoped that as a decision point rather than an assumption.
Our approach
How we worked.
Discovery
Mapped the three user tiers, the device layer, and the regulatory boundary between a wellness device and the health data the platform would hold.
Architecture
Designed the microservices backend, session engine and permission model across administrator, clinic and patient roles.
Scope definition
Separated the core platform from the partner-app ecosystem, which we assessed as comparable in size to the core build.
Delivery planning
Defined the roles and skills the build would require.
Risk assessment
Identified device connectivity and EHR integration depth as the two variables that materially change scope.
The outcome
What the client received.
The client received a delivery plan with defined roles and skills.
We identified that device connectivity was the largest unresolved variable and scoped it as a decision point instead of an assumption.
We separated the partner-app ecosystem into a later phase after establishing it was comparable in size to the core platform, preventing significant scope inflation.
We established that the device's wellness classification and the platform's HIPAA obligations are distinct questions, which clarified the compliance scope.
Questions
What people ask.
Does a wellness device platform need to be HIPAA compliant if the device itself is not a regulated medical device?
Usually yes, and the two questions are separate. A device can be classified as a low-risk general wellness product and still sit inside a platform that stores patient names, health notes and treatment history. It is the handling of that health information that triggers HIPAA obligations, not the regulatory classification of the hardware. This is general guidance. Confirm the position for your own product with qualified counsel.
What determines whether an app can control a connected device directly?
It depends entirely on whether the hardware exposes a documented connectivity protocol or SDK. If it does, the app can start sessions, set parameters and read device status. If it does not, the app can still manage entitlements, scheduling and tracking, but the device is operated separately. This is the first question to settle, because it changes both scope and team composition.
What does EHR integration actually involve?
It varies enormously. A generic FHIR export is a contained piece of work. Integrating with a specific electronic health record system involves vendor onboarding, certification and domain-specific data mapping, and is a much larger piece of work. Establishing which of the two is required comes first.