Applied Sciences Homework

Chapter 5

Writing the Quality Manual

The quality manual is the fi rst point of entry into to your QMS. It should set the context, the scope, and the goals of your QMS as well as introduce your processes on a high level. I also like to defi ne constants affecting several of the other processes in the quality manual; for example, principles for document retention periods and device lifetimes—that way, these are available for all your SOPs in one convenient and predictable location.

This section will take you through what is expected of a quality manual, provide you with a template for creating it, and then walk you through the requirements of the standard to create a manual that meets the expectations in a smart, concise, and readily maintainable way.

5.1 What Is Expected

The quality manual is the gateway, or the airlock, to your QMS. It is both the foundation stone of your QMS when you are adding new processes or figuring out any conflicts between them and the best bird’s-eye view of the lay of the land for an outsider, such as an auditor, a discerning B2B customer, or a new employee. It sets the scene for all activities inside your organization and describes your relationship to the world around you. It even sets the overarching quality policy your organization will aspire to. It is in many ways the backbone of the way of life you want to build for your quality management operations.

As you are writing the first sections of the manual, it will all probably seem quite aspirational, but it should not be flying off in the stratosphere

DOI: 10.4324/9781003202868 -5 99

 

100  Developing an ISO 13485–Certifi ed QMS

sprinkling stardust and hype on all that read it. Out of all your QMS docu- ments, the manual is the one place where you can exercise a little more artistic flair to make it easier on the reader, but it should all still be very much grounded in reality. The details of your processes will be in the stan- dard operating procedures (SOPs) we will be writing in the next sections, but here you are laying the foundation for all that is to come: the negotiation of the various SOPs together, the context of interpretation for any particu- lar SOP, and the underlying common understanding between you and your reader—whether that reader is an employee, an auditor, or a customer.

The formal requirements for the quality manual are given in Clause 4.2.2 of the standard. The quality manual must define the scope of the QMS, explain any exclusions you have made on the clauses of the stan- dard, describe the processes that make up your QMS, and also outline the documentation used by the QMS. Furthermore, description of the interac- tion between your processes is a requirement for the manual. In practice, a description of the organization, its mission, and the general overview of the type of products it works with is also expected here. Not having this description here would make it more challenging to set out the quality pol- icy and objectives a little later. The policy and objectives need to be defi ned somewhere in your QMS, preferably on a level of some elevated standing as these will affect all the other parts of the QMS, so I would do that here in the manual.

Table 5.1 gives an overview of what is required of the manual by the standard and what I would recommend you consider when writing it.

Recently, there was lively discussion on one regulatory professional’s forum comparing notes on how big a quality manual should be. The

Table 5.1 Requirements and Recommendations for the Quality Manual

Required  The scope of the QMS. Explain what operations your QMS covers and what clauses of the standard are not relevant and why. Remember that you can only exclude requirements from Clauses 6, 7, and 8, and even then, only with a valid reason (see Section 4.3 in this book).

 The processes of the QMS. Explain what processes your QMS consists of and how these relate to each other.

 The structure of your QMS documentation. Explain what documents and records make up your QMS and how they relate to each other. You might, for example, have a quality manual that is supplemented by process-specific SOPs that, in turn, make use of working instructions and defined template documents to create individual records.

 

 

Writing the Quality Manual  101

Table 5.1 (Continued) Requirements and Recommendations for the Quality Manual

I would recommend

 An overview of your organization. Don’t go overboard here, but your readers will benefit from having a short introduction into your organization, why it was founded, where it is located, and so forth.

 A short overview of the kinds of products this QMS will cover. Don’t try to describe the specifics of the products you intend to work with, but it should be helpful to explain whether you, for example, work with high-risk implantable products or some basic bandages to dress wounds.

 Quality policy. Clause 5.3 of the standard requires your organization to have, somewhere in your QMS, a top-level quality policy that is communicated, understood, reviewed, and—I would also add— adhered to continuously. I feel that the quality manual offers an excellent location to define this policy and that defining this policy is the logical next step after introducing your organization and products.

 Define global constants affecting all other processes, or several of them, in the quality manual. Examples of such constants could be principles for calculating document retention periods, device lifetimes, and so forth. You may want to write in some latitude for refi ning these further down the food chain as circumstances require, but the quality manual should be a good place to set up the mechanism.

Food for thought

 Consider what types of periodic changes that are external to the quality manual are likely to take place and how these changes will affect the manual. For example, if you write in a lot of detail on any given process in the quality manual, these details may change as the SOPs for the processes are revised during regular document review. If the changes made in the individual SOPs do not affect the input of any other process or SOP, it is likely that the changes should not require you to revise a well-written quality manual. Predicting this here in how you write the manual may make your life easier in the long run as you will be forced to make less trivial edits to your manual.

 Consider including a reference table or a few paragraphs of text mapping the clauses of the standard to your SOPs. If your QMS is very lean, or written to use the structure of the standard, this may not add utility, but it is worthwhile considering how the clauses of the standard map to your QMS. Your auditors will approach your QMS from the point of view of the clauses and not necessarily from the delicate narrative structure you have intended.

experiences on encountered manuals ranged from a single-page docu- ment to a multitier affair resembling the file management view built into the Windows operating system or a full-blown website. On another forum, a consultant once told me that the manual is just a graphical diagram of the individual processes. In fact, there is no one correct answer, but if you go

102  Developing an ISO 13485–Certifi ed QMS

for a diagram, remember that you still need to cover the requirements of the standard, including, for example, the written quality policy, somewhere in your QMS. Each of these approaches has been successful, so the primary consideration should be how your organization wants to represent the infor- mation in question. What matters is that the quality manual works for you: it sets up your QMS, introduces it to those needing to grasp your QMS, and functions as a part of the overall documentation you have set up for your QMS.

