Are Database Objects Controlled Documents and/or Records?

Manix

Get Involved!!!
Trusted Information Resource
#1
Hi All,

I am currently trying to move my customer complaints, NCM and Customer returns over to a database approach from a heavily paper based system.

Now the paper based system has various forms all of which are standardised and the format of which is controlled using our document control system. So the format remains controlled and is always used.

Now I want to move all this over to an electronic database. Now reading the standard (TS), it seems I have to:


  • Approve documents for use.
  • Review and update and re approve.
  • Revision status and changes are identified.
  • Relevant versions are available at point of use
  • Documents are identifiable
  • Prevent unintended use of obsolete documents.

Now my dilemma is initially, is a database and it's forms, reports, tables etc... actually documents?

I am trying to figure out the controls I need to have in place.

My initial thoughts are:

- Control the database at the top level in terms of being able to edit. That way only the current approved versions of the database and it's elements are able to be used by users.
- Ensure changes to any elements of the database are approved and recorded.
- The very essence of a networked database means it is available at the point of use.
- Preventing use of obsolete documents will be done by only the approved version of the Database being available to users.

However, reporting from the database become documents, how do I identify them? The current forms have unique numbers, but I see no point in having this on reports coming from a controlled database???!!

Can anyone help with examples of how they have approached this very issue?

TIA
 
Elsmar Forum Sponsor

Stijloor

Staff member
Super Moderator
#2
Hi All,

I am currently trying to move my customer complaints, NCM and Customer returns over to a database approach from a heavily paper based system.

Now the paper based system has various forms all of which are standardised and the format of which is controlled using our document control system. So the format remains controlled and is always used.

Now I want to move all this over to an electronic database. Now reading the standard (TS), it seems I have to:


  • Approve documents for use.
  • Review and update and re approve.
  • Revision status and changes are identified.
  • Relevant versions are available at point of use
  • Documents are identifiable
  • Prevent unintended use of obsolete documents.

Now my dilemma is initially, is a database and it's forms, reports, tables etc... actually documents?

I am trying to figure out the controls I need to have in place.

My initial thoughts are:

- Control the database at the top level in terms of being able to edit. That way only the current approved versions of the database and it's elements are able to be used by users.
- Ensure changes to any elements of the database are approved and recorded.
- The very essence of a networked database means it is available at the point of use.
- Preventing use of obsolete documents will be done by only the approved version of the Database being available to users.

However, reporting from the database become documents, how do I identify them? The current forms have unique numbers, but I see no point in having this on reports coming from a controlled database???!!

Can anyone help with examples of how they have approached this very issue?

TIA
Manix,

The easy way is to control everything electronically. Any report produced from this database has a limited "life" and is considered "uncontrolled." Some of my Clients print a footer on the document stating that it is only valid for 24 hours or state that any hardcopy report is considered uncontrolled.

Stijloor.
 

BradM

Staff member
Admin
#3
Manix, good questions.

In most of the databases I have worked within there is an output form or template. Be it through Crystal Reports or some other report generation system, there is a "fixed" format for which the data is rendered. So, we would always put form/data controls on the report. Then, any information being produced on the form would be just like writing something down.

Like paper forms, there are minor changes you may make (move a field over a bit) up to major. Usually, anytime the information would look different, it would call for a revision change. That, is entirely up to you.

Now... then you say forms, many times that is an input tool on a database. You may control that if you wish (limit what goes into the database), but I would only worry about the output (forms). Too, there may be several Ad Hoc reports you want for management use (sales figures, % in/out, etc.) that I would not put under change control. Just identify them clearly as management reports or something.

To me, while the spec. may not call for it, assure you have proper security/ access levels in place. Also, design the thing right up front, the first time. Whatever time you spend now, will return you 10 fold later.
 
S

szohar

#4
Brad: To me, while the spec. may not call for it, assure you have proper security/ access levels in place. Also, design the thing right up front, the first time. Whatever time you spend now, will return you 10 fold later. :agree1:

Agreed on all counts. My preferred approach: Don't allow anyone other than IT to tap directly into databases, and only release reporting tools to users when a decent amount of security and canned formatting is built into those tools.

It's a bit of a hassle when getting started, but as Brad said, it's better to invest the time up front. I have learned through painful experience that it's a lot uglier to fix that sort of thing later.
 

Manix

Get Involved!!!
Trusted Information Resource
#5
Thanks for the replies so far. Some valid points.

I think I should say that we are a very small company (sub 20) and I developed the DB myself, with no previous DB experience.

It has been a long and arduous road, but the system has been in place since the turn of the year in parallel with the paper based system. It has worked well, with some minor tweaks here and there.

I need to implement some kind of control over Access rights and perhaps a log in system. I think as long as I address the change control and security aspects, it will remain within the bounds of the standard. :whip:
 
Z

zancky

#6
Hi All,

