Understanding the Use of “Where Appropriate/As Appropriate” Within the ISO 13485:2016 Standard


 Remember, you determine what is appropriate for your business.
Document the rationale for the decision.

Historically, the term “where appropriate” and/or “as appropriate” have been implied within the ISO 13485 standards as well as the FDA 21 CFR 820 Quality System Regulations.  The FDA has always explained that “as appropriate” means it is appropriate unless you can justify why it isn’t appropriate.  The recent changes in ISO 9001:2015 introduced the concept of risk-based thinking.  Risk-based thinking establishes the foundation to make decisions based on the business risk – both positive and negative risk.  The key is to make decisions based on a level of risk that is acceptable to an organization.  ISO 13485:2016 also uses risk-based decision making as a foundation.  The ISO 13485:2016 references “where appropriate” 26 other times within the standard.  Essentially, this was done to allow companies the flexibility to “right size” the QMS (quality management system) to meet appropriate business and regulatory needs.

Because the 13485:2016 standard did not convert to the new ISO format there is no explicit clause related to risk-based thinking.  As you can see below, the “where appropriate” requirement ties the risk- based thinking approach to business and QMS management.  The risk-based thinking approach enables the organization to make better decisions about the processes and opportunities for overall improvement. 

ISO 13485:2016 explicitly states in Clause 0.2:

“When a requirement is qualified by the phrase "as appropriate," it is deemed to be appropriate unless the organization can justify otherwise. A requirement is considered appropriate if it is necessary for:

  • product to meet requirements
  • compliance with applicable regulatory requirements
  • the organization to carry out corrective action
  • the organization to manage risks

 

The following table identifies the clauses that include the “where appropriate” clause and some guidance for how to handle these within your QMS.

 

Clause Statement Comments
4.1.3 For each quality management system process, the organization shall:
  1. determine criteria and methods needed to ensure that both the operation and control of these processes are effective;
  2. ensure the availability of resources and information necessary to support the operation and monitoring of these processes;
  3. implement actions necessary to achieve planned results and maintain the effectiveness of these processes;
  4. monitor, measure as appropriate, and analyze these processes;
This is a critical area of transitioning to the 13485:2016 standard. The standard is based on the process approach which incorporates plan – do – check – act (PDCA) and risk-based thinking. The PDCA helps to ensure your processes are adequately resourced and that inputs and outputs are clearly understood. As you work your way through the transition to the new standard, keep in mind how the processes are related to each other. The output of one process often becomes an input to another process. Additionally, as you consider these key processes, you should evaluate if they require measurement, monitoring and analysis and if so, what is appropriate. Don’t just put in KPIs for the sake of KPIs or data. Evaluate what data will indicate the process is working well and you can achieve intended results.
4.1.6 4.1.6 The organization shall document procedures for the validation of the application of computer software used in the quality management system. Such software applications shall be validated prior to initial use and, as appropriate, after changes to such software or its application This is a new clause to the standard. Essentially you have to document a procedure for validating applications of computer software used within the QMS (document control, complaints, CAPA, etc.) The procedure should address the types of software that require validation and when software requires validation (initially and/or post change). Remember you are validating your intended use. Does the software really work the way you want? Never ever automate a broken process. This will end up costing you more time and money than you want. Validation should give you a better idea that the software application will work the way you want with appropriate results.
4.2.3 e The content of the file(s) shall include, but is not limited to: as appropriate, requirements for installation; The Medical Device File is the replacement for the Technical File terminology. Essentially, if installation and servicing don’t apply, then they would not be appropriate. You can’t just state they don’t apply. You need to document there is no risk to the business or the QMS because they are not applicable to your business model. This doesn’t have to be complex, just document you have given it due consideration.
4.2.3.f The content of the file(s) shall include, but is not limited to: as appropriate, requirements for installation; The Medical Device File is the replacement for the Technical File terminology. Essentially, if installation and servicing don’t apply, then they would not be appropriate. You can’t just state they don’t apply. You need to document there is no risk to the business or the QMS because they are not applicable to your business model. This doesn’t have to be complex, just document you have given it due consideration.
6.3 The organization shall document the requirements for the infrastructure needed to achieve conformity to product requirements, prevent product mix-up and ensure orderly handling of product. Infrastructure includes, as appropriate:
  1. buildings, workspace and associated utilities;
  2. process equipment (both hardware and software);
  3. supporting services (such as transport, communication, or information systems).

