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!

Regulations and Guidance for Assessing a Computer System Supplier

Hello good people of the world! Today’s post is continuing the series on compliance in the cloud. Today’s post is a simple list of regulations and guidance that you can provide to someone who asks the question: why do we have to assess suppliers of computer systems/software? These are the reasons why!

FDA 21 CFR Part 820 Quality System Regulation (link)

Section 820.50 Purchasing controls

Each manufacturer shall establish and maintain procedures to ensure that all purchased or otherwise received product and services conform to specified requirements.

(a) Evaluation of suppliers, contractors, and consultants. Each manufacturer shall establish and maintain the requirements, including quality requirements, that must be met by suppliers, contractors, and consultants. Each manufacturer shall:

(1) Evaluate and select potential suppliers, contractors, and consultants on the basis of their ability to meet specified requirements, including quality requirements. The evaluation shall be documented.

(2) Define the type and extent of control to be exercised over the product, services, suppliers, contractors, and consultants, based on the evaluation results.

(3) Establish and maintain records of acceptable suppliers, contractors, and consultants.

EudraLex Volume 4 Annex 11: Computerised Systems (PDF)

Section 3 – Suppliers and Service Providers

3.2 The competence and reliability of a supplier are key factors when selecting a product or service provider. The need for an audit should be based on a risk assessment.

3.3 Documentation supplied with commercial off-the-shelf products should be reviewed by regulated users to check that user requirements are fulfilled.

3.4 Quality system and audit information relating to suppliers or developers of software and implemented systems should be made available to inspectors on request.

Section 4 – Validation

4.5 The regulated user should take all reasonable steps, to ensure that the system has been developed in accordance with an appropriate quality management system. The supplier should be assessed appropriately.

ICH Guideline Q9 on Quality Risk Management (PDF)

II.4 Quality Risk Management for Facilities, Equipment and Utilities

Computer systems and computer controlled equipment

To select the design of computer hardware and software (e.g., modular, structured, fault tolerance); 

To determine the extent of validation, e.g., 

• identification of critical performance parameters; 
• selection of the requirements and design; 
• code review; 
• the extent of testing and test methods; 
• reliability of electronic records and signatures.

II.5 Quality Risk Management as Part of Materials Management

Assessment and evaluation of suppliers and contract manufacturers

To provide a comprehensive evaluation of suppliers and contract manufacturers (e.g., auditing, supplier quality agreements).

ICH Guideline Q10 on Pharmaceutical Quality System (PDF)

Section 2.7 Management of Outsourced Activities and Purchased Materials

• Assessing prior to outsourcing operations or selecting material suppliers, the suitability and competence of the other party to carry out the activity or provide the material using a defined supply chain (e.g., audits, material evaluations, qualification); 

ICH Guidance E6 on Good Clinical Practice (PDF)

Section 5.5 Trial Management, data handling, and record keeping

5.5.3 When using electronic trial data handling and/or remote electronic trial data systems, the sponsor should: 

(a) Ensure and document that the electronic data processing system(s) conforms to the sponsor’s established requirements for completeness, accuracy, reliability, and consistent intended performance (i.e., validation).

That’s it! Are there any I missed? Comment below!

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

Compliance in the Cloud: ISO 27001 Information Security Management Systems

Hello good people of the world! Today’s post is continuing the series on compliance in the cloud. In the last post, we looked at the FDA’s 21CFR11, which is the legal statute medical device, pharmaceutical, and biologic manufacturers must adhere to when using computer systems for electronic records and/or signatures as part of their manufacturing process for products sold in the United States.

But 21CFR11 is old (1997!) and vague, really only covering at a high-level the requirements for impacted computer systems. Industry has filled in the details, and the ISO standards are a good example of that.

ISO 27001 covers Information Security Management Systems and costs about US$130. Firms may reference ISO certification as evidence of 21CRF11 compliance, such as Microsoft’s statement here.

Below is a summary of the procedural and/or engineering controls required by the standard. You’ll see a lot of overlap with the CFRs, other industry guidance like GAMP5, and other regulations like MHRA’s data integrity expectations.

Management of Policies

1. Policies shall be defined, approved by management, and distributed to employees.
2. Policies shall be reviewed at a planned interval and must be revised when processes change.
3. Responsibilities shall be defined.
4. Duties shall be segregated to avoid conflicts of interest.
5. Communication with relevant authorities shall be maintained.
6. Communication with relevant special interest groups and forums shall be maintained.
7. Information security shall be addressed in all projects.

Human Resource Security

1. Background checks shall be employed.
2. Responsibilities related to information security shall be documented and understood.
3. Training relevant to job functions shall be mandated and documented.
4. A formal disciplinary process shall exist for employees who have committed an information security breach.
5. Responsibilities shall be managed appropriately upon employee termination.

Asset Management

