Lab Informatics System Risk Assessment – Done! Now what??

OK, so you know that Risk Management is an integral part of computer systems validation and you’ve already completed the System Risk Assessment and produced a full set of lifecycle and validation documentation. Is the system ready to be used? Are we there yet? The idea of “one-and-done” risk analysis puts your company at risk for quality and compliance issues. Managing Risk throughout the Laboratory Informatics Lifecycle is both a regulatory expectation and a business benefit when performed correctly.

The Risk Management models in GAMP 5, ISO 14971 and ICH Q9 that are most commonly used in FDA regulated industries all present a similar methodology of identification, assessment, control and monitoring risk. The purpose of this blog is to further discuss the Risk Control and Monitoring portions of those methodologies.

(Figure courtesy of ISPE, GAMP 5; figure M 3.10)

Risk Control

Typically, detailed functional risk assessments describe actions to mitigate the risks that have been identified. These mitigation steps can include functional testing and technical and/or procedural controls. Technical controls (e.g., access controls) for medium to high risks require validation, while procedural controls (e.g., responding to failed login attempt alerts) for medium to high risks must be approved, trained on, and made effective. While many companies have become proficient at these risk assessments, some remain weak in documenting that the risk mitigation steps (e.g., SOPs are in effect, testing has been completed) have been executed which has often resulted in audit citations.

A good validation process starts with a description of actions to be performed and finishes when a summary of the activities is approved. The same process should be applied for risk assessments. One method is to approve the risk assessment and revise it after all activities have been completed. This is better for global systems and teams where there may be multiple releases and individuals. The risk documentation can serve as a gate for releasing a system. Another method is to draft the risk assessment, perform all associated risk control activities, and the update the risk assessment to ensure all risks are closed and approved. This is a preferable approach for smaller systems and teams where the burden of approving a revision does not outweigh the benefit of agility. Both methods reduce the possibility that technical solutions were not actually done or that procedural steps are not actually in place.

→ Related Reading: Understanding Risk Management

So how is risk managed after the risk mitigation activities have been verified? Before any change is made to a system (e.g., hardware, software, procedures or people), risk should be assessed and documented. Certainly, if there are changes to User Requirements, the functional risk assessment should be revised. Although some changes may seem less invasive than others, all changes require the same assessment methodology as performed during the initial assessment for the system. You also need to consider the following when determining the timing of assessing a change and impact to regular use of the system:

• What stakeholders are required to review and approve the risk assessment?
• Can you group multiple changes into one assessment to consolidate effort?

These changes are best addressed within your Quality and/or IT Change Control formal processes. Yet many times, it’s more efficient to proceduralize changes. That is, to write a procedure that addresses changes without initiating a formal change control process (e.g., defined hardware changes, configuration, master data and data archiving, etc.). This minimizes the repetition of assessing similar changes with multiple stakeholders. The key factors for a procedural change process include:

• Stakeholders in Quality and Validation approving the procedure
• Well characterized changes where you can accurately assess risk and the ability to verify controls (e.g., replacing hardware such as failed RAID disks or instrument interfacing protocol converters, moving configurations from a validation environment to a production environment, converting paper documented tests to the lab informatics system, etc.)

Risk Monitoring

Companies have to evaluate risk initially and before subsequent changes. So is that it? Are we there yet? Not quite. It’s possible that over time changes have a cumulative impact on a system that may not have been adequately assessed and challenged. In addition, needs/requirements can change and thus controls need to change. Also, controls may no longer be effective or have not been properly utilized to mitigate risk. To address these potential issues, periodic reviews should be performed on a basis that is appropriate for the criticality of the system. This information needs to be documented and controls evaluated. Where risks have decreased, controls should be reduced.  Where new risks have been identified or risk has increased, appropriate controls should be applied.

Risk control and monitoring present the opportunity to minimize compliance exposure and the effort to implement controls. Apply appropriate controls to address the risk level, and when possible, assess maintenance activity risk up-front and proceduralize in lieu of change control. Assessing risk not only initially but throughout the lifecycle of the system will keep risk management current and help you stay in compliance!

---

Do your Computer System Validation SOPS require Risk Assessment updates after controls are in place? Have you been able to leverage lab informatics procedures to minimize the burden of formal change control? Are your lab informatics systems on a periodic review schedule?