One of the first questions to answer when setting out to write a quality manual is if you want to write one monolithic document or a set of docu- ments. Some consultants may still advise you to think of the quality manual as a synonym for your QMS. They may advocate writing in all you want to say about any process or subprocess into the manual and thereby circum- vent the need to write separate standard operating procedures. You could do this and write in all the detail of your processes in your quality manual, but in most cases, I would advise against that for the following reasons:

 Your quality manual serves as the primary entry point into your QMS. You will want to share that entry point with auditors, new staff members, and possibly even B2B customers. If you wrote everything in one document, you would be sharing it all as the basis of, for example, every surveillance audit of your QMS from here on out. You would be asking all new staff members to read a monolith and figure out which sections are important to them and which are not. This is doable but probably not optimal. It therefore makes sense to write that entry point, or index if you will, as succinctly as possible so as not to waste every- one’s time and possibly overwhelm them with superfluous details on processes that are not relevant to them.

Maintaining a monolith may be gargantuan task. After you have successfully launched your QMS, you will go into a continuous cycle of document reviews, where every month or so you will be asking dif- ferent process owners to review and revise their process descriptions to make sure they are still accurate and effective. If all your processes were in a single document, you would have to be even more careful when handling this document review so that changes don’t fl ow over from one process to the others, or worse still, overwrite each other.

 Training on a document undergoing constant change will be a hassle. You would need to be careful with what has actually changed within the quality manual and what has not, even though the whole

Writing the Quality Manual  103

quality manual will have a new version number. This will have ripple effects in organizing staff training on the changes performed. The quality manual is the one document in your QMS that should really be trained to all your staff, and attempting to deviate from that—or keep track of which section of a single monolithic document is relevant to whom—may be more trouble than its worth.

 No other document in your QMS is superior to the quality manual. If you write your whole QMS into your quality manual, there is no distinction here, but setting your quality manual up as the parent of other documents in your QMS may have advantages; for example, it allows you to define something, like the quality policy, once and reuse it elsewhere.

Ultimately, the choice between one document or a set of documents is, of course, yours. In this book, I have opted to go with a hierarchical set of documents and would not look back. Similarly, the choice of where to define something—in the quality manual or a specific SOP is largely up to you. For most things, the standard requires something to be defi ned, but it does not make many requirements on where within the QMS those are defined. This book gives you a suggested structure for what is defi ned in the manual and what in the individual SOPs, but in most cases, you could decide otherwise if you truly wanted to.

It is worth noting that the ISO 13485 standard gives us a great overview of the quality management system we want to build. It doesn’t exactly give us a blueprint of what we want—there are still regulations, other standards, and the specific circumstances of your organization’s business to consider in implementing the standard—but it does give us a practical framework to build our QMS within.

5.2 Pen to Paper

Okay, let’s finally put pen to paper or fingertips to keyboard keys. This sec- tion will walk you through the writing of the manual. You will find a tem- plate for creating the manual in Appendix 2 when you need it.

The quality manual is the place to introduce your circumstances and your QMS, and perhaps get a few global matters defined too. You will begin by writing what you already know then move to topics that are increasingly new and some that you will want to revisit after working on your SOPs

104  Developing an ISO 13485–Certifi ed QMS

in Sections 6 through 19. In writing the process descriptions here in the manual, stick with a very high-level overview of each process. Most of the specifics should be left to the SOPs we will write for each process a little bit later. You may even want to treat the process descriptions here as placehold- ers for something you will fill in after working on the coming sections. Also note that in both the manual and the SOPs, you can make use of appendi- ces and references to structure the content and thereby make its reuse easier when later referring to it from your other documents.

The manual itself can be as long or as short as you see fit. In practice, I would aim at 10 pages and be happy if I ended up somewhere between 5 and 30. This is also a good place to define a general document template for your organization’s QMS documents. If your organization already has a generic template and you would like to dive straight into creating your qual- ity manual, you can also use that template for now. There are some things specific to a QMS template, but for now, you can skip those and get writing as we will be working on templates a little later. If you would like to get started with the full template straight away, read Section 20 now and then return here. The template presented in Section 20.3 follows the design dis- cussed in this section.

My suggestion for the outline of your quality manual is shown in Table 5.2. Note that the first half of the manual is intended to read like a standalone introduction into the QMS, while the second half of the list mainly consist of references to the process-specifi c SOPs.

I highly recommend writing the manual in the order specified in the table, from top to bottom. This way, you will progress naturally from the things you should already know (e.g., description of your organization and your product), to things you probably already know at the back of your mind (e.g., your quality policy), and to things you then need to fl esh out (e.g., the individual processes). In addition to being easier for you to write, this order will also nicely set out the narrative inroad for your auditors and other interested parties getting to know you through your quality manual. Also know that you will probably be making another pass over the manual after having worked on the SOPs, so don’t worry too much about getting everything perfect from the start here.

Although not shown in the outline table, your general document template will probably also introduce other practical information elements, such as a document record table (consisting of, for example, document name, docu- ment ID, version, issuer, issuance date, and signatures), and some of this

Writing the Quality Manual  105

Table 5.2 Outline for the Quality Manual

A) Purpose of the document

B) Organization overview

C) QMS overview

D) Key roles

E) Products

F) Processes

G) References

H) Appendices

I) Version history

 What is this document?  What purpose does it serve?

 Information about the organization  Identified role of the organization in medical

devices  Basic structure of the organization  Type of products manufactured

 Scope of the QMS and rationale for exclusions  Quality policy  Quality objectives (see appendix)  Structure of QMS documents  High-level principles (e.g., document retention

time schemes)

 Definition of top management  Definition of key roles, such as the management

representative and the quality manager

 Any generic definitions on device lifetime, product version numbering, and so forth

 Overview of the processes defined by the organization, including their interrelationships

 Identification of any prioritized core processes  Overview of all the processes based on the

clause structure of the standard

 Any references you may have used

 Staff responsibilities and qualifications by role  Quality objectives  Inter-process relationships

 Version numbers and dates for this document, along with short description of key changes and identification of the person who made that change

N o

