Your Signature, Please:  Approving Design Outputs

Failure to have a good procedure in place for signatures and approvals can slow you down.

David A. Vogel, PhD
Intertech Engineering Associates

The following example is completely fictitious, and is not meant to represent any single company. Regardless, a healthy percentage of readers will be uneasy as they recognize elements of this story in what occurs in their own workplace.

The Rise and Fall of a Design Control Process

“AllBetter Devices,” a medical device manufacturer, recently put in place corporate policies and procedures to comply with the FDA’s design control regulations (21 CFR 820.30). The procedures outline the activities and documentation required to meet the regulation, and they detail the templates for the cover sheets for the documentation. Each document that is created must be “approved,” and signatures are affixed to the cover sheet for each document to evidence the approval.  

As the interested parties at AllBetter developed their design control polices and procedures, the topic of signatures and approvals came up for each document. To “play it safe,” AllBetter management decided that, with a few exceptions, all the company’s “stakeholders” in the development of the device should be approvers on each design output. Certainly, they thought, this would be just what the regulatory agencies would want to see to convince them that the design and development process was well controlled, and that all interested parties in the company were in agreement with the design as it progressed through its lifecycle.

AllBetter started its first product design and development project after gaining corporate acceptance of the new policies and procedures. The team was enthusiastic to use the new procedures and to finally “do things right.” The systematic process would produce documentation at each phase of the development lifecycle that would be reviewed, approved and “signed off” before moving into the next phase. No longer would AllBetter allow itself to develop products in an ad hoc, random walk manner. It would never have to retro-document a project just before release to make it look like the company had followed a controlled design process. Nobody liked retro-documenting. It was boring; it seemed like a waste of time; and it didn’t feel like it was an honest thing to do. This process should be so much better.

It didn’t take long for the new design control process to begin to unravel. Engineering didn’t want to approve and sign the Product Requirements Definition (PRD) until it had time to think about the requirements in more detail to be sure the device would be easy to implement. The team held off the engineering signature until it could think through some of the more detailed electronics and software requirements. After all, the engineering professionals didn’t want to be on record that they had “approved” the product requirements only to find out later that they couldn’t implement them. That certainly wouldn’t look good for engineering.  

The head of quality assurance for the project didn’t want to sign the PRD until everyone else had signed. After all, knowing that the engineering team was still tinkering with the requirements and that it already was well into the next phase of the development lifecycle put the team out of compliance with its own procedures. Withholding Quality’s approval and signature was a way of telegraphing the team’s displeasure with the way the project was progressing.

Marketing didn’t want to sign the PRD yet. Two of the features that truly would sell the device were related to how fast the AllBetter-2 could actually make a patient, well, all better. If—when Engineering finally signed the PRD—the team changed the performance requirement to say it would be no faster than the AllBetter-1, the company would never sell as many as desired.

Almost everyone had a reason not to sign the PRD except the author, who felt the PRD was a real work of art and should be approved in record time. However, after Engineering, Quality, Marketing and Clinical rewrote sections of the PRD, even the author didn’t want to sign the PRD. It no longer was his document. It wasn’t his writing, and he didn’t like their writing style. Signing as the author might mean that he would take the criticism in the future for poor thinking and poor writing in this document.

Six weeks later, the PRD was approved with all signatures affixed, but only after corporate management threatened to withhold annual bonuses unless the PRD was signed and moved to the next phase of the lifecycle. Unfortunately, by the time the PRD was approved, the engineering team had already written about 80% of the detailed software and hardware requirements (or specifications). Several of the engineers who were skeptical of the new procedures fell back to their old habits and started writing software before the software requirements had been approved—and they completely skipped the software design description required by their development process. Their rationale was that the PRD experience had confirmed their skepticism, so they would develop products as only they knew how. Managers looked at how long the approval process took for the PRD and extrapolated that for all documents required in the development process. They realized that the project would be two years late if they followed the approval process to the letter. They condoned the non-compliant behavior in the interest of getting a product to market.

A number of product requirements changes were made between the first release of the PRD for review and the version that ultimately was approved. Unfortunately, very few of the changes actually were implemented because engineering was “way ahead of those guys” and couldn’t “wait for them to make up their minds.”   

Subsequent verification testing caught the fact that a number of requirements were missing from the product. Unfortunately, reworking the design to include these requirements was very expensive because the software was so complex. Changes late in development carried a risk that they might break something else that they didn’t intend to change. In fact, it was so expensive, the team decided to not include a number of product requirements just because of cost and schedule concerns.  

