Pilot Deployment Report - Bridge€¦ · · 2012-01-25Pilot Deployment Report. Authors: Robert...

Building Radio frequency IDentification for the Global Environment

Pilot Deployment Report Authors: Robert Lilley, Phil Parkins, Tony Walsh, John Jenkins

July 2008 This work has been partly funded by the European Commission contract No: IST-2005-033546

© BRIDGE Project Version 2.0 21st July 2008

About the BRIDGE Project:

BRIDGE (Building Radio frequency IDentification for the Global Environment) is a 13 million Euro RFID project running over 3 years and partly funded (€7,5 million) by the European Union. The objective of the BRIDGE project is to research, develop and implement tools to enable the deployment of EPCglobal applications in Europe. Thirty interdisciplinary partners from 12 countries (Europe and Asia) are working together on : Hardware development, Serial Look-up Service, Serial-Level Supply Chain Control, Security; Anti-counterfeiting, Drug Pedigree, Supply Chain Management, Manufacturing Process, Reusable Asset Management, Products in Service, Item Level Tagging for non-food items as well as Dissemination tools, Education material and Policy recommendations. For more information on the BRIDGE project: www.bridge-project.eu This document results from work being done in the framework of the BRIDGE project. It does not represent an official deliverable formally approved by the European Commission.

This document:

This is a truly ground-breaking pilot on an international scale; no team, to our knowledge, has designed, installed and successfully operated such a complex piece of Track, Trace and authentication within the ‘real’ pharmaceutical supply chain, anywhere in the world. Work Package (WP6) has implemented and piloted a fully operational drug product tracking system using the EPCglobal network for supply-chain wide data collection and used Data Matrix symbology on all levels of product packaging – item, bundle, case, pallet and vehicle for the first time. In addition, RFID tags were used at case and pallet level in Hybrid labels (with printed bar codes) and some pallets were also fitted with active RFID tags to enable GPS tracking across national borders and shipping routes. This was an addition to the original project design but again offered a ground-breaking piece of work. This use of interoperable RFID and printed bar code carriers should set an example to all of how such a practical system can function successfully in the real world.

Disclaimer:

Copyright 2008 by (Domino UK, JJA) All rights reserved. The information in this document is proprietary to these BRIDGE consortium members This document contains preliminary information and is not subject to any license agreement or any other agreement as between with respect to the above referenced consortium members. This document contains only intended strategies, developments, and/or functionalities and is not intended to be binding on any of the above referenced consortium members (either jointly or severally) with respect to any particular course of business, product strategy, and/or development of the above referenced consortium members. To the maximum extent allowed under applicable law, the above referenced consortium members assume no responsibility for errors or omissions in this document. The above referenced consortium members do not warrant the accuracy or completeness of the information, text, graphics, links, or other items contained within this material. This document is provided without a warranty of any kind, either express or implied, including but not limited to the implied warranties of merchantability, satisfactory quality, fitness for a particular purpose, or non-infringement. No licence to any underlying IPR is granted or to be implied from any use or reliance on the information contained within or accessed through this document. The above referenced consortium members shall have no liability for damages of any kind including without limitation direct, special, indirect, or consequential damages that may result from the use of these materials. This limitation shall not apply in cases of intentional or gross negligence. Because some jurisdictions do not allow the exclusion or limitation of liability for consequential or incidental damages, the above limitation may not apply to you. The statutory liability for personal injury and defective products is not affected. The above referenced consortium members have no control over the information that you may access through the use of hot links contained in these materials and does not endorse your use of third-party Web pages nor provide any warranty whatsoever relating to third-party Web pages.

http://www.bridge-project.eu/�

BRIDGE – Building Radio frequency IDentification solutions for the Global Environment

D6.5 Pilot Deployment Report 3/54 21st July 2008

Note

The views expressed in this document are the views of the joint authors and the Community is not liable for any use that may be made of the information contained

herein.



CONTENTS

t 1 Introduction .................................................................................................................... 8 2 Overview of the Deployed Solution ................................................................................. 9

2.1 Outline ................................................................................................................... 9 2.2 Technical Architecture...........................................................................................11

3 User Systems Installed ..................................................................................................18 3.1 Manufacturing installations ....................................................................................18 3.2 Distributor Installations ..........................................................................................36 3.3 Wholesaler installation ..........................................................................................39 3.4 Hospital Installation ...............................................................................................44

4 Operation of the Pilot .....................................................................................................47 4.1 Timescales ............................................................................................................47 4.2 Training .................................................................................................................47 4.3 The problems faced and how they were addressed ..............................................49 4.4 User issues and reactions .....................................................................................51 4.5 Pilot Management .................................................................................................53

5 Appendix .......................................................................................................................54



ACKNOWLEDGEMENTS

The implementation of this pilot has been due to the teamwork of the different parties each bringing their knowledge, experience and skills to solve the issues raised during the project. We would like to thank each of the parties involved no matter how small their involvement was during the project. Supply Chain Partners Sandoz Actavis Tjoapack Athlone Laboratories Kent Pharmacies CPG Movianto UniChem St Barts London Hospital Equipment Suppliers Cognex Domino UK Limited Impinj Pepperl & Fuchs QinetiQ Zebra Bridge Partners JJ Associates - For overall programme and project management, who had the task of co-ordinating all the different parties and bringing us together to complete the pilot. Melior Solutions –Technical design and software development. Domino - Deployment of the solution at each site and for giving up their weekends to fit in with the production cycles of the manufacturers. GS1 UK - Providing the technical advice about the coding structures Verisign Inc – For providing the EPCIS Databases



