brad-gilbertson.com

The first anti-bureaucracy therapy is The Operating Fiction Of Linear Thinking. If your troops learn this concept and practice it religiously, the FDA will like you, and your Quality System is less likely to grow into a writhing mass of poisonous, strangling, bureaucratic tentacles.

First, let’s nail down some ideas, so we can use them in this post, and others to follow.

What FDA wants is to know the following:

· You took the trouble to understand what behaviors and characteristics your product is to exhibit. You also know why you didn’t choose some behaviors or characteristics.

· Your processes are very highly likely to identify errors soon after they occur, including when making changes during development or manufacture. Also, you can prove it.

· Using your processes, you are very highly likely to devote your effort towards more important stuff than less important stuff.

· Somebody who doesn’t already know all your stuff can understand it, at least the high level, without having to live with you. Not only that, but this hypothetical observer will be able to learn this material in the course of an inspection, which usually lasts a few days.

I call this last point “Maintaining The Operating Fiction Of Linear Thinking.” The way many folks will talk about the requirements listed above will make you think that you’re required to actually do your work in a linear way. This is not true. They just want to understand your stuff in the limited time available.

When you’re creating plans, requirements, and designs (records of what you will do), and other documents such as test protocols and test results (records of what you did), FDA wants you to structure your material to tell a story.

So, here’s a metaphor: Think of how movies are made:

· First, there’s a “treatment”, which is a summary of what the movie will be like

· There’s a screenplay, which contains dialogue and basic elements of scenes

· Storyboards lay out the visuals of scenes

· A host of other documents describe costumes, props, and other materials

· Filming starts. This is the first place where The Operating Fiction Of Linear Thinking begins to manifest.

· After filming, the movie is edited. This is where The Operating Fiction Of Linear Thinking shines.

Let’s take the example of Castaway, starring Tom Hanks. Remember the early parts of the movie, when Tom is chubby and clean shaven? Then, later in the movie, after he’s been spearing fish for like three years, he’s slender, fit, muscular, and bearded, with a head of long hair.

God, there’s no justice. My high-school classmate is rich and famous, and he has his hair. Can you believe it?

Anyway, you could imagine that the director might have filmed the end of the movie first, so that Tom could have a couple of years to grow his hair and get ripped. Then, after filming, they could take six months to fatten the man, and give him a haircut. Okay, he could get the haircut any time, but hey, you know what I mean.

After all that mixed filming, the editing process would bring the movie together, to create the illusion that the narrative and filming occurred in the same order.

Having said all this, I cannot tell a lie. They actually filmed the movie in the same order as the major events, ie fat first, and muscles later.

I had you going, though, didn’t I? And you got the point!

When to apply The Operating Fiction Of Linear Thinking

This concept is an opportunity to replace Quality System content with skills. If you develop a cultural imperative to apply the concept, or create some training materials to inject the skill into the genetic code of your practitioners’ brain cells, then you can lighten up the amount of material you have to write to support each Quality System component. The troops are more likely to do a good job without detailed instructions.

The problem is that, if poor practices take hold, and your company attracts the attention of the agency, it’s a slippery slope to writing bigger and more complex procedures. One of the temptations is to try to legislate judgment by making perfecting the rules of engagement. While such an approach is theoretically possible, it’s very expensive and difficult, requiring a very high level of skill on the part of your procedures authors.

Wouldn’t it be cool if you could make your troops smart enough that they wouldn’t need detailed instructions for some common activities, such as writing?

Any writing that describes intended activities, or past events and activities, or their impacts, is a good candidate for the Tao Of The Operating Fiction Of Linear Thinking. Below, I’ve included some candidates. Please recognize that I haven’t exercised the fictitious examples for perfect writing and scenario construction, I’m just trying to make a helpful point about what issues to expose.

· Defect reports – During development testing or final Design Verification (not implying a process here, just putting the term “defect report” in context), your tester or other symptom observer may not have realized the actual behavior at the time it occurred. Maybe the person who investigated for cause was able to refine the or correct the description of the failure. In any case, provided you have an audit trail that lets each reader easily find or reconstruct the original description, it’s okay to go back and re-describe the description of the symptom, or investigation, or action plan so that a reader can make the mental connections among symptoms, causes, possible impacts to patients and on-market products, and the mitigations for those causes and impacts.

A defect report is a good example of how teaching the Tao Of The Operating Fiction Of Linear Thinking helps simplify your Quality System. If the troops know how the audience will think when reading defect reports, then they’ll do a good job of writing them. You won’t have to write a tutorial on defect reports as a CAPA for a 483 about your tortuous and garbled defect reports.

· Impact statements for on-market defect reports – your company may call this concept any of a number of different names, but if you have complaints against your device, you’ll have to assess the impact of your problem against your DMR, DHF, inventory, and installed base.

If you can afford a computer system that automates impact assessments, then you don’t need to worry about good authorship for them, but what if your company is too small, or too young, to afford the kind of systems analysis and software that such a system requires?

If the troops all understand the Tao Of The Operating Fiction Of Linear Thinking, then a “best practices” checklist might be all the support your Quality System needs in order produce acceptable impact statements. (I’m hoping to cover the pluses and minuses of checklists in another post, but for now, let’s just remember that, if a checklist is part of your Quality system, there will be a demand for checklist records that show every item to have a response, which can be onerous.)

If such a checklist is available, but not required, then an impact assessment author can write an understandable and complete description of what could be affected by the problem:

When the photon-density bracket fails due to accumulated cosmic irradiation, the gravity beam focus point is changed. The gravitron power sensor detects a change in the gravity beam power. The system reports an exception, then shuts down. Medical results are not affected, but there could be a delay of up to 1 hour in treatment or reporting for a procedure in progress.

