FDA CFR 21 Part 11 using DSC Module

[bjla]

I am implementing an application using the DSC Module that needs to comply with the regulations for digital signature etc. according to FDA CFR 21 Part 11. I have been reading the tutorial:  Using LabVIEW to Create FDA 21 CFR 11 Compliant Applications and it explains how to comply to the different sections of the regulation. Most of it is pretty straight forward, however when it comes to signature manifestation there is very little information on how this should be done? There is no explanation on how a signature can be tied to data that has been collected or how a signature is suppose to be stored (other than that it can be written to the database)?

Is there anyone that has implemeted this using the DSC module that can provide me with some design ideas?

Best regards,

Bjorn Larsson  

[Joe D.]

Greetings Bjorn,

What part of the signature manifestation are you having problems with? Most if it is grabbing the information from the Database.

If it helps you might want to take a look at the free on-line DSC training here

[bjla]

Hi Joe,

Thanks for your response.

The problem is more of a design issue. I have gone through the training material and the tutorials for FDA CFR 21 part 11 and do not clearly understand how to manifest the signature or how a signature is related to logged data.

Below is an excerpt from the http://zone.ni.com/devzone/cda/tut/p/id/4570 : My comments or questions are in red.  

11.50 Signature Manifestations

(a) Signed electronic records shall contain information associated with the signing that clearly indicates all of the following:

(1) The printed name of the signer.

You can programmatically get the printed name of the signer and log this information to the database.

This is no problem I know where to get the login name. But not how to log it to the database? Should I create a shared variable with type string and enable logging? It is not really ideal to log this to the Citadel because it is more of an event and is better suited in an relation database? It is unclear what the author of the document ment with "the database".  Is it the Citadel or just a user designed database?  

(2) The date and time the signature was executed.

The date and time is attached to all data logged to the database.

This implies that the signature should be logged to the Citadel database?

(3) The meaning (such as review, approval, responsibility, or authorship) associated with the signature.

You can design the application so that when a user applies an electronic signature, he/she must choose the meaning of the signature from a list, such as review, approval, responsibility, or authorship. The DSC module can write these meanings to the database with the signature.

 

Again this refers to "the database" as if it was obvious? It is simple to add a combobox with meanings, but this is better implemented using a relation database since the meaning needs to be attached to the name and date? 

(b) The items identified in paragraphs (a)(1), (a)(2), and (a)(3) of this section shall be subject to the same controls as for electronic records and shall be included as part of any human readable form of the electronic record (such as electronic or printout).

All the information in part (a) of this section is written to the database. Therefore, you can use SQL queries or MAX to retrieve it in the same way you can retrieve all other data written to the database.

Here the author implies that the signature is stored in a relation database and retrieved by SQL queries? Also there is no explanation on how a signature is tied to logged data? In other words, a user needs to know what he applies his signature to? Is a dataset or a time interval or something else? How can a user find out what data that has been signed and what has not been signed?

Please let me know if I have completely misuderstood or missed some built in functionality of the DSC module that makes signature manifestation easy?

Best regards,

Bjorn

[aeastet]

When we do this testing. We make the operator input all of the necessary data that we store in the database (name, sample, type, revision etc...). It is not stored in a database. You need to be able to explicitly distinguish each test so that if you are audited you have a trail so that all information is available with little or no effort.

[Joe D.]

Hi Bjorn,

All you have to do is write the data to a shared variable that is custom control with logging enabled. The database is citadel and is pretty well abstracted so I would not worry about it to much.

[bjla]

Thanks Tim for your answer.

The machine I am designing the data logging system for is a continues process equipment that will run 24/7 and will therefore continuesly produce data. The data can be distinguished by using datasets triggered by time or some other identifier like a lot/batch id etc. 

But, I imagine that each distinguished data needs to be signed with an electronic signature with the name, meaning and time stamp? So what I am looking for is, if there is any built in functionality in the DSC module to store this information. It sounds like there is not? 

I can easily create a SQL database that can store all the signatures together with a unique identifier that ties the signature to a dataset (there is an internal ID for each dataset that can be used for this purpose). But, before I spent time on implementing this I wanted to know if there is any built-in support for electronic signatures or if I completely got the signature manifestation wrong and would be wasting my time on adding this?

Best regards,

Bjorn   

[bjla]

Hi Joe,

One thing that I am still a little confused about is if the signature manifestation shall be performed after the data has been collected or during the time it is collected? This is not necessary clear in the FDA CFR 21 part 11 guideline? Since my process is of continues nature there will not be any operator interaction between different datasets.

Best regards,

Bjorn  

[Joe D.]

Hi Bjorn,

I would do it as it was collected