Part 11 and "Disappearing" Signature Manifestations

An interesting question appeared on-line today which we thought deserved airing with a wider audience via the blog.

Q. When implementing an electronic document management system, is it acceptable to make the author/approver names and dates disappear? Is this still in compliance with 21 CFR Part 11.50, Signature Manifestations?

A. Let's remind ourselves of the relevant rule:

§ 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;
(2) The date and time when the signature was executed; and
(3) The meaning (such as review, approval, responsibility, or authorship) associated with the signature.
(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 display or printout).

The first question to ask ourselves is the question of scope. Not all of the documents stored in the EDMS will fall within the scope of 21 CFR Part 11. In fact, this is a notoriously difficult area in which to interpret the predicate rules. Some rules will clearly state that documents need to be signed and in other areas it must be inferred from the use of words like "authorised" or "approved".

The first thing to therefore do is to clearly decide which categories of document fall within the scope of 21 CFR Part 11 OR (to be on the safe side) to decide that the approval of all documents will meet the technical requirements of part 11.

Looking at the specific question of signature manifestations, subpart 11.50 (b) clearly states that the name of the person signing, the signature date and the meaning of the signature must be included in any printout or electronic display.

Making the names and dates "disappear" in some way clearly contravenes the requirements of 11.50 (b) if these components are not readable in either the on-screen display or the hardcopy printout of the document. If this were to be implemented we would consider the solution to be non-compliant with Part 11, at least with respect to the documents that fall within the scope of Part 11.

Scaleable Database Controls for Part 11 Compliance

A good question posted on-line in the 21CFRPart 11 Yahoo Group, going to the heart of security controls around Electronic Records

Q Consider an electronic record system utlizing a typical database where a User ID and Password combination are used as an electronic signature to sign the records.  Assume the front end application has sufficient controls to prevent manipulation of the signature by the users.

Without getting too technical, what types of controls and solutions have you folks seen in terms of ensuring compliance with the requirements of 11.70 in regards to access to the database on the back end, typically by a DBA? 

How do you ensure that the linkage from record to signature is secure enough in the database to prevent manipulation by the DBA via ordinary means (i.e. with standard functionality and tools)?

Is there a risk justification for allowing the DBA some ability to manipulate the signature linkage, or should it be prevented by all but extraordinary means (i.e. using non-sanctioned tools, hacking, etc.)?

A. Without getting too technical there are a variety of controls that can be used. Which is implemented depends on risk and should be decided based upon the outcome of a documented risk assessment.

The first step is to use digital rather than electronic signatures. At its simplest, this means calculating some sort of 'hash' (fancy checksum) which is calculated using the contents of both the record and signature components. If either the record or signature components are changed, any attempt to recalculate the hash will come up with a different answer and you will the know that something has changed.

It won't however tell you what was changed - for that you need to rely on audit trails which can be set up at either the applications level (looking at changes to the defined record) or at the database level, to identify any inadvertent or accidental changes at the database level.

There is still the chance that the DBA can turn off the audit trails, so with some databases (e.g. Oracle) you have a couple of other options. The first is to write the audit trails into a separate database schema to which the DBA does not have access. This can use something like Audit Vault technology, which means the audit trails are written to a separate database server. The second is to make the database tables 'virtual private' database tables, which means the DBA can't even see them, let alone access them.

There may be circumstances when the DBA needs to access the database to make changes at the data level e.g. data corruption, or an accidental deletion by a user. It is permissible to make corrections under these circumstances, but you need a strict change control procedure to record what is being fixed, why and when (i.e. to preserve the audit trail). In such circumstances you would typically issue the DBA with a 'Super DBA' user account and password to make the changes, and then change the password afterwards (obviously someone needs to be trusted at some point).

One important principle is the idea of 'motivation' - why would a DBA want to make such changes? Organisational controls should be in place (including training and sanctions) to prevent e.g. a DBA and a system user from working in collusion to falsify records. Clearly system users should not also be DBAs.

It is therefore possible to make your Part 11 records and signatures very, very secure, but the more secure they are the more complex and expensive the solution. That's where the risk assessment is important - to identfy what is appropriate for any given set of records.

Risk-Based Approach to Clinical Electronic Records/Signatures

Q. I'm looking at complying to regulations, in order to validate some lab software collecting data from an ICP. Anyone have any ideas on attacking this? The software claims to be "part 11 capable" but it's pretty soft. E-sigs are 'loose' and audit trails are also 'loose'. For something like this do you feel attaching a risk assessment to each part of the regs to determine what level of testing to perform?

A. The reality is that with the 2003 Scope and Appplication guidance introducing a risk-based approach to e-records, the ability to use digital, electronic or no signatures (the latter being conditional on predicate rule requirements) and with the risk-based approach in Annex 11, taking anything other than a risk-based approach makes no sense.

You should therefore conduct a risk assessment against each of the applicable parts of Part 11, and also for each applicable records and signatures. The latter because the risks impact associated with different records/signatures may well be different (in terms of risk to the subject and subsequent risk to the wider patient population) and also because different technical controls may be applied to different areas of the system.