I am currently trying to move my customer complaints, NCM and Customer returns over to a database approach from a heavily paper based system.


  • Approve documents for use.
  • Review and update and re approve.
  • Revision status and changes are identified.
  • Relevant versions are available at point of use
  • Documents are identifiable
  • Prevent unintended use of obsolete documents.

Now my dilemma is initially, is a database and it's forms, reports, tables etc... actually documents?


- Control the database at the top level in terms of being able to edit. That way only the current approved versions of the database and it's elements are able to be used by users.
- Ensure changes to any elements of the database are approved and recorded.
- The very essence of a networked database means it is available at the point of use.
- Preventing use of obsolete documents will be done by only the approved version of the Database being available to users.

However, reporting from the database become documents, how do I identify them? The current forms have unique numbers, but I see no point in having this on reports coming from a controlled database???!!
I'm not an expert but I have written my own database for material incoming inspection, gage and instruments device managing (calibration records/status/procedures), material NC managing. and it works fine

first I have studied the database standard rules (something you can fine in every DB book).

2nd I have designed the basic DB structure according to the db standard rules and I have found out the first problem. Applying the standard rules it would be difficult to keep trace of the changes (e.g. printing a report of two years old data I need the specification at that time). So I'm storing in a single table the data and the specification used to control that data. To me the format can be changed but not the content! .

