ANSI TIR80002-2-2017 Medical device software - Part 2 Validation of software for medical device quality systems.pdf

《ANSI TIR80002-2-2017 Medical device software - Part 2 Validation of software for medical device quality systems.pdf》由会员分享，可在线阅读，更多相关《ANSI TIR80002-2-2017 Medical device software - Part 2 Validation of software for medical device quality systems.pdf（103页珍藏版）》请在麦多课文档分享上搜索。

1、AAMI/ISO TIR80002-2: 2017Technical Information ReportMedical device softwarePart 2: Validation of software for medical device quality systemsA Technical Report prepared by AAMI and registered with ANSI AAMI/ISO TIR80002-2:2017 Medical device softwarePart 2: Validation of software for medical device

2、quality systems Approved 11 August 2017 by AAMI Registered 18 August 2017 by American National Standards Institute Abstract: This document applies to any software used in device design, testing, component acceptance, manufacturing, labelling, packaging, distribution and complaint handling or to auto

3、mate any other aspect of a medical device quality system as described in ISO 13485. Keywords: medical device, software, validation Published by AAMI4301 N. Fairfax Drive, Suite 301 Arlington, VA 22203-1633 www.aami.org HU UH 2017 by the Association for the Advancement of Medical Instrumentation All

4、Rights Reserved This publication is subject to copyright claims of ISO and AAMI. No part of this publication may be reproduced or distributed in any form, including an electronic retrieval system, without the prior written permission of AAMI. All requests pertaining to this document should be submit

5、ted to AAMI. It is illegal under federal law (17 U.S.C. 101, et seq.) to make copies of all or any part of this document (whether internally or externally) without the prior written permission of the Association for the Advancement of Medical Instrumentation. Violators risk legal action, including c

6、ivil and criminal penalties, and damages of $100,000 per offense. For permission regarding the use of all or any part of this document, complete the reprint request form at www.aami.org or contact AAMI at 4301 N. Fairfax Drive, Suite HU UH301, Arlington, VA 22203-1633. Phone: +1-703-525-4890; Fax: +

7、1-703-525-1067. Printed in the United States of America ISBN 978-1-57020-670-2 AAMI Technical Information Report A technical information report (TIR) is a publication of the Association for the Advancement of Medical Instrumentation (AAMI) Standards Board that addresses a particular aspect of medica

8、l technology. Although the material presented in a TIR may need further evaluation by experts, releasing the information is valuable because the industry and the professions have an immediate need for it. A TIR differs markedly from a standard or recommended practice, and readers should understand t

9、he differences between these documents. Standards and recommended practices are subject to a formal process of committee approval, public review, and resolution of all comments. This process of consensus is supervised by the AAMI Standards Board and, in the case of American National Standards, by th

10、e American National Standards Institute. A TIR is not subject to the same formal approval process as a standard. However, a TIR is approved for distribution by a technical committee and the AAMI Standards Board. Another difference is that, although both standards and TIRs are periodically reviewed,

11、a standard must be acted onreaffirmed, revised, or withdrawnand the action formally approved usually every five years but at least every 10 years. For a TIR, AAMI consults with a technical committee about five years after the publication date (and periodically thereafter) for guidance on whether the

12、 document is still usefulthat is, to check that the information is relevant or of historical value. If the information is not useful, the TIR is removed from circulation. A TIR may be developed because it is more responsive to underlying safety or performance issues than a standard or recommended pr

13、actice, or because achieving consensus is extremely difficult or unlikely. Unlike a standard, a TIR permits the inclusion of differing viewpoints on technical issues. CAUTION NOTICE: This AAMI TIR may be revised or withdrawn at any time. Because it addresses a rapidly evolving field or technology, r

14、eaders are cautioned to ensure that they have also considered information that may be more recent than this document. All standards, recommended practices, technical information reports, and other types of technical documents developed by AAMI are voluntary, and their application is solely within th

15、e discretion and professional judgment of the user of the document. Occasionally, voluntary technical documents are adopted by government regulatory agencies or procurement authorities, in which case the adopting agency is responsible for enforcement of its rules and regulations. Comments on this te

