EU Proposal of new regulation: what's new for software? - part 2
By Mitch on Friday, 12 October 2012, 06:42 - Regulations - Permalink
Here is the second part of my last article about EU Proposal of new regulation.
Changes between the two documents (continued)
Technical File
The annex II of the new directive details what shall be inside the technical file of a medical device. It has no equivalent in the current directive. I find it useful. Manufacturers have to browse the annexes I to VIII of the current directive to know what's exactly in the technical file.
More, the proposal talks about the summary technical documentation (STED). The STED is a technical file template issued by the Global Harmonization Task Force (GHTF). In an ideal world, one harmonized technical file could be submitted to every country where the GHTF template is accepted. Of course, this is far from reality. But the new proposal is a step forward.
Software is present in two sections of the technical file.
Section 1: device description and specification
The section 1.1.(i) requires a general description of the key functional elements, e.g. its parts/components (including software if appropriate).
This focus on software in the general descriptions is only here to remind manufacturers that software matters! It's true that the current directive doesn't require to describe whether software is embedded in the general description of the device.
Section 6: Product verification and validation
This section contains a sub-section 6.1 about preclinical and clinical data where software is mentioned.
The section 6.1.(b) requires a detailed information regarding test design, complete test or study protocols, methods of data analysis, in addition to data summaries and test conclusions regarding (...) software verification and validation.
That means that software verification and validation matters. The current directive states in its essential requirements that software shall be validated (see my last article).
The new directive expects that software is verified and validated, and that the records of these activities are present in the technical file. The new directive lists those records in parenthesis in section 6.1.(b):
- The software design and development process,
- Evidence of the validation of the software, as used in the finished device.
- This information should typically include summary results of all verification, validation and testing performed both in-house and in a simulated or actual user environment prior to final release.
- It should also address all of the different hardware configurations and, where applicable, operating systems identified in the information supplied by the manufacturer.
Wow! this is really accurate!
Manufacturers are expected to do testing either in-house, or in simulated environment, or in actual user environment. I can only applause to this statement.
Releasing a software without these 3 tests phases in the shortest path to software failure in the hands of the end-user.
Classification Rules
Good news, the classification rules don't change!
Rules 9 to 12 in annex IX of the current directive are relevant for software as they are considered as active (i.e. powered) medical devices.
The new directive lists the classification rules in Annex VII Classification Criteria.
When I mean they don't change, that's the way they're applied:
- Software embedded in medical devices take the class of the device,
- Software that drives or influences the use of a device take the class of the device,
- Standalone software independent of any other device, it is classified in its own right.
I was doubtful about the words "drives or influence" to be still present in the new directive. These two words are really subject to interpretation (and misinterpretation). Any change to those would have added confusion.
The rules 9 to 12 are still numbered rules 9 to 12 in the new directive. Their content hasn't changed, except for the paragraph about active implantable medical devices that was removed (it added certainly confusion to the AIMD directive).
So you won't have to redo the difficult analysis necessary to choose the class of your software.
No need to ask either a medium or a indian sorcerer to guess the class of your software. Enjoy!
Other points
The Unique Device Identification (UDI)
Unique Device Identification (UDI) doesn't mean a unique number for each instance of the software installed by the manufacturers or downloaded by the user. This kind of unique number still exist, like batch or lot number. Batch or lot number are relevant for embedded software, not for standalone software.
The UDI is made to identify the medical device. For embedded devices, the UDI is for the whole device, not the software. For standalone software, the UDI should be linked to the software name, not the version. Thus MySoftware V1.0 and MySoftware V2.0 should have the same UDI.
BTW, It could be a good idea to add a UDI field in the help/about window of a software.
Clinical Investigations
The Annex XIV.2.3 of the new directive requires that the Investigators Brochure contains pre-clinical testing and experimental data, in particular regarding in design calculations, in vitro tests, ex vivo tests, animal tests, mechanical or electrical tests, reliability tests, software verification and validation, performance tests, evaluation of biocompatibility and biological safety.
In the current directive, software verification and validation aren't namely required in the pre-clinical data.
I think that it would be very hazardous to use a software that hadn't verified before going to clinical tests. And that's actually what manufacturers do.
So, this is not a big deal.
Notified bodies
A word about the capabilities of personnel of Notified Bodies.
The new directive requires in the Annex VII.3.2.5 that the personnel responsible for carrying out product related review (e.g. design dossier review ... software validation shall have the proven qualification.
The proven qualification is sought in the degrees and 4 years of professional experience in health care, whilst two years of this experience shall be in the design, manufacture, testing or use of the device or technology to be assessed.
This means the Notified Bodies' personnel that assesses software shall have such professional experience.
The current directive doesn't go so much into details and requires only that the personnel possesses experience and knowledge sufficient to assess the medical functionality and performance of devices.
Thus experience in software is enforced by the new directive, for devices that are or embed software.
This can be a big deal!
Conclusion
From the point of view of software, the proposal of new directive doesn't change so much. I would rather say that it brings more details on what is expected to be found in the technical file to meet the essential requirements.
If a manufacturer already has a software development process compliant with EN IEC 62304, then there's almost nothing to change to be compliant with the proposal.
More, the classification rules aren't changed. This is a real relief, hence everybody should have to reclassify his medical devices if the rules had changed!
The major change is in the definition of an accessory. An article that assists the use of a medical device is an accessory to the medical device. The word is ambiguous and many software companions may fall in the category of accessories whereas they aren't today according to the current directive.
Bye
