Document Controls - Input and Ideas - Small medical devices company

C

Chris Ford

Hi All,

Here's the scenario:

  • Very small establishment consisting of six employees, including the President.
  • The staff telecommutes from remote locations.
  • They are developing a Class III medical device - software only.
  • They currently store all documents electronically on a remote server.
  • They have no document controls in place.
  • No documents have been assigned numbers.
  • There is little to no revision control.

The staff consists of very intelligent scientists who are all very busy. They have no understanding of the quality system requirements, or a sense of document controls. They need a system that is very simple to use, that will not add a major burden to their work environment.

My Plan:

  1. Establish a very simple 4-digit numbering system with a document prefix (e.g. SOP, WI, VAL, VER, SRD, etc.).
  2. Establish an approval matrix appropriate for the size of the company. In this case, I've decided to establish a single reviewer/approver requirement. Author signs, then reviewer approves. Either can add reviewers/approvers at their discretion, and the President (or designate) is designated as the one required approval.
  3. Contain all of the associated processes in one procedure under Document Controls. This staff prefers to work with "manuals" and doesn't like the idea of having to look for additional procedures, or open multiple procedures in order to accomplish something. So, for now, this is a very long document covering the document structure, numbering, issuing numbers, document life cycle / status, revision control, review / approval, the document control process, and even deviations.
  4. The system will be a "self-service" system. There is no one person to assign document control tasks to. This is how they currently do things so I've elected to keep it that way.
  5. I've installed a check system at the end of the procedure where the President will review every third DCO processed since the last review. There is a set of criteria to verify.
The Problem:

My goal is to seamlessly integrate document controls into their system. They're aware that "some things are going to change" and they're willing to deal with that. They're going to have to start assigning numbers and conducting formal reviews, then they'll need to create paper master copies of everything. They don't have funding for a Part 11 system, or the time to validate one.

I've got everything defined in a way that I believe will satisfy the requirements for a Class III, moderate concern device in a tiny company like this one. The self-service idea with the periodic review is "OK", but it'll work. They've got adequate checks and balances and the internal audits will be conducted by third-parties anyway.

A manual document control system is extremely cumbersome no matter how you slice it. I need to create a document index first.... something they can assign numbers from. But, I need to be able to see the status of those documents, the revision levels, effective dates, etc.

I also need to create a DCO index with all of the pertinent DCO information.

Both should be managed in Excel, because that's probably the easiest and will be accessible to everyone on the network.

Of course, a paper copy will have to be maintained because there are no controls in place.

When a document number is first issued, the document is considered a DRAFT. That's it's status. When it's approved, it becomes ACTIVE. It can then become INACTIVE or OBSOLETE.

If I create an index that includes the status, they technically should create a new entry every time the status changes. I feel that if they overwrite information on the index, they're going to run into serious problems during an inspection. Though, I don't want to see their document index cluttered with multiple entries for each document. I'd rather see only the most current revision for each document on the list. The only way to accomplish this is to overwrite the status, revision level, effective date, DCO #, etc as they change.

The question any auditor or investigator will ask is, "how do you know that you didn't accidentally delete something or overwrite the wrong line?"

Their only safeguard is to overwrite then reprint the list every time. I don't see how this can work for this type of company.

I can easily establish a system with all the controls necessary, but the challenge here is to make this one as seamless and transparent as possible. This company will not be manufacturing the product; they are selling the design when the PMA is approved.

I'm looking for ideas and input. I'd love to see how other people who have worked in a Class III environment would approach this scenario. I've considered hiring myself as their document control department. That's not out of the question.

Throw ideas out here... think tank... brainstorm... whatever. I can also show you what I've written so far - though it's an incredibly long document. Hey... it's their preference so I'm not knocking it! But would still love to hear what you think!
 
M

MIREGMGR

Re: Document Controls - Input and Ideas

All of the effective software developers I've known in the past decade or so, either centrally located or distributed over a WAN, have used one of the source-code-control software packages to manage the practical (as opposed to regulatory) aspects of effective checkout/checkin control, level-of-access control and revision control/versioning.

I can't imagine doing effective team software development on a modular basis these days without that kind of enforced source control.

