Learn how to safely pass the medical device approval process

Sie befinden sich hier:
Software: Intro
authorsymbol
Prof. Dr. Christian Johner
authorsymbol
Quality Managers, Developers, Regulatory Affairs Managers, Project Managers
Foundation
Nicht verfügbar
authorsymbol
veröffentlicht am 13.05.16
Welcome to our video training in the series on how to develop and document medical software. In this first part you will get to know the regulatory requirements of both, European legislative authorities and the FDA. This gives you an overview on the documents you have to compile when developing medical software. You will learn about current trends related to problems that the authorities report and thereby about the auditors’ focus.
Kapitel
Es sind keine Kapitel verfügbar

Welcome

Welcome to our video training in the series on how to develop and document medical software.

In this first part you will get to know the regulatory requirements of both, European legislative authorities and the FDA. This gives you an overview on the documents you have to compile when developing medical software.

You will learn about current trends related to problems that the authorities report and thereby about the auditors’ focus.

Start

This and the subsequent video trainings shell assist you manifold:

     

  • First they will help you to avoid problems during audits
  • Second they will guide you reducing overhead and streamlining your software development
  • And third they will show how to significantly reduce the number of software problems. In other words: How to develop better software.
  •  

Instead of being stressed by fixing software bugs and struggling with delayed projects you will find the time to creatively develop innovative software applications; with a predictable quality in a predictable time.

Regulations Overview

You most probably already have seen the video trainings on the regulatory framework. Therefore you know that in Europe the most relevant regulation are the European directives in particular the medical device directive. This directive defines so call “essential requirements” any medical device has to fulfill. For software the most relevant requirements are risk management, usability engineering and software life cycle. The quality management system is not an essential requirement.

In this series of video trainings the software life cycle is of particular interest.

MDD

The MDD contains just one sentence directly addressing software. The claim is clear:

     

  • Manufacturers have to develop software according to a life cycle,
  • have to apply risk management and
  • have to verify and validate the software.
  •  

In particular the life cycle is worth emphasizing: The mindset of some companies that development starts with the first and ends with the last line of code is a no-go. And testing – verification and validation – is not enough either.

62304

The recommended approach to prove compliance with this essential requirement is to work compliant with the harmonized standard IEC 62304. This standard requires that manufacturers define - among other processes – a software development process.

Every 62304 compliant software development process definition has to address

     

  • a software development plan,
  • the specification of software requirements,
  • the documentation of the software architecture and the detailed design,
  • the unit verification,
  • the integration and system tests and
  • the software release.
  •  

The next videos trainings will cover all these activities and requirements in more depth. However, already now the scope of documentation becomes clearer: Each of these activities is described typically in one or more documents. So we are talking about nine or more documents together constituting the “software file”.

FDA

The regulatory framework in the US consists of three layers: On top there is the national law, in particular the food, drug and cosmetic act, FD&C. Then there is the administrative law under the FDA’s responsibility. This is 21 CFR, a chapter in the Code of Federal Regulations. Additionally FDA publishes guidelines and recommendations.

21 CFR

An important part of 21 CFR is the part 820 defining the quality system regulations. In particular the design controls, subpart C, and the records, subpart M, are relevant.

Subpart C

Subpart C specifies a list of documents to be compiled in due course of development like design input and output as well as design review, verification and validation.

However, these requirements are very generic. Nevertheless, we will discuss all of them in detail in the following video trainings.

Guidance

The guidance documents as the “Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices” give more precise directions what types of documents have to be written and submitted. Comparable to the three safety classes of IEC 62304 the FDA distinguishes three levels of concerns. Dependent on these levels the amount and content of documents to be submitted may vary.

List of docs

The FDA’s and IEC 62304’s requirements with respect to documentation of medical software development are comparable. There are differences related to the organization of documents or to chapter structure, but content wise they are 90% identical. Both regulations address the planning of the development and development process and the verification of the development results.

NBMED

It makes sense that regulations do not only address verification and validation: As the notified bodies in Europe were stating already back in 2001, software is much to complex that testing alone would be sufficient to detect failures. Therefore quality assurance has to address the entire software life cycle including design. In other words: We have no only have to detect errors but also to prevent errors as good as possible.

Quality Assurance