Executive Summary This is a truly ground-breaking pilot on an international scale; no team, to our knowledge, has designed, installed and successfully operated such a complex piece of Track, Trace and authentication within the ‘real’ pharmaceutical supply chain, anywhere in the world. Work Package (WP6) has implemented and piloted a fully operational drug product tracking system using the EPCglobal network for supply-chain wide data collection and used Data Matrix symbology on all levels of product packaging – item, bundle, case, pallet and vehicle for the first time. In addition, RFID tags were used at case and pallet level in Hybrid labels (with printed bar codes) and some pallets were also fitted with active RFID tags to enable GPS tracking across national borders and shipping routes. This was an addition to the original project design but again offered a ground-breaking piece of work. This use of interoperable RFID and printed bar code carriers should set an example to all of how such a practical system can function successfully in the real world. The adoption of the 4 string data structure, as originally used in the Irish Blood Trial of 2006, was very forward thinking, as this structure is now being used by EFPIA as part of its European vision, in Turkey for its new reimbursement system and being considered by California and FDA in US and may yet become the blueprint for the first globally accepted data structure used in the pharmaceutical industry at item level and beyond. The serial number element that forms an integral part of the data structure is critical, simply because of its unique nature. Every single pack of every single product being tracked had a different and unique serial number associated with it. Using this and the process of aggregating the contents to other unique serialised packaging levels the EU Bridge team were able to provide full traceability of a single item from the packaging line, throughout the distribution supply chain to the precise delivery point at the hospital pharmacy and every associated link to other pack types along the supply chain. Full use of GS1 and EPCIS systems including the use of GLN (Global Location Number) & GRAI (Global Returnable Asset Identifier) numbers for physical assets and locations as part of this pilot will once again make it ground-breaking. Linking these GS1 code standard number formats to other data carriers such as Data Matrix, GS1-128, SSCC and RFID tags and data structures has again expanded the knowledge and use of how to integrate these ‘tools’ into a fully functioning solution. The selection and use of a range of different printing technologies, substrates, line speeds, various types and sizes of container or pack not only added to the complexity of the challenge but also to the success of the whole pilot. Choosing to work with both original pharmaceutical packers/manufacturers and contract packer allowed the team to test the two most used routes into pharmaceutical supply chains. The choice of generic, with their lower margins and higher line utilisation – in general - rather than branded product (so often used in pilots and trials) - also added to the challenges and hence the success of this pilot. All the data was collected locally and then passed via the internet to the EPCIS database (implementation of the EPCglobal Network) created for each manufacturer and once again showcasing cutting edge use of technology. Where possible the EU Bridge team chose different methods of processing for similar operations in order to compare their functionality and practical application; for example the dual process for the receiving of the pallets. Firstly, the use of a Manual scanning system linked to the Internet where the operator scans the pallets using a bar code scanner where the data was then sent to the EPCIS system via the internet. Secondly, a more automated operation where an RFID portal is used to read the pallet tags. The goods-in operator would



move the pallet through the portal using a forklift truck, the data collected from this process being saved separately. The data collected from both these operations was then compared to ensure that both were operating correctly. Adding further to the challenges the innovative use of mobile technology to scan codes at various ‘remote’ locations again proved to be a great success in adding to the knowledge and practical use of complex code carriers such as Data Matrix where hardwired or other traditional solutions would have been difficult or impracticable. In summary, whilst the WP6 Team experienced a number of project delays and issues of a system and operational nature during the course of the implementation and deployment of the pilot, gaining valuable learnings and experiences as a result, we were able to successfully overcome them, thus demonstrating a practical, workable solution for mass serialisation for track and traceability of pharmaceuticals in the open supply chain.



1 Introduction This is the fifth document in a series documents discussing the different elements of the work package. So far the documents have covered;

• Problem Analysis • Requirements Analysis • Business Case • Pilot Preparation

This document describes the pilot in terms of:

• What we deployed and implemented • What we did to enable the deployment • The associated timescales • The problems faced and how they were addressed • User issues and initial reactions (more will follow on this aspect of the pilot in the next

deliverable, The Pilot Evaluation Report – D6.6) Work Package (WP6) has successfully implemented and piloted a fully operational drug product tracking system. We have taken drugs from three independent manufacturers and have tracked them all the way through an international supply chain, via distributors and a wholesaler, to the hospital pharmacy. At this point the tracking operation ceased. We have achieved this tracking capability by deploying a variety of technologies and information standards. Key elements have been the use of an implementation of the EPCglobal network for supply-chain wide data collection and by use of Data Matrix symbology on all levels of product packaging. RFID tags were also deployed to offer system redundancy and comparative data with Data Matrix scanning. Use of Data Matrix and the codes contained within them have been useful for a number of reasons – particularly their ability to hold a large amount of data in a physically small size and area and the cost of applying them to the product is miniscule compared with other technologies. As described in earlier WP6 documents, these codes contain all the information that might be expected (e.g. the product number or GTIN) of the more usual linear barcode (GS1-128 or EAN13) but importantly for this deployment they contain three additional pieces of information:

• The BATCH code of the item • The EXPIRY date of the item (both of these are very useful when automating product

stock and replenishment systems) • A unique SERIAL number

The serial number is critical simply because of its unique nature. Every single pack of every single product tracked had a different and unique serial number associated with it. Using this and the process of aggregating the contents to other serialised levels of packaging we were able to provide full traceability of a single item from the packaging line, throughout the distribution supply chain, to the delivery point at the hospital pharmacy. The results and findings of the Pilot will be discussed in the next Deliverable, The Evaluation Report.



2 Overview of the Deployed Solution

2.1 Outline The Pilot Deployment covered the complete supply chain from the packaging stage to the receiving of the goods into the hospital. We were operating in a ‘live’ working environment, manufacturing and distributing drugs intended for administration to the patient in the hospital.

FIG 2.1 - Overview The above diagram is a simplistic view of the system deployed but illustrates how the data is collected at each stage of the supply chain and how the product history was built up. In reality, the distribution process for the movements of the products was quite complex as seen below.

Fig 2.2 – Supply Chain Model



The pilot used products from three manufactures, Athlone Laboratories, Actavis and Sandoz. Products from Actavis and Sandoz were shipped to Tjoapack for the serialisation to be added to the packaging. Athlone Laboratories undertook the serialisation and packaging at their site in Ireland. All products could not be packed at the same location as Athlone Laboratories specialises in antibiotics and these cannot be packed under the same conditions as other pharmaceutical products. At the patient pack level, each item was coded with a unique SGTIN (serialised Global Trade Item Number) in the format of a 2-D Data Matrix code. The packs were then aggregated to a case that is coded using an SSCC (Serial Shipping Container Code ) code. The case label is a multi-format (Hybrid) label in that it can store the SSCC code as a 2-D Data Matrix code, GS1-128 linear barcode, human readable text and it is also encoded into the RFID tag. This provides assurance that whatever system is used further down the supply chain it is able to read the case label. Cases were then aggregated onto a pallet by scanning each of the cases as part of the palletisation process. At this stage we also deployed a RFID scanner to scan each of the case codes on the pallet, this data could then be compared to the data read by the barcode scanners for evaluation of the technologies for this process. Each pallet was coded using a SSCC code, that is the original and first unique serialised identifier to be used as a global standard for tracking logistics units. The SSCC was encoded on the pallet label as a 2-D Data Matrix code, GS1-128 linear barcode and onto an EPC Gen 2 standard UHF RFID tag. During the despatch process the pallets were scanned onto the distribution vehicle. This was allocated a unique code number that could be scanned and associated to the pallets. All the data was collected locally and then passed via the internet to the Verisign EPCIS database (implementation of the EPCglobal Network) created for that manufacturer. As an addition to the original pilot design, a decision was made to add mobile GPS (Global Positioning System with a Global System) to particular pallets to test whether they could be physically tracked from point to point in real time, as the vehicles and their cargo moved. Again the pallets’ unique codes were identified and linked to the EPCIS system via mobile tracking and read at regular intervals to check whether the pallets were moving in the vehicles, static (parked) or delivered; the pallets could be both identified and located precisely. Each tracked movement was recorded as part of the chain of custody process to ensure that we not only knew where the pallets and its contents were at any time but also their location was as expected. Although this tracking of physical movement was an additional feature to the original specification, it added a significant level of information to the whole Track & Trace process. In the future it should be possible to not only track the physical and geographical position of the vehicle and its load, but also check when and where vehicles stopped (and whether this was part of the schedule). Additionally a range of environmental monitoring such as temperature, pressure (for intrusion purposes), smoke and other contamination can be added. At each stage during the movement of the pallet from the manufacturer to the wholesaler the pallet was received from the vehicle using mobile barcode scanners. The pallets were scanned again onto the next vehicle for the next leg of the journey. All the transactions were stored locally then passed onto the appropriate EPCIS database, as ‘owned’ by each supply chain partner. At the wholesaler site, we implemented a dual process for the receiving of the pallets. The main process was for the operator to scan the pallets using the barcode scanner. This data



