IEC 62304 Services

Overview

We can audit your software development lifecycle processes against the IEC 62304 standard and work with your team to fill any gaps. See below our procedure. Also, here is an example report.

Unlike many medical-device regulatory firms, we also provide engineering services. We speak both languages so we can work directly with your engineering team to help them find a process that meets the regulatory requirements yet won’t be overly burdensome.

Furthermore, we have templates and tools that can automate parts of IEC 62304. Here are a few examples:

• Generate problem reports, open anomalies reports, and change requests reports from GitHub, GitLab, or Jira Issues
• Trace between automated verification tests and their requirements using in-code annotations
• Generate a Software Bill of Materials from software requirements files
• Generate software design documentats from code documentation

We know how poorly designed software development processes can slow down the engineering team. Our process likely won’t work for you out of the box, but we can use it as a starting point to more quickly get you compliant.

Procedure

1. Kickoff meeting
   1. Discuss motivation for seeking IEC 62304 compliance and other goals for the project
   2. Quick introduction to IEC 62304 is and how it all fits together
   3. Talk through key terms and traceability
   4. Identify tools and documents we’ll need to access (e.g., GitHub, eQMS, Jira, wikis, etc.)
   5. Schedule weekly meeting
2. Information Gathering
   1. Review existing tools and documents
   2. Ask high-level software process questions to software engineering management
   3. Meet with the client to talk through their answers and ideate more
3. Identify gaps
   1. Filling in the audit report (see example report below) as we go
4. Gap assessment meeting
   1. Talk through the gaps
   2. Using our suggestions as a starting place, develop a plan to fill the gaps
5. Fill the gaps
   1. This varies from project to project
   2. We can provide template documents based on our own agile software development approach (which uses RDM)
   3. We can draft and review procedures
   4. We can provide training to engineers to help them follow these new processes
   5. We can help develop custom tooling to automate some of the more burdensome aspects of IEC 62304 (e.g., generating unresolved anomalies reports, test verification reports, etc.). We have some tooling available from past projects, but usually there is some customization involved.

Key IEC 62304 Documentation Items

Medical device regulators require software engineers to track a variety of regulatory items. A regulatory item refers to a unique set of things that must be documented. For example, you’ll need to document your software requirements. Each software requirement may have an “id” to track it, a “description”, and possibly a “type” or a “name” or other fields. Conceptually, each software requirement is a row in a software requirements database table. There are many other tables that you may have and these tables are related to one another, similar to how database tables are related with foreign keys.

This diagram shows a typical database schema for a medical device that includes software and hardware (SiMD). A software only device (SaMD) won’t have some of these tables. The diagram is also not complete. E.g., a larger project may have a “Sub System Requirements” table. Also, some of the relationships that are shown as many-to-many could als be one-to-many depending on your preference.