(Co-written by Dr. Marion Lepmets, SoftComply, and Mike Rink, Comalatech)

Until recently, the Medical Device industry was comprised of a handful of large and well-established hardware manufacturing organizations. As those devices have become more software-driven, so too have software development companies begun working closer with the medical device manufacturers. In addition to supplying software to those manufacturers, these software companies now also independently develop medical products built for consumer devices, e.g. iPhone or Android apps. The ubiquity of consumer electronics allows for almost any software company or app developer to enter this highly regulated market. Today, the majority of medical device software in the EU is developed by small and medium sized software companies. But, regardless of their expertise in software development, most of them are new to the world of medical device regulations.

The biggest challenge facing fledgling medical device software developers is adhering to the same set of rigorous regulations as the established medical device manufacturers, to ensure that their products are safe to use; in the medical world,  software is held to the same standard as hardware. Software as a medical device cannot be released on the market without first passing regulatory audits to confirm that the product is safe and effective1. This requires significant additional time and investment from developers.

This case study examines the challenges that small-to-medium software companies face when entering the regulated medical device industry, how they can overcome them, and the tools they should use.

The Challenges of Becoming a Compliant Medical Device Company

Challenge 1 – Implementing a Compliant Quality Management System (QMS)

Companies operating in safety-critical industries like automotive, aerospace, or medical devices, face complex regulatory requirements to which they need to comply. Medical device companies must acquire a CE mark to sell their products in the EU, or FDA approval for the US market.

These regulatory tests include the presentation of rigorous planning and execution documentation. For medical device companies it means assembling a Design Technical File, and providing evidence that the company operates within a ISO13485-compliant Quality Management System.

In other words, teams must prove that they know what they are doing – demonstrating consistency in their software development, as opposed to achieving success through luck.

Challenge 2 – Implementing Digital Document Control for Fully Electronic QMS

Safety-critical products can be very complex, and so they are often developed by distributed teams, or in a partnership of several companies working together. In order to pass regulatory product approval, detailed specifications must be recorded, including logging any approved changes to the specifications. Regulatory audits require a documented historical trail; for example, a history of all the changes that were requested, approved and implemented throughout the development lifecycle. Manual document control can be successfully used, but it often results in cumbersome processes, and human error is likely to creep into project documentation in large projects.

Although this process can be extremely complicated and interconnected in big teams, the standard requirements for Document Control are actually quite simple.

These requirements, described in ISO 13485:2016 §4.2.4 and §4.2.5, and 21 CFR 820.40, are summarized below:

  1. Documents must be reviewed and approved, i.e. have signatures (electronic or handwritten) and date;
  2. If reviewed or modified, they must be re-approved;
  3. Each document must have a revision and the revision must be clearly displayed on it;
  4. Each document should be clearly identified as draft (not released), released or obsolete (other states are possible, these are the minimum requirements);
  5. Documents must be available for people who need and use them;
  6. Documents must remain legible;
  7. The company must prevent documents from being lost or damaged;
  8. Obsolete documents cannot and should be prevented from being used,
  9. External document (e.g. standards, regulations) must be controlled;
  10. Changes must be approved by the same function(s) (e.g. R&D) as the initial approval, or equivalent; record of changes shall be kept.
  11. Documents must be retained for the life of the device, but not less than records generated by these documents; (e.g.: SOP-AA-bbb gives guidance on how to fill in FORM-cccc; FORM-cccc was used to document the test of product X; thus SOP-AA-bbb cannot be destroyed until the end of life of product X (but it can be Retired / Obsolete)). Note: specific jurisdictions and devices may have higher or different requirements.
  12. Records (e.g. completed forms, results, etc.) follow the same principles;
  13. Records must be retained for the life of the device, but not less than 2 years; Note: specific jurisdictions and devices may have higher or different requirements.
  14. There must be procedures that control the document management process.

Obviously all of this can be done manually, but with distributed teams and large projects digital document control systems with e-signatures is the most convenient solution.

The biggest roadblock for electronic records and electronic signatures is the compliance to 21 CFR 11. Amongst several other requirements, it requires the validation of the electronic document management system and electronic signatures. With the wrong tools this can quickly become a very complicated task.

