Features
May / June 2020

A GAMP® Approach to Robotic Process Automation
Sion Wyn
James Canterbury
A Gamp® Approach to Robotic Process Automation

This article introduces the concept of robotic process automation (RPA) and discusses how the technology may be used within a GAMP® framework to support both non-GxP and GxP processes.

We focus on deterministic robotic process automation and do not discuss related but significantly different approaches, such as artificial intelligence (AI), machine learning (ML), or cognitive automation (CA). It is, however, the intent of the GAMP® Special Interest Group (SIG) to continue to actively consider these topics and how these approaches may be applied together.1 ,2 ,3  The approach described here is consistent with GAMP® 5 and has undergone GAMP® subject matter expert (SME) review.

Definitions

Robotic process automation is a technology application that allows the configuration of computer software (a robot or “bot”) to capture and interpret data from existing applications for processing transactions, manipulating data, triggering responses, and communicating with other computerized systems.1 ,4 ,5

Robotic process automation technology uses software bots to mimic the activities of human workers. robotic process automation simulates how a human user would use an application’s graphical user interfaces (GUIs) to perform tasks, which the bot performs by automatically executing those tasks directly in the graphical user interface without human intervention.2 ,5 ,6 This may be likened to recording an action and then programming the bot to replay it.

Robotic process automation bots can log into applications, extract data, enter data, complete tasks, and log out. Robotic process automation technologies can be divided into three types: probots, knowbots, and chatbots.7 This article focuses on probots—bots that follow simple, repeatable rules to process data. Other types of bots are knowbots, which search the internet to gather specific information, and chatbots, which respond to human input or queries in real time.

Robotic process automation software is not always considered part of an organization’s traditional IT systems architecture. Rather, it is sometimes regarded as sitting on top of that architecture, with robotic process automation software implementation and operation being possible without changing the existing systems.1 ,2 ,5

It takes little or no previous experience to program bots, and separate application bots may not change the underlying systems; however, robotic process automation bots can influence the business process and related data. Therefore, their use should be carefully planned and controlled.

Components

Robotic process automation technology consists of the following main components: the underlying package or product, the individual bots, and the automation or script (see Figure 1).

Underlying Package or Product

The underlying package or product is classified as GAMP® Category 1 software. Examples of platforms or products characterized as robotic process automation include, but are not limited to, Automation Anywhere, Blue Prism, EdgeVerve, HelpSystems, UiPath, Workfusion, Kofax, NICE, PegaWorld, and Kryon. This list of example platforms and products is included for convenience only and should not be regarded as complete or definitive.

Individual Bots

The bots will be set up (or qualified) as general infrastructure components that are ready to use with some general account, access control, and security settings. They can then be instructed to perform specific business processes (GxP or non-GxP) as required by means of specific automations or scripts.

The individual bots are GAMP® Category 1 software components. Such bots—like people—can be regarded as a multiskilled workforce, ready to be instructed in a specific process by means of defined automation or script. Multiple bots can run any individual automation, and any bot can run multiple automation. This is analogous to multiple qualified human operators being able to follow a specific standard operating procedure (SOP), and a qualified human operator being able to follow multiple SOPs.

Automation or Script

The automation or script can be considered a stand-alone application and should have an appropriately managed life cycle. Business processes and rules need to be defined, and the bot needs to be configured to perform specific activities and meet the business rules, following the defined process. A con-trolled life cycle is needed for these scripts or automations, starting with planning and progressing through specification, verification, and release into the operational environment.

Figure 1
Figure 1: Components of RPA technology.

The automations and scripts are classified as GAMP® Category 5 components (equivalent to small stand-alone custom applications). The deliberate choice to include them in Category 5 reinforces the need for a controlled life cycle for these scripts or automations from planning through specification, verification, and release into the operational environment. The effort involved in the specification, verification, and related documentation should be scaled according to risk, complexity, and novelty following normal GAMP® principles.

Another valid approach may be to regard the scripts or automations as analogous to individual batch instructions or workflows (having their own con-trolled life cycles and validation), similar to those running on an underlying electronic batch record or manufacturing execution system (MES) platform. Again, the underlying life-cycle activities and controls would be the same (i.e., specification, verification, release management, and subsequent change management).

Typical Applications and Prerequisites