Very important a backdoor that only YOU can use for correct input etc.
(don't allow anybody to know it, they will destroy the db integrity!)

3rd I have design the forms too (No problem for the revision of the format)

3rd I had request to my colleagues to use it. it was like a revolution I had to modify a lot of things to avoid mistyping, double click, insert explanation etc

4th the problem of special characters:some databases don't allow them and You need special tricks according to the software

the review / approval etc can be done very easily with a form once you state a version for your software. A paper document that states something like "we as YYY, approve the "XXXX" software into the revision "AAA" as valid to be used etc" or by electronic signature (a table field password controlled).


sorry but I don't understand revision concern Can you explain me?

best luck ( .. and please don't hesitate to ask me if you think I can help You)
 
S

szohar

#7
One common convention I've seen (and use, when I have the option) is that software changes are released as "versions" while document changes are released as "revisions" - not everyone does things this way, but the distinction can be useful in terms of clarity, if nothing else.

I don't know if that was what Manix was referring to.
 

Manix

Get Involved!!!
Trusted Information Resource
#8
HI All,

I am now determined to get this DB up to speed and in full use so need it in line with TS16949 requirements.

My idea and hopefully my source of questions is detailed in the attached .pdf. Effectively if I control the revision of the whole DB, then I control both it's input and it's output. This is entirely feasible using our current change control process.

I will incorporate a change table with maybe some electronic signatures, but need to swat up on how to protect the DB using passwords and user names etc....!!!

I do have one small question still though: The revision will appear at the front console of the DB, but should the current revision of the DB be stated on all output reports? So in essence, this report was created using V1.1 of the DB?

I hope this is clear!!! :bonk:
 

Attachments

CycleMike

Registered Visitor
#9
You should keep track of your database and all your changes to it using version numbers. But I would only have the documents themselves (reports) stamped with a small textbox, maybe at the bottom, that show the actual document revision.

Is your database MSAccess? Will you be splitting it into a frontend/backend?

If not, you should consider it. You can keep all the tables on the server and only have an .mde of the database on the users PC's. Then if you have to change a form or report or something, you only have to redistribute the updated frontend as an .mde. A plus is that no one can get into an .mde and change the reports or forms.
 

Manix

Get Involved!!!
Trusted Information Resource
#10
You should keep track of your database and all your changes to it using version numbers. But I would only have the documents themselves (reports) stamped with a small textbox, maybe at the bottom, that show the actual document revision.

Is your database MSAccess? Will you be splitting it into a frontend/backend?

If not, you should consider it. You can keep all the tables on the server and only have an .mde of the database on the users PC's. Then if you have to change a form or report or something, you only have to redistribute the updated frontend as an .mde. A plus is that no one can get into an .mde and change the reports or forms.
Thanks,

I think I will take you advice on the version numbers etc.... The front end back end thing I will proably look to do in the near future, but for the time being it will remain an mdb file. We are very small and there is only likely to be 2-3 users.:thanx:
 
Thread starter Similar threads Forum Replies Date
M UDI Database and EUDAMED - Will there be two separate databases? EU Medical Device Regulations 3
N Discovery of "hidden" FDA database of malfunctions Customer Complaints 6
M Informational EU – Draft Functional specifications for the European Database on Medical Devices (Eudamed) – First release (High(1)) to be audited Medical Device and FDA Regulations and Standards News 0
S MAUDE database and similar devices Other US Medical Device Regulations 5
Marc Old Registered Visitors "Pruned" from the Database - 20180916 Forum News and General Information 0
Sidney Vianna High number of certificate suspensions in the IAQG OASIS database AS9100, IAQG 9100, Nadcap and related Aerospace Standards and Requirements 14
H IS there any database for list of CE marked Medical devices and there current status EU Medical Device Regulations 8
supadrai Repacker/Relabeler (a/k/a/ Customer) is now shown as "Holder" of 510(k) in Database 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 0
D Microsoft Excel database to Stand-alone software Calibration and Metrology Software and Hardware 3
A How to Handle Documented Information in an online database for ISO 9001:2015 ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 7
D Pasting table on OASIS new database AS9100, IAQG 9100, Nadcap and related Aerospace Standards and Requirements 0
R Electronic (Online Database) Calibration Records General Measurement Device and Calibration Topics 4
M Leaving Footprints in the Data - Large Database Validation Statistical Analysis Tools, Techniques and SPC 7
R Questioning legitimacy of CBs if not in IAQG-OASIS Database - AS9100 Certificate Registrars and Notified Bodies 8
Pmarszal FDA Global UDI Database: Record Submission Retention Other US Medical Device Regulations 1
E Document Control MS Access Database Document Control Systems, Procedures, Forms and Templates 39
L Making a Medical Devices Registration Database - Help and Suggestions Wanted Other Medical Device and Orthopedic Related Topics 2
F U.S. Medicare Reimbursement Searchable Database for specific procedures (DRG or CPT) Other Medical Device and Orthopedic Related Topics 2
P Obtaining the Italian MoH database and Smartcard for Medical Devices EU Medical Device Regulations 3
I GUDID listing - Inputting data into the GUDID database Other US Medical Device Regulations 3
I How to build a Microsoft Access MDB Database for Document Control Document Control Systems, Procedures, Forms and Templates 6
N Database for monitoring NDT Personnel Software Quality Assurance 4
xfngrs Automotive Industry Nonconformance Database wanted - Preferably SharePoint based Quality Assurance and Compliance Software Tools and Solutions 5
S How to track and manage all uncertainty budgets - Database? Measurement Uncertainty (MU) 3
N Database (Like ASSIST) to subscribe to & have access to new SAE-AS & ANSI standards Various Other Specifications, Standards, and related Requirements 2
SteveK Interesting Medical Device Database Site (666,413 items listed) Other Medical Device and Orthopedic Related Topics 1
N Notified Body excessive reporting onto Competent Authorities via the Eudamed database ISO 13485:2016 - Medical Device Quality Management Systems 7
S Problem Solving Database for Each Machine Manufacturing and Related Processes 5
V Have you used Intelex Corrective Action Database? Quality Assurance and Compliance Software Tools and Solutions 3
R ERAI - Counterfeit Component Database (Listed on page 39 of AS5553A) AS9100, IAQG 9100, Nadcap and related Aerospace Standards and Requirements 3
T Controlling an Excel Spreadsheet (Database) ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 3
Wes Bucey Code of Federal Regulations Electronic Copy Searchable Database Quality Manager and Management Related Issues 1
bio_subbu USFDA issues final guidance on Global Unique Device Identification Database (GUDID) Other US Medical Device Regulations 1
Sidney Vianna Interesting Discussion IAF CertSearch Database - Repository of "properly" Accredited Management System Certs ASQ, ANAB, UKAS, IAF, IRCA, Exemplar Global and Related Organizations 74
K Ideas for an Open Source Calibration Database Software Calibration and Metrology Software and Hardware 3
B Shop Drawings that Integrate Information from a Database Inspection, Prints (Drawings), Testing, Sampling and Related Topics 3
B Do I need to validate my database software? Calibration and Metrology Software and Hardware 1
C Incoming Inspection Database Inspection, Prints (Drawings), Testing, Sampling and Related Topics 2
D Open database for incidents and recalls of comparable medical devices EU Medical Device Regulations 7
E Open Sourced Surgical Tray Sterilization Database and Software wanted Medical Information Technology, Medical Software and Health Informatics 2
T Microsoft Access Database to create a Simple Calibration Certificate General Measurement Device and Calibration Topics 6
T Basic Document Control Database (Excel/Access) Document Control Systems, Procedures, Forms and Templates 3
S Customer Database Versioning Question Document Control Systems, Procedures, Forms and Templates 3
A Does anyone use FMEA database in Access? Quality Assurance and Compliance Software Tools and Solutions 2
E Database search is correct to capture medical device ISO 13485:2016 - Medical Device Quality Management Systems 2
A How to purchase CTS-ECG Database Quality Assurance and Compliance Software Tools and Solutions 1
J Corrective and Preventive Actions Database in Excel Document Control Systems, Procedures, Forms and Templates 11
L Lesson Learned Database for Audits Internal Auditing 4
R Inspection Database Picker - Creating an Inspection Report Document Control Systems, Procedures, Forms and Templates 1
C Managing Inspection Records with a Database and Destroying Paper Records Inspection, Prints (Drawings), Testing, Sampling and Related Topics 4
Similar threads


















































Top Bottom