The regulations governing the serialisation of medicines are becoming more complex and extensive worldwide. Pharmaceutical companies and packaging service providers are obliged to give consideration to this landscape when selecting an appropriate software and database solution for serialisation and track & trace applications. They must seek to identify a solution that complies not only with all the current international requirements, but also with future needs.
When selecting a suitable serialisation software, it is crucial for pharmaceutical companies and packaging service providers to ensure that it not only satisfies the existing serialisation regulations, but is also capable of accommodating changing requirements. This applies in particular in view of the increasing complexity and scope of the serialisation projects and specifications that are currently being initiated and implemented in many nations across the globe. It is essential to understand that a supposedly quick and easy solution can have a detrimental impact on productivity, efficiency and security in the packaging and labelling process. Given the constant consolidation of requirements and processes, it can prove impossible to make changes quickly, and additional costs can be incurred. Preference is to be given to software whose system architecture can expand to accommodate growing requirements and future needs both regarding regulation and workflows.
As a general rule, the serialisation software is the most crucial component of a serialisation project and is therefore not to be regarded as merely an adjunct to hardware components or an update for existing programs. But what criteria should a user apply when searching for an appropriate serialisation software solution? Which are the most important factors? The discourse that follows provides some answers and serves as an aid to decision-making.
The serialisation of drug packaging, which will become mandatory in the USA from November 2017 and in the EU from February 2019, and is already prescribed in China and Turkey, presents a major challenge to pharmaceutical manufacturers and packaging service providers as regards suitable databases and software solutions.
In the past, companies implementing a serialisation project for the first time often focused on the hardware required within a packaging line to apply, inspect and, if applicable, save locally the relevant codes with serial numbers on secondary packaging on ISA-95 Levels 1 and 2 (machines and single packaging lines). It is now considered better practice to give closer consideration at the outset to the appropriate configuration of a database solution that is capable of reliably controlling and managing the necessary processes also across multiple lines (Level3), sites or even company-wide (Level 4) (see Fig. 1).
Figure 1: Serialisation software on Level 4 controls and monitors all Level-3 systems as well as contract manufacturing organisations (CMOs). It can also exchange data with both the internal ERP system and customers (wholesalers). Other important aspects are the central data repository for serial numbers and aggregation hierarchies, the exchange of data with country hubs, and the generation of transaction statements. (All graphics credited to Atlantic Zeiser GmbH)
The list of requirements is long. It ranges from the secure generation, management and storage of serialisation and aggregation data, as well as their transfer to national authorities, wholesalers or logistics partners, to the integration of existing or new hardware components and simultaneous production management for multiple lines. At the same time, data security must be ensured and productivity maintained. Against this background, many pharmaceutical companies and packaging service providers have serious concerns relating to reliable implementation. In most cases it becomes evident that an 'off the peg' software solution is unable to offer compliance with the complex and diverse requirements of serialization and track & trace applications.
The problem is well illustrated by way of an example. Pharmaceutical company A produces an expensive cancer drug in relatively small quantities on a single packaging line, but distributes it worldwide and has to comply with numerous country-specific regulations. Contract packer B, in contrast, packages medicines for a variety of customers in large quantities, but the products are destined exclusively for local distribution. Both companies must address the issue of serialisation – but their requirements concerning processes, workflow and data transfer could hardly be different. At the same time, neither company A nor company B is usually able to rule out having to offer a completely different range of services, even at very short notice, as circumstances change.
It therefore follows that the software architecture of serialisation and track & trace solutions should be sufficiently modular to allow flexible configuration according to the individual user's processes and requirements. In the absence of modular architecture, the software has to undergo costly revision, which ultimately adds to the user's costs. Given the certainty of future changes to processes and regulations, the ability to expand functionality and increase the scale of processes (e.g. the number of lines or aggregation levels) are also highly important factors – as illustrated by the most recent developments in China and Brazil. If the software is unable to accommodate such changes, significant additional costs can arise each time the serialisation or packaging process is modified. Furthermore the software has to be completely revalidated which in many cases represents the bigger cost factor regarding the need of time.
To identify an appropriate software and database solution, the first step should be to conduct an internal examination and analysis of the existing packaging process. Key questions in this connection concern where customer orders and production orders are initiated, and how the serialization data are reported back to authorities. If this is to be done through an existing enterprise resource planning (ERP) system, the serialisation software must have appropriate interfaces, and a suitable process has to be defined. If an interface to an ERP system is not required, the software should be able to generate the orders and manage them efficiently, even in complex cases.
Another important criterion for the software solution can be the visualization of warehousing or logistics processes, as required when repackaging and making up consignments for wholesalers – especially when aggregation is required.
No matter whether one or several medicines are being produced and packaged at the site, the complexity of the operation increases as soon as the product has to be exported to several countries where different regulations apply. In China the serial numbers are recently provided by the authorities, in the EU or US they have to be generated by the serialisation software. In addition, some regions prescribe consecutive serial numbers, while others apply the random principle (see Fig. 2). The general rule applies that serial numbers belonging to a defined range cannot be issued more than once. The numbers can be based on a Global Trade Item Number (GTIN) – an identifier for trade items developed by the not-for-profit organisation GS1.
Figure 2: Pharma companies and CMOs that serialise drug packaging must be able to comply with the vast array of different code formats and standards that exist worldwide.
As a consequence, the serial numbers contained in the codes must be held on file for a long predetermined period. It may also be necessary to run comparisons in order to recognise duplication if the numbers are allocated by an external source, as was the case in China and is envisaged for the future by Russia. Depending on the region, the serialisation data may have to be stored for at least six months beyond the medicine's expiry date or even for several years beyond the production date. This aspect is not to be underestimated, including when storage capacity is being specified for the necessary servers and other hardware.
It is to be assumed that the currently valid or imminent coding principles in individual countries and regions will be revised sooner or later, and that additional countries and new regulations – Russia is on the horizon – will need to be accommodated. If it is to be future-proof, the software solution must therefore be designed so that it can be adapted to suit changing circumstances. The greater the extent to which the serialisation and track & trace processes can be configured in-house without any programming, the faster the response and the lower the costs when changes need to be made.
Many countries prescribe not only serialisation, but also aggregation of the secondary packaging into packaging hierarchies in order to allow the seamless tracking of medicines throughout the entire logistics chain – thus accomplishing an end-to-end track & trace capability. This entails comparing the previously serialised individual packs against the serialisation database during the manual or mechanised packaging process in order to produce what are known as parent-child relationships (see Fig. 3).
Figure 3: Integrating camera systems and scanners enables serialisation software to visualise the aggregation process across numerous stages. For smaller batches manual packing tables with integrated cameras are a good alternative.
In the case of packaging by machine, note that defective and illegible packs can repeatedly impede successful aggregation and will need to be exchanged manually at the end of the process. If necessary, the serialisation software must also be able to model these operations on Level 3. At the latest for the purposes of repackaging and order picking in the warehouse, it should be possible partially to dissolve or redefine the originally established child-parent relationships. For users who already, or may in future, export to countries where a track & trace capability is mandatory, it is essential that the software and database solution accommodates these aspects. Such a requirement already exists in Turkey and is scheduled for implementation soon in the USA. Protocolls like EPCIS from GS1 seem to be a good standard for information interchange within the logistics chain. A suitable software solution should be prepared for that.
Before the process of serialisation and, if applicable, aggregation can begin, the relevant serialisation data for the individual products have to be defined as the basis for generating specific production orders with batch data and expiry dates in a further step. In the interests of maximising process security, the serialisation software should eliminate a particular source of errors – the human factor – as far as possible. When new product related serialization schemes are being created, for example, cross-checking and a release process involving several people are advisable. The software should allow such release processes to be configured accordingly and repeatedly revised.
The capabilities of a prospective software solution become apparent at the latest when production orders are to be allocated to multiple packaging lines at the same time. In this context, the complexity and necessity of a production management platform soon become apparent. Capable serialisation software should be able to oversee the production of a single batch on multiple lines at the same time without any risk of serial numbers being duplicated – even in the event of technical malfunctions and line restarts. The chosen solution should likewise be able to redistribute current jobs if relocating production at short notice.
If an enterprise already possesses an inventory of serialisation and aggregation machines, for reasons of economy the serialisation software should be capable of accommodating hardware components sourced from a wide variety of manufacturers. Bilateral communication between the machines and the software is essential because, apart from the regular transfer of codes and serial numbers, additional information also needs to be shared, such as user data or log files to allow the central generation of audit trails
Another conceivable scenario is the addition to packaging lines of functions or modules at a future date, either in order to increase efficiency or in response to changed market requirements, e.g. to facilitate the application of tamper-proof labels. In this particular case, it would be good practice to be able to record and store the linking of a serial number to the successful dispensing of a sealing label. The software architecture of a suitable solution should therefore be structured to allow the functionality of packaging lines or individual machine modules to be both expanded simply at any time and visualised economically and quickly – again also in respect of validation.
In addition, of course, all the data exchanged between the machines and centralised software should be easily exportable from the system depending on the user's requirements – whether relating to completed products with serial numbers, aggregation hierarchies or audit trails. Here again, an interface to the ERP system, as mentioned above, can be a useful resource if needed.
Most companies with multiple production sites that initiate a pilot project are likely to focus initially on a single line and ISA Level 2. In every instance, however, the expandability of a software solution's functions to encompass ISA-95 Levels 3 and 4 should be thoroughly explored and mapped out for the future from the outset. If the chosen software is unable seamlessly to grow along with your needs, significant additional project costs can arise in the medium term.
The availability of diverse interfaces and data formats for transferring the serialisation data to central databases on an international basis (hubs) is a further key point to bear in mind when procuring and installing software. Although governments have yet to resolve many of the details, and hubs are still being established, there is no reason to postpone the acquisition of centralized serialisation software. In fact, these circumstances represent another argument in favour of attaching the utmost priority to ensuring that the software solution can be modified at a later date, irrespective of whether data are subsequently to be transferred directly to the hubs and, if applicable, distributors, or indirectly by way of the ERP system.
Close scrutiny is likewise warranted in respect of both the data encryption methods and the general security standards applied in order to prevent unauthorised access to the database and illicit data transfers. Note that the entire IT infrastructure must be appropriately configured for this purpose as well.
It is essential that internal processes are thoroughly analysed and all current and future requirements are defined before serialisation software is purchased or even put out to tender. For this purpose it is highly advisable to establish an interdisciplinary project team assembled from various departments (IT, production, logistics, engineering, quality management, validation, packaging design). Sufficient time should also be allocated to such a complex project, but pressures are likely to increase in view of the approaching effective dates of statutory regulations and foreseeable capacity bottlenecks among software and hardware suppliers. Depending on the ISA-95 Levels that are to be implemented, a period of up to 24 months should be allowed from the start of the analysis to completion of the pilot phase, including procurement, implementation, validation and training both fore software and hardware. It must also be borne in mind that external partners, such as packaging printers, contract packers and, depending on the market, wholesalers, need to be integrated in the process as well, and that the relevant processes need to be defined and interfaces created in good time.
Generally speaking, the following holds true as regards the quality of prospective centralised serialisation software: the greater the modularity of its structure and the easier it is to make adjustments at process level concerning the integration of machines, the more future-proof the solution is likely to be (see Fig. 4).
Figure 4: Modular serialisation software allows individual modules to remain inactive until they are actually required.
Figure 5 is a schematic representation of the procedure to be followed for serialisation, using the example of a special software solution – it is valid for a single line or multiple lines (up to ISA-95 Level 3). The tasks and functions of the software are shown against a yellow background. The production orders are generated in an ERP system and forwarded to the serialisation software. At the same time, serial numbers are either imported to the database from an external source and checked for non-duplication, or generated directly by the software.
Figure 5: Schematic of the serialisation software functions required to model the ISA-95 Level 1, 2 and 3 processes reliably.
On the basis of predetermined product definitions – stored in the software after multiple cross-checking if necessary, batch-specific production jobs can then be generated and allocated to one or several packaging lines. The only available lines are those whose technical attributes, which are also managed by way of the software, satisfy the requirements of the relevant production job.
The lines report the production outcomes or results to the database, from where they can be exported together with audit trails and, if necessary, encrypted and transmitted to the relevant authorities; databases or wholesalers. In the interests of enhancing its performance capabilities, the database can hold large quantities of data. Figure 5 alone illustrates that ISA Levels 1, 2 and 3 entail a high degree of complexity, which increases further when ISA Level 4 is implemented as well.
A scalable software solution capable of easily assimilating additional functions, operation levels and aggregation levels is therefore essential.