was then sent to the EPCIS system via the internet. The second method was to use an RFID portal to read the pallet tags. The goods-in operator would move the pallet through the portal using a forklift truck, the data collected from this process being saved separately. The data collected from this solution could then be compared to that of the barcode solution. In the wholesaler warehouse, the physical stock was stored in a separate quarantine area set aside for the EU Bridge pilot. The replenishment and despatch process here consisted of the operators picking products for delivery to St Barts and the London NHS Trust (Barts) against a St Barts generated order transaction and scanning the products into a tote box. Each tote box was uniquely identified using a GRAI code (Global Returnable Asset Identifier). Once the order was complete then a tote label was printed, again bearing a 2-D matrix code, and the tote box sealed using a SSCC label over the flapped hinges (as an anti tamper device). The tote boxes were scanned onto each delivery van ready for despatch. The tote boxes were delivered to the pharmacy where the operators scanned the SSCC code on the tote box to receive its contents. The pharmacy could then print off a manifest of the contents of the tote box. The receipt data was sent to the EPCIS database via an internet connection.

2.2 Technical Architecture

Fig 2.3 – System Arcitecture Overview The above diagram shows an overview of the solution architecture. The data is collected at each location and is sent via the internet to the VeriSign EPCIS system. Each owner of the data has been allocated their own EPCIS server to maintain data integrity. Mobile phones with special Data Matrix scanning software were used in the distribution process. The



mobiles phones communicated via SMS to a central server at Melior solutions. These devices were chosen for ease of implementation and to demonstrate you do not need to use expensive equipment during the tracking process. The Solution is split into four main sections, Manufacturing, Distribution, Wholesaler and Pharmacy.

2.2.1 Manufacturing Deployment of the pilot consisted of three packaging lines, one packing antibiotic blisters, one contract packer blister packing line and one antibiotic syrup bottling line. The manufacturing process consisted of three sections:

• Primary Item Coding • Case Coding • Pallet Labelling

Fig 2.4 Production Line 2.2.1.1 Primary pack Coding The process of coding the primary pack was the same for both the manufacturing and contract packaging sites although each site had its own set of issues, which will be discussed in detail later. The item pack was coded with a 2-D Data Matrix code, which contained the SGTIN, Batch number and Expiry date. Because we were using existing products we had to decide the best location to print the Data Matrix code on each product. The solution had to cater for this variable location of the Data Matrix code for both coding and scanning later in the process.



Fig 2.5 Sample Pack The installations used three different technologies for printing the Data Matrix code.

• Continuous Ink Jet (CIJ). • Scribing laser. • Thermal transfer labels.

Continuous ink Jet Continuous ink jet technology uses electrically charged ink droplets to create high quality characters based on a grid formation. Using a wide range of inks that have been developed for specific industry applications, CIJ printers can print text, graphics and variable data directly onto food, glass, plastic, metal, rubber and other substrates. The print head contains an ink drop-generator with a vibrating drive rod. This creates ultrasonic pressure waves in the ink, breaking up the stream of ink into individual droplets. When this stream of droplets falls between a set of electrodes, individual droplets are intermittently charged. The size of the charge given to each droplet determines how far it will be deflected out of the stream when passing through the deflector plates and therefore its placement on to the product. By placing a collection of these droplets close together, a variety of characters are printed as the product passes the print head. Droplets not deflected out of the stream are re-circulated to repeat the process. The CIJ process was used at Tjoapack in Holland to code the item packs as they left the blister-packing machine. This technology was well suited to the environment as the process already used ink jet technology to code the human readable codes onto the products. Scribing Laser Marking is achieved by using a laser to etch or vaporise the surface layer of the material leaving an indelible, permanent mark. As there are no inks or fluids used, laser printing is very cost-efficient and environmentally friendly. Scribing lasers such as the Domino S-series installed on the Athlone line use a continuous laser beam guided by mirrors that are controlled by galvanometer assemblies. The galvanometer technology enables coding and marking to be applied to moving or static products as well as at high speeds and with great accuracy. This technology was used in Athlone on the blister-packing machine to print onto the packs before the blisters were inserted as there was little space to use ink jet technology outside of the packing machine. The packaging at Athlone had to have a slight modification for use with the laser coder. A dark blue square was added to the packaging to enable the laser to code onto the packaging. Thermal Transfer labels Printing is achieved by placing a thermal ribbon between a heated print head and the substrate to be marked. With the three items in contact, the print head is moved over the



length of both the ribbon and the substrate. Heat from the print head is passed through the ribbon, causing ink to melt and be released from its underside. The ink adheres to the substrate and then cools rapidly resulting in a permanent print. Thermal transfer labels were used to label the bottles from the syrup lines at Athlone. Initially it was intended to use Continuous ink jet technology to code the Data Matrix code onto the cap of the bottles but due to the instability of the product (bottles) on the line it was decided to use labels instead. In all cases once the code had been applied to the pack then the code was checked to ensure the code was readable. Any packs that failed to be read by the inline camera were then rejected from the production line.

Fig 2.6 Code validation 2.2.1.2 Case coding On all three production lines, once the item packs had been coded with a unique code then packs were grouped into bundles before packing. The bundles were groups of 10 item packs and were for ease of handling and packing. The first stage of the aggregation process was to read all the item codes on a bundle and associate these codes to the case label. The installation used both fixed scanners to read a complete bundle and hand held scanners to read each code individually. The details of each will be explained in detail later. The case label was a multi-coded label in that in contained the SSCC code as linear barcode, 2-D Data Matrix code and a UHF RFID tag embedded into the label. The label was applied to the case once the case was completed – i.e. completely full with the correct number of bundles.

Data matrix Camera Reject Mechanism



Fig 2.7 – Sample label The individual cases were then placed onto pallets ready to be taken to the warehouse once the pallet manifest was complete. 2.2.1.3 Pallet Labelling At the palletising station we built the contents of the pallet by hand scanning each of the cases on the pallet using a barcode hand scanner and then associating these cases to the pallet label. In addition to this hand scanning of the cases on to the pallet, we also used a RFID reader to read the RFID tag on each of the cases. This data could then be used to check the accuracy of the barcode scanning during the evaluation phase. The final stage of the process was to scan the pallet on to the distribution vehicle. Scanning the Pallet SSCC code using a hand held scanner completed this.