Some changes were made, which, unfortunately, resulted in some defects that made their way into the field and led to a costly recall and regulatory attention.

What Happened?  

Weren’t these design controls supposed to prevent this kind of outcome?

Actually several things happened in this story: a process out of control, in-fighting and positioning among the development team, poor regression testing, etc. However, what triggered the sequence of events that lead to the unraveling of the design control process was the time it took to get the signatures on the very first document produced in the development process. Development teams are expected to work to meet scheduled milestones and releases. In many design control processes, they also are expected to wait for approval of the outputs of a given lifecycle phase before proceeding to the next phase. It’s impossible to meet schedules and wait for approvals that cumulatively can take up 50% of the development schedule to collect. It is common for development teams to discuss making corrections to a document—only to reject the idea because they don’t want to take on the approval process.

With all this in mind, let’s examine the approval and subsequent signature process and how it might be better defined and streamlined in corporate procedures. It is not the author’s intent to assign blame for failed design control processes to a flawed approval and signature procedure. There are plenty of reasons these processes fail; the signature process is only one.  However, the signature process is one “failure mode” that is rather easily fixed if given proper understanding and attention.

What Is a Signature? How Important Is It?

A signature in the context of a design control process simply is hard evidence that the person to whom the signature belongs has “approved” the document to which the signature is affixed. The signature is secure in the sense that it is not easily copied and usually can be detected if someone tries to do so. The problem discussed earlier really is not with the signatures themselves, but in collecting the signatures and convincing approvers to find time in their busy schedules to do their critical reviews of a document prior to affixing their signatures.

So a signature implies approval. What does approval mean? In the design control regulations, the FDA only notes that “design output shall be documented, reviewed, and approved before release. This approval, including the date and signature of the individual(s) approving the output, shall be documented.”   

An approval, presumably, is the result of some review of a design output. Who the approvers are, and what they are approving, are not specified by the FDA and are up to each manufacturer to determine as appropriate for its own situation. The Management Responsibility section of the Quality System Regulations (QSRs) makes it clear that the manufacturer needs to define the responsibilities and authorities related to work assessments (approvals):

“Each manufacturer shall establish the appropriate responsibility, authority, and interrelation of all personnel who manage, perform, and assess work affecting quality, and provide the independence and authority necessary to perform these tasks.” (21 CFR 820.20 – b – 1)

Since approvals and work assessments are required by the QSRs, failure to adequately fulfill the requirements renders a device adulterated, according to the regulations. Adulterated devices and the individuals responsible for the failure to comply with the regulations are subject to regulatory action, which may include removal of the device from the market, fines and penalties to the corporation and civil and criminal actions against individuals. Needless to say, there is plenty of incentive to take those signatures seriously.

What Was Wrong With the Approval Process?

Going back to our hypothetical situation, AllBetter Devices had several problems in its quality system related to approvals and signatures:  

1. Too many approvers and signatures. The decision to “play it safe” and include all device stakeholders as approvers of all documents actually hurt the company. Many of the documents required approvals from disciplines that would not have much to contribute in the review of technical document. For example, what would a clinical specialist or marketing manager have to offer in reviewing a detailed software design specification? Requiring an approval in this case does not do much to build one’s confidence in the design output. Asking someone to do so probably would just result in procrastination.

2. Unclear instructions and goals for approvers. AllBetter’s procedures treated all approvers as equals. Either management expected a similar level of review from all approvers or thought the different approaches to the approval would be obvious to the different disciplines. Regardless, vague instructions for the approvers and unclear goals for their review and approval activities also encouraged procrastination if the approvers overestimated what was expected. If they underestimated what was expected, they would produce a poor outcome.  

3. Allowing delayed signatures. Waiting for Engineering to determine what it could conveniently implement before setting the requirement was poor practice. Instead, the requirement should specify what is needed to meet the user (or other) need, not what is convenient to design. Certainly, holding up approval on a document for this activity should be forbidden. Too often, companies fear revising documents simply because the approval/signature process is so painful. AllBetter’s delayed signatures backed up the entire quality system, causing it to collapse.

4. Approving and signing under duress. AllBetter’s approvers finally signed off on the PRD when their bonuses were threatened. There is a good likelihood that some (or many) of them never actually reviewed the document before they signed it to protect their bonuses—even though they held up the process for their review. They may or may not have been aware of the potential personal liabilities associated with this activity. Regardless, they probably didn’t feel threatened, since each approver essentially was an equal. They all depended on “the other guy” to do the review.

5. Allowing “signature sniping.” Let’s face it—demanding to be the last signer on a document is a power play. Approval of design outputs is a serious business and should be above the gamesmanship of arguing over whose opinion or time is more valuable.