Both FDA and ISO 13485 require a document control system that demonstrates product safety and reliability.  Automated systems drive processes that integrate workflow and data capture with applications, databases, notifications and tracking. Getting rid of paper and investing in the right electronic solution not only enhances organizations’ digital document handling but also increases the likelihood of regulatory compliance.

Challenge 3 – Implementing a Compliant Risk Management Solution that is fully integrated to the Software Development Environment

Safety-critical software systems are developed within a risk-based framework; the regulatory framework requires the assessment and mitigation of all reasonably foreseeable risks prior to releasing the products on the market.

The ISO 14971 compliant risk management process is in practice a core part of the Quality Management System.

The medical device risk management process has to be documented in a Risk Management Plan, while all the risks, mitigation actions, and verifications need to be reported in a Risk Report. The goal of such detailed and compliant risk management processes is to ensure that medical devices are safe; in the Medical Device world, the word “safety” means “freedom from unacceptable risk”, which implies that any device is always associated with a level of residual risk. Simply put, when dealing with people’s lives, teams must exercise extreme caution. The risk assessment includes the determination of key hazards, risks, failure modes, and mitigations.

How Software Teams Can Overcome These Challenges

Teams that wish to design software for medical devices should take a three-pronged approach to overcoming their compliance challenges:

  1. Implement a Quality Management System (QMS)
  2. Add Digital Content Control to the QMS
  3. Automate the risk management process

Develop and implement an ISO13485 and IEC62304 compliant Quality Management System

When supplying software to medical device manufacturers, companies must demonstrate that they operate according to applicable standards and regulations. Clients (hardware manufacturers) want to ensure that the product is developed to a standard they feel comfortable submitting and defending to regulatory agencies. To achieve this, a software developer must implement a Quality Management System and document its activities. Regardless of whether the software is developed under the client or supplier’s Quality Management System, developers must have an adequate familiarity with applicable standards and regulations, and documentation management in general.

This is where medical device companies could benefit from SoftComply’s eQMS product, the development of which was motivated by the challenges medical device companies face. Choosing a pre-packaged QMS like eQMS it would have saved months of time.

SoftComply analyzed the experiences of emerging software companies to find the ideal method for a new medical device software provider to achieve compliance. The lessons learnt from medical device companies formed the underlying concepts of SoftComply eQMS:

  1. Simple. Maintain a limited number of procedures and templates, to ensure compliance without excessive paperwork overburdening a company. The FDA refers to this as the “least burdensome approach”; quality instead of quantity.
  2. Usable. Procedures are written to be understood by the average user, not an expert in the regulations. The documents in the SoftComply eQMS were created with day-to-day use in mind. Unlike other pre-packaged QMSs, there is little need to consult the parent standards to understand how to use each procedure or template.
  3. Embedded: it is not necessary to install a new software package or revolutionize the IT infrastructure. The SoftComply eQMS is built for Atlassian Confluence, one of the many Atlassian products compatible with Atlassian Jira.

Teams simply establish their Quality System as a space in Confluence (Fig. 1), allowing their users to work with the SOPs and technical documents. Developers can then copy the required templates to any product development project space within Confluence and customize them to whatever the specific project required.

Figure 1 – Compliant Quality Management System in a Confluence Space

Add Digital Document Control to the Quality Management System

With a compliant Quality System and all medical device related documentation on Confluence, the next step is to implement digital document control.

Figure 2 presents a simplified diagram of the regulatory requirements of document control, as set out by the FDA and ISO 13485:

Figure 2 – Compliant document control workflow based on ISO 13485

To meet document control needs many companies turn to Comala Workflows, an app available for Confluence. Based on existing document control procedures and the teams’ structure, companies can develop their own specific workflows inside the app, defining the required review phases and role-based approvals. Figure 3 shows a real example of one of these workflows:

Figure 3 – QMS Document Workflow with Comala Workflows and Publishing

Setting the document access permissions is critical to achieving compliance, as the hard deletion of documents has to be totally restricted, and the decommissioning of documents has to be handled as part of the document workflow.

