Success Story
The Challenge
International Standards, such as ISO, IEEE and ASTM, play a crucial role in developing medical devices. Standards, particularly technical standards, establish a minimum performance level for medical devices by providing requirements and specifications for them to meet.
Most regulatory agencies require compliance to these standards or justification for why the standard has not been followed. To develop innovative MedTech products, businesses must understand the constraints set by the standards from the outset of product development. Failure to fully grasp the applicable standards may lead to the technical file submission being rejected by the regulatory agency. That costs time and money.
Full comprehension of standards relies on an essential decomposition of standards into a comprehensive set of design requirements, which in turn guide product development teams throughout the innovation process.
Standards can make up about 80% of the design requirements, while the remaining 20% is specific to the medical device that is being developed. Therefore, it is crucial that design requirements are written with a full appreciation of the standards from the outset.
In the case at hand, a client sought a clear, concise, and consistent set of overarching design requirements that the product development team could then utilise as the basis for all current and future development projects.
The client’s situation was for each product development team to look at the standards and decompose them using whatever approach the team felt was appropriate.
This wasn’t working for several reasons. First, having each team produce their own design requirements from the same standard was inefficient. There was a considerable waste of resources as each team started afresh by reviewing all the applicable standards and writing the design requirements.
And without a centralised source from which the established design requirements could be pulled, no one even knew if the work had already been done by another team.
Second, the inconsistency across the development projects led to issues with comparing design outputs and test results across projects. The organisation particularly struggled with the product development team’s ability to understand the appliable standards, how to interpret them, and inconsistencies with writing the design requirements.
The lack of consistency also had the potential to cause audit issues. If an auditor was reviewing related files of similar devices and found that the design requirements were not consistently and comprehensively addressed, the auditor could question the validity of the development process and the device design across the board.
Thirdly, by not having a standardised decomposition, crucial standards were missed in some developments, forcing device designs to be reworked.
Therefore, not only did the standards need to be correctly interpreted, but there was a need to establish a consistent process for writing the design requirements.
However, the interpretation process involved in decomposing the standards and turning them into design requirements is far from easy. It is time consuming and relies on a significant amount of retained experiential knowledge.
The Choice
Archetype founder Stuart Grant was selected to decompose the standards that specifically relate to hip design and development and turn them into a comprehensive set of design requirements because he had previously developed a process for decomposing standards into design requirements and was known for this work.
As part of a previous role within J&J as Design Control Lead, Stuart produced comprehensive work instructions for writing customer needs and design inputs; this included a process for writing design requirements.
Also, part of Stuart’s PhD research looks at how customer needs are specifically captured in writing (grammar, syntax) and how they flow through into design requirements, design outputs, and risk management processes within MedTech organisations.
The combination of in-depth knowledge of the theory and 20 years of experience writing design requirements for development projects helped Stuart quickly understand how the problem could be effectively solved.
Stuart understood the interaction between the products, standards, and stakeholders and had the communication and training ability to work with the business unit to help them understand the process and eventual outcome.
His experience also enabled him to work quickly, which was appreciated by the client. His speed meant the business unit could get back on track within a tight window and avoid slipping behind with getting products to market.
The client had an active project that needed the standards to be decomposed quickly into a set of design requirements for progress to be possible, so it became a working case study.
The Solution
Stuart wasted no time developing an algorithm to decompose each clause within a standard and turn it into a design requirement using a heuristic. The algorithm decomposed the clause into 7 areas:
1) Action: What the requirement was aiming to achieve.
2) Population/Context: In this case, the standard reference and clause number. But this could also be a user population for other types of design requirements.
3) Design Problem: This is the product being designed, for example, a ‘Hip Stem.’
4) Design Function: The specific function of the design problem, for example, hip anteversion angle.
5) Unit of Measure: An SI unit and increments, for example, x to x degrees, in x degree increments.
6) Direction of Improvement: How much it changes from the existing device, for example, better than, less than, or equivalent to.
7) Target Change of Outcome: This is the reference existing device.
These areas were then combined to create a design requirement statement. Once the design requirement had been created, it could then be directly transposed into the other design control document, such as the requirements trace matrix.
A key strategic decision that needed to be taken was the best way to capture and deliver the design requirements. Stuart evaluated various software solutions (Excel, FileMaker, MS Access). Together with the client, he decided to keep it simple and use Excel because it was useable and editable with software and skills that the team already possessed.
Other solutions would have required a degree of training and license access, adding complexity to something that called for simplicity.
Decomposing standards involves some tricky challenges. For example, standards do not use similar grammar throughout a document or even between related standards. For consistency, a set of grammar and syntax rules were established for writing design requirements, but in doing this, it was necessary to ensure that the intent of the standard’s clause was left unchanged.
For the active-project case study, Stuart worked with the Hip Replacement Family of Standards, including ISO16061, 21534, 21535, and the MDR GSPR requirements, and decomposed them into over 200 separate design requirements.
The algorithm also had the benefit of converting the design requirement into a design output. A design output is the corollary of a design requirement, and with some minor changes to the grammar and tense, the output is generated automatically. This had the advantage of allowing several design control documents to be pre-populated, saving significant resources.
Therefore, the process Stuart designed created three points of related data: design requirements, design outputs, and risk analysis statements. All of which served as evident triangulation of the device's safety and effectiveness.
That means the regulatory agency can efficiently review the requirements traceability matrix and the risk management file to determine that the design requirements have been met, verified, and validated and that risks have been identified and mitigated as far as possible. The easier the auditor’s job, the faster market approval can be granted.
The Impact
Establishing the design requirements process Stuart created has had several benefits for the client.First, the product development team now has a consistent set of design requirements that they can utilise to ensure the product they are developing is meeting all the technical requirements in the standards.
Second, the development process has been made more efficient as the teams do not need to spend time and resources mining the standards themselves for design requirements.
Third, the regulatory agency can efficiently review the technical file to determine that the design requirements have been met, verified, and validated and that risks have been identified and mitigated as far as possible. All of which equate to faster market approval.