Добавить в избранное
GPP
GACP

Для содержимого этой страницы требуется более новая версия Adobe Flash Player.

Получить проигрыватель Adobe Flash Player






External service providers

Here you will find answers to the following questions:

  • What is meant by outsourcing, offshoring, nearshoring and backshoring?
  • Why are contracts with IT service providers necessary?
  • Which elements must be covered by a contract?

   

9.G.1 Relocation of activities (outsourcing, offshoring,
nearshoring, backshoring)

  • Outsourcing refers to the contracting out of development, maintenance or service tasks. These then no longer fall under the organisational responsibility of the pharmaceutical company.
  • Offshoring refers to the outsourcing of activities to foreign countries, in relation to software, to India in particular.
  • This process is known as nearshoring if activities are outsourced to neighbouring countries.
  • In backshoring or insourcing, the activities return from external companies to the company's own organisational responsibility.

The key to all successful outsourcing is IT governance, a set of rules that provides a general description of all services and processes. This is based on standards that are intended to ensure that control of all work and deliverables remains guaranteed. Examples of this type of IT service standards are ITIL (Informatics Infrastructure Library), ISO 20'000, Information technology -Service management - Part 1: Specification and Part 2: Code of practice and CobiT, the Control Objectives Management Guidelines Maturity Models of the IT Governance Institute (ITGI) (www.itgi.org).

Models also exist for the development of software by third parties; of which the most renowned are CMMI (Capability Maturity Model Integrated) and SPICE (Software Process Improvement and Capability Determination), which is also known as ISO Standard ISO/IEC 15504.

In a comparison of both models, a distinctive characteristic is that step models prescribe the sequence of improvement steps in the improvement program. In contrast, continual models allow you to determine the sequence of improvement steps yourself according to your own aims and risks. In its step model, CMMI strictly prescribes the optimisation of project and configuration management at step 2, while verification and validation processes are not considered until step 3. In SPICE (ISO/IEC 15504), the individual improvement strategy allows you either to simultaneously raise all processes to a higher level or, for example, to raise the test processes to a higher level earlier than the project management processes.

SPICE has also proven to be capable of adaptation and has been adapted for the aerospace, automotive, and medical industries.

9.G.2 Service level agreement

A service level agreement organised in different levels is used to describe

  • Clear tasks,
  • Clear responsibilities (chapter C.4 Part I Basic Requirements for Medicinal Products, chapter 2, basic principles) and
  • Clear communication flows.

It therefore minimises misunderstandings and increases working efficiency. The GMP requirements in Annex 11 (point 18) of the EU-GMP Guideline (see chapter C.6.11 Annex 11 Computerised Systems) also describe that when contracting external companies to perform services for computers, a formal agreement should be concluded in which the responsibilities of the external company are clearly defined.

Services must be precisely defined and agreed. The contract between the contract giver and the contract acceptor must clearly define the tasks of both sides and regulate communication between the two sides.

The tasks of the contract giver include responsibility for assessing the competence of the contract acceptor, which should be established in an assessment or audit. The contract giver must ensure that all work is performed in a GMP-compliant manner. Documentation, change management, training, and all other GMP aspects must be reviewed. The contract giver must supply all the necessary information to ensure that tasks can be executed properly.

The contract acceptor should possess suitable premises and the necessary equipment, as well as sufficient technical expertise, experience and competent personnel, and may not subcontract any work contractually assigned to them to a third party without the prior review and approval of the contract giver. The contract acceptor must also permit inspections by the contract giver and the authorities.

9.G.2.1 Contents of a service level agreement

The following is a typical example of a table of contents for a service level agreement:

  • Service description
  • Validity
  • Provision of the service
  • Availability
  • Reaction time
  • Response time
  • Technical details / file formats
  • Scope of the service
  • Obligations of the contract giver
  • Training
  • Documentation requirements
  • Change management
  • Data backup
  • Business continuity planning
  • Inspection and audit
  • Costs and method of payment
  • Service acceptance and resolution of deficiencies
