Transcription
White paper:Implementation of ANSI/AAMI/IEC62304 Medical Device SoftwareLifecycle ProcessesThis paper reviews the implementation of theANSI/AAMI/IEC 62304 Medical Device Software - Software LifeCycle Processes standard. This paper aims to provide anoverview of the dynamic utilization of ANSI/AAMI/IEC 62304with regards to key concepts and activities.This document was prepared in February 2016, any content including links and quoted regulation may be out of date. Please refer to theappropriate source for the most recent information. We endeavour to keep an up-to-date record of information at www.pharmout.net. 2016 PharmOut. This document has been prepared solely for the use of PharmOut and its clients. Copying is prohibited.MKT TMP200 01 r06
PharmOut white paper:Implementation of ANSI/AAMI/IEC 62304 Medical Device Software Lifecycle ProcessesPrerequisitesThe list below provides prerequisites for the users of the Technical Paper: Availability of ANSI/AAMI/IEC 62304 Familiarity with ANSI/AAMI/IEC 62304 General Knowledge of project management, systems development processes andsystem life cycle models.Scope of the ANSI/AAMI/IEC 62304ANSI/AAMI/IEC 62304 Standard applies to the development and maintenance of medical devicesoftware where the software itself is a medical device or when the software is an embedded orintegral part of the final medical device.The standard does not cover testing, validation and final release of the medical device, evenwhen the device consists entirely of software.This paper does not detail the maintenance activities of the medical devices because theactivities and processes are similar to the software development concept.Context of the ANSI/AAMI/IEC 62304An organization needs to be able to conduct business and perform operations. Standardsfacilitate businesses by providing a common framework for establishing agreements betweensystems acquirers and suppliers with respect to developing, using and managing a systemwithin the defined life cycle of that system.The ANSI/AAMI/IEC 62304 standard is applicable to organizations, enterprises and projectswhether they act as the acquirer or the supplier of a system.The standard defines the life cycle requirements for medical device software. It definesconceptual structure spanning the life of the software from the definition of its requirements tomanufacturing, which: Identifies the Processes, Activities and Tasks involved in development of aSoftware Describes the sequence of the dependency between activities and tasks, and Identifies the milestones at which the completeness of specified deliverables isverified.The software development process is divided into a set of activities, with most activities furtherdivided into a set of tasks. These activities are listed below: Software Development Planning Software Requirement Analysis Software Architectural DesignPharmOut Pty Ltd, ABN: 85 117 673 766, Unit 10, 24 Lakeside Drive, Burwood East, Victoria 3151.Ph: 61 3 9887 6412, Fax: 61 3 8610 0169, Email: [email protected] Web: www.pharmout.net 2016 PharmOut. This document has been prepared solely for the use of PharmOut and its clients. Copying is prohibited.Page 2 of 15MKT TMP200 01 r06
PharmOut white paper:Implementation of ANSI/AAMI/IEC 62304 Medical Device Software Lifecycle Processes Software Detailed Design Software Unit Implementation &Verification Software Integration and Integration testing Software System Testing Software Release.The maintenance process activities are considered to be as important as the softwaredevelopment process activities. These activities include: Generate Software Maintenance Plan Problem and Modification AnalysisANSI/AAMI/IEC 62304 refers to the risk management process described in InternationalStandard ISO 14971 for identifying and managing risks during development and maintenance ofthe software.It is imperative to note that ANSI/AAMI/IEC 62304 recognizes two additional processesconsidered essential for developing safe medical software. They are the software configurationmanagement process and software problem resolution process.Compliance with the standard is accomplished by implementing all of the processes, activitiesand tasks identified in the standard in accordance with the software safety class.Software Safety ClassificationANSI/AAMI/IEC 62304 identifies three classes of medical device software in accordance with thepossible effects on patient, operator, or any other people affected by software-related hazards.The medical device software should be classified based on severity as follows: Class A: No injury or damage to health is possible Class B: Non-Serious injury is possible Class C: Death or Serious injury is possible.PharmOut Pty Ltd, ABN: 85 117 673 766, Unit 10, 24 Lakeside Drive, Burwood East, Victoria 3151.Ph: 61 3 9887 6412, Fax: 61 3 8610 0169, Email: [email protected] Web: www.pharmout.net 2016 PharmOut. This document has been prepared solely for the use of PharmOut and its clients. Copying is prohibited.Page 3 of 15MKT TMP200 01 r06
PharmOut white paper:Implementation of ANSI/AAMI/IEC 62304 Medical Device Software Lifecycle ProcessesThe figure below illustrates the activities associated with each of three different classes of thesoftware.Figure 1 Classification of software and related activitiesUse of the StandardOverview A specific project can use the standard for developing and supporting a medicaldevice software. An organization can use the standard for managing one or more of the medicaldevice software’s life cycle stages. An organization can use the standard for developing the Quality ManagementSystem.Concept of useAn organization is driven by the nature of its business, corporate responsibilities and itsbusiness strategy.To help achieve the overall business and quality goals and exploit opportunities, an organizationshould establish policies and procedures to guide control and monitor the performance ofprojects and function groups.PharmOut Pty Ltd, ABN: 85 117 673 766, Unit 10, 24 Lakeside Drive, Burwood East, Victoria 3151.Ph: 61 3 9887 6412, Fax: 61 3 8610 0169, Email: [email protected] Web: www.pharmout.net 2016 PharmOut. This document has been prepared solely for the use of PharmOut and its clients. Copying is prohibited.Page 4 of 15MKT TMP200 01 r06
PharmOut white paper:Implementation of ANSI/AAMI/IEC 62304 Medical Device Software Lifecycle ProcessesTo create these policies and procedures, and define the resources needed by the organization,the ANSI/AAMI/IEC 62304 standard can be utilized to provide specific standardized processesfor use within one or more software development life cycles.POLICY QUALITY STANDARDS ®ULATORY POLICY RISK MANAGEMENT POLICY SOFTWARE DEVELOPMENT POLICY PROJECT IMPLEMENTATIONPOLICY QUALITY POLICYNATURE OFBUSINESS DOMAIN OF PRODUCTS EXPERTISE AND SKILLS SOCIAL RESPONSIBILITIES REGULATORYCONSIDERATIONCONTROLS PROCEDURES WORK INSTRUCTIONS METHODS TEMPLATE TOOLSFigure 2 Overview of concept of useThe overall relationships between the various organizational activities are portrayed in Figure 2.The aim of the Quality Standard Policy is to define the standards and industry regulations thatthe organization adapts in order to achieve its organizational objectives which is reliant on thenature of business. The above figure also illustrates the factors that influence the nature ofbusiness.Similarly, the Risk Management, Project Implementation and Quality policies are used toensure that adequate assessment planning and control activities are utilized to create supportand monitor projects.At the initiation phases of the project to satisfy the stakeholder’s requirements, assessmentshould be conducted to identify if the current policies and procedures are sufficient.If the procedures and policies are not adequate, new ones are created or existing modifiedbased on the current standard in accordance with the scope, size and funding of the work to bedone.PharmOut Pty Ltd, ABN: 85 117 673 766, Unit 10, 24 Lakeside Drive, Burwood East, Victoria 3151.Ph: 61 3 9887 6412, Fax: 61 3 8610 0169, Email: [email protected] Web: www.pharmout.net 2016 PharmOut. This document has been prepared solely for the use of PharmOut and its clients. Copying is prohibited.Page 5 of 15MKT TMP200 01 r06
PharmOut white paper:Implementation of ANSI/AAMI/IEC 62304 Medical Device Software Lifecycle ProcessesHow Does Standard-Driven Development Work Management defines expectations for how software is written and tested. Developers are trained on how the expectations relate to the business objectives. An automation infrastructure sits in the background of the developmentenvironment to automatically monitor compliance according to definedexpectations. For example, a policy may require all code to follow a designated setof secure development practices, undergo peer review, and be verified by testcases. When requirements are implemented, the automation infrastructure unobtrusivelyidentifies policy violations. If policy violations are identified, the infrastructure alerts the responsibledeveloper that policy violations need to be addressed immediately. The ability to passively and unobtrusively monitor developers' work is paramountto policy-driven development. If it is done properly, it will improve quality andincrease productivity.Consideration for UseThe ANSI/AAMI/IEC 62304 standard can be considered for a specific project with a set durationor for a continuous work effort conducted by an organization.The following are examples of items to consider while planning use of the ANSI/AAMI/IEC 62304standard.The scope of the work effort, such as: A single project or multiple projects within the organization. Concentration on some key processes or a single process where there is expectedto be some gain for the organization. Concentration on a single life cycle stage to carry out the operation of that stage.Identification and listing of stakeholders, such as: Intended users or customers of the medical device software. Other interested parties who have an interest or stake in the products. Sources of requirements and constraints.Desired outcomes, such as: Work products (software configuration item, or procedure document). Services or capabilities to be delivered or demonstrated at the end of the projectand at specific milestones.PharmOut Pty Ltd, ABN: 85 117 673 766, Unit 10, 24 Lakeside Drive, Burwood East, Victoria 3151.Ph: 61 3 9887 6412, Fax: 61 3 8610 0169, Email: [email protected] Web: www.pharmout.net 2016 PharmOut. This document has been prepared solely for the use of PharmOut and its clients. Copying is prohibited.Page 6 of 15MKT TMP200 01 r06
PharmOut white paper:Implementation of ANSI/AAMI/IEC 62304 Medical Device Software Lifecycle ProcessesSpecial considerations, such as: Medical Device Software technologies that focus on hardware or humans. Medical Device Software classification including single use, repeated use andcontinuous use. Medical Device Software builds such as one-of-a-kind, replicated or massproduced.Goals and objectives of the project, such as: Specific objectives identified by milestones. Long-term utilization goals related to the use of the medical device software. Project strategy, such as: How the project will be carried out, including any agreement considerations. How work packages will be planned, assessed and controlled. How work products will be planned, evaluated and controlled. How work and changes will be authorized. Major milestone decision or event points (e.g. management reviews, meetings,pilot tests, deployments and deliveries) with milestone entry or exit criteria.Requirements and constraints, such as: Specific functional and performance requirements for, capabilities of or data froma Medical Device Software, including special quality attributes and usabilityexpectations or safety concerns. Policies, priorities and constraints such as risks, personnel, facilities, sites andcritical resources that will affect meeting the requirements and objectives of theproject. Core organizational technologies that will affect medical device softwarerequirements or other work product requirements and constraints; applicableorganizational processes, standards and specifications (including source andavailability); product implementation risks; and how information (includingdifferent product versions) will be captured, stored and controlled. Applicable medical device software life cycle stage activities (for exampledevelopment, pilot testing, full production) and expected outputs (for example.deliverables, work products and management reviews). Relevant stage entry or exit criteria, including expected level of medical devicesoftware maturity, level of acceptable risks and management review concerns. Project start-up and end dates, including milestone dates associated with approvaland progress reviews and pilot tests, as applicable. Management structure, including participants and their roles.PharmOut Pty Ltd, ABN: 85 117 673 766, Unit 10, 24 Lakeside Drive, Burwood East, Victoria 3151.Ph: 61 3 9887 6412, Fax: 61 3 8610 0169, Email: [email protected] Web: www.pharmout.net 2016 PharmOut. This document has been prepared solely for the use of PharmOut and its clients. Copying is prohibited.Page 7 of 15MKT TMP200 01 r06
PharmOut white paper:Implementation of ANSI/AAMI/IEC 62304 Medical Device Software Lifecycle Processes Exclusions of organizations or persons (if applicable), including when the exclusionis or is not valid. Level of security classification and other security considerations, if applicable. Expected deliverables at milestones, at end of project/work and duringproject/work performance. Environment, recycling and reuse issues.AmendingWhen the ANSI/AAMI/IEC 62304 is used by an organization to form a set of policies andprocedures governing project work, amending the existing Quality Management System may bedone to appropriately reduce or extend the scope of the ANSI/AAMI/IEC 62304 standardimplementation.Thus, it is expected that the requirements of the ANSI/AAMI/IEC 62304 will be tailored to thecharacteristics of a particular project, life cycle stage, or agreement.Revising should be given careful consideration so that critical factors of the ANSI/AAMI/IEC62304 are not excluded, and that factors that do not add value to the process or Medical DeviceSoftware element are not added.When adapting out factors from the ANSI/AAMI/IEC 62304, care should be taken that theappropriate balance between timely delivery, cost and satisfaction of requirements is achieved.When amending is done, it may be important to ensure that applicable compliancerequirements of ANSI/AAMI/IEC 62304 are met.Amending considerationsThe objectives and requirements of an agreement should define the context of application of theStandard.To assist in defining the level of detail and effort required for execution of some processes, thefollowing should be considered when implementing the standard. The life cycle stage and the applicable exit criteria. The mission profiles, operational scenarios and operational concepts for eachmajor functional requirement of the Medical Device Software. The set of measures of effectiveness, with relative importance, by which theacquirer typically determines satisfaction of the requirements. Empirical data that describes the constraints and risks that could affect the projectand organization, including budget, resources, competition and schedule. The technology base and any limitations on the use of technologies.PharmOut Pty Ltd, ABN: 85 117 673 766, Unit 10, 24 Lakeside Drive, Burwood East, Victoria 3151.Ph: 61 3 9887 6412, Fax: 61 3 8610 0169, Email: [email protected] Web: www.pharmout.net 2016 PharmOut. This document has been prepared solely for the use of PharmOut and its clients. Copying is prohibited.Page 8 of 15MKT TMP200 01 r06
PharmOut white paper:Implementation of ANSI/AAMI/IEC 62304 Medical Device Software Lifecycle ProcessesAmending guidanceEither the organizational unit responsible for forming policies and procedures, or the projectteam or individual assigned to plan the project can be responsible for completing appropriatemodification.To aid changing, the following factors affecting the project effort should be helpful: Project requirements such as the required work, schedule, funding and technicalrequirements based on the classification (for example functional requirements,performance requirements and interface requirements) can drive stage timing andthe definition of the Medical Device Software under consideration. Applicable processes should be used, only the processes of the ANSI/AAMI/IEC62304 Standard that apply to the domain, business of the organization and type oforganization (for example supplier, user, acquirer, or other stakeholder) should beincluded in project plans. Other processes that are not in the ANSI/AAMI/IEC 62304Standard can be required by an agreement, or they can be required by the natureof the project, the applicable Medical Device Software or the type of organization.These processes may be added, complete with their purpose, outcomes andactivities. Activities for each applicable process and the expected outcomes of each activityshould be selected. Software development models and tools required for activity completion should bedetermined. The applicable Software development models and tools are notmandated in the ANSI/IEC 62304 standard. Reporting and technical review requirements applicable to the life cycle stage orstipulated in the governing agreement or in organizational policies and proceduresshould be considered. Project measurement requirement provisions should be included for the collectionand reporting of key measures by which project progress will be evaluated. Requirements related to activities and tasks involving specialty engineering andfunctional disciplines may be integrated in appropriate processes. Theseprocesses include requirements (special requirements or critical project andMedical Device Software requirements) and life cycle stage entry or exit criteria(for example safety, security, design, software development, production and test).Specialty and functional plans that are needed to ensure completion of projectwork may be included in work definition. Applicable standards, policies and procedures, regulations and laws can be thesource of additional process and activity requirements to add to the workdefinition, even though not included in the ANSI/IEC 62304 Standard processrequirements.PharmOut Pty Ltd, ABN: 85 117 673 766, Unit 10, 24 Lakeside Drive, Burwood East, Victoria 3151.Ph: 61 3 9887 6412, Fax: 61 3 8610 0169, Email: [email protected] Web: www.pharmout.net 2016 PharmOut. This document has been prepared solely for the use of PharmOut and its clients. Copying is prohibited.Page 9 of 15MKT TMP200 01 r06
PharmOut white paper:Implementation of ANSI/AAMI/IEC 62304 Medical Device Software Lifecycle ProcessesDepending on the size and scope of the project, the type of organization and whether theMedical Device Software is the object of the project, one or more of the ANSI/IEC 62304Standard activities for a process could possibly be applied to develop the quality managementsystem.Likewise, outcomes and activities may be added to a process when needed to meet agreementrequirements or to meet unique requirements for a Medical Device Software.Get Started with Standard-Driven DevelopmentPolicies must be formed around any aspect of the development process, but to be effective theymust be definable, enforceable, measureable, and auditable.There are various types of policies that align with different goals as shown in figure 2.Process Policies drive overarching sets of tasks through to completion and usually establishquality gates associated with the completion of a release cycle.Examples include policies that oversee: Compliance with industry standards & regulations or recommendations Software development models Software lifecycle processes Project Implementation Risk Management.People (or human) policies can be designed based on role, responsibility, skill-level, etc. Theyoversee processes related to human interactions, for example: Task estimation Specification & documentation review TrainingQuality policies promote business objectives that are defined as non-functional requirements.They are measured by process monitors that deliver unprecedented visibility into the software.Examples include policies that cover: Application development (monitored by static code analysis) Code reliability (monitored by coverage analysis) Change impact (monitored by regression testing).Adopting a combination of these policy types leads to a number of benefits that fundamentallyimprove the development process.PharmOut Pty Ltd, ABN: 85 117 673 766, Unit 10, 24 Lakeside Drive, Burwood East, Victoria 3151.Ph: 61 3 9887 6412, Fax: 61 3 8610 0169, Email: [email protected] Web: www.pharmout.net 2016 PharmOut. This document has been prepared solely for the use of PharmOut and its clients. Copying is prohibited.Page 10 of 15MKT TMP200 01 r06
PharmOut white paper:Implementation of ANSI/AAMI/IEC 62304 Medical Device Software Lifecycle ProcessesSummaryThe most important factor controlling the ability to produce defect-free software is the inabilityto conceive policies and procedures to oversee its development.At the same time, creating defect-free software requires discipline, which is burdensome andtime-consuming.Creating policies and procedures from standards and guidelines before the need arises doesnot come naturally, so the confrontation to policy-driven development is understandable. Theconfrontation though, is misguided by the prejudices engrained by traditional softwaredevelopment strategies.This confrontation will fade as organizations begin to realize that elevating guidelines todefinable, enforceable, measureable, and auditable policies will drastically improve how theydevelop software.It not only helps organizations accurately measure application quality and developmentproductivity, but also improve it by preventing errors and eliminating waste.Adopting a policy-driven development process is key for achieving the following goals: Ensuring that developers do not make trade-offs that potentially compromisereliability, performance and safety. Preventing defects that could result in costly recalls, litigation, or a damagedmarket position. Accurately and consistently applying quality processes. Gaining the traceability and auditability required to ensure continued policycompliance.PharmOut Pty Ltd, ABN: 85 117 673 766, Unit 10, 24 Lakeside Drive, Burwood East, Victoria 3151.Ph: 61 3 9887 6412, Fax: 61 3 8610 0169, Email: [email protected] Web: www.pharmout.net 2016 PharmOut. This document has been prepared solely for the use of PharmOut and its clients. Copying is prohibited.Page 11 of 15MKT TMP200 01 r06
PharmOut white paper:Implementation of ANSI/AAMI/IEC 62304 Medical Device Software Lifecycle ProcessesTermsDefinitionsActivityA set of one or more interrelated or interacting tasks.AnomalyAny condition that deviates from the expected based onrequirements specifications, design documents, standards, etc. orfrom someone’s perceptions or experience.ArchitectureOrganizational structure of a system or component.Change requestA documented specification of a change to be made to a softwareproduct.Configuration itemEntity that can be uniquely identified at a given reference point.DeliverableRequired result or output (includes documentation) of an Activity orTask.EvaluationA Systematic determination of the extent to which an entity meetsits specified criteria.HarmPhysical injury, damage, or both to the health of people or damageto property of the environment.HazardPotential source of harm.Medical DeviceAny instrument, apparatus, implements, appliance, implant, in vitroreagent or calibrator, software, material or other similar or relatedarticle, intended by the manufacturer to be used, alone or incombination, for human beings for one or more specific purpose(S)of diagnosis, prevention, monitoring, treatment or alleviation ofdisease, compensation for an injury, investigation, replacement,modification, or support of the anatomy or of a physiologicalprocess.Medical DeviceSoftwareSoftware system that has been developed for the purpose of beingincorporated into the Medical Device being developed or that isintended for a use as a Medical Device in its own right.Problem ReportA record of actual or potential behavior of a software product that auser or other interested person believes to be unsafe, inappropriatefor the intended use or contrary to specification.ProcessA set of interrelated or interacting activities that transform inputs tooutputs.Regression TestingThe testing required to determine that a change to a systemcomponent has not adversely affected functionality, reliability orperformance and has not introduced new defects.RiskCombination of the probability of occurrence of harm and severity ofthat harm.PharmOut Pty Ltd, ABN: 85 117 673 766, Unit 10, 24 Lakeside Drive, Burwood East, Victoria 3151.Ph: 61 3 9887 6412, Fax: 61 3 8610 0169, Email: [email protected] Web: www.pharmout.net 2016 PharmOut. This document has been prepared solely for the use of PharmOut and its clients. Copying is prohibited.Page 12 of 15MKT TMP200 01 r06
PharmOut white paper:Implementation of ANSI/AAMI/IEC 62304 Medical Device Software Lifecycle ProcessesRisk ControlProcess in which decisions are made and risks are reduced to, ormaintained within, specified levels.Risk ManagementSystematic application of management policies, procedures, andpractices to the tasks of analyzing evaluating, and controlling risk.Risk ManagementFileSet of records and other documents, not necessary contiguous, thatare produced by a risk management process.SafetyFreedom from unacceptable risk.SecurityProtection of information and data so that unauthorized or systemscannot read or modify them and so that authorized persons orsystem are not denied access to them.Injury or illness that directly or indirectly:Is life threatening,Serious InjuryResults in permanent impairment of a body function or permanentdamage to a body structure, orNecessitates medical or surgical intervention to prevent permanentimpairment of a body function or permanent damage to a bodystructure.Conceptual structure spanning the life of the software fromdefinition of its requirements to its release for manufacturing,which;Softwaredevelopment lifecycle modelIdentifies the PROCESS, ACTIVITIES and TASKS involved indevelopment of a SOFTWARE product,Describes the sequence of and dependency between ACTIVITIES andTASKS, andIdentifies the milestones at which the completeness of specifieddeliverables is verified.Software ItemAny identifiable part of a computer program.Software ProductSet of computer programs, procedures, and possibly associateddocumentation and data.Software SystemIntegrated collection of Software items organized to accomplish aspecific function or set of functions.Software unitSoftware unit that is not subdivided into other units.Software Of Unknown Provenance (acronym).Software item that is already developed and generally available andthat has not been developed for the purpose of being incorporatedinto the medical device (also known as “off-the-shelf software”) orsoftware previously developed for which adequate records of thedevelopment Processes are not available.SOUPPharmOut Pty Ltd, ABN: 85 117 673 766, Unit 10, 24 Lakeside Drive, Burwood East, Victoria 3151.Ph: 61 3 9887 6412, Fax: 61 3 8610 0169, Email: [email protected] Web: www.pharmout.net 2016 PharmOut. This document has been prepared solely for the use of PharmOut and its clients. Copying is prohibited.Page 13 of 15MKT TMP200 01 r06
PharmOut white paper:Implementation of ANSI/AAMI/IEC 62304 Medical Device Software Lifecycle ProcessesSystemIntegrated composite consisting of one more of the processes,hardware, software, facilities, and people, that provides a capabilityto satisfy a stated need or objective.TaskA single piece of work that needs to be done.TraceabilityDegree to which a relationship can be established between two ormore products of the development process.VerificationConfirmation through provision of objective evidence that specifiedrequirements have been fulfilled.VersionIdentified instance of a configuration item.SourcesLinks used within this document are prone to change. Please refer to the appropriate source forthe most recent information. We endeavour to keep an up-to-date record of information atwww.pharmout.netPharmOut Pty Ltd, ABN: 85 117 673 766, Unit 10, 24 Lakeside Drive, Burwood East, Victoria 3151.Ph: 61 3 9887 6412, Fax: 61 3 8610 0169, Email: [email protected] Web: www.pharmout.net 2016 PharmOut. This document has been prepared solely for the use of PharmOut and its clients. Copying is prohibited.Page 14 of 15MKT TMP200 01 r06
PharmOut white paper:Implementation of ANSI/AAMI/IEC 62304 Medical Device Software Lifecycle ProcessesPharmOut is an international GMP consultancy serving the Pharmaceutical, Medical Device andVeterinary industries. PharmOut specialises in PIC/S, WHO, United States FDA, European EMA,and Australian TGA GMP consulting, engineering, project management, training, validation,continuous improvement and regulatory services.Our team includes international GMP experts who have previously held leadership roles withinregulatory bodies.For more information please visit www.pharmout.net or contact us at [email protected] Pty Ltd, ABN: 85 117 673 766, Unit 10, 24 Lakeside Drive, Burwood East, Victoria 3151.Ph: 61 3 9887 6412, Fax: 61 3 8610 0169, Email: [email protected] Web: www.pharmout.net 2016 PharmOut. This document has been prepared solely for the use of PharmOut and its clients. Copying is prohibited.Page 15 of 15MKT TMP200 01 r06
ANSI/AAMI/IEC 62304 Standard applies to the development and maintenance of medical device software where the software itself is a medical device or when the software is an embedded or integral part of the final medical device. The standard does not cover testing, val