Designing a Value-Added Approval/Signature Process

There may be some art and science involved in creating a good approval process, but mostly it is just common sense. Careful deliberation over the following points will lead to a streamlined approval process that will actually add value to the development process and will not become the bottleneck that destroys the quality system.

• Design an approval plan. Few documents need to be reviewed by everyone, and few approvers need to approve every document. Don’t require an approval from a stakeholder unless that stakeholder will have valuable domain knowledge to contribute to the design output. In general, early phase documents related to the definition of the product will benefit from a larger list of approvers. Detailed technical documents will have a much smaller list of stakeholders—those who will contribute valuable feedback and will understand the document. Don’t add approvers to “play it safe.” Too many approvers can destroy your process.

The design of an approval plan can be thought of as a cycle of responsibility for the design of the product. Clinicians and marketing departments with knowledge of the clinical, market and user needs should approve the product-level requirements. Regulatory Compliance, Legal, Service and Engineering all will have their opinions about the product requirements, too. In the middle phases of the development lifecycle, few groups other than engineering will have an opinion about design details such as data structures, choice of integrated circuits, etc. There is little value added in burdening people with approving documents that they won’t be able to critically review. Near the end of the lifecycle, as device validation is underway, the group that helped define and approve the product requirements also should be involved in reviewing and approving the validation tests and results that confirm that the device meets the needs of the various stakeholders.    

In addition to the breadth of approver coverage, the corporate position of the approver also should be considered. Does a vice president need to approve every document in the design history file?  A well-thought-out approval plan will place the signature responsibility at the level in the corporate hierarchy that the approver can critically review and approve the design output. At a minimum, executive management should be required to approve documents such as validation reports and risk management summaries so that they have a clear understanding of any residual risks in a device going to market.

An approval plan also should include a definition of responsibilities and authorities that go along with the approval power. Some plans include an escalation process for when consensus cannot be reached among the delegated approvers.

• Provide training for the approvers. Approvers should be trained to understand the potential impact on the device design and, ultimately, on the users of the device if they don’t take their approval responsibilities seriously. Approvers also need to be made aware of the potentially destructive effects of regulatory action on the company and on them as individuals if they fraudulently sign a document, or if they allow design errors to slip through because they don’t take their approval responsibilities seriously. The intent of this training is to inform approvers of how the quality system depends on their expertise in the approval process and to help them understand the potentially devastating effects of an inadequate review process on end-users, the company, co-workers and the approver him- or herself. By giving the approver a clear sense of responsibility and liability for the approval process, he or she may be more likely to treat the responsibility seriously and less likely to sign under duress.

• Set clear expectations for what the quality system expects from each approver. It is quite possible that no two approvers should look at a design output for the same thing. Make it explicitly clear to each approver what his/her signature is assumed to mean. Consider adding a short statement next to each approver’s signature that clarifies for what aspect of the approval the signer is taking responsibility. For example, next to the marketing department’s signature the signature page may state: “Marketing approval implies that this document has been reviewed for meeting the needs of the market, for competitiveness and salability of the finished product.” Note that marketing is not expected to review the document to determine if the design is error-free, or if it meets all clinical needs, or if it interferes with competitors’ patented features. Presumably that level of review is being done by other approvers. The meaning behind the signatures will depend on who is on the approval team.

• Design an approval procedure. By making approvals part of a well-defined procedure, it will help eliminate approval delays. An approval procedure should allow adequate time for the approver to review the design output on his/her own. A review should be held with all approvers to compare their individual review notes. Action items should be identified that will resolve all issues raised by the approvers. The individual/group review process may need to iterate but should end in a final approval meeting where all approvers sign the document at the same time. This eliminates “signature sniping” and changes a nearly serial approval process into a parallel process that takes less calendar time.

Wrapping Up

Approvals and signatures often are not given the careful consideration they deserve. A poor or nonexistent approval process actually can dismantle a design control system and delay completion of the project. Proper training for what is expected of reviewers will give them incentive to do a thorough review for approval. Clear guidelines for the specific approval activity expected of an approver may reduce the perceived magnitude of the task, making it less likely to be a target of procrastination. A systematic approval process with approvers working together and in parallel will further streamline the collection of signatures.

Dr. David Vogel is president and founder of Intertech Engineering Associates, Inc. of Westwood, MA. Intertech has served the medical device industry since 1982, providing product development and validation services. Intertech also trains and advises clients on both technical and regulatory matters. For more information, visit www.inea.com.