Skip to main content
QMSQMS
QMS
  • Welcome to your QMS
  • Quality Manual
  • Procedures
    • GP-001 Control of documents
    • GP-002 Quality planning
    • GP-003 Audits
    • GP-004 Vigilance system
    • GP-005 Human Resources and Training
    • GP-006 Non-conformity, Corrective and Preventive actions
    • GP-007 Post-market surveillance
    • GP-008 Product requirements
    • GP-009 Sales
    • GP-010 Purchases and suppliers evaluation
    • GP-011 Provision of service
    • GP-012 Design, Redesign and Development
      • Deprecated
      • Templates
        • T-012-001 Requirements
        • T-012-003 Test run
        • T-012-004 Software version release
        • T-012-005 Design change control
        • T-012-006 _Product name_ life cycle plan and report_YYYY_nnn
        • T-012-007 Formative evaluation plan_YYYY_nnn
        • T-012-008 Formative evaluation report_YYYY_nnn
        • T-012-009 Validation and testing of machine learning models_YYYY_nnn
        • T-012-010 Device backup verification_YYYY_nnn
        • T-012-012 Customers product version control_YYYY_nnn
        • T-012-014 Summative evaluation plan_YYYY_nnn
        • T-012-015 Summative evaluation report YYYY_nnn
        • T-012-016 Software usability test guide
        • T-012-017 Integration test review
        • T-012-018 Test plan
        • T-012-019 SOUP
      • Specific procedures
    • GP-013 Risk management
    • GP-014 Feedback and complaints
    • GP-015 Clinical evaluation
    • GP-016 Traceability and identification
    • GP-017 Technical assistance service
    • GP-018 Infrastructure and facilities
    • GP-019 Software validation plan
    • GP-020 QMS Data analysis
    • GP-021 Communications
    • GP-022 Document translation
    • GP-023 Change control management
    • GP-024 Cybersecurity
    • GP-025 Corporate Governance
    • GP-050 Data Protection
    • GP-051 Security violations
    • GP-052 Data Privacy Impact Assessment (DPIA)
    • GP-100 Business Continuity (BCP) and Disaster Recovery plans (DRP)
    • GP-101 Information security
  • Records
  • TF_Legit.Health_Plus
  • Licenses and accreditations
  • External documentation
  • Procedures
  • Records
  • Procedures
  • GP-012 Design, Redesign and Development
  • Templates
  • T-012-006 _Product name_ life cycle plan and report_YYYY_nnn

T-012-006 Product name life cycle plan and report_YYYY_nnn

Purpose​

To define the techniques, tools, resources and activities related to the development of the {name of device} to guarantee this development is performed following the IEC 62304:2006/A1:2015 Medical device software. Software life-cycle processes standard.

Terms and definitions​

  • Arquitecture: organizational structure of a system or component.
  • Change request: a documented specification of a change to be made to a medical device software.
  • Evaluation: a systematic determination of the extent to which an entity meets its specified criteria.
  • 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.
  • 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.
  • QMS: Quality Management System
  • Regression testing: the testing required to determine that a change to a system component has not adversely affected functionality, reliability or performance and has not introduced additional defects.
  • Safety: freedom from unacceptable risk.
  • Security: protection of the information and data so that unauthorized people or systems cannot read or modify them and so that authorized persons or systems are not denied access to them.
  • Software development life cycle model: conceptual structure spanning the life of the software from the definition of its requirements to its release, which:
    • identifies the process, activities and tasks involved in development of a medical device software,
    • describes the sequence of and dependency between activities and tasks, and
    • identifies the milestones at which the completeness of specified deliverables is verified.
  • Software item: any identifiable part of a computer program, for example, source code, object code, control code, control data, or a set of these elements.
  • Software system: integrated collection of software items organized to accomplish a specific function or set of functions.
  • Software unit: software item that is not subdivided into other items.
  • SOUP: software of unknown provenance (acronym). Software item that is already developed and generally available and that has not been developed for the purpose of being incorporated into the medical device (also known as “off-the-shelf software”) or software item previously developed for which adequate records of the development processes are not available.
  • Verification: confirmation through provision of objective evidence that specified requirements have been fulfilled.
  • Version: identified instance of a configuration item.
  • Legacy software: the medical device software that was legally placed on the market and that is already commercialized, but for which it does not exist sufficient objective evidence about the fact that was developed in compliance with the current version of this standard.
  • Release: particular version of a configuration item that is made available for a specific purpose.

Resources and responsibilities​

JD-XXX​

  • Name:
  • Position:
  • Education:
  • Experience with product/process/technology or state of the art:
  • Risk management training or other related training:
  • Responsibility:
  • Qualification required:
  • Authority:
