International Society for Blood Transfusion Guidelines for Traceability of Medical Products of Human Origin

Medical products of human origin (MPHO) are products that come from a human donor and are intended for clinical application in a human recipient. Due to their human source, they carry the risk of infectious disease transmission, incompatibility and other adverse reactions. This makes MPHO products of an exceptional nature and strict traceability requirements must be maintained to identify the MPHO and its constituents every step of the way until final disposition and to ensure traceability from donor to recipient and vice versa. In some instances, traceability records are required to be maintained for long periods that can exceed 30 years based on country or local regulations. Some MPHO may be deemed not suitable for clinical application, and there may be additional traceability requirements for these products. It is important that all those involved in the chain of custody of MPHO, at all levels, understand the importance of traceability and their role in maintaining the traceability pathway. Traceability regulations do differ between countries, and requirements may be different for MPHO shipped internationally. Contractual expectations between supplier and customer may also differ. These guidelines were developed by the Traceability Task Force of the International Society of Blood Transfusion Working Party on Information Technology (ISBT WPIT). The purpose of these guidelines is to provide recommendations on ensuring that MPHO can be traced regardless of the extent of computerization used in record keeping. The ability to accurately trace the products from donor to recipient and from recipient back to the donor is a cornerstone of patient safety and involves those collecting, testing, modifying, distributing, shipping and using the MPHO in patient care. Technology is rapidly advancing. These guidelines should serve as a basis for evaluating the current system and developing plans to ensure changes to system maintain traceability. This guideline is focusing on the traceability of blood and cellular therapy products. However, much of the information and guidance provided is applicable across all areas of MPHO. It is intended to provide best practices in capturing and maintaining a robust record of processes involving the collection, manufacture and disposition of MPHO. It does not replace local or national regulations. Such regulations would supersede these guidelines. Accreditation institutions may have standards that also affect traceability requirements. Traceability of MPHO is defined as the maintenance of a permanent continuous information trail beginning with the selection of donors of MPHO and continuing through procurement, processing, testing, distribution and recipient matching to the final disposition of all the sub-products, ensuring timely tracing from donor to recipient and vice versa is possible. This core level of traceability is essential for all MPHO products and is often required by regulation. It is necessary to support biovigilance activities including product recall and lookback. Traceability is also a tool in quality management that provides detailed information regarding who did what, where and when on a particular process, and what supplies, reagents and equipment were used. This additional traceability information provides lookback information that is useful in performance monitoring and conducting root cause analysis. Traceability information may be captured manually, electronically or by a combination of electronic and manual processes. Traceability steps should be embedded in the workflow of all critical processes. Responsibility for traceability lies with both the organizations responsible for any part of the MPHO chain of custody and also with each individual responsible for handling these products or the information associated with them. Each organization working with MPHO should have an established and actively managed and audited quality system. Traceability requirements should be integrated into this system and all relevant procedures should specify the traceability steps associated with the process. End-to-end traceability must be ensured and verified through traceability audits (end-to-end within the organization including interfaces with other organizations). Additional information can be captured to further enhance traceability and an example is shown in Table 1. Organizations are responsible for the long-term retention of traceability information and for ensuring procedures that are maintained for retrieving this information promptly. If organizational change such as acquisition, merger or closure occurs careful attention must be paid to the ongoing security of traceability information. Particular care must be taken in the transcription of traceability information as an error can result in a breakdown in the traceability chain. Any perceived failure in traceability should be immediately reported and investigated. Mitigation of transfusion-transmitted diseases: If the donor has a disease transmissible by transfusion or transplantation that was undetected at the time of donation or has a high-risk behaviour that could have affected his/her eligibility to donate that was only discovered after donation, good traceability records allow facilities to quickly: The purpose of traceability is to ensure that an information trail is maintained between the donor and the recipient(s), processes related to preparation are retained and the information can be retrieved quickly. This requires a system to ensure the unique identification of each MPHO product, a secure mapping from the donation to the donor and mechanisms to accurately capture and store critical information. It is preferable to use electronically readable information (e.g., barcodes) and to have data saved electronically in a well-structured Information Technology (IT) system. It is possible to perform traceability in a manual capture and paper-based system; however, it is more laborious and open to errors, requires space for record preservation and storage and is slower. All organizations involved in the MPHO chain of custody should have an established and well-controlled quality system. Procedures should identify the elements of traceability that must be documented (see Table 3) and staff should be trained, and their competency assessed. Traceability should be achieved by real-time tracking and recording each step of the lifecycle, from donor screening to the MPHO being transfused/transplanted into the patient or allocated for any other intended use. It is recognized that traceability of MPHO from the donor to the recipient and vice versa is necessary for biovigilance. Many factors impact the effectiveness of traceability. Each collection of an MPHO, each step in the manufacturing process and each movement of an MPHO from one location to another should be clearly and concisely documented. Where possible, identifiers in records should be electronically readable/storable to avoid potential transcription errors. In some situations, the MPHO product is collected and infused/transplanted within the same organization. Traceability in this instance is straightforward. In other instances, a single MPHO collection can result in multiple products that may be further divided and/or pooled with components from different MPHO collections. These products may then be distributed to various unrelated sites, further modified or distributed to additional sites. For example, pooling platelets or cryoprecipitate would require both a new product identifier and a confirmed link to the components that were used to create the pool. To further complicate the scenario, components may be combined in large batches for further manufacturing of lot number-based products. Starting material for a cellular therapy treatment for a patient may be collected at one site, sent to one or more sites for processing and ultimately sent to another site for infusion. The examples below detail a few scenarios that demonstrate the complexity involved with the traceability of an MPHO product. Blood Donor Centre (whole blood collected, processed to produce red blood cell [RBC], tested and distributed) → Transfusion Laboratory X (received RBC and transferred out) → Transfusion Laboratory Y (received RBC, divided into four parts) → Parts A and B transfused to patient 1, Part C transfused to Patient 2 and Part D discarded. Donation is recalled due to information obtained on subsequent donation. In this instance, it must be possible to track the donor and the products made from the donation, from the Blood Centre to the Transfusion Laboratories and then to the point of use, accounting for each product and identifying all recipients. Transfusion Laboratory receives platelet products from two different blood centres. The transfusion service pools six platelets each from a different donor: three platelets originating from Blood Centre A and three from Blood Centre B. The pool is given a new identification number (pool number). The pooled product is transfused. The patient contracts an infectious disease. In this instance, the Transfusion Laboratory must notify each Blood Centre of the donation identification numbers in the pooled unit. The Blood Centres must be able to trace back to each source donor, all products derived from the current donations and any previous donations from the donors. Cells are collected, split and sent to three manufacturing facilities. Facility A makes three different products from the original product. The first of these manufactured products is further spit into 100 vials. The second product, from Facility B, is further manufactured and is split into 15 containers. The final product that was sent to Facility C is further processed and sent to six different distributors. At the core, each institution must have a mechanism to track and trace each MPHO from its point of origin or receipt to its final disposition within that institution. Each step in the collection, manufacturing and distribution processes must be documented transparently. Each holder of the product must be able to provide relevant information to either the previous holder of the product or the subsequent holder of the product. Traceability records need to be retained for long periods often specified in the regulation. For example, the European Directives require traceability information for blood, cells and tissues to be retained for 30 years following clinical application. Over long periods, information storage systems change and may become unusable. Information management plans need to be in place to ensure that storage media are updated regularly and information retrieval procedures are kept up to date. Organizational change (takeovers, amalgamation and closure) can also impact traceability and plans need to be in place to manage archive information. If an electronic system that contains traceability data is replaced with another, it is important to keep traceability in mind when deciding which data need to be converted from the old system to the new one. Risk management is the process of having a contingency plan to prevent risk occurrence or reduce undesirable outcomes as much as possible. According to the International Organization for Standardization (ISO) 14971 for Medical Devices Risk Management Assessment [5], risk management is described as the systematic application of management policies, procedures and practices to the tasks of analysing, evaluating, controlling and monitoring risk. Each facility is responsible for evaluating the risks of its traceability processes and procedures and taking action to reduce those risks. Once key traceability information is established for each MPHO, the ability to trace an MPHO from its origin to its final disposition and vice versa is only as good as the records retained. Retained records should be electronically readable to avoid transcription errors. To ensure accuracy, permanent records should be created concurrently with collection, processing and distribution steps. At a minimum, sufficient information should be captured to ensure continuity of the traceability pathway between donor and recipient, including key identifiers and links to previous and next points in the pathway (i.e., donation identification number, product code, where received from, where distributed to and date of record). Organizations responsible for collection and clinical application must retain information linking the donation to the donor and recipient, respectively. Additional desirable information includes who created the record, and identification of operators, critical supplies, equipment, testing and critical steps used in the manufacturing process of each product. National regulations and accrediting agency standards will describe the specific documentation to save and the retention periods. These vary from country to country. For example, the specific time to retain MPHO-related information ranges from 5 years to at least 30 years depending on the specific kind of MPHO, national regulations and accrediting agency standards. Table 4 describes key traceability information to retain and the reason for retention. If current data (data in use) is lost, a plan should be in place to retrieve data from backup resources, validate it to ensure accuracy and restore it for ongoing use. The restoration and validation should be fully documented. Policies, processes and procedures should be in place to assure that backup data is: always readily available, stored appropriately (locally and remotely) to preserve the data and tested periodically to assure integrity. Any legacy equipment required to access data should be available and in working order. Procedures and effective risk management should ensure that catastrophic data loss does not occur. However, if all data is lost and there is no backup or the backup cannot be restored for some reason (disaster, lack of legacy equipment, legacy equipment failure, etc.) the entire process must be documented as to why the backup failed or could not be restored and what will be done to assure that this will not happen again. All policies, processes and procedures should be reviewed to make sure that they are updated and reflect changes for accurate future data restoration. In some cases, it may be possible to reconstruct the traceability path by a reverse search. For example, if a blood centre loses information on where a product was sent, it may be possible to query all likely recipient organizations to locate the receiving facility indirectly. In its simplest form, data migration is the movement of data from one storage area to another where no change to the data is needed, for example, where one storage disc is replaced with another identical disc and data is copied from one to another. However, data migration is generally a lot more complex as manipulation of the data is usually required to move it from one system to another (e.g., when IT systems are upgraded or replaced with a new system). When large amounts of data are involved, automated data migration processes should be employed to ensure standardization of the process. Minimizing the amount of human intervention will reduce the potential for error and cut down the time it takes to complete the migration. Data migration can adversely impact operations by causing extended downtime, data integrity issues (which may impact donor, component and patient safety) and costly rework if the migration steps are not adequately designed, controlled and documented. Gaining an understanding of the data to be migrated and the relationships between data items will help identify which items of data are to be migrated. It is vital to identify all data needed to maintain the traceability chain and ensure those items are included in the migration. Where partial migrations are being run it is possible to miss data essential for traceability which will cause future issues should tracing be required and may irretrievably break the chain. It is less of an issue when all data is being migrated. The main objective then is to ensure that data relationships and context are maintained. It is common to find some issues with data quality in any IT system, for example, duplication, redundancy and miscoding. It is therefore recommended that a data cleansing exercise is undertaken before data migration. Removing unnecessary data and correcting data values and representation will simplify the design process, reduce the likelihood of errors and cut down the time needed to migrate. It is unlikely that two systems will hold exactly the same data in the same format therefore moving data from one system to another usually requires some degree of data mapping and/or conversion. Where data mapping is required, for example, where one coding system is being replaced by another, a one-to-one link has to be created between the old and new code. This mapping will be held in a table and used during the migration process to convert items to the new coding system. If the data has to be traced back, this table will be a vital tool to help understand the history of the data. Where data has to be converted from one format to another, for example, date format, the rules for the conversion need to be written in such a way that all data variations are considered, and the conversion process results in a standard output. Again, these rules need to be documented as they could be instrumental in understanding what has happened to the data sometime in the future. Once the data to be migrated is identified and mapping and conversion rules have been established the utility to carry out the migration needs to be designed and created. The objective should be to create as automated a process as possible that can be run and re-run giving consistent results each time. The data migration utility is essentially an ETL process (extract, transform and load) that pulls the data to be migrated from the original system, transforms it using the mapping and conversion rules to the new system presentation and loads it into the new system. Responsibility for each step may reside with different parties (e.g., multiple system suppliers, IT departments and user departments). Communication, activity and expectations all need to be carefully managed. It is very unlikely that a data migration will be correct on the first run; therefore, this utility should be documented in detail, version controlled and placed under change management from the outset. It could be vital for traceability that the processes, mappings and conversions used in this utility can be retrieved and understood at a future date. As previously noted, systems can differ in the data they hold and need. It is quite usual for the receiving system not to have a defined space for all the incoming data. Judgements will need to be taken on the criticality of such data and decisions made as to how it will be handled. Option 1 will cause issues at some point in the future as technology changes and becomes outdated. Choosing option 3 can add complexity to system development, configuration, data migration and validation, but it has the advantage of keeping all data together in one place. Another equally common problem for data migration is that the new system may have the ability to hold data items that the old system did not. For a migration, this is not a problem as these data fields are just not populated during the migration. A decision is then needed to determine if they need to be populated going forward and if a historical update is needed and feasible, and if not, they remain empty. A potential problem arises, however, if the population of the data field is mandatory for the new system. Failure to populate may cause operational issues going forward. The solution here is to derive and populate the necessary data item as part of the migration process if possible or to agree on a standard default value for migrated records, ensuring the rules are documented for each data item in question. Initial migration runs should be performed on a test system and a thorough validation should be performed. This should involve data checks on a select number of records that cover all critical data combinations, and statistical checks to ensure pre- and post-migration statistics match. Once the data migration utility has been run and the data is available in the new system, statistical checks should be repeated to ensure that all expected data has been moved. Record sampling should take place to ensure mapping, conversions, derivations and defaults are accurately in place. At this point, backward traceability should be tested to ensure that the traceability chain is not broken. Any issues discovered at this stage should be addressed as it may not be possible to address them once the migration is complete and operation on the new system begins. Documenting the data migration approach, rules, processes and outcomes is essential to ensure that going forward traceability is supported. Detailed documentation will reduce the risk of data being lost or misunderstood in the future, and it will greatly reduce the cost and effort of traceability exercises as people and years move on; see Table 5 for considerations for good data migration practices. Regulations in many parts of the world require that traceability information be retained for very long periods, for example, in the European Union, for at least 30 years for blood, tissue and cell products [6, 7]. Historical data need to be managed and protected to meet the same standards of confidentiality and security as the live database. Effective traceability depends upon key identifiers remaining unique throughout the domain that the MPHO circulate in and across the period of record retention. The donation identification number provides the key identifier for an MPHO donation, its samples and test results, and for each of the products derived from the donation. The donation identification system must be able to ensure that donation identification numbers are not repeated within the data retention period. The ISBT 128 international standard uses a donation identification number structure that ensures uniqueness at the global level for a period of 100 years [8]. If historic records do not use such a numbering system, there may be duplication of identifiers over time. The archive system needs to accommodate this and ensure the integrity of the distinct records. When MPHO are shipped to one facility and then transferred to another facility, there is the possibility of breaking the chain of identity when products are renumbered and the link between the two numbers is broken. Policies and procedures that ensure complete data recording and methods to search for renumbered units should be included in the policies and procedure manual of the facility responsible for the renumbering. The ability to trace MPHO may be lost when facilities are merged or closed. To ensure traceability, the facility must have a plan for data preservation. In some countries, a governmental agency may be responsible for the data. In other situations, it may be the responsibility of the management of the facility to have a plan for the storage of, and access to, the data from the closed or merged facility. Where data must be converted from one format to another (e.g., date format), the rules for the conversion need to be written in such a way that all data variations are considered, and the conversion process results in a standard output. Again, these rules need to be documented as they could be instrumental in understanding sometime in the future what has happened to the data. Consideration needs to be given to deleting archived data once the need for retention has passed. Data protection regulation permits data to be retained when there is a legitimate need. Once the regulatory retention period has expired, there is no longer a legitimate need to hold the data and failing to delete it may lead to infringement of data protection regulation. Archived data is usually stored on media, and using software applications, that are current at the time of archiving. Over the long periods required for storage, technology will have moved on and systems capable of reading the media may be rare or unobtainable. The archiving strategy should be reviewed at defined regular intervals and data transfer to modern media undertaken promptly. Such data transfer may be complex, and sufficient time and resources will need to be provided. When archived data is being maintained on older systems, such as read-only legacy systems, it is important to ensure that the skill set required to operate the system is retained. At all times, there should be at least two individuals in the organization who are competent to perform the necessary lookback operations. If the maintenance of the legacy system is contracted to a third party, the same requirement will need to apply, and contracts should specify the need for a minimum number of contractor staff with the necessary skills. Standard Operating Procedures (SOPs) and staff training for utilization of the legacy systems mitigate this problem. Consideration should be given to alternative archiving methods as new technology becomes available. All systems containing sensitive information should be covered by the organization's data protection and security policies and should be subject to security audits. These policies and procedures must meet the same regulatory requirements as live data. Where data is transferred to more modern archive systems, the old database will need to be handled in a manner that ensures that all sensitive data is removed before disposal. Authority to access or restore information should be limited and may be different from the live system. Consideration needs to be given to the time required to initiate and perform a traceability action in the archived system. In some cases, particularly where the implicated product may still be in stock, a delay in the traceability search could result in the additional transmission of infection. In general, data will not be archived whilst the product remains in stock, but products with very long shelf lives (e.g., frozen red cells) may remain in the supply chain for very long periods after they were distributed. The recovery time for archived information will depend upon the archiving strategy employed. Organizations should adopt a risk-based approach to archiving and should establish target recovery times for archived data that can be verified through a local audit programmed at defined intervals. Periodic audits of IT documents and processes are an essential part of a quality management system. Audits provide evidence that regulatory requirements are being met. The focus of the audit should include high-risk activities as identified in a risk assessment or those critical items in the operational qualification (OQ) and performance qualification (PQ) of the user requirements. Many regulatory agencies and standard-setting organizations require that there be a written process in place to assure that traceability is defined and audited to assure that MPHO can be traced from donation to final disposition. Requirements include unique identifiers, critical equipment, materials used in processing, lab samples, donor records and patient records. Both internal and external audits should be performed periodically to assure the robustness and continuity of traceability. External audits may be performed as a part of ordinary inspections by accrediting organizations, regulatory bodies, competent authorities or external consultants. The frequency and type of audit may be determined by regulatory or standard-setting organizations. Audits may be performed once, periodically or may be performed on an ongoing basis. The scope may be broad or limited to one element. Commonly performed audits include lookback tracing, policy and procedure audits, operations audits and tracer audits. An audit schedule and plan should be documented. It is the management's responsibility to review the report, make recommendations and ensure action was taken to correct existing problems and implement preventative actions. This is the first version of traceability guidelines written by the ISBT Working Party on Information Technology. The Traceability Task Force thanks the ISBT for the opportunity to work on these guidelines. Funding for virtual meetings was provided by ISBT. W.B.: Australian governments fully fund Australian Red Cross Lifeblood for the provision of blood products and services to the Australian community. All authors contributed to the literature research, writing and editing of the document. P.A. and S.B. were co-chairs of the Traceability Task Force of the WPIT. S.B. was the Chairperson of the WPIT. M.C. is the CEO of Swiss SCWeb company and the scope of the company is ‘Design and development of specific application software for tracking of healthcare professionals’ activities’.