This article is the second 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 use to define a structured way for developing high-quality software for healthcare. The purpose is of this series is not to act as a guide, but rather to give inspiration to others embarking on the same journey.

Part II: Your design is never secure

In Part I, I discussed the basics of a quality management system (QMS) which is required in order to be coherent with the ISO-62304 standard. However, design documents, templates, work instructions, and standard operating procedures, are only a small part of the whole medical device software concept.

I now switch focus to the more interesting parts of this series, i.e. the activities which relate more to the day-to-day work.

Although it can be fairly simple to define a basic QMS, a QMS does not automatically yield high quality software.

It takes time to change behavior and work ethics, and it’s also highly affected by the size of the organization in question and the level of dedication from both employees and the QA department.
Here at MEDEI, we have only a handful of employees within our design and development team. Despite the limited size, I can’t say that it has been simple to implement the standards.
That being said, it all comes down to how you structure it, especially your implementation plan and QMS training. If there’s one thing I have learned throughout all of this, is that a QMS is never complete – a QMS requires continuous care and revision.

Spotless design

It can be fairly easy to be ignorant of our own faults – but ignorance can be catastrophic. In the field of healthcare, ignorance can injure, or even prove lethal.

When designing a solution, risk analysis should always be performed continuously throughout the whole software lifecycle. This is not only to identify hazardous scenarios during design and development, but also to highlight possible threats which can occur during production or when using the medical device software.
However, and I think that many experts will agree with me on this, it is almost impossible to identify all possible hazardous scenarios beforehand. Meaning, that when designing a solution, it is theoretically impossible to take care of all possible hazardous scenarios – no matter how sophisticated the design is.

The truth is that technology is constantly evolving and when a particular software is designed, risk analysis is only performed with the current knowns in mind at that point in time. In other words, as soon as you release a solution, and with every day that passes from its release, a gap is being built between your risk analysis and today’s technology.

Let’s take an example.

A medical device software is released as a software as a service platform and runs on a specific web domain via HTTPS. Two months later, a bug is found within a specific versions of SSL certificates (which are used for HTTPS connections) and apparently, the software is using the same type of flawed certificate for its platform. 
The organisation responsible for servicing and hosting the solution, are not aware of this, and a few months later, a hacker gains access to their solution utilizing that particular flaw and is able to gather massive amounts of data from within the system, which could be utilized to potentially destroy it or cause serious harm to its users.

We’ve already seen examples of this with cases like the heartbleed bug, where solutions relying on a particular SSL library were suddenly open to attacks. 
What’s important to take from this, is that no matter how sophisticated your risk analysis is, you will have to continuously be aware of possible new hazardous scenarios, and be agile enough to assess them as they come.

Designing with the right mindset

One of the major changes in the new medical device standards, is the shift of focus to a more risk driven QMS and risk based design. 
This means that risk analysis shall not only be focused on the solution itself, but also the tools and methods used, and standard activities performed during design and development. 
At MEDEI we rely on between 5 to 10 different software tools for all our design and development activities, for example:

Enterprise Architect
A sophisticated engineering tool we use to design and track every aspect of a system. Within Enterprise Architect, we document everything from a customer requirement to test specifications.

JIRA is a highly customizable task tracking tool, which we use to plan development activities and development tasks, along with keeping track of change requests, bugs, new features, and a backlog.

Sometimes called the sister tool of JIRA, and is used to keep track of documentation, either related to development or support. We mainly use it as a common place to share our QMS files, and design documentation. We have also used it for wireframes and to share guides on how to setup tools or 3rdparty software used while developing or testing.

Git is a type of software version control system which we use for keeping track of all the source code written. It’s one of the more common version controlling systems being used in software development today.

We use SourceTree to streamline our activities with Git. Git can and is often used via terminals/command line interfaces, which can be difficult to control – especially if you have specific work instructions on how version control should function. Therefore, we use SourceTree to standardize our working methods with Git.

These are only a few of the tools we use on a daily basis, and each one serves an important role in our software lifecycle.
One could say that with each tool we use, we are opening up for new potential risks with every solution we design and develop. However, with the right mind-set, and correct choice of tools together with an agile QMS – which includes clear work instructions and standard operating procedures, you can greatly minimize that risk.
With that said, we continuously have to validate our methods and tools in every aspect of our organisation.

  • Is our task management system backed up?
  • Is our system design safe from an outside breach, or could someone potentially acquire our design and use it against us later?
  • If someone gained access to one of our e-mail accounts, could they access sensitive security information, such as server- or database keys?

These are only a part the questions we continuously have to revise.

Unfortunately, we have had to learn it the hard way. As only a few months ago, we found out that backups weren’t being made on one of the databases we use to keep track of our designs (which was not that convenient). But luckily the damage was almost insignificant in that particular case, compared to what could have happened, and we managed and implemented a solution to the problem.

Security and risk are never static, and this is important to remember, because neither is software design. To be agile, and ready to take on changes, and continuously improving your methods and activities is crucial. This will not only benefit your organisation as a whole, but also its end-users – and thereby possibly saving lives as well.