300 likes | 442 Views
Orcanos Café עידכונים ודרישות חדשות בתחום התוכנה למיכשור רפואי, ובנושא פיתוח תוכנה רפואית ב- Mobile. Orcanos Dec. 2013. Software Development and Validation – Updated Status. Mike Ze ’ evi SoftQuest Systems www.softquest.co.il email: mikez@softquest.co.il. Topics . What is the issue?
E N D
Orcanos Café עידכונים ודרישות חדשות בתחום התוכנה למיכשור רפואי, ובנושא פיתוח תוכנה רפואית ב- Mobile OrcanosDec. 2013
Software Development and Validation – Updated Status Mike Ze’eviSoftQuest Systems www.softquest.co.il email: mikez@softquest.co.il
Topics • What is the issue? • Standards and guidances • Verification and Validation • SOUP • General and summary
FDA Annual Report 2011 • Software Failures Responsible for 24% of all Medical Device Recalls • The absence of solid architecture and "principled engineering practices" in software development affects a wide range of medical devices, with potentially life-threatening consequences.
FDA Annual Report 2011 • The agency has come under fire in recent years for not holding manufacturers' accountable for insecure or poorly written software. • "Manufacturers are responsible for identifying risks and hazards associated with medical device software (or) firmware, including risks related to security, and are responsible for putting appropriate mitigations in place to address patient safety."
Software in the Medical Device Medical Device Software can be • part of the medical device itself • an accessory to the medical device • the medical device itself
FDA Software Development Standards • General Principles of Software Validation, FDA, CDRH, 11/1/02 • Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices, FDA, CDRH, 11/5/05 • Off-The-Shelf Software Use in Medical DevicesFDA, CDRH, 9/9/99
62304 • Edition 1 • Approved 2006 • FDA approved it as a consensus standard • CE approved as standard for software development • Edition 2 • Should be released Q1/2014 • Interim updates for future major release • Advance draft copy available • Adds flow for determining Software Safety Classification • Relates to validation of legacy software • Miscellaneous clarifications and technical changes
62304 Continued • Capability assessment will become a separate Technical Report • Assessment TR expected during 2014 • Second edition expected 2015/2016
60601 • 3rd edition released 2005 • Amendment 1 released 7/12 • Known as edition 3.1 • Risk management according to IEC 14971:2007 • Software development lifecycle according to IEC 62304:2006 • Usability engineering according to IEC 62366:2007
Risk Management Standards • ISO 14971:2007, Second edition, Medical devices – Application of risk management to medical devices • EN 2009, EN 2012 updates • ISO/TR 24971:2013, Medical devices - Guidance on the application of ISO 14971 • OD-2044 Ed. 2.0, Evaluation of Risk Management in medical electrical equipment
82304-1 • IEC 82304-1 Health Software • Draft status • Draft copy available • Relates to standalone health software (software intended to be used specifically for maintaining or improving health of individual persons, or the delivery of care) • Should be released during 2014
Medical Device Data Systems - MDDS • 21 CFR 880.6310, Medical Device Data Systems, FDA • Hardware or software products that transfer, store, convert formats, and display medical device data • SW87:2012, Application of quality management system concepts to medical device data systems
Agile Software Development • AAMI TIR45:2012, Guidance on the use of agile practices in the development of medical device software
80002-1 • IEC TIR 80002-1:2009 Medical device software - Part 1: Guidance on the application of ISO 14971 to medical device software • Released in 2009 • Relates to the software risk analysis on the operational software in the formal risk management process
80002-2 • IEC/TIR 80002-2, Validation of software for regulated processes • Draft, due to be released in 2014 • Current guidance is TIR36:2007
Mobile Medical Applications • Mobile Medical Applications, FDA, CDRH, 25/9/13 • What is a mobile medical application? • Mobile apps are software programs that run on smartphones and other mobile communication devices. They can also be accessories that attach to a smartphone or other mobile communication devices, or a combination of accessories and software. • Mobile medical apps are medical devices that are mobile apps, meet the definition of a medical device and are an accessory to a regulated medical device or transform a mobile platform into a regulated medical device.
Mobile Medical Applications - Continued • The FDA is taking a tailored, risk-based approach that focuses on the small subset of mobile apps that meet the regulatory definition of “device” and that: • are intended to be used as an accessory to a regulated medical device, or • transform a mobile platform into a regulated medical device. • Mobile apps span a wide range of health functions. While many mobile apps carry minimal risk, those that can pose a greater risk to patients will require FDA review.
80001 • Application of risk management for IT-networks incorporating medical devices • IEC 80001-1:2010, Part 1: Roles, responsibilities and activities • IEC 80001-2-1:2012, Part 2-1: Step by step risk management of medical IT-networks - Practical applications and examples • IEC 80001-2-2:2012, Part 2-2: Guidance for the disclosure and communication of medical device security needs, risks and controls • IEC 80001-2-3:2012, Part 2-3: Guidance for wireless networks • IEC 80001-2-4:2012, Part 2-4: General implementation guidance for Healthcare Delivery Organizations
FDA Guidances • Content of Premarket Submissions for Management of Cybersecurity in Medical Devices, draft, 14/6/13 • Radio Frequency Wireless Technology in Medical Devices, 14/8/13 • Global Unique Device Identification Database(GUDID) – draft, 9/13
Patient-Centric Integrated Clinical Environment (ICE) • ASTM F2761-09 (2013), Medical Devices and Medical Systems — Essential safety requirements for equipment comprising patient-centric integrated clinical environment (ICE) — Part 1: General requirements for network control
Future Software TIRs • AAMI TIR on Guidance on Health Software Safety and Assurance • AAMI TIR on Classification of defects contributing to unacceptable risk in health software
Software Verification and Validation • Verification – provides objective evidence that the design outputs of a particular phase of the software development life cycle meet all of the specified requirements for that phase; did we build the software correctly? • Validation – confirmation by examination and provision of objective evidence that software specifications conform to user needs and intended uses, and that the particular requirements implemented through software can be consistently fulfilled; did we build the correct software?
Software Validation Review Model • To ensure that the software validation regulatory requirement has been met • To ensure that the software validation is sufficient based upon the complexity and risk of the software
Additional Issues • Process and documentation • SOUP • Source code • Security and Cybersecurity • Mobile apps • Internet • . . .
SOUP – Software Of Unknown Provenance • Legacy software in the organization • Software developed for other projects in the organization • Procured software without source code • Open source software
FDA Issues – Source Code • The FDA have requested from companies to submit their source code for review or submit the SCA Report • The code is reverse engineered to show the detailed design, which is then reviewed by the FDA • The code is analyzed using a Static Analysis tool, which serves as a basis to conclude if the code is “safe”
FDA - Static Analysis • There are a number of tools that the FDA uses, including: Coverity, Polyspace, Parasoft, PQRA, Klocwork, Grammatech, Code Sonar • If a recognized static code analysis tools is used in the project, the report may be submitted instead of the source code. • According to various sources, the probability of the FDA requesting the source code for infusion pump software is high.
Looking Ahead • Have a good software process defined in a procedure that is practical and affordable • Even if using sub-contractors, have them work according to your defined software procedure, and monitor their work • Software documentation should be correct, concise, compliant, controlled and complete
Summary • Software in medical devices should be related to seriously • Documentation and testing are closely reviewed • Do it right and don’t overkill • Define the process and work accordingly • Use professionals