The Four Phases of Transitioning from Paper to Electronic
Introduction
In a world that is rapidly digitalizing, working with paper sources is becoming less and less sustainable. New and/or updated regulations from virtually every regulatory agency (MHRA, FDA, ICH, EMA, WHO, etc.) increasingly emphasize the control of electronic records. Therefore, it is a logical step to transition your operation from paper-based to paperless or fully electronic. Such a system, if properly implemented, can lead to quality improvement and efficiency gains. However, this is not a simple task and must be carefully considered, managed and implemented. The approach described below is generally applicable to any system that converts paper input into an electronic format. Examples are electronic batch records, electronic laboratory notebooks, project management systems, quality management systems, training records, etc.
Phase I: Recognize the Need
The first and most important phase is recognizing and acknowledging the need for the transition. This can be a need for ease of operation on the shop floor and/or the desire to increase efficiency and traceability, reduce errors and improve quality. From there, the full commitment must be given from the top down in the organization to make it a success. Only by envisioning the future and embracing the change can the program be successfully launched.
Phase II: System Selection
Phase II consists of selecting the system. A proper in-depth examination of the system should be performed to assess its suitability. Do not believe the sales stories and smooth demos. Explore and investigate a system to really learn more about it. The mindset must be all about change. Do not expect a system to produce ‘the electronic version of the paper processes’. This will not bring efficiency or quality, but only an unworkable and unacceptable system. There are many existing and emerging solutions available. Examples of electronic (lab) notebooks and Lab Execution Systems include Labguru, Benchling, LabArchives, eLabJournal, SciNote and IDBS e-workbook. As for Electronic Batch Records or Manufacturing Execution Records, there also many choices, such as Lonza MODA-ES, Batchline, InstantGMP, MasterControl, Amplelogic and SimplerQMS.
Choosing a system is only one step in the entire transition process. No system will fit perfectly with the existing (paper) processes and probably will not support it in that way. As a result, processes will (or must) be adjusted and the system may require customization or (full) development. It may also be required to make additional investments in associated hardware and software, such as barcode scanners, portable devices for real-time entries, updates to other software to enable integration, or possibly even replacement of older systems. Consider how the new system will be used: will it be part of an integrated IT landscape as a single, stand-alone system, or even (one of) the central system(s)?
Regulations dictate full data integrity controls, such as controlled access, audit trail (and review), data flow and definition of raw and processed data, etc. These should be properly assessed when considering purchasing and throughout the implementation process. Keep in mind that data must also be archived, so check the system if it is appropriate to allow this. Full validation of the system and associated processes is of course required.
Phase III: Dedicated Team
Phase III is creating a team. In addition to the usual stakeholders and product owner, it is essential to have a dedicated team consisting of:
- a lead / project manager;
- skilled developers / modifiers;
- testers;
- subject matter experts (SMEs);
- an independent process writer.
The size of the team depends on the scope of the implementation, such as single/multiple site, full/partial transition, expected time frame, etc. The number of testers should be equal to the number of developers, because testing is not only checking whether the system works, but also whether the new processes associated with the change are clear, workable and properly implemented in the system.
The team must be committed to this transition. It cannot be done alongside regular work. The sooner such a team is involved in the process, the better the results will be and the easier the system will be accepted. Since the pharmaceutical industry is very specific, it is advisable to find a team that has in-depth knowledge of your organization and processes. They can learn ‘IT’ (customizing a system, code language, typical IT approaches and processes). Teaching IT‑educated personnel the (details of the) pharmaceutical industry has proven very difficult, with many misunderstandings, unwanted deliveries and even personnel turnover due to miscommunication and dissatisfaction. While there are many regulations and processes, the success of the industry is often in the experience and the small (unwritten, but obvious) details. Having an independent process writer with business knowledge is essential as process owners may or may not be involved in the implementation and thus lack knowledge of the system.
Phase IV: Implementation of the System
The final phase (IV) is the implementation. If deploying a custom or full development system, it is essential to create an agile motion of releases. This transition is complex and can take a long time. Therefore, it is important to give the finished parts of the product to the organization early (after approval by the SMEs). Although the system may not be complete or perfect, it is recommended not to keep both a paper and an electronic process side by side. This will create confusion and introduce errors. It is therefore recommended that, as soon as any part of the system has been delivered, the paper trail should be decommissioned immediately.
The first version of some functionalities probably will not be perfect, but it should be functional. Feedback, increasing knowledge about and experience with the system is essential to improve the product and tailor it to the needs of the organization. Please note that new/updated processes should be final once the releases are completed. While releasing in agile mode, it is important to keep an eye on the initial scope and be aware of scope creep. Too often a team is focused on perfecting already released products instead of expanding the system with functional modules. The same can be said about the receiving party. So deliver quickly, update quickly, but prioritize.
Work with the capabilities of the system to increase efficiency and quality. For example, a paper-based process requires one person to select (and use) material for processing and a second person to do a cross-check the material. The system can help when using barcode scanners. One person can still select the material, but the system can act as a second checker. The first person has manually selected the material and then checks with the barcode scanner connected to the system whether the correct material has been selected. The system can approve and allow to continue, or the system will block the continuation if the wrong material is selected. As a result, the person does not have to wait for a second person to check (efficiency) and the system helps to select and use the correct material (quality).
As these are validated systems, validation plan(s), User Requirements, testing (IQ/OQ/PQ) and reporting are required. This also means that change management is necessary. For example, changes to the system must first be described (unless in a critical hotfix, where this can be done afterwards), prioritized and only then implemented. Changes to data are likely to be requested, especially shortly after startup. When introducing a new system, training will be essential, but it will not completely eliminate the possibility of human error. It is then quite natural to request a change of data. This should be considered very carefully if it could be done at all (regarding data integrity). For example, a wrong entry from a non-existent device can be hidden (or deleted) after a helpdesk ticket (or similar) has been created. If a wrong weighing has been performed (e.g., the system was not set to zero prior to weighing), this data should never be hidden or deleted. Although the data is wrong, it is still raw/source data. Instead, this data should be kept and handled in the same way as on paper (i.e., made obsolete, with a remark). The IT/Development/Implementation team can only be the executor in this case; the ownership and responsibility for the data still lies with the organization.
Progress can help
Progress has experience with these programs and can help you design and implement your transition from paper to electronic. Working with a multidisciplinary team, years of experience and a personal approach are the most important aspects for Progress to make every project a success. Reach out and learn more about how Progress can partner with you and your organization.