ve l c

o n

te n

t Sh

o rt

in tr

o

+ re

fe re

n ce

s

N o

ve l c

o n

te n

t

information may also be carried over to the document header or footer. Refer to Section 20 for more on templates.

Let’s go over that outline in more detail, focusing on the most important and novel sections of the manual. The structure I propose here is based on several years of experience, but you are free to modify it or add to it if you like. The standard does not impose any one structure on you or any maxi- mum set of information you may have in a manual, but it does expect to see

106  Developing an ISO 13485–Certifi ed QMS

certain information in your manual. Less is more when it will come to keep- ing the content current over the coming years, so be concise but not to the point of cruelty toward your readers.

5.2.1 Section A—Purpose of the Document

This is a short introduction that helps orientate the reader on why this particular document was written, what purpose it has, and what role it is given by the organization’s QMS. In the case of the quality manual, this may simply be a short statement that the document is the quality manual of the organization’s ISO 13485 Quality Management System, and that it introduces the organization’s QMS and refers to other QMS documents for more details.

5.2.2 Section B—Organization Overview

Section B gets down to the business of your QMS. In writing each of the following subsections, you are now diving deeper into your QMS. Writing these subsections in the given order leads you down a logical path to defi n- ing your whole QMS one step at a time.

About the Organization

A general-level organization overview is, strictly speaking, not required by the standard, but it will be difficult for the reader of the manual to get a handle on your organization without some sort of a soft-landing in the form of a brief introduction of your organization and the business it is in. Think about being dropped into a Christopher Nolan film like Memento or Tenet and spinning your wheels in all directions while you try to figure out what is going on. In films, such tricks work great, but in real life, your reader will grow frustrated with you if you make them guess what the point of it all is. QMS documents really are not about intrigue and the Aristotelean dramatic arc but instead about focusing on the essential information and walking your reader into it.

Having a soft introduction of your organization here will not only ease the reader into your QMS, but it will also make it easier for you to intro- duce your scope and quality policy a little later in the manual. It is also something auditors have, by all accounts, come to expect from the manual. The introduction should be short and sweet. Your organization’s registered name, registered address, and a brief “about us” description of where you

Writing the Quality Manual  107

come from and where you want to go. The important part here is to clearly state what role your organization takes under the medical device regulations applicable to you; for example, a manufacturer, an authorized representative, an importer, or a distributor (required by Clause 4.1.1). Note that the regula- tions applicable to you may affect your choices here.

In our case, we were just getting started as a startup company after spin- ning out from under the wing of the university, so we wanted to say that. We were working on our first product, so we said that. We saw ourselves as the manufacturer of a medical device product, so we said that. My advice here is that you shouldn’t take things for granted but instead, be quite explicit in stating your role. This is something your reader will look for in the text, so don’t make them guess or deduce how you see yourself.

It is also worth noting that while Clause 4.2.2 of the standard cover- ing the quality manual does not require the organization’s physical loca- tions to be listed here, the guidebook on the standard published by ISO does request addresses and functions performed at these addresses to be listed here. The guidebook, of course, does not have the offi cial standing of the standard, so the choice here is up to you. You will, in any case, have to define the addresses somewhere in your documentation, includ- ing the certification application. The manual, therefore, is a good choice. Note that any changes to these locations will be of interest to your cer- tification provider and may trigger a new audit of the premises, so you should discuss such moves with them in advance. Similarly, the ques- tion of handling remote locations, even offshore locations, appears to be a reoccurring discussion on forums for regulatory professionals. If this applies to your situation, it, too, will be a serious conversation between you and your provider.

Organizational Structure

Your organizational structure is perhaps best represented as a chart or a tree diagram. We thought about the different functions we will have: the shareholders, board, CEO, Management Team, Communications Team, and Quality Management Team, for example. These go into a chart nicely. In addition, I would write the more detailed roles and responsibilities of per- sonnel as an appendix of the manual that we can refer to here without the fear of bloating text or duplicating it.

The requirement to define roles and the interrelation between roles stems out of Clause 5.5.1 of the standard but is conveniently addressed on a top

Figure 5.1 Organizational chart.

108  Developing an ISO 13485–Certifi ed QMS

level here in the quality manual. You may also consider defi ning substitutes by roles in the same appendix. The process-specific responsibilities and authorities of the roles should, however, be defined in more detail in indi- vidual SOPs.

Figure 5.1 provides a sample organizational chart. Make sure the chart you provide makes sense to you and is true to life at your organization. Of particular interest here from the point of view of the standard is that you clearly define your top management and any chart you provide matches with that definition. Additionally, you may want to define what personnel affect quality at your organization and depict that in the chart too.

Writing the Quality Manual  109

5.2.3 Section C—QMS Overview

Section C picks up speed by defining the scope of your QMS, your overarch- ing quality policy, and the overall document hierarchy used by your QMS.

Scope

The first item to cover in the overview is the scope of the QMS and the operations you intend to fit within your QMS. For example, are you only designing medical devices or also manufacturing and possibly selling them to end users? This will affect what clauses of the standard apply to your operations.

Within the organization role you defined in Section B, you should now provide further clarification on whether you provide a product and/or ser- vice, and whether you are involved in the design, development, production, and/or sales of the product and to what kind of customers. Per Clause 0.1 of the standard, your organization may be involved in one or more stages of the life cycle of a medical device or a service. The stages may, for example, be one or more of the following: design and development, production, storage, distribution, installation, servicing, support, decommissioning, and disposal. The right answer here is the answer that describes your particu- lar situation the best. You should use these established terms if they apply to you, or if they don’t—for example you are adopting the standard by choice—explain your role here the best you can.

An example here might be that you are a medical device manufacturer engaged in the development, production, and sales of a particular kind of a medical device intended for medical professionals. Make the defi nition broad enough to cover the intended purpose (intended use) of all your devices but narrow enough to be of value to the reader.

The requirement for the definition of the scope is in Clauses 1 and 4.2.2a.

