IEC 62304 an Introduction the Software Life Cycle for Medical Devices Version 04

Total Page:16

File Type:pdf, Size:1020Kb

Load more

IEC 62304 An introduction the Software Life Cycle for Medical Devices Version 04 Process Vision IEC62304 Medical Device Software – Life Cycle processes Sheet 1 Content • The IEC62304 and its environment • SW Classification • IEC62304 implementation • The IEC62304 step by step • General Requirements • Software Development • Software Risk Management • Software Configuration Management • Software Problem Resolution • Software Maintenance • SOUP Process Vision IEC62304 Medical Device Software – Life Cycle processes Sheet 2 But first who is who….. • Willem vd Biggelaar • Quality and Medical Regulatory Consultant for 15 years now • Certified DEKRA auditor for ISO 9001 / ISO 13485 • Setup ISO 13485 certified Quality Management Systems (QMS) • Previous jobs • Quality Assurance Officer (5 years) • System Tester (1 year) • Embedded software engineer (7 years) • And you? Process Vision IEC62304 Medical Device Software – Life Cycle processes Sheet 3 The IEC62304 and its environment Process Vision IEC62304 Medical Device Software – Life Cycle processes Sheet 4 Just to set the scope…….IEC62304:2006 v1.0 • Is the de-facto process standard for the development of medical device software • New 2.0 version on it’s way, version 1.1 already available but not harmonized Process Vision IEC62304 Medical Device Software – Life Cycle processes Sheet 5 Recognized by major markets (EU, USA, China) Process Vision IEC62304 Medical Device Software – Life Cycle processes Sheet 6 Regulatory framework Harmonized Standards presume conformance to GSPR Generic Product Standards examples Process Standards IEC 60601-1 Electrical Safety ISO 13485 QMS for MDR contains GSPR medical devices IEC 60601-1-2 EMC Regulatory Medical Device requirements ISO 14971 Risk IEC 60601-1-6 Usability Management European Medical Satisfy Fulfill Devices Regulate Particular Product Standards Regulation (2017/ IEC 62366 Useability examples 745/EC) Engineering IEC 60601-2-10 safety of nerve and muscle stimulators IEC 62304 Software Life Mandatory. You have to comply cycle IEC 60601-2-57 Non-laser light source equipment IEC 62471 Photobiological safety of lamps and lamp systems Voluntary but if you do not follow them,a lot of justification is needed European website where you can find the harmonized standards (based on current MDD): http://ec.europa.eu/growth/single-market/european-standards/harmonised-standards/medical-devices/index_en.htm Process Vision IEC62304 Medical Device Software – Life Cycle processes Sheet 7 Relation with other standards Standalone & embedded Embedded Standalone Health SW Medical Device SW Medical Device SW IEC62304 IEC60601-1 Medical Electrical Equipment IEC82304 Electrical equipment having an Medical Device Medical Electrical Health Software APPLIED PART or transferring energy to Software Equipment – Basic safety or from the PATIENT or detecting such Health SW energy transfer to or from the Any kind of software, which directly or Normative PATIENT and which is intended by its indirectly has an effect on health. Reference MANUFACTURER to be used as a MEDICAL E.g. Radiology Information Systems (RIS), DEVICE Prescription Management Systems (PMS), ISO14971 Laboratory Information Mngt Systems (LIMS) Risk Management ISO13485 IEC62366 Quality Systems Useability Process Vision IEC62304 Medical Device Software – Life Cycle processes Sheet 8 Out of scope of IEC62304: Validation • Standalone Software: IEC82304 Health Software • Embedded Software: IEC60601-1 Medical Electrical Equipment: Chapter 14: PEMS Process Vision IEC62304 Medical Device Software – Life Cycle processes Sheet 9 Relation with IEC60601-1 Medical Electrical Equipment Process Vision IEC62304 Medical Device Software – Life Cycle processes Sheet 10 Content IEC62304 1. Scope 2. Normative references 3. Terms and definitions 4. General Requirements 5. Software Development 6. Software Maintenance 7. Software Risk Management 8. Software Configuration Management 9. Software Problem Resolution 10. Annex A Rationale for the requirements of this standard 11. Annex B Guidance on the provisions of this standard 12. Annex C Relationship to other standards 13. Annex D Implementation Process Vision IEC62304 Medical Device Software – Life Cycle processes Sheet 11 Product creation in one picture Maintenance feedback & Change Management Field impact on change Installed Base Customer Stakeholder Change Timing, budget Hazards Request product product CM Item Configuration Risk Project / Product Management Management Management (CM) Project Plan Release Product Release Risk V&V Plan Baseline Management Design File Release Notes Reviews Requirements User Manual Problem Reports Control Risk / Benefit Measures analysis V&V Specs V&V Reports Requirements Requirements Verification & Management Specifications Validation (V&V) Peer Regression Reviews Tests Design Specs Peer Design & Software Code Reviews Implementation Process Vision IEC62304 Medical Device Software – Life Cycle processes Sheet 12 So what is IEC62304 about? Professional Software Development Process Vision IEC62304 Medical Device Software – Life Cycle processes Sheet 13 Software Classification Process Vision IEC62304 Medical Device Software – Life Cycle processes Sheet 14 Definition Software classification Class A No injury or damage to health possible Class B Non serious injury possible Class C Death or serious injury possible Dependent on the classification, more requirements from IEC62304 are to be implemented. The idea behind it is that The most unsafe SW requires the most strict SW process Process Vision IEC62304 Medical Device Software – Life Cycle processes Sheet 15 A B C 5 Software Development 22 46 52 5.1 Development Planning 7 10 11 5.2 Requirements Analysis 5 6 6 5.3 Architectural Design 0 4 5 5.4 Detailed Design 0 1 4 5.5 Software Unit Implementation 1 4 5 5.6 Integration and Testing 0 8 8 5.7 System Testing 5 5 5 Applicable clauses 5.8 Release 4 8 8 6 Software Maintenance 8 8 8 per class 6.1 Establish Software Maintenance Plan 1 1 1 6.2 Problem and Modification Analysis 5 5 5 6.3 Modification Implementation 2 2 2 7 Software Risk Management 1 12 12 7.1 Analysis of software contributing to Hazards 0 5 5 7.2 Risk Control Measures 0 2 2 7.3 Verification of Risk Control Measures 0 2 2 7.4 Risk Management of Software Changes 1 3 3 8 Software Configuration Management 7 7 7 8.1 Configuration Identification 3 3 3 8.2 Configuration Control 4 4 4 8.3 Configuration Status Accounting 1 1 1 9 Software Problem Resolution 8 8 8 Process Vision IEC62304 Medical Device Software – Life Cycle processes Sheet 16 Differences classification mostly in development • Class A • no architectural design • No detailed design • No unit verification testing • No integration testing • No evaluation of known residual anomalies • Class B • No detailed design Process Vision IEC62304 Medical Device Software – Life Cycle processes Sheet 17 SW Classification process in the IEC62304 Process Vision IEC62304 Medical Device Software – Life Cycle processes Sheet 18 Inheritance of safety class SW System C SW Item SW Item SW Unit A B C SW Unit SW Unit SW Unit SW Unit A A B B Process Vision IEC62304 Medical Device Software – Life Cycle processes Sheet 19 SW Classification process in the IEC62304 • By default the whole SW system is class C • You may use class A only if……(Quote from DEKRA notified body): SW Classification process • Perform the system risk analysis according to ISO14971 • Have the SW architecture defined • Filter out all hazards that have a SW component failure as source • Filter out all hazards that have SW component as control measure • Classify those SW components based on the severity of the hazard • If a HW control measure is defined, the classification can degrade Process Vision IEC62304 Medical Device Software – Life Cycle processes Sheet 21 Example – surgical robotic system – initial assessment • The system manipulates an instrument inside the organ. The software of the system has full control over this manipulation and can cause serious injuries. Therefore, the software system as a whole is treated as safety class C, with certain subsystems having a lower safety class A. • All complexity and safety-critical aspects are centered in one subsystem. • Application Software subsystem – Class C Includes state control, robotic motion control and a safety layer. The state control controls the states of the system. The robotic motion control controls the manipulation motion of the surgical instrument • Service SW subsystem – Class A • User Interface (GUI) SW subsystem – Class A • Firmware (FW) Software subsystem – Class A Process Vision IEC62304 Medical Device Software – Life Cycle processes Sheet 22 Example Lung function measuring device – full assessment measure, calculate and present lung function parameters without any diagnosis. NO FORCED EXHALATION IS REQUIRED AS IN SPIROMETRY; PULMONARY FUNCTION VALUES ARE OBTAINED DURING TIDAL BREATHING both the single occlusion technique (SOT) and the interrupter technique (RINT) can be done. In addition, tidal flow volume (TFV) loops can be monitored and analysed Example Lung function measuring device Process Vision IEC62304 Medical Device Software – Life Cycle processes Sheet 24 Example Lung function measuring device Process Vision IEC62304 Medical Device Software – Life Cycle processes Sheet 25 Example Lung function measuring device Process Vision IEC62304 Medical Device Software – Life Cycle processes Sheet 26 Process Vision IEC62304 Medical Device Software – Life Cycle processes Sheet 27 Example Lung function measuring device Process Vision
Recommended publications
  • Medical Devices

    Medical Devices

    FRAUNHOFER INSTITUTE FOR EXPERIMENTAL SOFTWARE ENGINEERING IESE MEDICAL DEVICES Contact Fraunhofer Institute for Experimental Software Engineering IESE Ralf Kalmar Software is a part of our lives. Embedded into everyday equipment, into living and working en- [email protected] vironments or modern means of transportation, countless processors and controllers make our Phone: +49 631 6800-1603 lives simpler, safer, and more pleasant. We help organizations to develop software systems that www.iese.fraunhofer.de are dependable in every aspect, and empirically validate the necessary processes, methods, and techniques, emphasizing engineering-style principles such as measurability and transparency. Fraunhofer Institute for The Fraunhofer Institute for Experimental Software Engineering IESE in Kaiserslautern has been Experimental Software one of the world’s leading research institutes in the area of software and systems engineering Engineering IESE for more than 20 years. Its researchers have contributed their expertise in the areas of Process- es, Architecture, Security, Safety, Requirements Engineering, and User Experience in more than Fraunhofer-Platz 1 1,200 projects. 67663 Kaiserslautern Germany Under the leadership of Prof. Peter Liggesmeyer, Fraunhofer IESE is working on innovative topics related to digital ecosystems, such as Industrie 4.0, Big Data, and Cyber-Security. As a technology and innovation partner for the digital transformation in the areas of Autonomous & Cyber-Physical Systems and Digital Services, the institute’s research focuses on the interaction between embedded systems and information systems in digital ecosystems. Fraunhofer IESE is one of 72 institutes and research units of the Fraunhofer-Gesellschaft. To- gether they have a major impact on shaping applied research in Europe and contribute to Ger- many’s competitiveness in international markets.
  • ECSO State of the Art Syllabus V1 ABOUT ECSO

    ECSO State of the Art Syllabus V1 ABOUT ECSO

    STATE OF THE ART SYLLABUS Overview of existing Cybersecurity standards and certification schemes WG1 I Standardisation, certification, labelling and supply chain management JUNE 2017 ECSO State of the Art Syllabus v1 ABOUT ECSO The European Cyber Security Organisation (ECSO) ASBL is a fully self-financed non-for-profit organisation under the Belgian law, established in June 2016. ECSO represents the contractual counterpart to the European Commission for the implementation of the Cyber Security contractual Public-Private Partnership (cPPP). ECSO members include a wide variety of stakeholders across EU Member States, EEA / EFTA Countries and H2020 associated countries, such as large companies, SMEs and Start-ups, research centres, universities, end-users, operators, clusters and association as well as European Member State’s local, regional and national administrations. More information about ECSO and its work can be found at www.ecs-org.eu. Contact For queries in relation to this document, please use [email protected]. For media enquiries about this document, please use [email protected]. Disclaimer The document was intended for reference purposes by ECSO WG1 and was allowed to be distributed outside ECSO. Despite the authors’ best efforts, no guarantee is given that the information in this document is complete and accurate. Readers of this document are encouraged to send any missing information or corrections to the ECSO WG1, please use [email protected]. This document integrates the contributions received from ECSO members until April 2017. Cybersecurity is a very dynamic field. As a result, standards and schemes for assessing Cybersecurity are being developed and updated frequently.
  • Thesis and Dissertation Template

    Thesis and Dissertation Template

    DEVELOPMENT OF A QUALITY MANAGEMENT ASSESSMENT TOOL TO EVALUATE SOFTWARE USING SOFTWARE QUALITY MANAGEMENT BEST PRACTICES Item Type Other Authors Erukulapati, Kishore Publisher Cunningham Memorial library, Terre Haute,Indiana State University Download date 23/09/2021 23:31:43 Link to Item http://hdl.handle.net/10484/12347 DEVELOPMENT OF A QUALITY MANAGEMENT ASSESSMENT TOOL TO EVALUATE SOFTWARE USING SOFTWARE QUALITY MANAGEMENT BEST PRACTICES _______________________ A Dissertation Presented to The College of Graduate and Professional Studies College of Technology Indiana State University Terre Haute, Indiana ______________________ In Partial Fulfillment of the Requirements for the Degree Doctor of Philosophy _______________________ by Kishore Erukulapati December 2017 © Kishore Erukulapati 2017 Keywords: Software Quality, Technology Management, Software Quality Management, Bibliometric techniques, Best Practices VITA Kishore Erukulapati EDUCATION Ph.D. Indiana State University (ISU), Terre Haute, IN. Technology Management, 2017. M.S. California State University (CSU), Dominguez Hills, CA. Quality Assurance, 2011. B.Tech. National Institute of Technology (NIT), Calicut, Kerala, India. Computer Science and Engineering, 1996. INDUSTRIAL EXPERIENCE 2011-Present Hawaii Medical Service Association. Position: Senior IT Consultant. 2008-2010 Telvent. Position: Operations Manager. 2008-2008 ACG Tech Systems. Position: Test Manager. 2000-2008 IBM Global Services. Position: Project Manager. 1996-2000 Tata Consultancy Services. Position: System Analyst. PUBLICATIONS/PRESENTATIONS Erukulapati, K., & Sinn, J. W. (2017). Better Intelligence. Quality Progress, 50 (9), 34-40. Erukulapati, K. (2016). What Can Software Quality Engineering Contribute to Cybersecurity?. Software Quality Professional, 19(1). Erukulapati, K. (2015, Dec 2). Information Technology in Healthcare: Current Status and Future Perspectives. Presented at IEEE Hawaii Chapter - Computer Society Meeting, Honolulu, Hawaii.
  • Quality Factors for Mobile Medical Apps

    Quality Factors for Mobile Medical Apps

    _________________________________________________________________________________________________________________Proceedings of the Central European Conference on Information and Intelligent Systems 229 Quality Factors for Mobile Medical Apps Nadica Hrgarek Lechner Vjeran Strahonja MED-EL Elektromedizinische Geräte GmbH Faculty of Organization and Informatics Fürstenweg 77, 6020 Innsbruck, Austria Pavlinska 2, 42000 Varaždin, Croatia [email protected] [email protected] Abstract. The increased use of mobile phones, less in healthcare. According to a report from the smartphones, tablets, and connected wearable devices business consulting firm Grand Review Research, Inc. has fostered the development of mobile medical (2016), the global connected health and wellness applications (apps) in the last few years. Mobile devices market is expected to reach USD 612.0 billion medical apps are developed to extend or replace some by 2024. existing applications that run on a desktop or laptop The results of the sixth annual study on mobile computer, or on a remote server. health app publishing done by research2guidance If mobile apps are used, for example, to diagnose, (2016) are based on 2,600 plus respondents who mitigate, treat, cure, or prevent human diseases, participated in the online survey. As displayed in Fig. patient safety is at potential risk if the apps do not 1, remote monitoring, diagnostic, and medical function as intended. Therefore, such apps need to be condition management apps are the top three mHealth cleared, approved, or otherwise regulated in order to app types offering the highest market potential in the protect public health. next five years. In 2016, 32% of total respondents There are many papers that have been published predicted remote monitoring apps as the app category about the quality attributes of mobile apps.
  • Relevant Norms and Standards

    Relevant Norms and Standards

    Appendix A Relevant norms and standards A.1 A Short Overview of the Most Relevant Process Standards There is a huge number of different process standards, and Fig. A.1 contains an overview of the most relevant such standards as covered in this book, showing the topics covered. A more extensive list of the relevant standards will be provided in the following section below. ISO/IEC 15504, ISO 19011 ISO/IEC 330xx Auditing man- agement systems Process Process assessment ISO/IEC 20000-1 ISO 9001 ISO/IEC 15504-6 ISO/IEC 15504-5 Service management QM system re- System life cycle PAM Software life cycle PAM Assessments, audits Criteria system requirements quirements ISO/IEC/IEEE 15288 ISO/IEC/IEEE 12207 ITIL System life cy- Software life cy- IT Infrastruc- cle processes cle processes ture Library COBIT Life cycle processes SWEBoK Software engineering Funda- Body of Knowledge mentals ISO/IEC/IEEE 24765 ISO 9000 Systems and SW Engineering Vocabulary QM fundamentals (SEVOCAB) and vocabulary Vocabulary Systems Software Organzational IT Quality Management Engineering Engineering Fig. A.1 Overview of the most important standards for software processes © Springer Nature Switzerland AG 2018 327 R. Kneuper, Software Processes and Life Cycle Models, https://doi.org/10.1007/978-3-319-98845-0 328 A Relevant norms and standards A.2 ISO and IEC Standards The International Organization for Standardization (ISO) is the main international standard-setting organisation, working with representatives from many national standard-setting organisations. Standards referring to electrical, electronic and re- lated technologies, including software, are often published jointly with its sister organisation, the International Electrotechnical Commission (IEC), but IEC also publishes a number of standards on their own.
  • FI-STAR Deliverable D1.1 Has Already Discussed Legal Requirements Related to Data Security Breach Notifications

    FI-STAR Deliverable D1.1 Has Already Discussed Legal Requirements Related to Data Security Breach Notifications

    Ref. Ares(2014)706091 - 13/03/2014 Deliverable D2.1 Standardisation and Certification requirements Editor: Franck Le Gall, easy global markets Deliverable nature: Report (R) Dissemination level: Public (PU) (Confidentiality) Contractual delivery Dec. 2013 date: Actual delivery date: Jan. 2014 Suggested readers: Version: 1.1 Total number of 74 pages: Keywords: Standardisation, certification Abstract This document details the technical requirements resulting from existing standards and prepares future certification process. FI-STAR FP7-ICT-604691 D1.2 Standardisation and Certification requirements Disclaimer This document contains material, which is the copyright of certain FI-STAR consortium parties, and may not be reproduced or copied without permission. All FI-STAR consortium parties have agreed to full publication of this document. The commercial use of any information contained in this document may require a license from the proprietor of that information. Neither the FI-STAR consortium as a whole, nor a certain part of the FI-STAR consortium, warrant that the information contained in this document is capable of use, nor that use of the information is free from risk, accepting no liability for loss or damage suffered by any person using this information. This project has received funding from the European Union’s Seventh Framework Programme for research, technological development and demonstration under grant agreement no 604691. Impressum [Full project title] Future Internet Social and Technological Alignment Research [Short project
  • Open Source Software Security a Research Summary December 2020

    Open Source Software Security a Research Summary December 2020

    Open Source Software Security A research summary December 2020 Table of Contents Executive Summary ......................................................................................................... 5 Welcome ........................................................................................................................... 6 Introduction ...................................................................................................................... 7 Background ...................................................................................................................... 9 Systems-level Approach ..................................................................................................... 9 Component-level approach............................................................................................... 12 Research Topics ............................................................................................................. 13 Research Overview ........................................................................................................ 14 National Telecoms and Information Administration (NTIA) ............................................... 15 SAFECode.org ................................................................................................................. 19 OWASP ( https://owasp.org ) ............................................................................................ 25 OASIS Open Standards, Open Source (OASIS)..............................................................
  • Best Practices for Dealing with Offshore Software Development

    Best Practices for Dealing with Offshore Software Development

    Best Practices for Dealing with Offshore Software Development by David A. Vogel, Ph.D. and Jill E. Connolly Intertech Engineering Associates, Inc. as published in Handbook of Business Strategy 2005 Is cost the only benefit to offshore outsourcing, Advantages of Offshore Outsourcing or are there others? Do you give up anything For US companies to endure the disadvantages of for the cost savings? The purpose of this offshoring listed below, the advantages need to be article is to examine why US companies substantial. Advantages reported by US companies outsource software development offshore, and that have experience with offshoring: to determine whether the benefits of offshore • The most powerful attraction is significant outsourcing outweigh the drawbacks. cost savings. US companies are finding that offshoring their software development ffshore outsourcing (offshoring) of software saves them money because of lower labor development has been an increasingly popular costs. For example, Otis Elevator Company trend in recent years. The cost benefits are O COMPANY PROFILE easy to understand when you consider that the average annual salary for an engineer in the USA is $70,000 Intertech Engineering Associates, Inc. in 2004, compared with a $13,580 average salary for an engineer in India, according to Electronic Business Address: 100 Lowder Brook Avenue magazine. Suite 2500 Westwood, MA 02090 Is offshoring worth it? Are the cost savings as large www.inea.com - (781) 801-1100 as they seem? Is quality of the software sacrificed Industry: (Electro)Medical
  • Nr. Standard Reference Title 1 IEC 60317-4:2015

    Nr. Standard Reference Title 1 IEC 60317-4:2015

    Nr. Standard reference Title Specifications for particular types of winding wires - Part 4: Solderable 1 IEC 60317-4:2015 polyurethane enamelled round copper wire, class 130 Appliance couplers for household and similar general purposes - Part 1: 2 IEC 60320-1:2015 General requirements Amendment 1 - Low-voltage electrical installations – Part 4-44: Protection IEC 60364-4- 3 for safety – Protection against voltage disturbances and electromagnetic 44:2007/AMD1:2015 PRV disturbances IEC 60364-5- Amendment 2 - Electrical installations of buildings – Part 5-53: Selection 4 53:2001/AMD2:2015 PRV and erection of electrical equipment – Isolation, switching and control Corrigendum 1 - High-voltage swithgear and controlgear - Part 200: AC IEC 62271- 5 metal-enclosed switchgear and controlgear for rated voltages above 1 kV 200:2011/COR1:2015 and up to and including 52 kV IEC/IEEE 62271-37- High-voltage switchgear and controlgear – Part 37-013: Alternating-current 6 013:2015 PRV generator circuit-breakers Photobiological safety of lamps and lamp systems - Part 5: Image 7 IEC 62471-5:2015 projectors LEDsi lamps for general lighting services with supply voltages not 8 IEC 62838:2015 PRV exceeding 50 V a.c. r.m.s. or 120 V ripple free d.c. – Safety specifications IEC Corrigendum 1 - Amendment 1 - Self-ballasted LED-lamps for general 9 62560:2011/AMD1:2015/CO lighting services by voltages >50 V - Safety specifications R1:2015 Electrical installations for lighting and beaconing of aerodromes – Safety 10 IEC 62870:2015 PRV secondary circuits in series circuits
  • Proceedings 2014 Download

    Proceedings 2014 Download

    EuroSPI² 2014 Proceedings Proceedings The papers in this book comprise the industrial proceedings of the EuroSPI² 2014 conference. They reflect the authors’ opinions and, in the interests of timely dissemination, are published as presented and without change. Their inclusion in this publication does not necessarily constitute endorsement by EuroSPI² and the publisher. DELTA Series about Process Improvement – ISBN 978-87-7398-157-3. EuroSPI² EuroSPI² is a partnership of large Scandinavian research companies and experience networks (SINTEF, DELTA, FiSMA), iSQI as a large German quality association, the American Society for Quality SW Division, and ISCN as the co-ordinating partner. The EuroSPI² conference presents and discusses results from systems, software and services process improvement and innovation (SPI) projects in industry and research, focusing on the gained benefits and the criteria for success. This year's event is the 21st of a series of conferences to which international researchers and professionals contribute their lessons learned and share their knowledge as they work towards the next higher level of software management professionalism. Since 2009 we have extended the scope of the conference from software process improvement to systems, software and service based process improvement. The Centre de Recherche Public Henri Tudor, Luxembourg, is the host of the EuroSPI² 2014 conference. CRP Henri Tudor is currently leading research projects in the areas of Advanced Materials Technologies, Health care technologies, Information
  • Zephyr Overview 091520.Pdf

    Zephyr Overview 091520.Pdf

    Zephyr Project: Unlocking Innovation with an Open Source RTOS Kate Stewart @_kate_stewart [email protected] Copyright © 2020 The Linux Foundation. Made avaiilable under Attribution-ShareAlike 4.0 International Zephyr Project Open Source, RTOS, Connected, Embedded • Open source real time operating system Fits where Linux is too big • Vibrant Community participation • Built with safety and security in mind • Cross-architecture with broad SoC and Zephyr OS development board support. 3rd Party Libraries • Vendor Neutral governance Application Services • Permissively licensed - Apache 2.0 OS Services • Complete, fully integrated, highly Kernel configurable, modular for flexibility HAL • Product development ready using LTS includes security updates • Certification ready with Auditable Products Running Zephyr Today Grush Gaming hereO Proglove Rigado IoT Gateway Distancer Toothbrush Smartwatch Ellcie-Healthy Smart Intellinium Safety Anicare Reindeer GNARBOX 2.0 SSD Adero Tracking Devices Sentrius Connected Eyewear Shoes Tracker GEPS Point Home Alarm RUUVI Node HereO Core Box Safety Pod Zephyr Supported Hardware Architectures Cortex-M, Cortex-R & Cortex-A X86 & x86_64 32 & 64 bit Xtensa Coming soon: Native Execution on a POSIX-compliant OS • Build Zephyr as native Linux application • Enable large scale simulation of network or Bluetooth tests without involving HW • Improve test coverage of application layers • Use any native tools available for debugging and profiling • Develop GUI applications entirely on the desktop • Optionally connect
  • Software Process Improvement Roadmaps – Using Design Patterns to Aid SME’S Developing Medical Device Software in the Implementation of IEC 62304

    Software Process Improvement Roadmaps – Using Design Patterns to Aid SME’S Developing Medical Device Software in the Implementation of IEC 62304

    Software Process Improvement Roadmaps – Using Design Patterns to Aid SME’s Developing Medical Device Software in the Implementation of IEC 62304 Peter Rust, Derek Flood, Fergal McCaffery Regulated Software Research Centre & Lero, Dundalk Institute of Technology, Dundalk, Ireland {peter.rust, derek.flood, fergal.mccaffery}@dkit.ie Abstract. One stated objective of the European Union is to encourage SME’s expand their area of operation into other domains. The medical device domain is one such domain identified by the EU. Medical device software development must be carried out in a manner that compliance with certain medical device standards and regulations can be demonstrat- ed. IEC 62304, Medical device software - software life cycle processes, is a standard that defines the processes that are required to be executed in or- der to develop safe software. SME software development organizations wishing to expand their operations into the medical device software devel- opment domain face serious challenges in demonstrating compliance with IEC 62304. The standard describes the set of processes, activities, and tasks that are required to be carried out, but importantly do not describe how they should be carried out. This paper describes the development of a roadmap that will aid software development SME’s, entering the medical device software development domain, by the use of design patterns to gen- erate “How-to” artefacts, overcome the challenge of demonstrating com- pliance. Keywords: SME’s, Medical device software, medical device standards, regulatory compliance, software roadmap, Software Process Improvement, Software Process Improvement Roadmaps, IEC 62304, Design Patterns 1 Introduction In Europe, the medtech industry generates over €100 billion annually and em- ploys approximately 575,000 people.