Some of those packages might be able to be adapted for the control of regulatory documents in addition to source code.

Of course, the pretty QMS-specific UI would be missing...but the level of control across a WAN would be high, and likely pre-validated in a regulatorily satisfactory way.
 
C

Chris Ford

Re: Document Controls - Input and Ideas

All of the effective software developers I've known in the past decade or so, either centrally located or distributed over a WAN, have used one of the source-code-control software packages to manage the practical (as opposed to regulatory) aspects of effective checkout/checkin control, level-of-access control and revision control/versioning.

I can't imagine doing effective team software development on a modular basis these days without that kind of enforced source control.

Some of those packages might be able to be adapted for the control of regulatory documents in addition to source code.

Of course, the pretty QMS-specific UI would be missing...but the level of control across a WAN would be high, and likely pre-validated in a regulatorily satisfactory way.

I like that idea. Thanks... I hadn't thought about that. I don't know what they're using for traceability, but I'm sure they've got some kind of bug tracking going on, and it's probably a commercial product. It would serve well, since they're already using it - plays into my goal to make this integration as transparent as possible. I get the impression from my client that once the product is sold, the company may no longer exist. So, they're not necessarily looking for a quality system that they'll ride on for years to come. The impression I've gotten is they didn't understand the requirement, and now they need the "documents" in place for their PMA. I've already had the initial educational conversations with him, explaining that it's not just about writing a set of procedures. He understands where things stand, but the goal will obviously be to make it as painless as possible.

Thanks again for your input.
 
M

MIREGMGR

This is not intended as a positive or negative recommendation, but the kind of software package I'm thinking of is something like Microsoft's Visual SourceSafe. There are many others, of course.

In my experience, bug trackers usually are separate packages, and usually have strengths in workflow management and task prioritization rather than document/file control. They may have a bug tracker in operation as well, but I think what you really need is a source controller.
 
C

Chris Ford

This is not intended as a positive or negative recommendation, but the kind of software package I'm thinking of is something like Microsoft's Visual SourceSafe. There are many others, of course.

In my experience, bug trackers usually are separate packages, and usually have strengths in workflow management and task prioritization rather than document/file control. They may have a bug tracker in operation as well, but I think what you really need is a source controller.

Good point. I'm preparing a bundle to send over to them now. I'll ask them what they're using. If I find I can't use what they're using, I'm thinking I might implement a soft-copy index only using Excel, and have them save each version of it as they make changes. I can't see the benefit at all to imposing a paper copy of the index. No one will ever access it.

Thanks again
 

Le Chiffre

Quite Involved in Discussions
A source control approach was my instant reaction when reading the original post too.
This is not intended as a positive or negative recommendation, but the kind of software package I'm thinking of is something like Microsoft's Visual SourceSafe. There are many others, of course.

In my experience, bug trackers usually are separate packages, and usually have strengths in workflow management and task prioritization rather than document/file control. They may have a bug tracker in operation as well, but I think what you really need is a source controller.
Here's one that covers pretty much everything you need. I've tried it out and it works well :agree1:
https://www.projectlight.ca/
 

Wes Bucey

Prophet of Profit
Hi All,

Here's the scenario:

  • Very small establishment consisting of six employees, including the President.
  • The staff telecommutes from remote locations.
  • They are developing a Class III medical device - software only.
  • They currently store all documents electronically on a remote server.
  • They have no document controls in place.
  • No documents have been assigned numbers.
  • There is little to no revision control.

The staff consists of very intelligent scientists who are all very busy. They have no understanding of the quality system requirements, or a sense of document controls. They need a system that is very simple to use, that will not add a major burden to their work environment.

My Plan:

  1. Establish a very simple 4-digit numbering system with a document prefix (e.g. SOP, WI, VAL, VER, SRD, etc.).
  2. Establish an approval matrix appropriate for the size of the company. In this case, I've decided to establish a single reviewer/approver requirement. Author signs, then reviewer approves. Either can add reviewers/approvers at their discretion, and the President (or designate) is designated as the one required approval.
  3. Contain all of the associated processes in one procedure under Document Controls. This staff prefers to work with "manuals" and doesn't like the idea of having to look for additional procedures, or open multiple procedures in order to accomplish something. So, for now, this is a very long document covering the document structure, numbering, issuing numbers, document life cycle / status, revision control, review / approval, the document control process, and even deviations.
  4. The system will be a "self-service" system. There is no one person to assign document control tasks to. This is how they currently do things so I've elected to keep it that way.
  5. I've installed a check system at the end of the procedure where the President will review every third DCO processed since the last review. There is a set of criteria to verify.