Exclusions

The standard allows you to exclude requirements made in Clauses 6 (“Resource management”), 7 (“Product realization”), and 8 (“Measurement, analysis and improvement”) of the standard if, and only if, you can pro- vide an acceptable rationale as to why such requirements are not applicable to you. The rationale may be based on the activities undertaken by your organization or the nature of the medical device you work with. It is, how- ever, absolutely crucial that you include a clear, acceptable rationale for any

110  Developing an ISO 13485–Certifi ed QMS

exclusions you make here. Also, don’t make further exclusions in your SOPs later, but instead, gather all your exclusions here.

Be careful here and remember what we previously discussed in Section 3: the standard requires interpretation, and nothing can be dismissed right off the bat. Also note that you are not allowed to make exclusions to requirements made in Clause 4 (“Quality management system”) or Clause 5 (“Management responsibility”) or Clauses 0 to 3 either.

The requirement for the definition of exclusions is in Clauses 1 and 4.2.2a.

Quality Policy and Quality Objectives

The next big thing is the quality policy—your organization’s shining light in shaping quality management and making a difference in the world for the better. For example, how do you see your relationship with new science, clinical studies, and feedback from the field? What role do customer satis- faction, patient outcomes, or intellectual property rights play in your opera- tions? The policy will be your North Star, which may evolve over time, but it should not be fleeting or in constant change.

The requirement to have a quality policy and quality objectives comes from Clause 4.2.1a. Furthermore, Clauses 5.1b, 5.1c, and 5.4.1 then require that your top management is involved and that you establish both a policy and the objectives based on it. The core requirements for both are then set out in Clauses 5.3 and 5.4.1, as described in the following. The requirements for the quality policy are written so that your top management must ensure the policy does the following:

 is applicable to your organization’s purpose  includes commitment to requirements  includes commitment to maintaining QMS effectiveness  provides a framework for establishing and reviewing quality objectives  is communicated and understood within the organization  is continually reviewed for suitability

Similarly, the top management must ensure that the objectives do the following:

 are consistent with the quality policy  are established at relevant levels and functions with the organization

Writing the Quality Manual  111

 answer to product and regulatory requirements  are measurable

The general idea behind the quality policy is that it allows you and your organization to pursue your intended use and benefit while understanding and adhering to applicable requirements in an effective, safe, and sustained manner. The policy is something that you should have a very good idea of from the start and that probably should not change much over the fi rst few years. In writing your quality policy, don’t worry about fancy prose or reference to specific clauses in the standards or regulation. Make sure you address the previous items, but otherwise, be yourself and talk with your management to arrive at a description that captures the essence and the drive of your organization. The policy will inform everything else you do later in developing your QMS, so it is worth spending some time on it, but if there are small things that your organization doesn’t yet know or may want to tweak later, that’s okay. The quality policy will be reviewed continually—I would recommend coupling this with the management reviews as a fail-safe for periodic rereview—and the management will get to revise it as needed.

I would attempt to keep the policy to a length of half a page or a page at most. Some auditors have reportedly even asked staff members to recite the quality policy by heart, and although that is just seven kinds of stupid, you should be clear and concise on what the policy wants to say for your read- er’s sake. If you are the only person at your organization who can appreciate the beauty of the quality policy you have written, then you have messed up, as not many others at your organization will observe or strive for the same policy. In some companies, you may see the quality policy posted on walls of the factory floor or even distilled down to simple quotes on their business cards, so think about what you want to set as your goals here and be con- cise in how you word them.

Building on the policy, the quality objectives are then an extension of your policy toward measurable aims to strive toward in your operations. I would aim at a handful of objectives overall and, instead of writing them into the body of the manual, include them as an appendix to the manual for easy reference. I would approach the objectives as themes you can pick out from your overall policy, and think of these as the folders for the indi- vidual quality indicators you will end up having to measure in tracking your processes.

Your quality indicators are the third level of defining trackable qual- ity metrics at your organization. The indicators are measurable, preferably

112  Developing an ISO 13485–Certifi ed QMS

numeric, values that you can periodically (think: monthly) collect from your organization. The indicators should provide you and your top management with adequate information on the overall status of your operations to assess how well the quality objectives are being met and your quality policy real- ized. Thus, when your policy discusses a drive to meet customer require- ments, one of your objectives could be “high customer satisfaction” and one of the quality indicators under that objective could be the number of com- plaints as a simple monthly count or a factor of all feedback.

Strictly speaking, you do not have to define the quality indicators in your quality manual, but thinking about the indicators now when you are writing your manual and SOPs, and then finalizing the indicators after the SOPs are ready are good ideas. In general, you will want some indicators for each of your quality objectives while also making sure you cover all the processes in your QMS. A handful of objectives and about two dozen indicators might be a good starting point for a new QMS, but the exact figures will depend on your circumstances.

The indicators will not be set in stone as your management will have the right to modify the indicator list, as well as the responsibility to monitor the indicator data. As your operations mature, so, too, will the indicators you track, but also pay attention to the longevity of the indicators and get mean- ingful time series data on any of the indicators. I would suggest entering the list of quality indicators as an appendix to your manual and updating that list as you progress through the SOPs in Sections 6 through 19. Alternatively, you can focus on the policy and the objectives here, and then set the indica- tors and track them (e.g., via a registry) when you launch the QMS.

Once you have defined the scope of your QMS and written a policy and objectives you are happy with, you will have laid the foundations for your QMS. Get a cup of coffee, tea, or whatever it is you enjoy as your energy drink of choice. Also, make sure that your top management is happy with the policy and that, if you prepared the policy for them, any changes they want to make are observed. The checklists in Section 5.3 will help you check your bases when writing the policy and the objectives.

Structure of QMS Documentation

The third major item to outline in this section of the manual is the over- all structure of your QMS documentation and whether the documents are managed as a physical collection of binders of papers or on some electronic document management system. Unless you have some hippo-sized reason

