{"id":3602,"date":"2021-05-17T20:41:39","date_gmt":"2021-05-17T13:41:39","guid":{"rendered":"https:\/\/www.squat.in.th\/en\/?p=3602"},"modified":"2025-10-22T21:40:09","modified_gmt":"2025-10-22T14:40:09","slug":"mds-vv-ep3","status":"publish","type":"post","link":"https:\/\/www.squat.in.th\/en\/mds-vv-ep3\/","title":{"rendered":"Medical Device Software Standards (Part 3)"},"content":{"rendered":"\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

IEC 60601-1 Clause 14 and IEC 62304<\/strong><\/span><\/p>

IEC 60601-1 Clause 14 and IEC 62304<\/span><\/b><\/p>

The software development processes defined in\u00a0IEC 62304<\/b>\u00a0and\u00a0IEC 60601-1 Clause 14<\/b>\u00a0follow the\u00a0V-Model<\/b>\u00a0of software development, as illustrated in\u00a0Figure 6<\/i>.
In IEC 60601-1 Clause 14, the\u00a0software system<\/b>\u00a0is defined as a sub-requirement under the\u00a0Programmable Electrical Medical System (PEMS)<\/b>\u00a0framework.<\/span><\/p>

During PEMS development, the\u00a0IEC 62304<\/b>\u00a0standard is applied at the\u00a0PEMS component level<\/b>\u00a0\u2014 from defining software requirements, through the assembly of\u00a0software items<\/b>, to integration into the overall\u00a0software system<\/b>.
This software system then becomes part of the\u00a0Programmable Electrical Subsystem (PESS)<\/b>.<\/span><\/p>

Therefore,\u00a0IEC 62304<\/b>\u00a0mainly addresses\u00a0software verification<\/b>\u00a0within the PESS but\u00a0does not<\/b>\u00a0cover full\u00a0software validation<\/b>\u00a0at the system level.<\/span><\/p>

\"\"\u00a0<\/p>

Figure 6 \u2013 Software as Part of the V-Model<\/span><\/b><\/p>

(Source: ANSI\/AAMI\/IEC 62304:2006, Medical Device Software\u2014Software Life Cycle Processes)<\/span><\/i><\/p>

In Figure 6:<\/span><\/p>

  • Green area:<\/span><\/b>\u00a0Software development process under IEC 62304<\/span><\/li>
  • White + Green area:<\/span><\/b>\u00a0PEMS development process under IEC 60601-1 Clause 14<\/span><\/li>
  • Rectangles:<\/span><\/b>\u00a0Development activities<\/span><\/li>
  • Solid arrows:<\/span><\/b>\u00a0Deliverables (inputs\/outputs of each activity)<\/span><\/li>
  • Dashed arrows:<\/span><\/b>\u00a0Deliverables incorporated into the Risk Management File<\/span><\/li>
  • Thick arrows (right-facing):<\/span><\/b>\u00a0Outputs from the software problem resolution process<\/span><\/li>
  • Thick arrows (left-facing):<\/span><\/b>\u00a0Inputs to the software problem resolution process<\/span><\/li><\/ul>
    <\/div>

    IEC 62304: Key Clauses<\/span><\/b><\/p>

    IEC 62304 comprises\u00a0six major clauses (4\u20139)<\/b>, as shown in\u00a0Figure 7<\/i>\u00a0and detailed below.<\/span><\/p>

    \"\"<\/p>

    Figure 7 \u2013 IEC 62304 Main Clauses<\/span><\/b><\/p>

    (Source: ANSI\/AAMI\/IEC 62304:2006, Medical Device Software\u2014Software Life Cycle Processes)<\/span><\/i><\/p>

    <\/div>

    Clause 4: General Requirements<\/span><\/b><\/p>

    This clause includes several sub-clauses:<\/span><\/p>

    • Clause 4.1 \u2013 Quality Management System<\/span><\/b>
      Requires software development to be conducted under a formal quality management system, generally aligned with\u00a0ISO 13485<\/b>.<\/span><\/li>
    • Clause 4.2 \u2013 Risk Management System<\/span><\/b>
      Requires a risk management process for software development, referencing\u00a0ISO 14971<\/b>.<\/span><\/li>
    • Clause 4.3 \u2013 Software Safety Classification<\/span><\/b>
      Defines the classification of software based on\u00a0safety severity levels<\/b>:<\/span><\/li><\/ul>

      Class<\/span><\/b><\/p><\/td>

      Description<\/span><\/b><\/p><\/td><\/tr><\/thead>

      A<\/span><\/b><\/p><\/td>

      Software that cannot cause injury or health damage.<\/span><\/p><\/td><\/tr>

      B<\/span><\/b><\/p><\/td>

      Software that may cause\u00a0non-serious injury<\/b>.<\/span><\/p><\/td><\/tr>

      C<\/span><\/b><\/p><\/td>

      Software that may cause\u00a0serious injury or death<\/b>.<\/span><\/p><\/td><\/tr><\/tbody><\/table>

      • Definitions:<\/span><\/b>
        • Software System:<\/span><\/b>\u00a0A complete software entity (or PESS) consisting of multiple software items.<\/span><\/li>
        • Software Item:<\/span><\/b>\u00a0A discrete unit of software, which may itself contain sub-items.<\/span><\/li>
        • SOUP (Software of Unknown Provenance):<\/span><\/b>\u00a0Software with unknown development and safety characteristics.<\/span><\/li>
        • Legacy Software:<\/span><\/b>\u00a0Software with known development and safety characteristics, reused in new systems.<\/span><\/li><\/ul><\/li><\/ul>
          <\/div>

          \"\"<\/p>

          Figure 8 \u2013 Software System Structure and Safety Classification<\/span><\/b><\/p>

          To determine a software system\u2019s safety class:<\/span><\/p>

          1. Identify all\u00a0software components<\/b>\u00a0within the system.<\/span><\/li>
          2. Assess the\u00a0severity level<\/b>\u00a0of each component.<\/span><\/li>
          3. Assign the overall system classification based on the\u00a0most severe<\/b>\u00a0component.<\/span><\/li><\/ol>

            Example:<\/span><\/b><\/p>

            • If components include Classes C, B, and A \u2192 the system is\u00a0Class C<\/b>.<\/span><\/li>
            • If components include Classes B and A \u2192 the system is\u00a0Class B<\/b>.<\/span><\/li>
            • If all components are Class A \u2192 the system is\u00a0Class A<\/b>.<\/span><\/li><\/ul>

              For example (see\u00a0Figure 8<\/i>):
              A software system includes\u00a0components X<\/b>\u00a0and\u00a0Y<\/b>, where Y consists of\u00a0subcomponents W (Class B)<\/b>\u00a0and\u00a0Z (Class C)<\/b>.
              \u2192 Component Y is\u00a0Class C<\/b>.
              \u2192 Even though X is\u00a0Class A<\/b>, the overall system becomes\u00a0Class C<\/b>\u00a0due to the most severe classification.<\/span><\/p>

              <\/div>

              Clause 5: Software Development Process<\/span><\/b><\/p>

              As shown in\u00a0Figure 6<\/i>, this clause describes the step-by-step software development process with the following sub-clauses:<\/span><\/p>

              1. Clause 5.1 \u2013 Software Development Planning<\/span><\/b>
                Planning the entire software development lifecycle.<\/span><\/li>
              2. Clause 5.2 \u2013 Software Requirements Analysis<\/span><\/b>
                Defining and analyzing functional and non-functional requirements.<\/span><\/li>
              3. Clause 5.3 \u2013 Software Architectural Design<\/span><\/b>
                Designing software architecture, identifying\u00a0software items<\/b>,\u00a0SOUP<\/b>, and\u00a0legacy software<\/b>\u00a0(see\u00a0Figure 8<\/i>).<\/span><\/li>
              4. Clause 5.4 \u2013 Software Detailed Design<\/span><\/b>
                Detailed design of software units.<\/span><\/li>
              5. Clause 5.5 \u2013 Software Unit Implementation and Verification<\/span><\/b>
                Coding each software item and performing\u00a0unit-level verification<\/b>.<\/span><\/li>
              6. Clause 5.6 \u2013 Software Integration and Integration Testing<\/span><\/b>
                Combining software items and testing their integration (see\u00a0Figure 9<\/i>).<\/span><\/li>
              7. Clause 5.7 \u2013 Software System Testing<\/span><\/b>
                Testing the complete integrated system (Figure 9 \u2013 circular area).<\/span><\/li>
              8. Clause 5.8 \u2013 Software Release<\/span><\/b>
                Preparing, installing, and verifying the software for deployment.<\/span><\/li><\/ol>
                <\/div>

                \"\"<\/p>

                Figure 9 \u2013 Levels of Software Testing<\/span><\/b><\/p>

                <\/div>

                Clause 6: Software Maintenance Process<\/span><\/b><\/p>

                This clause includes:<\/span><\/p>

                • 6.1 \u2013 Establish Software Maintenance Plan<\/span><\/b>
                  Define the post-release maintenance plan.<\/span><\/li>
                • 6.2 \u2013 Problem and Modification Analysis<\/span><\/b>
                  Analyze issues and modifications after system delivery.<\/span><\/li>
                • 6.3 \u2013 Modification Implementation<\/span><\/b>
                  Implement and verify modifications following analysis.<\/span><\/li><\/ul>
                  <\/div>

                  Clause 7: Software Risk Management Process<\/span><\/b><\/p>

                  Includes:<\/span><\/p>

                  • 7.1 \u2013 Analysis of Software Contributing to Hazardous Situations<\/span><\/b>
                    Analyze hazards from software items, SOUP, and legacy software.<\/span><\/li>
                  • 7.2 \u2013 Risk Control Measures<\/span><\/b>
                    Define and apply mitigation measures.<\/span><\/li>
                  • 7.3 \u2013 Verification of Risk Control Measures<\/span><\/b>
                    Verify risk reduction effectiveness.<\/span><\/li>
                  • 7.4 \u2013 Risk Management of Software Changes<\/span><\/b>
                    Manage risks arising from software changes.<\/span><\/li><\/ul>

                    Note:<\/span><\/i>\u00a0Clause 7 builds upon\u00a0Clause 4.2 (Risk Management)<\/b>.<\/span><\/p>

                    <\/div>

                    Clause 8: Software Configuration Management Process<\/span><\/b><\/p>

                    Key sub-clauses:<\/span><\/p>

                    • 8.1 \u2013 Configuration Identification<\/span><\/b>
                      Identify work products and outputs to be controlled (see\u00a0Figure 10<\/i>).
                      Examples include design documents, configuration items (CI), and file naming conventions, e.g.:<\/span>
                      • F-001-SoftwareDevelopmentPlan<\/span><\/b>\u00a0\u2192\u00a0Software Development Plan Form<\/i><\/span><\/li>
                      • File name: xxx-SoftwareDevelopmentPlan<\/span><\/li><\/ul><\/li><\/ul>

                        Control also includes:<\/span><\/p>

                          • File storage (electronic folders or physical cabinets)<\/span><\/li>
                          • Versioning (see\u00a0Figure 11 \u2013 left<\/i>)<\/span><\/li>
                          • Development path definition (see\u00a0Figure 11 \u2013 right<\/i>)<\/span><\/li><\/ul><\/li>
                          • 8.2 \u2013 Change Control<\/span><\/b>
                            Manage software changes systematically (see\u00a0Figure 12<\/i>).<\/span><\/li>
                          • 8.3 \u2013 Configuration Status Accounting<\/span><\/b>
                            Track status of configuration items \u2014 draft, reviewed, approved, etc.<\/span><\/li><\/ul>
                            <\/div>

                            \"\"<\/p>

                            \"\"<\/p>

                            \"\"<\/p>

                            Figures 10\u201312: Examples of Configuration and Change Management<\/span><\/b><\/p>

                            • Figure 10 \u2013 Example Configuration Item<\/span><\/i><\/li>
                            • Figure 11 \u2013 Versioning and Development Path<\/span><\/i><\/li>
                            • Figure 12 \u2013 Software Change Process<\/span><\/i><\/li><\/ul>
                              <\/div>

                              Clause 9: Software Problem Resolution Process<\/span><\/b><\/p>

                              Includes:<\/span><\/p>

                              • 9.1<\/span><\/b>\u00a0Prepare problem reports<\/span><\/li>
                              • 9.2<\/span><\/b>\u00a0Investigate problems<\/span><\/li>
                              • 9.3<\/span><\/b>\u00a0Advise relevant parties<\/span><\/li>
                              • 9.4<\/span><\/b>\u00a0Use change control process<\/span><\/li>
                              • 9.5<\/span><\/b>\u00a0Maintain records<\/span><\/li>
                              • 9.6<\/span><\/b>\u00a0Analyze problems for trends<\/span><\/li>
                              • 9.7<\/span><\/b>\u00a0Verify software problem resolution<\/span><\/li>
                              • 9.8<\/span><\/b>\u00a0Test documentation contents<\/span><\/li><\/ul>

                                \u00a0<\/p>

                                \"\"<\/p>

                                An example process is shown in\u00a0Figure 13 \u2013 Software Problem Resolution Process<\/i>.<\/span><\/p>

                                <\/div>

                                After Software Development<\/span><\/b><\/p>

                                Once medical device software development is complete, manufacturers should verify all required\u00a0evidence items<\/b>\u00a0(see\u00a0Figure 14<\/i>).
                                This\u00a0Evidence List<\/b>\u00a0corresponds to the primary and sub-requirements of\u00a0IEC 62304<\/b>, and will be submitted to the\u00a0Testing Laboratory<\/b>\u00a0for certification or regulatory approval.<\/span><\/p>

                                <\/div>

                                \"\"
                                Figure 14 \u2013 Example Evidence List<\/span><\/b><\/p>

                                <\/div>

                                Conclusion<\/span><\/b><\/p>

                                This three-part article series has presented an overview of\u00a0IEC 62304<\/b>, the international standard for\u00a0medical device software life cycle processes<\/b>.
                                In the next article, we will continue exploring related standards \u2014 particularly\u00a0IEC 60601-1 Clause 14<\/b>, which governs safety requirements for programmable electrical medical systems (PEMS).<\/span><\/p>

                                Stay tuned!<\/span><\/p>

                                <\/div>

                                References<\/span><\/b><\/p>