The Problem:

My goal is to seamlessly integrate document controls into their system. They're aware that "some things are going to change" and they're willing to deal with that. They're going to have to start assigning numbers and conducting formal reviews, then they'll need to create paper master copies of everything. They don't have funding for a Part 11 system, or the time to validate one.

I've got everything defined in a way that I believe will satisfy the requirements for a Class III, moderate concern device in a tiny company like this one. The self-service idea with the periodic review is "OK", but it'll work. They've got adequate checks and balances and the internal audits will be conducted by third-parties anyway.

A manual document control system is extremely cumbersome no matter how you slice it. I need to create a document index first.... something they can assign numbers from. But, I need to be able to see the status of those documents, the revision levels, effective dates, etc.

I also need to create a DCO index with all of the pertinent DCO information.

Both should be managed in Excel, because that's probably the easiest and will be accessible to everyone on the network.

Of course, a paper copy will have to be maintained because there are no controls in place.

When a document number is first issued, the document is considered a DRAFT. That's it's status. When it's approved, it becomes ACTIVE. It can then become INACTIVE or OBSOLETE.

If I create an index that includes the status, they technically should create a new entry every time the status changes. I feel that if they overwrite information on the index, they're going to run into serious problems during an inspection. Though, I don't want to see their document index cluttered with multiple entries for each document. I'd rather see only the most current revision for each document on the list. The only way to accomplish this is to overwrite the status, revision level, effective date, DCO #, etc as they change.

The question any auditor or investigator will ask is, "how do you know that you didn't accidentally delete something or overwrite the wrong line?"

Their only safeguard is to overwrite then reprint the list every time. I don't see how this can work for this type of company.

I can easily establish a system with all the controls necessary, but the challenge here is to make this one as seamless and transparent as possible. This company will not be manufacturing the product; they are selling the design when the PMA is approved.

I'm looking for ideas and input. I'd love to see how other people who have worked in a Class III environment would approach this scenario. I've considered hiring myself as their document control department. That's not out of the question.

Throw ideas out here... think tank... brainstorm... whatever. I can also show you what I've written so far - though it's an incredibly long document. Hey... it's their preference so I'm not knocking it! But would still love to hear what you think!
I'm tight on time before the weekend, but I'd like to point out that "numbering" of documents is an archaic holdover from pre-computer days when the numbering system aided in storage and retrieval.

In early computer days, we were limited to eight character file names (plus extension.)

Today, search and retrieval tools allow us to name documents in reader/user friendly terms, negating the use of an index to determine the difference between "A-123" and "A-124." Hence we can title the first document "SOP for cleaning toilets" and the second, "SOP for brain surgery," and use a search engine to key on key word "brain" or "surgery" to retrieve the document.

Version control and permissions are available from commercial software. I've been writing on the topic of electronic document management for years - see one of my earlier posts from more than five years ago.
Electronic Document Management/Control
<SNIP>
My own organization uses this phrasing for

4.2.4 Control of records

Records may be hard copy or electronic. A record is a special document which holds data generated during the course of performing a process. We control a document by maintaining its integrity against loss or alteration during its useful life. We provide access to a record to all interested parties. We may aggregate data from records into reports or summaries. We may analyze the data contained in a record with a view toward modifying or retaining a process.

We have a documented process to determine which controls over identification, storage, protection, retrieval, retention, disposal shall apply to a specific record.

So, in actual practice, each time we create or receive a document or record (internally generated or received from customer, regulator, or supplier), we hold it up against the yardstick of which Procedure (of several in the process) applies to that particular document or record. The item is then flagged/tagged with an ID code (alphanumeric) which identifies it in our system and therefore which storage, retrieval, retention, disposal actions will apply to it. The ID code is intuitive enough so that the average employee can determine whether it belongs to engineering, production, quality, accounting, sales, etc. and whether it is internally generated or externally generated when he has a hard copy in hand.