2.2.2 Distribution Products were shipped as complete pallets (either single product or multiple products) that were not intended to be broken down until they reached the wholesaler. This simplified the distribution process to a straightforward receipting and despatch process at each of the distribution sites. The distribution system used the Data Matrix code on the pallet label along with standard phone technology with special software, provided by Melior Solutions, to decode the Data Matrix code.



Fig 2.8 – Pallet Scanning As described in the following diagram, the Data Matrix code on the pallet was scanned when the pallet arrived at goods inwards. The code was processed locally on the mobile phone and the data extracted and sent to a hosted data handling service (shown below as GSM/GPRS Messaging Server) via a SMS text message. Once the data was received by the data handling service, the interface with the appropriate EPCIS, signalled the event of goods received/goods despatched. This provided a simple to maintain, simple to operate mechanism for providing goods movement data to an EPCIS.

Fig 2.9 - Workflow Note from the process schematic above that each delivery vehicle used was allocated a known GRAI (Global Returnable Asset Identifier) and likewise each Distribution location also had a unique GLN. This allowed each observation event to be linked to a unique number that in turn provided a concise history of product movement.



As described earlier, additional technology was deployed to provide tracking during the distribution of the pallets. We fitted the pallet with a GPS surveillance device into the cases that tracked the precise whereabouts of the shipment throughout its journey. The device was set to provide regular location messages back to a central server where the location information extracted and linked to the EPCglobal network as a series of ‘container’ observation events. The UID of the device was linked with a GRAI (Global Returnable Asset Identifier) – the pallet - that in turn was associated with the SSCC of the pallet being shipped.

2.2.3 Wholesaler The wholesaler process was broken down into two areas of activity. The goods receiving process to receive the pallets from the distributor used a hand held scanner, the user scanning the barcode on the pallet and the system recording that the pallet was received. At Goods In, a RFID portal was also deployed to offer RFID comparative data reads with those of the 2-D bar code read. Secondly, and the key process for the wholesaler, was the system to enable the tote assembly and despatch process necessary as part of the order replenishment process prior to delivery to the hospital.

2.2.4 Hospital Receiving The hospital receiving process was very straightforward being based upon the use of a hand held scanner to scan the 2-D barcode on the tote box to process the receipt. The operator was then able to download the contents of the tote and print a tote manifest. Finally, the operator would put away the receipted products into stock either via the robotic inventory management system or by a manual stocking process.



3 User Systems Installed

3.1 Manufacturing installations

3.1.1 Tjoapack System Architecture

Fig 3.1 Tjoapack System Architecture For the pilot, the system architecture was kept as simple as possible to keep the impact on the production line down to a minimum. The Inkjet printer installed was a stand alone printer to print the Data Matrix code on to the pack. The system did not change or affect in anyway the current production systems for printing the statutory human readable data. Only codes read at the point of packing were stored in the system. The aggregation of the cases and the pallets were stored locally in a MS SQL database. The local database system was then connected to the VeriSign EPCIS database via an internet connection. A stand alone RFID system was also deployed within the warehouse to read the cases on the pallet. This would enable us to evaluate the use of RFID with the warehouse process.



Fig 3.2 – Process Flowchart



Primary Coding The Ink Jet printer was totally stand-alone for the coding of the Data Matrix code. The user entered the data onto the printer which then generated the sequential serial number for the SGTIN.

Fig 3.3 – Ink jet Printer

FIG 3.4 – Ink jet print position The print head had to be able to print on either side of the packs because of the Data Matrix position on the different products. The existing printing position enabled us to position the print head either side of the packs without any alterations to the production line. Any numbers generated at this stage were not registered in the system. Only packs that were scanned into the shipping cases were recorded on to the local tracking system thus reducing complexity of the pilot in reconciling rejected packs.



Fig 3.5 – Inkjet Print head

Fig 3.6 – Example Data Matrix The Data Matrix code was made up of the following data items:

• GTIN (Global Trade Item Number) • Serial Number • Expiry Date • Batch / Lot number

The format of the code complies with GS1 standards. Barcode Number (GTIN-Global Trade Item Number): This is a number composed of 14 digits used to uniquely identify product lines on a global scale GTINs can be 8, 12, 13 or 14 digit numbers, and in circumstances when the commercial product is used at the retail sales point, the number is often a GTIN-13 and encoded in an EAN-13 barcode. When any of these GTINs is encoded in a bar code that uses the GS1 application identifiers to specify the data content, the GTIN field is denoted by the application identifier ‘01’, and the GTIN always shown in a 14-digit field. This means that GTINs less than 14-digits long will need to be prefixed by filler zeroes which do not change the number. The formats for some of the main element strings encoded in bar codes such as GS1 Data Matrix and GS1-128 are given below. ‘Element string’ is the term for the application identifier together with the data that follows it. Global Trade Item Number (GTIN) Application Identifier

(AI)

Barcode Number (GTIN)

Indicator GS1 Company Prefix Product Reference Check Digit

01 0 N1, N2,N3,N4,N5,N7 N8, N9,N10,N11,N12,N13 N14



Example Application Identifier

(AI)

Barcode Number (GTIN)

01 0 5015201006336 6 Serial Number: This is a number used in identifying each unit of a product identified by the GTIN. A serial number used for a product may not be used again for the same type of product. The serial number is of variable length and may contain 20 characters at most. The GS1 Application Identifier identifying the serial number is “21”. Application Identifier

(AI)

Serial No

21 0 N1……………… Variable Length.N20 Example: Application Identifier

(AI)

Serial Number

21 1234567890 Expiration Date: This refers to the final date on which the product may be used safely. It is a numeric data composed of 6 characters. The format of the data is YYMMDD. YY indicates the Year information in two digits, MM indicates the Month information in two digits and DD indicates the day information in two digits. The GS1 Application Identifier identifying the Expiration Date is “17”. Application Identifier

(AI)

Expiry Date

Year Month Day 17 N1, N2 N3, N4 N5, N6

Example Application Identifier

(AI)

Expiry Date

17 081023 Batch/Lot Number: This is a number used to differentiate one batch/lot from others during production. The Batch/Lot Number is of variable length and may contain 20 characters at most.



The GS1 Application Identifier identifying the Batch/Lot Number is “10”. Application Identifier

(AI)

Batch / Lot Number

10 0 X1……………… Variable Length.X20 Example: Application Identifier

(AI)

Batch / Lot Number

10 07P064 Primary Code Verification For the pilot, we setup a simple reject mechanism. The 2-D Data Matrix camera provided an digital output signal when it was unable to read a code. The output signal was connected to an air solenoid to reject any unreadable codes. This was independent of the local tracking database and the codes were not recorded at this stage.

