Auditgarant: Sicher durchs Audit, sichere Produkte, sicher zum Erfolg

Sie befinden sich hier:
Software: Intro
authorsymbol
Prof. Dr. Christian Johner
authorsymbol
Qualitätsmanager, Entwickler, Regulatory Affairs, Projektleiter
Beginner
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

Start

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.

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

Auditgarant: Mitglied werden

Der Auditgarant: Ihre sichere Bank - nicht nur in Audits

Der Auditgarant hilft Ihnen …

  • peinliche Schwierigkeiten im Audit zu minimieren,
  • kosten- und zeitintensive Nacharbeiten zu vermeiden (ein Re-Audit kostet einige 1000 Euro, zusätzlich die internen Ressourcen).
  • beschleunigen Sie die Time to Market für Ihr Produkt, weil Sie unnötigen Projektverzug vermeiden z.B. aufgrund unnötiger Nachbesserungen, aufgrund aufwendigem (retrospektiven) Erstellen der technischen Dokumentation. Wie viele hunderttausend Euro ein Projektverzug bei Ihnen pro Monat kostet, können Sie selbst abschätzen, wenn Sie die Jahresumsätze mit Ihren Produkten durch 12 teilen.
  • machen Sie teure Berater weitgehend überflüssig und sparen Kosten oft im fünfstelligen Bereich.

Der Preis: Ihre Investition

Im Vergleich zu diesen Kosten ist der Auditgarant ein Schnäppchen: 990,-- Euro pro Jahr. Wir sind davon überzeugt: Es ist fast unmöglich, dass sich diese Investition nicht in kürzester Zeit rechnet. Überzeugen Sie sich selbst und bestellen Sie gleich jetzt.

Zufriedenheitsgarantie

Auditgarant bestellen

Was unsere Kunden sagen

Picclient"Die Angebote sind die umfangreichesten Informationen zu dem Thema an einer Stelle - und sehr gut und nützlich für die tägliche Arbeit aufbereitet."

Klaus Müller, Geschäftsführer xmachina GmbH

Picclient"Ich bin wirklich überrascht, wie gut es Ihnen gelungen ist Ihre Motivation und Freude zum Ausdruck zu bringen und dies bei wirklich nicht einfachen Thematiken. Es hat Spaß gemacht, sich die Webtrainings anzuschauen und die Mindmailer zu beantworten. Ich danke Ihnen sehr dafür, dass Sie so mit dem Herzen bei der Sache sind und dies wunderbar weitergeben können. So wird aus einem komplexen und eigentlich trockenen Thema ein hoch interessantes Thema von dem man nicht genug bekommt. Wirklich super!"

Nicole Haas

Picclient" Sehr geehrter Herr Johner,
ich habe während meines gesamten Berufslebens noch nie etwas mit einer technischen Dokumentation - geschweige denn mit der IEC62304 - zu tun gehabt. Mein Chef hat es mir zugetraut und mir Ihre Videos anvertraut. Und was soll ich sagen? Dank Ihnen habe ich meinen Job behalten, denn ich habe es geschafft und arbeite maßgeblich an der technischen Dokumentation mit!
Vielen Dank![...]"

Nina Schubert

Picclient"Ich bin ich von den Inhalten des Audit-Garanten immer mehr überzeugt und [...] erkenne, dass die Templates aus dem Premium-Auditgaranten sehr viel nutzen."

Jonas Schansker, ARGOS Messtechnik