Introduction
If you are developing a medical device that uses software, or if you are developing a SaMD (Software as a Medical Device), it is important to understand and comply with applicable regulatory requirements.
Manufacturers should consider IEC 62304 early in the development process. A common problem is that there can be a mismatch between brilliant developers on the one hand and medical device terminology and regulations on the other. This can happen when they get caught up in designing some great new software, but don't care about regulatory requirements at an early stage.
ADN offers you support in implementing the requirements of the IEC 62304 standard for your software integrated in medical device (SiMD) or SaMD software.
What is IEC 62304?
IEC 62304: 2006 / AMD 1:2015 is the current version of the international standard that defines software lifecycle processes used in medical devices. This standard is considered a harmonized standard and therefore recognized by regulatory authorities such as the European Commission, the FDA and many others around the world.
Specifically, IEC 62304 applies to both stand-alone medical device software (SaMD) and software embedded in an end-use medical device (SiMD).
It provides guidance for the planning, development, and post-market surveillance activities of medical device software. It should be implemented early in the planning phase and should continue after market launch.
How is IEC 62304 organized?
The IEC 62304 security framework is meant to be implemented together with a quality management system (QMS) and a standardized risk management system. With these systems in place, IEC 62304 enables safe software development and implementation beyond product testing and risk analysis.
It does this by defining three security classifications for software. Each classification has different requirements for documentation of the development process. The standard is divided into 9 chapters. The first 4 chapters define the scope of the standard as well as references, terms and general requirements. The following 5 chapters are key to compliance with the IEC 62304 standard:
Chapter 5 - Software Development Process
Chapter 6 - Software Maintenance
Chapter 7 - Software Risk Management
Chapter 8 - Software Configuration Management. It includes change control and configuration status tracking
Chapter 9 - Solving Software Problems
Software safety classification according to IEC 62304?
It is important to ensure security from the start of development. Product testing is not enough to guarantee patient safety. However, patient safety is essential. Yet, building security into your processes from the start saves time and money later.
The software security classification in the standard determines which security-related processes you will need to use. This impacts the entire software development cycle, from requirements and coding to release and maintenance.
The standard defines three security classes for software in its Chapter 2 – General Requirements
Class A: no injury or damage to health is possible
Class B: an injury is possible, but not serious
Class C: Death or serious injury is possible.
The documentation required for the development of the software process depends on the security classification, as shown in the table below.
Documentation | Class A | Class B | Class C |
Development Planning | ✔ | ✔ | ✔ |
Requirements analysis | ✔ | ✔ | ✔ |
Architectural design | | ✔ | ✔ |
Detailed design | | | ✔ |
Unit Implementation | ✔ | ✔ | ✔ |
Unit checking | | ✔ | ✔ |
Integration & integration testing | | ✔ | ✔ |
System testing | ✔ | ✔ | ✔ |
Release | ✔ | ✔ | ✔ |
Maintenance | ✔ | ✔ | ✔ |
| | | |
How does ADN support you?
To comply with this standard, processes must be well documented. Using software lifecycle management tools like the Atlassian suite can help you meet this need and speed compliance.
How? Let's take a few application examples for each of the 5 chapters of the standard.
Chapter 5 - Software Development Process
This chapter describes the software development activities to be carried out for each class of medical device. The use of Software Lifecycle Management Application can help to effectively meet these documentation requirements.
Examples:
1. Management of software requirements and specifications
Two of the most important things to think about when it comes to IEC 62304 compliance is managing requirements, software specifications, and ensuring their traceability. Most of the time, we notice that the requirements are documented in a Word file, an Excel spreadsheet or for the lucky ones on a wiki. The same goes for specs. The only way to achieve vertical traceability in this case is to put numbers next to each requirement and specification and then freely copy and paste those numbers into both documents and watch the information become unmanageable and unmaintainable very quickly. To simplify this tedious work, the integration of Jira and Confluence is a great solution.
With its properties of JIRA tickets and their type, you can create ticket types to be allocated to each level of software specification i.e. SRS, SAD, SDD under Confluence. The visible benefits and advantages for the company are as follows:
Each software requirement can be identified thanks to its type, but above all its key automatically generated during the creation of the ticket.
In addition, Jira also allows you to establish links between issues. The type of link therefore makes it possible to ensure the nature of the traceability between requirements (coverage, dependency, blocking, etc.). Thus, by exploring a requirement ticket one can know from which it derives and which ones cover it.
A JIRA audit trail is automatically enriched with each requirement modification.
Requirements are also associated with a software version.
The specification is automatically generated and updated in Confluence based on a JIRA filter.
2. Setting up the tests
IEC 62304 specifies the need to establish tests for software requirements. Several solutions exist to meet this need: We offer the JIRA "X-Ray" plugin to generate test cases related to the requirements. The visible benefits and advantages for the company are as follows:
It creates a new ticket of type "Test" to which you can add the standard text block as well as the different test steps you want. The advantage of managing your tests under JIRA is to directly establish traceability with the requirements to which they are linked.
X-Ray also has the "Test plan" type to create test cycles. The typical example is that of a software release at the end of a sprint. The idea is to create for each sprint or software version, one or more test plans where all the test cases of the sprint will be housed. These test plans have the advantage of tracking sprint/release test results and presenting a schematic overview of test execution at any given time as evidence during the product design verification phase.
X-Ray automatically generates a traceability matrix between requirements, tests, their execution and bugs.
3. Unit testing process
In addition, Class B and Class C software must also establish a software unit verification process. You can meet this requirement by using the code coverage, code analysis and data flow tools offered by your software development platform (Gitlab, Bitbucket, etc.) whose integration with JIRA is possible to harmonize the data on the same platform. The visible benefits and advantages are as follows:
View code associated with development tasks
Integrate software development activities into the overall project schedule
Automate the progress of development tasks in relation to the result of unit tests
Chapter 6 - Software Maintenance
Chapter 6 of IEC 62304 describes the software maintenance process. This includes:
The establishment of a software maintenance plan
Problem analysis and change requests
The implementation of changes
During this phase, it is important to take into account software change requests, user feedback and to resolve problems that have arisen after the release of the medical device software.
For budget-constrained manufacturers who are looking for a cost-effective and efficient software maintenance management solution, the architecture based on a DevOps approach that we propose around the Atlassian platform is suitable and will allow them to set up a maintenance process in accordance with the requirements of this chapter of IEC 62304. To convince you of this, let us take few application cases.
Examples:
The establishment of a maintenance plan
In the same way that Confluence was used in the previous chapter to document the software specifications, it will also be used to document the software maintenance plan. This plan, which is subject to change, must be versioned, approved and traced like any QMS document. We rely on our DMC tool, Confluence plugin, which combined with it constitutes a structured electronic quality management system (e-QMS). This custom Confluence-based architecture supports functions such as implementation, versioning, e-signature approval, secure documentation access, and standards compliance throughout the software lifecycle.
2. Analysis of software problems
Software problem analysis uses the software problem resolution process to document, evaluate user feedback that results in a software defect. This process distinguishes between software issues identified on an official release and in development. Maintenance focuses on those identified on a release.
Using JIRA and Jira Service Management (JSM), it is possible to create such a process consisting of the following elements:
Inputs to the process: each problem is reported on a JSM portal configured according to the source of the problem (internal or external user, non-compliance or customer complaint). The portal interface has the advantage of being customizable with several fields to fill in for each problem identified.
Registration: each problem registered via the JSM form creates a JIRA ticket of the "Problem Report" type which includes the fields previously filled in, including the asset (Asset) or configuration element native to JSM which will allow the tickets to be mapped . Each "Problem Report" type ticket created is only accessible internally to the agent in charge of collecting and evaluating problems after release. In this way, the problem is reported and stored automatically in a database classified by lists according to the type of assets created (software, electronics, mechanics, ...) or according to the asset itself (version software for example). Each list is made up of several problem tickets related to an asset or more generally to the type of asset and may be reviewed periodically. Jira Software Management also offers the possibility for operators at the manufacturer to interact with the initiator of the ticket and thus keep him informed of the progress of the problem reported. The advantage here is to centralize all the information on a single platform.
Evaluation: Each issue is assessed in the dedicated JIRA space to determine if it is an anomaly, how it affects the security of the software product, and what change is needed to resolve the issue. The scope of the change is evaluated and documented through ticket properties: affected software versions, related software specifications, resources and time required to resolve the issue. Once the assessment is done, a priority can be assigned to the JIRA issue based on the results of the assessment.
3. Analysis of change requests
Input to software changes can come not only from a need for problem solving, but also from anyone in the company, from external consultants, or even from customers. This data should be communicated to the maintenance process owner, who can initiate the design change request by creating a "Design Change Request Form" in the same manner as the problem reports previously illustrated. Software change requests are intended to implement specific and limited changes, aimed at making improvements to the initial project in areas such as reliability, architecture, addition of functionality, ease of use, ease of maintenance or ease of manufacture.
The change request created on the JSM form is then saved and, if approved, the resulting changes are managed as "software change" tickets in JIRA.
The software change ticket follows the steps defined in a JIRA workflow specific to this type of ticket. Similarly, it can be broken down into activities and artefacts (requirements, test cases, etc.) which can be assigned and tracked individually.
4. Implementation of Changes
Software changes necessary to implement modifications resulting from a software problem or a change request must be implemented by the design team of the software solution: update of the risk analysis, software requirements under JIRA, coding and versioning. Once these actions have been completed, a specific verification test phase must be carried out. To verify that the implementation is correct, test cases are created and executed under JIRA using the X-Ray plugin. The execution of the tests is of course linked to the source ticket of the software modification. If the test is successful, the assignee changes the ticket to RESOLVED. If not, the assignee should continue to work on the problem until they get the desired result. If the product design team has decided not to proceed, the ticket moves to CANCELED status.
Chapter 7 - Software Risk Management
Chapter 7 of IEC 62304 describes the software risk management process.
This includes:
identification and analysis of software elements contributing to dangerous situations
risk management
verification of risk management
The risk management process assumes the existence of a comprehensive risk management procedure, in accordance with the ISO 14971 standard. Thus, risk management is not only about software. It can also include risk management for elements such as Hardware or user errors (URRA).
This process is implemented and maintained throughout the software development cycle and aims to ensure that software is developed in a way that minimizes risk to patient safety.
For manufacturers developing stand-alone medical device software (SaMD) or software-integrated medical device (SiMD), risk management is one of the cornerstones of their compliance. If you already use Jira for other design activities, from user requirements to testing, it makes sense to also extend it to risk management for end-to-end visibility and accessibility. You will also facilitate the participation and commitment of your team members in this process. Let's see some application cases.
Examples:
1. Risk analysis of software elements
Overall risk analysis can be done in different ways. Many techniques are used, including preliminary hazard analysis, FMEA and use risk analysis. The risk management process must be able to justify the choice of one of them and define the risk assessment criteria. The Softcomply Risk Manager plug-in offers risk table templates and evaluation matrices for each of these techniques to customize according to your needs.
For software risk analysis, the SoftComply Risk Manager hazard analysis table template based on ISO 14971 is suitable.
This table already has in its native configuration, the minimum fields in the form of columns required for a top-down risk analysis approach. This table, in the form of a pre-populated spreadsheet, is an excellent starting point. Small precision: for software, the cause of a dangerous situation is its malfunction, also called in risk management "sequence of events". Thus for more clarity, the "Cause" column can be renamed by "Reasonably forseeable sequence or combination of events".
Risk assessment matrices are also customizable. It is thus possible to modify the levels of severity or probability and the classes of risks.
With the risk matrix configured, we will begin to document risks. Each risk recorded creates a JIRA ticket of the "Risk" type which includes the values of the fields entered. The evaluation of a risk is done by selecting the probability of occurrence of the hazard and the level of severity in accordance with the evaluation matrix. The risk class is automatically assigned to it after definition of a severity and probability.
2. Risk management
For each case documented in the risk management file where a software element can contribute to a dangerous situation, you must define and document a risk control measure in accordance with ISO 14971 for class B and C software. The risk control measure can be implemented at the level of hardware, software, the work environment or instructions intended for users (IFU, Labelling). Within the framework of IEC 62304, we are interested in the control measures implemented at the software level. The "Hazard analysis" table of Softcomply already offers in its right part basic fields for risk control, in particular the column of mitigations or risk control measures, the residual probability and severity.
For risk control measures implemented as part of the functions of a software element, the manufacturer must document the risk control measure in the form of a software requirement (SRS, SAD, SDD) identified by a ticket JIRA existing or to be created from the same table. The displayed properties of this ticket are its key, summary, and status. This allows you to have a quick overview of the actions carried out, in progress or to be done. To better meet the requirements of the IEC 62304 standard, it will be necessary to add "Software Item" and "Item Class" columns corresponding to the software item where the risk control measure will be implemented.
After performing your initial risk analysis and defining mitigation actions, it is time to evaluate the residual risks. The same model proposes residual probability and residual severity fields. By entering a value for each of these fields, the residual risk class is automatically assigned. You can therefore see the overview of the assessment line by line in the first column "Risk" and a complete overview of the initial and residual risks in the risk matrix view.
3. Verification of risk management
To ensure that the mitigations assigned to the risk reduce their class, you will need to verify them. Just like mitigation columns, verification actions can also be added using a column labeled "Verification links". This allows you to add links (verification links) to the test cases of a software project in Jira. You can also create a new test case from the table.
4. Production of risk traceability
There are several risk reports in SoftComply Risk Manager. Depending on the platform and tools you use in addition to SoftComply Risk Manager, you will be able to produce different types of integrated reports. In addition to the native "Risk Management Plan" and "Risk Management Report" reports pre-populated and exportable in different formats, we offer additional risk reporting options on Confluence thanks to the SoftComply Risk Manager for Confluence Cloud plugin . It is a free extension of Confluence for risk reports. This app lets you create and customize risk reports in Confluence by adding risk matrices and tables to your Confluence pages.
The benefits and advantages of using the Atlassian ecosystem for risk analysis are as follows:
Proposal of a collaborative interface that will allow the participation and commitment of your team members in this process.
An instant, always-up-to-date view of the risk matrix on Jira and Confluence: While Excel has good functionality for various charts (including those pivot tables that seem to constantly break), the SoftComply Risk Manager apps for Jira feature high-value risk matrix objects that can be added in seconds to a Jira reporting dashboard
Better risk management traceability: linking risks, mitigation measures (software requirements), risk verification and corresponding software elements
The assignment to an owner of each identified risk
An easier impact analysis in the event of design changes
Overview of the audit trail of changes: A risk management in Jira allows you to see the complete history of the people who created, modified and worked on each risk element.
The ability to export each risk management document in different formats or more generally the entire Risk Management File.
Chapter 8 - Software configuration management.
Expected publication date: September 30, 2023
Chapter 9 - Troubleshooting Software
Expected publication date: October 31, 2023
Conclusion
The IEC 62304 standard is one of the pillars of our integrated quality management system.
Our team of engineering consultants, highly experienced in the development of SaMD and SiMD medical devices, can support you in complying with the IEC 62304 standard in an agile environment.
Do not hesitate to contact us via the form below so that we can discuss your project and the options available to you.
Comments