VDI VDE 3516 Blatt 1-2013 Validation in GxP area - Open-source software.pdf

《VDI VDE 3516 Blatt 1-2013 Validation in GxP area - Open-source software.pdf》由会员分享，可在线阅读，更多相关《VDI VDE 3516 Blatt 1-2013 Validation in GxP area - Open-source software.pdf（19页珍藏版）》请在麦多课文档分享上搜索。

1、 ICS 25.040.40, 35.080 VDI/VDE-RICHTLINIEN September 2013 VEREIN DEUTSCHER INGENIEURE VERBAND DER ELEKTROTECHNIK ELEKTRONIK INFORMATIONSTECHNIK Validierung im GxP-Umfeld Open-Source-Software Validation in GxP area Open-source software VDI/VDE 3516 Blatt 1 / Part 1 Ausg. deutsch/englisch Issue German

2、/English Die deutsche Version dieser Richtlinie ist verbindlich. The German version of this standard shall be taken as authori-tative. No guarantee can be given with respect to the English translation. VDI/VDE-Gesellschaft Mess- und Automatisierungstechnik (GMA) Fachbereich Industrielle Informations

3、technik VDI/VDE-Handbuch Automatisierungstechnik VDI-Handbuch Informationstechnik, Band 1: Angewandte Informationstechnik Vervielfltigungauch fr innerbetrieblicheZweckenichtgestattet/Reproduction even for internalusenotpermittedFrhereAusgabe:09.12Entwurf, deutschFormeredition:09/12Draft,inGerman onl

4、yZubeziehendurch/AvailableatBeuthVerlagGmbH,10772BerlinAlleRechtevorbehalten/ All rightsreservedVereinDeutscherIngenieuree.V.,Dsseldorf2013Inhalt Seite Contents Page Vorbemerkung . 2 Einleitung . 2 1 Anwendungsbereich . 3 2 Begriffe 3 3 Abkrzungen . 3 4 Typische Eigenschaften der Open-Source-Softwar

5、e . 3 4.1 Geschftsmodelle . 4 4.2 Rechtliche Aspekte 4 4.3 Entwicklungsprozess 5 4.4 Support und Wartung . 5 4.5 Kunden-Lieferanten-Beziehung . 6 4.6 Distributionswege 7 5 Validierungsmethode fr Open-Source-Software, basierend auf einem risikobasierten Ansatz 8 5.1 Konzeptphase . 8 5.2 Projektphase

6、. 9 5.3 Operativer Betrieb 14 5.4 Stilllegung 16 Anhang 17 Schrifttum 19 Preliminary note . 2 Introduction 2 1 Scope . 3 2 Terms and definitions 3 3 Abbreviations 3 4 Typical properties of open-source software . 3 4.1 Business models. 4 4.2 Legal aspects 4 4.3 Development process . 5 4.4 Support and

7、 maintenance . 5 4.5 Customer-supplier relationship 6 4.6 Distribution routes . 7 5 Validation method for open-source software, using a risk-based approach 8 5.1 Concept phase 8 5.2 Project phase 9 5.3 Operation . 14 5.4 Decommissioning 16 Annex 18 Bibliography 19 B55EB1B3E14C22109E918E8EA43EDB30F09

8、DCDB7EF87D9NormCD - Stand 2013-09 2 VDI/VDE 3516 Blatt 1 / Part 1 Alle Rechte vorbehalten Verein Deutscher Ingenieure e.V., Dsseldorf 2013 Vorbemerkung Der Inhalt dieser Richtlinie ist entstanden unter Beachtung der Vorgaben und Empfehlungen der Richtlinie VDI 1000. Alle Rechte, insbesondere die des

9、 Nachdrucks, der Fotokopie, der elektronischen Verwendung und der bersetzung, jeweils auszugsweise oder vollstn-dig, sind vorbehalten. Die Nutzung dieser VDI-Richtlinie ist unter Wah-rung des Urheberrechts und unter Beachtung der Lizenzbedingungen (www.vdi.de/richtlinien), die in den VDI-Merkblttern

