Handling Development in a Medical Device World (Part 2)

So what went wrong during this audit? The obvious and most simple answer is that I wasn’t prepared. Yet, even as I reflect, to this day I’m not entirely sure what the auditor wanted to know. The project manager was irritated with me for not understanding the questioning, yes, but what was the problem here? Why did the project manager assume I didn’t know how to do whatever my boss told me to do?
The real problem, of course, was our process. As my bleary eyes could attest, we had stacks of procedures in place. We had the training. Someone had worked very hard to come up with all the “stuff” needed to state how this project would be designed and developed per the requirements of the CFR.

But there was a big piece missing: Application of the procedures.

I wasn’t necessarily doing anything wrong. I was just doing whatever my boss told me to do. That’s a good thing, right? And my boss was doing whatever her boss told her to do. Also good, right?

Well, not really. None of us were doing what our very own Standard Operating Procedures, written by us, for us, told us to do. The auditors dinged us for not following our own system! We knew about the CFR, and we knew procedures had to be created in order to satisfy it. But we weren’t thinking in very practical terms.

21 CFR 820 covers quality system regulation for medical devices (and software medical devices). Also known as the Quality System Regulation outlines Current Good Manufacturing Practice regulations that govern design and development of a software medical device (but you already knew that). It tells us a lot about the controls we need to implement as a part of our quality system, but it doesn’t give us many concrete examples or specifics on how to best apply it.

Whether or not you decide you actually need standard operating procedures, i.e., a number of procedures that reside somewhere in some files named “such and such an SOP,” is a decision that is up to the organization. Regardless, it is necessary to have certain procedures laid out that explain how all these quality system requirements are actually performed. To that end, I can think of two ways to write standard operating procedures, each of which has its place (and for the purposes of this article, I am writing only in terms of software development projects).

The first approach is to tailor a number of procedures in a way that is specific to the project. In this way we can handle changing technologies and environments. Over time, as things change, it will undoubtedly be necessary to revisit all of the SOPs. An even bigger problem is that this approach doesn’t lend itself to a “one size fits all” set to SOPs, and they become a procedural and documentation nightmare. This approach is fine for a small environment with only a few concurrent software projects with similar environments, but it won’t scale well for more extensive corporate needs.

A more practical approach, in my humble opinion, is to create SOPs so that they are environment and technology agnostic. This way, at least for all of the software medical devices that are being designed and developed, we do have a set of procedures that make sense and remain relevant for more general and longer lasting usage. This leads to a different approach to handling software project management. These high-level SOPs, of course, are not very pragmatic on their own (and this is a good thing!). They need another layer so that they may be applied in some practical way.

In this second approach, we no longer technically constrained by the procedures that we worked so hard to put in place. No longer do we lean toward using a single version control system, database, ticketing system or tool simply because it would be too difficult to refine our SOPs. Our SOPs no longer state what we must use; they simply state what we must do. If any SOP ever prevents efficient software design and development by prohibiting the ability to utilize changing technologies and practices, it is a bad SOP.

Over the years I’ve worked with many good developers who view “process” as a dirty word. I don’t blame them. All too often we let our processes become so cumbersome that they don’t serve any real purpose other than to frustrate those who are forced to work within their confines. In such a situation, the processes are sidestepped, rendering them useless.

So how do we make a good process? How do we make use of SOPs in a way that serves rather than restricts productivity and good design?

The answer is this: We let our standard operating procedures serve as guidelines and we create work instructions on a per-project level that explain the actual (and practical) use of those guidelines. This is done (at least as comprehensively as possible) during our project planning. It is at the project level that we state which corporate-wide SOPs apply to this project and how we will apply them. This means that for a given SOP we must have one or several work instructions explaining how we implement them, what applications are used, how to use those applications and when to use them. Where a design control SOP states “versioning control is used for source code,” our project plan (or configuration management plan) states “Subversion is used for source code version control. The repository for project X resides at…”

With so much involved, hopefully it is clear why the project plan should include detailed work instructions to help us make sense and real application of our procedures.

Remember my story about being interviewed during the audit? Sure, I had read the SOPs, but I didn’t really know how they applied. This is because the SOPs (in this case) provided a high level of design control, but the practical application lived only in the heads of those who happened to be using the tools for the project. And even when, by luck, and SOP was followed, it was only because the approach being taken happened to be in line with a general guidance and not with the specifics of any work instruction. Those SOPs provided little more than lip service to the CFR.

It all comes down to this: A standard operating procedure is useless if it has no concrete application. Without an understandable and usable means of application, an SOP is just an annoying piece of paper that will cause headaches down the road.

Our work instructions point us to the specifics on how and when to use Redmine, Subversion and Hudson (continuous integration builds, later in this article). Essentially, the standard operating procedures can be thought of as a framework, and the work instructions the implementation. And these work instructions should allow us to use the technology available to make our processes not only applicable, but effective and helpful. We mustn’t think of these procedures as a roadblock to our work—On the contrary, they should make our work more efficient. If they do not, we are going about things in the wrong way.