brad-gilbertson.com

Long considered a normal part of life in most software environments, the information and control provided by good configuration management (“CM”) practices increase in value when CM includes all Design Inputs and Design Outputs.

In this post, I’m going to tell you that, if you intend to maintain your product through multiple updates, or will develop many products, you should consider integrating hardware and software CM in the Design History File (“DHF”), and that the resulting configurations should be made easy to design transfer to the Device Master Record (“DMR”).

In subsequent posts, I’m going to describe how to handle specific CM and document publication techniques to make this approach happen, plus show you an idea for world-class software CM. This post lays out some basics.

BTW, this posting will open a discussion of a particular approach to CM, but won’t provide a tutorial on the general subjects of CM and its close relative, version control.

Here’s a Wiki page on CM in general: http://en.wikipedia.org/wiki/Configuration_management

Why Should You Bother Considering These Ideas?

The goal is to create an environment where written procedures are necessary only at the highest level of your Quality system, and that the work that people do tends to be compliant with those procedures without a lot of bureaucratic overhead.

It’s not hard to meet this goal, of course, but you want more than this. You also want everybody in the company to have an easily-accessible source for all information about requirements, design, risk management, and part specifications for manufacturing. If your people have to do manual searches of paper to find the information they need, they eventually will stop bothering. If they rely on common LAN directories, you won’t really have your data under control. FDA is likely to notice, and send you a company greeting that starts with the digits “483”.

Basics

The basic purpose of CM is to ensure that you can always replicate a particular “version” of your system or other complex artifact. In this blog, of course, the focus is always on medical device systems. A system is composed of many components that can each have a different version. The combination of all these components and versions is a “configuration.” It’s easy to get buried in the terms “revision,” “version,” and “release.” In software teams, there is usually no difference in meaning. In hardware teams, the word “revision” means “a formally approved version,” and a “version” is “identifiable specific content.” For this blog, I’ll use the words “revision” and “version” interchangeably, and use the word “release” to mean “a controlled configuration.”

Most medical devices comprise both hardware and software, with many also using chemical disposables (for the purpose of this post, I’m going to refer to chemical components as hardware, which might make you scream in pain if you’re a chemist, but keeps this post simpler without sacrificing much information). Each of these technologies has components that can be version-controlled. As development progresses toward 510(k) clearance or PMA, and Design Transfer begins, good configuration management will provide attachment points for snapshots such as the following:

·        Requirements to be implemented in a Scrum sprint, or other development increment, depending on your process;

·        Impact assessments to justify limiting testing to a part of the product’s features or characteristics in support of an on-market or development-stage change;

·        Development prototype configurations used to build up characterization or launch justification data;

·        Pilot configurations, including bills of material (BOMs), manufacturing methods, test methods, purchase specifications and other Design Transfer outputs.

The problem space for software is still somewhat different than for multi-technology systems, because:

·        Software tends to be more complicated, with more parts, than other technologies (see my Gleick On Software page);

·        Software lends itself very readily to automated controls and management, because the tools used to design and implement it were developed by people who are highly sensitized to software CM;

·        Folks who are more used to managing hardware are not as familiar with CM concepts and practices as are their software engineering counterparts.

The Tower Of Babel

It’s not a trivial question to consider pulling all your DHF artifacts into a single CM model. Each engineering and business discipline has its own toolkit, and the toolkits may integrate poorly, or be expensive to integrate.

All your manufacturing information will probably be contained in an Enterprise Requirements Planning system (“ERP”) and/or a Product Lifecycle Management System (“PLM”). Depending on your vendor, these two systems will probably represent everything as Bills Of Material. Their job is to manage changes to the versions to components, and track configurations. Manufacturing folks will use ERP to know what they’re building today. Hardware developers will use PLM to conglomerate hardware configurations into BOMs that can be handed off to the Design Transfer.

All the mechanical designs will be done in a mechanical CAD system, and electronics will be done in one or more electronics CAD systems (for schematics, board layouts, FPGA IP modules, and fabrication specifications) that may, or not, have their own version control and CM vaults. Software requirements and designs may be developed in a computer-aided software engineering system (“CASE”), and one or more interactive development environments (“IDEs”) that may also have independent repositories.