Figure 5.2 Basic document structure.

Writing the Quality Manual  113

for going with a paper-based approach, I would give the electronic system serious consideration.

Regardless of whether you manage your documentation electronically or physically, the structure of the documents may again be effectively repre- sented as a diagram. Here, I would simply present a tree diagram of the top levels of my stack of documentation; for example, something like shown in Figure 5.2.

In implementing your document structure on an electronic platform, you will want to play around with the different platforms to make sure your chosen platform supports the structure you want. In all likelihood, the struc- ture you want to define won’t be all that mystical that any decent software couldn’t support it, but if you get to choose your platform, you should make sure you can and want to work with it (also see Section 22 for software vali- dation). The basic set of documentation you will be working with on the top

114  Developing an ISO 13485–Certifi ed QMS

level is fairly standard, and Section 4.4.1 previously introduced you to all the key types of documents.

You can define many more documents in this hierarchy if you like, but I would just define the top levels here and then expect to fi nd appropriate places for other documents under the tree when writing the SOP discussing each document. Logical expansion is the name of the game here, especially as you have yet to write all the SOPs.

The requirement to outline the overall QMS documentation structure comes from Clause 4.2.2 of the standard.

High-Level Principles

The body of your previous description will have quickly set out the founda- tions of your QMS, why it is developed, what role you undertake, and what is its scope. In doing so, you will probably have touched on aspects, such as whether you intend to keep records in an electronic versus paper-based format, whether your QMS is in English or Japanese, and whatever else was relevant to you in setting up your existence earlier. There are two further topics I would specifically address here.

Firstly, I would briefly refer to SOP-1 as the key to your document IDs. The details of this will be handled in the SOP, and thus, a mere reference will do here.

Secondly, I would set out your basic approach to both document and record retention times here. As discussed in Section 3.11, QMS documenta- tion is subject to retention times that need to meet not only the standard but also the applicable regulations. Clauses 4.2.4 and 4.2.5 of the standard require that documents instructing records are available for at least as long as the records made based on them; records, on the other hand, are avail- able at least X years after the devices made based on them are on the mar- ket (i.e., from the time the device is released by the organization); and none of this expires in under two years. The definition of X is up to you here, but realize that the applicable regulations probably talk of five to ten years or longer instead of the two-year minimum given by the standard. A rule of thumb I have come to live by is to promise X years and quietly aim at for- ever. If you know you will need to address differing requirements from the various jurisdictions that apply to you on these matters, you may begin to do that here and make allowances for subsequent adjustment in your SOPs (particularly SOP-11) and product-specifi c documentation.

Writing the Quality Manual  115

5.2.4 Section D—Key Roles

In addition to the organizational chart that may be included in the quality manual, the QMS must define key roles and both their responsibilities and authorities. To a large extent, this is done in the individual SOPs, but intro- ducing the key roles and their qualifications is best done in the manual. The requirement to ensure responsibilities and authorities are defi ned, docu- mented, and communicated within your organization rests with top manage- ment (Clause 5.5.1).

The roles were already introduced in Section 4.4.4, but as a refresher, the central roles you will probably be dealing with in your quality manual and SOPs, are introduced here are as follows:

 Top management  Management representative  Quality manager  Quality Management Team  Various C-level officers (e.g., chief technology offi cer)  Various subject area expert positions at your organization (e.g., medical expert and regulatory expert)

I would mention these roles here, but leave any detailed definition of them for the appendix to the manual on staff responsibilities and qualifi cations by role. This way, all the key responsibilities, authorities, qualifi cations, and arrangements for deputies are conveniently located in one place.

As a reminder, C-level officers are safer options for ensuring something is done, and more generic subject area expert roles, or communal hats, are good options for ensuring that some important viewpoint is heard while doing that. Remember to also define deputies for critical roles somewhere in your QMS; for example, in an appendix to the manual that describes staff roles.

Note also that Clause 5.5.1 requires you to document the interrelation of all personnel who may affect quality and to ensure the independence and authority of these personnel in such tasks. Defining an organizational struc- ture and placing these roles at the appropriate locations under that struc- ture, as well as defining substitutes for key roles, will begin to answer this requirement. That is about as much as you should aim to do in the quality manual. The rest of the details will be in the SOPs and the devil itself in how you run your organization in the day-to-day.

116  Developing an ISO 13485–Certifi ed QMS

In Europe, you may also want to define the person responsible for regulatory compliance (PRRC) here, but as there seems to be a fair amount of confusion around the exact role, responsibilities, personal liability, and other characteristics associated with the definition and a great deal of variation across the industry, I might be wary of taking a stand in the QMS just yet. For small companies, this role can be outsourced to a consul- tant, and larger corporations have apparently split the role across multiple people, each taking responsibility for some specific area. If the European regulations are applicable to you and you are new to QMS, I would dis- cuss this matter with your quality experts to make sure your defi nition is sound. You can also check out real examples of how companies have defined PRRCs from the online EUDAMED database run by the European Commission.

5.2.5 Section E—Products

A section on products is not required by the standard, but I would recom- mend it as a practical place for introducing any product-related concepts you may need elsewhere in several SOPs. For example, defining your overall approach to device lifetime, product version numbering, and product iden- tification might go in here. Product classification under the various regula- tions that might be applicable to you, I might save for SOP-11, but make this reference here. Similarly, SOP-10 is your reference here for instructing the product realization process in general

Clause 7.5.8 requires you to have a documented system for assigning unique device authentication to your products if this is required by the regulations applicable to you. This requirement is a short piece of text in the standard but a profound requirement for your operations. In some cases, your basic product version numbering may be enough (e.g., in case of a truly cloneable software module this probably identifies the product beyond any doubt), but in other cases, you will want to lean on unique IDs specifi c to a production batch or even packaging. You may also comment on your approach to the traceability of products (Clause 7.5.9, see SOP-11) on a high level here.

