1 Scope
1.1 * Purpose
This standard defines the life cycle requirements for medical device software. The set of processes, activities, and tasks described in this standard establishes a common framework for medical device software life cycle processes.
1.2 * Field of Application
This standard applies to the development and maintenance of medical device software.
This standard applies to the development and maintenance of medical device software when software is itself a medical device or when software is an embedded or integral part of the final medical device.
This standard does not cover validation and final release of the medical device, even when the medical device consists entirely of software.
1.3 Relationship to Other Standards
This medical device software life cycle standard is to be used together with other appropriate standards when developing a medical device. Annex C shows the relationship between this standard and other relevant standards.
1.4 Compliance
Compliance with this standard is defined as implementing all of the processes, activities, and tasks identified in this standard in accordance with the software safety class.
Note: The software safety classes assigned to each requirement are identified in the normative text following the requirement.
Compliance is determined by inspection of all documentation required by this standard including the risk management file, and assessment of the processes, activities and tasks required for the software safety class. See Annex D.
Note 1 This assessment could be carried out by internal or external audit.
Note 2 Although the specified processes, activities, and tasks are performed, flexibility exists in the methods of implementing these processes and performing these activities and tasks.
Note 3 Where any requirements contain “as appropriate” and were not performed, documentation for the justification is necessary for this assessment.
Note 4 The term “conformance” is used in GB/T 8566 where the term “compliance” is used in this standard.
2 *Normative References
The following documents contain provisions which, through reference in this standard, constitute provisions of this standard. For dated reference, subsequent amendments to (excluding the corrections), or revisions of, any of these publications do not apply. However, parties to agreements based on this standard are encouraged to investigate the possibility of applying the most recent editions of the standards indicated below. For any undated references, the latest edition of the document referred to applies.
YY/T 0316 "Medical Devices - Application of Risk Management to Medical Devices" (YY/T 0316-2008, ISO 14971:2007, IDT)
3 *Terms and Definitions
For the purposes of this document, the following terms and definitions apply.
3.1
Activity
a set of one or more interrelated or interacting tasks.
3.2
Anomaly
any condition that deviates from the expected based on requirements specifications, design documents, standards, etc. or from someone’s perceptions or experiences. Anomalies may be found during, but not limited to, the review, test, analysis, compilation, or use of software products or applicable documentation.
[IEEE 1044:1993, definition 3.1]
3.3
Architecture
organizational structure of a system or component.
[IEEE 610.12:1990]
3.4
Change request
a documented specification of a change to be made to a software product.
3.5
Configuration item
entity that can be uniquely identified at a given reference point.
Note: Based on GB/T 8566-2007, definition 3.6.
3.6
Deliverable
required result or output (includes documentation) of an activity or task.
3.7
Evaluation
a systematic determination of the extent to which an entity meets its specified criteria.
[GB/T 8566-2007, definition 3.9]
3.8
Harm
physical injury, damage, or both to the health of people or damage to property or the environment.
[ISO/IEC Guide 51:1999, definition 3.3]
3.9
Hazard
potential source of harm.
[ISO/IEC Guide 51:1999, definition 3.5]
3.10
Manufacturer
natural or legal person with responsibility for designing, manufacturing, packaging, or labelling a medical device; assembling a system; or adapting a medical device before it is placed on the market and/or put into service, regardless of whether these operations are carried out by that person or by a third party on that person’s behalf.
[YY/T 0316-2008, definition 2.8]
3.11
Medical device
any instrument, apparatus, implement, machine, appliance, implant, in vitro reagent or calibrator, software, material or other similar or related article, intended by the manufacturer to be used, alone or in combination, for human beings for one or more of the specific purpose(s) of
——diagnosis, prevention, monitoring, treatment or alleviation of disease;
——diagnosis, monitoring, treatment, alleviation of or compensation for an injury;
——investigation, replacement, modification, or support of the anatomy or of a physiological;
——supporting or sustaining life;
——control of conception;
——disinfection of medical devices;
——providing information for medical purposes by means of in vitro examination of specimens derived from the human body.
And which does not achieve its primary intended action in or on the human body by pharmacological, immunological or metabolic means, but which may be assisted in its function by such means.
Note 1: This definition has been developed by the Global Harmonization Task Force (GHTF). See bibliographic reference [15] (in YY/T 0287-2003).
[YY/T 0287-2003, definition 3.7]
Note 2: Some differences can occur in the definitions used in regulations of each country.
3.12
Medical device software
software system that has been developed for the purpose of being incorporated into the medical device being developed or that is intended for use as a medical device in its own right.
3.13
Problem report
a record of actual or potential behaviour of a software product that a user or other interested person believes to be unsafe, inappropriate for the intended use or contrary to specification
Note 1: This standard does not require that every problem report results in a change to the software product. A manufacturer can reject a problem report as a misunderstanding, error or insignificant event.
Note 2: A problem report can relate to a released software product or to a software product that is still under development.
Note 3: This standard requires the manufacturer to perform extra decision making steps (see Clause 6) for a problem report relating to a released product to ensure that regulatory actions are identified and implemented.