Fig 3.7 – Code validation



Case Printing The packing process within Tjoapack is a manual process. The item packs are orientated correctly on the production line and then bound into bundles, usually in groups of 10. These bundles are then scanned using a hand held scanner to scan each pack prior to placing the bundles into the shipping case.

Fig 3.8 – Case packing

Hand held scanners proved to be an issue in this environment. The hand held scanners take an image of the Data Matrix code and then decoded it into a text string which can then be processed. This image capture proved to be an issue at the packing station as one could not be certain which code had been scanned. The operators managed to get around this by masking the other codes around the code that was being scanned. This natually slowed down the packing process and an alternative method would need to be deployed in a live situation. Once the case was complete, the serialised GTIN code on the case was scanned and the items aggregated and the case closed.



Fig 3.9 – Case scanning

The case labels

Fig 3.10 – Sample Case Label

The case label is best described as Hybrid A6 SSCC label that contained a 2-D Data Matrix code and RFID tag. The printed (thermal transfer) label contains human readable data about product, dosage type and dosage strength as required by law. In addition, there is an SGTIN (GTIN plus serialised 20-digit element separated by appropriate Application Identifier (AI)). There is a Data Matrix code that contains the four items of data (GTIN, Serial Number, Batch



Number and Expiry Date) plus a GLN (AI 412), indicating the identity of the generating site, at the bottom of the label. The RFID tag was encoded with an SGTIN element in accordance with EPC/GS1 recommendations. The labels were printed on a Zebra RFID enabled thermal transfer printer. The printer validated that the RFID tag had been successfully encoded. The word “VOID” was repeatedly printed on any labels where the RFID tag failed to encode.



Pallet Coding The basic process within the warehouse is to associate the cases to a unique pallet identifier, each case being scanned using a hand held scanner. The scanner is able to scan either the linear barcode or the 2-D Data Matrix, then the pallet label is scanned and the association is complete. The issue with the manual scanning operation is ensuring that the operator has scanned each of the cases. Although this is an additional task to the current process it is a check that can ensure all the cases are correct and any cases accidentally mixed onto a pallet are quickly identified. Scanning improved as the operator became familiar with the operation.

Fig 3.11 – Pallet aggregation

This process can be enhanced further by checking the scanned pallets against the initial build of the pallets on the production line. Any discrepancies can be quickly identified and dealt with. The aggregation data collected onto the local system was sent via an internet connection to the Verisign EPCIS database as an aggregation event by scanning the pallet label a second time. In addition to the case to pallet aggregation scanning, the pilot included the use of RFID as an alternative to the traditional barcode scanning process. Each case label included an embedded RFID tag that was coded with a SGTIN to comply with GS1 recommendations. Two antennas were mounted onto the arm of the stretch wrapper and as the pallet was rotated, the antennas moved up and down with the stretch wrap. All the case RFID codes were recorded in a separate database for further analysis and comparisons to scanning the barcodes. The only real issue we had with reading the RFID tags was to ensure we only read the tags on the pallet. The power of the antennas had to be turned down to prevent reading tags on nearby pallets.



Fig 3.12- RFID scanning

The Pallet label was also an A6 Hybrid SSCC label. The label contained:- Product description in clear human readable text, Serial Shipping Container Code (SSCC) with an application identifier (AI) 00 encoded as a linear barcode and a 2-D Data Matrix code EPC coded RFID tag GLN (Global Location Number) of the generating site, AI 412 Despatch Operation At the point of despatch the system required the operator to record each pallet loaded onto the vehicle. Each vehicle had been labelled with a GRAI label to uniquely identify the vehicle. The operator scanned the SSCC code with a hand held scanner followed by the GRAI on the truck. The data was stored locally in a Microsoft SQL database and was then sent to the EPCIS as a despatch event.

RFID Antennas



Installed Hardware

Tjoapack Blister Line Part Specification

A-Series

A200 Configured as follows: - Ink = 291BK Nozzle Size = 60 micron Print Format = 3M7ST60 Conduit = 3m Standard Domino encoder NPN Proximity Sensor fro external trigger

2-D Code Reader

90mm from Data Matrix substrate Powered from 24v power supply Internal Illumination Shutter Speed = 50ms

Reject System Regulated Factory Air to suit. Standard Domino Air Knife 24v Air Solenoid, triggered by the 'no read' output from MAC340

Case/Pallet Scanner P&F hand scanner configured as: - RS232 SXGA high resolution mode

Laptop with TTM100 Software

Configured to allow item, case and pallet scanning with serial hand scanner

RFID Reader Impinj Speedway UHF reader



3.1.2 Athlone Installation System Architecture

Fig 3.13 – System Architecture All Aggregation data and distribution events were collected on to a local MS SQL database. The local database was connected to the VeriSign EPCIS via the internet. The printing stations were installed as standalone systems and only item codes which were packed into shipping cases were collected and stored locally before being sent to the external EPCIS system. 3.1.1.1 Blister Packing Line The pilot used two lines at Athlone Laboratories - the blister packing line and the syrup packing line. There are a number of differences between the blister packing line and the packing line at Tjoapack. Firstly, the production line is much more condensed into the available space and there is no conveyor between the item-packing machine and the bundler shrink wrapper. Secondly the line operates at much faster speeds. With our philosophy of minimum impact to the production environment, we installed the laser and code verification system on the stainless steel chute between the blister packing station and the shrink wrapper. The advantage of this solution would have been minimum impact on the current operations of the line. The laser and the camera could have easily been removed when not producing the pilot products. However, this location proved to be unsuitable for two main reasons. Firstly, the pack was not stable enough for the laser to code the Data Matrix onto the packs at speed. Secondly the polished stainless steel slide reflected too much light onto the pack that made reading the codes with the camera very difficult.



Fig 3.14 – pack slide

The laser was moved inside the Romaco blister-packaging machine. The laser coded the packs on the fly (whilst moving) prior to the pack being opened ready for the blister to be inserted. As shown below the Domino S200 laser was fitted to the top of the Romaco machine at the point where the packs entered the machine but before they were opened. The installation required a longer focal length on the laser and a custom bracket to enable it to be fitted inside of the machine. An encoder was fitted to the Romaco gearbox to provide the necessary pulses to ensure correct coding of the Data Matrix while the item pack was moving past the laser coding head. Vibration of the machine was an issue, so a stabilising arm was fitted to reduce the amount of movement of the pack as it was coded.

Fig 3.15 – Laser position

Domino S200 Laser Coder



The camera was also fitted inside the Romaco just before the reject chute and was integrated into the Romaco software. If any packs failed to read then a signal was raised and the PLC on the Romaco rejected the invalid pack.

Fig 3.16 – Camera Position