The alternative to introducing these mechanisms here is that you do so solely at a lower level in your SOPs or even product-specifi c documenta- tion. You will then need to always dive deeper in audits and perhaps jump through more hoops to ensure your staff and customers share and remem- ber your definitions. The quality manual should thus be a good place to

Figure 5.3 A bird’s-eye view of your SOPs.

Writing the Quality Manual  117

introduce at least the existence of such concepts. I would introduce my approach to product versions here and refer to SOP-11 for more details on identification and traceability.

5.2.6 Section F—Processes

The requirement for the manual to include or reference the documented procedures of the QMS is a fundamental one in the ISO 13485 standard and is stated in Clause 4.2.2b. In my view, it is impractical for maintenance rea- sons and for training and general readability reasons to include the whole process descriptions in the manual, although this, too, would be permis- sible by the standard. If you do have separate SOPs, it is unwise to repeat details here or go into too much detail while attempting to introduce the processes in the manual as any edits to the underlying SOPs would then need to be reflected in the manual as well. This would lead to frequent unnecessary editing of the manual. The consensus among quality profes- sionals is that the process descriptions in the manual should be brief, be on a high level, and have the primary objective of referencing the actual SOPs in question.

Clause 4.2.2c further requires you to describe the interaction between the processes. You can begin to answer this requirement by providing a high- level diagram of your SOPs showing the connections between the individual SOPs and possibly pointing out critical paths as well as which SOPs act to serve other SOPs. Figure 5.3 shows an example.

118  Developing an ISO 13485–Certifi ed QMS

The previous diagram is a high-level sketch of what your process archi- tecture could look like. In the diagram, the typical SOPs are divided into four groups (from bottom to top in the diagram): 1) Essentials, 2) Resources, 3) Requirements, and 4) Critical path of core SOPs you run on top of the rest. We will go through each SOP separately in the coming sections. You could decide to segment your QMS differently, but if this model makes sense for your setup, you can use it as a basis for your work here. You can always return to the diagram later as you are finishing your SOPs.

Section 5.2.8 will present another way to look at your SOPs, this time taking a true bottom-up approach building a view of the links between your SOPs as declared in the SOPs themselves. Both views offer practical aids for figuring out your QMS processes. The first diagram gives a great overview of your processes to a new reader, while the diagram presented later in Section 5.2.8 will be practical for maintaining your SOPs through the periodic docu- ment review process.

In this section, we are focusing on writing your quality manual, and the SOPs themselves will be written starting from Section 6. I therefore suggest that for the now, you leave this section somewhat open and return to it after Section 19. The checklist at the end of that section will remind you to do so. Alternatively, you can start drafting a high-level sketch of your processes here, but realize that you may want to edit that a little bit later.

After introducing the high-level network of processes, I would present the processes themselves in a way that roughly matches the clause structure of the standard. Instead of long-winded discussion of each process or clause, I would introduce the principal SOPs that answer to the processes required by each clause of the standard. The goal of this description is thus twofold:

 Introduce all your individual SOPs as required by the standard and as may not always be achieved to the best effect by a high-level process network diagram, such as the one previously presented.

 Give those of your readers who are already familiar with the standard, such as your auditor or B2B customer, a solid landing zone or a menu into your QMS. This section will ensure that you cover all your required bases, but it may also act as a good starting point if you experience a sudden case of brain freeze during some meeting or audit.

I would, therefore, structure this section to generally follow the clauses of the standard, but I might depart from that in a few small ways. I would thus group my processes under the following fi ve headings.

Writing the Quality Manual  119

General QMS Requirements

This section roughly matches with Clause 4 of the standard. Here, I would explain that this quality manual sets up the relationship between your QMS, the standard, and the applicable regulations. Your commitment to maintain- ing an effective QMS in this context, and in the context of your organiza- tion’s role, is hopefully evident from the quality policy you have defi ned earlier, your subsequent QMS planning activities, and all your day-to-day activities since making that defi nition.

We already introduced the processes of your QMS and the network they make up using a chart of the overall network of processes. The essential document and process controls are instructed by SOP-1 and SOP-2, respec- tively. Your process-specific risk management activities (SOP-8) will address the control of these processes following a risk-based approach that places greater emphasis on the control of high-risk processes. Internal communi- cation is instructed in SOP-7 and post-market surveillance in SOP-12. The medical device file is a special type of a document that is instructed in SOP- 10. Regulatory affairs are instructed in SOP-11.

Management Responsibility

This section roughly matches with Clause 5 of the standard. Here, I would refer to the quality policy (Clause 5.3) contained in the manual as the basis of demonstrating management commitment (Clause 5.1), customer focus (Clause 5.2), and quality planning (Clause 5.4). For quality plan- ning, I would also refer to SOP-1, which instructs QMS planning and, among other subprocesses, the document review. I would further refer to the appendix of the manual on responsibilities, authorities, and even qualifications of personnel. Finally, audits and the management review are instructed in SOP-6.

Resource Management

This section roughly matches with Clause 6 of the standard. This consists of three main topics: management of infrastructure (SOP-3), management of human resources (SOP-4), and management of the work environment (also SOP-3). In addition, the provision of these resources is a topic, but unless you have a specific process for this, I would not invoke a specific SOP here but instead leave provision to the previously mentioned SOPs and the rel- evant activities defined under management responsibility. I also would bring

120  Developing an ISO 13485–Certifi ed QMS

up SOP-5 as the place for instructing supplier management and SOP-3 for instruction on software validation, both of which are required by Clause 4, but more logically handled here under resource management.

Product Realization

This section matches quite neatly with the massive Clause 7 of the standard. Here, I would refer to my SOP on product realization (SOP-10), which cov- ers most of the topics of this clause in the standard. In addition, I would link to SOP-7 for internal and customer-related communication, SOP-12 for post-market activities, SOP-8 for risk management, SOP-9 for clinical evi- dence, SOP-11 for regulatory affairs, and SOP-5 for purchasing and supplier management.

