Clinical workflow analysis: A framework for Medical Devices to identify the fit for the digital component

Medical device OEMs know precisely what their hardware measures but telemetry tells you what the device did, not what happened to the patient. And a signal that only reports on the hardware is easily replicated, which is how clinically valuable devices slide into commodity competition. What lifts a device above that is a digital component fitted into the real clinical workflow. When software closes a gap clinicians feel every day — a break in visibility, adherence, or coordination — the device stops being one interchangeable option and becomes something the care team relies on. That fit is what makes a device indispensable. But it begins with a diagnostic question, not a feature: is a digital component genuinely necessary here, and where exactly does it belong? This article walks through how to answer that before any development commitment is made.

Clinical workflow analysis helps OEMs look beyond the intended care pathway to understand how care is actually delivered across clinical and home environments. It examines the people, processes, behaviors, systems, and handoffs that shape whether a device or digital solution will be adopted and used effectively.

For medical device OEMs, the primary challenge is therefore often not what to build, but where a digital component should fit within the wider clinical workflow. As connected devices, medical device companion apps, and software as a medical device (SaMD) products become more prevalent, teams that focus only on features risk adding complexity rather than value.

Success requires an understanding of the care pathway, patient and clinician needs, operating model, regulatory requirements and commercial strategy before any features are designed.

Workflow analysis is often viewed as an implementation step, conducted after vendor selection or SaMD product concept development. This approach is too late. The Agency for Healthcare Research and Quality’s (AHRQ) Workflow Assessment for Health IT Toolkit recommends integrating workflow assessment into planning, design, implementation, and use, highlighting its impact on both clinical and administrative workflows.

 Standard operating procedures describe the intended pathway, not the real environment. Patient real life outside of a controlled environment includes workarounds, missing steps, environmental constraints, and changes that don’t appear in the ideal model. – Pavel Kyrylchenko, Senior Product Manager at Star

For OEMs, workflow analysis should happen upstream, during strategy and product definition. This early-stage approach helps teams identify where digital solutions can truly enhance care delivery and where they may risk becoming disconnected.

This guide outlines Star’s clinical workflow analysis framework for medical device OEMs, helping teams determine where a digital component fits, when it should be implemented, and what roles it should serve within a regulated healthcare ecosystem.

Step 1: Frame the care and business context

Effective workflow analysis begins before considering solutions. Your first step is to clearly define the problem space, including the indication, care model, target population, care settings, stakeholders, and commercial context.

Clinical pathway documents are valuable but often do not reflect the full reality of care delivery. They outline intended processes, but typically omit local workarounds, missing steps, parallel communications, staffing constraints, and environmental limitations that influence real-world practice.

This is particularly relevant for device-led care in the home. Factors such as home environment, caregiver support, connectivity, storage, fatigue, health literacy, and daily routines all change what is realistic to expect from users. The U.S. Food and Drug Administration (FDA) human factors guidance reinforces this point: medical device digital health workflows should be designed for intended users, uses, and use environments, not just ideal clinical conditions.

 What looks clinically reasonable in an intended-use statement may still be unrealistic in daily life. – Pavel Kyrylchenko, Senior Product Manager at Star

When a patient goes home, things like school runs, grocery shopping, and other daily obligations are added to the mix. Life can be distracting. A workflow that looks manageable in a clinical model may be difficult to sustain in real life.

At this stage in the process, the goal is to define the:

• Indication and care model
• Target population and key segments
• Care settings and transitions
• Stakeholders involved in delivery, support, and escalation
• Business model and route to market
• Strategic hypothesis for digital value

This approach prevents premature SaMD product development and ensures alignment with clinical, operational, and commercial realities.

Step 2: Map the real workflow

Once the context is clearly established, begin mapping actual processes across the full ecosystem.

For teams working on SaMD workflow mapping for patient and clinician adoption, this means looking beyond product use alone to understand training, monitoring, adherence, documentation, escalation, and support. A comprehensive clinical workflow map should include the patient and caregiver journey, clinician workflow, service and support processes, logistics, onboarding, commercial handoffs, and escalation paths.

Handoffs → Training → Monitoring → Adherence → Documentation → Escalation

The most consequential breakdown in care often appears at transition points:

• From onboarding to routine home use
• From patient to caregiver
• From patient to provider
• From provider to service or support
• From monitoring to action
• From sales promise to post-sale adoption

At these critical handovers, ownership often becomes unclear. Patients may not know when to escalate, and caregivers may assume support roles. Clinicians may receive data without clear action steps, and distributors may sell devices without addressing workflow changes.

 We should not focus only on the visible friction point. We need to trace it backward and understand the sequence of events: who did what, at what time, in which condition and who owned the step.  – Pavel Kyrylchenko, Senior Product Manager at Star

