About this talk
This talk provides an overview of how Philips develops medical grade software for X-ray systems used in minimally invasive cardiovascular procedures. The speaker, Paul Robert Marco, a senior system engineer at Philips image-guided therapy systems, emphasizes the importance of patient safety and regulatory standards in the medical software industry. He details the key components of their software development process, including quality management systems, the establishment of SMART requirements, and the use of modular design principles. The speaker discusses the role of risk management, error handling, and continuous improvement, along with the integration of CI/CD practices in their workflow. Ultimately, the talk highlights the collaborative efforts in software development, emphasizing the necessity of rigorous testing and quality assurance for medical applications.
Full transcript
Hello. Hello everybody. Can you hear me? Everybody's everything okay? You can hear me loud and clear. No interference. Okay. So, let's start it. Welcome. It's the first time here in such a conference and it's the first time that I presenting for such a audience about some awesome things that we do at Philips. Therefore, my name is Paul Robert Marco. I'm a senior system engineer at Philips imageguided
therapy systems. And today I will give you a very brief overview about how we develop uh medical grade software for our X-ray systems. We at Philips IGT we create and develop X-ray systems used for minimally invasive cardia cardiovascular procedures such as our uh uh flex arm system. What you can see here is that the doctors uh prepare the patient. They introduce catheterss and everything that they need.
After the patient is prepared, they move the system into position so that you can acquire X-ray images. And after the X-ray images are acquired, they move the detector to the right place so they can see the region of interest that they want to radiate. But you can see here is reconstruction of an artery with contrast injection. But you can see uh pictures like substracted at different uh
different uh process images when they you can also rebuild a little bit the vessel structure if you uh if you in if you uh insert the contrast agent and voila you have here for example the reconstruction of your uh of your foot the vascular tree. So this is this kind of uh X-ray systems we create. What do you think that uh medical devices uh medical industry the
avi aviation industry and the car manufacturing industry has in common software wise? Well that software is safe. It means that it comes with a uh guaranteed quality. It's safe to use and it's reliable because it comes from a regulated industry. A regulated industry means that leg regulatory bodies are watching over you and that also you have to fulfill some uh some standards. Every journey starts with a
vision and our vision at Philips is to have better treatment, better care for more people and we want to achieve this in a in a safe manner. We want to achieve this with sustainable manner with latest innovation and with patient safety at core of everything we do. Patient safety is something mandatory for us towards the patients. It's not optional. It's not something nice to have and it's
at core of everything we do. And this is how we want to achieve clinical excellence. You may ask yourself why patient safety? Well, in minimally cardiovascular procedures, you may use devices such as catheterss, guide wires and balloons. And what you can see here in the picture is the tip of catheter in a beating heart into uh in injecting contrast uh agent. I also bought with me uh
some of these devices so you can actually see what what uh how does it look like. So please distribute it around. So I have Yes. And what you can see here we have uh citers, we have guard wires and balloons. And these ones are used in uh in Oh, okay. Yes. And these ones are used in u in such uh procedures. Now, what do you need to
be able to make and to create uh a quality medical grade uh software? First of all, you need to have a quality management system where you plan and control your quality when you take in a consider when you manage the your your processes and also you measure the performance on the system. But you also have to have something for um for getting a continuous improvement and getting
the feedback from uh from the uh from customers. Nevertheless, when we develop requirements, we try to have requirements that are smart, meaning that is specific, measurable and achievable. If those requirements are not not uh fulfill this these um quality requirements, then we not simply we cannot make it as a requirements and because we cannot test them. When we uh when we introduce requirements, we have to look
at how how we going to uh test them. our requirements systemwide or just only for few components important. When we do other requirements, we um we effectuate uh design failure mode and effect analyzis. So when you see the when we see the defect the defects and how we can u how we can actually see what kind of failure modes are coming from those uh from those failures
and what kind of risk control measures we have to uh to um mitigate those uh those risk that are identified in the failure mode analyzes. We also have to fulfill standards and the standards have also impact over your requirements. For example, in our case, we have the IEC 62 304 software classification for medical devices. And when we uh when we also change requirements regarding image quality as
you seen as you seen the the X-ray images, we also conduct clinical trials for that one. When we look at our architecture and design, we try to have a modular design. So when you change a component, it does not affect when you change a component A, it does not affect component B. When we introduce uh interfaces between components, we try to segregate them on their use cases
and using the solid principle for single responsibility. We also model those interfaces so we can uh we can formally uh verify them. We also think about error handling and recovery for faulty situation when what happens when different software exceptions happen but also graceful degradation how you actually lose functionality in case of a hardware failure we have to design for these kind of things because hardware will fail
that's if we look at our usability and UI when we develop software we have to take into consideration that uh we have to keep the situ situational awareness of our uh doctors Because when they operate they have to focus on actually on the patient and when we develop also the workflow and the UI elements we have to be consistent to show the same same kind of information
the same manner but also keeping the uh the situational uh responsiveness of the UI is an important uh item because you don't want to have an UI that does not respond or for a long time is doesn't give feedback for the users and especially you don't want to have an interface case when you're going to have in critical situation discussions about like tiny button when somebody says
push push the tiny button do you push the button that is tiny or the button that says it's tiny so when we come to implementation we have um we conduct um bi-weekly software quality standard standups when we uh look at the static code results from tools as tix tick tool from tobi and coarity we also have um coding guidelines where we see what kind of how do
we name variables and how we initi how we create initial initializers and how we initialize our software. We also facilitate uh pair programming because pair programming has is an awesome thing because you can share also knowledge but you can also do code review in the same time and we have gated pull request. So when you push your uh um when you push your code to uh to
the master branch, you automatically will test it. And that brings to our uh CI/CD part, excuse me to drink some water. So that the CIC CICD part we can distinguish CI/CD on two levels component level and system level. At component level, at every pull request, we run module test. It's a short duration test. And uh if they succeed we can uh we can merge with the master.
But at night we run the most extens extensively test for memory measurement for performance and also for a long duration test on the system level. However at every night we collect the baseline of uh latest uh the latest baseline of components and automatically build them and push them to a to a selected subset of systems where we run acceptance test and regression test. In the acceptance test,
we see if that components integrate well and we didn't break any interfaces. And in the regression test, we're going to check if already existing functionality is not broken. Now we got we go we arrive at the verification validation phase. In the verification uh phase, we verify that our software does what it actually meant to do based on requirement tanks. And the validation phase we check if the
system and our software also does what the user needs what a user expects and what the user need are. An important aspect in this part is the tool validation because even if you use uh open source software thirdart third party software we need to validate it. So we need to check the quality of that uh particular library because if the quality of that library is not okay
then our AO product is not okay. And meanwhile we meanwhile in verification and validation phase we also create uh and run reli reliability uh measurements for the uh measuring the meanantime between failure which gives an overview of how robust we are. how robust we are. Our way of working, we use scale agile uh scale agile scale agile framework with concepts such as agile release trains, program increments
and and epics and also every morning we have the scrum um scrum rituals stand up where we discuss daily work. So the key key takeaways first of all if you want to make a medical grade software it's a regulated industry so you need to have a quality management system. If you want to be able to test your requirements, they need to be uh smart. Which means that
they are specific, measurable and attainable. You have to have also uh risk control measurements and failure mode analyszis because you have to identify your uh failure modes. So how do you react on that? You have to design for u error handling and graceful degradation because hardware real breakdown and how you will respond to that. And you have to have uh uh tools for static code analyszis and
uh and u also to look measure also memories. But we also need to have better programming to share the knowledge and also to guarantee quality on of your code doing code reviews. And of course if you want to have uh reliable software you have to build up confidence. And the only way to build up confidence is you if you run tests and to run tests you need
to have a strong um CI/CD pipeline. That being said, thank you for your uh presence and for your attention. I hope you enjoyed it. And if I made you enthusiastic work at the medical domain and work at Phillips, you can join us at Phillips. Thank you very much.