Measurement, Analysis, and Improvement

This section matches nicely with Clause 8 of the standard. Here, I would link to SOP-2 for monitoring, measurement, and CAPA. Customer feedback and the use of maintenance activity information is in SOP-7. In addition, I would link to SOP-10 for related product-realization activities and SOP-6 for audits and the management review.

5.2.7 Section G—References

If you have used references in your manual, include them here. The stan- dard does not require you to have references, but if you have used some books, extra standards, or documents to advise you, it is good to include them here so that you will also remember the documents when you are later revising the manual or, indeed, using the manual. You might, for example, want to mention this book that you are holding in your hand if you follow the advice it gives.

You may also reference the ISO 13485 standard, if you like, but that should pretty much be given from the purpose of the document in Section A of the manual.

5.2.8 Section H—Appendices

The use of appendices is entirely optional and not required by the standard. You could include all the necessary information in the body of the manual

Writing the Quality Manual  121

itself, but I find it is better to structure some of the content as self-contained appendices. This way, maintaining the information and referring to it from elsewhere is easier.

In this book, I would have you include three appendices to the manual:

 Staff responsibilities and qualifications by role  Quality objectives  Inter-process relationships

Let’s go through the appendices one by one. The use of appendices to cover this information is entirely optional, but the previously stated information does need to be somewhere in your QMS.

Appendix on Staff Responsibilities and Qualifications by Role

This is part of how you meet the requirement to ensure responsibilities and authorities are defined, documented, and communicated within your orga- nization (Clause 5.5.1), and the interrelation, independence, and authority of the personnel is addressed (Clause 5.5.1). Here, you can define all the key job titles in use at your organization, the qualifications required from the title holders, and the responsibilities and authorities of each. You may also define role-level substitutes here in case of holidays and absences, as this may come in quite handy when later running your QMS. Make sure that any substitutes you define also meet adequate qualifications for the role they are substituting for.

Keep the definitions simple. A list of a few bullet points for responsi- bilities, authorities, qualifications, and deputy arrangements will be suf- ficient. You can later use this information, for example, when you need to write announcements on open job positions. Having this information here will help ensure that you won’t hire someone without fi rst defi ning their job adequately—something which would be frowned upon by your auditors.

Appendix on Quality Objectives

The quality objectives were discussed in Section 5.2.3. The objectives could have been inserted into the body text in that section, but as that could easily get messy after a while, I prefer to place these into an appendix so that it is easier to edit them and refer to them from across the QMS.

Figure 5.4 Example of SOP-to-SOP links as a two-way table.

122  Developing an ISO 13485–Certifi ed QMS

Placing the objectives in an appendix also gives you the option to list the relevant quality indicators under each objective. This may lead to dupli- cation as you will in all likelihood be tracking those indicators using a registry, but having the indicators here will ease sharing information on what indicators you track should you need to do that. If you opt to use the register only for listing the indicators, make sure you can still prove their appropriate approval during assignment (e.g., via management review, Management Team minutes, or reports). See Section 5.3.2 for a checklist on objectives.

Appendix on Inter-Process Relationships

To me, this is the most interesting appendix out of the set—maybe because I was so chuffed to come up with the sneaky method for its creation. The list of associated SOPs (see Section 20.3.4) shown in each SOP will prove very handy when drawing up this diagram and, later, when keeping it up-to-date. This appendix, together with the diagram shown in Section 5.2.6, should give an excellent overview of your processes and the links between them, and thus, meet the requirements of the standard. The basic idea is that you can see which SOP refers to which SOP, and vice versa. Figure 5.4 shows a conceptual example where the SOPs referenced by each SOP are mapped out on each row.

This is basically the switchboard of your SOPs. You can use this appen- dix to figure out forward and backward connections between your SOPs when you are running the document review activity or when you are trying

Writing the Quality Manual  123

to see dependencies between SOPs for running CAPA activities, for example. You can look at the row for any given SOP to see what processes it links to and then look at the column for that SOP to see if any other processes link to it in addition. In this diagram, one-way links are further highlighted by using a white box marker for them, and a black-box marker for two-way links.

Drawing the previous diagram will be easy after you have written the SOPs. The section for using the SOP template (Section 20.3.4) presents a handy method for creating the diagram almost as an afterthought. It is not an afterthought, of course, as you will have been thinking about process dependencies carefully in writing the SOPs and, thus, also cre- ated the information to use here. As you will be figuring out the SOP linkages during writing the SOPs yourself, note that the previous fi gure is only conceptual in nature. The final diagram will be born out of the links you make. For now, only worry about writing the SOPs and making the links that make sense to you. The figure will almost sort itself out in the end.

5.2.9 Section I—Version History

A version history is something you should consider as an essential part of every significant QMS document from here on out. Note that I said “docu- ment” and not “record” here, although you are, of course, free to also item- ize changes in records.

The version history is a critically important part of QMS requirements. The version history may, for example, be recorded within the document itself, as an appendix, or in the metadata of the document in some docu- ment archival software. The version history information, along with who made what changes and when, must always be available. For lower-level records, it is enough that such version differences are retrievable (e.g., via comparing two archived versions of the record), but for actual key QMS documents, such as your quality manual and SOPs, these differences must be spelled out in a readily accessible way.

This section will come in handy during audits when you will need to quickly show how any one document has changed over time. Everyone else, too, at your organization who needs to work based on the changed document will appreciate the available history information to see what has changed and how it might affect their work. Having a version history may

124  Developing an ISO 13485–Certifi ed QMS

not let you off the hook on training your staff regarding the changes, but it will be a part of the overall solution to ensuring change does not go by unnoticed.

The requirement for version control is in Clauses 4.2.4 for documents and 4.2.5 for records.

5.3 Checklists for the Manual

Writing a quality manual doesn’t sound too bad, does it? The type of con- tent needed and the amount or structure of it is very manageable. The devil is, of course, in how you manage to write the manual so that it is relevant to your organization and meets all the requirements in a way that is also appropriate to your operations.