Of all of the advantages to our system, by far the most valuable to us has been being able to reduce the search and retrieval time for any document from a previous range of ten minutes to 48 hours down to 5 minutes maximum.

We use a computer-based system. Internally-generated documents are always left in native format (Word/CAD/Excel/Access/etc.) and our software allows us to image any of 200 different formats, regardless of whether the native format is loaded at an individual station. Externally-generated documents we receive go through an extra step of determining if we can import an electronic copy from the external source or if we have to scan a hard copy into our system. In either case, we often have to add "meta tags" (little bits of code which refer to a field in our database) to the externally generated document to aid in retrieval.

The meta tags allow us to add up to 30 layers of security to the documents once they are in our system. Security levels determine who may alter, delete, redline, read, print a document. By working with secure internet connections, we are able to share and/or collaborate on documents almost anywhere in the world. The same security layers allow documents and records to be sorted according to applicable departments. Note all documents are added in random order (alphanumeric ID is unique to each document) and the software sorts and regurgitates each according to the meta tags

We had to deal with our legacy documents (documents created before the system was installed) in the same way we deal with externally-generated documents - we had to add the meta tags individually (a time-consuming and labor-intensive project if you have a lot of documents - we decided the future cost savings justified the expense of adding legacy documents.)

As always, I apologize for telling how to build a watch when you only ask the time.
Not included in the above post, but certainly pertinent, is the fact such software also maintains version control to assure no one inadvertently uses an obsolete version.
 
Last edited:
D

DeviceMaker

Chris,

"The question any auditor or investigator will ask is, "how do you know that you didn't accidentally delete something or overwrite the wrong line?"

Their only safeguard is to overwrite then reprint the list every time. I don't see how this can work for this type of company."

The reprinting does not eliminate the possibility of an accidental re-write or over-write. Only a review could catch it. I use "could" since if there were 100 reprints of the index with 10 errors, a 100 reviews would prpbably catch 4-6 of those errors. This just shows my cynical nature on quality reviews versus systematic controls.

Another note: in my small company I did away with the traditional Author line on SOPs and made everyone signing a reviewer. I was and still am doing a lot of the writing, but then someone else woud sign as author so I could sign as QA. Didn't make sense so I changed it.

Mike
 
C

Chris Ford

I'm tight on time before the weekend, but I'd like to point out that "numbering" of documents is an archaic holdover from pre-computer days when the numbering system aided in storage and retrieval.

In early computer days, we were limited to eight character file names (plus extension.)

Today, search and retrieval tools allow us to name documents in reader/user friendly terms, negating the use of an index to determine the difference between "A-123" and "A-124." Hence we can title the first document "SOP for cleaning toilets" and the second, "SOP for brain surgery," and use a search engine to key on key word "brain" or "surgery" to retrieve the document.

Version control and permissions are available from commercial software. I've been writing on the topic of electronic document management for years - see one of my earlier posts from more than five years ago.
Not inluded in the above post, but certainly pertinent, is the fact such software also maintains version control to assure no one inadvertently uses an obsolete version.

I understand where you're coming from Wes, but maintaining a control number for documentation prevents mix-up and duplication, in my opinion. It also makes filing the documents much easier. The document index can be very detailed, segregating documents by departments, products, QS element, etc. and it seems easier to track a document's history, if a number is assigned (in my opinion). I can't tell you how many times I've seen document titles change on ECO/DCO's. It would be a nightmare to try to list a document's history from an index if that document didn't have a number and we relied only on its title.

Let's say the Purchasing dept. changes a procedure's title from "Materials Procurement" to "Purchasing" to make it easier to understand. When they make the change, they execute a ECO/DCO, changing Materials Procurement, Revision B to Purchasing, Revision C. We now have what appears to be two different procedures. The revision history on the procedure (if the procedure has one) for the Purchasing, Revision C document will clearly indicate that the title changed. However, unless you add steps into your procedure to update the revision history log on the previous revision document, as well (nobody does this), you won't have tracebility in both directions, and you won't see that on your document index. If it's issued a number, you'lll see the entire history for that number, including its title changes.