10、 geregelt sind, mglich. Allen, die ehrenamtlich an der Erarbeitung dieser VDI-Richtlinie mitgewirkt haben, sei gedankt. Eine Liste der aktuell verfgbaren Bltter dieser Richtlinienreihe ist im Internet abrufbar unter www.vdi.de/3516. Preliminary note The content of this standard has been developed in

11、 strict accordance with the requirements and rec-ommendations of the standard VDI 1000. All rights are reserved, including those of reprint-ing, reproduction (photocopying, micro copying), storage in data processing systems and translation, either of the full text or of extracts. The use of this sta

12、ndard without infringement of copyright is permitted subject to the licensing con-ditions specified in the VDI Notices (www.vdi.de/ richtlinien). We wish to express our gratitude to all honorary contributors to this standard. A catalogue of all available parts of this series of standards can be acce

13、ssed on the internet at www.vdi.de/3516. Einleitung Diese Richtlinie behandelt die Besonderheiten von Freier Software und Open-Source-Software (OSS) im Vergleich zu kommerzieller Software und die daraus resultierende Vorgehensweise zur Qualifi-zierung und dem Betrieb von OSS im GxP-regulierten Umfel

14、d. Die Verwendung von OSS in der pharmazeuti-schen Industrie erfordert eine Interpretation der Validierungsmethodik, um die besondere Art des Kunden-Lieferanten-Verhltnisses abzudecken. In-sofern stellt diese Richtlinie eine Erweiterung des etablierten Standards der GAMP-Richtlinie (Good Automated M

15、anufacturing Practice) 1; 2 dar und basiert grundstzlich auf dessen Methodik. Obwohl OSS oft als vllig verschieden von traditioneller kommerzieller Software dargestellt wird, sind die Auswirkungen fr die regulierte Industrie recht gering. Die Unterschiede beziehen sich auf die Lizenzmodelle, Entwick

16、lungsprozesse und Sup-portmodelle und knnen daher die Lieferanten-auswahl und Serviceprozesse beeinflussen. Die Aktivitten im Lebenszyklus bleiben grundstzlich dieselben und der risikobasierte Ansatz, wie in 1 beschrieben, ist anwendbar. Regulatorische Behrden unterscheiden im Allge-meinen nicht zwi

17、schen kommerzieller Software und OSS 3, daher knnen sich Hersteller von Pharma- und Medizinprodukten und deren Zuliefe-rer entscheiden. Alle computerisierten Systeme, auf die GxP-Regulatorien anzuwenden sind, ms-sen vor der Verwendung validiert werden, um den Nachweis zu erbringen, dass sie fr den b

18、eabsich-tigten Gebrauch geeignet sind. Entscheidungen hinsichtlich Mechanismen zur Datenintegritt und Introduction This standard deals with the special features of free software and open-source software (OSS) com-pared with commercial software, and with the re-sulting procedure to be followed for th

19、e qualifica-tion and operation of OSS in the GxP-regulated environment. The use of OSS in the pharmaceutical industry requires an interpretation of the validation method-ology, in order to deal with the special nature of the customer-supplier relationship involved. In that respect, this standard is

20、an extension of the stan-dard established by the GAMP (Good Automated Manufacturing Practice) guideline 1; 2 and is based essentially on its methodology. Although OSS is often portrayed as completely different from traditional commercial software, the implica-tions for the regulated industry are qui

21、te minor. The differences relate to the licensing models, development processes and support models, and therefore can affect the choice of supplier and ser-vice processes. The lifecycle activities remain es-sentially the same, and the risk-based approach as described in 1 can be utilised. Regulatory

22、 authorities do not, in general, distin-guish between commercial software and OSS 3, therefore this decision can be made by the manu-facturers of pharmaceutical and medicinal products and their suppliers. All computerised systems sub-ject to GxP regulations need to be validated before use, in order

23、to demonstrate that they are suitable for their intended purpose. Decisions regarding the mechanisms used for data integrity and the depth of validation, should be based on documented and B55EB1B3E14C22109E918E8EA43EDB30F09DCDB7EF87D9NormCD - Stand 2013-09All rights reserved Verein Deutscher Ingenie

