Computer System Lifecycle: Considerations

Hello good people of the world! Today’s post is an overview of the lifecycle of a computer system in regulated industries (pharmaceutical, biologics, and medical device manufacturing). It is based on my almost 20 years experience in the field, and will provide you at a high level the things you should be thinking about with respect to computer systems.

1. Requirements Elicitation
Before anything else, we must understand the requirements around the need for a computer system. This could be the hardest step, and is definitely the most important. Spending extra time and expertise here can prevent a lot of problems downstream. Know who your stakeholders are, and elicit their requirements better than they do. You will often (always ?) find end-users may not know what their requirements are, or may not be able to communicate them effectively. Understand the business process you are trying to automate, and ensure you are talking to all stakeholders: end-users, administrators, managers, etc.

2. Supplier Selection
Once you know what your requirements are, you’re going to find someone to help you met your requirements. At this stage it is important to vet your suppliers to make sure they have the required experience and expertise to deliver a solution to meet your requirements. Supplier selection in regulated industries includes a Supplier Audit.

3. Planning
Now is the time to document your plan. Traditionally this plan is called a Validation Plan, or Validation Project Plan, or Project Validation Plan, but I like calling it a Quality Assurance Plan. Validation is one (big) part of ensuring the quality of the delivery of your new computer system, but your planning needs to encompass all quality considerations. Your plan should include:
– change management procedure to be followed in implementing the system
– updates to your system inventory
– business continuity impact assessment
– risk management considerations (project risk, compliance risk, etc.)
– data privacy considerations
– HR data access considerations
– GxP regulatory determination (e.g., System-Level Impact Assessment (SLIA))
– plan for leveraging supplier documentation
– test strategy for backup, archive/retrieval, restore
– system release strategy
– data migration strategy (if applicable)

4. Specifications
Once your plan is in plan (and agreed upon by all stakeholders), now is the time to specify how the system will meet requirements. Depending on the time of system, risk, GxP impact, etc., deliverables of this stage may be a Functional Specification (FS), Functional Risk Assessment (FRA), Design Specification (DS), Configuration Specification (CS), Requirements Trace Matrix (RTM).

5. Verification
Now that your system is specified, it’s time to test it. Again, depending on the project scope, this stage could include an overall Test Plan, draft SOPs (admin, operating, end-user, etc.), protocol generation, RTM update, business continuity and disaster recovery plans, functional testing, training curricula development, and user-acceptance testing (UAT).

6. Release
Everything has gone well and it’s time to put the system into production use. Be sure to consider: SOP approval/effectiveness, updating the RTM again, any testing in production (such as IQ), system release notification, creating an index of system documentation, closing the Quality Assurance Plan with a report (what actually happened versus what was planned), and closing the change control.

7. Operation
Once the system is in use and everyone is happy, the work is not done! Maintain activities should include: change management, incident/problem management, periodic review of the validated state, periodic testing of backups and disaster recovery, and maintaining the system documentation index.

8. Retirement
Hopefully after many years of service, the time will come to retire your computer system. Be sure to consider data archiving and retrieval in this (final) stage of the computer system lifecycle.

Did I miss anything? Comment below.

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

Advertisement

Montrium Connect Compliance Concerns

Hello good people of the world! Today we’re talking about a specific Software-as-a-Service (SaaS) product: Montrium’s Connect. Montrium offers a number of modules in their Connect software (Document Management, Training, CAPA, Incidents, etc.) Today I’ll focus on the Document Management module.

What makes Montrium’s offering unique is that is it built on top of Microsoft Sharepoint. I previously talked about Sharepoint Online with respect to compliance concerns here (a little out-of-date, but still relevant).

The first point I’ll make is having the application built on Sharepoint brings some significant advantages and disadvantages. The primary advantage I see, in comparison with other electronic Document Management Systems (eDMS), is that Sharepoint uses Microsoft’s Office Online suite, and arguably the world’s best online word processor: Word. I am not aware of any online word processor as fully featured as this one. I have used other eDMSs that have their own word processor and having less features can be really frustrating.

That said, Sharepoint also brings it’s clunky user interface and outdated Active Server Page (.aspx) architecture. The application won’t feel as snappy as modern websites, and you’ll see page reloads for things that would be handled by a component re-render in more modern applications. Overall the application feels very slow. I found myself having to wait minutes sometimes for items moving through a workflow to pop up in my task list.

An example of Montrium / Sharepoint UI

The first thing that struck me with the compliance aspect of Montrium’s offering is that they have categorized their Connect SOP (which is the brand name for the Document Management Module) as GAMP category 3 software. GAMP category 3 is commerical-off-the-shelf (COTS) non-configurable software. I don’t know how they consider this software non-configurable, because there is a lot of configuration options that change how it functions, including workflows. This results in end-users not creating a configuration specification and not testing the configuration to their specific intended use. This could be a compliance risk.

Another thing I noticed is the audit trail functionality. There is no interface for audit trail, instead it is automatically exported a protected Excel file every 28 days. I find it strange that the audit trail would not be available in real-time, and think this could introduce some compliance risk. It also falls into the trap of including at least some non-human readable data. See the example below:

Audit Trail Example

So just a couple points of concern with Montrium’s Connect software in a regulated use case.

What has your experience with Montrium Connect been? What is your favorite eDMS? Comment below.

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

Basic Components of a Test Form

Hello good people of the world! Today’s post is a short one on what are the basic components of a test form. In Validation, you’re going to record a lot of data, and you want this data to be well organized and easily understood. Here are the basic components I think every test form should have:

1. Numbering! Each step should have a unique number so that it is easily identifiable and easy to reference elsewhere.
2. A Title! What is this test all about? A short description should be provide.
3. Purpose! What is the purpose of the test? Make it clear.
4. Verification Steps! Clearly define what steps need to be performed.
5. Expected Results! Clearly define what the expected results are. Does every step need an expected result? Every step can have one, so include it.
6. Actual Results! This is where the actual data is collected. The actual results can be recorded exactly as the expected results are stated to avoid any confusion.
7. Pass/Fail! Did the step pass or fail? This will quickly tell you. Also a good place to reference any comments.
8. Initials/Date! In order for the data to be attributable, initial/date uniquely identifying the test executer must be included for each step.

What basic components do you include on your test forms? Comment below.

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

How to Store an 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: