In certain parts of the world there are med tech graveyards. Places where secondhand or donated Western medical equipment are dumped, because they simply can’t operate in the conditions in which they are now expected to be used.
They may have proved unequal to the heat, humidity or sporadic power supply that can affect particular regions. And this is a problem. Medical devices that can cease working unexpectedly or in the environments where they are most needed, can clearly represent a serious threat to human life.
These tech graveyards illustrate in the starkest possible way how a device that is not designed with the conditions of its end use specifically in mind can lead to its total failure in the field.
European and American med tech graveyards maybe more metaphorical locations, but they are no less real for that. It’s here where brilliant product ideas are languishing unused; products that were launched but found themselves unequal to the real world challenges they encountered. Products which were imperfectly realised against their requirements; or those that were found to be useless or dangerous to consumers because critical user requirements were never gathered in the first place.
And it’s this understanding that in recent years has bought a new regulatory focus on the way design and validation processes can prevent such wasteful and expensive outcomes for developers and their customers.
So you want to be a successful medical device developer?
Even as far back as 2011 the FDA recognised that more than half of all medical device recalls in the US could be traced back to a failure in the design or manufacturing process that governed the creation of a device, rather than a basic failure of concept or an engineering blue-print.
Indeed, the FDA report ‘Understanding Barriers to Medical Device Quality’ identified that many developers were facing:
“significant difficulties in designing medical products for actual, and not merely intended, use. Firms struggled with designing and validating devices for the diversity of applications and environments in the field.”
In fact, many med tech consultants still tell us, if a medical device fails, that failure can usually be accounted for by an omission or mistake within the user requirements. This could include the way they were gathered, written up or integrated into the design process.
All this is why user requirements now form such a pivotal part of the design controls outlined in ISO 13485, and why the body has mandated that ‘design inputs’ be used to verify designs at key stages before a build commences, and the functioning of the device itself be validated against ‘user needs’, once it has been built.
It should be noted that this kind of approach has become part of the legal requirements for device development in many regulatory environments. For example the FDA 21 CFR Part 820 requires your Quality Processes establish “by objective evidence that device specifications conform with user needs and intended use(s).”
Adopting user centred design (UCD) principles and techniques is one way in which medical device developers can keep the needs of users at top of mind as they work. At the same time, this approach can throw up the potential for a sprawling, unmanageable and seemingly unending process of design iteration, change, overhaul and tweaks, which can never reach a conclusion.
UCD seeks to keep developers focused on the absolute primacy of the end user and their needs when developing solutions for them. Everything else is subservient to this activity. Design decisions should not be driven primarily by business or commercial concerns, neither should a desire to include a particular technology within a solution. Instead, a design and development process should be focused on how best to solve a clearly identified and unmet consumer need.
UCD techniques might include:
UCD is a good fit for med tech development, but, at the same time a medical device developer requires the tools to ensure that all the customer needs you are identifying, plus all the testing data you are accumulating are being properly captured in your documentation.
You need a way to instil discipline and structure into what could be a loose and agile process.
And developers don’t just need to do this for their own purposes. As mentioned above, they also need to use these techniques in a way that can prove to regulators that they have done so, or they will never have their product licensed or approved.
The right digital Quality Management System (QMS) can be part of the tool kit that helps you deliver this. Used in conjunction with a Project Management approach like Prince2, you can impose a structure of ‘plan, do, check, act’ at every stage of the design and build process of a medical device, that is backed up by a fully auditable trail of documentation.
This kind of tool can help you share plans with selected stakeholders, making available the documentation your teams need to achieve their goals, and then impose requirements to review and approve outputs before the next stage of a project can be triggered.
In the first place a QMS can help you formally gather ‘user need’ documents and data together, sharing them with stakeholders for comment and feedback, then managing the iterative creation of the User Requirement Specification (URS) document that will become a primary design input for your final product.
Then as the process continues, digital ‘phase gating’ tools should allow you to impose and manage ‘stage boundaries’, that can define and contain a potentially sprawling project into manageable units of development, testing and approval.
Among the many stage boundaries to be cleared in a dev process, the most critical will be the mandatory process of design verification and validation that must take place before a product can be built or released for regulatory approval.
If the user needs have been successfully turned into a specific and measurable set of USRs (with feedback and approvals from all relevant stakeholders gathered in the process) and then turned into a set of measurable design requirements, then this should be a more manageable process.
With a digital QMS in operation it should be more straightforward to assess and approve exactly how unmet user needs have been met by the design process, while also demonstrating how the clinical proof and risk management requirements of the design process have created a demonstrably safe and usable end product.
A properly managed digital QMS will also prove invaluable when assessing the usability of the end device, helping you create a systematic and auditable regime of testing and approval by all relevant parties.
As the design validation process centres on the way the product meets unmet needs safely and efficiently, so the User Centred Design approach should have left a paper trail of evidence to show how these were factored into its design and realisation.
The questions for validation might include:
Supporting a compliant User Centred Design approach, as well as the design verification and device validation process required by med tech regulators is a complex business.
However, adopting a digital QMS can help fulfill all this in highly flexible but systematic way that will help reduce the risk of making errors.
It should help you ensure that no essential requirement for the proper functioning of the end product is missed at any stage of the design and realisation process.
In the medical device graveyard there may be many epitaphs, but those of the mismanaged design process carries the most dire warning of all for a medical device developer,
“If you think good design is expensive, you should look at the cost of bad design.”
Faced with the prospect of commercial failure or the injury of a user through misuse or failure, med tech developers should consider how best they can understand and meet the critical unmet needs of the consumers they seek to serve.