Developing IEC 62304 - Compliant Embedded Software for Medical Devices - MATLAB & Simulink
Video Player is loading.
Current Time 0:00
Duration 42:43
Loaded: 0.09%
Stream Type LIVE
Remaining Time 42:43
 
1x
  • Chapters
  • descriptions off, selected
  • captions off, selected
      Video length is 42:43

      Developing IEC 62304 - Compliant Embedded Software for Medical Devices

      Overview

      Whether you are an embedded software developer or an engineer designing a medical device, software quality is critical for patient safety.

      Model-Based Design incorporates verification and validation into the software development workflow. As a result, the software is comprehensively tested and verified before you integrate it into a medical device. In addition, parts of the documentation required by IEC 62304 are automatically generated for regulatory compliance. 

      But how does Model-Based Design work in practice? And how do you get started? Join this webinar to learn the best practices for improving software quality while reducing development time and costs.

      Highlights

      • Requirements management and system architecture design
      • Automated unit and system level testing with test report generation
      • IEC 62304 supported workflow for FDA/MDR regulatory compliance

      About the Presenter

      Dr. Visa Suomi is the Medical Devices Industry Manager at MathWorks. He has over 10 years of international experience in the life sciences and healthcare sector, with an interdisciplinary background from the medical technology industry, academia, and clinical research. He holds a doctoral degree (DPhil in Healthcare Innovation) from the University of Oxford, UK, with the focus on translating academic and clinical research into commercial applications.

      Recorded: 26 May 2021

      Hello, everyone. And welcome to the presentation, Developing IEC 63204-Compliant Embedded Software for Medical Devices. My name is Visa Suomi. I'm the Medical Devices Industry Manager at MathWorks. I have over 10 years of experience in working with medical device companies. In this presentation, I will share my experience on how you can improve software quality of while being compliant with IEC 62304 software development process.

      So the outline for the presentation is shown here. I'll first talk about advances in medical device software development. Then I'll show a couple of practical examples from the industry how surgical robotics and ventilators have been made using model-based design. After that, I'll talk about the model-based design in general. And then after that, I will show the benefits of model-based design. And finally I will summarize the presentation.

      So let's start with challenges. As many of you already know, medical devices have become more and more complex. There are multiple sensors, high computational capabilities, and more advanced algorithms. And due to all this complexity it also increases the risk of design errors in the final medical device.

      Secondly, medical devices consist of multi-domain components, such as electrical components, fluidic components, and also mechanical components. And due to all this complexity, when you put everything together in the final system the devices are subjected to integration issues. Thirdly, regulatory bodies, such as the FDA, and in Europe, MDR, are enforcing stricter guidelines for medical devices. That means companies need to comply to more regulations in the developmental process, and they need to adapt more rigorous development and V&V processes that are compliant with these standards.

      One case from the industry is infusion pumps. So in the past, and also in the past years, infusion pumps have been subject to many safety issues. And FDA has noticed this. Because of this they do the Infusion Pump Improvement Initative, which is the initiative to support safer development methods for infusion pumps while minimizing the risks to the final patient. As the outcome from this initiative model-based development FDA calls it, but is the same concept as model-based design, was proposed as one of the solutions to improve software safety.

      MathWorks actually had a collaboration together with the FDA where we are looking for applications in model-based design, how to develop safer medical devices, and how the industry and the manufacturers could benefit from this process. So now let's look at the couple of practical examples of how the best design can be used in the field. So let's start with the surgical robotic system. Surgical robots, they are very complex systems. They have multiple instrument controls, motor controls for the instruments, they have high precision and they also need feedback for surgeon to you feel how tissue feels in the actual cutting operation. They're also highly regulated. So they are classified as FDA Class II devices, which means that they have all the regulatory requirements to fulfill before these devices have been approved to the market.

      One of the solutions to develop safer surgical instruments for surgical robots is to use system design models to see how the software or hardware interacts with the plant model. So you can have actually to the whole surgical robotic system built in a simulation model, and then test that in real life how all the controls and model controls and feedback loops work in practice. And that enables you to also do verification at the same time as you are building your design. And for the whole process during conform to IEC 62304 standard issue for all the model-based standard process requirements all the way to the embedded core.

      Here's an example of a simulation model done in Simulink. So you have the comment, so this would be the surgeon's operating console where they give commands to the driver, to the controller, which drives the final surgical instruments which in this case is cable- driven mechanism. So this is an open loop controller. So the surgeon just gives instructions to the controller, which then executes those on the final surgical instrument. But you could have this in a closed-loop fashion as well, where the sensors in the surgical instrument would feed back to the command generation and the controller. In this case, the surgeon would feel how the tissue actually feels. Is it hard or soft tissue that they are cutting.

      One of our customers is Corindus. It's a Siemens Healthineers company. They used the model-based design process in developing their next generation surgical robotic system. So actually the model, the control systems, in Simulink, and they used the real-time rapid prototype platform, where they could actually execute that model in real time. And in that way the engineers and the surgeons could feel and test the simulation model in practice before making that final hardware, This device then came to market after this developing phase. It was used to perform the first PCI intervention in the world, remote PCI integration. And the engineering development time also halved, the engineering efforts reduced by 80% by working this way.

      So now let's have a look at the video of one of the engineers explaining how they used the submarine with a platform in rapid prototyping.

      I came on as the principle Robotic Control Systems Engineer, and so I developed the control systems for the robot that we have behind us, the GRX, for guide catheter control and manipulation. When I came the first thing I did is I started modeling the systems and simulate them. And I simulate those in Simulink. And I started designing all the control laws that were involved on the product at hand. What I would do is I would kind of model the system as high level as I could, get the math right, get the algorithms correct, simulate them and then when we needed a platform to run it on, I used the Speedgoat with off the shelf amplifiers. And in a really short time frame we basically got a working system for in vivo testing in an animal model to verify that we could indeed manipulate catheters safely inside a patient. And so I had a real-time video capture system. They're going to compress it with JPEG, and then they're going to chop it up, send it over the network, and then reassemble that image, and then display it for the physician in real time. At the same time, the Speedgoat supported the ability to do Precision Time Protocol.

      And so I had to design a system that could take advantage of the PTP support that MathWorks had. We thought we could synchronize a clock over an encrypted network. So the challenge is not only do we need to know the time that events are occurring in order to safely do an intervention with the patient, but we also need a secure channel. So the system that I developed allows us to kind of send packets back and forth, where the Speedgoats are completely unaware they think they're on the same network. But I need to be able to know exactly when events are occurring. And I want to do that using Precision Type Protocol. The problem is you can't have one clock with Precision Type Protocol. So what we did was we chose to go ahead and have two clocks at each side. And then we know exactly the time delay between the two sites at all times. Not only could we measure the delay, we can actually inject delay so that we could actually see if you could safely finish interventions under various types of delay in order to kind of characterize what those results were.

      And then we can use that to safely ensure that the physician won't have delays that are too large. But we have a TelePresence system so that you can basically contact the other side, we have a tunnel that's created between the two sites so that we know that we're kind of, all systems are go. And then we basically bring up both the local and remote side, and then next thing you see, you see the video. You have the real-time fluoro, and you have the hemodynamics there to monitor the patient's health, and exactly what the time delay is. So I have continuous time models for the motors that are used in the robot, and obviously a model of the kinomatics. And some of the physics involved with the slide and stuff. So like, for guide catheter control. On the control side, we then build all the discrete algorithms. Most of it's written using embedded MATLAB blocks running within the Simulink environment. Then you'll replace the simulation of the plant and then you'll just have the actual robot. And then you'll go ahead and run those items on the robot using Simulink real time. You're actually working with the robot. So when I know it goes on the robot it's going to do exactly the expected.

      So next case is a it's a mechanical ventilator. So mechanical ventilators have been a lot in the news lately. They actually are a very challenging device to build because there are multiple parameters and dangers that need to be incorporated into device, such as humidity, the temperature, the airflow, the air pressure, and such have to be monitored all the time when the patient is getting the support from the ventilator.

      That being said, there's also a risk of patient injury or death because this is a high-risk medical device, FDA Class II. And that also means that the development of mechanical ventilators are subject to multiple regulatory requirements in the development process. Again, one of the solutions to develop this kind of complex medical device is to actually simulate the closed-loop control of all the sensors on the ventilator controller in a one system model. That enables you also to use this model for verification. So you can have the verification and the requirements done simultaneously while you're designing the ventilator. In the same process you can also conform to IEC 62304 standard as mentioned before.

      Here is a simple positive air pressure ventilator model that we have available on our website. If you go to File Exchange you're going to find this model there available to download. So this model will be basically half our patient long model, with a passive patient with the muscle pressure, added moisture for humidation in the body, and the body temperature. Then we have the floor sensors, We have the patient mask, we have a controller, and we have also humidifier, and inspiratory tube for the ventilator. And in this model, we can model the whole patient into the ventilator and at the same time see how the controller behaves in different situations.

      One of the companies that we've had very closely with is a Cambridge consulting company based in Cambridge in England. They actually had to build a ventilator prototype for the British government in a very short time period. So they used for this purpose Simulink. So they put the whole ventilator system in Simulink together with the graphical user interface that you can see here. They were able to test and verify that the ventilator worked as expected in the simulation model.

      And when they then used the real hardware prototype they made the exact same user interface and the exact same parameters, and they were able to build this whole prototype ventilator in just 47 days, which is a remarkable achievement considering the complexity of the device. This was, again, enabled by utilizing the simulation on model-based design early on in the development process, and then executing that on a real, live hardware prototype.

      So now I've talked about what model-based design, but I haven't actually shown any benefits or how does it look when it comes to the development process. So let's look at that next. So here you have the schematic of a traditional development process. So the companies and the engineers, they do some research based on the stakeholder comments that they want to put for the clinical device.

      Based on the results, they also define the requirements for the ventilator. Based on the requirements, they then do the specifications. These specifications are for the different teams. We might have a team in charge of the electrical design of the medical device. You might have a team in charge of the algorithm development of the device. And then you might have a team in charge of the mechanical components. And this in between here, mean that these teams usually, when they get the m they work independently. So there's no interaction happening between teams during a design process.

      After that, you will have some algorithms written in C. Maybe you have FPGAs and HDL code in there, and even in some cases, CUDA code. And you put everything together here at the integration testing phase. And what happens here is that the errors that you might have caused already here at the specification stage, you only start finding them here at the integration and testing phase.

      And the time scale all the way from specification to integration testing is very long. It's at least a month, and in some cases, could be even years. And you can imagine how much time and money it costs if you found a critical error here at the testing phase, and the integration phase that has been caused by misdefined specifications in the beginning. So in model-based design, we start actually from the design phase.

      In the design, you would have physiological models. So in the case of ventilator, that you would have the lung model here. You would have the physical components of the medical device. Again, in the vendor, they would have the controller and all these by tubes built in here, and you would have also the algorithms. Say the controllers, or the signal processing algorithms, or maybe the image processing algorithms that go into your device.

      All of them you can model in Simulink, and in the design phase. You can also link your requirements directly to this design. So in Simulink, it is possible to actually dynamically link your requirements to different components and different algorithms in design. And that enables you to actually start testing and verifying your design earlier on.

      So here in model-based design, you can actually start testing and verifying your requirements against the design early on. Whereas in this process, in the traditional process, as I showed, you can only find those specification errors here at the integration testing phase. So now, you are actually saving a lot of time, possibly money in the long run when you can start this early verification process.

      Another benefit is also that the teams know how to work together in defining the design. So all these different team members who are in charge of the electrical components, the algorithms, and the mechanical components have to come together in order to define and refine this initial design, and make sure that the specifications that have been defined actually are implemented here in the first design.

      After you have verified and done the design, you can then move on to implementation. So we have the capabilities of generating code directly from the design. So depending on your hardware target, you can generate C++ codes for CPUs for example, or microcontroller units.

      You can also generate HDL code directly for FPGAs and ASICs. And you can also generate CUDA codes for some deep learning networks for GPUs, and also HDL codes from deep learning networks that can be integrated in your final medical device. And now again, you can test and verify this object code against your design, and against your requirements because you can do software-in-the-loop testing to make sure that the generated code, the automatically generated code from your design matches exactly the functionalities that you have in the design, and matches exactly the requirements that you have defined earlier.

      If you want to go a step further, you can also benefit from rapid prototyping, so you can actually execute this code directly on a hardware prototyping platform, and then you can see in real time how your design behaves on a complete system model. This is a real time, real life hardware prototype. And that enables you to do a system level of verification between real life hardware and test against those requirements that you have defined in the beginning.

      So now you have complete verification validation. Workflow verification of all this has been integrated into the process seamlessly. So study from system design. So in Simulink, you can actually create a system level models. So you can have a system model described based on the kinds of components. So you might have some different stereotypes that you want to link the like the price, and the cost, and the rate.

      And all of those can be linked to the system level models. You can also see the interaction between different components, so you can drag and drop lines, name the components, and assign stereotypes of these components. You can sketch these hierarchical systems, and you can link them as I mentioned before through the comments.

      Next, you can also edit or manage system requirements. So you can link requirements, the design, or architecture during drag and drop. So in Simulink, you have this interactive requirements management panel that you can see your requirements listed here, and which of those requirements have been actually implemented in your design.

      So you have the dynamic linking, so you can link your requirements into the design. And you can see here with the flow bar which of the requirements have already been implemented in your design. You can also link test cases to the comments, so you can see if the bar is green that you have linked the test case and you have verified those requirements.

      Or if the bar is red, you can see that you have linked the test case, but the requirement hasn't been yet verified. So that gives you that kind of dynamic view over your design, and also keeps coverage of the implementation and coverage of testing during your design phase.

      You don't necessarily need to use Simulink requirements exclusively for requirements management. So we support a number of third party tools for requirements by linking. So you can export your requirements from tools such as IBM DOORS, Word, or Excel, and you can link those into Simulink.

      In that way you can execute them also in the design. We support ReqIF standard, so if we have softwares that can support that format, exporting that important ReqIF format requirements, we can also import those in the same way, and you can then have them in your system model.

      And as I mentioned, you can perform this coverage analysis because you have the dynamic view of the requirements in your Simulink model, and the state at which they are. You can also use the model as and integration platform. so you don't have to exclusively use MATLAB, or Simulink language to work on your design. So we also support importing languages such as C++, or C.

      So if you have legacy code, or you have some code that you want to use in the model instead of similar components, you can then import that code, and call that code into the design, and use the same verification on testing capabilities as you would with the native code. So you are not bound to use only Simulink. You can still use C and C++ code within your software group, or your engineering group. But that enables you just to link those codes into the design.

      For image posting, we also support OpenCV, so you import functions in the design for imaging posting purposes. And we can also import deeper networks in ONNX format, which is an open source network format. But if you have deeper networks, say in Python, you can then convert those into ONNX and import those into MATLAB, and then also into Simulink.

      You can also get real-time data acquisition capabilities into your design. So we have a say, some clinical device, say ECG device, or some kind of temperature monitor for example, you can link that data to fit in real time in the Simulink from different instruments. And in that way, you can actually test your design with real clinical data in real time. So that's one of the benefits that comes with the rapid prototyping that you can actually get real-time acquisition data for your design.

      You can also perform unit and system level testing for your design. So you can create and run test scores automatically. So you can create test harnesses for different components in your design.

      You can automatically execute test cases that you have defined. And as I mentioned, if you want to use your legacy or handwritten C or C++ code, you can link that in the design, and use those testing capabilities, or support that legacy code.

      You can link this test case through the requirements, and that gives you the ability to see which specifications or requirements have already been verified, and what is still missing from that list. You can test system with conditions that would be otherwise too risky or time-consuming. So if you have to do a lot of manual system level testing, you have to maybe use some clinical testing, you can make sure in the beginning with the simulation that your device works as expected with the simulation.

      And then you can be confident when you go to the clinical validation later on that you have a design that has been tested and verified at a system level. You can maintain traceability from requirements code. So when you start from the requirements, they are linked to the design, and that design is also linked with the final object code, which can be automatically generated.

      And that enables you to generate traceability matrices, which are very helpful when working with the regulatory bodies and in showing that you have actually implemented all the requirements in the final object code. That is possible to do because you have this dynamic linking from design into the code and the requirements. So I've talked about code generation before.

      So we support multiple different targets for code generation, and they are vendor independent, so you can even use custom chips, or custom hardware for your design. In the final hardware design, and then you can optimize the code generations for that specific target. So from this on, you can generate code for multiple different formats.

      So you can C, C++ code for CPUs, for example. We support ARM Intel Cortex chips as an example. You can generate GPU code for NVIDIA platforms, and then also you can generate FPGA code. So HDL, HHDL, Verilog code for different types of FPGAs or custom ASIC designs. So all these are supported, and you can optimize object codes depending on your needs. So you can optimize it for memory, optimize for speed, you can optimize it for energy.

      All of these optimizations you can do and define yourself, how you want the final code to look like. You can also use rapid prototyping. So you can link your model into the automatically generated code, and then execute, or deploy that on a target, real-time hardware. So we have partnered with a company called SpeedCoder, that built this real-time practice platforms, and that enables you to run your model in real-time on one of the hardware components and see how that system works in real life when you have the hardware prototyping in your object there, for example.

      So you can loop your automatically generated code back into your design and verify that it works the same way as the model does. That this call software-in-the-loop. You can also link your hardware. Say, the rapid prototyping platform in the design, and make system aggregation to see that your system actually works the same way as your design. And that is called hardware-in-the-loop testing.

      So all of these are possible when you have this dynamic linking of code in the design and the requirements. So next, let's look at the benefits of model-based design. What are the main advantages compared to traditional development methods.

      So first you have fast implementation from concept to code. So you can implement concepts quickly, but you have in mind ideas that you have in mind. You can sketch them in System Designer, or you can sketch them on Simulink, and use this graphical user interface to drag and drop components, and track signals between different components. That enables you also to manage complexity in algorithm design because you can see how the system looks, and where all the signals go, and what are the hierarchies are between different components.

      And you can also reduce manual coding errors because your design automatically matches with the code. So just with the click of a button, you can translate your design into a final object code. That enables you to have high quality code that has been verified already at the design phase, and should work exactly the same way as your example. Secondly, you can detect design errors early on in the development process.

      So here's a graph showing where the errors actually are caused in the design and the development phase taken from this publication here in the source. So around 6% of the errors introduced the final design and the system design are already set in the specification stage. Then around 20% in the design phase, around 10% in the implementation phase, and then finally 5% in the testing phase.

      Now if you look at where these errors are actually found, the picture looks quite the opposite. So around 55% of the errors are only found here at the testing phase. So what it means is that you caused a majority of the errors here in the specification stage, but you only find them here at the testing phase. And the time scale from here, from the specifications in the testing from design implementation can be months, or even years.

      So there's a lot of time and effort wasted when you start testing early on. Only here at the late stage you start to refine the specifications and do all this process again. So what happens is the idea is to move this detection of errors earlier on already here at the design phase.

      So as I showed, you can start designing simulation model, and testing that simulation model against the specifications early on. And how should I iterate this error reduction early on in the development process and save me a lot of time? You are still causing a lot of errors in the specification stage, but you also start to find them early on in the design phase, and that's the value.

      So you are saving a lot of time and money because the errors that you would cause to go down this path in the development process and testing phase, you already start to find them here at the design phase. You can do hardware independent development. So you can actually start developing these models before finalizing the hardware design of your medical device.

      That is because you can focus on the functionality aspect of the design. Say if you're developing a ventilator, you're going to focus on functionality, like the pressure detection, the flow detection, the humidity detection, without caring how your final hardware is going to look like. Because you're going to use code generation after that to optimize your final code to your chosen hardware, and be able to support coding standards such as MISRA or CERT-C, so that they can be compliant with different requirements and standards for the code generation.

      And the benefits become even more obvious when you are developing the next generation medical device. So say your device has been on the market for some years and you are starting to develop the next device, you can reuse your previous design, simulation model, maybe add some functionality. Maybe you want to improve the algorithms, maybe you add some extra components to it. But the core design, you can reuse it.

      And once you have added that functionality for the next generation device, you can then again use the code generation for your new hardware and that is independent development process where you don't have to specify the hardware in the future. And that enables you to do shorter time to market for new medical devices by reusing these old legacy models.

      Fourthly, you can be compliant with regulations standards. Support the FDA and EU. They require complete software life-cycle management processes. They don't specify which process they require, but IEC 62304 is a standard that's probably used 90% to 99% of companies because it clearly states what steps you need to do in your development process in order to be compliant for these regulations.

      It's a harmonized standard, so it's accepted by both the EU and FDA for the medical device regulations. So if you use model-based design, you can fulfill all these steps. So in this table, you can see what is the requirement for the software development.

      So you start from software development plan, define the requirements, do the software architecture, do the detailed design, unit modification, unit verification, integration, integration testing, system testing, and final software release. And class means what safety class your software is in. So if you use model-based design, you can actually do most of these steps already in Simulink, and you can also generate documentation to show for the regulators that you have done these steps.

      So that's a critical aspect because you save a lot of time documenting documentation because these requirements have been dynamically linked, and that enables you to also generate test reports, and generate traceability matrices that you can show the regulators that you are compliance with standards. So the final and fifth benefit is fully integrated verification and validation workflow. So you manage requirements with traceability directly in Simulink.

      And its bi-directional, so you can track them from requirements in to final code and back when you have this dynamic linking. You can automate test cases for unit and system-level verification and that supports all the hardware-in-the-loop and the software-in-the-loop testing. You can detect critical run-time errors in C and C++ code. If part of your code is legacy code, or you want to use handwritten code in your design.

      And we also have TUV SUD certificates for tool qualification. So you don't have to do this extra step for tool validation because we have done that already for you. So we have validated it through TUV SUD. Our coder products and the verification validation products so that they're compliant with the IEC 62304 process, and we have those documents to show that we have done that tool validation.

      So next, let's summarize the presentation. So key takeaways with model-based design. You can implement concepts quickly on the system level. So you can start sketching your design, or at the early stage when you have ideas in mind.

      You can do early testing to detect errors in the design. You can do hardware development with rapid prototyping using some of the platforms where you can actually get the code in real-time from your design. You can be compliant with the software life-cycle requirements of IEC 62304, and at the same time you can also generate the documentation to solve the compliance.

      And finally, you have full integration of verification and validation into your workflow with the seamless integration of the third party tools. If you want to use external requirements management software, or you want to use some legacy code or handwritten C code, you can still use the verification and validation capabilities in Simulink. So how to get started?

      We have actually written this white paper, which is available to download on our website. It's titled the same as for this presentation. So with model-based design, you can start by experimenting with a small piece of the project. So you can choose a sub-component or a sub-system medical device that you want to apply this model-based design and start with that.

      You can then do some system level simulations to see how the component works on a wider scale in your medical device design. You can use these models to solve specific design problems. Say if you want to focus on the control aspect, you can do that. If you want to focus on the ECG signal analysis, you can focus on that component.

      So it doesn't matter. You don't have to actually do the whole device at once. You can just focus on a specific problem first, and see how the simulation works in that design, and then you can start expanding from that in the future.

      You don't have to pick up all the model-based design steps right from the beginning. So you don't have to do the verification or validation. You don't have to do the code generation.

      You can just start by simply simulating, so you can pick up components similar to how that system works. And after that if you're happy with the performance, you can then maybe generate code and deploy that code on your medical device. And if it works as expected, you can also then incorporate these verification and validation capabilities, where you can start doing early testing and verification in the design process.

      And you can also take advantage of our resources. So we have a lot of resources available to you. So we have a lot of online courses online that you can benefit from. We have professional engineering support, and we have practical examples in our recommendations that you can use in order to get familiar with the process and see how everything works in practice.

      So if you are interested, we have as I mentioned, we have this OnRamp course, which are completely free, available on our website. So that is like a three hour course, free course where you have hands-on exercises on different tools and products that you can use in model-based design. Such a Simulink, Stateflow, and Simscape.

      We have awesome free webinars available where you can see how Simulink is used in the industry, what is model-based design in practice, and how to get started with model-based design. We also have on-site and self-paced training courses. So if you want to do an online course, or maybe you have a team in your company that could benefit from our professional training, we have those courses on our website, and our trainers are happy to come to your site or specific location to train in the efficient use of Simulink and other products for your design.

      And from the engineering support side, so as I mentioned, we have training. So that's professional training with instructors, one or two day trainings typically for the whole team to get started properly with tools. We also have guided evaluations and trials, so if you're not sure if the Simulink would be the right tool for you, or if model-based design would be the right process for you, you can work together with our engineers completely free of charge and have the free trial at the same time to evaluate our tools and see if it works.

      And that is guided so you will get the benefit of working together with our operation engineers in that process. We also have on-site workshops. So if you have any specific topic you will want to learn more about, say if its deep learning or if its simulation, or maybe it's a control design, we also do those workshops on site for our customers. For specific engineering support, we also have consulting services.

      So we have consultants that can actually work and do work for you. So if you want to implement some specific components, or you want to acquire the technical knowledge into your company for our experts, you can do that together with consulting and that will show you hands-on with the work that they do on how we actually do that development you are planning to.

      And then finally, they have technical support. So they have actually a lot of master's level engineers and technical support who can answer questions related to technical topics that you might encounter during your development process. So feel free to contact them. They are available online and also on the phone when you need them.

      And finally, please have a look at our website mathworks.com/medical and there you can find more information about our solutions, and how they could be used in medical device development. Thank you very much and have a good day.

      View more related videos