Table of contents
How important is it to define the right design levels for your medical device requirements?
The development of a medical device is a complex process, spanning from the initial idea to a market-ready product, and is fraught with numerous challenges. A key aspect that is often underestimated is the proper alignment of requirements with the various design levels. Here, we refer to the “right altitude” for your requirements. Choosing the wrong altitude can lead to significant problems in the design process, negatively affecting efficiency and ultimately compromising the safety and effectiveness of your product.
In a structured design process, the product is viewed from different perspectives, or “altitudes”. The concept presented here is divided into three typical main levels:
- Stakeholder Level (L1): At this level, the focus is on stakeholders, i.e. relevant individuals or groups interested in the product. Their perspective concerns the desired properties and functions the product should fulfill. The focus here is on the “what” and the “why”, meaning the specific problems to be solved and needs to be addressed. Technical details are of secondary importance at this stage. The product is discussed only in terms of what it is supposed to do, not how it will be technically implemented.
- System Level (L2): At this level, system architects translate the stakeholder requirements into system architecture by considering technological concepts and organizing them into functional assemblies. The focus shifts to the fundamental “how” – the basic technological principle by which stakeholder requirements will be fulfilled – and the integration of system components into assemblies. Here is where technology fundamentals are established without getting into detailed component specifications.
- Output Level (L3): This is where the concrete technical implementation of the system concepts occurs, carried out by designers and engineers. Individual modules and components are specified in detail. This includes, for example, circuit diagrams, construction drawings, and parts lists. The focus lies on the detailed technical implementation and the manufacturing specifications – the “blueprint” for the final product.
For complex products, additional intermediate levels are often introduced between the presented levels (L2 and L3) to provide a more fine-grained structure.
A precise definition of the “right altitude” for requirements is crucial for a smooth and efficient development process. With a correctly chosen altitude, it is ensured that:
- the stakeholder needs (L1 requirements) are systematically and correctly captured.
- the system architecture translates the requirements into a system that optimally supports the intended product functionality.
- the design output precisely implements the system requirements
- the dependencies between all design levels are understood and managed, allowing for consistent traceability.
- changes and their impacts can be analyzed and managed appropriately.
- requirements are adequately validated through testing.
Typical Mistakes and Their Impacts
An incorrect “altitude” in requirements can lead to the following problems:
- Overly specific Requirements at the Stakeholder Level (L1): When stakeholders specify detailed technical solutions or precise components, it can restrict the creative freedom of designers and potentially lead to suboptimal or less future-proof solutions. Additionally, there is a risk that technical assumptions made at this stage later prove to be unsuitable. Since the technological interests of stakeholders must be taken into account, they should indeed be captured – but primarily formulated as non-functional requirements (e.g., boundary conditions) rather than technical specifications.
- Overly specific Requirements at subordinate Design Stages: Such requirements can cause problems in change management. For example, components may need to be optimized during their life cycle, or technologies may evolve. If technical information is already referenced unnecessarily in higher design levels, this level needs to be included in the change process when design changes are made. This increases the workload as interfaces between design levels may need to be managed and maintained, or levels may need to be included in the verification or validation of changes where this is not necessary. For example, replacing a technical component at (L3) with a component with a comparable specification would have no impact on the technology or the requirements of the stakeholders. The situation would be different if the component was already in specification at (L1) or (L2).
- Overly abstract Requirements at the Detailed Design Level (L3): Vague or unclear requirements at this level create room for interpretation during technical implementation, which can lead to errors, incompatibilities, and difficulties during verification. Requirements at L3 must be precise, measurable, and detailed in order to form a clear basis for construction and manufacturing. Simply replacing a supplier’s data sheet with a specification is not a solution if component substitution would not meet critical specifications, or if adherence to exact specifications is essential, and deviations would result in procurement issues or higher costs. This leads to complications when parts are sourced that do not fulfill their intended purpose because they were not adequately specified.
- Mixing Design Level in Requirements: When a requirement contains details from different design levels, it can cause confusion, misunderstandings, and unnecessary coordination efforts. It results in more or less redundant requirements, makes traceability of existing dependencies and impact analysis of changes more difficult. A clear indication of the applicable design level helps avoid such mixing, ensuring, for example, that identical tests at different levels are not unnecessarily repeated or that tests can be clearly assigned to the correct design level. Every requirement should be explicitly attributed to a specific design level.
To ensure the “right altitude” for your requirements, consider the following points:
- Stakeholder Level (L1): Focus on the needs, goals, and usage context of the stakeholders. Describe the core tasks that must be fulfilled to achieve the intended purpose. Formulate general and long-term valid requirements that provide system architects with sufficient options for solution design. Avoid naming specific technical preferences.
- System Level (L2): The description of the system’s functional modules and their interactions should concentrate on the technical fundamentals (e.g. provision of thermal energy, determination of a state variable). The interfaces are specified in terms of the type, quantity and quality of the substances, energies or information to be exchanged, without already specifying concrete technical solutions (e.g. protected transfer of information X from module A to module B at the request of module B). Use logical groupings in your design that can also be applied to product platform strategies or supply and production planning.
- Detailed Design Level (L3): Specify individual components and their parameters precisely. Provide tolerances for manufacturing and material properties, and indicate alternative requirements if necessary. External components should not merely replicate supplier data sheets; instead, they should meet the required specifications and satisfy their intended functions.
- Clear Separation of Design and Requirements: The design specification must be clearly distinguishable from the development task. In addition to technical requirements, the development task may contain specific implementation instructions for all design phases. The design specification should take this into account, but be strictly design phase oriented. The same applies, for example, to agile projects. The user tasks in the sprint in Scrum, are tasks that also include feasibility analyses and mock-ups and therefore cannot be equated with the design output.
- Consistent Structures: Use attributes for your requirements to clearly define context (e.g., stakeholder, system module) and type of requirement (functional, non-functional, interface requirement, or usability requirement). This enables consistent classification and assignment to the appropriate design levels. Use templates to formulate requirements, ensuring conditions, functions, or scopes are clearly specified. This creates a consistent design approach within the development team.
- Traceability: In addition to vertical traceability to risks and tests, consistent horizontal traceability must be implemented between the requirements of the various design levels. This verifies that all stakeholder requirements are correctly transferred and verified in the product design. Traceability also helps you to formally check your information for consistency. This allows to ensure that a requirement classified as “source of risk” has actually been assigned to a risk, or that a test case of type “effectiveness” has actually been assigned to a mitigation measure.
- Reviews: Perform regular design reviews to check the adequacy of the “flight level” of the requirements at each level and identify inconsistencies at an early stage.
Conclusion
The correct mapping of requirements to design levels is a fundamental building block for successful and efficient medical device development. Ensure an appropriate level of detail and abstraction at each level. This will help you avoid many potential errors, improve design quality, and meet important regulatory requirements. By choosing the “right altitude,” you lay the foundation for a safe and efficient medical device.
