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.

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.

Would it not be easier to call it a change request/order (http://en.wikipedia.org/wiki/Change_request) 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.

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.

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

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…

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.

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

In my experience, either term is fine as long as you define the scope of what your ECO / DCR covers (e.g. if you call it a DCR and include non-document items, then just be sure to define that in your procedure). Training is the key - make sure your employees know how to use the form. Also, make sure your procedures are clearly written so regulatory agencies are also clear on how you're using them.

SandraD

I am trying to develop a DCR process, do you have an example of your request form?

I work for a medical device contract manufacturer and am struggling with this exact same issue... they want to use one form to capture all documentation changes. One thing I have not seen on any of the forms that I have been looking at on this site is one that would be specific to a meddev company--i.e. would capture review of risk analysis, validation, inventory, training requirements, customer notification.... can anyone out there help with examples? I'll share an example of what I have as soon as I finish it, but any help now would be greatly appreciated.

You all are the best!

Hi MBeth

I just noted your question from October of last year. I am currently in a similar situation with a start-up med diag company. I am looking for a template of an ECO Procedure and an ECO form that encompasses the necessary requirements. Did you come up with anything that you could share with me.

Many thanks

Laura

believe it or not, we're still working on it, but I will post what I have so far (with the confidential info omitted, of course). I'll get to it later today

:) These things always take more time that one thinks. Thanks.

Laura

I initiated a single form to try to capture any type of change I'll try to attach it here feel free ... i am finding now after using it for 2-3 years that i really need to split out the EC's and document changes just to get it moving through the sign off process simple little form changes should not have to go through the rigorousness of this process ... but defining what's what will be tricky - i'm also trying to find something simple to use for document changes versus EC changes ...

Just to put my 2 cents in... don't really have time to put all down of what I think... But here it is... Remember that this is a Quality System... it is always sugested that you only use a single system for any given operation. thus for any change, no matter what it is for, should follow a single system, within this system you can then seperate the Engineering changes with Document changes with a class rateing. Remember that engineering also creates documents such as assemby docs for mfg and other procedures. these are Engineerng controled documents, but if you put them under a DCR/DCO is means seperation of systems.
Mike