Many countries prescribe both serialisation and the aggregation of secondary packaging into packaging hierarchies to allow the seamless tracking of medicines throughout the entire logistics chain — thus accomplishing end-to-end track and trace capability. This entails comparing the previously serialised individual packs with the serialisation database during the manual or mechanised packaging process to produce what are known as parent-child relationships (Figure 3).
In the case of packaging by machine, 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 at Level 3. At the very latest, for the purposes of repackaging and order picking in the warehouse, it should be possible to partially dissolve or redefine the originally established child-parent relationships. For users who already, or may in the future, export to countries where a track and 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 in the USA. Protocols such as 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.
Production management platform
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 serialisation 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 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 obvious. 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/when relocating production at short notice.
Integrating existing machinery
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 to increase efficiency or in response to changed market requirements (to facilitate the application of tamper-proof labels, for example). 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 at any time and visualised economically and quickly for the purposes 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 with 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 to grow according to your needs, significant additional project costs can arise in the medium term.
The availability of diverse interfaces and data formats to transfer 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 centralised 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 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.
Managing data with intelligence and legal certainty
The greater the number of lines and ISA-95 Levels that are to be operated by centralised serialisation software, the more important it becomes to implement intelligent user management. User rights are best managed by way of groups to which the individual users can be assigned. In this context, of course, compliance with general standards, such as 21 CFR Part 11, is to be ensured.
Interdisciplinary project team and time requirements
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 for 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 regarding 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 (Figure 4).
Possible workflow up to Level 3
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 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.
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 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.