Source code might live in a software CM system, such as my favorite, Perforce, or Visual Studio, or one of the various freeware systems.

Don’t forget systems requirements; it’s not unlikely you have those stored, or at least their traceability managed, with a database system such as DOORS.

Thus, you have the problem of relating together the content of all these different repositories. You have this problem as soon as there’s a product complaint with a non-obvious cause, or when an FDA inspector shows up at your door. Although it depends on your scope of operations and the complexity of your device, you can raise your total capability, and dramatically reduce your risk of inconsistencies among Design Inputs and Design Outputs, by keeping track of all this stuff with a single tool.

Find An Appropriate Binding Platform, Such As A PLM System

My model for integrating the DHF and DMR uses a PLM system as the hub around which all information sources revolve. Development, and sustaining production changes, are entered into PLM as Change Requests (“CR”), each of which contains a statement of what has to be changed (the “Change Plan,” or “CP”).  The Change Plan can be either simple or complex, depending on the change, but the PLM system tracks each task and displays the artifacts that complete it. For example, if the task is “update a subassembly drawing”, it is completed by attaching an electronically approved drawing and the electronic change order (“CO”) that approved it. BOM relationships are approved as part of executing CO’s.

This is a good thing because all these drawings and approvals are electronically communicated to the ERP system when approved. Just thinking about the PLM end of things, the process looks like this:

Development Artifact=>CO=>Task=>Change Plan=>CR completed

(For each CO)          CO=>development BOM=>test=>CO=>production BOM

Each CO makes a version of a development part or a production part. For product tracking, an entire software release is modeled as a single part. In my particular case, each new release gets its own part number, because my product family needed to track software releases through field service, and maintain different instrument configurations in the field.

What I did was to create a PLM structure, modeled as a BOM, for each product’s DHF and DMR:

 Sorry for the grainy appearance – I’m still working on optimizing my Visio diagrams against the blog theme. Here’s a PDF of the diagram you can view: Integrated DHF & DMR

How It Comes Together

So, the product-description part of the DHF is a configuration-managed BOM, as is the product’s DMR. The artifacts contained in the DHF are the outputs of all the CAD and CASE tools described above.

Project members use the PLM system’s Change Order procedure to post development artifacts to the DHF, as part of the CR process shown above. Then the same Change Order process moves various parts and software releases into the DMR as a Design transfer activity, including whatever manufacturing processes are needed, when projects show that those parts and software releases are ready for market.

Some caveats and costs are:

·        Capital costs of enterprise platforms

·        Support costs of enterprise platforms

·        Systems analysis to ensure that your plan takes your entire process into account and has a growth path built in

The downside of this approach is that you need a strategic systems thinker in charge of the initial implementation, and that person needs to understand how your company works. PLM and ERP vendors may not provide this insight during the integration process, because they may have a plan in mind when they show up at your door.  Without a good internal strategist, you have a risk of buying what the vendor wants to sell you, instead of what you actually need.

The major benefits of this approach are:

·        Train everybody in the company on only one system

·        Global access to DHF and DMR information – supports knowledge-sharing and concurrent compliance assessment

·        Easy to integrate with ERP

·        Easy to maintain auditability, without a complex body of procedures

·        Removes the temptation to create multiple processes where one will do the job

·        If your company uses common parts among products, or develops derivative products, the total effort to design, implement, and test is reduced, because development and V&V efforts are not duplicated. Further, it’s easy to justify not doing that redundant work when the various information dependencies are baked in at the time of initial approval

·        With this model, it’s relatively easy for development projects and sustaining engineering to use the same design control practices and knowledge base, which helps prevent unintended effects of changes by putting your products’ design history and critical quality attributes front and center.

The Bottom Line

You can build a DHF-DMR structure that enables your development and sustaining engineers to concentrate on doing the real work, and get compliant document maintenance as a side effect. Your company and product line can grow quite extensively without accompanying increases in complexity. It’s analogous to what any database admin can tell you: a theoretically correct initial model will reduce the total cost over ownership – of your entire company, in this case! – including maintenance.

I’ll bring in more details in future posts to show how you supporting systems and even manual (ugh!) procedures can use CM to keep your troops’ eyes on the prize, and still hold the Bureaucracy Virus at bay.

Thanks for reading!

Brad