Document Imaging for Business Processes - a document warehouse for patient information, document management and archiving

Date
Thursday 13 July 2000

Venue:
The Board Room, Moorfields Eye Hospital, City Road, London, EC1V 2CD

Speakers:

Steve Entwistle, International Business Change Leader

Martin Lillis, UK Department Head for Document Management, Glaxo-Welcome

Introduction

The presentation proved to be as much about the management of change as it was about a system for document imaging in a particular business process handling clinical trials information. Both aspects should have important messages for the NHS now.

Both speakers briefly introduced themselves - Steve had worked as a nurse & mlso before joining G-W and is now a project manager, Martin is a chemist at G-W.

The project's purpose

The purpose of the project was to improve the handling of the large volume of paper generated during a clinical trial. The clinical trial process looks complex, but is driven by the need to log all events that happen to trial subjects. The incidents are logged on Case Report Forms (CRF).

Defining the problem

Definition of the Problem: the US Food and Drug Administration (FDA) require that by 2002 all submissions to them be electronically based. A paper mountain of 2.6m pages per year within GW and the challenge this causes for the security of data forms, their auditing, searching, accessing and archiving have all driven the move to automated document image handling.

The starting point

The starting point: A submission to the FDA can be up to 0.5m pages (100Gb), especially as they require 3 copies!

The solution

The solution: this had to be secure, validated, legally acceptable, fast, provide easy access, have world-wide capabilities, enable migration from an old proprietary system in use in the USA, and simplify submissions to the FDA. In the USA 100% of documents were scanned, there was no scanning in the UK.

Driving factors

The driving factors were the need for electronic submission, concurrent viewing, immediate access, all of which would lead to cost reduction. Other needs were: Compliance (security, recovery, version control, internal and external audit); quality and credibility; productivity (desktop access, concurrent access on an international scale, parallel processing).

Why scan paper?

GW is moving to away from paper-based working, so the question arises 'why scan paper?' The team examined scenarios to show that there was still a case - the demise of paper was still some way off and there were savings that could be made.

Controlling the project

Project control was complex, made so by a combination of factors: covering 26 countries, varied user groups (researchers, regulators, data entry staff), differing views from the user groups of the balance between benefits, cost, quality and time (speed and centralisation by the centre, reduced travel and better use of staff time by operational sites), imposed requirements (laws and regulations, company standards, available supplier and technology.)

All of which resulted in a large requirement specification.

Change management: costs were estimated between £0.5 and £6m, risk assessment covered people, technology, project control, complexity and novelty. This lead to a high risk rating for the project.

Consequently the project board was chaired by an international director, with the regulatory division identified as a key customer. GW has a decentralised structure, which causes some conflicts for a centralised project. However the work was in effect a series of sub-projects: image migration (for the USA based system - EDMIS), disaster recovery, index automation (ie. bar-coding each page), change management and training.

System development

System development went through the usual stages- project definition, justification, user requirements, prototyping, technical specification, image migration, design stage, system stability, network impact, system standards, procedures and development of an export tool.

Testing and validation

Validation was essential but hard work and easy to underestimate the effort required. Without validation the system would not be trusted and could not be used for FDA submissions. The user requirements, functional and system requirements, interactive testing and prototyping all required development of a validation plan, a system test plan leading to user acceptance planning and testing (UAT) and finally a system incident reporting method for when the system was live.

The test and validation reports led to a second round of system and UAT and finally an acceptance report sign-off. The desired outcomes were fewer data errors and their earlier detection, faster database closure - a CRF was complete in 24 hours, less resource to search for data, an ability to handle different document types, and reduced travel.

What has it produced?

The project has built: index and scanning tools, different document types, database design and storage media, web based retrieval, an export tool, and the software supplier has other solutions to add to the system that they would like to implement. The technical solution as based on Oracle RDBMS, 5.24 WORM, based on an optical jukebox.

In summary - the data was being stored in its most useful form; it added value to the paper form and presented a standard access method to all users. The production costs had fallen, as had cycle times. ie. most of the intended benefits had been achieved.

Some practical details - before and after images of the documents are being taken as the paper-based records are still being used for hand-written annotations during the verification process.

Critical requirements

The four critical requirements were identified as :

  • A compelling business case
  • An active sponsor
  • A good communication plan
  • Clear decision processes

Question Time

The presenters then answered a wide range of questions and joined in a general discussion until time was called.