As appropriate, the requirements shall apply to equipment used in production, the control of the work environment and monitoring and measurement

The infrastructure requirements aren’t new. You have always had to document the infrastructure requirements. It is recommended that you generate a basic risk document related to your infrastructure to identify any potential risks to product and or process that could impact the end product safety/efficacy.
6.4.2 As appropriate, the organization shall plan and document arrangements for the control of contaminated or potentially contaminated product in order to prevent contamination of the work environment, personnel, or product. What do you do to prevent contamination? If you don’t have to worry about contamination because of the nature of the product you manufacture or the process for manufacturing, then just document this as part of the risk management. If it isn’t appropriate, then you have the justification for why it isn’t necessary.
7.1 In planning product realization, the organization shall determine the following, as appropriate:
  1. quality objectives and requirements for the product;
  2. the need to establish processes and documents (see 4.2.4) and to provide resources specific to the product, including infrastructure and work environment;
  3. required verification, validation, monitoring, measurement, inspection and test, handling, storage, distribution and traceability activities specific to the product together with the criteria for product acceptance;
  4. records needed to provide evidence that the realization processes and resulting product meet requirements (see 4.2.5).
Again, as a business you get to determine what is appropriate and how you will handle it. The risk- based thinking is a great benefit here as you have the opportunity to demonstrate the potential risks/impacts on the business and processes. Having this documented in a risk assessment type of document provides you with history/support as future business decisions are made. It can eliminate a lot of non-added value work and expense.
7.3.2 The organization shall plan and control the design and development of product. As appropriate, design and development planning documents shall be maintained and updated as the design and development progresses. The expectation with the new standard is that the design and development documents are maintained and updated throughout the life cycle.
7.3.3 d Inputs relating to product requirements shall be determined and records maintained (see 4.2.5). These inputs shall include: d) as appropriate, information derived from previous similar designs; Essentially as you are putting together the design input/requirements documentation, you should consider if there are similar designs within your own organization/product or other organizations. Are there inputs that would be appropriate for your product? If so, call them out. if this isn’t appropriate, then document the rationale and how they are not appropriate.
7.3.2 The organization shall plan and control the design and development of product. As appropriate, design and development planning documents shall be maintained and updated as the design and development progresses. The expectation with the new standard is that the design and development documents are maintained and updated throughout the life cycle.
7.3.7 The organization shall document validation plans that include methods, acceptance criteria and, as appropriate, statistical techniques with rationale for sample size. This clause is giving some flexibility to the necessity and use of statistical techniques and tools. You have the opportunity to determine where and when statistics need to be used in validation. If you determine that statistics are not required or appropriate you must document the rationale and risk.
7.3.9 c The organization shall document validation plans that include methods, acceptance criteria and, as appropriate, statistical techniques with rationale for sample size. This clause is giving some flexibility to the necessity and use of statistical techniques and tools. You have the opportunity to determine where and when statistics need to be used in validation. If you determine that statistics are not required or appropriate you must document the rationale and risk.
7.4.2 Purchasing information shall describe or reference the product to be purchased, including as appropriate:
  1. product specifications;
  2. requirements for product acceptance, procedures, processes and equipment;
  3. requirements for qualification of supplier personnel;
  4. quality management system requirements.
