Category Archives: Computer Systems Validation

How to Store an Electronic Signature

Electronic Signature

Hello good people of the world! Today’s post is a short one on the topic of electronic signatures. 21CFR11 includes requirements around the use of electronic signatures in place of traditional handwritten signatures and these requirements are fairly well understood at this point. The question of this post is, how should your electronic system store the electronic signature?

It is important to understand that electronic signatures are meta-data. That is, they are data about data. So if you have an electronic batch record, for example, the electronic signature recorded during approval is not part of the batch record data, but meta-data of the batch record data. In this example, it is specifically the who, what, and when of the batch record approval.

Given that, electronic signature data should not be included in the same record (table row, document, etc.) in the electronic system. It is meta-data and should be handled as such, an important consideration in electronic system design. This will ensure electronic signature data is robust, auditable, and readily available.

How do you store electronic signatures? Any lessons learned? Comment below.

Like this MWV (Mike Williamson Validation) blog post? Be sure to like, share, and subscribe!

Warning Letter: Daito Kasei (Japan)


Hello good people of the world! Today’s post is about a recent (January 2018) warning letter issued by the FDA to a Japanese cosmetics and drug manufacturing company called Daito Kasei. The warning letter, which can be found here, underscores the need maintain focus on data integrity requirements in our modern age. This warning letter includes explicitly the following data integrity remediation steps: Continue reading Warning Letter: Daito Kasei (Japan)

Computerized System Qualification: AssetCentre


Hello good people of the world! This covers qualification of Rockwell Automation’s Change Management software application FactoryTalk AssetCentre. AssetCentre is a application the can be used to implement version control on GxP process PLC, HMI, SCADA, BMS, BAS, etc. software files.

AssetCentre may be considered GAMP category 3: non-configurable off-the-shelf software if you’re using the default configuration, or GAMP category 4: configurable off-the-shelf software if you’re doing some configuration related to your specific processes. There is no customization available in AssetCentre.

Some things that may be configured (and therefore in the scope of qualification) include:

  1. Database Limitations: the maximum database size, warnings levels, maximum number of versions per asset, etc. may be configured to ensure application performance
  2. Disaster and Recovery Schedules: the frequency and number of backups of a specific asset or group may be configured
  3. Searches: searches may be configured and specific unique security rights
  4. Security Groups: typically security is integrated with the site Active Directory, but additional groups may be configured to apply specific feature security (see below)
  5. Feature Security: security rights for each feature (e.g. ability to view specific folders, edit the Asset tree, etc.) may be configured
  6. Database Backups: regular backups of the SQL Server database may be configured

Data integrity issues:

  1. There is a function (called “Log Cleanup Wizard”) which effectively allows the audit trail entries older than the current day’s date to be purged from the system.

What details do you include in your AssetCentre qualification?

Like this MWV (Mike Williamson Validation) blog post? Be sure to like, share, and subscribe!

Data Integrity – What is Means for You

data-integrityHello good people of the world! Data integrity is an important topic in the information age and has come into focus for regulatory agencies as more and more parts of manufacturing processes become automated. Agencies know that data integrity can directly affect drug quality.

This post covers the MHRA (UK) guidance on data integrity version 2, released March, 2015, which can be found here.

The guidance document defines data integrity as “the extent to which all data are complete, consistent, and accurate throughout the data lifecycle.”

Of course, the concept of data integrity also applies to paper records, but it is the novelty and complexity of computerized systems that makes data integrity applied to electronic records a subject worthy of discussion and exploration. While we’ve had generations to get used to maintaining paper records, electronic records are relatively new, and the best practices for assuring data integrity may still be maturing.

Raw electronic data typically comes from one of four sources:

  1. Direct data capture via instrument/device output (e.g. temperature transmitter, valve actuator feedback, etc.)
  2. Capture of data stream from another computerized system (e.g. electronic chart recorder, electronic scale, etc.)
  3. Automated import of data from another computerized system (e.g. event or alarm log, recipe, etc.)
  4. Manual entry via HMI (Human-Machine Interface)/OIT (Operator Interface Terminal)

