cGMP – Design Inputs (URS-FRS-MRS-ERS) – ISO 13485:2016 (7) Clause 7

We expect that the Design & Development Plan be a written and reviewed document. Similarly, the Design Inputs also needs to be a controlled document. In practice, the design input document is created alongside the DDP simultaneously. However, before we start to analyze the design input, we should take a look at User Requirement Specifications (URS) or Customer Related Processes (see ISO 13485:2016 Chapter 7.2).

The focus of the URS should be on the customer experience. In other words, it should be a list of what the user desires rather than a list of requirements. Also, the list should not have solutions alongside it unless the solution satisfies the requirement of what the user wants to achieve using the product. Likewise, the URS should also include answers on what the customer experiences. In the medical device industry, the demands of the users should be considered from two perspectives namely;

1.     As a patient.
2.     As the device operator.

The moment the needs of the user is identified, the device designers have to translate those needs into the design input forms. Although the job is primarily that of the device engineer, inputs from crucial personnel in production, marketing, service, and others should be added as needed. Design engineers should strive to eliminate ambiguity in the design input process to reduce the level if inaccurate assumption. One of the effective ways to avoid false assumptions is to exclude design solutions from the design inputs unless the solution is part of the design. For example, let say a user requirement is; the device must have a foot switch to trigger operation. A suitable alternative would be not to specify a foot switch, rather have the requirement stipulate the need for a hand free operation for the device.

Design Input Categories

Using the User Requirement Specification, one can easily generate several input requirements documents. Input Requirements often fall into three categories namely;

• The Functional Requirements (FRS): This requirement specifies the capabilities of the devices, its operations as well as its input and output characteristics.
• Performance Requirement (PR): It covers the device behavior during use, and some of the behaviors can include; precision, ranges of quantitation accuracy, operational environmental ranges, and other performances.
• Interface Requirement (IR): All interface requirements should be specified. Interface requirements can be either external or internal. However, all specifics relating to the interface should be listed.  External interfaces can be in the form of patient/product interface, external communication interface, and operation/product interface. Meanwhile, the internal interface can be software/hardware and communication interface. Each interface requires a review to ensure that the system works well together.

The documentation for each requirement often depends on the product and the organization. Although, almost all organization have functional requirement documentation or documentation that directly addresses design input requirements (DIR). Sometimes there are separate documents to capture specific requirements of the document such as a Mechanical Requirement Specification (MRS). Another example is the Electrical Requirement Specification (ERS) that are created within the sections or either the DIR or FRS documentation, Orcanos ALM system support over 58 different types of requirements and can be expended to more as needed.

Other requirements that deserve consideration are safety and regulatory requirement. We mustn’t forget the requirements for applicable risk management inputs.

Adequate Time

There should always be enough time to allow for the development of the Design Input Requirement (DIR). Each requirement should be ;

•        Unambiguous
•        Quantitative
•        Contain expected tolerance.

The environmental conditions for optimal performance of the medical device and environmental specification for storage of the device should be stated. As much as is possible, organizations should try to capitalize on the standards set by the industry for each product. Nevertheless, the standards should be reviewed to ensure they cover and satisfy the design input requirements. A popular example is the referencing of ASTM D40169 for performance testing of shipping containers and systems as it relates to verifying the method of testing and packaging conditions. The standard sometimes might not cover the acceptance criteria like in this instance, and if such provision is left out of the DIR, the design input requirement will be incomplete.

It is expected that over the corse of product development, the design input requirement will change. For this reason, the change control will play a vital role in ensuring that the changes are reviewed based on their impact on other design input requirements, Orcanos traceability tools also includes integrated suspicious indication feature which proactively alerts on such possible impact. It is not unusual that a change in one requirement would affect another design input requirement. For more information see related links