Specific requirements of the pharmaceutical industry

Since the pharmaceutical industry is subject to regulations and constant audits by the authorities, the following points in particular should be taken into account:

  • Training documentation (chapter C.4 Part I Basic Requirements for Medicinal Products, chapter 2.9): Date, duration, contents of training, and evaluation of whether participants have understood the contents.
  • Documentation requirements: No pencil, changes and corrections made in GMP-compliant style (cross out the old version legibly and add the new content with initials, date and rationale).
  • Change management: No unauthorised changes.
  • Backup and Business Continuity Planning: In the event of a product recall, all relevant information must be accessible within the minimum possible time.

9.G.2.2 Example of a service level agreement

GAMP Guide 4, Appendix O2 also covers the service level agreement. The GAMP Guide proposes the structure shown below - unfortunately without entering into the details. The GAMP list is also not quite complete and omits some points, such as which quality standards must be complied with. The table below therefore contains the expanded structure proposed by the GAMP Guide Appendix O2 on the left, with explanations of how this can be implemented in practice on the right. Text proposals or Examples are highlighted in italics . The table not only contains points relevant to regulations, but also points that lead to improved maintainability of the contracts and hence reduce the probability of errors.

The table is based on a service level agreement that was published by Siemens as a part of the North Rhine Westphalia E-Initiative.

The title sheet below contains all relevant information for the service level agreement and the corresponding generic designation by which it is later know in the contract. This has the advantage that the service level agreement is easy to maintain, for example if a contract partner has to be replaced. The writing style is also consistent, i.e. Datacenter Mannheim does not appear alongside DC MH, Datacenter MH, or even Datacentre Mannheim. There is nothing more irritating when the service level agreement is forwarded for signatures than noticing that the old contract acceptor still appears in the header or footer, or elsewhere in the text (figure 9.G-1, figure 9.G-2).

Figure 9.G-1 Title sheet of a service level agreement

Service level agreement
for the
"Datacenter Mannheim" server farm

Service recipient
Small-Pharma
referred to in the following as the contract giver

and

Service provider
IT-Profis
referred to in the following as the service provider

Validity period
1. April 2007 until withdrawal

Figure 9.G-2 Service level agreement structure 

Structure

Explanation and example

System definition

Should only be specified on the title page and described generally in the body of the text.

Title page: Datacenter Mannheim server farm

Text: The server farm contains 24 servers.

Supported service

Specifically on the title page:

Generally in the text

Quality standards

The contract acceptor is certified in accordance with DIN EN ISO 9001:2000. The contract acceptor is obliged to the contract giver to apply and comply with the regulations of DIN EN ISO 9001:2000.

Regular quality meetings will take place between the customer contact person of the contract acceptor and representatives of the contract giver, initially on a weekly basis, with the frequency later reduced to monthly or quarterly. Users have the opportunity to contribute to optimisation of the service in an annual customer satisfaction survey.

Measurement of the service against the requirements of the service level agreement

Availability, times for problem resolution, processing, run-in and downtimes can be measured and should be specified here. If necessary, the required printouts should also be defined here.

Availability refers to the ability of the servers to handle queries within a maximum of 2 seconds.

Reaction time is the time from when a failure message, setup request or settings request is sent, until confirmation of receipt is received.

The problem resolution time is the time from the confirmation of receipt of the problem until the problem is resolved.

The processing time is the time taken to set up or change users, user profiles, authorisation changes to directories or servers, until it is reported that the changes have been made.

The run-in time is the time considered necessary by the service provider for planned changes to the server in order to make a change at a particular time.

Review and audit from the contract giver side

During an inspection of the contract giver, the contract giver or authorities have the right to inspect the contract acceptor.

Inspection of the contract giver

In the event of an inspection of the contract giver, the contract acceptor is obliged to supply all required documents with the highest priority.

Who compiled the document

The author should be mentioned.

Contract status of the document