This will allow you to assess the risk impact, likelihood and detectability for each record/signature and to determine whether the in-built controls are appropriate to the risk. If they are not you can either find alternative solutions e.g. print out the records and sign them, or validate a process to copy data/records to an external, secure system and signing them there or introducing additional procedural controls. If there are no alternative control that are acceptable then you may well need to be looking at an alternative piece of software.

When are e-Signatures Required?

We answer a lot of questions submitted to us by e-mail or in various on-line groups. We thought that some of these deserve a wider audience, so from now on we're going to publish the best questions (and answers) here on the Life Sciences Blog.

Q. I had a question regarding 21 CFR Part 11 Electronic records. If a system has electronic records but no electronic signature but does contain the Audit trail does it mean that each record that is created within the system has to be printed in hard copy and signed so as to associate that record with the signature.

A. The fact the system has an Audit trail which links the user name and action on that records is sufficient enough to meet the 21 CFR Electronic Records criteria. If the record requires no signature (either explicit or implied from a predicate rule perspective) then there is no need to print and sign anything (either copies of the record or the audit trail).

The (secure) recording of what, (optionally who) and why (inferred from the transaction) will be sufficient to demonstrate compliance with the predicate rule.

A good example would be a training record. The predicate rule does not require training records to be signed, but you would still want to record what (training was undertaken), who (who was trained) and why (the training topic or syllabus). Even though an audit trail would be maintained for the training record, there would be no need to print and sign it because the predicate rule requires no signature.

New Part 11 Assessment (and Enforcement) Is Coming

As we report in this month's copy of our ValidIT newsletter (focusing on IS Compliance and Computer System Validation issues) it looks as if the US FDA's CDER division wants to assess the state of play in the industry with respect to 21 CFR Part 11 (Electronic Records, Electronic Signatures).

Although the scope and specific program areas aren't yet decided the way they intend to do this is to ask specialists in the Agency to accompany Inspectors from the Field Divisions on routine inspections and look at issues around Part 11, taking appropriate enforcement action where necessary. This is to help them to understand how the industry is responding to the 2003 Scope and Applications Guidance and to help the Agency decide how to revise Part 11.

This demonstrates a pragmatic approach to resolving this open issue and the Agency is to be applauded in taking a proactive yet measured approach (other Divisions within FDA aren't directly involved and are playing a watching brief).

I hope that what they'll find - certainly on inspections in North America and Europe - is that:

• Most Regulated Users have taken Part 11 on board and are responding well, applying a risk-based approach where appropriate,
• Technology has moved on, allowing Suppliers to meet Part 11 technical requirements much more easily, leveraging significant advances in security, encryption and digital signatures.

Of more concern is not what is happening in North America and Europe, but what is happening in the emerging economies where an increasing proportion of pharmaceutical (and medical device components and products) are being manufactured. Major international Life Sciences companies who have set up operations in countries like China, India and Brazil are largely applying their own internal processes and procedures and are leveraging mature software products from experienced vendors - Part 11 compliance shouldn't be a problem here - so far, so good.

However, there is also a significant number of indigenous API, pharmaceutical and medical device companies in these markets often using local software developers to avoid the licensing costs or overseas development costs of using more established software from multi-national vendors. Our experience in these markets is that in many of these cases the requirements of Part 11 are well less understood.

Looking at any of the on-line forums that exist, anyone who reads some of the Part 11 questions posed by certain individuals and organizations from some countries will realize that in many cases the current level of understanding (and in some cases the level of technology) is where North America and Europe was ten or more years ago. What we might consider to be 'simple' questions and answers only appear simple based on more than fifteen years discussion and experience in the industry, which many newcomers understandably lack.

Now this isn't a rant about moving jobs 'overseas' or about how unfair lower cost labor is in emerging markets - we all compete in a global economy. Working with end users and suppliers in these markets I know how well educated their labor pool is, how hard working they are and how innovative they can be.

What I hope is that the FDA will not restrict their assessment of the state of Part 11 to just their domestic market or traditional developed markets (Canada and Europe), but that they will also include a broader set of overseas manufacturers, to determine what the overall state of the market is with respect to Part 11 compliance.

Without this representative sample there are two potential risks:

• The Agency concludes that things are in relatively good shape and that no great changes are needed to Part 11, or the enforcement thereof. This has the potential to miss possible issues in emerging economies where fraud can be as much as an issue as accidental problems with electronic records and signatures,
• The Agency develops a revised Part 11 based upon an assumption that all software developers (and their clients) generally have access to the latest technology, which can again lead to compliance risks. Any new Part 11 should clearly avoid the problems created by the original preamble and should not focus on any specific technologies or techniques.

I also hope that the Agency will continue to work in conjunction with the industry to understand the underlying causes of any issues they do find and work with the industry to ensure that all manufacturers and their software suppliers have an adequate understanding of Part 11 and the current (and future) expectations of the Agency.