24、ure e.V., Dsseldorf 2013 VDI/VDE 3516 Blatt 1 / Part 1 3 die Tiefe der Validierung sollten auf einer doku-mentierten und begrndeten Risikoanalyse basie-ren. Die Auswirkung auf Patientensicherheit und Produktqualitt sowie Datenintegritt und Daten-verfgbarkeit sind in diesem Rahmen zu prfen. Klare Akz

25、eptanzkriterien sind basierend auf dieser Risikobewertung zu definieren und im Validie-rungsplan zu dokumentieren. justified risk analysis. The impact on patient safety, product quality and data integrity and avail-ability, should be examined in this context. Clear acceptance criteria need to be def

26、ined on the basis of this risk assessment, and documented in the validation plan. 1 Anwendungsbereich Diese Richtlinie findet Anwendung bei Planern, Herstellern und Betreibern von Open-Source-Systemen im pharmazeutischen Umfeld. 1 Scope This standard is designed for use by planners, pro-ducers and o

27、perators of open-source systems in the pharmaceutical environment. 2 Begriffe Fr die Anwendung dieser Richtlinie gelten die folgenden Begriffe: Community (Open Source Community) Arbeitsgemeinschaft zur Entwicklung von Open-Source-Software. Prozess Zusammenhngende Operationen, die Eingaben in Ausgabe

28、n umwandeln. in Anlehnung an DIN EN ISO 9000:2005 2 Terms and definitions For the purposes of this standard, the following terms and definitions apply: Community (open-source community) Working group for the development of open-source software. Process Interrelated operations that convert input into

29、 out-put. adapted from DIN EN ISO 9000:2005 3 Abkrzungen In dieser Richtlinie werden die nachfolgend aufge-fhrten Abkrzungen verwendet: BSD Berkeley Software Distribution DMS Dokumenten-Managementsystem GAMP Good Automated Manufacturing Practice GMP Gute Herstellungspraxis GNU ein rekursives Akronym

30、 von GNUs Nicht Unix (engl. GNUs Not Unix) IQ Installationsqualifizierung OSS Open-Source-Software SLA skalierbare Dienstleistungsvereinbarung 3 Abbreviations The following abbreviations are used throughout this standard: BSD Berkeley software distribution DMS document management system GAMP good au

31、tomated manufacturing practice GMP good manufacturing practice GNU a recursive acronym of GNUs Not Unix IQ installation qualification OSS open-source software SLA scalable service level agreement 4 Typische Eigenschaften der Open-Source-Software Open-Source-Software zeichnet sich allein durch die Ar

32、t des Lizenzmodells aus. Unerheblich ist, ob sie von uneigenntzigen Individuen erstellt wird oder von Firmen oder anderen Organisationen und lizenzkostenfrei ist. Um geeignete Entscheidungen bezglich OSS zu treffen, ist es fr kommerzielle Software-Unter-nehmen, Systemintegratoren, Berater und Anwen-

33、der im Gesundheitswesen wichtig, die Geschfts- und Lizenzmodelle, Entwicklungsprozesse und Support-Strukturen zu verstehen. 4 Typical properties of open-source software Open-source software is characterised solely by the type of licensing model used. It is immaterial whether it is produced by altrui

34、stic individuals or by companies or other organisations, and is free of licence fees. In order to reach appropriate decisions with regard to OSS, it is important for commercial software companies, system integrators, advisers, and users in the healthcare sector to understand the business and licensi

35、ng models, development processes and support structures. B55EB1B3E14C22109E918E8EA43EDB30F09DCDB7EF87D9NormCD - Stand 2013-09 4 VDI/VDE 3516 Blatt 1 / Part 1 Alle Rechte vorbehalten Verein Deutscher Ingenieure e.V., Dsseldorf 2013 4.1 Geschftsmodelle In der Regel wird die Software-Entwicklung in OSS

36、-Projekten durch folgende Teilnehmer getra-gen: Einzelpersonen, die in ihrer Freizeit am Projekt mitarbeiten Unternehmen und andere Organisationen (z. B. Universitten), die direkt oder indirekt Pro-grammierer oder andere Spezialisten finanzie-ren, um am Projekt mitzuarbeiten Die Motivation fr den Ei