16、chnical information report are invited and should be sent to AAMI, Attn: Standards Department, 4301 N. Fairfax Drive, Suite 301, Arlington, VA 22203-1633. ANSI Technical Report This AAMI TIR has been registered by the American National Standards Institute as an ANSI Technical Report. Publication of

17、this ANSI Technical Report has been approved by the accredited standards developer (AAMI). This document is registered as a Technical Report series of publications according to the Procedures for the Registration of Technical Reports with ANSI. This document is not an American National Standard and

18、the material contained herein is not normative in nature. Comments on the content of this document should be sent to AAMI, Attn: Standards Department, 4301 N. Fairfax Drive, Suite 301, Arlington, VA 22203-1633. Contents PageGlossary of equivalent standards . v Committee representation vi Background

19、of AAMI adoption of ISO TR 80002-2 . viii Foreword ix Introduction x 1 Scope 1 2 Normative references 1 3 Terms and definitions 1 4 Software validation discussion 1 5 Software validation and critical thinking . 2 6 Documentation . 17 7 Prerequisite processes . 17 Annex A (informative) Toolbox 19 Ann

20、ex B (informative) Risk management and risk-based approach 26 Annex C (informative) Examples . 30 Bibliography . 91 2017 Association for the Advancement of Medical Instrumentation AAMI/ISO TIR80002-2:2017 v Glossary of equivalent standards International Standards and technical information reports ad

21、opted in the United States may include normative references to other International Standards. AAMI maintains a current list of each International Standard and technical information report that has been adopted by AAMI (and ANSI). Available on the AAMI website at the address below, this list gives th

22、e corresponding U.S. designation and level of equivalency to the International Standard and technical information report www.aami.org/standards/glossary.pdf vi 2017 Association for the Advancement of Medical Instrumentation AAMI/ISO TIR80002-2:2017 Committee representation Association for the Advanc

23、ement of Medical Instrumentation Software Working Group The publication of AAMI/ISO TR 80002-2 as a new American Technical Report was initiated by the AAMI Software Working Group which also functions as a U.S. Technical Advisory Group to the relevant work in the International Organization for Standa

24、rdization (ISO) ISO/TC210 JWG2. U.S. representatives from the AAMI Software Working Group participate as US experts on the ISO committee. At the time this document was published, the AAMI Software Working Group had the following members: Cochairs: Michelle Jump John Murray Members: Michael Attili, A

25、maxo Inc Pat Baird, Philips Conor Curtin, Fresenius Medical Care Richard De La Cruz, Silver Lake Group Inc Theresa Dennis, Sterigenics International Harsh Dharwad, Hospira, a Pfizer company Plamena Entcheva-Dimitrov, Preferred Clinical Research LLC Christie Evans, Hill-Rom Holdings Chris Flahive, Ch

26、ris Flahive Associates Rick Hampton, Premier Inc Ed Heierman, Abbott Laboratories Jeremy Jensen, Boston Scientific Corporation Rob Johnson, Baxter Healthcare Corporation Michelle Jump, Stryker Instruments Division Jim Kainec, Steris Corporation Patty Krantz-Zuppan, Medtronic Inc Campus Alan Kusinitz

27、, SoftwareCPR Yimin Li, St Jude Medical Inc Neeraj Mainkar, Smiths Medical Mercy Massana, MDM Engineering Consultants Jared Mauldin, Integrated Medical Systems Mary Beth McDonald, Chrono Therapeutics Mulugeta Mideksa John Murray, FDA/CDRH Jeff Newfeld, Spacelabs Healthcare Andrew OKeeffe, Draeger Me

28、dical Systems Inc Geoff Pascoe Joe Petruzzelli, Mindray DS USA Inc Dewey Phan, Becton Dickinson extent of content in the documentation and deliverables; selection of tools from the toolbox and methods for applying the tools; level of effort in applying the tools. The primary drivers for decisions in

29、 the four areas are process risk and software risk. However, other drivers can influence decisions, including the complexity of the software and process, the type of software and the software pedigree. 4 2017 Association for the Advancement of Medical Instrumenttion AAMI/ISO TIR80002-2:2017 The vali

30、dation planning process consists of two distinct elements. The first validation planning element involves determining the level of rigor in the documentation and the scrutiny to be applied to the review of the resulting deliverables. The decisions in this element are primarily driven by the results