The document number adds a level of control that I wouldn't really want to impose on document titles. It seems easier to me to assign a simple number than to control how a title is written on a document. If I indexed by title, I'd have to control how the title is written in order to have any consistency in the filing system.

Assigning control numbers also gives you other benefits. Many manufacturers add documentation to their Bills of Materials, so the documents are listed on Work Orders. Their procedures require employees to verify and record the revision level of the document used in production for that lot or batch.

Honestly, the only time I've actually seen document numbers not used is when the establishment isn't meeting any document control requirements.

Intelligent numbering is useful, but tends to be very burdensome. I've really leaned toward simple numbering, with or without document prefixes. When I assign a system like this, the prefix is only part of the document number on paper. On the index, it's a separate field, and can be changed without changing the document number itself. The document number is simply an indexing tool.

I'm mainly concerned with keeping things simple in terms of processing changes and recording information. Adding an index and document management system to this company's processes is going to be a burden no matter what. But, I'd like to make it as simple as possible without losing the ability to effectively track documents.

If I could, I'd implement a small document management database, but given the situation, I'm really limited to something like an Excel spreadsheet.
 
C

Chris Ford

Chris,

"The question any auditor or investigator will ask is, "how do you know that you didn't accidentally delete something or overwrite the wrong line?"

Their only safeguard is to overwrite then reprint the list every time. I don't see how this can work for this type of company."

The reprinting does not eliminate the possibility of an accidental re-write or over-write. Only a review could catch it. I use "could" since if there were 100 reprints of the index with 10 errors, a 100 reviews would prpbably catch 4-6 of those errors. This just shows my cynical nature on quality reviews versus systematic controls.

Another note: in my small company I did away with the traditional Author line on SOPs and made everyone signing a reviewer. I was and still am doing a lot of the writing, but then someone else woud sign as author so I could sign as QA. Didn't make sense so I changed it.

Mike

Hey Mike,

Thanks for your input! I agree with you. I'm definitely not implying that reprinting the index (if one is to even print it at all) would prevent accidental loss of data.

Reprinting would only provide a back-up in the event that you discover that data was lost. It would be an ugly situation to have to analyze a printed spreadsheet and compare it with a different version. And, there's just no way that this company will even need or want to reference a printed document. The entire staff telecommutes. They don't have a physical office. So, like I said, I really don't see how this would work or benefit the company.

I can have them save the index as a new document every time they change it. That's essentially the same as reprinting it, except they'd have the ability to sort and compare indexes, if they needed to.

Saving a copy of the index - essentially treating the index itself like a controlled document, even though it's not - will at least maintain a history and preserve data. From a risk perspective, there isn't much I can do to mitigate or remove the risk of accidental overwrites or obliteration of data in a system like this, but I can put in place methods for preserving data.

Of course.... it's a human-managed system. What's preventing someone from making data entry mistakes then overwriting the file accidentally? What if they forget to change the file name? I'm considering having them name the file DOCINDEX04172009 then saving it as a new document every time they make a change. If more than one change in a day, they'd add a letter to the end of it. Essentially, date code the file. But the answer to the question is "nothing will prevent human error in this system" and that's the reason FDA is so concerned with systems like this. Add to the issue that I'm dealing with a Class III device. Granted, being a moderate level of concern lowers the expectation a bit, but this device's level of concern is actually still up for debate anyway. I have a feeling FDA will actually come back and say it's a high level of concern device.

This company has no QA function. They don't have any departments. It's basically one guy with five or six people reporting to him. There is a person who deals with SQA and testing, but from a document management perspective, they're a self-service organization. You change it, you process it. Given the size of the company, I'm assigning one reviewer / approver - the President, or his designate. He and the author can add reviewers / approvers at their discretion. Because it's a self-serve system, it's lacking checks and balances. So, I built in a periodic review and sampling plan with criteria. I don't think this is ideal for a Class III device, but given the size of the organization, I don't think FDA will be overly concerned. They'll probably be happy to see that some kind of due diligence is actually executed to make sure document changes were effectively processed. So many small companies lack in this area.

Thanks again!
 
Top Bottom