1. An inventory of assets shall be maintained.
2. Each asset shall have an assigned owner.
3. Acceptable use of each asset shall be documented.
4. Distribution and return of assets shall be managed.

Information Classification

1. Information shall be classified in terms of legal requirements, regulatory requirements, confidentiality, etc.
2. Procedures shall exist for the labeling of information by classification.
3. Management of assets shall take into consideration the classification of information associated with the asset.

Media Management

1. Removable media shall be managed per procedure.
2. A procedure shall exist for the proper disposal of media.
3. Procedures shall exist for the physical transfer of media, including protecting against unauthorized transfer, and damage/corruption of media during transfer.

Access Control

1. A procedure shall exist for access control.
2. User access shall be limited to the networks, systems, and information required to perform their job duties.
3. A procedure shall exist for the registration and de-registration of users.
4. A procedure shall exist for the access provisioning of users to all applicable systems.
5. The allocation of privileged access rights shall be restricted and controlled.
6. Authentication information shall be controlled through a formalized process.
7. Asset owners shall review user access at planned intervals.
8. User access shall be removed at appropriate times, such as employee termination.

Cryptography

1. Procedures shall exist for the use of cryptographic controls to protect information.

Physical Security

1. Security perimeters shall be defined to protect areas containing sensitive information.
2. Secure areas shall employee physical entry controls.
3. Physical protection against external and environmental threats shall be established.
4. Procedures shall exist for working in secure areas.

Equipment

1. Equipment shall be protected from problems with supporting utilities.
2. Cabling shall be protected from interception, interference, and damage.
3. Equipment shall be maintained on planned intervals.

Operations Security

1. Operating procedures shall exist.
2. Change management procedures shall exist.
3. Resource use and process capacity shall be measured and understood.

Backup

1. Backup and restore procedures shall be documented and tested on planned intervals.

Logging

1. Event logs shall be employed, retained, and reviewed on planned intervals.
2. Logs shall be protected from tampering, unauthorized access, and loss.
3. Administration activities shall be logged and reviewed on planned intervals.
4. Clocks used by systems shall be synchronized to a single reference time source.

Development Processes

1. Software development procedures shall be documented.
2. Changes to systems in the development lifecycle shall be controlled.
3. Development environments shall be secured.
4. Security functionality shall be tested during development.
5. Acceptance testing shall be established for all new versions of software.
6. Test data shall be controlled.

Suppliers

1. Risks associated with supplier access shall be documented and mitigated.
2. Risks and mitigations shall be communicated and agreed upon with suppliers.
3. Suppliers shall be audited on planned intervals.
4. Changes to supplier relationships shall be controlled.

Incidents

1. Procedures shall exist for the management of incidents.
2. End users shall be required to report incidents.
3. Corrective and preventive actions shall be applied to the management of incidents.

Business Continuity

1. Procedures shall exist for the continuity of business processes during adverse events.
2. Business continuity procedures shall address information security concerns.

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

Compliance in the Cloud: 21 CFR Part 11 Requirements

Hello good people of the world! Today’s post is the next in the series on compliant software in the cloud. Today we’re taking a deep dive into the FDA’s 21st Code of Federal Regulations, Part 11 (21CFR11). If you’re not familiar, 21CFR11 is an ancient (written in the late 1990s) regulatory statute on the use of electronic records and electronic signatures in regulated industries such as medical device, pharmaceutical, and biologic manufacturing. Despite it’s age, 21CFR11 is the governing statute for the use of computer systems in regulated spaces, so it’s critical that we understand it well.

In this post, I’ll give a abridged version of each applicable section of the statute, and then detail the engineering and procedural requirements that are typically used to meet the statute in the design, development, and implementation of a cloud-based computerized system. Let’s go!

Subpart B §11.10, Controls for Closed Systems

• Persons who use closed systems to create, modify, maintain, or transmit electronic records shall employ procedures and controls designed to ensure the authenticity, integrity, and, when appropriate, the confidentiality of electronic records. Controls used require the following:
  • Validation
  • Legibility
  • Record Protection
  • Limited System Access
  • Secure Audit Trails
  • Operational System Checks
  • Authority checks
  • Device Checks for data validity
  • Training
  • Policies in place for operational adherence
  • Control of Distribution
  • Change Control Procedures

Engineering requirements:

• System shall employ HTTPS and other modern web application security technology per according to ISO/IEC 27001 and ISO/IEC 27018 standards
• System shall employ user-level security, ensuring each user is required to maintain a unique username and password to access the system
• System shall employ role-based permissions and limit access to only functionality required by the job role
• System shall employ audit trail to ensure compliant activities are documented with username, time/date stamp, and reason for signature
• System shall employ electronic signatures with username, time/date stamp, and reason for signature for GxP-related activities

Procedural requirements:

• System shall be validated
• Audit trails shall be reviewed
• Appropriate training shall be assigned and managed
• Use and administration procedures shall exist
• Change control procedures shall exist

