EU Proposal of new regulation: what's new for software? - part 1
By Mitch on Monday, 8 October 2012, 11:13 - Regulations - Permalink
The proposal of new regulation for CE Mark of medical devices was unveiled last week. If you've not heard about it, you were in the desert without access to the internet.
I won't argue on the length of the document or the consequences of this possible new regulation on the early release of technologic improvements in the european market. I invite you to have a look at Mat's article.
What's new for software?
Let's see what's new for software in this proposal. To do so, I took my best PDF viewer and searched for "software" in the actual directive and in the new proposal.
Software matters
Whereas the word "software" appears in 4 paragraphs in 93/42 CE directive, it appears in 10 paragraphs in the proposal of new directive.
In the introduction of the proposal, the European Commission indicates that one reason to release this document is the need to adapt safety and performance requirements to technologic progress, for example in software.
I can only applause. I scan regularly the adverse events published by competent authorities of member states. And I see an increasing number of events where software failure is seen as cause or a root cause.
Changes between the two documents
This is a brand new document that has been released by the European Commission, this is not an amendment of the current directive. Let's see what's new and what's unchanged.
Definitions
Medical device and standalone software
In the current directive, the definition of software as a medical device was split between the definitions of a medical device in Article 1.1.2.a and the precisions about standalone software in the definition of an active medical device in Annex IX.I.1.4
The regulators have gathered the definition of software as a medical device and standalone software as an active medical device in Article 2.1. It doesn't change the definitions but clarifies them by putting everything in a single place.
Accessory
The definition of an accessory has changed in the proposal of new directive. An accessory is "an article which whilst not being a medical device, is intended by its manufacturer to be used together with one or several particular medical device(s) to specifically enable or assist the device(s) to be used in accordance with its/their intended purpose(s)"
In the current directive the word "assist" is not present. It means that some software that wasn't in the scope of the directive is now inside.
The word "enable" is simple to understand i.e. if the software is not present, the device can't be used. Thus the software is an accessory to the device.
The word "assist" is more ambiguous i.e. if the software is not present, the device may still be used.
This means that some kind of software, like a software companion to a medical device may fall inside the scope of the new directive.
For example, a dynamic html5 presentation of a surgical technique that is displayed in the OR to assist the surgeon in the use of surgical instruments could fall in the scope of the new directive.
General Safety and Performance Requirements
The Essential Requirements are renamed General Safety and Performance Requirements in the proposal of new directive. This title is closer to the title of requirements issued by the Global Harmonization Task Force (GHTF).
Req. #14 Software incorporated in devices and standalone software
The new requirement #14 replaces the current requirement #12.
The requirement #12.1 of the current directive states that electronic programmable systems must be designed to ensure the repeatability, reliability and performance of these systems according to the intended use.
This requirement is extended to software in the new requirement #14.1: Devices that incorporate electronic programmable systems (PEMS), including software, or standalone software that are devices in themselves, shall be designed to ensure repeatability, reliability and performance according to the intended use.
This clarifies a situation that had evolved since the release of the directive in 1993. Software is more and more present in medical devices. Since 1993, PEMS like FPGA and ASICS were followed by nano computers-on-a-chip embedded in devices. Quoting only PEMS sounded a bit old.
The requirement #12.1.a of the current directive states that
for devices which incorporate software or which are medical software in themselves, the software must be validated according to the state of the art taking into account the principles of development lifecycle, risk management, validation and verification.
This requirement is changed to the new requirement #14.2: For devices that incorporate software or for standalone software that are devices in themselves, the software shall be developed and manufactured according to the state of the art taking into account the principles of development life cycle, risk management, verification and validation.
The main difference is the word "validated" replaced by "developed". This is also a clarification of the way a software is designed.
The word "validated", though relevant, could be interpreted in a wrong manner by manufacturers. One could think that the development was not mandatory. I find the word "developed" is more articulate.
Once again, to my mind, these new requirements #14.1 and #14.2 are not a big deal. The EN IEC 62304 is an harmonized standard that requires exactly what's in the rules #14.1 and #14.2 of the new directive.
Manufacturers which apply the EN IEC 62304 won't see much difference with these new rules.
Req. #14.3 Software in mobile computing plaforms
This is a new requirement with no equivalent in the current directive. Even if it contains the "mobile" buzzword, this is not a "big" requirement.
It only states that software that are intended to be used in combination with mobile computing platforms shall be designed and manufactured taking into account the specific features of the mobile platform (e.g. size and contrast ratio of the screen) and the external factors related to their use (varying environment as regards to level of light or noise).
Do you feel disappointed? Yes, you could if you expected to have more information about mobile software. We don't have articulate criteria on what kind of mobile software falls into medical device and what kind doesn't. I think the distinction will come from the case law.
Req. #11 Interaction of devices with their environment
The new requirement #11 "Interaction of devices with their environment" replaces the current requirement #9 "Construction and environmental properties".
Two points are important for software in the new requirement:
Devices shall be designed and manufactured in such a way as to remove or reduce as far as possible and appropriate
- (b) the risk of use error due to the ergonomic features, human factors and the environment in which the device is intended to be used;
- (e) the risk associated with the possible negative interaction between software and the environment within which it operates and interacts;
These two points clarify the need of a risk analysis and appropriate mitigation actions for software interacting with its environment and with the users.
I find that this requirement is a kind of novelty in the directive, as it wasn't mentioned anywhere in the previous one that the interaction of software with its environment is risk prone.
This means that the risk analysis of software shall not be put apart from the risk analysis of the device, should the software be an accessory or embedded in the device.
I already saw risks analysis where software was put apart (for example a different spreadsheet for the device and for its software). Hazardous situations where software interacting with its environment is the root cause may be missed.
We've not seen very big difference for software in the new proposal, so far.
I continue in my next post the analysis of the differences between the new proposal and the current directive.
Bye.