robotic process automation is best suited for stable processes that use structured data and have explicit and well-documented business rules, with high transaction volumes and typically with a “single correct answer.”1 ,2 ,5 ,6

Robotic process automation is often applied to automate “swivel chair” tasks—tasks that employees perform by swiveling (often literally) between applications or computers to manually extract information from one application, check or validate it, and then enter it in another application.5  robotic process automation applications may include automating time-consuming processes, such as when users need to log in to third-party sites to download items on a regular basis.

Typical uses of a robotic process automation process include the following:

  • Bots are set up as email “listeners” to kick off other processes. For example, when given the email trigger, “Here is the link to the file you requested,” the bot logs into the third-party system and downloads the file. When it is downloaded, the bot parses and integrates the data into an existing data set.
  • If a requester fills out an email form that requires more than just simple field validation, a bot can perform the initial verification checks—such as “Does this request already exist?”—and swiftly provide an initial reply to the requester.

Prerequisites for successful application of deterministic robotic process automation include stable processes, clean data, and established and documented business rules that are sufficiently well defined and detailed enough for automation.1 ,2 ,5 , 6 It is good practice to redesign the process for automation, instead of simply automating the “as is” human process, which may involve logging on and off many times or not batching activities for efficiency.

Robotic process automation may be appropriate when the underlying source system is not a good fit for its purpose. Alternatively, robotic process automation may be desirable when a change to the source system is especially complicated or difficult, or when two systems are difficult to integrate. Choosing to use robotic process automation may also be a purely business decision, which may have multiple underlying reasons, including budget constraints.

Where robotic process automation is introduced to address an underlying functional or integration issue, a longer-term strategy may be required to address the problem. It is often good practice at the start of robotic process automation projects to develop a longer-term (e.g., three- to five-year) plan whereby the robotic process automation functionality is replaced by permanent changes to the underlying systems or further redesign of the business process.

Benefits and Risks

For rule-based deterministic processes that are digital and repetitive, properly implemented robotic process automation can improve quality and reduce business risks and errors, offering opportunities for high availability, consistency, productivity, accuracy, and reliability.1 ,2 ,5 ,8  Robotic process automation also offers an opportunity to lower compliance and quality risks associated with nonintegrated systems in different functional areas (i.e., “siloes”), which may currently depend on manual interactions, manual transcriptions, or work-arounds to share data within the same or related processes.9  Robotic process automation can also provide comprehensive time-stamped activity logs, which may be used for process analysis.8

Properly implemented robotic process automation can improve quality and reduce business risks and errors.

With robotic process automation, test cases are easier to define and perform due to clear rules and objective processes (typically with one correct or expected outcome). Robotic process automation is a good candidate for the application of automated testing, especially regression testing, and RPA tools have technical similarities to graphical user interface testing tools. Robotic process automation also lends itself to an approach of establishing a library of verified building blocks—tested once and used many times.

Robotic process automation interacts with systems through existing, defined user transactions and uses predefined logic, avoiding the need for more complex and potential-ly invasive system integration approaches such as application programming interface coding and new custom interfaces, which would require more extensive testing.1 , 4 , 5 . This also allows the continued leveraging of the definition, specification, design, and testing of existing system requirements (e.g., system functionality and features related to error prevention, data integrity, security, and access control). Requirements for regression testing when scripts are modified may therefore be substantially lower, as the previous verification of existing systems is still valid. Verification can be tightly focused on the correct definition of the business rules, as well as the verification of the script or automation against business rules within the defined process. Data structures in existing systems are unchanged.

However, as discussed later in this article, the use of robotic process automation may introduce new challenges and risks associated with security and access control in the operational environment.1 These risks require specific assessment, application of appropriate security and access controls, and verification of such controls. This is likely to be a primary element of risk management for robotic process automation.

Error and exception handling are a major design consideration. In such cases, enough information should be provided to the appropriate person so that timely action can be taken, which will typically require establishing local or centralized monitoring mechanisms. Errors and exceptions should be addressed and should not cause the process to hang or terminate, unless this is a process design decision.

Error and exception handling should be rigorously tested. This reflects the EudraLex Volume 4 Annex 11 requirement that “particularly, system (process) parameter limits, data limits and error handling should be considered” during testing.10

The overall risk-benefit balance is favorable given the application of an appropriate life-cycle approach and operational controls.

