How to Handle Documented Information in an online database for ISO 9001:2015

[agarrett]

Hello,

I require some clarification of how to handle some documents to meet the ISO 9001:2015 standard. We just became ISO certified last year, so our company is still very new to this. All of our documentation when we started was in Excel or Word formats. However, in the past year, we have transitioned the majority of our forms into an online database system called Quick Base. Our first renewal audit is coming up, and I want to make sure that I am still compliant, but not doing too much work when it comes to these documents.

So essentially we have an online database where all of our forms are created and completed now. If changes are made, it is immediate, and everyone always has the current version of the form. All records are stored in the same database. I had previously been advised that these forms were no longer required to be part of our documented information process. I am trying to confirm is this is true.

Essentially, I was told that because there is no real revision history and that everyone has the most recent version at all times they don't need to be included on my master document list. This list contains all of our documents and their revision history (and is also stored in the database system) along with where they are stored, and who is responsible for changes.

So I want to confirm that once the form has been moved into the database it can be removed from my list. If this is not the case, how should I handle changes to these forms as they occur.

We are still freshly in this new software, so changes occur frequently as we decide we need new fields added to the forms. So I need to be sure that I am tracking this all correctly.

Thank you!

 

[Golfman25]

I would see if your database can make a list. If so, I would remove the form from your normal list and just make reference to the database list. No reason to have two lists.

 

[agarrett]

Sorry, I don't think you understood the question. I do only have one master list.

If a form is stored, maintained, and filled out within software, is it required to be on that list? Is it considered to be a controlled document?

 

[Golfman25]

Sorry, I don't think you understood the question. I do only have one master list.

If a form is stored, maintained, and filled out within software, is it required to be on that list? Is it considered to be a controlled document?

I understood the question. Can you print me a list of forms in your database? If so you can probably remove from your written list.

 

[agarrett]

Ok. I see what you are saying, I guess I did not understand your answer. I would say the answer is not really. The software is table based. So each form resides on its own table. While I am able to print a list of the tables in the application it doesn't designate which are forms.

Although, I suppose that every table is truly a form. Let me try to explain this a little bit better so I know that I'm getting an accurate answer. I've been going back and forth on this one for a while.

So the easiest way for me to describe this is to use Excel as an example since it's the most widely known. Essentially I have what is called a table, similar to a workbook in excel. I set up the fields I want on the form, and lay them out in the order I want (see screenshot 1 for a picture of a form). As people fill out this form it creates a new record which would be the same as a row in excel. These records can be viewed individually or in a report (view screenshot 2 for a picture of the report). If we need to add a new field to the form, it takes a few minutes to do so, and once it's done everyone has the current version of the form immediately. There is no keeping track of who has what copy of which version (it's amazing).

So the form is not given a document number or revision tracking as I would have previously done with excel forms. So I suppose a list of tables would serve as a list of forms as well. However, as we add new fields to these forms, am I supposed to be keeping track of who requested the change, and why it was added? The answer I received before was that because everyone has the most recent version of the form right away there is no reason to keep the revision history, and therefore they don't have to be in document control.

 

[howste]

Have you looked at all of the requirements of clause 7.5 to verify that they are being met? For example:
- When changes are made to forms how do you ensure that they are reviewed and approved for suitability and adequacy (7.5.2c)?
- Are the forms and records adequately protected from improper use or loss of integrity (7.5.3.1)?
- Have you addressed version control of changes (7.5.3.2c)?

 

[Golfman25]

Ok. I see what you are saying, I guess I did not understand your answer. I would say the answer is not really. The software is table based. So each form resides on its own table. While I am able to print a list of the tables in the application it doesn't designate which are forms.

Although, I suppose that every table is truly a form. Let me try to explain this a little bit better so I know that I'm getting an accurate answer. I've been going back and forth on this one for a while.

So the easiest way for me to describe this is to use Excel as an example since it's the most widely known. Essentially I have what is called a table, similar to a workbook in excel. I set up the fields I want on the form, and lay them out in the order I want (see screenshot 1 for a picture of a form). As people fill out this form it creates a new record which would be the same as a row in excel. These records can be viewed individually or in a report (view screenshot 2 for a picture of the report). If we need to add a new field to the form, it takes a few minutes to do so, and once it's done everyone has the current version of the form immediately. There is no keeping track of who has what copy of which version (it's amazing).

So the form is not given a document number or revision tracking as I would have previously done with excel forms. So I suppose a list of tables would serve as a list of forms as well. However, as we add new fields to these forms, am I supposed to be keeping track of who requested the change, and why it was added? The answer I received before was that because everyone has the most recent version of the form right away there is no reason to keep the revision history, and therefore they don't have to be in document control.

View attachment 19767

View attachment 19768

Again, I would just want to know what "forms" are in the data base. If there is a list of files/forms/worksheets, etc. then I would use that list and not have it on a separate master list of documents.

 

[somashekar]

Ok. I see what you are saying, I guess I did not understand your answer. I would say the answer is not really. The software is table based. So each form resides on its own table. While I am able to print a list of the tables in the application it doesn't designate which are forms.

Although, I suppose that every table is truly a form. Let me try to explain this a little bit better so I know that I'm getting an accurate answer. I've been going back and forth on this one for a while.

So the easiest way for me to describe this is to use Excel as an example since it's the most widely known. Essentially I have what is called a table, similar to a workbook in excel. I set up the fields I want on the form, and lay them out in the order I want (see screenshot 1 for a picture of a form). As people fill out this form it creates a new record which would be the same as a row in excel. These records can be viewed individually or in a report (view screenshot 2 for a picture of the report). If we need to add a new field to the form, it takes a few minutes to do so, and once it's done everyone has the current version of the form immediately. There is no keeping track of who has what copy of which version (it's amazing).

So the form is not given a document number or revision tracking as I would have previously done with excel forms. So I suppose a list of tables would serve as a list of forms as well. However, as we add new fields to these forms, am I supposed to be keeping track of who requested the change, and why it was added? The answer I received before was that because everyone has the most recent version of the form right away there is no reason to keep the revision history, and therefore they don't have to be in document control.

View attachment 19767

View attachment 19768

The manual of your online database may be a good place to start with. There may rights given for use only and modify only for the forms structure. There is always a date control for the forms as I understand. Look out to see if there is a provision for narration entry for the person who has modify / create rights. If not, as your service provider of the online database to make provision. I hope you have some answer in this..... Thanks