Currently installed brackets that are not causing this gravitron power interruption can remain in service without harm to users or patients. Operations will do stock sweeps to remove and replace with rev B, any undelivered and field depot rev A brackets. For asymptomatic product units, a Field Service Bulletin will be issued (see Change Plan 42, task 3) to instruct Field Technicians to replace rev A brackets with rev B brackets at the next preventive maintenance visit.

Change Plan 42 introduces a modified bracket that withstands cosmic radiation for up to 14 years, instead of the current 6 month service life of the bracket.

Here’s what this fictitious example shows your inspector the following information, and demonstrates that you’re paying attention:

1. The condition(s) under which the problem occurs (accumulated cosmic irradiation)

2. The effect on the product in use (error message and shutdown)

3. The effect on operator and patient (delay of up to 1 hour, but no other medical effect)

4. Whether a latent hazard or problem is hiding in the field, waiting to harm customers.

5. How we’ll prevent this problem from recurring with parts already manufactured.

6. Because there’s a reference to a Change Plan, the inspector can see how the problem will be avoided for units not yet manufactured.

· Iterative development process – Unless your device’s method is well understood, you probably have a lot of feasibility development to do (OMG: If you’re a startup, your team might not yet even realize that getting the feasibility prototypes working are really the beginning of the work, not the end of it).

Your design team is going to make decisions based on data gathered during feasibility activities. Your QA folks are going to read the QSR, and conclude that FDA will regard data as suspect unless it was gathered in accordance with a pre-approved protocol (they don’t want business pressures to influence how the data were reported – they want the standards of success to be determined before the outcome must be interpreted).

So, fine, there’s a whole different proof-statement conversation about when to use characterizations and when to use Design Verification and Design Validation protocol execution results, and I’ll do another post on this topic. But, what about those situations where the original feasibility work was following a discovery path, and you’re pretty sure the data are solid, and you can’t afford to recreate the experiments later, just to satisfy a pre-approval requirement?

The key here will be to describe the rationale for using characterization data as a decision basis, and justify the rationale by showing that the characterization was rigorous. Or, maybe, using just the rigorously-derived outcomes as your decision basis. You’ll do this by writing up the informally-constituted steps that created the feasibility data, just as though there had been a pre-approved protocol in place, including expected and actual outcomes, the whole nine yards. In the introduction to this document, you’ll make clear that the material has been created in arrears. With a little forethought as to the acceptance standards for such a statement, your Quality System can allow the use of feasibility data as proof support for product design decisions or change impact determinations.

In conversation, your people will say “the gravity flux was not affected by the change because we were only changing the photo-density attachment bracket.” In a written description, each of the hidden assertions in this conversational tidbit will be parsed out and illuminated:

For the Anti-Gravity Generator to maintain the correct gravity field (see requirement 123.1), the gravity flux has to be X at time Y (see requirement 123.2). In March of 2008, prototypes 42 through 57 exhibited gravity flux of X in every experimental iteration (see pages 1001-5096 in redbook 456), irrespective whether the experimenter installed the production photo-density attachment bracket, part number 98765 rev A, or the experimental bracket, part number 1-98765, version 1.

Because this characterization study showed the gravity flux to be insensitive to differences in the photo-density attachment bracket when the gravity beam focus conformed to Gravity Beam Focus Specification, document 765, rev B, verification of the system with the modified photo-density attachment bracket, part number 98765 rev M, will consist of measuring the gravity beam focus in a shipment-ready Anti-Gravity Generator Subassembly, part number 91234, rev C. See Test Procedure 82, Gravity Beam Focus Measurement .

So what this quickly-crafted blurb says is

1. I know what the critical subsystem has to do (requirements), and how well it has to do those things (Critical Quality Attributes, CQAs, best expressed as requirements constraints, which are a subject of a different post).

2. In the past, somebody showed that the original part has been proven in the past to be interchangeable with other parts, without affecting the critical subsystem, provided that the CQAs are satisfied. This characterization was documented, including the inputs, procedure and outputs of it. The documentation is stored in a controlled location where I can prove that it hasn’t been lost or altered.

3. Here’s how I’ll use that historical information to devise a test of the modified part (this plan doesn’t involve setting up that horribly expensive Supernova With Black hole experiment we had to do during feasibility development). Now, I’ll just test the defining CQA using a procedure I’ve already approved, and that I can afford to use.

4. Without reading any other document, the reader can get a sense of the workflow, the intentions of the proof statement, and the level of rigor.

So, practice the Tao Of The Operating Fiction Of Linear Thinking. Focus more on what was challenged and proven and be careful to avoid concentrating only on from. The hidden philosophy in this idea is that your job is to ensure the outcome, and describe it in a way that someone else can visualize.

As with any mystical Tao, this one is not simple. With CAPA as an example, a moment of contemplation will lead you to realize that CAPAs need their whole record-investigate-risk-correction-corrective-action-preventive-action cycle to be executed. The point of this Tao is not that you can skip the thinking, is that your organization can run cleaner and lighter by communicating the thinking in a way that points the reader of your readers to real understanding of what happened and what the impact and significance of the events were.

Bureaucracy tends not to grow when the stakeholder groups, eg developers, testers, investigators, QA assessors, can develop justified confidence in each other.

So, emphasize outcomes and true understanding, not just the appearance of consistency.

1. 
   OrsonTheTechnoid said...
   10:27 am - January 4th, 2009

   Hi Brad -

   I heard your November talk at the Medical Device Software Development Conference in San Diego and like it a lot. Your sense of humor was great! I got some good points out of the DOORS discussion afterwards, too.

   I told my manager and Quality Assurance deparment about this ideal and we’re going to add it to our training.

   You need to publicize this blog more so that more people can read it. The only reason I found it was that I finally looked for you on LinkedIn.

   Cheers!

   OTT