Engineering Change Request/Order (ECR/ECO) or Document Change Request/Order (DCR/DCO)

[Marquee05]

I work for a mid-sized medical device manufacturer and am the sole documentation specialist for the organization. We have a difference of opinion on whether our change control documents should be called Engineering Change Request/Order (ECR/ECO) or Document Change Request/Order (DCR/DCO).

The rationale for ECO is that it seems to be the familiar term used by larger medical device companies while the DCO would be more appropriate for changes made outside the engineering area, such as Marketing, Finance, etc. which have nothing to do with Engineering.

Is one more appropriate than the other for a Medical Device Manufacturer? We are currently using ECO and all our documentation references that.

Thank you.

[AndyN]

I tend to favor the idea of keeping two systems. The ECO is appropriate for product - the changes are often the result of a more rigorous process controls.

A DCR (or similar) is good, IMHO, for the 'lesser' documentation you mentioned, including QMS documents. I'd recommend you use both processes.

[Frank T.]

Would it not be easier to call it a change request/order and have some sort of check box that differentiates the two.

Although I am not familiar with Medical Device manufacturing, my philosophy is to K.I.S.

[ScottK]

I also keep two systems but defined them differently than Andy...

ECO's are for engineering drawings. The CAD designer is the owner of the system.
DCR's are for everything else - procedures, external documents, forms, specifications, etc. DC Manager is the owner of that system.

When I came on board the ECO process was set up and functioning well, so I decided to leave it be and built the DCR system.

We are entertaining thoughts of consolidating them in the next year as drawings are really just another document.

[Kevin Mader]

I’m with Andy on this one, but I’ve seen this done both ways. It might be helpful to think about this topic in these contexts:

1. Engineering changes are more closely associated with design changes that include design and product level documentation. These documents support design requirements and specifications as part of Design Control. While they might be physically represented on paper spec sheets and drawings, they are product oriented and technical in nature.

2. Documentation changes are more closely associated with changes to documentation used to establish the QMS procedures. Less technical in nature and not product oriented. For instance, you do not need an independent reviewer to establish a change to a procedure where as you need one to make a design change/release.

This said - there is plenty of mud! A good example might be a design verification protocol. While the creation of a protocol will definitely tie into product documentation (e.g. design requirements specification), the document itself is created to support a QMS requirement. Many folks process a review of the protocol under the Document Control hat rather than the Design Control hat.

When folks have difficulty in determining which to process to use for a given change, they tend to perform the more rigorous review which is generally the design review using an independent reviewer. This might be viewed as overkill, but a safe (safer?) way out when reviewing a change. Keep in mind that while both processes are similar, there are enough differences in the contexts of what is reviewed and how changes are reviewed that, in my opinion, warrant keeping the control processes distinct.

Good question by the way.

Regards,

Kevin

[joshua_sx1]

For me, you can use either of two… and to make them more effective in your organization, you have to define their terminologies in your manual and/or procedures – meaning, document their meaning…

…so everybody involved shall have the same interpretation when dealing with your manual and/or procedures…

[Helmut Jilling]

In Reply to Parent Post by AndyN

I tend to favor the idea of keeping two systems. The ECO is appropriate for product - the changes are often the result of a more rigorous process controls.

A DCR (or similar) is good, IMHO, for the 'lesser' documentation you mentioned, including QMS documents. I'd recommend you use both processes.

I agree with bot Andy and Kevin. I would only point out a way to simplify the thinking.

All of them are doc changes. However, Engineering change requests are a subset, and frequently go much deeper, can impact product design, tooling, customer approval requirements, PPAPs, ...many more links and ripples.

So, most organizations have developed a specialized process for doc changes related to Engineering. The others can be done more simply.

[Kevin Mader]

Joshua – Yes. Operational definitions are important and key to improving communication within the organization and when communicating to outsiders (e.g. auditors). I’d say your comment on establishing a common language is good advice in all arenas.

Good point Helmut. I can say that even though we have fairly good operational definitions, folks in Engineering seemingly struggle the most with selecting the right process - design changes (special emphasis) vs. document changes (more general). Also of note, folks tend to migrate towards the simpler path (document control) even when the more robust (and involving the most effort) design change control process is warranted.

To ensure less frequent occurrences, I’ve instructed my team to advise on these matters throughout the design/product development process. We also do frequent DHF and DMR audits to ensure that proper reviews using the proper control processes have been followed upon project completion and throughout our sustaining efforts. We’re not perfect, but we have significantly improved.

Good discussion folks!

Regards,

Kevin