info

Complete the information required above for each person involved in the life cycle process.

IEC 62304:2006/A1:2015 Checklist​

Instructions

Insert a table with all the requirements coming from IEC 62304:2006/A1:2015, their applicability and a reference to the section where the requirement is explained.

General requirements​

QMS and risk management​

We have in place a QMS based on the ISO 13485:2018 Medical devices. Quality management systems. Requirements for regulatory purposes and ISO 14971:2020 Medical devices.Application of risk management to medical devices standards to be able to manufacture any software as medical device in compliance with regulatory and clients requirements.

You can read about our QMS and risk management procedures at the documents Quality Manual and GP-013 Risk management, respectively.

Software safety classification​

Instructions

To include the software classification according to the IEC 62304:2006/A1:2015 standard.

Legacy software​

Instructions

To include the information of any legacy software that was commercialized previous to the medical device being manufactured. If this is the first version of the software this section does not apply.

Software development process​

Software development planning​

Instructions

Insert the software development plan for conducting the activities of the software development process appropriate to the scope and software safety classification of the software to be developed. The plan shall include the following:

  • processes to be used in the development of the software
  • deliverables (including documentation)
  • traceability between system requirements, software requirements, system tests, risk control measures implemented in the software
  • software configuration and chnage management, including SOUP configuration items and software used to support development
  • software problem resolution for handling problems detected in the software, deliverables, activities at each stage of the life cycle

Software requirement analysis​

Instructions

Insert where and how we document software system requirements, which shall contain:

  • type of requirements (e.g. functional and capability, security, usability, regulatory, installation)
  • risk control measures implemented in the software
  • how requirements will be verified

Minimum system and hardware requirements​

Instructions

Insert minimum software and hardware requirements to ensure the correct operation of the medical device. The requirements shall be divided into:

  • training and testing requirements
  • deployment requirements

Software architectural design​

Instructions

Insert information about software architecture, identification of software items and SOUP. For SOUP, include the following:

  • functional and performance requirements
  • system and hardware requirements to support proper operation of the SOUP item.

Insert how we verify the software architecture.

Software detailed design​

Instructions

Insert software units identified and their detailed designed, including a detailed design for any interfaces between the software units and external components.

Insert strategy, methods, procedures for verifying each software unit, including acceptance criteria to be met before integration of the software units into larger software items.

Software unit implementation and verification​

Instructions

Insert how we document the software unit verfification results.

Software integration and integration testing​

Instructions

Insert information about the integration plan to ensure proper integration of software units.

Insert how we evaluate integration test procedures for correctness and how we document the results of integration test, including regression test.

Describe how we evaluate any anomalies found during the integration testing.

Software system testing​

Instructions

Describe how we establish and perform system tests to ensure all software requirements are verified. Information about system test shall include:

  • inputs
  • expected outcomes
  • pass/fail criteria
  • procedures to conduct the test
  • traceability between software requirements and system tests
  • results of testing.

Describe how we document and evaluate anomalies found during system testing.

Describe how we manage changes made during system testing.

Software release​

Instructions

Describe the process for software release including how we docunent and evaluate known residual anomalies, environment and procedures used to create the released software and verfication of completeness of all activities.

Software maintenance process​

Establish software maintenance plan​

Instructions

Describe the software maintenance plan which shall include:

  • procedures for feedback management
  • criteria for determining when a feedback is to be considered a problem (non-conformity)
  • use of risk management process
  • procedure for analysing and resolving the problem
  • use of software configuration management process for managing modifications
  • procedure to evaluate and implement upgrades, bug fixes, patches and obsolescence of SOUP.

Problem and modification analysis​

Instructions

Describe the process to monitor, document and evaluate feedback on relased software from both inside and outside Legit.Health.

Describe how we manage feedback that are considered to be a problem (non-conformity) and how we communicate any issues with released software to customers and regulatory authorities.

Describe the process we follow in case of change in the released software.

Modification implementation​

Instructions

Describe how changes are implemented in the software and how we manage relased of new version of the software based on the type of change.

Software risk management process​

Analysis of software contributing to hazardous situations​

Instructions

Insert the software items that could contribute to hazardous situation and their potential causes of contribution to hazardous situation.

Describe how we evaluate published SOUP anomalies and where we document the results of the analysis.

Risk control measures​

Instructions

Describe the risk management process in place with particular focus on the risk control measures implementation phase for software items contributing to hazardous situations.

Insert the safety classification of each software item based on the possible effects of associated hazards.