Subpart B §11.50, Signature Manifestation

Requirements for signature manifestation:

• Signed electronic records shall contain information associated with the signing that clearly indicates all of the following:
• The printed name of the signer; The date and time when the signature was executed; and
• The meaning (such as review, approval, responsibility, or authorship) associated with the signature.

These are 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).

Engineering requirements:

• System shall employ electronic signatures with username, time/date stamp, and reason for signature for GxP-related activities

Procedural requirements:

• System shall be validated
• Audit trails shall be reviewed
• Appropriate training shall be assigned and managed
• Use and administration procedures shall exist
• Change control procedures shall exist

Subpart B §11.70, Signature/Record Linking

Electronic signatures and handwritten signatures executed to electronic records shall be linked to their respective electronic records to ensure that the signatures cannot be excised, copied, or otherwise transferred to falsify an electronic record by ordinary means.

Engineering requirements:

• System shall employ electronic signatures with username, time/date stamp, and reason for signature for GxP-related activities
• Electronic signatures shall be linked to specific records and cannot be transferred by any means.

Subpart C §11.100, General Requirements

Each electronic signature shall be unique to one individual and shall not be reused by, or reassigned to, anyone else.

Before an organization establishes, assigns, certifies, or otherwise sanctions an individual’s electronic signature, or any element of such electronic signature, the organization shall verify the identity of the individual.

Persons using electronic signatures shall, prior to or at the time of such use, certify to the agency that the electronic signatures in their system, used on or after August 20, 1997, are intended to be the legally binding equivalent of traditional handwritten signatures.

• The certification shall be submitted in paper form and signed with a traditional handwritten signature, to the Office of Regional Operations (HFC-100), 5600 Fishers Lane, Rockville, MD 20857.
• Persons using electronic signatures shall, upon agency request, provide additional certification or testimony that a specific electronic signature is the legally binding equivalent of the signer’s handwritten signature.

Engineering requirements:

• System shall employ user-level security, ensuring each user is required to maintain a unique username and password to access the system
• System shall employ role-based permissions and limit access to only functionality required by the job role
• System shall employ electronic signatures with username, time/date stamp, and reason for signature for GxP-related activities
• Electronic signatures shall be linked to specific records and cannot be transferred by any means.

Procedural requirements:

• Procedure shall exist for systems users to sign testimony that their electronic signature is equivalent to their handwritten signature and for this testimony to be communicated to the agency

Subpart C §11.300, Controls for Identification codes/passwords

Persons who use electronic signatures based upon use of identification codes in combination with passwords shall employ controls to ensure their security and integrity. Such controls shall include:

• Maintaining the uniqueness of each combined identification code and password, such that no two individuals have the same combination of identification code and password.
• Ensuring that identification code and password issuances are periodically checked, recalled, or revised (e.g., to cover such events as password aging).
• Following loss management procedures to electronically deauthorize lost, stolen, missing, or otherwise potentially compromised tokens, cards, and other devices that bear or generate identification code or password information, and to issue temporary or permanent replacements using suitable, rigorous controls.
• Use of transaction safeguards to prevent unauthorized use of passwords and/or identification codes, and to detect and report in an immediate and urgent manner any attempts at their unauthorized use to the system security unit, and, as appropriate, to organizational management.
• Initial and periodic testing of devices, such as tokens or cards, that bear or generate identification code or password information to ensure that they function properly and have not been altered in an unauthorized manner.

Engineering requirements:

• System shall employ user-level security, ensuring each user is required to maintain a unique username and password to access the system
• System shall employ role-based permissions and limit access to only functionality required by the job role
• System shall require each user have a unique username and password
• System shall expire passwords after a set amount of time
• System shall lockout users after a set amount of failed login attempts
• System shall have documented password strength requirements
• System shall obfuscate passwords when entered and displayed on User Interfaces
• System shall store passwords in an encrypted manner, and never display, store, or transmit passwords in plain text

Procedural requirements:

• Procedures shall exist for the administration of users into the system
• Procedures shall exist for the routine use of computer systems

What Engineering or Procedural requirements do you think are critical for cloud-based computer systems? Comment below!

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.

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.

Evaluating 3rd Party Software Solutions

Hello good people of the world! This post is about evaluating 3rd party software solutions for GMP use and is based on this excellent questionnaire from the Canada-based company Montrium: 17 Must-Ask Questions for Demonstrations of Regulated EDMS’

The following are some topics to focus on:

Considerations in SaaS Validation

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:

SharePoint 2013 in a GMP Environment

Hello good people of the world! Today’s post is about implementing and using Microsoft SharePoint 2013 in a regulated (GMP) environment.

Microsoft has published a comprehensive guide to SharePoint 21CFR11 compliance, which can be downloaded for free here.

Basic software requirements are: