SLIDE 1
Do not distribute or reproduce without permission 1 9/28/2016
contact@lne-america.com 1-301-495-0477 lne-america.com
Do not distribute or reproduce without permission 2 9/28/2016
contact@lne-america.com 1-301-495-0477 lne-america.com
LNE/G-MED North America, Inc Embedded Software in Medical Device : - - PowerPoint PPT Presentation
LNE/G-MED North America, Inc Embedded Software in Medical Device : - - PowerPoint PPT Presentation
contact@lne-america.com 1-301-495-0477 lne-america.com LNE/G-MED North America, Inc Embedded Software in Medical Device : Common Regulatory and Quality Misconceptions. 9/28/2016 Do not distribute or reproduce without
SLIDE 2
SLIDE 3
Do not distribute or reproduce without permission 3 9/28/2016
contact@lne-america.com 1-301-495-0477 lne-america.com
What is an embedded medical device software?
SLIDE 4
Do not distribute or reproduce without permission 4 9/28/2016
contact@lne-america.com 1-301-495-0477 lne-america.com
One of the areas of important development in medical devices has been the role of software, as an integral component of a medical devices.
SLIDE 5
Do not distribute or reproduce without permission 5 9/28/2016
contact@lne-america.com 1-301-495-0477 lne-america.com
Software: is defined as a set of instructions that processes input data and creates output data.
IMDRF/SaMD WG/N10FINAL:2013
Stand alone software: means software which is not incorporated in a medical device at the time of its placing on the market or its making available.
MEDDEV 2.1/6 July 2016
Medical device software SOFTWARE SYSTEM that has been developed for the purpose of being incorporated into the MEDICAL DEVICE being developed or that is intended for use as a MEDICAL DEVICE in its own right.
IEC 62304:2006
Definitions
SLIDE 6
Do not distribute or reproduce without permission 6 9/28/2016
contact@lne-america.com 1-301-495-0477 lne-america.com
The use of embedded software in medical devices is increasing rapidly. Any company active in this market must ensure the highest quality
- f
software development. By adopting and enforcing a demonstrable commitment to software quality, medical device developers are better positioned to meet regulatory requirements when developing embedded software.
Delivering healthy embedded SW
SLIDE 7
Do not distribute or reproduce without permission 7 9/28/2016
contact@lne-america.com 1-301-495-0477 lne-america.com
- software may be constructed either by coding (i.e., programming) or by assembling together
previously coded software components (e.g., from code libraries, off-the-shelf software, etc.) forming an integral part of medical device technology.
- Whether the medical device will be used in the home or in a hospital environment, system
failures are not an option. Making the right software development platform choice can help avoid problems and get the device to market on time and within budget.
What is MD software in general
Source: CDRH/ General Principles of Software Validation; Final Guidance for Industry and FDA Staff
SLIDE 8
Do not distribute or reproduce without permission 8 9/28/2016
contact@lne-america.com 1-301-495-0477 lne-america.com
- The software is often part of the Medical Device
Technology,
- Determining the safety and effectiveness of the MD
containing software, based on software intended use.
- The software must demonstrate that its use meets
the
- bjectives
without unacceptable risks.
SLIDE 9
Do not distribute or reproduce without permission 9 9/28/2016
contact@lne-america.com 1-301-495-0477 lne-america.com
Why and how does a software differ from hardware?
- A number of errors related to software are
introduced during the design phase.
- Software can be much more complex than hardware.
- It is difficult to fully test the software and test all
possible scenarios.
- Software includes often passive hidden defects.
- Software is more easily modified than the hardware.
Source: GPSV
SLIDE 10
Do not distribute or reproduce without permission 10 9/28/2016
contact@lne-america.com 1-301-495-0477 lne-america.com
- Blood Gas Analyzer & Monitors
- Cardio Machines
- Defibrillator
- Dialysis Machine
- Digital Thermometers
- Elecrtrocardiogram Devices
- Infusion & Insulin Pumps
- Glucose Meters & Portable Meters and Oximeters
Medical Applications in which Embedded Software has been deployed
SLIDE 11
Do not distribute or reproduce without permission 11 9/28/2016
contact@lne-america.com 1-301-495-0477 lne-america.com
It is necessary to clarify that software in its own right, when specifically intended by the manufacturer to be used for one or more of the medical purposes set out in the definition of a medical device, is a medical device. Software for general purposes when used in a healthcare setting is not a medical device. Requirements introduced by directive 93/42/EEC and directive 90/385/EEC)
SLIDE 12
Do not distribute or reproduce without permission 12 9/28/2016
contact@lne-america.com 1-301-495-0477 lne-america.com
The essential requirement
- f
Directives 93/42/EEC & 90/385/EEC (Annex 1 Article 12 Directive 93/42/EEC and Annex 1 Article 9 Directive 90/385/EEC): For devices which incorporate software or which are themselves medical software, the software must be validated on the basis of the state of the art, taking into account the principles of the development cycle as well as risk management, validation and verification.
The European regulatory context
SLIDE 13
Do not distribute or reproduce without permission 13 9/28/2016
contact@lne-america.com 1-301-495-0477 lne-america.com
Harmonized standards They are considered as voluntary standards in the field
- f new approaches directives.
However, they give a “presumption of conformity with essential requirements”. Notified bodies and competent authorities consider a harmonized standard as a preferred means to measure / determine the methods deployed by the manufacturer.
How to meet the essential requirements?
SLIDE 14
Do not distribute or reproduce without permission 14 9/28/2016
contact@lne-america.com 1-301-495-0477 lne-america.com
Marketing medical devices in Europe require demonstrating conformity to Essential Requirements and several Harmonized standards can be used to do so. EN 62304 is one of these
- standards. The standard provides a list of tasks and activities that
support the safe design and maintenance of medical device
- software. The goal of this is to ensure the software does what is
intended without causing any unacceptable risks. Therefore, EN 62304 relies heavily on Risk Management strategies.
Improving Code Quality While Complying with EN 62304
SLIDE 15
Do not distribute or reproduce without permission 15 9/28/2016
contact@lne-america.com 1-301-495-0477 lne-america.com
- This standard applies to the development and maintenance of medical
device SW when software is itself a medical device or when software is an embedded or integral part of the final medical device.
- This standard should be used in conjunction with other relevant standards
for the development of medical device: – ISO 13485 and ISO 14971 provides a management environment that establishes a basis for a company to develop products. – Safety standards such as IEC 60601-1 give specific instructions for creating safe MD. – For embedded MD Software, EN 62304 provides more detailed instructions on development and maintenance processes.
When to apply EN 62304
SLIDE 16
Do not distribute or reproduce without permission 16 9/28/2016
contact@lne-america.com 1-301-495-0477 lne-america.com
It identifies the requirements for each life cycle process. There are five main processes:
- Software Development
- Software Maintenance
- Software Risk Management
- Software Configuration Management
- Software problem resolution
EN 62304 Scope
SLIDE 17
Do not distribute or reproduce without permission 17 9/28/2016
contact@lne-america.com 1-301-495-0477 lne-america.com
It introduces a notion of software risk classification based on the hazards to which the software system can contribute to the patient, operator or other persons:
- Class A : No injuries or damage to health is possible
- Class B : Non-serious injury is possible
- Class C : Death or serious injury is possible
EN 62304 scope and classification
SLIDE 18
Do not distribute or reproduce without permission 18 9/28/2016
contact@lne-america.com 1-301-495-0477 lne-america.com
- Manufacturer must record the safety class of the software assigned to each software system
into the risk management file.
- When a software system is decomposed into SOFTWARE ITEMS, and when a SOFTWARE ITEM
is decomposed into further SOFTWARE ITEMS, such SOFTWARE ITEMS shall inherit the software safety classification of the original SOFTWARE ITEM (or SOFTWARE SYSTEM) unless the MANUFACTURER documents a rationale for classification into a different software safety
- class. Such a rationale shall explain how the new SOFTWARE ITEMS are segregated so that they
may be classified separately.
- For each SOFTWARE SYSTEM, until a software safety class is assigned, Class C requirements
shall apply.
How to document the class of the software?
SLIDE 19
Do not distribute or reproduce without permission 19 9/28/2016
contact@lne-america.com 1-301-495-0477 lne-america.com
For manufacturers of medical devices, IEC 60601-1 Edition 3.1 represents a significant departure from Edition 3.0 of the
- standard. While the application of risk management principles has
been clarified, the amended standard includes new requirements regarding essential performance, mandates usability engineering evaluations, and requires the adoption of a formal development life cycle process for software.
IEC 60601-1 Edition 3.1 Introduces New Product Safety Requirements
SLIDE 20
Do not distribute or reproduce without permission 20 9/28/2016
contact@lne-america.com 1-301-495-0477 lne-america.com
Programmable Electrical Medical Systems (PEMS) (Clause 14) Amendment 1 incorporates many of the specific requirements of EN 62304:2006, Medical Device Software Life Cycle Processes, which are applicable to equipment and systems whose operation depends on software or any programmable element (also known as PEMS). In addition, Amendment 1 incorporates validation requirements for equipment connected to a network.
IEC 60601-1 Edition 3.1 Introduces New Product Safety Requirements
SLIDE 21
Do not distribute or reproduce without permission 21 9/28/2016
contact@lne-america.com 1-301-495-0477 lne-america.com
In the European Union (EU), as of Dec. 31, 2017, compliance with the provisions of EN 60601-1: 2006 (equivalent to IEC 60601-1 Edition 3.0) will no longer be accepted as evidence of conformity with the essential requirements
- f the Directive.
In the U.S., both the FDA and OSHA are adopting ANSI/AAMI ES60601-1: 2005/(R2012) and A1:2012, C1:2009/(R)2012 and A2:2010/ (R)2012 = IEC 60601-1 Edition 3.1 but may have some national deviations that might trigger additional requirements for regulatory approval.
Regulatory Implementation Timetable for IEC 60601-1 Edition 3.1
SLIDE 22
Do not distribute or reproduce without permission 22 9/28/2016
contact@lne-america.com 1-301-495-0477 lne-america.com
For manufacturers, to achieve compliance with IEC 60601-1 Edition 3.1 a particular challenge will be the new requirements applicable to software and other programmable systems that are incorporated in medical electrical equipment. As the development or modification of software must now also apply additional processes (detailed in EN 62304:2006). In brief, manufacturers are required to establish a formal software development plan that addresses:
- The processes to be used in software development.
- Development deliverables.
- Traceability between system and software requirements.
- Software configuration and change management, including the use of “software of unknown
provenance” (SOUP), i.e., off-the-shelf software.
- Addressing problems detected in software products throughout the entire product life cycle. In
addition, the risk management plan required for medical electrical equipment must include a specific reference to the software validation plan (if applicable)
Special Considerations for Transitioning to IEC 60601-1 Edition 3.1
SLIDE 23
Do not distribute or reproduce without permission 23 9/28/2016
contact@lne-america.com 1-301-495-0477 lne-america.com
SOUP (acronym for «Software Of Unknown Provenance»)
SOFTWARE ITEM that is already developed and generally available and that has not been developed for the purpose of being incorporated into the MEDICAL DEVICE (also known as “off the- shelf software”) or software previously developed for which adequate records of the development PROCESSES are not available.
EN 62304 : Definitions to remember
SLIDE 24
Do not distribute or reproduce without permission 24 9/28/2016
contact@lne-america.com 1-301-495-0477 lne-america.com
- Do not forget to record the class of software system into the risk
management file (EN 62304 §4.3).
- Do not forget to refer to the risk management plan in the software
development plan (EN 62304 §5.1.7).
- Do not forget to re-evaluate the risk management file following the
updating of software requirements(EN 62304 §5.2.4).
- When a software defect is identified (isolated case or trend), do not forget
to assess the impact in the risk management process and to update the risk management file (EN 62304 §9.2).
Implementation of a risk management process applied to software, what manufacturers should not forget to do?
SLIDE 25
Do not distribute or reproduce without permission 25 9/28/2016
contact@lne-america.com 1-301-495-0477 lne-america.com
Manufacturers do not need re-create medical device software development process, yet they should confirm that processes and solutions adopted by them for the design and construction are in conformity with the harmonized standards (i.e. EN 62304) (standards giving a presumption of conformity to ER) OR demonstration that the alternative method adopted by the manufacturer still guarantees an elevated level of security and performance conforming to the state of the art.
Conclusion
SLIDE 26
Do not distribute or reproduce without permission 26 9/28/2016
contact@lne-america.com 1-301-495-0477 lne-america.com