Download pptx - Orcanos Café עידכונים ודרישות חדשות בתחום התוכנה למיכשור רפואי, ובנושא פיתוח תוכנה רפואית ב- Mobile Orcanos Dec

Orcanos Café עידכונים ודרישות חדשות בתחום התוכנה

למיכשור רפואי, ובנושא פיתוח תוכנה רפואית ב- Mobile

Orcanos Dec. 2013

2Copyright SoftQuest Systems 2013

Software Development and Validation – Updated Status

Mike Ze’eviSoftQuest Systemswww.softquest.co.ilemail: [email protected]

Copyright SoftQuest Systems 2013 3Copyright SoftQuest Systems 2013

Topics

What is the issue? Standards and guidances Verification and Validation SOUP General and summary


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


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