OEMs often overlook these gaps when relying solely on study data, adverse events, complaint data, or distributor feedback. While these sources provide valuable insights, they often don't reveal setup friction, training decay, routine non-adherence, workaround behaviors, delayed escalation, or caregiver substitution.

A strong workflow map should document:

• Actors and roles
• Tasks and decisions
• Handoffs and escalation points
• Tools, systems, and information objects
• Time, place, and environment of use
• Workarounds, delays, and duplications

This step creates a current-state view of care delivery and identifies where the product, service, or digital component should intervene.

Step 3: Diagnose the root causes

Mapping the clinical workflow is an important exercise, but it is not enough on its own. The next step is to understand which gaps are symptoms of an issue and which are root causes.

A visible friction point may not be the true cause of poor performance. For example, low engagement with medical device companion apps may appear to be a UX issue, but the underlying cause could be weak onboarding, unclear patient value, limited clinician endorsement, or a support model that does not reinforce use after setup.

The same principle applies to clinician-facing tools. Alert fatigue may appear to be a notification design problem, but the deeper issue could be unclear ownership, ineffective triage logic, or workflows that add review tasks without reducing workload elsewhere.

At this stage, OEMs should work on diagnosing failure types, including gaps in visibility, adherence or execution, coordination and handoff, confidence and education, delayed response, documentation and traceability, incentive and ownership, and staffing or process.

This diagnosis also helps separate product gaps from process, staffing, channel or service-model gaps. The World Health Organization’s (WHO) digital health guidance makes the broader principle clear: digital health interventions are not a substitute for functioning health systems.

 A digital component can strengthen healthcare delivery, but it should not be treated as the cure for a weak operational model.  – Pavel Kyrylchenko, Senior Product Manager at Star

A good root-cause diagnosis should produce:

• A root-cause map
• A failure mode or friction map
• A digital-solvable vs. non-digital classification
• Prioritized problem statements

This step helps teams decide whether software is actually the right response, or whether the answer is training, process redesign, support redesign, channel enablement, or a different commercial model.

Step 4: Test digital fit and solution feasibility

Not every workflow problem requires a digital component. An appropriate digital candidate is repeatable, observable, time-sensitive, and linked to a controllable behavior or decision point.

Criteria for digital fit:

Workflow alignment → Data availability → User readiness → Ownership clarity → Regulatory/evidence feasibility

The problem should have a clear owner, integrate with existing workflows, and deliver measurable clinical, operational, or commercial value. If nobody owns the signal or the action it triggers, the digital product quickly becomes ineffective. In fact, it failed at the design stage.

Digital fit should be tested across several dimensions:

• Clinical value
• User value and behavior fit
• Workflow fit
• Data availability and interoperability
• Technical feasibility
• Evidence and regulatory fit
• Business and reimbursement fit
• Implementation and support fit

Weak workflow alignment and unclear ownership are common reasons for poor digital fit. Data availability and regulatory and evidence requirements also frequently present challenges, particularly when teams assume integration, validation, or proof can be addressed later.

Clinician burden is a critical consideration. A digital solution should not shift work elsewhere. Assess who receives the signal, what action it triggers, whether it replaces existing effort, and whether triage logic reduces low-value touches.

 If notifications, alerts, documentation, and triage time keep increasing, the product is not reducing burden. We need to look for workflow simplification.  – Pavel Kyrylchenko, Senior Product Manager at Star

Discovering evidence, usability, interoperability, or regulatory constraints late can force redesigns. These can affect scope, claims, architecture, validation, launch timing, and commercial assumptions. Therefore, digital fit should be assessed before finalizing the solution roadmap.

Step 5: Define the roles of the digital component

Once digital fit is confirmed, the next step is to define the combination of roles the component should fulfill and the boundaries around each one.

 At Star, we do not start with feature design. We start with the workflow failure we need to fix. – Pavel Kyrylchenko, Senior Product Manager at Star

A digital component may fulfill several roles at the same time. The right combination should be shaped by the workflow failures and goals identified during the analysis. For example, one solution may combine monitoring to address visibility gaps, coaching to improve execution, and triage to support faster intervention.

Common digital roles include:

• Monitoring
• Coaching and education
• Adherence support
• Symptom tracking
• Decision support
• Triage and escalation
• Communication and coordination
• Documentation and traceability
• Service orchestration

The objective is not to select one role from this list. It is to determine which roles are needed, how they interact, and which users, decisions, and workflow failures each one supports.

For every role, teams should define:

• The workflow failure or the goal it addresses
• The user or stakeholder it serves
• The information or action it provides
• Who owns the resulting signal, decision, or handoff
• The data, systems, and services it depends on
• The measurable outcome it should influence