As you work through the approved suppliers, you need to consider each of these elements. Using some type of risk management/prioritization approach to supplier management gives you the opportunity to determine what type of information you need to qualify and/or approve supplier based on criticality and risk as well as what type of information you need to provide to the supplier. It also gives the opportunity to determine whether a Quality Agreement is appropriate to define how quality management system requirements are to be met for both organizations.
7.5.1 Production and service provision shall be planned, carried out, monitored and controlled to ensure that product conforms to specification. As appropriate, production controls shall include but are not limited to
  1. documentation of procedures and methods for the control of production (see 4.2.4);
  2. qualification of infrastructure;
  3. implementation of monitoring and measurement of process parameters and product characteristics;
  4. availability and use of monitoring and measuring equipment;
  5. implementation of defined operations for labelling and packaging;
  6. implementation of product release, delivery and post-delivery activities
The list of requirements for this clause may or may not apply to your business. You should evaluate each of these elements to determine what has implications for your business. What risks do you encounter from a business, product and process perspective and are these risks acceptable. If any of the elements are not appropriate, you should document along with the reason they are not appropriate for your business.
7.5.3 The organization shall document requirements for medical device installation and acceptance criteria for verification of installation, as appropriate. If your product does not require installation or support, then this clause would not be appropriate. This must be documented and should introduce no risks to the business.
7.5.4 b The organization shall analyze records of servicing activities carried out by the organization or its supplier: as appropriate, for input to the improvement process If servicing activities are carried out by your organization, you must analyze the service data for potential opportunities and/or risks. If there are no servicing or support activities, then there would be no analysis required. This should be documented as minimal or no risk.
7.5.6 The organization shall document procedures for the validation of the application of computer software used in production and service provision. Such software applications shall be validated prior to initial use and, as appropriate, after changes to such software or its application. The specific approach and activities associated with software validation and revalidation shall be proportionate to the risk associated with the use of the software, including the effect on the ability of the product to conform to specifications. If your organization used computer software anywhere within the QMS, you must validate the software. Essentially this clause states you must have a procedure for validation of computer software used – even within the manufacturing operations. It must be validated prior to use. The type of validation is based on the risk associated with the use of the software. It is recommended that you make a list of all software used within your operations and identify what is being used for, what business risks might be encountered and when it was last validated. If there is validation documentation, then reference that for easy auditing. If there is no validation documentation determine if it is necessary. Consider a retrospective validation based on length of time in use and what the software is used for.
7.5.7 Processes for sterilization and sterile barrier systems shall be validated prior to implementation and following product or process changes, as appropriate. If your product requires sterilization of a sterile barrier, then it should be validated prior to implementation and whenever there are product or process changes, as necessary. Again, these should be identified on the master list along with appropriate risks and necessary validation requirements.
7.6 The organization shall document procedures for the validation of the application of computer software used for the monitoring and measurement of requirements. Such software applications shall be validated prior to initial use and, as appropriate, after changes to such software or its application. The specific approach and activities associated with software validation and revalidation shall be proportionate to the risk associated with the use of the software, including the effect on the ability of the product to conform to specifications. This requirement goes along with the other requirement for procedures for the validation of computer software. Again, having them on a master list along with risks and requirements facilitates easy reference as necessary for changes and/or upgrades.
8.2.5 The organization shall apply suitable methods for monitoring and, as appropriate, measurement of the quality management system processes.

These methods shall demonstrate the ability of the processes to achieve planned results. When planned results are not achieved, correction and corrective action shall be taken, as appropriate.

The key here is how to monitor and measure that your quality system processes are working well or as intended. You have to determine what methods you use and appropriateness to provide meaningful information.

These methods should be more than just establishing KPIs for data’s sake. It is important to identify the key information to evaluate the processes and the ability to achieve planned results.

