Navigating Med Tech: Starting with Product Development or Documentation?

What should come first in a med tech project? Product development or documentation? 

If you’ve got a great idea, there’s always the temptation to get on with ideating and prototyping rather than paying attention to the paperwork. But is that really the right thing to do?

The view from the podcast

Our friends at the excellent Medical Device Made Easy Podcast recently raised this very question and it made us think about how we would answer it.  

In this edition of Monir El Azzouzi’s weekly podcast, Monir and medical device QMS expert Stefan Bolleininger discussed the role documentation needs to play in the early development of a medical device.

For those with an existing med-tech product portfolio, they argue, starting with the documentation is absolutely imperative. 

If you want to expand a product line or introduce a new feature, says Bolleininger, then you should definitely start with the documentation first.

The documentation ‘gives you strategy’ adds Monir, and Bolleininger echoes that with this thought:

“If you want to build a house, you need to make a plan first, because if you don’t. it’s not sustainable.  And we want to build safe and sustainable products.”

The right documentation describes the way forward for your project, defining what needs to be done, how the work should be executed to comply with regulations and, critically, what ‘done’ will look like.  

The documentation requirements of ISO 13485

Later, the pair spoke about ISO 13485 and its demands for the design phase of a product to be properly documented. Could this kind of design documentation be put together retrospectively?

ISO 9001:2015 - How to apply Risk-based Thinking to Quality Processes [Part I]

“It can”, says Stefan, “but, then, it will only be on paper”

The point of the documentation process, he reminds us, is not only to prove your product has been developed in a compliant way, but to make that process easier, more efficient, less prone to waste, error and, therefore, commercial failure. 

Documentation, verification and validation 

Having the proper documentation in place from the beginning of a project will also allow the required verification and validation processes to happen more easily at the end of a development phase.  It will enable you to systematically look back at user needs (as documented at the start of a process) and compare them to the physical product in front of you at the end - thus identifying any serious gaps or omissions.

New features, new claims - new clinical tests?

The podcasters also note, that if you’re adding a new feature that will extend the range of conditions the product can treat, then writing down those objectives  is hugely important from a commercial point of view. In the end it might mean adding a new claim to your product literature and that may necessitate running new clinical trials to support this.

Documenting expected processes, requirements and designs first -  then recording each step you take against your plans, is clearly the most logical way to go about what needs to be a highly accountable process.  And as Stefan reminds us, if you don’t do these things, there is a very good chance:  

“You will fail with the production validation or fail in the market”

For all these reasons documentation should precede development efforts and, clearly, using a proprietary digital Document Management System to record, organise, store and audit them will make it easier for you to get to market with your new offering.

But what about those starting out in med tech development for the first time?

But then, there’s the startups and smaller businesses, those without an existing product, but with the inspiration for one, or the technology that could be applied to build one.

Stefan argues that if you’re a start-up and you’ve got an innovative idea for a product, then you need to focus on the product first over documentation.  Even to the point of prototyping elements ready to demo for potential investors

"Create just a few snippets of product… enough to convince your investors”

All this, he says, should be done before you start worrying about putting together the documentation and building out a DMS  that will be the basis of your quality management approach.

When a DMS is over-kill

This view is understandable.  Looking at the variety of document management system options available to medical device developers, it’s no wonder that startups often shy away from a more formal DMS solution until they absolutely have to commit.  

Faced with a choice between adopting Google Docs to store and index their initial requirements gathering, and paying out for a heavyweight eQMS that would take weeks to install and then wrap them up in red tape, then the Google Docs route is pretty much a no-brainer.

Why not just use Google Drive as a Document Management System?

What does a medical device start up really need?

If you are a lean and nimble start-up with a great med tech idea then it really won’t be long before you start butting up against the realities of the sector’s demanding regulations and the lack of a systematic document management approach will begin to show.   

Of course, if your initial work is just validating some basic and fundamental ideas about the medical application or feasibility of a particular product, it might be worth holding back on producing documentation.

But if you’ve got to the point where you are working full time on your idea, and if you’ve assembled a team to do so, you should definitely be working on the documentation as part of your process and looking to organise it in a way that will help you further down the road with the manufacture and licensing.

Should you bother with a DMS?

The truth is,  the consultants we work with regularly tell us about medical device start ups who throw themselves into the process of building a prototype ready to take to investors, but who are then on the back foot because they can’t show them the steps they’ve taken to get there.

In an increasingly squeezed and competitive device market, with long lead times and waits for certification, the way you approach the initial ideation and design process itself can make the difference between an investor feeling able to take the risk of working with you or not.  

Depending on how far down the development process you’ve gone it may take too long, or be otherwise impossible, for you to ‘back solve’ these documentation requirements and still remain on a viable path to market..

And, indeed, in the Medical Device Made Easy Podcast, both Stefan and Monir, both raise this point.

Book a free demo of the Cognidox Document Management System

A DMS for every med device developer?

However, Stefan also makes an important general point here about your approach to documentation.  

“It doesn’t need to be ‘perfect’ at first, but it needs to show the R and D team the way you want to go”

It’s a reminder that at the very beginning of your project, your documents might not need to be exhaustive or contain every single detail of what you will need to achieve, but there is still a need for them to be recorded, retained and indexed in a systematic way if you’re going to be able to ramp up your compliance efforts later on.

Given all this, there is clearly a need for a Document Management System that is cost-effective for smaller businesses - easy to set up, but robust and sophisticated enough to scale with you as your idea for a medical device starts to take shape and then becomes a reality.   

So, what should come first?

We would argue that it is important for every medical device developer to start thinking about their document management needs as early on as possible in their work.  And there are alternatives to the monolothic eQMS systems that dominate med tech, or the improvised Dropbox/Google Doc solutions that proliferate among start-ups. These solutions can be more suitable for dynamic and agile organizations than the former, and more equal to the rigours of the regulated environment than the latter.