This article is the first in a three-part series, where I reflect on the challenges we experienced in MEDEI while implementing the medical device software life cycle standard into our agile software development.
In this series, I describe my experience with implementing the required procedures for ISO-62304, and which tools and methods I used to define a structured way for developing high-quality software for healthcare. The purpose of this series is not to act as a guide, but rather to give inspiration to others embarking on a similar journey. 

Part I: Ensuring quality – the great dam of documentation

Since MEDEI was founded in early 2013, I have realized that the quality standards in software architecture highly vary between organizations. The variance is not only specific to methodologies or documentation standards, but also how design is conveyed to artefacts and communicated to product owners.

Healthcare is an ever-growing consumer market, where both start-ups and enterprises are recognizing that information technology and software development have become one of its essential cornerstones.

Due to this fact, software solutions are being produced at a high speed to minimize overall go-to-market time. Additionally, new players from other fields of IT, and even hardware manufacturers, have started developing their own software solutions to be used in a healthcare applicable context.

However, as more actors focus on developing software solutions for healthcare, noncompliant software solutions can or will reach the market, i.e. solutions that are not following quality or regulatory requirements for medical device software. We have seen examples of this where the FDA, and other regulatory organizations, have banned the marketing of a number of applications from both, Apple and Google app stores.

Ensuring quality

The core values at MEDEI have always been quality and to produce high-quality software using state of the art methods and technology.
But what is quality and how do you measure it? Is it possible to distinguish yourself from other competitors using high-quality slogans alone?

In my opinion, in order to achieve high quality, you do not only require structure and planning, but a coherent design and development strategy as well.

Within healthcare software development, for the most part, there have already been defined a set of standards which describe the basic principles required when developing healthcare software, which should ensure robust solutions. However, ISO standards have never been known for describing exactly “how” one should achieve compliance with them, but rather only explaining procedures which ought to be followed.

For many, the ISO standards can often come as a shock. Luckily, for us at MEDEI, many of the core procedures required by ISO 62304 have always been a part of our standard design and development procedures.
However, in order to ease our process with implementing the required procedures and documents, we got our good friend Hugo Bertelsen, from MedicQA ( in Aalborg, to give us guidance. 

The first step

The first, and probably the most important thing to ensure, is to organize all the required documents and procedures. The importance of standardizing documents, design methods, work procedures, and even code styles cannot be stressed enough. The core document behind of all this is dubbed “Control of Documents”, and is usually a part of your standard operating procedures, or SOP. A QMS is usually divided up into different categories, where SOP is one of the main ones. An example of QMS categories:

  • QF – Quality Files
  • QM – Quality Manual
  • SOP – Standard Operating Procedures
  • WI – Work instructions

At MEDEI we have managed to define a set of documents which cover everything from file naming conventions, to coding guidelines – which describe how “if” sentences shall look in a source code.

Nonetheless, the documents required within each category of a QMS highly vary between organisations. For example, we have a set of documents within our SOP which describe how we capture design inputs for a product and convey them to software development tasks. Additionally, for work instructions we have a set of documents which describe how developers should proceed with software version control, and development task management (more on that in part 2).

Other software companies might have different work instructions or SOP, all dependent upon your choice of methods.
The most important thing to note is that there’s no golden rule for how a QMS should look or function.

A QMS is simply a way of placing known methods into a structured system, to ensure that everyone within your organization is aware of how things should be done.

As soon as we realised this, the whole concept about a QMS and the ISO62304 standard became a lot clearer.

I cannot stress enough, how important it is to have a set of instructions on how to handle documentation, software code, or development tasks. As soon as I had a set of documents which everybody had to follow, my time spent on teaching new developers, or reviewing work for quality assurance, was minimal and gave me time to focus on other important tasks – without compromising on quality.

Improvement is the key to success

Currently, our biggest problem is the enormous amount of work involved in keeping version tracking of all our documents, both within the QMS, and project specific documents. Our QMS has standard templates, defined as quality files, for how to document use cases, engineering requirements, architecture design, test specifications and more. When working on a project, these documents can quickly change from one version to another, and because our current QMS is implemented in a set of Word documents, we can spend a quite a lot of time just ensuring that the documents are fulfilling our Control of Documents standard. 

Many organizations are still running their QMS on paper-based documents, and some have moved to a part-digital solution. Our current QMS cannot be categorized as a complete digital solution, as we have to print and sign all of our documents before we scan them and store them in a digital format.
The problem is not that documents can easily be created and kept in digital format alone, but without any signatures, they cannot be validated. This is the main reason why our documents have to be printed out. 

Clearly, for the sake of the environment and time, the next step for me is to move our whole QMS into a complete digitalised format which allows us not only to keep track of new and old documents and their changes, but to digitally sign them as well.

Currently we are using both JIRA and Confluence to keep track of development tasks, and our engineering design documents. We have customized a lot in both systems to be coherent with our procedures and standards, and it gets even better as we continue to use them.

Going forward, the most realistic path, would probably be to implement our QMS into Confluence as well, and with time we probably will. But for now, we continue to focus on gaining experience with our QMS in order to build a better digital system, while also improving our software architecture design standards.

Rome wasn’t built in one day, and neither is a quality management system.

Be sure to check in on part two, where I will cover our journey into risk based software design and development, and the tools we use.