8.2.6 Evidence of conformity to the acceptance criteria shall be maintained. The identity of the person authorizing release of product shall be recorded (see 4.2.5). As appropriate, records shall identify the test equipment used to perform measurement activities. Evidence of conformity is required throughout this clause. The where “appropriate” applies to the service reports. If your business doesn’t provide service to the products, then it would not be appropriate. You must document this along with the rationale and the decision of no risk impact.
8.4 f The analysis of data shall include data generated as a result of monitoring and measurement and from other relevant sources and include, at a minimum, input from: service reports, as appropriate. Again, data analysis occurs at numerous areas within the standard. The where “appropriate” applies to service reports. If you don’t provide service on the product, then there would be no data to evaluate.
8.5.2 d The organization shall take action to eliminate the cause of nonconformities in order to prevent recurrence. Any necessary corrective actions shall be taken without undue delay. Corrective actions shall be proportionate to the effects of the nonconformities encountered. …..planning and documenting action needed and implementing such action, including, as appropriate, updating documentation. This clause is referencing the update of documentation as appropriate to support a corrective action. For example, if the root cause requires a process or design change, the associated documentation may need to be reviewed and updated. This is part of the risk-based thinking that has been built into the standard. If there are no updates required, then this should be documented in the file.
8.5.3 c The organization shall determine action to eliminate the causes of potential nonconformities in order to prevent their occurrence. Preventive actions shall be proportionate to the effects of the potential problems. planning and documenting action needed and implementing such action, including, as appropriate, updating documentation; This clause is referencing the update of documentation as appropriate to support a corrective action. For example, if the root cause requires a process or design change, the associated documentation may need to be reviewed and updated. This is part of the risk-based thinking that has been built into the standard. If there are no updates required, then this should be documented in the file.
8.5.3 e The organization shall determine action to eliminate the causes of potential nonconformities in order to prevent their occurrence. Preventive actions shall be proportionate to the effects of the potential problems, planning and documenting action needed and implementing such action, including, as appropriate, reviewing the effectiveness of the preventive action taken, as appropriate. This clause is referencing the update of documentation as appropriate to support a corrective action. For example, if the root cause requires a process or design change, the associated documentation may need to be reviewed and updated. This is part of the risk-based thinking that has been built into the standard. If there are no updates required, then this should be documented in the file.

 


This article is related to the White Paper:

Understanding ISO 13485: A Brief, Yet Comprehensive, Overview

To get the full details, please download your free White Paper.

As you work through your transition to the new ISO 13485:2016 keep a few critical points in mind:

  • You make risk-based decisions every day in your business and personal life!  This really isn’t new.  The requirement to document a procedure for how risk is managed.  This includes business risk, product risk, and process risk.
  • You determine what is appropriate for your organization/business.  Just be sure to document the rationale for the decision.
  • Keep it simple.  Don’t overthink it.



Christine (Chris) Park
is a seasoned quality assurance professional with a wealth of experience in establishing and remediating quality systems of all sizes.  Using a pragmatic approach to compliance and quality assurance, Ms. Park has successfully focused on results-oriented solutions that integrate quality into the daily business activities of organizations.  Her experience in R&D and general manufacturing for medical devices, IVDs, and biotech/pharmaceuticals provides a well-balanced background for her work in compliance.

Whether working on a full quality system or on key quality components (CAPA, complaints, audits, supplier quality, management controls), Ms. Park provides employees and management not only with adequate direction and tools to maintain compliance, but also with the understanding of why they must comply with specific requirements.

Ms. Park has played an active role in the generation and review of technical documentation in support of regulatory submissions.  Her direct experience includes facilitating product and process risk assessments, change management (design as well as manufacturing), product and process validation plans and protocols.  She has developed strong relationships with manufacturing as well as design/development organizations.  She is an active member of AAMI TC210 standards committee.

Ms. Park is currently consulting with industry for implementation and/or transition to the revised ISO 9001:2015 and ISO 13485:2016 standards. FDA remediation (820, 210/211, foods).  Additionally, she is providing training and auditing expertise for organizations related to these standards, 21 CFR 820 and other FDA regulations.  She may be reached at (678) 480-5411 or cpark928@mindspring.com.