Verification of risk control measures​

Instructions

Describe how we document the verification of implementation of risk control measures and how we ensure traceability between hazard, hazardous situation, software item, software cause, risk control measure and verification of risk control measure.

Risk management of software changes​

Instructions

Describe how we evaluate software changes with respect to safety, their impact on existing risk control measures, including chnages to SOUP.

Software configuration management process​

Configuration identification​

Instructions

Desctibe configuration items and how we control their versions.

For SOUP configuration item, include the following:

  • the name
  • the manufacturer
  • the designator

Change control​

Instructions

Describe the process for approval, implementation and verification of changes on configuration items, including how we ensure traceability between the change, the problem report triggering the change, approval of change and its verification.

Configuration status accounting​

Instructions

Describe how we ensure the availability of records of the history of controlled configuration items.

Software problem resolution process​

Prepare problem reports​

Instructions

Insert where we document the problem detected in the released software, including information about the type of problem, scope and criticality.

Investigate the problem​

Instructions

Describe the process to investigate problems and where we document the results of the investigation, including reference to chnage request (when applicable).

Advise relevant parties​

Instructions

Describe the process to notify customers and/or regulatory authorities about problem found in the released software.

Use change control process​

Instructions

Describe how the change control process is followed when a detected problem requires a software change in order to address and solve the problem.

Maintain records​

Instructions

Insert how we maintain all the applicable records when we detect a problem.

Analyse problems for trends​

Instructions

Describe the process for analysis of problems to identify whether there is any trends.

Verify software problem resolution​

Instructions

Describe how we verify the implementation of actions to solve the problem and where we document the verification.

Test documentation contents​

Instructions

Insert the content of testing due to a software change.

It shall include:

  • test results
  • anomalies found during testing
  • version of software tested
  • test tools
  • date tested
  • identification of the tester.

Annex I: Design control matrix​

User requirements control matrix​

Instructions

Insert traceability matrix between user requirements and system tests that verified them.

SRS control matrix​

Instructions

Insert traceability matrix between software requirement specifications and system tests that verified them.

Design requirements control matrix​

Instructions

Insert traceability matrix between design requirements and system tests that verified them.

Regulatory requirements control matrix​

Instructions

Insert traceability matrix between regulatory requirements and system test/other documentation that verified them.

Record signature meaning​

Signature meaning

The signatures for the approval process of this document can be found in the verified commits at the repository for the QMS. As a reference, the team members who are expected to participate in this document and their roles in the approval process, as defined in Annex I Responsibility Matrix of the GP-001, are:

  • Author: Team members involved
  • Reviewer: JD-003, JD-004
  • Approver: JD-001
Instructions

Delete this section when you create a new record from this template.

Signature meaning

The signatures for the approval process of this document can be found in the verified commits at the repository for the QMS. As a reference, the team members who are expected to participate in this document and their roles in the approval process, as defined in Annex I Responsibility Matrix of the GP-001, are:

  • Author: Team members involved
  • Reviewer: JD-003, JD-004
  • Approver: JD-001
Previous
T-012-005 Design change control
Next
T-012-007 Formative evaluation plan_YYYY_nnn
  • Purpose
  • Terms and definitions
  • Resources and responsibilities
    • JD-XXX
  • IEC 62304:2006/A1:2015 Checklist
  • General requirements
    • QMS and risk management
    • Software safety classification
    • Legacy software
  • Software development process
    • Software development planning
    • Software requirement analysis
    • Minimum system and hardware requirements
    • Software architectural design
    • Software detailed design
    • Software unit implementation and verification
    • Software integration and integration testing
    • Software system testing
    • Software release
  • Software maintenance process
    • Establish software maintenance plan
    • Problem and modification analysis
    • Modification implementation
  • Software risk management process
    • Analysis of software contributing to hazardous situations
    • Risk control measures
    • Verification of risk control measures
    • Risk management of software changes
  • Software configuration management process
    • Configuration identification
    • Change control
    • Configuration status accounting
  • Software problem resolution process
    • Prepare problem reports
    • Investigate the problem
    • Advise relevant parties
    • Use change control process
    • Maintain records
    • Analyse problems for trends
    • Verify software problem resolution
    • Test documentation contents
  • Annex I: Design control matrix
    • User requirements control matrix
    • SRS control matrix
    • Design requirements control matrix
    • Regulatory requirements control matrix
  • Record signature meaning
All the information contained in this QMS is confidential. The recipient agrees not to transmit or reproduce the information, neither by himself nor by third parties, through whichever means, without obtaining the prior written permission of Legit.Health (AI LABS GROUP S.L.)