The combination of roles has important implications for infrastructure and operations. A component that provides education and adherence support may require relatively simple infrastructure. Adding continuous monitoring, clinician coordination, or triage introduces further requirements around reliable data capture, interoperability, response protocols and service ownership. Advanced decision support and closed-loop capabilities typically require an even stronger evidence base and clearer controls.

The most demanding role – and the way the roles interact – will often determine the component’s wider technical, workflow, and service requirements. Teams may therefore need to introduce capabilities in stages. Coaching, education, or structured symptom capture might be implemented first, while monitoring, triage, or decision support is added as the data foundation, evidence, and operating model mature.

This sequencing helps determine what can be built immediately, what depends on ecosystem readiness, and what should be deferred. It also prevents teams from launching a multi-role component without the infrastructure or service model required to support it.

The full combination of roles also shapes intended use, claims, validation, and regulatory burden. FDA guidance on clinical decision support software shows how intended function and the degree of influence on clinical decision-making can affect oversight expectations.

A component that only supports general education or behavior change differs significantly from one that also identifies risk, recommends action, or influences triage and treatment decisions. Defining the complete role composition and its boundaries early helps prevent unexpected regulatory, technical, and delivery challenges.

Step 6: Make it work commercially and operationally

A digital component may be technically feasible yet still fail in the market.

For OEMs, commercial viability requires more than product-market fit. The product must be purchased, sold, onboarded, supported, and its value demonstrated. Many digital extensions of hardware products struggle at this stage.

 Very simply, someone must pay, someone must sell, someone must onboard, someone must support, and someone must own the lifecycle.  – Pavel Kyrylchenko, Senior Product Manager at Star

Once the digital component moves from concept to commercial offer, OEMs need to plan how it will be sold, onboarded, and supported through existing channels. Sales teams often need to transition from feature-based selling to emphasizing workflow value and outcomes. Distributor and provider channels may require updated messaging, qualification criteria, objection handling, and incentives. Support teams may need revised onboarding processes, usage monitoring, and escalation protocols.

The most common failure points include:

• No clear owner for the digital offer
• Weak value messaging
• Poor onboarding
• Low channel incentive alignment
• Support burden that was underestimated
• Mismatch between the digital promise and field reality

Distributors may excel at selling hardware, but digital health often requires them to promote workflow change, evidence, service adoption, and ongoing value. Without proper enablement, even strong concepts may stall.

Monetization requires careful planning. Some components should be monetized directly through subscriptions, licensing, usage-based models, or reimbursement pathways. Others may be more effective as adoption levers, retention tools, clinical differentiators, service enablers, or strategic advantages.

The optimal model depends on channel maturity, strength of evidence, support requirements, and the centrality of the digital component to the overall product offering.

How to turn the analysis into an actionable roadmap

Workflow analysis should not remain a static research report. It should serve as a decision package for product, clinical, regulatory, commercial, and delivery teams.

At a minimum, a useful clinical workflow analysis should produce:

• Current-state workflow maps
• Patient and caregiver journey maps
• Ecosystem actor maps
• Root-cause and risk maps
• Prioritized use cases
• Digital-fit decisions
• Role definitions and boundaries
• Dependency lists
• Implementation roadmap
• KPI framework
• Evidence roadmap

These outputs should be clearly connected. Journey maps illustrate the experience, workflow maps detail the work, and risk maps identify failure modes. Prioritized use cases justify intervention, the digital-fit scorecard determines software involvement, and the roadmap assigns ownership, dependencies, evidence requirements, and measurable outcomes. Together, these outputs show how to decide where a digital component fits in care delivery, which dependencies must be addressed first, and which outcomes the product should be measured against.

KPIs should encompass both leading and lagging indicators. Leading indicators may include onboarding completion, adherence, escalation timeliness, workflow completion, clinician acceptance, and support burden. Lagging indicators may include clinical outcomes, retention, account expansion, reduced service costs, or improved adoption.

Early signals are particularly important. Metrics such as fewer missed steps, faster escalation, clearer handoffs, increased confidence, and improved signal quality indicate whether the digital role is enhancing the intended control point.

 The less friction we have at the target control points, the better. Fewer missed steps, clearer handoffs, better signal quality, and faster escalation show the component is working.  – Pavel Kyrylchenko, Senior Product Manager at Star

Building digital components that fit care delivery

The most effective digital components are designed to fit seamlessly into workflows, rather than focusing solely on features.

For medical device OEMs, this requires evaluating clinical, patient, caregiver, operational, data, regulatory, commercial, and change-management factors before finalizing a product concept. Star’s clinical workflow analysis framework clarifies where digital should fit, its intended functions, limitations, and the conditions necessary for success.

FAQ's