The cover sheet normally includes information on the date from which a contract is valid, for how long it runs, and whether it replaces an existing document.

Relationships to other documents

Other documents should be referenced with details of update obligations.

Purpose, roles and responsibilities

The description of the support organisation with details of contact addresses for reporting problems, orders, complaints, and crisis management can include an SPOC (= Single Point of Contact) or different contact addresses.

Service catalogue

The individual services are listed here:

System availability 98%: per year rolling, not inclusive of revision times, which have been previously agreed with the contract acceptor.

Problem resolution time: 24 hours, only incl. weekdays.

Run-in times for server extensions: 6 weeks.

Error reporting and error weighting

All errors should be reported by telephone immediately to the contract giver's contact person.

Total system failure - critical - 60 minutes to resolve the fault, not including problems caused by external forces or natural disasters.

Partial server downtime - critical - 60 minutes

Single failures - important - 4 hours

Escalation procedure

The direct contact persons of the contract acceptor and contract giver should be named here as a function, as well as the corresponding superiors, a court of arbitration and the court of jurisdiction in the event that a problem cannot be solved by any other means.

The names do not belong in the contract.

Provision of alternative measures

In the case of a total system failure, the contract acceptor will provide the complete system infrastructure within 2 hours by implementation of a backup. If the infrastructure can no longer be installed at the same location, the new location must be agreed with the contract giver.

Software patches

Software patches, security patches and virus protection updates must be installed following agreement with the contract giver.

Upgrades

Upgrades that are requested by the contract acceptor must be discussed and agreed in advance with the contract giver.

Upgrades that are requested by the contract giver should be applied for from the contract acceptor including the necessary run-in and processing time.

Cleaning and completion of corrections

The validation activities are defined by the contract giver on the change request or the fault reporting form.

Data backup

The contract acceptor executes a daily backup to enable full recovery of all data within 12 hours.

Management and administration

The contract acceptor is responsible for ensuring that all staff have attended a course on correct documentation in the GxP environment and that they comply with the elementary principles.

The contract giver provides the contract acceptor with the training material for the GxP training courses.
Any outsourcing to third parties, freelancers or contractors must be agreed with the contract giver in advance.

Support of hardware and infrastructure

No software or hardware should be implemented unless it is discussed with the contract giver in advance. Remote maintenance and Internet access must be agreed with the contract giver before each individual access.

Software implemented

This section contains a list of all permitted software components.

Testing and calibration

This section provides references to all test and qualification protocols.

Contact persons in an additional document and not in the service catalogue

Since the contact persons may change relatively frequently, they are not explicitly named in this document.

Measurement of services

This section contains the catalogue of measured values: What is measured, how is it measured and calculated, who records the data, format and periodicity of reports, procedures for handling questions regarding the service reports, assessment of trend results and who is responsible for executing the analysis.

Additional points include circumstances for adjusting the service level agreement, contact persons, contract acceptor, contract giver, who distributes the reports, and costs such as fixed costs, order costs, and debit costs. The general terms and conditions of business must also be listed.

9.G.3 Auditing of suppliers and service providers

Service providers and suppliers have to be audited. The focus of the supplier audit is to ensure that the supplier correctly performs all development activities in his area in accordance with the V model (see chapter 9.E.4.1 Test stages in the V model). The quality assurance system also has to be reviewed. Another important point is the supplier's error failure investigation and resolution process. In particular, it should be ensured that systems that have been supplied to other customers are also reviewed in terms of reported errors and that the supplier informs all customers if a global error has been detected.

The focus of the service provider audit is to ensure that the service provider is performing all tasks in accordance with the service level agreement and would be prepared to undergo an audit by the authorities. In service provider audits, in particular change management, reporting, and documentation are inspected.

The question catalogue in figure 9.G-3 offers a practical and helpful supplement to the question catalogue in the PIC/S guidance (see chapter F.3 PIC/S Guidance Good Practices for Computerised Systems in Regulated "GXP" Environments (PIC/S PI 011)). A cross in the column "Supp", "SP" and "I" provides an indication of whether the question is relevant for a supplier, a service provider, or internally. A "P" in the relevant column stands for "partially", if the corresponding activity was carried out by the partner.