As can be seen from the picture above the space for the camera is very limited and so the Dataman 100 was used, as it was small enough to fit the gap. The camera was configured to burst the image with a fast shutter speed as it passed by. Bursting the image enabled the camera to capture the image at different stages as it passed the camera. This was found to provide the best performance due to the amount of reflected light from the surrounding area. Case Packing Once the packs have been printed, they are grouped into bundles for ease of packing, then completely shrink wrapped. The process is a manual operation where the operator checks the bundle to ensure all packs are coded and then packs them into the shipping case. Due to the speed of the line, the operator would not be able to scan all the individual codes on the packs using a hand scanner. The solution was to create a jig to ensure the packs were always in the same position and then using a single camera read of all 10 codes within the bundle, before placing the bundle into the case. Once the case was full, the case was labelled with a SSCC label and then scanned using a hand held scanner.

Fig 3.17

Cognex Camera



3.1.1.2 Syrup Line Primary Pack Coding Initially, the intention was to print 2-D Data Matrix codes onto the cap of the syrup bottles. We installed a Domino A200 Ink Jet printer on the line with a camera and reject point. During testing of the line it was obvious that due to the lightweight bottles, and their shape, and the vibration of the production line, it was impossible to print a quality code without adding some mechanical handling device to the production line to stabilise the product for coding. These changes were outside of the project scope and so we had to devise an alternative coding method. NB We may well fit a more robust system at some future point (within months). The alternative solution was to manually place a thermal transfer label to the cap prior to the shrink-wrapping process. Each bottle was still validated using the camera on the line and any unreadable codes were rejected. Case packing The installation for the case coding was the same as Tjoapack in that we used a hand held scanner to read each code on the bottle cap.

Pallet packing The pallet packing is the same process as per Tjoapack. We did not implement the RFID reading of the cases at this site. This was to prevent the loan equipment from Impinj from being contaminated within the antibiotics environment. If installed, the equipment could not be removed.



Fig 3.18 – Athlone packing process



Installed Hardware

Athlone Blister Line Part Specification

S200W

Wide Angle Scan Head 10mm Lens with 20mm spacing Ring 20W laser tube Dynamark2 Operating Software Connected to factory air regulated to 1.5bar. Quadrature Shaft Encoder for Mark on The Fly PNP Proximity Sensor fro external trigger

DPX500 Standard domino specification interfaced with the S-Series controller

Dataman100 Code reader 50mm from code substrate

Domino I/O Box

Connections included: - RS232 for Camera programming and monitoring 24v for camera power Trigger input from Romaco PLC Good Read output of 40ms to Romaco PLC

24v Power Supply Moxa 24v Power supply rated at 24v/3A(Also used to power Insight camera)

Cognex Insight Camera.

Reading 10 codes per trigger taking approximately 400ms External 'camera' trigger using foot switch Approx 200mm from Data Matrix substrate No external lighting used. Data Matrix codes exported to TTM software via Ethernet.

Case/Pallet scanner P&F MAH120 hand scanner configured as: - RS232 SXGA high resolution mode

Athlone Bottle Line Part Specification

A-Series

A200 Configured as follows: - Ink = 291BK Nozzle Size = 60 micron Print Format = 3M7ST60 Conduit = 3m Standard Domino encoder NPN Proximity Sensor fro external trigger

MAC340 Code Reader

90mm from Data Matrix substrate Powered from 24v power supply Internal Illumination Shutter Speed = 50ms

Reject System Regulated Factory Air to suit. Standard Domino Air Knife 24v Air Solenoid, triggered by the 'no read' output from MAC340

Case/Pallet Scanner P&F MAH120 hand scanner configured as: - RS232 SXGA high resolution mode



24v Power Supply Moxa 24v Power supply rated at 24v/3A

3.2 Distributor Installations Two technologies were deployed for the distribution tracking. The primary technology was the mobile phone for recording the receipt and despatch at each site in the process. The second technology was a GPS device implanted in one of the cases of the pallet. Solution Architecture

Fig 3.19 – Distribution Architecture

Installation The installation was straight forward and consisted of loading the TTM200 software on to the mobile phone handset. The phones were used to scan the Data Matrix code that the TTM software decoded into a text string and sent the converted string to the Melior Solutions hosted server via a SMS text message. This server processed the text message and created an event on the EPCIS system



The vehicles used for the pilot were fitted with a GRAI label. This enabled the pallets to be tracked on and off the same vehicle. An exception would be noted if a receipt had been made against a vehicle that the pallets had not been scanned onto. Vehicle Label

Fig 3.20 – Example Vehicle Label

Application Identifier 8003 denotes the code is a GRAI (Global Returnable Asset Identifier) GPS installation As discussed in the pilot preparation report, we wanted to cover all of the distribution processes and not just the check points that the pallets passed through. To this end we installed a GPS surveillance device that tracked the precise location of the device. The GPS device was a high sensitivity GPS device. This allows the device to be installed without external antennas or complex wiring and can be hidden away within the pallet. Even though the GPS device was hidden within a case within the pallet and the pallet was transported inside a vehicle the high sensitivity of the device still enabled it to locate itself and transmit the data via GMS/GPRS. The GPS device was assigned a GRAI. The GRAI of the GPS device was linked to the pallet’s SSCC code, which enabled the system to track the pallet through the distribution process



Fig 3.21 – Sample GPS screen image The device was set to provide regular location messages back to a central server where the location information can be both graphically displayed on a map and also linked to the EPCglobal network as a series of ‘container’ observation events. The example above shows the track of a shipment from Athlone Laboratories (based in Ireland) to their distributor; Kent Pharmaceuticals (based in Ashford, Kent, UK).



3.3 Wholesaler installation

System Architecture

Fig 3.22 – Wholesaler system architecture

Wholesaler Part Specification

Goods receipting and picking scanner

Pepperl and Fuchs ODT-HH-MAH200 Bluetooth Scanner – Configured for serial communications.

Despatch Scanner Pepperl and Fuchs ODT-HH-MAH200 Bluetooth scanner – Configured as keyboard wedge

Label Printer

Zebra ZM400 label printer 300 DPI Max label width 102mm



Installation As standard practice, UniChem use reusable tote boxes to deliver the picked items to Barts Hospital. Each tote box was labelled with a unique GRAI (Global Returnable Asset Identifier) label.

Fig 3.22 – sample Tote Label Application identifier 8003 denotes the code as a GRAI. The GRAI on the tote box is used for the picking process to associate the items picked with the tote box. Potentially, this process would enable the individual totes to be tracked to ensure the empty totes are returned. As described in the flowchart below there are three processes at the Wholesaler.

• Receipting • Picking • Despatch



Fig 3.23 Pallet receipting The full pallets are received by scanning the pallets off the incoming delivery vehicle. The vehicle is identified with the GRAI label. The goods receipt event is recorded on the Verisign EPCIS database. The pallets are then unloaded and stored in the goods receipt area. A second scan is performed to download the contents of each pallet to the local database. Products are picked into special tote boxes (coloured white for ease of identification) that were labelled with a unique GRAI barcode. The SGTIN barcode on each item is scanned and is associated to the GRAI on the tote box. The contents of the tote box are then transmitted to the Verisign EPCIS system. Once an order has been picked and it is ready for despatch and scanned onto the vehicle by scanning each tote and the vehicle GRAI. Each event is uploaded to the Verisign EPCIS system.