Software quality assurance for many companies still is limited to testing. However, software testing is just a part of the analytical quality assurance. This aspect of the overall quality assurance aims to find errors as bugs. The other aspect of quality assurance is the constructive quality assurance. Its goal is to avoid errors from the very beginning. This includes three major elements.

The first element is life cycle process; the development process or the maintenance process to mention two. The second element is the methods and procedures being applied in due course of these processes: For example methods to analyze requirements, to model the architecture or to systematically derive test cases. And the third element is the tools supporting manufacturers to apply these methods.

On the meta-level we have training and standards addressing exactly these processes, methods and tools.

On the analytical side there is more than testing: While software testing applies to the already executable e.g. compiled software, reviews focus on documents as a software requirement specification or source code, which is a document, too.

Audits verify the effectiveness and application of processes; those processes that have been specified as part of the constructive quality assurance.

Standards and laws like IEC 62304 or the FDA guidance documents cover this entire picture.

Assessment

Yes indeed: We currently experience a revolution not only in the way software is developed but also in the approach authorities govern and audit software-developing companies. This is not a surprise: The value added by software continuously increases. More and more functionality is implemented in software. Therefore the complexity increases: While in the past software was just part of a medical device, part of a stand-alone physical box so to say, we nowadays have highly interconnected systems. Medical devices with embedded software now connect to clinical information systems – stand-alone software.

These networks are no longer limited to just one site: We are talking about chains of hospitals and affiliate locations up to national healthcare systems and about other distributed, complex and hard to control systems. As consequence the number of software related problems explodes: In Germany the number rose in 2010 within a year by 300%. In the US software is the number two reason for FDA recalls. We sometimes have the impression that software problems are getting out of control.

The legislative authorities do what authorities can do to address this problem: They come-up with new regulations or they increase the intensity of audits: Duration of audits increase by up to 30%. Notified bodies substantially invest in the education of personnel. More and more computer scientists are hired. And the focus of audits changes, too: It is not longer the technical issue, the single bug. It is rather the organizational failure, which is scope of audits.

Companies have to understand that software development does not start with the first line of code and end with the last one. It is not sufficient to retrospectively document what they did. Companies have to build up process competency. Not only to comply with standards and to pass audits, but also to be successful by high quality products and a fast time to market.

Outlook

In this training you got a first overview on the regulatory requirements and the list of documents you as a medical device manufacturer have to compile. You learnt that you have address both, analytical and constructive quality assurance. To become and continue to be a successful and innovative company developing medical software, your team does not only need technical expertise but also an understanding of regulations. It has not only to know how to comply with regulations without establishing a quality overhead but also to understand how to apply processes, methods and tools to boost productivity.

This is exactly what the series of video trainings is about: It gives you a step by step, a document by document guidance that helps you to do what you probably like most: Instead of fixing annoying bugs and writing useless documents find ease to develop high quality software: within the planned time and with the predicted quality. And as a side effect you will pass your audits safely.

Look forward to these next training units!

Materialien
Vorausgesetzte Videos
Weiterführende Videos
Ergänzende Videos

E-Learning Library: Become a member

A safe bet - not just in audits

The E-Learning Library will help you 

  • minimize embarrassing difficulties in the audit,
  • avoid wasting time and money on rectification (a re-audit will cost about 1,000 EUR, in addition to internal resources)
  • accelerate the process to the market for your product because you will avoid unnecessary project delays, e.g due to unnecessary rectification or elaborative (retrospective) development of your technical documentation. You would be surprised to know how much a project delay would cost you, try to divide your product revenue in a year into twelve, then you can see how much it already affects your monthly cost.
  • avoid expensive consultants and save your budget up to five-figures sum.

Your investment

Compared to how much all of these will cost you, auditgarant is an absolute bargain: just 990 EUR per year. We are convinced that it is almost impossible that this investment will not benefit you straight away. Convince yourself and order now!



What our customers say

PicclientAt one point, the offers are the most comprehensive informations for this topic-
and are very well prepared and useful for everyday work.

Klaus Müller, CEO xmachina &GmbH

Picclient"I'm really surprised how you succeed to express your motivation and passion, and the fact that you did this with the not-so-easy topics. It was fun to watch the web training and answer the mindmailer. Thank you very much for putting your heart into this and so generously pass this knowledge. This way, a complex and really dry topic becomes a highly interesting topic that you can’t get enough of. Really great! "

Nicole Haas