hello software friends I assume you landed on this video because you are interested in software as a medical device also known as Sam in this short course I want to share my thoughts what to get right when working with software only products and at the end of this video I will also share tips about software risk management which is painful if you don't get it right I am Christian Kessner and I started my career as embedded software engineer in the early 90s after a couple of years I moved into the medical advice field where I have developed sterilization equipment transplantation devices wound care therapy and much more several years ago I joined the project teams authoring IEC 62304 and IEC 82304-1 and I also work as a lead auditor this short course applies to you if you are developing software as a medical device for example an app a cloud service or a regular desktop application I will be showing you some key Concepts in the medical device software area to help you understand it and avoiding mistakes to get things right I first want you to know the difference between a software release and a product release then I want you to know about the necessary standards that are needed for smooth approval process but standards are not too exciting so I also want to share a few practical tips on how to conform to the standards and I've saved the best for the last software risk management now let's get to it I often hear people say that working with software as a medical device is different from working with other medical devices in my opinion on product level there are no differences because you must work with planning requirements risk management verification and validation regardless of what type of medical device products you develop but to be fair there are some differences when it comes to the development of software let me share what I believe are the two main differences the first and the most obvious reason is software bugs a software product comes with all bugs enabled but you don't know when that will pop up if you have a car you can take it to a garage and ask them to check your brakes or oil level but for software there is no such option one Infamous example of software bug is a Windows blue screen it is very unexpected when it happens and you lose all your unsaved work when working with medical devices the same blue screen can mean the loss of a patient's life clearly this makes people nervous because there's no way to confidently claim a hundred percent test coverage when working with software this brings me to the second topic which is about how products are created the vast majority of software issues or bugs are traceable back to errors made during the design and development process and this is logical because there is no manufacturing process when working with software products for tangible products designing the manufacturing process is a significant part of your development work in the manufacturing process you can Implement checkpoints like in process controls and apply statistical process controls when working with software products process control is not an option because there is no manufacturing process you simply have to trust that the development was done correctly and all quality controls must be part of your development work and again sorry to say or solve for repeating myself there is no final production test where you can Implement inspections to capture product failures closest thing in software would perhaps be the software release node which is not at all the same thing speaking of software release takes me to software release versus product release in modern software development it is common to find continuous integration and continuous deployment continuous delivery is a software development methodology where the release process is automated every software change is automatically built tested and can be deployed to production at any time this is cool but before you get too excited this is usually a software release and not a product release now you might think when talking about software as a medical device there are no other components than the software system perhaps not components but in an audit situation I would expect to find accompanying documents such as the instruction views and evidence of a successful design validation in your product release it may be simplification but you could say that as software as a medical device product is the combination of software and its relevant documentation and product documentation is usually overlooked in a software release as you can see a complete medical device release flow spans many more activities than the software release you find on the left hand side just to mention a few there are requirements for design validation and accompanying documents such as the instruction views these activities will result in what I call a design release you may be using another term once the design release is done you may need to wait for regulatory approval before product release and placing the product on the market after initial product release you can usually manage non-significant changes without new third-party regulatory approval however please ensure you maintain relevant regulatory documentation for example keep the MDR general safety and performance checklist and Technical documentation up to date when working with Standalone software you can merge soft release and design release into a single activity for example by including technical documentation and instruction views as configuration items in your development work this is a lean approach and makes sense in most cases still I want you to be careful about placing a software on the market without considering all the activities and deliverables needed for a product release now you know the difference between a software release design release and a product release next up is the central standards applicable to software as a medical device standards aren't the most exciting part of software development but the idea with standard is to establish a common way of thinking which can be recognized by various stakeholders such as regulatory authorities so by conforming the standards your head previews and Auditors to understand your development process and the resolving output if you do this right your chances of a smooth approval process increases significantly when working with the software as a medical device there are six essential standards you should be aware of and preferably also understand and Implement at the bottom you will find something often referred to as management standards they usually the core in any quality management system ISO 13485 contains requirements on your quality management system that is how you're supposed to work in general this includes for example requirements on design and development and that you have to establish design and development inputs but ISO 13485 also contains requirements that are not related to designer development for example how to structure your quality management system and how to manage documents in general getting back to the design and development inputs they are inputs to your software requirements and software development process in ic 6234 the design and development inputs as they are calling ISO 1345 are referred to as system requirements when working with Standalone software too many layers of a requirement might just complicate things if so feel free to merge requirements into fuel or even a single document just remember to include the requirements for all applicable standards ISO 14971 contains requirements on your risk management process that is how you should be performing risk management the risk management process provides one of the most important inputs to a software development process and that is hazardous situations a good understanding of hazardous situation is key to performing meaningful software risk management and getting it right and as it so happens you can find causes on both ISO 1345 and ISO 4971 on medical device HQ IEC 6204 is the leading process standard you need to understand for software development luckily for you we're sure to take a closer look at IC 6204 if you have used interface of any kind in your software you will also bump into IEC 62366-1 which is about usability engineering the usability Engineering Process can contribute to both functional requirements and user interface related risks which you need to consider in your development work please note though the definition of use interface in the usability engineering standard is Broad it is not only reducing phase you see in the software so be aware even if your software is intended to run as a technical background service without any traditional use interface the usability standard might still be applicable for example when working with instruction views and installation instructions that are connected to how to use the software product the last process standard I want you to be aware of is IEC 81001-5-1 which is about security it might not be applicable to all some products but if you are working with Standalone software there is a highlight load that security is something you should keep a close eye on the next and the last standard to be covered in this overview is IEC 82 304-1 it is a product standard for Standalone software such as apps PC program and cloud services that are supposed to run on generic Hardware platforms so when working with Standalone software this standard applies to you and your product iec82304 is a product standard for health software the standard defines requirements for establishing high-level product requirements for your software product you also find requirements on design validation and accompanying documents but in all honesty IEC 82304-1 essentially duplicates the requirements you find on design inputs and design validation in ISO 13485 therefore when working with software asymmetical device my recommendation is to adapt your existing quality management procedure to embrace the additions you find in IEC 8234-1 instead of establishing a standalone procedure for ISE 82304-1 but in one aspect IEC 82304-1 is much more specific than what you find in ISO 1345 which is requirements about accompanying documents as a product standard it defines a detailed requirements on what to include in the instruction for use and the technical description of your software for example the following activities are expected to be described in instructions for use installation startup shutdown operating and decommissioning now let's have a closer look at IEC 62304 which is a process standing meaning you will not find details like performance or screen resolution requirement or what to include in instructions for use what you will find is a list of requirements and activities you should carry out throughout your development cycle if you are a software developer this standard will influence your work the most this is because the standard defines requirements you must relate to in your daily work many Sam the developers are working agile nowadays and unfortunately the standard is very sequential which implies a water foliage development method however the standard has no requirement forcing you to apply a specific development method you're free to use whatever method you want to as long as you acknowledge the process approach and don't skip any activities in the standard let's take a look at the standards essential elements development risk management configuration management problem resolution and maintenance each process is divided into activities with a development process having the most activities and now this is not rocket science if you have been working in a mature organization developing software whether that be in defense industry or mobile phone industry you will find that the ways of working are similar but use different names there's one difference though in the medical advice industry we are obsessed with safety because in the medical device industry a software bug is not only blue screen it can literally be a blue screen of death a bug can kill someone back to the standard a nice thing with this standard is that the number of activities you need to do depends on how harmful your product can be this is decided with the help of software safety classification the flow through the standard is the same but the rigor is different depending on your classification which is further explained in the standard graphical overview visualizes the scope of IEC 6234 blue boxes are in scope gray or out of scope arrows between blue and gray is where there is an information exchange and as you learned before IEC 6234 gets its input from IEC 82304-1 and ISO 13485 the first Arrow gives you inputs about what and when when is for example pre-releases for various purposes before final release what can be functional requirements such as information to display on a screen or alarm management it can also be Hardware constraints even for Standalone software for example do you have one or more CPUs available or should Communications happen over USB or ethernet in the standard there is a clause about software requirement content but nothing about how you document your requirements you can capture requirements in any way you want it can be tickets stories Wiki Pages or Advanced requirement management tools it is up to you but please remember a couple of formal requirements you need to consider for example in your system verification you must reference a specific set of requirements which I would call a Baseline this is particularly important when working with agile methods you should be able to identify the complete set of requirements applicable to a specific version even if you work in sprints requirements shall also be reviewed and improved please make sure your setup can support you in this work traceability is also required by the standard ideally your choice of requirement management also supports you with traceability from a requirement to verification in addition to when software releases are expected you also need to plan for Content purpose and how to deliver each software release the expectations are most likely different if you're releasing for a demonstration usability test or aim for a design release he will back to our obsession with safety to develop a safe software we need input about hazardous situations to understand what we must avoid this input often includes risk related requirements for example a clear warning when a diagnosis can't be decided the go to standard for risk management is ISO 14971 your risk management process should provide you with all information necessary to effectively Implement software risk management bulk of your development work will be in the highlighted section where you can see the various development activities that will take place and the order in which they should ideally happen however it is unlikely your development work will happen exactly like this and your development method should allow you to be adaptive as your knowledge evolves over time one way to do this is by working with agile methods Agile development methods Embrace changes and allow a product to evolve over time let's look at an example with the help of scrum you might feel there's a mismatch between the waterfall approach in the standard compared to working with agile methods well there is no need to be worried working with backlog stories and Sprint planning can be compared with when eating an elephant take one bite at a time let's look at an example from the standard and compare the two ways of working you need to verify the quality of your requirements by for example verifying that they do not contradict one another or expressed in terms that avoid ambiguity are traceable to system requirements or other sources if you review a scrum story before it gets implemented you do it by taking one byte at a time the wording might differ but you certainly don't want contradictions and ambiguity in your stories if a simplify things you verify software requirements on a story based level instead of verifying your complete backlog of requirements if we now compare with a waterfall approach you typically aim to have nearly a full set of requirements and then go for a review in this late example you will not verify as frequently as you do in scrum but you will spend more time in every review so you can work with agile principles and meet the standard requirements it is only a question of how you have chosen to meet the requirements in case you're into Agile development there is an excellent technical report from Amy tir45 which is a guidance on the use of agile principle enjoy your reading there's much more to talk about when it comes to Theory and standards but for now I will continue with other topics which I believe your more practical user let's kick off with planning I'm not a planning guy but I've learned to accept the importance of proper planning when working with software as a medical device you will spend most of your time in software development which should be planned following the requirements of IEC 6234 the standard requires you to plan configuration management software risk management and much more you can choose to split these into different plans but instead of making your life hard I suggest you keep it simple and start with a single plan a single source of Truth you should only start splitting the project into different plans if it adds value to your project team for example if you have a separate test team then it could make sense to have a dedicated verification plan the software development plan is a perfect place to explain how the team is structured and how you interact with your quality management system let's take a look at an example of what interacting with quality management system could be many quality management systems are developed with a physical piece of paper mod you could call it a document based mindset software information is typically not organized based on physical papers information is structured based on other aspects such as architectural functional considerations and preferably the information is kept where it supports the developer the most I would say in the source code there is a requirement in a standard about detail design the conservative approach to this requirement is to write a traditional document but since you already Version Control your source code why not let some of your documentation coexist with the code instead of forcing the information into traditional paper document here it's up to you either you keep the information in the source file or you decide to extract the information from source file and create traditional documents your way of working with information and documents can be explained in the software development plan because there's certainly no need to convert all the information to paper document but you need to identify it where it can be found and how you control it in this example I've used oxygen format for the comments in case you really must you can also easily extract the comments to tradition document formats when you later maintain the code the documentation is available where it supports the developer the most and and it's also much easier to maintain if you take this one step further technical documentation come an integral part of your build process by creating a build pipeline for documentation running in parallel with your software build this would ensure that documentation always being in sync with the software let's talk about configuration management I would say that a software product usually has more configuration items to control than all documents together in a complete development project if you look at the definition of a configuration item it says entity that can be uniquely identified at a given reference point in the software domain a given reference point can be down to hours or even minutes and this is very difficult if you compare with documents which typically are released with the help of signatures in a much lower Pace maybe ask yourself what is a configuration item a configuration item can be many things it can be pre-commered libraries build files source code compiler settings basically any piece of information needed to create your deliverable including documentation one example of configuration management is Version Control Systems which can support you with traceability in this example you see two branches for bug fixes by using branches you can quickly review how a specific bug has been resolved in the bigger picture Version Control also supports you in reviewing changes between releases this is super helpful when you're determining how much regression testing needs to be done or what you should put into your release node but it's not only the Practical aspects of gathering data and providing traceability support correctly implemented configuration management can also support process aspects of your development work let's break down the flow in a couple of steps the first step is a decision step for example when you decide to implement a change request you can use rules to Define who can create branches and use this to control when implementation work starts in response to an approved change request the next step is the implementation step if you define a new procedure that you should always work on a branch and never directly in the main this ensures that you always have traceability back to the reason why you are implementing something the third step is about verification this is a great step to implement a peer review and good practice is that you are not budging back your own code to the main the verification step is also a step where you can get a lot of compliance work integrated directly into your workflow and while you're at it also take the opportunity to review relevant documentation if you prepare good work instructions on how to merge back branches to main you can cover most of the content of the courses I've listed here on the screen the documentation part of this would end up as information pieces in your configuration management system and as I mentioned in the planning section it will be documented but not as traditional documents if you haven't done it yet spend some time in looking for good configuration management tool that can satisfy your needs and please make sure you validate the system set up and use it as much as you can I assume you have some basic understanding of risk management if you don't I recommend you watch the videos about risk management at medical device HQ one of the most misunderstood Statesmen in this field is that the probability of occurrence of harm should be set to 100 just because you're working with software I can tell you that statement is wrong the probability of occurrence of harm can be split up into two components P1 and P2 the probability of occurrence of the hassle situation is P1 P2 is the likelihood that the Hazardous situation will lead to harm when people are talking about the probability of occurrence of harm and claim it shall be a hundred percent they refer to P1 but also this assumption can be challenged let's look at an example where a software is used to recommend the proper medication in this example we assume that one percent of the patients are allergic to drug a and we have five different drugs to choose from the software fails by choosing the wrong medication what is the PO for this risk the correct answer is it depends it depends on the type of software failure we are dealing with either the software failure results in randomly selecting one of the five drugs or the failure always result in choosing drug a for the sake of safety we could assume that drug a will always be selected but if we are talking about random errors the like load for the software to only select drug b or any other drug is as high as it is for only selecting drug a this results in a different scenario in the random drug example I still agree that the software failure always will happen but cannot predict the outcome so in this particular case if the Hazardous situation is that drug a is incorrectly chosen the likelihood of the hassle situation occurring is 20 percent it is quite a difference to summarize if you are working a lot with software please do yourself a favor and start using P1 and P2 if you stay with po only you will be in a challenging situation I will of course go into more depth on this topic in the full course and also explain how to work with risk control measures in software to reduce P1 and eventually even P2 thank you for watching this short course if you want to learn more about software as a medical device IEC 6204 and IEC 82304-1 I welcome you to sign up for the full online course introduction to sound IEC 6234 and IEC 82304-1 the food cause is similar to this short course but much more comprehensive with more in-depth information and quizzes at the end of each topic to test your knowledge and understanding at the end of the full course you will also receive a course certificate which many Auditors will be asking for at medical device hq.com we offer online courses public classroom courses as well as in-house training on safety risk management usability engineering design control quality management and clinical investigation for medical devices drop us a line on support at medical device hq.com if you would like to learn more about your options or receive a proposal all right to me on the same email address if you have questions relating to medical device development in general I hope to hear from you [Music]