Fig 3.24 – Wholesaler Process



In addition to the standard goods receipting process using the SSCC pallet barcode, the pilot deployed a RFID portal to read the RFID tags on the pallet label and on each case. The bi-static RFID installation consisted of a single Impinj UHF reader with two antennas connected. The pallets were then driven between the antennas and the reads were collected in a database for comparison against the barcode receipt process.

Fig 3.25 – RFID scanning

RFID Antenna

RFID Reader

RFID enabled labels



3.4 Hospital Installation Solution Architecture

Fig 3.26 system Architecture – St Barts Hospital

Barts Hospital Part Specification

Goods receipting Pepperl and Fuchs ODT-HH-MAH200 Bluetooth Scanner –

Despatch Scanner Pepperl and Fuchs ODT-HH-MAH200 Bluetooth scanner – Configured as keyboard wedge

Label Printer

Zebra ZM400 label printer 300 DPI Max label width 102mm



Fig 3.27 Receipting Process



Installation Totes are received from UniChem into the Barts Pathology and Pharmacy building. The goods receipt process is a two-step process, the first step being to scan each tote off the vehicle. The process is then completed by scanning the GRAI on the truck, followed by the GRAI on the tote box.

Fig 3.28 – Tote delivery This then sends an event to the Verisign EPCIS database. The second part of the process is downloading the contents of the tote to the local database. This is achieved by scanning the SSCC barcode on the seal label. The system then connects to the Verisign EPCIS system and downloads the contents of the tote recorded in the system .

Fig 3.29 – Tote Receipting

If there is an issue with a product, a manifest can be opened using the search facility on the TTM software on the user laptop system. The user is then able to search for the suspect item, using the Data Matrix data. This gives Barts the ability to see manufacturing dates and batch codes for that particular product.



4 Operation of the Pilot

4.1 Timescales The pilot operation was a major task for the project. With so few pallets moving through the system, the team felt it necessary to have key personnel at each site ready to receive the shipment and to despatch it to the following site. We had to plan exact timings to and from each site to ensure the trained personnel were available at each location. After the installation work at the production site key Bridge personnel were on site to ensure the correct running of the system. The production was run with the support of the Tjoapack and Athlone personnel. Pallets were created and stored within the warehouse before shipping to the next location. Stock was held until the next link in the chain was ready to receive the goods. Sufficient notice was given to the team and trained personnel were sent to site to receive and despatch the pallets. Due to varying production schedules it was not possible – nor desirable – to manufacture and distribute all pilot products at the same time. As a result, the Tjoapack packed products (sourced by Sandoz and Actavis) were distributed first, followed by two batches of Athlone products. Whilst this necessitated additional project resources to be deployed it meant that the crucial stage of pilot operation, that of the order/replenishment process between Barts’ hospital pharmacy (Royal London site) and UniChem, could commence at an earlier stage than would otherwise have been the case. The distribution process commenced in mid October 2007 with the stock being accumulated and stored at UniChem. The order/replenishment process commenced mid February 2008 and completed on 31st May 2008, a 15 week timescale in line with the originally intended plan.

4.2 Training

On-site training programmes were developed for managers, supervisors, operators, logistics and distribution staff within the production plants, the warehouse (goods-in and goods–out), transport and distribution sites , the wholesaler facilities and goods received at the hospital pharmacy. A training document was produced which described the pilot system and how each operation contributed to the overall tracking of the items. One of the most difficult parts of the pilot programme, certainly at the early stages within the logistics chain, was to encourage operators, pickers, packers, loaders to attend training sessions and use the equipment supplied, even though in our minds it was a very straightforward process. The standard operating procedures were kept as simple as possible, copy typing using a standard keyboard, scanning using a simple point and press scanner or similar processes using mobile cameras or hand-held devices. Often the groups worked shifts and training was complicated by time constraints and ‘other operational’ pressures. However, all the processes that required operational training were finally completed. Generally, and notwithstanding the difficulties, this training programme was very effective and the complete process, from manufacturing through to receipt at the hospital pharmacy, worked very efficiently after some initial user nervousness. The original project plan required that user system training was given prior to the pilot going live. However, the overwhelming feedback received from the users required that training (and



onsite support) should be repeated immediately prior to the first ‘live’ operational run of the order/replenishment between UniChem and Barts. Accordingly, when the pilot went ‘live’ training was firstly given to key people within the UniChem team. A demonstration was included and then each team member processed an order that was placed on them by Bart’s that day. Once each member of the team was happy with the process at UniChem the totes were built and placed in the delivery van ready for shipment to Bart’s. The training was also very useful as an aid to improve the process within UniChem as the staff knew where the best locations in the warehouse would be to undertake the scanning process and assemble the tote once they were ready for shipment. One area that was overlooked was to ensure that the scanning was performed within the wireless network coverage. This became an issue early on in the pilot as orders could not be uploaded onto the VeriSign system as there was no network connection. The reason for this was that one of the locations for scanning was out of the range of the wireless router installed by Domino. A member of the Bridge project team then rode in the van with the driver to Bart’s hospital with the assembled totes. Again this was useful as it highlighted that potentially the Bridge totes could be delivered to the incorrect department. At Bart’s hospital there are several receiving departments. Occasionally, when there is time pressure on the delivery process, all totes destined for Bart’s are delivered to one location and not all of the locations, relying on internal logistics for delivery. In these instances, some totes may therefore not be delivered to the Pharmacy building. This issue was raised with UniChem and they ensured that the Bridge totes would be delivered to the correct building. Training was given to three Bart’s personnel again explaining the function and operation of the hand held scanner and TTM software. Each team member was taken through the process and then they receipted and downloaded the totes that were delivered earlier. Working on ‘live’ products proved that the system worked effectively and gave UniChem and Bart’s confidence that the hardware and processes worked successfully.



4.3 The problems faced and how they were addressed The following describes pilot problems encountered from the Project Team’s point of view. User views are currently being collected (via an AV filming process) and these will be recorded and documented in the next deliverable, The Evaluation Report (D6.6) There were a number of issues encountered during the pilot and we have divided these into the following categories

• Technical issues • Co-ordination • Distribution issues

Technical Issues The serialisation of the syrup line presented the main technical issue of the project. The initial design of the pilot considered 2 technologies for the serialisation of the bottles.

• RFID • Data Matrix

