Because of their intricate connections, medical technology products are getting more and more complex. Future MedTech systems, like autoinjectors, will not only inject drugs, but also collect vital health data to ensure patient safety. Despite this complexity, users desire intuitive and user-friendly devices for self-administered injections. Balancing product complexity from an engineering perspective with user-friendly simplicity is crucial. In the MedTech industry, a range of expertise converges, from product strategy to engineering, to achieve regulatory approval.
Design thinking emphasizes human-centered design, while systems engineering focuses on a systemic approach to product development. For MedTech combination products, integrating DT and SE can be a big help. This research aims to define the advantages of applying DT and SE in the MedTech industry and proposes a framework for new product concept development. The paper also discusses the definition of a combination product in the context of MedTech advanced drug delivery systems and outlines the research methodology and key sections.
Development of Medtech combination products
Specifically, this paper focuses on medical auto injectors, which the FDA categorizes as drug/device combination products. A combination product, as defined by the FDA, is a fusion of drug and device, biological product and device, drug and biological product, or all three. MedTech combination products require the coordination of two distinct new product development processes: the drug NPD process and the device NPD process.
In a business-to-business context, pharmaceutical and
MedTech device manufacturers must work concurrently without direct communication, posing challenges for device manufacturers to anticipate both pharmaceutical company market needs and indirect end-user requirements. Manufacturers of class II or class III medical devices are mandated to establish procedures ensuring that design requirements are met, encompassing design controls to ensure safety and efficacy.
Table 1. NPD Processes for Pharmaceuticals and Devices in MedTech
Sample SysML-based Activity Diagram Code:
@startuml
package "MedTech Product Concept Development" {
activity "Market Research" as MR
activity "Conceptualization" as Concept
activity "Prototyping" as Prototype
activity "Clinical Trials" as Trials
activity "Regulatory Approval" as Approval
MR --> Concept
Concept --> Prototype
Prototype --> Trials
Trials --> Approval
}
@enduml
This example demonstrates the structure of the product concept development process in the MedTech industry using a SysML-based activity diagram.
Model of research
The initial research step involves a focused literature review on topics such as Human-Centered Design in the MedTech industry, Design Thinking implementation within the IDEO approach, and the enhanced value Systems Engineering brings when integrated with DT. The objective is to pinpoint relevant methods and tools that balance creativity and guide the innovative process with a systemic approach.
This balance is crucial for innovative products like medical autoinjectors, where simplicity and user-friendliness are key for patients, yet intricate design is essential for effective hardware-software integration. MedTech device manufacturers face added complexity in meeting the requirements of both pharmaceutical companies (B2B) and end-users. The second step involves constructing a SysML-based activity diagram to establish a product concept development framework for MedTech combination products. The framework can be viewed through various lenses, including core decisions, design steps, essential DT and SE tools, and critical design/business reviews influencing investment decisions in a particular MedTech solution.
Development process for Medtech combination products
In this section, we propose a new product concept development framework for MedTech combination products (Figure 1) based on a parsimonious integration of SE, DT, and agile design principles. The proposed framework is detailed, particularly the activities and core decisions made during MedTech product development. Secondly, participatory techniques of the DT toolbox are mapped – i.e. the HOW – with the activities of the process – i.e. the WHAT.
Developing a MedTech combo product concurrently and integrated
Developing a MedTech combination product involves simultaneously developing the device, packaging, and usage instructions. Both the device and drug development processes are regulated by authorities like the US FDA or the European Medicines Agency. The drug development process involves stages like discovery, preclinical research, clinical research, FDA review, and post-market safety monitoring.
In drug development, the exact properties needed for a drug delivery device may not be known until the clinical research phase, necessitating a minimum viable product at that stage. Collaboration between the pharmaceutical company and the device manufacturer is crucial for successful co-development, considering factors impacting drug delivery and device manufacturing. The co-development process begins when a business deal is made between the pharmaceutical company and the device manufacturer, requiring a proactive design strategy to engage agility in modular product concepts.
The initial phases of the proposed framework focus on product strategy and product concept definition, where core decisions are made that influence partnership establishment. This systematic approach leverages Systems Engineering and Model-Based Systems Engineering capabilities to track and store these vital decisions and rationale during MedTech product concept development.
Process for defining product strategy
The product strategy definition process involves key decision-makers within the MedTech device manufacturer, including funding sponsors, corporate executives, marketing managers, and product visionaries. It begins with capturing the broad yet solvable product-related problem (activity 1) and defining the business opportunity and market context (activity 2).
Evaluating problem resolution and setting quantitative business objectives and success metrics (activities 3 and 4) follow. Formulating the intended use (activity 5) provides a concise vision statement aligned with stakeholders' needs and regulatory exploration. Identifying and analyzing major business risks (activity 6) and defining product life cycle stages (activity 7) are crucial steps. Stakeholder definition (activity 8) positions the product in the business environment.
Iteration is common in these activities. Transitioning data from strategy to engineering-oriented product information is facilitated by a system architect. The product strategy team, including high-level executives, ensures alignment with corporate goals. This critical process sets the stage for further development, stored systematically or in a design backlog (Figure 1). Outputs provide a shared understanding of core information, from patient demographics to product use specifics. Notably, the device manufacturer does not have a customer to consult with at this early development stage, distinguishing it from traditional B2B or B2C businesses.
Process for defining a product concept
Product concept development begins by identifying needs (activity 9) shaped by the product strategy. Each product lifecycle stage involves different stakeholders with unique needs (activities 9 and 11). Neglecting a stage can result in unmet needs. The system's environment is defined for each stage, encompassing all external entities interacting with the system-of-interest (SOI).
Entities can either get services from the system or impose constraints. Stakeholder influence guides prioritization, and extreme users and stakeholders are mapped for resolving conflicts. The system architect plays a crucial role, defining the product context by establishing external interfaces between entities and the SOI. Customer journey analysis, storytelling, interviews, and operational scenarios are all good methods for understanding needs.
Needs are services to stakeholders or constraints from external entities. Recording needs should note priority and rationale, and stakeholder ranking helps in case of conflicts. Validated needs (activity 10) inform system requirements (activity 11), which are transformed into "shall" statements. System requirements validation (activity 12) ensures correctness, completeness, and environmental assumptions. MedTech manufacturers' needs and requirements are likely partially validated without receiving requests.
Main functional system requirements guide MVP (activities 13 and 14) design. MVP concept design verification (activity 15) aligns with system requirements, and MVP validation (activity 16) ensures stakeholder needs are met. Selected MVPs undergo a trade-off session (activity 17) and a technical review with pharmaceutical companies (decision point 5). Any misalignment prompts reevaluation and new MVP development.
If MVPs align, a business review (decision point 6) negotiates conditions, determining the next steps in the product planning process. A project manager, a system architect (Core Team Leader), and representatives from various functions make up the product concept development team.
This study emphasizes the need for MedTech products to maintain simplicity and user-friendliness despite increasing complexity. The challenge arises from aligning product features with pharma companies' needs (direct customers) while ensuring usability for end-users like patients, pharmacists, and healthcare practitioners.
Design Thinking (DT) and Systems Engineering (SE) approaches are required to address these challenges. The proposed framework for MedTech combination product development is illustrated in an activity diagram, revealing key insights. It advocates for a shift from the traditional stage-gate approach to a more iterative, agile-based method, extending the innovation phase to the product strategy level. The diagram emphasizes the importance of involving the system architect from the product concept team in high-level product strategy meetings to ensure traceability and informed decision-making throughout the development phases.
It combines SE and DT elements to facilitate creativity in early MedTech product development phases while maintaining a systemic approach to data preservation, knowledge reuse, and management. Unlike unstructured creative methods that require multiple frameworks or post-its, the framework tracks decisions, their makers, and their impact on subsequent processes in one diagram. Future work should enhance the framework by incorporating additional processes like safety and detailed design stages and integrating it with domain design activities.
Articulating the system development process with drug development allows co-development activities and design reviews with pharmaceutical company representatives. Validating new drug delivery systems and proving compliance and generalizability requires active involvement of pharmaceutical companies. Implementing this framework using a Model-Based Systems Engineering (MBSE) approach will involve defining a modeling method to structure SE outcomes supported by DT workshops. It's also important to define metrics to evaluate the framework's impact compared to current practices before applying it to existing or future industrial advanced drug delivery systems.
Top comments (0)