The following quick checklists look at your quality policy, your qual- ity objectives, and finally, your complete quality manual. The checklists are intended to help you in ensuring that you have addressed all the key requirements. If you get stuck in any of the checkboxes, return to the previ- ous discussion, in this section, for help.

5.3.1 Checklist for the Quality Policy

After finishing work on the quality policy, you can perform a quick check of your work using the following checklist (Table 5.3 ). The checklist contains the key items to tick for a quality policy, but it, of course, does not check the content of what you say in the policy. Once you are happy with the pol- icy, you may move to checking your quality objectives in the next section.

5.3.2 Checklist for the Quality Objectives

After finishing work on the quality objectives, you can perform a quick check of your work using the following checklist (Table 5.4). Notice that there is some necessary crosstalk here between the policy and the objec- tives. Once you are happy with the objectives, you may move to checking your full manual in the next section.

5.3.3 Checklist for the Finished Manual

The following checklist (Table 5.5) is intended to meet the requirements set in Clause 4.2.2 of the standard, which is dedicated to the quality manual,

Writing the Quality Manual  125

Table 5.3 Checklist for the Quality Policy Checklist

□ The quality policy is appropriate to your organization’s purpose Does the policy lead you to fulfill your purpose better?

□ The quality policy includes a commitment to requirements and an effective QMS Think about your customer, your product, your regulatory requirements, and your QMS.

□ The quality policy is in a language that is understandable to your personnel Make sure the language is appropriate and the message relatable to your audience.

□ The quality policy is understood to be reviewed Your policy must be reviewed by the management for continuing suitability.

□ Your quality objectives can be derived from your quality policy You can develop objectives that is based on this policy and that is covering the whole policy.

□ The quality objectives can be reviewed in relation to your quality policy Your QMS should provide a mechanism for reviewing the objectives and the policy.

□ You have top management approval for all the previous items Get some record of this (e.g., a signed statement or Management Team minutes).

Once you feel confident you have ticked every box, it’s time to move on.

Table 5.4 Checklist for the Quality Objectives

Checklist

□ Your objectives are consistent with the quality policy The objectives can be derived from the policy, and they cover it adequately.

□ Your objectives are measurable It is possible to define measurable indicators for each of (or at least most of) the objectives, and the objectives themself are not too abstract to be useful.

□ Your objectives cover QMS process requirements For example, the handling of issues detected in the efficiency of the QMS (including CAPA).

□ Your objectives cover product requirements For example, meeting customer requirements consistently.

□ Your objectives cover applicable regulatory requirements For example, notifications to regulatory authorities are handled as required.

□ Your objectives address the relevant functions within your organization Your objectives capture relevant operations at your organization.

□ Your objectives are established on relevant levels within your organization Your objectives capture information on a relevant level within your organization.

Once you feel confident you have ticked every box, it’s time to move on.

126  Developing an ISO 13485–Certifi ed QMS

Table 5.5 Checklist for the Finished Manual

Checklist

□ Your organization and product are introduced A general-level introduction to your organization and product(s) is given.

□ The role of the organization is defi ned For example, a manufacturer. Pay attention to regulations and how these may affect your role.

□ The scope of the QMS is defi ned For example, development, manufacturing, sales, and/or maintenance.

□ You have made the commitment of your top management clear Management is understood to support quality and QMS, and is committed to meeting the requirements. This should be evident in the text and in approvals of the text.

□ You have defined required key roles and responsibilities For example, top management, management representative, and quality manager. Remember to address any deputies and the interrelation of personnel who affect quality. See Section 4.4.4.

□ You have defined a quality policy and quality objectives You cleared the previous checklists. See Section 5.3.1 and Section 5.3.2.

□ The processes introduced by your QMS cover the standard For example, D&D, production, distribution, installation, and disposal. See Section 5.2.6 for help.

□ Any excluded processes are given an acceptable rationale If a process is required by the standard, you can only exclude it with a very good reason (see Section 3.8). Also pay attention to regulatory requirements.

□ The application of your processes makes sense for your organization The application of processes makes sense throughout your organization under its defi ned role.

□ In introducing each process, you also link to the relevant SOP. You may not be able to do this until after writing the SOPs in Section 6, but remember to come back here then. The SOP checklists will remind you to do so.

□ You don’t claim you aren’t responsible for some process You can outsource a process, but you can’t outsource the responsibility for it.

□ The processes are prioritized somehow You apply a risk-based approach to the control of processes.

□ The inter-process relationships are described in a practical way You describe the sequence and interaction between processes in a meaningful way.

□ You have outlined the structure of your documentation You provide a conceptual overview of your QMS documentation.

Writing the Quality Manual  127

Table 5.5 (Continued) Checklist for the Finished Manual

Checklist

□ You have defined the document and record retainment periods Beware of regulations that may be stricter than the two-year minimum of the standard.

□ You have enough resources to carry out what you have instructed Don’t fall victim of specifying here more than you can cope with. See Section 3.1.

□ Regulatory requirements are incorporated You probably can’t list the requirements separately, but make sure you know what the requirements are and that you are complying with them. Pay attention to different jurisdictions if this is relevant to your context.

□ If you use the terms “shall”, “should”, “may”, and “can”, these are used in the same sense as the standard uses them.

Once you feel confident you have ticked every box, it’s time to move on.

but it also addresses further requirements introduced in the other clauses of the standard.

5.4 That’s It?

Congratulations! You have now successfully finished your almost-print-ready quality manual. This was no small feat to do. You may still have some gaps in the manual that can’t be filled in before you finish writing the SOPs in the next sections, but that aside, you can now take pleasure in having com- pleted a significant portion of your QMS. In some bygone years, this could even have been enough for you to run your QMS, but today, you have a good number of requirements to still tackle in your SOPs. Let’s look at those SOP-by-SOP in a little while, but let’s first start with what are the general expectations for a standard operating procedure (SOP).