37、nzelnen in der ersten Gruppe kann stark variieren zwischen Begeiste-rung an technischen Herausforderungen, uneigen-ntzigen Motiven (z. B. OSS als Beitrag zur Be-kmpfung von Armut und Ungleichheit), bis zum Versuch, die persnliche Reputation als Entwickler aufzubauen, indem sie wertvolle Beitrge zu e

38、inem Projekt sichtbar leisten. Andererseits sind Firmen und freiberufliche Exper-ten eher an der Entwicklung neuer Geschftschan-cen rund um ihre Aktivitten im OSS-Umfeld inte-ressiert. Eine Reihe von Geschftsmodellen ist mglich: Erweiterung oder Verbesserung von OSS fr das entsprechende Projekt Dies

39、 kann eine kostengnstige Alternative zum Kauf oder Eigenherstellung sein. Erbringung von bezahlten Dienstleistungen fr ein OSS-Produkt Dies kann auch die Verbesserung oder Korrek-tur des Produkts auf vertraglicher Grundlage fr Kunden sein. Umwandlung eines kommerziellen Produkts in OSS zur Verbesser

40、ung der Produktakzeptanz und zur Erschlieung neuer Geschftschancen fr das Unternehmen Vertrieb eines Produkts mit dualer Lizenz So kann ein Produkt sowohl mit einer kommer-ziellen Lizenz als auch als OSS angeboten wer-den. Die OSS-Lizenz ist in der Regel in einigen Aspekten eingeschrnkt (z. B. ist d

41、ie Integration des Produkts in andere kommerzielle Produkte eingeschrnkt), wogegen die kommerzielle Li-zenz keine Einschrnkungen aufweist. Auf die-se Weise kann das Unternehmen die Vorteile der Community (z. B. externe Programmierer, erweiterte Nutzerbasis) nutzen und zustzlich bezahlte Dienstleistu

42、ngen anbieten. 4.1 Business models Normally, software development in OSS projects is carried out by the following participants: individuals who cooperate in the project in their free time companies and other organisations (e.g. univer-sities) that finance programmers or other spe-cialists directly o

43、r indirectly in order to allow them to cooperate in the project The motivation of individuals in the first group can vary greatly between enthusiasm for overcoming technical challenges, altruistic motives (e.g. OSS as a contribution to combating poverty and ine-quality), all the way to an effort to

44、develop their personal reputation as developers by making a valuable and visible contribution to a project. In contrast, companies and self-employed experts tend to be more interested in the development of new business opportunities around their activities in the OSS environment. Several different b

45、usiness models are possible: extension or improvement of OSS for a given project This can be an economical alternative to a pur-chase or in-house production. providing paid services for an OSS product This can include improving or rectifying the product on a contractual basis for customers. converti

46、ng a commercial product into OSS in order to improve product acceptance and in or-der to open up new business opportunities for the company marketing a product with a dual licence A product can be offered both with a commer-cial licence and as OSS. Normally, the OSS li-cence is restricted in several

47、 aspects (e.g. prod-uct integration into other commercial products is restricted), whereas the commercial licence is unrestricted. In this way, the company can util-ise the advantages of the community (e.g. ex-ternal programmers, expanded user base) and offer additional paid services. 4.2 Rechtliche

48、 Aspekte Open-Source-Software ist frei von Lizenzgebh-ren. Trotzdem entsteht durch das Benutzen von 4.2 Legal aspects Open-source software is free from licence fees. Nevertheless, the use of OSS creates a legal rela-B55EB1B3E14C22109E918E8EA43EDB30F09DCDB7EF87D9NormCD - Stand 2013-09All rights reser

49、ved Verein Deutscher Ingenieure e.V., Dsseldorf 2013 VDI/VDE 3516 Blatt 1 / Part 1 5 OSS ein Rechtsverhltnis, dessen Aspekte berck-sichtigt werden mssen. Dabei werden vertrags-rechtliche (Gewhrleistung, Haftung) und urheber-rechtliche (Copyright) Gesichtspunkte unterschie-den. Die Rechte, Pflichten und Risiken des normalen Endnutzers“, der beispielsweise Linux, Apache oder MySQL installiert und nutzt, sind denen eines blichen Software-Lizenzvertrags s