Figure 9.G-3 Question catalogue 

Question 

Supp

SP

I

General

Is there an inventory of all systems?

 

X

X

Are the systems uniquely identified, versioned and classified?

X

X

X

Is there a validation of all systems?

   

X

Personnel

Do staff have sufficient experience and training?

X

X

X

Is sufficient personnel available to realise the transferred tasks?

 

X

X

Do job descriptions exist?

P

X

X

Do organigrams exist?

X

X

X

Are the users involved in the development of a new system?

X

 

X

Are any quality assurance aspects from the old system lost in the new system?

   

X

Are users trained before using a new system?

   

X

Are maintenance and repair personnel for computerised systems in the production environment trained in the relevant hygiene and zone instructions?

 

P

P

Are advanced training options available for computerised systems and applications?

 

P

X

Are the training courses documented?

 

X

X

Service level agreements

Do service level agreements exist?

 

X

P

Do these contracts include quality assurance measures?

 

X

P

Do contracts restrict the transfer of tasks or data to third parties?

X

X

 

Do the contracts permit audits and inspections?

X

X

X

Life cycle

Have the systems been developed according to a life cycle?

X

 

P

Does a life cycle model or a project procedure model exist?

X

 

X

Is there a project plan and a corresponding SOP?

X

 

X

Is a project concept and a corresponding SOP created?

X

 

X

Is there a quality protocol and a corresponding SOP?

   

X

Are application specifications compiled and, if applicable, are these signed by the user?

X

 

X

Is a risk analysis carried out and is there a corresponding SOP?

X

 

X

Are there development specifications and an associated SOP?

X

 

X

Is the development of system components (hardware and software) documented?

X

   

Compilation of user instruction manuals

X

   

Installation and start-up/SOP

X

 

X

Acceptance test planning and execution

X

P

X

Release/SOP

   

X

Change control/SOP

X

X

X

System monitoring and maintenance/SOP

 

X

X

Error handling/SOP

X

X

X

Planning of tests and reviews/SOP

X

X

X

Are there plans or SOP for the retirement of systems?

X

 

X

Is the retention period of data and documentation regulated and does it comply with regulatory requirements?

X

 

X

Retrospective validation: Does an experience report exist?

   

X

Completeness of the documentation

X

X

X

Risk analysis

X

X

X

Quality protocol

X

 

X

Is authorised access regulated?

X

X

X

Are user lists up-to-date?

X

X

X

Are the authorisations appropriate, or are all users authorised as administrators?

X

X

X

Is system access protected by timeout or shutting down?

X

X

X

Are passwords protected using a suitable method and are they secure?

X

X

X

Are entries subject to plausibility checks so that they remain within predefined limits?

X

 

X

Is critical data reviewed?

 

X

X

Are data archiving process performed using a long-text format (PDF, TXT), or how is later retrieval of data guaranteed?

X

X

X

Is data archived on long-term media? (Magnetic media should be rewritten every two to three years, since magnetic information becomes lost over time.)

 

X

X

Are full backups performed on a regular basis?

 

P

X

Are two generations of full backups available?

 

P

X

Have the backups been checked for completeness and recovery ability?

 

P

X

Are daily incremental backups performed?

 

P

X

Are alternative systems available in the event of a failure?

 

P

X

Are procedures for restarting a failed system clearly defined and approved?

 

X

X

Summary:

External service providers for information technology services must be qualified to work in the pharmaceutical environment before activities can be outsourced to them. The outsourcing of the activities should be regulated in a specific contract known as the Service Level Agreement (SLA).

http://www.ogc.gov.uk/guidance_itil.asp (accessed 21. 03. 2007)

Previously published under http://www.nrw.de/, has since been removed from the Internet.



Рейтинг@Mail.ru Rambler's Top100