Tip Of The Week – How to Build Your Design Inputs/Outputs in QPack According to ISO 13485

Rami.Azulay November 7th, 2015 Posted by Rami Azulay( ) ALM 2.0, KPI, Tip Of The Week

October 25th 2015 335d499  Rami Azulay in Tip of the Week, QPack


Start Your Free Trial Now


 

Post Overview

If you are a medical device vendor, then you are probably aware of how the ISO 13485 methods of design and development. In the design phase, we draw on  all our market and product requirements, which are  used in designing. This data also informs  the project plan. Later comes the specifications, which are also determined by the  design inputs, which could be Software/Hardware/Mechanical requirements and their coupling detail design.

How Do I Create Design Inputs In QPack?

In QPack there are 36 work items that have different processes and procedures. Two of them belong to the design input phase. One is the Business Requirement work item. This work item is used to describe the business goals of the product. It is not yet a mandatory document for all medical device vendors, but if your medical device is software (Ex. Mobile Phone App.) only then you must start with that document. Yet best practice demonstrates that most successful projects start with thinking about market needs, and then goes downstream to defining the product.

2015-10-31_14-29-56

 

 

This is  a recommended template, which may be used to increase user productivity and focus on market goals, rather than features:

 

Field Description
MR Identifier QPack ID
MR Name Item Name
Directive

<Provide the instruction that guides and directs functionality being sought by the user.  Each directive addresses a facet of the market problem.  The directive format is:

“User [persona] <shall/should[(high/medium/low)]> be able to <functionality>.”>

<Comment: The special conventions used in the directive are:

  • Square brackets “[ ]” denote optional arguments
  • Pointed brackets “<>” denote mandatory arguments
  • Slash symbol “/” denote the “OR” logical operator.>
Priority QPack Item Priority
  • Rationales
<Provide a list of all possible rationales; the reasons that support the introduction of this market requirement.>
  • Sources
<Each rationale must be supported by a source.  Sources are a list of references and information origins that validate the market requirement.>
Constraints <Provide a list of all possible constraints; the limitations imposed on the solution relevant to this particular market requirement.  Each constraint should be supported by its own rationale and source.>
  • Rationales
<Provide a list of all possible rationales; the reasons that support the introduction of this constraint.>
  • Sources
<Each rationale must be supported by a source.  Sources are a list of references and information origins that validate the market requirement.>
Persona <List names of all personas applicable to this market requirement.>
Use Case <Provide a use case statement or use case identifiers applicable to this market requirement.  Entry of use case information is applicable only if a product or product concept actually exists.>
Buying Criterion <Indicate via this Boolean indicator (Yes/No/NA) whether this market requirement will foster a product feature used as a buying criterion.>
Differentiator <Indicate via this Boolean indicator (Yes/No/NA) whether this market requirement will foster a product feature that is a key differentiator, relative to competing products.>

 

In addition, QPack Product Requirements  can also be applied as a design input requirement. According to ISO 13485 section 7.3.2, design inputs relating to product requirements shall be determined and records maintained (see 4.2.4). These inputs include the following information

  1. a) Functional, performance and safety requirements, according to the intended use,
  2. b) Applicable statutory and regulatory requirements,
  3. c) Where applicable, information derived from previous similar designs,
  4. d) Other requirements essential for design and development, and
  5. e) Output(s) of risk management (see 7.1).

These inputs are reviewed for adequacy over PDR and CDR, and approved. Requirements are complete, unambiguous and not in conflict with each other.  

How Do I Create Design Output In QPack?

According to ISO 13485 Sec. 7.3.3, the outputs of design and development are inserted on a form, which also  enables verification ,and is approved prior to release. Design and development outputs:

  1. Meet the input requirements for design and development                                                                                                                                                               2015-10-31_21-56-25
  2. Provide appropriate information for purchasing, production and for service provision
  3. Contain or reference product acceptance criteria                                                                                                                                                                              2015-10-31_22-02-12
  4. Specify the characteristics of the product that are essential for its safe and proper use.

 

QPack FMEA Section

Risk Product Characteristic

Records of the design and development outputs are maintained (see ISO 13485 Sec. 4.2.4).

NOTE: Records of design and development outputs may include software/hardware specifications, manufacturing procedures, engineering drawings, and engineering or research logbooks.

In QPack you have several sets of work items that can be used to describe the design outputs. In the case of software, the system include work items such as Software Requirements/Software Detail Design/Firmware Requirement/Firmware Detail Design. In relation to hardware design outputs, the system includes Hardware Requirement/Hardware Detail Design, and in the case of mechanical design outputs, there are Mechanical Requirements/Mechanical Details Design (Drawings). All 8 types of work items complete any possible medical device design output.

 


About the author, Rami Azulay

Rami has over 24 years of experience in various software development and QA roles. Using his extensive knowledge of operations and quality, Rami was a main architect of the Orcanos software back in 2005 and later became Orcanos VP sales & marketing. Rami holds an MSC degree in Computer Sciences.

Orcanos

Contact

8Beit Oved Street
Tel Aviv, Israel
+972-3-5372561
info@orcanos.com

Copyright © Orcanos, All rights reserved. | Privacy policy | Terms of use