A golden rule in life sciences: you can’t mention medical software without summoning a list of regulations, standards and protocols. One of them: the international standard IEC 62304 for Medical Device Software. Meeting these requirements often happens in a rigid and stiff way, but believe us when we say there’s a flexible and agile way to tackle this standard. We did it for Barco, we’re doing it for Antelope Dx and we plan on doing it a lot more. 

Let us take you through how we organise ourselves to remain flexible while also guaranteeing IEC 62304 compliance by implementing the right tools and strategies from start to finish.

No IEC 62304, no product

First things first. To guarantee safety, bringing a medical device to the market means you need approval from medical authorities like the FDA or EMA. In a nutshell, the IEC 62304 is an international standard that specifies the requirements for medical software. 

This standard has been harmonized between the EU and US, and often forms a prerequisite for entering these markets. Depending on the safety class of your medical product, no IEC 62304 approved software means no market access or ability to even launch your digital solution.

V-model vs. agile

Now that we know that IEC 62304 compliance is essential, we can look at how we tackle things at In The Pocket. First off, complying with IEC 62304 requires documentation and validation of a whole range of activities. The danger of the V-model approach lurks in the fact that the series of requirements will only be tested and validated at the end of a lengthy process. Something doesn’t check out? Bad news, because that means operational inefficiencies and slipping timelines.

Inspired by the agile manifesto, we prefer to pick working software over comprehensive documentation. We like to cut the big process down into smaller pieces. By documenting, testing and verifying each step in consequent sprints, we avoid the risk of having to overturn the building blocks at the end of the ride and start over.

Putting theory into practice

So how exactly do we organise ourselves around IEC 62304? Instead of validating after working 6 to 12 months on the medical software, we’re going to break things down into functional Epics, and add incremental value in a certain sprint rhythm.

Every sprint, the team works towards a single component or feature of the medical software while also making sure it complies with IEC 62304. Depending on the client or product, compliance happens via a custom-made toolbox that enables the team to continuously validate, verify and test. 

A team lead oversees the whole process and constantly aligns with the client's product manager, so everyone stays on the right path, and every piece of the puzzle fits the bigger picture.

Product Discovery & Development‍

Together with the client, we create a well-defined vision of the product’s components and requirements. Still, nothing is set in stone. Development and discovery go hand in hand, as we can come up with new and better insights in favour of how this specific piece of medical software should be developed. 

The agile way of working gives us room to collaborate with clients and respond to change, leading to a better overall product. Tackling the IEC 62304 compliance, we make sure each small piece of software we’re working on is traceable, well-documented, tested, and validated.  

Looking from the client’s perspective, we guarantee that the transfer of our documentation is in line with the client’s needs. This way, they can effortlessly integrate our documentation in their bigger file meant for FDA and EMA approval.

Risk management‍

Apart from the biweekly sprints, we organize recurring steering committee meetings once a month together with the client’s key stakeholders. We look from a distance to what we did in the last period, what we plan to do in the next sprints and discuss all challenges and risks we have identified.  

Through workshops, we zoom in on the possible risks of our software and look for solutions to eliminate risks as early as possible. We, as a partner, will track our risks, but we need the interaction and integration in the overarching risk management of our client to make sure everything stays in sync and IEC 62304 certified.

Architecture and code‍

Diving a little deeper into the technicalities, IEC 62304 also requires validation, verification and documentation on the technical level. Every digital product or client is different, but in general you could say that we work by the four-eyes principle. 

Every line of code is checked through Gitlab Merge Request, which requires two reviews, and on an architectural level, everything gets checked by at least two pairs of eyes. Nothing gets passed if it hasn’t been checked and double-checked by both our engineers, architects and the client.

‍

It’s impossible to fully explain the ins and outs of our agile approach on dealing with IEC 62304 in one post. The main point here is that there is a flexible and iterative way to do it. And we have our happy clients at Barco Demetra & Antelope Dx to vouch for it. In need of more information? Or medical software in the pipeline? Just reach out. We don’t bite.