Software development for Medical Device according to IEC 62304


Clause 5 of IEC 62304

Today we will look at how IEC 62304 handles the software development process from planning to medical device release.

Some requirements depend on the security rating of the software ( trato disto no primeiro post desta série "Processo de ciclo de vida de software de equipamento Médico – IEC 62304"), in this case the software security class for which this item is required will be indicated.

Let's better understand sub-clause 5 of this document:

  1. 1. Software development planning - Establishes the processes that will be used in the development of the software system, the delivery items (including documentation) of activities and tasks, the traceability between system and software requirements, testing, and implementation of risk control measures in the software; In addition, it controls the software configuration and change management, used to support development; it also determines software troubleshooting for issues detected running at each stage of the lifecycle. He understands:
    • ▪Updated software development plan.
    • ▪ A reference from the software development plan to the system development project
    • ▪ Software development planning standards, methods and tools (requirement for class C software)
    • ▪ Software integration and integration test plan (requirement for class B and C software)
    • ▪ Planning for software verification
    • ▪ Planning for software risk management
    • ▪ Documentation planning
    • ▪ Software configuration management planning (requirement for class B and C software)
    • ▪Support items to be controlled (requirement for class B and C software)
    • ▪Software configuration item control before verification (requirement for class B and C software)
  2. 2. Software requirement analysis: defines and documents software requirements from system requirements, describes the content of software requirements, includes risk control measures in software requirements (requirement only for class B and C software), reassesses device risk analysis doctor to update requirements and verify software requirements tasks.
  3. 3. The software architecture project (requirement for class B and C software): Transforms the software requirements into an architecture, develops an architecture for the interfaces of the software items, defines the specification of the functional and performance requirements of the SDPD items, defines the specification of the software and hardware systems necessary for the SDPD item, identifies the necessary separation for risk control (requirement for class C software) and defines the verification of the software architecture.
  4. 4. Detailed software design: It presents the requirement for classes B and C to subdivide the software into software units, while for class C software it still requires the development of a detailed project for each software unit and interfaces, in addition to detailing the verification of this project.
  5. 5. Implementation and verification of the software unit: requires for all classes of software, to implement each software unit and for classes B and C requires that a software unit verification process be established presenting the acceptance and verification criteria of the software unit. For class C software still requires you to break down the acceptance criteria of the additional software unit
  6. 6. Software integration and integration testing (requirement for class B and C software): Defines that these classes should establish tests for software requirements, use the software troubleshooting process. Determines that a new test must occur after the changes and that there must be an evaluation of the software system test.
  7. 7. Software system test:determines that all classes of software that:
    • ▪ Establish tests for software requirements,
    • ▪Use the software problem solving process,
    • ▪Test again after changes
    • ▪ Evaluate the software system test
    • Keep the software system test log updated
  1. 8.Software release:
    • ▪Make sure the software check is complete
    • ▪Document known residual anomalies
    • ▪Assess known residual anomalies
    • ▪Posted versions of documents
    • Document how the released software was created (requirement for class B and C software)
    • ▪Make sure that activities and tasks are completed (requirement for class B and C software)
    • ▪File software
    • ▪Ensure reliable delivery of released software

Checklist da IEC 62304:2006 Amd1: 2015

I hope you enjoyed. Put in the comments if you want to go deeper into this subject or suggest a subject that you would like to see presented for discussion.

Ask in the comments for the checklist of this standard, leave your name and e-mail and I will send it to you free of charge.

Until the next post

Leave a comment

Your email address will not be published. Required fields are marked *