31、of the process risk analysis. The second validation planning element drives the selection of tools from the toolbox to implement, test and deploy the software. The choice of tools is driven primarily by the software risk analysis. Such planning steps result from different types of risk analyses and

32、are depicted as separate activities in this document. However, many times the steps are combined into one activity, which includes the different aspects of risk analysis and the resultant choices for proceeding with validation. During the development phase of the life cycle, risk management and vali

33、dation planning tasks are used to define the appropriate level of effort to be applied to the software and to determine what confidence-building tools to apply. This type of approach results in the completion of appropriate value-added activities and verification tasks, which are the basis for estab

34、lishing a validated state. Once these activities and tasks are executed, the tools and their associated results are cited in a validation report as support for the conclusion that the software is validated. Once deployed, the software moves into the maintenance phase of the software life cycle. Duri

35、ng this period, the software is monitored, enhanced and updated as dictated by the business needs or regulatory requirement changes. Change control activities use the same concepts as the initial approach that was applied during the development phase of the life cycle. Changes, however, are now asse

36、ssed as to their effect on the intended use, on the risk of failure, on the risk control measures that were applied during the initial development and on any functionality of the software itself. The retirement phase is the act of removing software from use either by removal of the process or by rep

37、lacement of the software being used for the process. The activities shown in Figure 1 reflect the primary software life-cycle control activities. Other work streams include project management, process development, vendor management (if applicable), and possibly others, depending on the software bein

38、g implemented. Figure 2 depicts software life-cycle control activities and critical thinking within the context of other work stream activities. The critical thinking activities appear in the iterative risk analysis and validation work streams. It is important to have clear and formal definitions of

39、 these work streams within the organizations business model to ensure that a program properly manages the software from both business and regulatory perspectives. 2017 Association for the Advancement of Medical Instrumentation AAMI/ISO TIR80002-2:2017 5 NOTE When the term “develop” or “development”

40、is used, it is about the development of a validated state of the software. Figure 2Life-cycle controls work stream 6 2017 Association for the Advancement of Medical Instrumenttion AAMI/ISO TIR80002-2:2017 The various colours depicted in Figure 2 correspond to the life-cycle portion that is shown in

41、the overall approach flow chart in Figure 1. The red dashed lines indicate information that is outputted from one activity and that provides input to or helps drive decisions in another activity. The diagram demonstrates how the ordering of the activities is driven by the need to have input informat

42、ion before completing the activities that require the input. It is important to note that all the activities are completed irrespective of the size or complexity of the software being implemented. However, for larger or more complex software, such activities will most likely be discrete; for smaller

43、 or simpler software, many of those activities will be combined or completed simultaneously. In summary, the critical thinking approach described a systematic method for identifying and including appropriate confidence-building activities or tools in various work streams to support the conclusions t

44、hat the software is validated on release and that the validated state will be maintained until the software is retired. The following subclauses provide additional details for each of the blocks found in the life-cycle controls depicted in Figure 1. The subclauses use the work stream depiction of it

45、erative risk analyses, validation and software activities shown in Figure 2 to provide perspective on the various decision points and decision drivers that incorporate critical thinking. 5.2 Determine if the software is in scope 5.2.1 Document a high-level definition of the process and use of the so

46、ftware The first step in determining whether the software is considered to be used for medical device quality systems is to document a high-level definition of the process and use of the software. This activity might seem of small value when it is readily known that the software is in scope and one

47、is already embarking on defining the full intended use of the software. However, for situations in which such assumptions are less clear, documenting the process and use enables the clear determination as to whether the software is in scope. In addition, for identified out-of-scope software, such an

48、 activity can result in a rationale as to why the software is out of scope. 5.2.2 Regulatory use assessment A regulatory use assessment can be used to determine whether the software is a “software for medical device quality system” and therefore falls within the scope of this document. Start by iden

49、tifying the specific regulatory requirements that apply to the processes that use the software and the data records that are managed by the software. A series of questions can be used to help fully understand the role that the software plays in support of these regulations. The following types of questions should be considered. a) Could the failure or latent flaws of the software affect the safety or quality of medical devices? b) Does the software automate or execute an activity required by regulatory requirements (in particular, the requirements for medic