In addition to those controls, audit trails must be associated with the Quality System documents to keep the archived documents’ records as long as needed. 

Benefits of Comala Workflows with SoftComply eQMS

Teams using digital Quality System documents work more efficiently when those documents are combined digital document control. To make those systems compliant with FDA and ISO 13485 requirements it is important to configure Comala Workflows and its publishing to Confluence properly.

Comala Workflows allows users to view the status of their Quality System documents and know what the next step in the document review process is (Fig. 4):

  

Figure 4 – Checking the status of the Quality Manual

Comala Workflows ensures that all approval steps are conducted in the predefined order verifying that the user has the necessary authority to perform key functions and supports role-based and electronically signed approvals.

Most importantly, all document revision history has to remain attached with the complete audit trail of each Quality System document as shown in Fig. 5 below:

Figure 5 – A full audit trail for each Quality System document, e.g. this Quality Manual

Comala Workflows consolidates document production with approval and signing audit trails. A time-stamped log of workflow operations is also maintained for each document.

Comala Workflows maintains visibility of the approved version of each document and can control which version of the document is available to each user, based on their role. In addition to that, another app, Comala Publishing, provides a solution to separate approved and draft content in distinct, separate spaces.

Automate the Risk Management Process

Some small medical device software teams use Excel to manage QMS, however it soon becomes clear that spreadsheets do not scale to large development projects; the potential for human-errors makes audits a nerve-racking process (read more about how Excel is not an ideal medical device risk management tool here).

Safety-critical systems are increasingly packed with software, and so software developers often prefer to work with open and integrated solutions where different aspects of system development are seamlessly linked to one another.

The main benefit of integrated solutions is the utilization of existing systems within the organization. Utilizing the existing systems will speed up the process of automation, and preparing for regulatory audits. Moreover, for distributed projects, risks need to be managed in a central system where all stakeholders can contribute to risk identification, evaluation and mitigation. Teams need a solution that is affordable and does not require the company to invest in a brand new set of tools.

SoftComply Risk Manager meets those needs precisely – it is built for Jira, and based on ISO 14971 and IEC 62304 requirements.

Benefits of SoftComply Risk Manager

An integrated risk management solution like SoftComply Risk Manager allows software developers using Jira to utilize their existing Atlassian tools, seamlessly linking software requirements and test cases to risks, as required for compliant risk management. Moreover, the developers existing familiarity with Jira mitigates the need for training, which accelerated the compliance process. The most important benefit of integrated targeted solutions is that the end user of the solution, the Regulatory Affairs Manager, gets exactly the right solution for their problem – there is no additional coding or complex configuration required. SoftComply Risk Manager meets the specific needs of regulated safety-critical system developers while being affordable and integrated to the rest of the development toolset.

Teams who have chosen to automate the risk management process with SoftComply Risk Manager have increased efficiency and reduced costs by a factor of ten, compared to using Excel. The software allows them to complete work ten times faster, while still adhering to regulations, thanks to its full integration with Jira.

One of the most noticeable benefits of using the SoftComply Risk Manager was the seamless traceability between risks, requirements and test cases, improving audit preparation (Fig. 6).

Figure 6 – automating the traceability between risks, requirements and test cases as one of the main benefits of using SoftComply Risk Manager

Summary

As medical devices become more dependent on software, and in some cases are entirely without hardware, the integration of regulatory compliance into the software development platform not only desirable, but mandatory.

Although there are numerous regulatory compliance software tools, most are conceived from the regulatory perspective, and are not preferred by software developers.

Atlassian tools are the preeminent integration between the rapid software development world, and the world of regulatory compliance. When combined with the apps available inside their Marketplace, it’s clear why there software is a popular choice for helping medical device companies stay compliant.

With more affordable regulatory compliance tools the completed devices get to market faster, and with better margins.

References

  1. https://www.atlassian.com/blog/add-ons/4-challenges-developing-safety-critical-software
  2. K. Trektere et al. 2016, Case Study: Becoming a Medical Device Software Supplier. In: IARIA Proceedings of the Second International Conference on Fundamentals and Advances in Software Systems Integration (FASSI 2016) on July 24 – 28, 2016 in Nice, France. Pp24-30.