The paper shows that a medical device digital twin becomes more useful when it is not treated as a standalone simulation. Its value comes from being embedded in a traceable MBSE architecture that connects stakeholder needs, system requirements, subsystem behavior, verification evidence, and risk-informed design decisions.
Why this paper matters
Medical device development is still heavily constrained by serial physical prototyping. That matters because each prototype loop can delay technical evidence, verification, validation, and ultimately regulatory submission, especially for Class II and higher devices.
This paper proposes a model-based systems engineering framework that integrates digital twin capabilities into medical device innovation. The case study is a capsule-based biomedical delivery system called Stela. The authors use it to show how a requirements architecture can be connected to CAD geometry, analytical modeling, finite element simulation, empirical testing, and verification artifacts.
The important point is not simply that the team ran simulations. The important point is that the simulations were made traceable to stakeholder needs and system requirements, so design decisions could be interpreted as evidence against clinical, mechanical, and regulatory intent.
Figure 1. The structure of the highest order diagram for a Medical Delivery System (Stela).
The framework: a traceable engineering backbone
The framework starts with a classic systems engineering move: identify stakeholder needs across multiple departments, not only engineering. The paper explicitly includes R&D, engineering, finance, marketing, production, manufacturing, regulatory, and logistics perspectives. This is crucial in medical devices because safety, usability, manufacturability, business constraints, and regulatory evidence cannot be bolted on after the design has stabilized.
The authors structure the model using Magic Grid V2 in CATIA Magic Cyber Systems Engineer. The top-level architecture moves from stakeholder needs and system context into use cases, conceptual decomposition, functional analysis, requirements, parameters, implementation requirements, and verification. In other words, the model is intended to preserve line-of-sight from intent to evidence.
Figure 2. SysML use case diagram representing the primary system interaction for delivery of medical grade material.
Figure 3. SysML activity diagram illustrating the sequence of actions and allocation of responsibilities across clinician, capsule system and patient during the delivery of medical grade material, from initial actuation through to material extrusion and clinical application.
From use case to functions, requirements, and critical interfaces
The selected use case is controlled delivery of medical-grade material from a capsule system to a patient. On the surface, this sounds straightforward: the clinician actuates the device, the material moves through the capsule, and the patient receives the material. But the paper shows that this simple clinical scenario decomposes into several interacting physical behaviors.
Two domains dominate the use case: structural behavior and fluidic behavior. The structural domain governs whether the capsule body and nozzle interface can withstand the load without separation or leakage. The fluidic domain governs the pressure and flow behavior of the medical-grade material during extrusion.
For the validation use case, the authors deliberately scope the digital twin to the structural domain, especially the annular snap-fit interface between the body and nozzle. This is a good methodological choice: it keeps the demonstration focused while still tying the analysis back to clinically meaningful device performance.
Figure 4. Detailed SysML activity diagram illustrating functional allocation across physical subsystems and interfaces, capturing internal system interactions during delivery of medical grade material, with emphasis on force transmission, interface behavior and structural load resistance.
Figure 5. Traceable functional breakdown of the primary system function “Deliver Medical Grade Material” derived from the SysML activity model.
Figure 6. Conceptual system decomposition of the capsule-based biomedical delivery system, illustrating subsystem elements, component hierarchy and critical interfaces, including the annular snap fit joint governing structural interaction between two system components.
Key quantitative results
Result area | Finding | Why it matters |
Traceability | 275 relationships linked stakeholder needs to system requirements. | The framework creates a dense dependency structure rather than isolated one-to-one documentation links. |
Problem-domain prioritization | 47 relationships connected mechanical performance to the problem domain: 27 structural and 20 fluidic. | This justified selecting the structural interface as the first digital twin use case. |
Digital twin calibration | Model error relative to empirical data was reduced from about 30% to within experimental repeatability. | The digital twin became credible enough for design assessment, not just visualization. |
Structural improvement | Interface performance improved by about 70%; peak strain increased from 7.5% to 10%; minimum FoS decreased from about 2 to 1.2 but stayed at the threshold. | The design used more of the available mechanical envelope while maintaining defined structural acceptability. |
Prototype-cycle compression | The MBSE-digital twin workflow totaled about 30 hours of active task time, compared with a 19-week prototype-cycle benchmark. | The acceleration is indicative, not a direct elapsed-time forecast, but it shows the potential scale of iteration compression. |
Scaled development impact | The simplified analysis reduces five-cycle prototyping burden from about 2.5 years to about 0.6 years; overall development could fall from roughly 3.5 to 1.5 years if non-prototyping activities remain unchanged. | The benefit is not just faster simulation; it is a better development architecture. |
What makes the digital twin useful
The structural digital twin is not a continuously synchronized operational twin. The capsule does not contain embedded sensors. Instead, the paper implements an event-based design and verification twin: empirical data, material properties, CAD geometry, analytical calculations, finite element results, and verification outputs are connected through the MBSE framework.
This matters because many “digital twin” claims in engineering collapse into disconnected simulations. Here, the twin is valuable because each result is interpretable as model-based evidence against a requirement or measure of effectiveness. Mating force, peak strain, and factor of safety are not just simulation outputs; they are linked indicators of structural integrity for the clinical use case.
Figure 7. Implementation architecture of the structural digital twin within the MBSE framework, integrating CAD geometry, analytical modelling, FEM and empirical testing through the MBSE environment as a central coordination layer.
Figure 8. MBSE traceability matrix linking stakeholder needs to system requirements for the Stela capsule-based biomedical delivery system.
Figure 9. Hierarchical MBSE traceability diagram linking stakeholder needs to system, sub-system and implementation requirements for the Stela capsule-based biomedical delivery system.
Figure 10. MBSE traceability matrix linking system requirements to sub-systems and components of the Stela capsule-based biomedical delivery system.
The structural result: better interface performance, controlled risk
The core engineering result is a roughly 70% improvement in structural interface performance compared with the baseline design. This was not achieved by simply making the design “stronger” in an unbounded way. Peak strain rose from 7.5% to 10%, and the minimum factor of safety dropped from about 2.0 to 1.2, which was the defined acceptance threshold.
That trade-off is important. It shows controlled use of the available mechanical envelope: higher mating performance, higher strain, lower reserve margin, but still within defined structural limits. From a systems engineering perspective, the design decision is defensible because the trade can be traced to requirements, analysis, and empirical validation.
Figure 11. Relative change in key structural performance metrics following improvement of the Stela capsule-based biomedical delivery system.
The development-speed result: faster loops, not magic
The paper compares the MBSE-digital twin workflow against a literature benchmark of about 19 weeks per prototype cycle. In the case study, the active measured workflow for manufacturing, verification, validation, modeling, and computation totaled about 30 hours. Manufacturing and validation remained the largest contributors, which is exactly what one would expect once digital work begins to compress the modeling and decision loops.
The authors are appropriately cautious: this is not a like-for-like elapsed-time prediction. The 19-week benchmark includes broader hardware-development realities, while the paper’s 30-hour workflow is active task time under specific assumptions. Still, the comparison is useful because it shows where a traceable digital twin workflow can compress iteration burden and shift effort earlier into analytical and computational decision-making.
Figure 12. Time allocation across the validated 3-week prototype cycle used in the MBSE-digital twin workflow.
Figure 13. Reduction in Medical Device Development Time Using the MBSE-Digital Twin Framework.
What MBSE teams should take from it
The paper’s strongest message is that MBSE becomes more powerful when it is connected to executable or evaluative engineering evidence. A requirements model alone can improve clarity. A simulation alone can improve local design understanding. But a traceable MBSE-digital twin framework can connect needs, requirements, subsystem behavior, verification evidence, and regulatory interpretation in one development logic.
This is especially relevant for regulated medical devices. Evidence has to remain connected to intended use, risk controls, and verification logic as the design changes. The framework shows a practical path for doing that: identify the critical use case, decompose it into physical functions, translate those functions into requirements and MoE, evaluate the critical subsystem with analytical and numerical models, validate with empirical testing, and feed the results back into the system model.
For MBSE practitioners outside medical devices, the lesson generalizes. Digital twins should not be side projects. They should be linked behavioral representations of decisions the system model actually needs to make.
Limitations to keep in mind
The demonstrated twin is not a real-time operational twin. It is a validated design and verification twin. That is still valuable, but it should not be oversold as continuous physical-digital synchronization.
The study validates one use case and one structural interface, not a full cradle-to-grave medical device lifecycle. The framework is promising, but broader use cases, fluidic behavior, richer subsystem coverage, automated metrology, faster computation, and more clinical-context validation remain future work.
The time-compression numbers should be read as indicative estimates. The paper makes a strong case for development acceleration, but the exact magnitude will depend on manufacturing route, test automation, model maturity, regulatory pathway, team workflow, and whether empirical data already exists.
Bottom line
This paper is a strong example of MBSE moving beyond architecture diagrams and document traceability. Its contribution is a practical framework in which stakeholder needs, requirements, physical behavior, simulation outputs, empirical evidence, and regulatory intent can be connected. The result is not merely a digital model of a device. It is a decision-making structure for faster and more defensible medical device innovation.
Source
Pinol, T. R., Prentice, L. H., Fox, K., & Pang, T. Y. (2026). A Model Based Systems Engineering Framework for Digital Twins in Medical Device Innovation. Systems Engineering. DOI: 10.1002/sys.70078.
