Qualification/Validation of Middleware and Service Oriented Architectures

Companies in regulated Life Sciences Industries must ensure that all computer systems critical to product quality or patient safety are validated. For many years we have streamlined the processes for application validation and developed a methodology for ensuring the compliance of a single component of Infrastructure. This has all become quite commonplace, however when we approach the subject of Middleware and Service Oriented Architecture, the standard approach to validation or qualification becomes unusable due to the very complex nature of the technology. These items are defined as: Middleware Middleware is any software that allows other software to interact; it connects different parts of an application or a series of applications and provides a transparent means of accessing information between clients and servers. Think of it as a sort of glue that holds together a network and its connected computers Examples being:

• Websphere

• Integration Services (Architectures)

• Active Directory

• Oracle Fusion

We have spent a great deal of time getting all of our applications and Infrastructure into compliance. We now need to look closely at what is left, to ensure our overall systems and architectures are compliant.

Service Oriented Architecture (SOA) Is a new approach (which will eventually replace middleware) to connecting applications used as services rather than individual applications so that they can communicate with and take advantage of each other. This connection allows sharing of functions, typically business functions, in a widespread and flexible manner

So now we know what we are dealing with, the question we must ask ourselves is...

Do we Validate or Qualify? This is a key question to answer when referring to Middleware/SOA, due to the differing amount of effort required to perform both activities, and in the present environment of risk based assessment, it is important to expend an appropriate amount of effort to ensure the appropriate level of compliance.

If we approach Middleware/SOA as software items that facilitate certain functions, we can ask the question, “do we need to validate or qualify?” the answer to which will lead to a number of other questions relating to the software, such as:

• What GAMP software category does the item belong to?

• Does the item interface with GxP applications?

• Is the transported data modified when passing through it?

• Are standard Validation or Qualification methods applied? These questions would usually help us to think about the application of validation or qualification to each individual component, which at first appears to be an easy task. However Middleware/SOA may consist of many individual components, connected in multiple ways, resulting in a matrix of connections, and producing multiple paths through which the required information can pass between applications. For example the diagram below shows the many routes which information could travel to pass from application A to application B: From this, it becomes apparent that there is a potential for almost endless testing of every one of the possible pathways that exist between applications A and B in order to meet regulatory requirements. However if we approach the Middleware/SOA item as a service i.e. what business process does it support, we can test the functionality using that very process, the first step being the application of a riak based approach.

A Risk Based Approach The first step towards attaining compliant Middleware/SOA, is to apply a risk based approach, incorporating risk management activities as we progress. This can be initiated by asking relevant questions concerning the service in question:

• What is the nature of the particular service?

• Does the service interface with other applications (GxP or otherwise)?

• How configurable is the transport mechanism?

• What is the GxP relevance of the data transported?

• What risk are we prepared to take (based upon the amount of data verification performed by recipient applications)?

• What is the extent to which the transmitted data is manipulated or transformed?

However, if we are to progress with our process of evaluation, we must provide a methodology that is both simple and easy to follow Therefore we could start our process by asking three simple questions of the middleware/SOA: Does the Service in question:

1. Exchange data with any other Regulatory or Business Critical applications? 2. Modify or encapsulate any Regulatory or Business Critical data? 3. Is the data transported, validated or verified by the recipient application?

This can be described in the following flow chart

These key questions can be interpreted as below:

Question Meaning

Does the service exchange data with any other Regulatory or Business Critical applications

Does the service exchange data with any software application that has a specific user defined business purpose which has either Regulatory or Business Critical impact?

Does the service Modify or encapsulate any Regulatory or Business Critical data?

Does the service take regulatory or business critical data from an application and change it in any way, (reformat, truncate, compile, convert etc.), so it leaves the service differently to when it arrived

Is the data transported, validated or verified by the recipient applications?

Is the data that is transported by the service validated or verified (checked for accuracy etc) by the applications providing the data and the applications receiving it

Once this evaluation has been performed, we then have a starting point for our validation/qualification process flow for determining the method of compliance required on a case by case basis with any applicable service. From the previous process flow diagram, it can be seen that as we work through the evaluation questions above, we can determine the different type of testing required (Validation or Qualification) for each individual service. This breaks down into 3 different approaches:

1. Fundamental Service, with no modification or validation of data during transport 2. Medium Service, with non modified transport functionality, or with modified content

validated by the application 3. Advanced Service, which modifies regulatory or business critical data and the data is

not validated by the application Each of these three approaches can be further described by referring to the expanded flow diagram overleaf, which splits the original flowchart into 3 distinct processes, each with its own deliverables.

Service Qualification/Validation Process With Recommended Deliverables

The output from each of the three swim lanes describes what the expected deliverables are following the testing of each particular service line, these can be summarised as:

Val/Qual approach

Deliverable Service Type Service Type Service Type

Fast Track • Configuration Item Specification

• IQ/OQ Fundamental MEDIUM ADVANCED

1st Qualification of type

• Requirements Specification (including

traceability)

• Systems Specification (Functional Spec,

Design Spec, Technical Specification)

• Qualification Plan

• Risk Assessment

• IQ/OQ

• Qualification Report

As in Basic Service plus:

• Include Transactions in Functional Spec

• Transaction Set Up

• End to End Testing in OQ

As in Medium service plus:

• Include Unit Testing if Direct Coding Used

• Validation Plan

• User Requirements Spec

• IQ, OQ, PQ

• Validation Summary Report

In conclusion, if we follow the previous methodology, we can achieve a compliant yet pragmatic approach to the testing and subsequent Qualification/Validation of our Middleware and Service Oriented Architectures, providing the relevant deliverables, as required by the regulatory authorities.

David. K. Stephenson Biography David Stephenson is a highly experienced Regulatory Compliance Principal Consultant, with detailed knowledge of Computer System Validation and particular expertise in IT Infrastructure. David has gained considerable consultancy expertise, working for a succession of blue-chip clients in Validation and IS compliance assignments. Roles have ranged from computer system validation of business and process solutions to qualification and testing of IT Infrastructure across multiple European sites and 21 CFR Part 11 assessment and procedural remediation. Most recently, he has been addressing issues with Validation of Pharmacovigilance systems and the introduction of an IS compliance strategy (including IS Security). David was a member of the GAMP Special Interest Group that was responsible for authoring the Good Practice Guide for Infrastructure Compliance and recently has performed Subject Matter Expert duties for the ISPE CPIP certification program. In addition to this strong industry experience and excellent consultancy track record, David has a very strong customer focus, and excellent communication skills, combined with man management of substantial teams. David is presently the Regulatory Compliance Services & Solutions Leader (SME) for Computer Task Group (CTG). Phone: +44 (0) 118 975 0877 Fax: +44 (0) 118 931 0249 Mobile: +44 (0) 7891 343814 E-Mail: David.stephenson@CTG.com