Although, in principle, RFID looked an ideal solution for the bottles, it was dismissed by the Athlone team as adding too much cost to the product. The Data Matrix solution was the chosen solution and we attempted to write a Data Matrix code to the cap of the bottle. The issue with this solution was the stability of the bottles on the production line. The bottles had very little weight being filled with dry powder, which made the bottles very susceptible to vibration and thus poor quality printing. The technical solution to the vibration issue would have meant adding product handling devices to the production line to stabilise the product. These changes to the production line were out of scope of the project. To simulate this, labels were manually placed onto the caps of the bottle and the camera validated the bottles. The process then continued as designed. Stabilisation is also an issue when printing any Data Matrix codes whilst the product is in motion. Sometimes we had just to ensure the product was always in the same position and other times we had to add simple devices to stabilise the product during the coding process. As mentioned earlier, reading the code can be a challenge if the wrong position of the camera is chosen. In a clean environment where everything is stainless steel the correct lighting and camera position is an issue. Certain cameras have a small field of view, which cause issues with accuracy and quality of an image of the Data Matrix code. This was solved by swapping the camera for one with a larger field of view. This gave the system a larger tolerance in triggering the camera. Co-ordination Limited access to production lines caused a number of issues that introduced significant delays to the project.

• Scheduling work during non production time o Weekends o Evenings o Shutdown periods



Working within constricted time frames did not always allow for issues to be resolved within a given time window. This delayed the project as the next available window was in several cases several weeks later. Distribution Issues Packing tape was placed over some case and pallet labels. This made the barcode/Data Matrix code impossible to read and it was not possible to peal the tape away as the label would also peel off. Either a more hardwearing label is required or the warehouse operatives need to know that they have to avoid doing this. RFID portal - It was observed that if the pallet was placed in the portal at one height approx. 50% of the labels would read. If the pallet was lifted up through the portal from the ground a much higher percentage were read. With all the labels being of a similar design and size it was difficult sometimes to locate the pallet label. Normally a larger label (A5) design would be used to differentiate the pallet and case labels. On the distribution elements of the project, the main problem was the consolidation of pallets, meaning that at Kent Pharmaceuticals new pallet labels were created to allow two consolidated pallets to be shipped and tracked. An important point to note that distribution costs are directly related to the number of pallets being shipped so partially filled pallets creates additional cost. Other pallet issues encountered were labels being obscured by packing tape so the code was unreadable and instances where the labels were lost altogether. To overcome these issues, all the cases on the pallet were scanned in place of the pallet label to ensure that tracking data was not lost. As already mentioned in the training section of this report, ensuring the assembled totes were delivered to the correct site at Bart’s hospital was an issue. UniChem attempted to ensure that this would be the case but the van drivers tended on occasions to short cut the procedure if they were under time pressures. UniChem experienced a loss of internet connection on occasions due to a change in the physical location of the scanning process (the wireless internet connectivity being interrupted). They were advised to always scan the product in the location that was identified as having good wireless internet reception as explained in the training. The time to scan the product was prohibitively long on occasion due to the manual scanning process, particularly when hundreds of packs were being assembled into the tote.. As a key feature of UniChem’s service levels, each order received in late morning had to be delivered by 2pm that day and therefore, if there was danger of missing the delivery schedule, scanning was stopped. It was very easy for the tote assembler at UniChem to miss a product, especially if they were scanning bundles of ten. There is a high likelihood that items were not scanned, which were then placed in the tote. The main reason for this was scanning a product twice instead of two individual items next to each other - the user would have no way of knowing if this occurred. It is envisaged that feedback mechanisms would be implemented as part of a fully operational system.



4.4 User issues and reactions The following table represents a list of issues and comments as logged by UniChem and Barts during the order/replenishment phase of the pilot. All occurrences of incidents were recorded in this way.


Barts and the Royal London Trust Issues

Issue Product/Process affected Number of

occurrences noted in log

Subsequent issue

EPC number not located Aqueous Cream, Co-Codamol, Prednisilone, Amoxicillin

5 Could not download Tote information on UniChem laptop

Tote Label was not present on top of Tote box Unknown 1 Could not download Tote information on Unichem

laptop

Bridge Project not sent in tote box but in original cardboard box. No Tote label. Aqueous Cream 1

Could not download Tote information on UniChem laptop

Some products not shown on Manifest Penicillin, Warfarin 2

Unable to retrospectively identify all products in delivered totes.

UniChem Issues

Issue Product/Process affected Number of

occurrences noted in log

Network communication failures Uploading Tote information. 2 Could not upload information onto VeriSign

Tote label would not print Tote Building 3 Products could not be processed as part of the bridge project as a Tote label could not be printed.

Bluetooth hand scanner was un-reliable Tote Building 2

Increases time to build the tote. Therefore affects the despatch time of the items to St Bart's

There was not time to scan all items for the Bridge orders due to the amount of items and

the speed of the hand scanner Tote Building 3

Some of the Bridge product was not uploaded onto the VeriSign system and therefore will be lost to the

project.

Speed of uploading the shipment was very slow Uploading Tote information. 3 Increases time to build the tote. Therefore affects

the despatch time of the items to St Bart's

Some items would not scan. Tote Building 2 Products that would not scan are lost in the

distribution process as they are not recorded onto VeriSign


4.5 Pilot Management Overall management of the Pilot was undertaken by the Project Co-ordinator (JJ Associates) strongly supported by the deputy manager (Melior Solutions) and other members of the Project team according to the tasks required and the particular phase of the Pilot. As already mentioned, there were a lot of detailed operational activities undertaken during the production running (manufacturing and packaging) and distribution phases of the pilot and a great deal of detailed ‘hands on’ management was required of Domino UK (the production system implementers) to co-ordinate the related tasks. Similarly, the distribution phase from manufacturing through to the wholesale operation at UniChem had to be carefully controlled and monitored to ensure appropriately skilled personnel were available to complete the “scan in” and “scan out” operations at each leg of the chain. Again, Domino UK were largely responsible for managing these activities. When sufficient product had been accumulated at UniChem and the order/replenishment phase commenced with Barts and The London hospital pharmacy (Barts) in mid February 2008, the management role changed entirely to much more of a hands-off, overseeing/monitoring role by JJ Associates. As the order/replenishment process occurred on ‘an as required’ basis (driven by additional stock needs of Barts) there could be up to two order/delivery cycles each day as per the service levels agreed between the two parties. There were therefore repetitive operational cycles undertaken by personnel at both ends of the supply chain and the management of this could be conducted on an exception basis. The support procedures in place required either UniChem or Barts (as relevant) to place a call on Domino technical personnel as first and second lines of support with the Pilot manager only being called upon as third line. This happened only rarely - perhaps twice during the whole of this project phase and therefore the management time required of this aspect of the pilot was relatively low. All of the support incidents were logged as discussed in section 4.3.


5 Appendix Project Plan

Date post:	26-Apr-2018
Category:	Documents
Upload:	dinhhanh
View:	223 times
Download:	3 times

Pilot Deployment Report - Bridge€¦ · · 2012-01-25Pilot Deployment Report. Authors: Robert...

Documents