Automation/Script Life Cycle

Like any more traditional custom application, robotic process automation requires the normal life-cycle steps and activities:

  • Definition of intended use, including business and quality objectives
  • Life-cycle and quality planning
  • Definition of the “to be” process, including identification of data and definition of data flow
  • Definition of business rules
  • Definition of detailed logic and other requirements
  • Configuration, scripting, or training (or whatever terminology is preferred)
  • Verification
  • Life-cycle and quality reporting
  • Controlled deployment
  • Application of operational controls (see next section), including change management

Typically, scripting, configuration, or training and subsequent verification are performed in development environments substantially equivalent to the production environments.

An iterative and incremental (Agile) approach may likely be the most appropriate option. The most practical and advantageous strategy may be to initially and quickly apply the approach to the cases where most business benefit is achievable, and to automate the most common paths first, while putting a framework in place that allows both refinement of existing rules and application to less-common paths as time and resources allow.

Such an iterative and incremental approach requires that the appropriate technical and project management skills and experience are available. It also depends on necessary input from line-of-business owners and business process SMEs, as well as from quality assurance for applications supporting critical GxP processes.

Robotic process automation scripting/automation tools are typically designed to be used by individuals who do not have extensive programming skills and experience (or, at least, that is what the marketing promises). However, the appropriate involvement of IT and relevant technical SMEs is necessary to ensure, for instance, that purchased software is safe, appropriate, and technically compatible with existing infrastructure; data security and access control policies are applied; suitable backup or equivalent arrangements are in place; and bots operate on a reliable and managed infrastructure.1

This reflects the EudraLex Volume 4 Annex 11 requirement (11.2 Personnel) that “there should be close cooperation between all relevant personnel such as Process Owner, System Owner, Qualified Persons and IT.” 10

Operational Aspects

Key operational aspects to consider include access and security management and change management.1  For access management, existing policies should be followed but suitably adapted to the needs of a substantially different situation. For example, it would be inappropriate in most cases for bots to use existing human user IDs and passwords, and rules and policies for the following would need to be adjusted:

  • Who sets passwords?
  • How are they updated?
  • How are password aging policies applied?
  • How are password compromise policies applied?
  • To what extent would sharing accounts and passwords be a problem?

Security and compliance rules must be adapted, and many behavioral risks and controls may no longer be relevant. Examples are rules related to auto logoff and auto screen lock. The practical application of the principles of separation of duties should be considered.

Data integrity and security risks should be assessed and managed. Concerns may include the security of permanent or temporary data storage, including vulnerability to human users; human access to desktops; and the possibility that a user could take over control from a bot. If the bots must be manually started, only authorized individuals should be able to do so. Both physical and logical access controls should be considered.

Auditability of data changes may be a factor to review and adjust. To what extent is a log entry required if a bot modifies or deletes a GxP record? The answer to this question would have to be very specific, well defined, and validated as conforming to the relevant business rules and policies.

Change management must cover cases when business rules or objectives change, situations in which the functionality or behavior of the associated systems changes, alterations in data models or data structures, and any changes to the underlying IT environment. Some products offer a centralized change and release management and distribution model, which may assist in managing all types of changes.

When considering potential robotic process automation applications, it can be interesting and fruitful to consider analogies to human resources (HR) challenges. For example, HR-like plans must be made for bot availability and start-up, task completion, exceptions, monitoring (especially to deal with errors and exceptions), performance review, and retraining.1

Conclusion

If applied to suitable processes and use cases within a GAMP® framework of quality risk management with appropriate project and operational controls, robotic process automation can offer business and quality benefits and the overall risk-benefit balance may be favorable. For this reason, the GAMP® SIG continues to investigate how robotic process automation and related technologies, such as AI, ML, and CA, may help the pharma industry achieve its business goals and promote patient safety and public health.

Information Systems
GAMP®

About the Author

Sion Wyn
Director
Conformity Ltd.
Sion Wyn, Director, Conformity Ltd., is an acknowledged international expert in computer system validation and compliance. He was consultant to US FDA during the re-examination...
James Canterbury
Principal, Consulting
Ernst & Young LLP
James Canterbury is the founder of Zeroth.Technology where he and his team work to establish cryptographic primitives that will secure our digital future. Prior to...