Each of these methods is subject to qualification/validation. Method #4 is a unique case in that is may require secondary verification by a separate operator or, in some cases, a supervisor, for critical data or any case where data is being transcribed from another location (electronic or paper-based).

The rules that apply to paper-based data also apply to electronic data. Data must be (ALCOA):

  • Attributable – it must be clear who made the entry
  • Legible – it must be clear what the entry is
  • Contemporaneous – the data must be recorded at the time of action/event
  • Original – the data must be raw
  • Accurate – the data must be correct, complete, and accurate

In order to maintain electronic data integrity, the following concepts are applied:

  1. Access Control
    • Each user shall be uniquely identified
    • Password controls shall be adequate
    • User’s shall have only the permissions necessary to perform their job functions
    • A list of current and historic users shall be maintained
  2. Change Control
    • Changes to the system shall be controlled and only available to authorized users
  3. Training
    • All users shall have the training necessary to perform their job functions
  4. Record and Retain Data
    • Required data shall be recorded ALCOA and retained through the lifecycle
  5. Audit Trail
    • Modifications to raw data shall be recorded in an audit trail, with who made the change, the original data, the modified data, when the change was made, and why
    • The audit trail may also record system events, transactions, logins, etc.
  6. Review Data
    • Data shall be available for review
  7. Backup Data
    • Data shall be backed up to ensure redundancy and eliminate any single point of failure

Originally, audit trails only captured changes to raw data, the way a line-out would capture a correction on a paper record. Now, much more may be expected of the audit trail, and audit trail functionality may consist of multiple system reports, for example record of logins (attempted and successful), application transactions, any change to application data or metadata. In addition, the audit trail report is expected to:

  • Record the original and modified values of any data change with user and date/time stamp
  • Not be editable
  • Be viewable and understandable by end-users (that means no foreign key values or other coded/hex values please!)
  • Be reviewed as part of batch release
  • Be regularly backed up

Some more considerations around your audit trail:

  1. Do administrators have the ability to modify or disable the audit trail? If yes, how to control the added risk
  2. Does the audit trail contain enough data to allow robust data review?
  3. Do the items in the audit trail include enough relevant items that will permit the reconstruction of the process or activity?
  4. What is the process for audit trail review?

Some more considerations around your user access procedures:

  1. Is there a procedure that describes how access is granted to a user, defines each user group, and their access levels?
  2. Is user access granted only after a documented training has been completed?
  3. Do users have only access rights appropriate for their job role (tied to SOP ideally)?
  4. Is it clear what rights to a specific individual (e.g. via user rights report)?
  5. Is historical information regarding user access levels available?
  6. Are shared logins or generic user access accounts used? Should avoid these!
  7. Is administrator access restricted to the minimum number of people required? Don’t want excessive numbers of admins!
  8. Is the generic administrator account available for use? Don’t allow this!

How do you assure data integrity in your organization?

Like this MWV (Mike Williamson Validation) blog post? Be sure to like, share, and subscribe!

WHO’s Draft Guidelines on Validation May 2016

Hello good people of the world! On May 15, 2016, the World Health Organization released its draft Guidelines on Validation. It is available on the WHO website for download here.

This post covers my review of the guidance. Continue reading WHO’s Draft Guidelines on Validation May 2016

Can SharePoint Online be Compliant?


SharePoint is an off-the-shelf configurable software solution that has been offered by Microsoft since 2001. It is popular in many industries (including Biotech, Pharmaceutical, and Medical Device) for document management, local Intranet, and many other applications. However, if SharePoint is being used for any GxP purpose, you better believe it is subject to 21CFR11 and/or Annex 11. Continue reading Can SharePoint Online be Compliant?

Considerations in SaaS Validation

SaaS Qualification

Hello good people of the world! Today’s post is about qualifying Software as a Service (SaaS), also known as “cloud-based” or “hosted” software. Simply, SaaS is any computer system in which any server is not hosted by the system owner. Here are some key considerations in qualifying SaaS computer systems:

Continue reading Considerations in SaaS Validation