Software in Medical Devices – Update June 2013

Software in Medical Devices – Update

 We have previously written about various aspects of the software development process, especially, the verification and validation activities. We would like to present you with an update on what is happening in the regulatory arena and how the regulatory groups are checking up on what we are doing.

Software Recalls 2012

The estimate for software recalls by the FDA for 2012 is 173. The software recalls for 2011 were 177 and for 2010 were 76. So far there are quite a few software recalls in 2013.

New Standards/Guidances

There are a number of new guidances and standards released and soon to be released:

• 21 CFR 880.6310, Medical Device Data Systems, FDA – released. This standard relates to hardware or software products that transfer, store, convert formats, and display medical device data. This application can be defined as a medical device which is a Class I device instead of the classification of your system. It has been used by a number of companies to define gateways between systems.
• ISO 82304-1, Healthcare Software Systems – Part 1: General Requirements For Product Safety – to be released maybe later this year. There is a draft copy out. This relates to medical devices that are only software.
• MEDDEV 1/16, January 2012 – Guidelines on the qualification and classification of standalone software used in healthcare within the Regulatory framework of medical devices
• ISO/IEC TIR 80002-1:2009, Medical device software – Part 1: Guidance on the application of ISO 14971 to medical device software – refers to the risk analysis on the software. This is an interesting aspect as we tend to analyze the risks on a system level. There are thoughts on the subject and anyone interested, please contact me.
• ISO/IEC TR 80002-02, Medical device software – Part 2: Validation of software for regulated processes – to be released maybe later this year. This refers to software used in the all other aspects in the organization.
• IEC 80001-1:2010, Application of Risk Management for IT Network incorporating Medical Devices – This is the risk management doctrine for hospitals, etc. employing medical devices on the network. If you supply your system to a hospital, you may be requested to let the hospital know if you are 8001 compliant. Once we know more on this, we’ll update you.
• AAMI TIR45:2012, Guidance on the use of agile practices in the development of medical device software – This is a technical report from the AAMI on the use of Agile in the software development.
• AAMI/ANSI SW87:2012, Application of Quality Management System concepts to Medical Device Data Systems (MDDS) – provides guidance for Application of Quality Management System concepts to Medical Device Data Systems (MDDS)
• AAMI TIR on Guidance on Health Software Safety and Assurance – future release
• AAMI TIR on Classification of defects contributing to unacceptable risk in health software – future release

IEC 62304

The IEC 62304 (Software Development Life Cycle) is in the update process and the updates will be released in at least two phases. It is not clear how much this will impact current processes. As we get more info, we’ll keep you informed.

21 CFR Part 11

First of all, we have been asked by many about the update to 21 CFR Part 11 (electronic signatures and electronic records). The FDA had released previously that new Part 11 would be released in late 2006. As of now, it has not been released and the timetable for the release is “flexible”. Your guess is as good as everyone else’s guess. Part 11 is more stressed in pharmaceutical manufacturers and less in medical device companies. In May 2007, the FDA issued the Guidance for Industry  Computerized Systems Used in Clinical Investigations. This supplements the guidance for industry on Part 11 and the efforts required when applying these guidances to source data generated at clinical study sites. As more and more companies are getting into eCRFs (electronic clinical research forms) and EDC (electronic data capture), the need for stricter controls, especially in using the Internet for data transfer and storage, is required.

Software Reviews

We have found that the CE and FDA reviewers expect to see reviews on the software requirements, software design and the software validation. General and technical meeting summaries are not enough to show that you held a review. You should be able to show that you held these reviews and that there are summaries (we use the terms SRR – Software Requirements Review, SDR – Software Design Review and TRR – Test Readiness Review).

As a byproduct of the regulatory requests for these reviews, we have found them very helpful in determining the issues in a timely manner. Where once we would end up with arguments with the developers during the software validation whether the software requirements are really requirements (of course, the developers never bothered to read the SRS), we finalize the software requirements with the developers in the SRR after we made sure they read the document. Until they read the document and we hold the SRR, we don’t continue with preparations of the software validation documentation (STD). The TRR (held prior to starting the software validation) allows us to find out if there are any open bugs in the system and how they affect the requirements. Accordingly, we can postpone the validation until the system is ready (instead of running the validation only to have it fail) or we can modify the requirements.

In summary, the reviews are extremely helpful and should not be ignored.

Static Code Analysis

Static Code Analysis (SCA) is a pet subject we bring up in each update because the topic is very much evolving. About 6 years ago we brought back from a conference with the FDA the idea that the FDA can request your source code and then run a  SCA tool on the code. About 4 years ago we found my first Israel company who was required to send their source code, so we realized that this is serious business. Since then, the FDA has recommended using a SCA in many submissions but only lately, the FDA has started requesting to receive the SCA report (the first case was a Major Level Of Concern project). This doesn’t mean that the FDA will request it for all submissions, but the floodgates are open, and, if the FDA requests it, you have to send it.

Based upon our experiences, if you start using the SCA only after the FDA requests it, you will add about 2 – 3 months to your timetable (depending upon the size and complexity of the software) and will require a new software validation after the software is cleaned up.

We recommend that you think this through during the development phase, especially if you are a high-risk project (Major Level Of Concern, PMA, infusion pump, or any other special case). We feel that the FDA is going to require the SCA report standard for all submissions (it saves them the trouble of asking for it).

Software Verification

We have discovered that a good software verification prior to the software validation can save much time and money. As such, the verification should be performed by someone who is independent of the software development. This can be an independent V&V group in the organization, clinical persons, systems engineers or a sub-contractor. The person performing the verification should run the verification against a checklist detailing all of the tests to be run. The purpose of the verification is to find as many software (and hardware) bugs as possible. It’s not meant to be a dry run of the software validation as the software validation covers only a specific set of tests (as defined by the software requirements). Please don’t wait until it is very late in the project to start organizing the software verification as this should be started as soon as the first software build is ready.

Document Control

Document control is not a software issue but a quality issue. We are raising it here is because we find that many projects do not control the software documents properly and this is discovered during the external audit. It is very important to make sure the document revisions are updated according to the changes made and the documents approved. We have found (during our internal software) that software validations are performed on projects where the SRS, std and even the Risk Analysis are not approved.

Networks and Security

The concept of networks and security is a very open and painful subject. Does connecting the medical device to the Internet make the submission easier, harder or almost impossible to get through? Is it better to break up the submissions into a number of submissions, adding additional connectivity to each submission, or should we go for the whole pot on the first submission? There is no cut and dry answer for this, and we see different solutions for different products. This is a heavy topic that should be addressed by the company where applicable.

Assurance Cases

The FDA is beginning to require assurance cases for specific submissions (e.g., infusion pumps) and will extend this to other products. An assurance case is a formal method for demonstrating the validity of a claim by providing a convincing argument together with supporting its evidence. The assurance case presents a line of reasoning as would be found in a court of law to prove a particular point. The use of assurance cases is not new as a method but is new in its requirement by the FDA.

E-Submissions

The FDA is beginning the e-submissions for 510Ks. You can find the more information on the eSubmitter at http://www.fda.gov/Forindustry/FDAeSubmitter.

We will expound on these issues and more in the future and will update you accordingly. We will also try to get out the updates more often. If there are any questions or requests, please feel free to contact us at the email listed below.

Mike

 

Download the Full Update