IFA Coding System PPN-Code Specification for Retail Packaging
Transcription
IFA Coding System PPN-Code Specification for Retail Packaging
IFA Coding System PPN-Code Specification for Retail Packaging Coding of packaging using Data Matrix Code to protect against counterfeiting of medicinal products Automatic identification of retail packages for the pharmaceutical sector www.ifa-coding-system.com Version: 2.01 Date of issue: 2013-06-26 Table of Content 1 Foreword and Introduction 4 2Scope 4 3 5 Coding agreements 3.1General 3.2 Pharmacy Product Number (PPN) – use in Germany 3.3 Further global uses of the PPN 3.4 Codes und data content of retail packages 3.5 Multi Country Packs 4 5 Data content and requirements 5 5 6 6 7 7 4.1 Data structure 4.2 Data Identifiers and data 7 8 Marking with code and clear text 10 5.1Symbology 5.2 Matrix size 5.3 Code size and quiet zone 5.4 Positioning of the Data Matrix Code 5.5 Emblem Data Matrix Code 5.6 Clear Text information 5.7 Code examples 5.8 Print quality 10 11 11 11 12 12 12 13 6 Printing systems 14 7 Scanning technology 14 8 Interoperability with different data structures and Identifiers 14 8.1 Interoperability based on existing Auto-ID 8.2 Interoperability based on XML-Standards All contents copyright © IFA GmbH | Information Center for Medicinal Products | English V 2.01 14 15 Page 2 Appendix A - Overview of the Data Elements and Data Identifiers 16 Appendix B - PPN check digits Algorithm 17 Appendix C - Code Emblem 18 Appendix D - Interoperability based on XML-descriptors 19 D.1General D.2 Data Format Identifier (DFI) D.3 XML-Node for Data D.4Implementation D.5Examples Appendix E - Quality and control of the code content E.1 E.2 E.3 E.4 E.5 E.6 E.7 E.8 Data Matrix Code as dot code Qualification and validation measures Checking codes for data content and print quality Printing variants Quality control statistics Testing equipment Colours and materials Quality criteria in accordance with ISO/IEC 15415 and ISO/IEC 16022 Appendix F - Common problems F.1 F.2 F.3 F.4 Faults in the data structures Data content errors Printing errors Material related errors 19 19 19 20 21 22 22 22 22 23 23 24 25 25 26 26 29 30 34 Appendix G - Layout –Best Practice 35 Appendix H - Bubble-Jet – Best Practice 35 Appendix I - Data Matrix Code –Symbology description 36 I.1 I.2 I.3 I.4 I.5 I.6 Module sizes Matrix size Fixed pattern Data area Pad characters Error correction 36 36 37 37 37 38 Appendix J - Glossary 39 Appendix K - Bibliography 42 K.1Standards: K.2 Further References K.3 Links 42 42 42 Appendix L - Document Maintenance Summary 43 Appendix M - Imprint 44 All contents copyright © IFA GmbH | Information Center for Medicinal Products | English V 2.01 Page 3 1 Foreword and Introduction • Bundesverband des Pharmazeutischen Großhandels – PHAGRO e.V. (Association As part of the "securPharm" project framework, to of Pharmaceutical Wholesalers) develop and pilot a system to implement the requirements of the European Directive 2011/62/EU to pro- • Pro Generika e.V. (Association of Generic tect against counterfeiting of drugs, for the German associations of pharmaceutical Medical Manufacturers) manufacturers, wholesalers and pharmacists (Stakeholders) the • Verband Forschender Arzneimittelhersteller need arose, to transform the German reimbursement e.V. (vfa) (Association of Research-Based number (PZN), as defined in social legislation, into a Pharmaceutical Companies) globally unique product number. Figure 1 shows a typical packing hierarchy from a single In this context, the "Informationsstelle für Arzneispezia- component (e.g. a blister pack or a bottle) through to a litäten GmbH (IFA)" [http://www.ifaffm.de] (German transport pallet. For the stages of retail packaging and Information Center for Medicinal Products), which transport units, IFA has corresponding coding specifi- manages the allocation of PZN, has acquired the status cations, referred to as the IFA Coding System. of an Issuing Agency and has created a coding system (IFA Coding System). While securPharm system focused on drug packaging 2 Scope to meet the specific legislative requirements, IFA Coding System extended the securPharm system firstly This document is the specification for the identification to cover all common pharmacy products (eg food of retail packages (see arrow in Figure 1). supplements). Secondly, it covers the identification of: - Retail packages and - transport units. This specification has been prepared on behalf of the associations represented by IFA: • ABDA - Bundesvereinigung Deutscher Apothekerverbände (German Federal Association of Pharmacists) • Bundesverband der Arzneimittel-Hersteller e.V. (BAH) (German Medicines Manufacturers Association) • Bundesverband der Pharmazeutischen Industrie e.V. (BPI) (German Pharmaceutical Figure 1: Packing hierarchy (as in ISO/DTS 16791-2012) Industry Association) The Transport Logistics specification is available from www.ifa-coding-system.org or directly through: http://www.ifaffm.de/mandanten/1/documents/04_ifa_ coding_system/IFA_Spec_Transport_Logistik_EN.pdf All contents copyright © IFA GmbH | Information Center for Medicinal Products | English V 2.01 Page 4 This specification which is based on the rules "Coding The "Coding rules securPharm" provide for the rules for medicines requiring verification for the German coding in Data Matrix Code as per ISO/ IEC 16022 market to protect against counterfeiting of medicinal (refer to Chapter 5.1) of this specification and the data products (Coding rules securPharm)", issued by secur- structure and syntax according to ISO/IEC 15418 and Pharm e.V describes in particular the conversion of the ISO/IEC 15434 (refer to Chapter 4). In this way, the PZN into a globally unique "Pharmacy Product Number machine readability of the data elementsis assured (PPN )". Further details are to be found in Chapter 3.2. and the technical prerequisite for the implementation of the EU directive for protection against counterfeit An essential component of this specification is the medicines and also the anticipated additional require- description of the Data Matrix Code, which holds the ments for verification of medicinal product packages. necessary data elements for automatic identification. Based on the PPN, as product number, it describes This code is referred to in its totality as PPN-Code. the coding and the associated marking of medicinal product packages,the data structures and the forms of print quality. 3.2 Pharmacy Product Number (PPN) – use in Germany All essential and mandatory coding components have Many processes e.g. reimbursement system and been adopted from the "Coding rules securPharm" into medicinal product identification are dependent on the this specification. However, in regard to the generation PZN product number. However to provide verification in of serial numbers, refer to Chapter 3.1 of the above terms of the EU directive it is necessary to use a unique mentioned rules. pan-European product number. To fulfil this require- data elements as well as the coding with code size and ment the Pharmacy-Product-Number (PPN) has been Thus by using this specification it is ensured that all created. The Data Identifier "9N" was assigned uniquely the guidelines of securPharm are covered. to the PPN. In addition this specification covers the detailed The PZN is converted into the globally unique PPN as description of typical faults or problems (refer to illustrated below: Appendix F). Pharmacy Product Number (PPN) 3 Coding agreements 3.1 General 11 12345678 42 The identification of medicinal products using the PZN (Pharmaceutical Central Number), in Code 39 form, has its legal basis set out in the Fifth Book German Security Product Registration Agency Code for PZN PZN Check-Digits PPN Code (SGB V). Figure 2: PPN generation Additionally the German pharmaceutical market stakeholders set out in "Coding rules securPharm", for the automatic identification of retail packages, the following data elements: • Product Number • Batch Number • Expiry Date • Serial Number All contents copyright © IFA GmbH | Information Center for Medicinal Products | English V 2.01 Page 5 The PPN consists of three parts which are identified The interoperability with other number systems, e.g. here with the colours red, blue and green. The 11 (in red) GTIN (GS1 as responsible IA) or HIBC (EHIBCC as is a "Product Registration Agency Code" (PRA-Code or responsible IA), is safeguarded by the common use of PRAC). This code is administered and assigned by the international standards. IFA. The 11 is reserved for the PZN. Following the 11, (in blue), is the national product number, this being the The use of the PPN is licence-free. unmodified PZN (PZN8). The following digits (in green) are the two-digit check digits calculated over the complete data element (including the 11). With the PZN, 3.3 Further global uses of the PPN as shown in the example, the result is the value "42". With the provisions of the PPN other healthcare partiIn the PPN, the PRA-Code, PZN and PPN-check digits cipants can uniquely map their national or proprietary are used without separators. By use of embedded PZN number systems to a globally unique numbering system, with the PPN Data Identifier "9N" and PRA-Code "11", e.g. the Eurocode IBLS of Blood banks, Austria-system the PPN is unique and the hyphen is not required as an (PZN), Belgian system (CNK-number), Greece system indicator. (EOF-number), Italy system (AIC-number), etc. The IFA as Issuing Agency ensures with the assignment and Existing data base and software systems can use an registration of the PRA-Code the conflict-free correlation algorithm to create the PPN from the PZN and vice of the PPN. Additional information can be accessed versa. Databases can thus continue to work with the under the following link www.ifa-coding-system.org. PZN. Alternatively translation tables can easily be Applications in connection with the PPN are described created. As an IFA service, the PPN will be provided as in Chapter 3.4 a supplementary attribute to the PZN. 3.4 Codes und data content of retail packages Depending on the type of product, the PPN-Code is made up of different elements either the PPN alone or in combination with additional data elements. In the following table the principle variants are shown: PZN-Code 1) PPN-Code 2) Symbology: Code 39 Symbology: Data Matrix Code PZN Medicinal products requiring verification Medicinal products – not requiring verification Other common pharmacy products PPN SN LOT EXP √ GTIN √ √ √ √ optional 3) √ √ optional optional optional optional 3) √ √ optional optional optional optional Figure 3: Various applications of PPN 1) In accordance with the Fifth Book German Social Security Code (SGB V),, the continued use of the PZN in the PZN-Code is, until further notice, mandatory. 2) The PPN-Code is optional for medicinal products which do not require verification and other common pharmacy products, however it is recommended for use where in addition to the PZN other coded data elements are to be displayed. 3) May be used optionally for internal purposes. All contents copyright © IFA GmbH | Information Center for Medicinal Products | English V 2.01 Page 6 3.5 Multi Country Packs Multi Country Packs are retail packages, which are [ ) > RS Message Header available for dispensing in a number of countries. These packages have in the "Blue Box" several national Through the identification using PPN-Code, the diverse product numbers can be stored within the Data Matrix Code. For products where verification is required, it is mandatory that the product numbers of all those Envelope Format Message Envelope requirements and various country-specific information. Envelope Format product numbers for reimbursement needs, logistical countries, requiring verification should be contained within the PPN-Code. The one serial num- Formatted Data R Format Trailer S Format Header Formatted Data Format Trailer R S EO Message Trailer ber contained within the Code should correspond during verification with the product number of the Format Header T Figure 5: Envelope structure as in ISO/IEC 15434 respective country. In the application described here, data element grouping Further details of the Data content are in Chapter 4.2.8 is not required so that all data is embedded in one and the "Clear text" information in Chapter 5.6. envelope format. The use of Data Identifiers is necessary for recognition and compulsory. A complete data element comprises of a Data Identifier and a Data Field. Several data elements are combined in a code, in which the data elements are each separated with a field separator (refer to Figure 7). The Field Separator at the end of the data elements is mandatory (ASCII 29 refer to Figure 6). Character set table: Character Decimal [ 91 5B Message Header ) 41 29 Message Header > 62 3E Message Header RS 30 1E Record Separator ambiguously identified, they are embedded in accordance GS 29 1D Field Separator with the syntax of ISO/IEC 15434 (refer to Figure 5). EOT 04 04 Message Trailer Figure 4: Multi Country Pack 4 Data content and requirements 4.1 Data structure In order that data elements in a data string should be un- HEX Purpose Figure 6: ISO/IEC 15434 Character set Envelope control characters The start sequence as System Identifier (SI) points uniquely to the structure employed. The formal data structure is: • • • • Message Header Format Header Data Fields 1 to n Format Trailer • Message Trailer All contents copyright © IFA GmbH | Information Center for Medicinal Products | English V 2.01 Page 7 4.1.3 Data string Interpretation Messageheader [)>RS Formatheader 06 GS Message Trailer Code content Codeword 237 The data string is terminated with a Format trailer RS and EOT. In accordance with ISO/IEC 16022, this trailer is implied by the Macro 06. Data Field 1 DI 9N Data Field 1 Content 111234567842 Field-Separator GS Data Field 2 DI 1T Data Field 2 Content 1234567 Field-Separator GS Data Field 2 DI D Data Field 3 Content 151200 Field-Separator GS Identifier). In this application, only the ASC Data Identifier Data Field 4 DI S (DI) is used in accordance with this standard, the form is Data Field 4 Content 123456789012 defined in the following chapters. For a better overview Field-Separator GS (optional) this information is shown in table form in Appendix A. Formattrailer RS Messagetrailer EOT 4.2 Data Identifiers and data 4.2.1 General The necessary Data Identifiers (DI) are defined in the international Data Structure Standards ISO/IEC 15418 (refers to ANSI MH10.8.2; Data Identifier and Application Although the standards may leave room for specific characteristics of the data elements, this specification, Figure 7: Example of a complete data string with data which is binding for all parties, defines the data type, elements PPN, batch number, expiry date and serial data length and character sets (refer to Appendix A). number If additional DI are required, a request should be made The order of the data elements (fields) is not defined. to IFA. Apart from the usual data elements, additional elements may be used if necessary. Details are provided in the Data Identifiers that are not in this specification, which following chapters. however use the syntax of the MH10.8.2, should be correctly applied and thus lead to defined states. The 4.1.1 Message Header data acquisition and verification processes may not be compromised. The specified data structures may not be Data Matrix Code according to ISO/IEC 16022 "ASCII corrupted through any such extensions. The Data Identi- encodation" provides a means of abbreviating the header fier as set out in ANSI MH10.8.2 is strictly alphanumeric. and trailer in one Macro codeword "237" der Header The Data Identifier always terminates with an alphabetic "[)> RS 06 GS" as is shown and interpreted in Figure 7 character which may be prefixed with a number. and following table: Approved data types, character sets and string length MacroCodeword 237 4.1.2 Name Interpretation Header Interpretation Trailer 06 Macro [)>RS06GS RS EOT etc., of the data to be encoded are presented in Appendix A. Field Separator Each data element is terminated with a field separator GS. At the end of the last Data Field the field separator may be omitted because the Format and Message trailers define the end of the data string. All contents copyright © IFA GmbH | Information Center for Medicinal Products | English V 2.01 Page 8 4.2.2 Product number Data Identifier: "9N" For product identification, the Pharmacy Product The expiry date has the format "YYMMDD" YY = 2 digit Year (00-99) As the expiry date is in the future, it is a 21st Century date (2000-2099). Number is used. All further data elements in the data string correspond to the PPN. The PZN is contained in the MM = 2 digit Month (01-12)) PPN and can be extracted from it (refer to Chapter 3.2). DD = Day The expanded 8 digit PZN (PZN8) must be used. This a) Expiry date with day, month and year (DD = 01-31) yields a 12 digit PPN. b) Expiry date with month and year (DD = 00) The Product number is available for use with other Example: Expiry date June 2016 national number systems and for this reason has been defined in the ANSI MH10.8.2 as a 22 character alphanumeric string. DI Data D 160600 This example represents the date as required by German Drug Law. Example: DI Data 9N 110375286414 4.2.3 Batch number Example: Expiry date 17 June 2016 DI Data D 160617 This example shows the precise expiry date. Data Identifier: "1T" Note: : In the ANSI MH.10.8.2 standard "D" is defined as The batch number is generated by the pharmaceutical a general date. In the context of PPN, "D" is only to be entrepreneur and forms therefore the relevant data used for the product expiry date. Other dates like e.g. element for the code. production dates must use other Data Identifiers (see Chapter 4.2.6). To demarcate batch parts special defined characters can be used (refer to Appendix A). 4.2.5 Example: Data Identifier: "S" DI Data 1T 12345ABCD Serial number The serial number is generated by the pharmaceutical entrepreneur and forms therefore the relevant data element for the code. It is mandatory for the medicinal 4.2.4 Expiry date product verification process. For products, where verification is not mandated, it is optional. With regard Data Identifier: "D" to the generation of serial numbers refer to "Coding rules securPharm ". The expiry date is generated by the pharmaceutical entrepreneur and forms therefore the relevant data element for the code. All contents copyright © IFA GmbH | Information Center for Medicinal Products | English V 2.01 Page 9 Example: Example: GTIN with the number 01234567891234 DI S Data DI Data 12345ABCDEF98765 8P 01234567891234 The usable characters are described in Appendix A. 4.2.8 4.2.6 Date of manufacture Data Identifier: "16D" Product numbers for Multi Country Packs The special characteristic of Multi Country Packs is the use of multiple, country specific product numbers. The The date of manufacture is generated by the pharma- relevant number for the country must be recognised by ceutical entrepreneur and forms therefore the relevant the commercial systems and at the dispensing point. data element for the code. Depending on whether the product number is a PPN or a GTIN/NTIN, either the Data Identifier "9N" or "8P" It can be used for internal purposes or when agree- should be used, possibly more than once. ments between market partners require it. Example: Date of manufacture has the format "YYYYMMDD" PPN with the number 110375286414 and GTIN with the number 01234567891231 and YYYY = 4 digit year NTIN with the number 03400123456789 MM = 2 digit month (01-12) DD = Day DI Data a) Manufacture date with day, month and year 9N 110375286414 (DD = 01-31) 8P 01234567891234 b) Manufacture date with month and year 8P 03400123456789 (DD = 00) All other data elements can be added without restric- Example: Date of manufacture March 2012 DI Data 16D 20120300 Example:Date of manufacture 15 March 2012 DI Data 16D 20120315 tion. 5 Marking with code and clear text 5.1 Symbology This chapter describes the code guidelines for clear texts and elements e.g. the PPN Code Emblem. 4.2.7 GTIN The data medium or the symbology is Data Matrix in accordance with ISO/IEC 16022. Error correction Data Identifier: "8P" adheres to ECC 220. Other error correction methods (ECC000 to EC140) are not allowed. The characteristics The manufacturer generates a GTIN following the GS1 of the Data Matrix Code are described separately rules. It is to be used for products where, in addition to (refer to Appendix I). If a consistent matrix size is required the PPN a GTIN is given, e.g. for dietary supplements. then padding characters should be used as necessary (refer to Appendix I.5). All contents copyright © IFA GmbH | Information Center for Medicinal Products | English V 2.01 Page 10 5.2 Matrix size Usually the matrix size should not exceed 26x26 or 16x48 modules. Smaller matrix sizes are allowed provided the capacity is sufficient for the encoding of the data. Square codes should be used wherever possible. If however the packaging design or printing technology requires it, a rectangular code can be used. Square symbols Matrix size Rows 22 Columns 22 Dimension (mm) Typical Min Max X = 0,35 X = 0,25 X = 0,615 7,7 5,5 13,5 Data capacity Numeric Alphanumeric 60 43 24 24 8,4 6,0 14,8 72 52 26 26 9,1 6,5 16,0 88 64 32 32 11,2 8,0 19,7 124 91 Rectangular symbols Matrix size Dimension (mm) Data capacity Rows Columns Typical X = 0,35 Min X = 0,25 Max X = 0,615 Numeric Alphanumeric 16 36 5,6x12,6 4x9,0 9,8x22,1 64 46 16 48 5,6x16,8 4x12,0 9,8x29,5 98 72 X = Module size in mm Symbology details refer to Appendix I. 5.3 Code size and quiet zone 5.4 Positioning of the Data Matrix Code The code module size may vary between 0.25 and 0.615 There are no specific rules concerning the code mm. With due attention to the printing quality (refer positioning. The manufacturer may decide the best to Chapter 5.8) and printing system (refer to Chapter 6), positioning based on the packaging layout and the the module size may be freely set within this size range. printing conditions (refer to Appendix G). Module size means the dimensions of a matrix cell For EMA approvals, the code should be printed outside (refer to Chapter 5.2 and Appendix I.1). Typical module the "Blue Box". sizes are in the range from 0.33 to 0.45 mm. The area immediately surrounding the code should be free of printing. This area is called the quiet zone and should be at least 3 modules wide. All contents copyright © IFA GmbH | Information Center for Medicinal Products | English V 2.01 Page 11 5.5 Emblem Data Matrix Code identification technology, which makes the data more accessible and less prone to error than manual data The emblem "PPN" on the Data Matrix Code, indicates entry. to the retailer the Code, which is to be used for the automatic identification of the product number and Clear text information on Multi Country Packs: further data. For products requiring verification, thisis The country specific product information and together also the indicator for identification and verification of the with product codes should be displayed without altera- retail package. tion in the "Blue Box". No additional text marking on the Data Matrix Code should be displayed. Further optional data elements: Individual rules governing possible clear text information are beyond the scope of this specification. 5.7 Code examples Figure 8:Code Emblem In the following examples the sequence is initialised There are several different possible versions for the with Macro 06 (Codeword 237). The data elements are graphical representation of the PPN-Emblem (refer to always terminated with the character GS (ASCII 29). There is no need for a GS character following the last data element as the scanner, because of the Macro 06, Appendix C). It is possible to apply the emblem either during initial printing or inline. automatically generates the characters RS and EOT. The minimum distance must be maintained (quiet zone). The following examples illustrate the possible sizes of During a transition phase the emblem may be omitted, codes depending on the length of the data elements. giving the pharmaceutical entrepreneur more latitude The data elements lengths are determined by the during the conversion process. manufacturer, in accordance with the specification documented in Appendix A. 5.6 Clear Text information Example 1 A typical size of a code is a matrix with 26x26 modu- Product number: The PPN, or rather the PZN, is the les. Here the Data Fields have a common length. key element of the retail packaging. According to the Code Content: current applicable statutory rules the PZN must be applied in text form together with Code 39 (refer to DI Data Field http://www.pzn8.de/downloads/de/IFA_Spec_PZN_ 9N 110375286414 Codierung_DE.pdf)For this reason, the PPN will not be 1T 12345ABCD printed in text form. D 150600 S 12345ABCDEF98765 Batch number and expiry date: The clear text for batch number and expiry date is governed by statutory Example 2 regulations. The smallest size of code has a matrix with 22x22 modules. The Data Fields have a very short length: Serial number: Serial numbers are not to be printed as clear text as the verification process for medicinal products is to be fully automated, using state of-the-art All contents copyright © IFA GmbH | Information Center for Medicinal Products | English V 2.01 Page 12 5.8 Print quality Code Content: Code content testing (scan test) is fundamentally DI Data Field 9N 110375286414 1T 1ABCDE The basic requirement of a useful code is that it can D 150600 be read and that the content corresponds to the S 1ABCDEF established rules. The practical readability depends different from print quality testing. on the scanner being used and the environmental conditions.To ensure a general readability of the code, In this variant, with a matrix of 22x22 modules, the batch a standardized print quality minimum is defined. and serial number can each only have a maximum of With digital printing, each print is individual and for 7 characters. this reason each code has to be scanned to check the Example 3 contents (refer to Appendix E.3). If the data element capacity is used to the limit, then a The current standard for determining print quality is matrix of 32x32 modules will be required: set out in ISO/IEC 15415. A red light of wave length 660 nm (+/10 nm) is used. The synthetic aperture is 80% of Code Content: the module size as defined in above standard. DI Data Field 9N 110375286414 with the built-in, ISO/IEC 15415 compliant testing 1T 1A2B3C4D5E6F7G8H9I0J capabilities of the data collection system being D 150600 employed. S A1B2C3D4E5F6G7H8I9J0 Alternatively, it is possible to determine print quality The print quality is graded either numerically from Example 4 grade 4 (best) to grade 0 (worst) or alphabetically from A (best quality) to F (worst quality) (refer to table This code has a rectangular format with a matrix of below). 16x48 modules. The data fields are identical with those in example 1. Quality grades ISO/IEC 15415 Code Content: DI Data Field 9N 110375286414 1T 12345ABCD D 150600 S 12345ABCDEF98765 ISO/IEC- ANSI- With repea- Meaning Grades level ted testing 4 A 3.5 - 4.0 Very good 3 B 2.5 - 3.49 Good 2 C 1.5 - 2.49 Satisfactory 1 D 0.5 - 1.49 Adequate 0 F less than 0.5 Failed All contents copyright © IFA GmbH | Information Center for Medicinal Products | English V 2.01 Page 13 The print quality grade may not be less than 0.5 The probability that codes are read with wrong data grade (adequate) in accordance with ISO/IEC 15415. content is low but can not be completely excluded. In order to ensure readability at the end of the Technical improvements in scanners do not necessarily supply chain (and possibly during), a print quality improve the results. grade of 1.5 (satisfactory) or better should be targeted. An optimal system uses fault-tolerant scanners and codes of good print quality, to minimize the likelihood The minimum print quality requirement is generally only of successful misreads valid according to standard statistical quality control methods. (refer to Appendix E.5). Further details concerning print quality and test equipment are described in the Appendix E 6 Printing systems 8 Interoperability with different data structures and Identifiers 8.1 Interoperability based on existing Auto-ID The printing systems must be capable of printing the defined codes in the minimum print quality (refer to For manufacturers, wholesalers, pharmacies, clinics Chapter 5.8). Printing systems can be tested according and care centers, the interoperability of codes is a to the international ISO/IEC 15419. prerequisite for reliable reading and unequivocal identification of data elements. Integrated interopera- Common printing errors along with data structure and bility helps to ensure cost-effective processes for the content are described in Appendix F. involved parties. 7 The common basis for this is the standard ISO/IEC Scanning technology 15459 Unique identifiers, the system standard and The Data Matrix Code is read with standard commercial identifier standard ISO/IEC 15418 (ANSI MH10.8.2) and scanners. The optical properties with respect to mini- the syntax standard ISO/IEC 15434. mum reading distance, depth of field and resolution should be chosen to achieve a high accurate firstread With due regard to the standards, data from variou da- rate. ta sources, different symbologies and indentification systems are transferred without conflict, as shown in The code properties described in this specification, in Figure 7. terms of various module sizes and matrix sizes are the minimum requirements for the scanner. Above all, the The following established systems are used in the area application determines necessary speed and depth of of health care, which can be used concurrently, without field. Scanners can be tested according to International conflict, with the data identification as set out in this standard ISO/IEC 15423. specification. The demands on the code quality increase with the level of automation. Manually operated scanners are the most fault tolerant to poor code print quality. Fully automatic scanners (typically fixed mounted) have the most difficulty with poor code print quality. The number of read errors increases with decreasing print quality and with increasing process speed (refer to Chapter 5.8 and Appendix E). All contents copyright © IFA GmbH | Information Center for Medicinal Products | English V 2.01 Page 14 GS1 8.2 Interoperability based on XML-Standards The GS1 system is based on the product item identification using GTIN. For special solutions, the In Appendix D, a standard is described, which should GS1 has assigned a prefix for a so-called NTIN, which be used, based on XML standards and which provides in technical terms is equivalent to an article number of a neutral description of the Data Identifiers. This allows GTIN. Important features are, according to DIN 66403, for the open exchange of data as illustrated in Figure 9, the use of the control code "FNC1" and the use of regardless of symbology and data structures. Application Identifier (AI). The interoperability of Application Identifier (AI) and Data Identifier (DI) is ensured by the reference tables of ISO/IEC 15418 (ANSI <PPN> MH10.8.2). The envelope format of ISO/IEC 15434 is not <GTIN> 012345.. used in the GS1 System. <SN> 12334…. <LOT> 12ABC.. <EXP> 151231 <PZN> 01234567 HIBC 11012… …. The Health Care Industry Bar Code HIBC is administered …. by the organization EHIBCC. EHIBCC is an Issuing …. Agency following ISO/IEC 15459. The classic HIBC is prefixed by the registered System Identifier "+" (plus) and thus can be clearly identified without risk of confusion Figure 9: XML-based Data Exchange between from all other systems. The defining characteristic of scanner and system the HIBC is the compact design and the capacity for alphanumeric product codes from 2 to 18 characters. The HIBC Standard has been extended to the alternative use of Data Identifiers on all logistical levels (DI 25P) (refer to www.HIBC.de). All contents copyright © IFA GmbH | Information Center for Medicinal Products | English V 2.01 Page 15 Appendix A - Overview of the Data Elements and Data Identifiers The following table specifies the properties of the individual Data Elements and the equivalent Data Identifier: Data elements XML-node DI Data type Data format Character Character subset length Pharmacy Product Number <PPN> 9N AN --- 4-22 0-9; A-Z No special characters No lower case characters No diacritics Batch number <LOT> 1T AN --- 1-20 0-9; A-Z; Allowed special characters "-" and " _ " No lower case characters No diacritics Expiry Date <EXP> D Date YYMMDD 6 0-9 Serial number <SN> S AN --- 1-20 0-9; A-Z No special characters No lower case characters No diacritics Date of manufacture <MFD> 16D Date YYYYMMDD 8 0-9 GTIN or NTIN <GTIN> 8P N --- 14 0-9 Note concerning – "Data format": Only for the "date" a firm data format is given. Note concerning – Special characters used in the batch number: The only special characters (non-alphanumeric) allowed in the batch number are the underscore "_" and the hyphen "-". All other special characters have different meanings in diverse applications. The use of such characters present a high risk of incorrect translation and on this basis is excluded here. Lowercase characters are not allowed because some systems are unable to distinguish between upper- and lowercase characters. Additionally because of the risk of confusion between lower and upper-case characters, lowercase characters are excluded from use. To add additional Data Identifier to this specification, please contact IFA. All contents copyright © IFA GmbH | Information Center for Medicinal Products | English V 2.01 Page 16 Appendix B - PPN check digits Algorithm The PPN check digits (refer to Chapter 3.2) are calculated according to the modulo 97. Here the characters of the PPN, are assigned their decimal value 00-127 according to the ASCII-Table. Each position of the PPN is then weighted by a factor. The product of the ASCII decimal values are summed and divided by 97. The rest is the numerical value for the two-digit check digit from 00 to 99. If the rest has a single-digit residual value then it is padded with a leading zero. The weighting of each digit starts on the left starts with "2" and is incremented by "1" for each of the following characters. This algorithm provides the check digits for both numerical, as well as alphanumerical PPN. Example of formation of the PPN check digits: For the German market, the PPN contains the pharmaceutical central number (PZN), prefixed with the "Product Registration Agency Code" "11". The PPN is formed using only the 8-digit PZN (PZN8). The PZN7 (seven-digit PZN) is converted into a PZN8 by inserting a leading zero. For details on PZN8 refer to: http://www.pzn8.de/downloads/de/IFA_Spec_PZN_Codierung_DE.pdf. For the PZN with the prefix 11 "1103752864" the PPN check digits is calculated as follows: PRA-Code PZN PPN 1 1 0 3 7 5 2 8 6 PZN check digit 4 ASCII Value 49 49 48 51 55 53 50 56 54 52 Weighting 2 3 4 5 6 7 8 9 10 11 Product of ASCII value and weighting 98 147 192 255 330 371 400 504 540 572 PPN check digit 1 4 Sum 3409 / 97 = 35 Rest 14 The check digits are the numerical remainder 14, and provides the last two digits of the PPN. The complete PPN is thus: 110375286414. The rest is taken as a numeric value and is not converted into the corresponding ASCII value. This ensures that the check digit consists of only the digits 0 through 9. A numerical sequence will be thus remain numeric. Note: Following testing of the PPN check digits then the PZN check digit can be tested. If the PZN check digit is correct then most common errors can be excluded. All contents copyright © IFA GmbH | Information Center for Medicinal Products | English V 2.01 Page 17 Appendix C - Code Emblem The string "PPN" in the font "OCR-B" has been defined as the PPN-Code Emblem. The graphical representation is to be found the following sketch: Nominal dimensions: c d a: results from the chosen module and matrix sizes b: for a square code a = b; for rectangular – depends e f on chosen module and matrix sizes c: 0,4 * a a d: *) e: results from the required quiet zone *) (Quiet zone refer to Chapter 5.3) f: results from the font type and dimension c b *) The dimensions d and e should be chosen so that the code is associated with the emblem. Tolerances The tolerances can be freely determined according to the selected printing process. The following orientations are in principle possible: Folgende Ausrichtungen sind prinzipiell möglich: In exceptional cases, the emblem can be applied to an adjacent surface. All contents copyright © IFA GmbH | Information Center for Medicinal Products | English V 2.01 Page 18 Appendix D - (informative) Interoperability based on XML-descriptors D.2 Data Format Identifier (DFI) By the transmission of XML-Standard data elements, D.1 General the properties for the display of the data in the Data Matrix Code are assigned to the Data Format Identifier For manufacturers, wholesalers, pharmacies and (DFI) and only this is transferred. clinics, the interoperability of coding is a prerequisite for reading and unequivocal identification of data The DFI tells us which data envelope according to ISO/ elements. Integrated interoperability helps to ensure IEC 15434, which Application Identifier (AI or DI) and- cost-effective processes for the involved parties. The whether a macro according to ISO/IEC 16022 is used. interoperability is based on the joint use of the IEC The DFI instructions can be found in Table 1. standards 15434 Syntax for High Capacity Media, ISO/ IEC 15459 Unique identifier, as well as System and Data Identifiers according to ISO/IEC ISO/IEC 15418. In order to provide manufacturers and users in XMLFormat-ID Data-TypData Identifier Format Identifier nach ISO/IEC nach ISO/ IEC (DFI) dard is described for interpreting the data. This applies both for data transmission to the printer, as well as for data transmission from the code nach ISO/IEC 15434 16022 15418 IFA 06 Macro 06 DI-ASC GS1 ------ FNC1 AI-GS1 the pharmaceutical field an even greater interoperability, in this Appendix, an XML-based stan- Data Identifier/ Application Identifier Table 1: Data Format Identifier reader to the connected systems. The DFI can have the values "IFA" or "GS1" and is transThe Standard set out in this appendix applies only to ferred in the attribute of the higher level XML node the data contents, i.e. it does not refer to the layout "<Content>". properties of the code, which include the provisions of the clear text printing and symbology (eg, Data Matrix D.3 XML-Node for Data Code). During data transmission and in accordance with this standard, the data will be uniformly named The table below shows the XML-Nodes for data and using XML nodes independent of the Data Identifiers their mapping to the Data Identifier (DI) und Applica- used in the code. Following layers are formed in the tion Identifier (AI): representation of the data: Application: XML nodes Data envelope ISO/IEC 15434 e.g. Format 06 or system identifier according to DIN 66403 e.g. "FNC1 Data structure Data Identifier (DI) or Application Identifier (AI) Symbology e.g. Data Matrix Code XMLKnoten DI (dfi="IFA") AI (dfi="GS1") Beschreibung <PPN> 9N ---- Produktnummer <GTIN> ---- 01 Produktnummer <LOT> 1T 10 <EXP> D 17 Verfalldatum <SN> S 21 Seriennummer Chargenbezeichnung Table 2: XML-Nodes for Data All contents copyright © IFA GmbH | Information Center for Medicinal Products | English V 2.01 Page 19 The complete list of currently defined nodes is shown When reading the code, the scanner puts the data in Appendix A. On this technical level of the description content in the XML structure, by using the corres- there is no difference between NTIN and GTIN. On this ponding XML nodes. By default, data transmission basis the comprehensive term GTIN is used. from the code reader to the higher systems only the data is transferred without the "DFI". Output of <Content> envelops the XML nodes <Data> "DFI" is optional for cases when e.g. the correct (refer to Appendix D.4 and Appendix D.5). use of structures within the code is to be checked. From the XML-Data and the DFI value contained therein, Generic XML description of data transmission to the printer derives all necessary information to create the printer and from the code reader: the Data Matrix Code. This includes the data elements, the DI or AI, the delimiters and the header. D.4 Implementation The XML description can be used both in the data <Content dfi="value_dfi"> <Daten _ 1>value _ Daten _ 1</Daten _ 1> <Daten _ 2>value _ Daten _ 2</Daten _ 2>. <Daten _ n>value _ Daten _ n</Daten _ n> </Content> transfer to the printer driver, as well as for the data outWhen transferring from the code reader the value of tation) "dfi" is optional XML-Node MESSystem MESSystem User-/Applicationlevel put from the code readers (refer to schematic represen- MH10.8.2DataIdentifier Application Identifier Terminal Printer Terminal Reader Printer Reader Systemlevel Driver Code Figure 7: Data transfer based on XML description The drivers for interpreting the XML description can be part of the higher-levels systems (MES) or the printer and reader. The use of the unified description enhances interoperability and helps to reduce errors. Further, the uncertainty regarding non-printable control character in transmission and interpretation is eliminated in the XML description. All contents copyright © IFA GmbH | Information Center for Medicinal Products | English V 2.01 Page 20 D.5 Examples In the following examples the use of the four data elements product number, batch number, expiry date and serial number is illustrated: Example 1: Data transfer to printer – IFA-Format Product number: PPN System Data Identifier: DI Data Format Identifier: IFA Printer <Content dfi="IFA"> PPN:111234567842 Batch:1A234B5 Expiry Date: 31.12.2015 Serial number: 1234567890123456 Data Carrier <PPN>111234567842</PPN> <LOT>1A234B5</LOT> Mac069N111234567842Gs <EXP>151231</EXP> 1T1A234B5Gs <SN>1234567890123456</SN> D151231Gs </Content> S1234567890123456 Coding:"IFA" Example 2: Data transfer to printer – GS1-Format Product number: GTIN System Data Format Identifier: GS1 Printer <Content dfi="GS1"> GTIN: 04150123456782 Batch: 1A234B5 Expiry Date: 31.12.2015 Serial number: 1234567890123456 Coding: Data Identifier: AI "GS1" Data Carrier <GTIN>04150123456782</GTIN> <LOT>1A234B5</LOT> FNC104150123456782 <EXP>151231</EXP> 101A234B5FNC1 <SN>1234567890123456</SN> 17151231 </Content> 211234567890123456 Example 3: Data transfer from scanner – IFA-Format Product number: PPN Data Carrier Data Identifier: DI Data Format Identifier: IFA Scanner <Content> <PPN>111234567842</PPN> Mac069N111234567842Gs <LOT>1A234B5</LOT> 1T1A234B5Gs D151231Gs <SN>1234567890123456</ S1234567890123456 SN></Content> <EXP>151231</EXP> System PPN: 1101234567842 Batch: 1A234B5 Expiry Date: 31.12.2015 Serial number: 1234567890123456 Example 4: Data transfer from scanner – GS1-Format Product number: GTIN Data Carrier Data Identifier: DI Data Format Identifier: GS1 Scanner <Content> <GTIN>04150123456782<GTIN> FNC104150123456782 <LOT>1A234B5</LOT> 101A234B5FNC1 <EXP>151231</EXP> 1717231 <SN>1234567890123456</SN> 211234567890123456 </Content> System GTIN: 04150123456782 Batch: 1A234B5 Expiry Date: 31.12.2015 Serial number: 1234567890123456 If you have any questions or suggestions about this appendix, please send them to IFA GmbH. All contents copyright © IFA GmbH | Information Center for Medicinal Products | English V 2.01 Page 21 Appendix E - Quality and control of the code content (informative) During the intake checking of packaging materials, due care should be paid to the extent and nature of the control of the pre-printed codes or the placeholders for E.1 Data Matrix Code as dot code code labels. The achievable print quality of the code depends on the substrate material and the printing pro- In accordance with the minimum requirements for print cess and may therefore be significantly better than the quality it is to be noted that codes such as dot code minimum requirement. where the printing quality is tested in accordance with ISO/IEC TR 29 158 (Direct Part Marking should not be E.3.2 Scan testing used. Dot codes are not specified for Data Matrix in the ISO/IEC 16022. Scanners can often not read dot codes During the scan test, the built-in acquisition system or read rates are unacceptably low. The only exception tests if: here are dot codes where the individual dots (data cells) are so wide and that they touch each other so that they • the code is present, pass the ISO/IEC 15415 test and are generally readable. • the correct symbology was used and • the content complies with the specifications. E.2 Qualification and validation measures It also ensures that non-existent, non-readable or incorrect Codes are rejected. The equipment for applying and testing of codes is subject to the general qualification requirements. Likewise E.3.3 Print quality testing the ancillary processes have to meet the general validation requirements. The print quality can generally be tested with two different methods: Definition and scope of qualification measures and the validation process are not part of this specification. 1. Using measurements according to ISO/IEC 15415 (for details refer to Appendix E.6.1) E.3 Checking codes for data content and print quality 2. Using built-acquisition systems (for details refer to Appendix E.6.2) with the ability to analyze and de- E.3.1 General requirements termine the print quality according to ISO/IEC 15415 The location and extent of testing equipment for scan ability and print quality will depend on whether the packaging materials are used pre-printed or in-line. All contents copyright © IFA GmbH | Information Center for Medicinal Products | English V 2.01 Page 22 E.4 Printing variants E.4.1 Packaging with pre-printed codes E.4.2.2 Continuous scanning and spot checks on print quality The codes are printed on the packaging inline during the medicine packaging process. As described in Ap- E.4.1.1 Quality control by the packaging manufacturer - assured print quality from the supplier pendix E.3.2, through the detection system each individual code is subjected to read checking. Also, the serial number of each code is recorded. In contrast with Appendix E.4.2.1 a testing device will be used to check The codes are applied by the packaging material sup- the printing quality of each code compliance to ISO/IEC plier. He has to ensure that the codes exist, are reada- 15415 (for details refer to Appendix E.6.2). ble, exhibit the correct symbology, contain the defined content and record the serial numbers. Furthermore, E.5 Quality control statistics he shall take the appropriate measures to ensure that the code content and the the print quality of the printed Testing of the print quality, according to to ISO/IEC codes meet the minimum defined requirements. This is 15415, must always be performed in the context of a checked by the pharmaceutical entrepreneur as part of standardized sampling procedure using generally ac- supplier qualification. cepted statistical rules. Briefly, this means: if one code should fall below the acceptable level, then within the The applied codes are scanned once again during the production batch more products have to be checked. medicine packaging process. In these cases, a com- If the error in the application of standardized sampling plete check is carried out at the place of use of the pre- procedure exceeds the acceptable level, appropriate sence, readability and use of the correct symbol and corrective action has to be taken. correct content. The actual serial number is also captured during this step. Sampling procedures in accordance with ISO 2859 and ISO 3951 should be used. In these standards, a defined E.4.2 Inline printing of packaging without pre-printed codes statistical method is described which leads to the assessment of whether a production batch is acceptable or not. The sampling methodology is designed to intel- E.4.2.1 Continuous scanning and spot checks on print quality ligently control the time and effort in quality inspection costs. The codes are inline printed on the packaging during The underlying principle of this statistical method is that the medicine packaging process. As described in Ap- a certain level of defects is acceptable. pendix E.3.2, through the detection system each code is subjected to scan testing. Also, the serial number of The inline inspection of the print quality according to each code is recorded. When required, additionally a ISO/IEC 15415 (refer to Appendix E.3.3) is considered, testing device should be used to carry out offline quality in the context of the sampling procedure, as a very fre- control of the printed code in accordance with ISO/IEC quent random sampling. The statistical method for in- 15415, (for details refer to Appendix E.6.1). telligent control of the quality testing that can also be used for inline inspection. All contents copyright © IFA GmbH | Information Center for Medicinal Products | English V 2.01 Page 23 E.6 Testing equipment E.6.2 E.6.1 Many acquisition systems for the scan testing (refer to Testing in compliance to ISO/IEC 15415 Testing based on ISO/IEC 15415 Appendix E.3.2) have the ability to continually analyze and test the print quality inline. This is a test, which is The print quality is measured in compliance to ISO/IEC related to ISO/IEC 15415. The method is often used as 15415 with measuring devices (verifier). The measu- an alternative to offline testing (refer to Appendix E.3.3). ring devices meet the requirements of the international These systems use the same criteria for testing the print standard ISO/IEC 15426-2. The most important require- quality as defined in the ISO/IEC 15415. However, there ments of a measuring device are: are constraints on the scanner, such as the wavelength and angle of incidence of the light source or repeated • Calibration has to be traceable back to nationalstandards (e.g PTB, NIST). • The measurement must be performed under code testing from various angles, which can not be provided for because of the integration in the packaging line. predefined conditions regarding lighting, camera angle and distance (Template: ISO/IEC 15415 The test results are related to ISO/IEC 15415. Such re- reference design). sults should be set in correlation to a verifier result (refer • Ambient light may only change the measurements- to Appendix E.6.1), within e.g. the qualifying process. within the allowable tolerances of ISO/IEC 15426-2. • A regular calibration of equipment must be carried out by the user. • A regular monitoring to check measurement accu- Data capture systems which test according to the ISO/ IEC 15415 method, ensure a complete, 100% inline inspection (scan and print quality control) of each code. racy must be carried out by the user. • The requirements of the symbology standard with- There remains a small risk, as the acquisition system respect to the reference decode algorithm must be which is primarily designed for best scanning results maintained, so that different decode algorithms do e.g. adaptive lighting, auto-focus and auto-zoom lenses not lead to different results. or optimized decoding algorithms. In such conditions, the data acquisition system, despite comparison with The measurement is performed offline. Because of the test results from ISO/IEC 15415, can sometimes costs, random samples tests are normal. A 100% tes- provide different quality results. ting using this method of measurement is not justifiable. Reading devices such as commercially available barcode scanners may not be subjected to the same restrictions as measuring devices in regards to reading distance, reading angle, lighting angle and ambient light conditions. Scanners must be capable of reading codes under a wide range of conditions. The defined minimum print quality supports this. There remains a small residual risk that repeated print quality tests of the same codes produce slightly different results. This applies even if the same codes are tested with different verifiers. All contents copyright © IFA GmbH | Information Center for Medicinal Products | English V 2.01 Page 24 E.7 Colours and materials Reflectance margin – similar to Modulation, except that the code words which were corrected by the Error Acceptable colours and substrates: correction are set here as Grad 0 (= Fail) in the decision matrix. • The print substrate must have a uniform diffusely reflecting surface. Surfaces that are highly reflective Contrast Uniformity – MOD values are determined (metallic, metallic effects), are unsuitable. Rough or for all code words. The MOD values are used for de- embossed surfaces are also not to be used. The termining the modulation and the reflection area. The following colour requirements are based on the as- contrast uniformity is the worst MOD value (informative). sumption that commercial scanners use red light. • Substrate colour: white, red, yellow or orange (under red light). • Module or code colour: black, blue or green (dark under red light). • Negative Data Matrix symbols, in which the colours of the substrate material and the module or matrix are reversed, are allowed. • When using inkjet printing on outer packaging it Errors in Modulation, Reflection area and Contrast Uniformity refer to: Appendix F.3.2.3 and Appendix F.3.2.4 and Appendix F.3.2.9 and Appendix F.3.3.2 and Appendix F.4.1 and Appendix F.4.5. may be required to provide a corresponding recess in the surface coating so that the ink adheres and Unused Error Correction (UEC) – the larger the value dries. the less errors had to be corrected (refer to Appendix F.3.1.2). The minimum quality requirement (refer to Chapter 5.8) determines the minimum contrast and thus the scope- Axial Non-Uniformity (AN) – code has been expan- for coloured codes. ded or compressed in the x or y axes (refer to Appendix F.3.1.3). E.8 Quality criteria in accordance with ISO/IEC 15415 and ISO/IEC 16022 Grid Non-Uniformity (GN) – degree of grid distortion compared to the ideal grid. Grid non uniformity does Listed below are the most important test parame- typically not influence axial non uniformity (Appendix ters from the standard with short description: F.3.1.4). Decode – Reference decode and Code internal struc- Fixed Pattern Damage (FPD) – All code parts which ture (Errors Appendix F.1 and Appendix F.1.9 and Ap- do not contain data or error correction values are che- pendix F.2). cked for damage. This means the L pattern for code orientation recognition, the clock track for grid recon- Symbol contrast – Contrast between the brightest struction, and the quiet zone. Contrast non-uniformity and the darkest elements in the complete symbol (Error which is in the data area graded as modulation is an refer to Appendix F.1.1). additional aspect if it appears in the fixed pattern (refer to Appendix F.3.2.1). Modulation (MOD) – refers to the reflectance uniformity of a symbol’s light modules to each other and al- Print growth – informative parameter which shows so the reflectance of the dark modules to each other. if black elements have been printed wider or smaller Reflectance margin – similar to Modulation, except that than intended (refer to Appendix F.3.2.2 und Appendix the code words which were corrected by the Error cor- F.3.2.3). rection are set here as Grad 0 (= Fail) in the decisionmatrix. All contents copyright © IFA GmbH | Information Center for Medicinal Products | English V 2.01 Page 25 Module size – – The size of a single matrix cell of a complete code is called Module size. The size of the Appendix F - Common problems (informative) module will determine the scanner specification in regard to depth of field, resolution and minimum reading In this Appendix common faults or errors are described, distance (refer to Appendix I.1). grouped into errors in data structure, data content and printing errors. Matrix sizes – The complete Code is composed of individual matrix cells (= Module) of a set identical mo- This summary should help to avoid problems in the ge- dule size. The international standard ISO/IEC 16022 de- neration of codes and as a guideline in the creation of fines the smallest Matrix size as 10x10 Modules and the software programs to give tips which errors are likely largest matrix size as 144x144. In practical applications and thus to help with error handling. allowed matrix sizes are limited in order to restrict the relationship of camera resolution to matrix size and to F.1 Faults in the data structures have enough pixels per module and thus increase scan reliability (refer to Appendix I.2). F.1.1 FNC1 used as the start sequence instead of Macro 06 Explanation: The PPN data structure does not use a GS1 "Application Identifiers" (AI), but "Data Identifier" (DI). In this case, the FNC1 character shall not be used because it indicates that a GS1 structure follows. Instead, the 06 Macro codeword has to be used instead of the FNC1 to designate that the DI data structure is used. F.1.2 Macro 05 used instead of Macro 06 Explanation: The Macro 05 is also an identifier of a GS1AI structure and may not be used in place of Macro 06 All contents copyright © IFA GmbH | Information Center for Medicinal Products | English V 2.01 Page 26 F.1.3 FNC1 as field separator instead of GS (ASCII 29) F.1.5 Mixed Data Identifier (AI and DI) used Incorrect data identifier for "batch " used. AI "10" instead of DI "1T" Explanation: In the PPN, several Data Fields can be used consecutively. A field separator is required to identify when a Data Field ends and the next element begins. In case of GS1 data structures, the scanner replaces the FNC1 character with a GS character. In the "Date" with AI "17" instead encoding of DI "D" case of the PPN, the GS character must always be encoded directly, and a translation is not necessary. Only after the identification of a code with GS1 data structure, through reading an FNC1 character a the first position, translation is carried out. F.1.4 Missing Macro 06 The serial number is coded with AI "21" insteadof DI "S" Explanation: The PPN uses the message envelope in accordance with ISO/IEC 15434. It is mandatory to code Macro 06 as the first character in order to form the The AI "01" (for GS1 GTIN) has been used instea- PPN correctly and to allow the further processing to dof DI "9N" for the PPN execute an additional plausibility check and as an explicit way of differentiation to other ISO compliant data structures. All contents copyright © IFA GmbH | Information Center for Medicinal Products | English V 2.01 Page 27 F.1.6 Incorrect Data Identifier (DI) used F.1.8 Wrong error correction The DI "14D" is used for the expiry date. In the context of In this example, the PPN structure is correct. The code the PPN DI "D" is always used for the expiry date. This is version is wrong. It should use the data matrix code with not a serious error but rather a case which is excluded ECC200 Reed Solomon error correction. Here the data by this specification to limit the number of variants and matrix code is used with the error correction ECC040 for instances, where in parallel, French CIP- and PPN- (CRC error correction). The Data Matrix ISO/IEC 16022 coding allow the same date format YYMMDD to be recommends not using this version (method is outda- used. (14D has YYYYMMDD) ted and error correction is less powerful). Only the ECC200 version is allowed in this PPN specification. F.1.9 Code with incorrect pad character Here the DI "25P" has been used for the PPN together with the IAC code PP which is assigned to the IFA. In a An increase in the matrix size is always associated with general ISO context this variant is not allowed, because an increase in the data capacity e.g. from 52 to 64 al- "25P" requires a company identification code (CIN) after phanumeric characters. If e.g. 56 characters are nee- the IAC Code PP and then a company assigned article ded, then the matrix size with a capacity of 64 charac- number. ters is required. The free capacity of the code is filled with pad characters. F.1.7 Field separator GS with fixedlength Data Field is missing The underlying DI definition of the PPN in accordance with ISO/IEC 15418 requires the use of a field separator (GS) after each Data Field. The GS1 structure uses exception handling in some fixed-length Data Fields. This exception allows the omission of the field separator with certain Data Fields. This version is implemented here with the PPN. The fixed-length fields are not ended with the field separator GS. All contents copyright © IFA GmbH | Information Center for Medicinal Products | English V 2.01 Page 28 F.2 Data content errors F.2.1 PPN check digit error F.2.4 Missing PZN check digit The PPN definition requires check digits, calculated ac- The check digit is missing from the PZN code. The sub- cording to Modulo 97, as a terminator in the Data Field sequent PPN check digit has been calculated usingone "9N" (refer to Appendix B). In this example, incorrect digit less. check digits have been encoded. F.2.5 F.2.2 PPN check digit missing PRA-Code incorrect / not plausible Explanation: The check digit, which is created over the The PPN system can be used with a wide variety of ap- PRA-Code (11 in the PPN) and the following PZN8 is plications. The PPN, in which the PZN8 number is em- missing . Since the Data Field is terminated with the se- bedded is always marked with the PRA-Code 11 after parator GS and the check digit of the PZN8 check digit DI "9N". Other PRA-Codes are possible but may never is correct, it is easy to recognise this error. be used to encode a number PZN8. F.2.3 F.2.6 PZN check digit incorrect PRA-Code missing The PPN contains a PZN8 number with the identifier In this example, the PRA-Code 11 is missing. The PZN8 "9N" in an internationally unique data structure. In this coding comes directly after the "9N". As it can be assu- case, the code has a PZN with an incorrectly calculated med that the error was made unintentionally, the PPN check digits and then the PPN check digits calculated, check digits are correct based on the existing data con- embedding the error and giving it the appearance of tent. being correct. . All contents copyright © IFA GmbH | Information Center for Medicinal Products | English V 2.01 Page 29 F.2.7 Incorrect date F.3 Printing errors The codes in this chapter are to illustrate errors which can occur while printing. The content has no significance and was arbitrarily chosen. In this example, the month value is not in the range 1 to F.3.1 General printing errors F.3.1.1 Symbol contrast is too low 12. F.2.8 PZN7 used a) Good symbol contrast In the PPN a PZN8 must always be used. This example uses an old PZN7 number. To convert a PZN7 to a PZN8, a 0 (zero) is prefixed before the PZN7. b) Poor symbol contrast because background is not white F.2.9 Incorrect conversion of PZN8 to PZN7 nicht weiß ist In this example, the 0 which should be have been inser- c) Poor symbol contrast because code is gray ted as the first character to the PZN7 has been appen- instead of black ded as the last character. F.3.1.2 Modules too light – low UECUEC The red dots appear white under red light. But they are parts of the matrix which should be black. The errors are evaluated by the unused error correction, and correctly decoded because the error correction allows thecorrect decoding, despite the error. All contents copyright © IFA GmbH | Information Center for Medicinal Products | English V 2.01 Page 30 F.3.1.3 Axial Nonuniformity (AN) F.3.2.2 Excessive ink a) Symbol distorted in Y Axis Because of excessive ink, absorbing substrate or by an incorrect print setting, the code has been overprinted. Pixel reduction can be used to compensate print gain b) Symbol distorted in X Axis F.3.2.3 F.3.1.4 The printer setting is wrong. Grid Nonuniformity (GN) F.3.2.4 Code too thin Irregular code print Here are two examples where the grid inside the symbol has been distorted without changing the outer square form of the symbol. The irregular image can have several causes. The nozzle plate may be dirty. The gap between the print head F.3.2 Bubble-jet printing and the substrate is possibly too great. The print head possibly has a static charge, which attracts a part of the A tiny heating element in the nozzle, vaporises the inkto ink droplet back to the head. create a bubble, which forms a droplet and ejects it from the print head. F.3.2.1 Nozzle failure Some of the printer nozzles are blocked and produce lines in the code. The print head needs to be cleaned or replaced. Cleaning should be carried out in accordance with the manufacturer’s specifications. All contents copyright © IFA GmbH | Information Center for Medicinal Products | English V 2.01 Page 31 F.3.2.5 Shadows in the code image F.3.2.7 Printing without speed sensor (Product speed unknown and variable) (Codedistorted) The shadows in the print image are caused by a timing error. The print head has several rows of nozzles where The code is distorted. There may be axial distortion the timed release of the ink droplets is vital for printing (code does not appear quadratic). With slippage or quality. If the timing of the release of the ink droplets is operation without a speed sensor, the individual matrix incorrect, this leads to the formation of a shadow which columns and rows (depending on the print direction) can be seen here to the left of the matrix elements. can vary widely in their widths. This causes grid distortion. Similar effects may appear if the print head is dirty, is statically charged or is too far from the substrate. F.3.2.8 The following example shows quite distinctly the sha- Printing with ink for highly absorbent materials on lacquered packaging (or metal or plastic) dows caused by the wrong speed setting In this case, the ink does not dry fast enough and smears. To make matters worse, in this example, the part had a curved surface. F.3.2.6 Incorrect ink F.3.2.9 Printing on a very strongly absorbingsurface The wrong ink has been used which then causes poor start-up performance. This is evident from the fact that at each print-start the vertical lines on the left side ap- There has been here an excessive ink absorption into pear irregular and frayed. the substrate (blotting paper effect). The printing elements are much thicker than would normally be expec- . ted. A possible remedy is by reducing the number of pixels or through the use of a faster drying ink. All contents copyright © IFA GmbH | Information Center for Medicinal Products | English V 2.01 Page 32 F.3.3 Continuous inkjet printing (CIJ) F.3.3.3 Direct Laser marking (a continuous stream of ink droplets is electrostatically A powerful laser changes the colour of the labeling ma- deflected) terial or printed ink is removed. F.3.3.1 Printing as a dot code Possible reasons for bad code: • colour is not completely removed by the laser • laser setting is too strong • print as a dot code • wrong colour combination (red for scanner) In this case, the individual dots are compressed together. A print image has been produced that may be F.3.4 Thermal transfer printing used as a normal printed code rather than as a DPM Heat is transmitted to a ribbon which then transfers code. theimage to the product or a label. F.3.3.2 Distorted Possible reasons for quality problems: • Non-smudge-resistant thermal transfer ribbon • Temperature setting is too high • Temperature setting is too low • Speed is too fast In this code the dots of the matrix are not positioned correctly. The print head gap to the printed pattern is • Pressure of the printing head (head runner) is too low too large and / or there is insufficient electrostatic de- • Heating elements are not working flection of the ink droplets. • Wrinkles in the ribbon • Ribbon position changes If these errors were corrected and the code is no longer • Label position changes distorted, then the code remains a DPM code because • Printing too close to the edge the dots are scattered in the matrix. If such printers are used, it should be set so that the printed image as in the previous Appendix F.3.3.1 is produced . All contents copyright © IFA GmbH | Information Center for Medicinal Products | English V 2.01 Page 33 F.4 Material related errors F.4.1 F.4.3 Print on shiny metallic surface Printing on translucent plastic The reflective metal surface causes an uneven illuminaIn this case, a code was printed on a plastic materi- tion, depending on the angle of the illumination source al. The plastic is translucent. Light penetrates relatively (scanner) to the code. Partial reflections make the dark deeply into the material and then is partially reflected parts of the code appear light. back. The resulting effect is an apparent formation of shadows on the edges of print. This is because the lar- This case is a typical DPM code. This is not approved ge unprinted area of the material reflects more light than for use as an IFA product code, because scanning re- in the small unprinted structures. quires special DOME light (very diffuse, non-directional lighting, which minimises reflections and angle depen- F.4.2 Opaque white on transparentplastic film to thin dencies). F.4.4 When a code is printed on a thin film which has been Code printed on screen printedsubstrate previously printed on white, two effects are created. If there is a cavity under the film or the film is on a black background, all the light that passes through the thin white layer is absorbed. The code loses contrast. If the film is on a light background, the light permeated by the light surface is reflected. The reflection is uneven and results in a similar effect to that in Appendix F.4.1. When a code is printed on the raster of a screen-printed substrate (here black, yellow and blue dots, which appear green to the human eye) the dots interfere with the code. The larger the code module size is in relationship to the raster grid size, the better the raster can be removed by filtering (highly magnified example). All contents copyright © IFA GmbH | Information Center for Medicinal Products | English V 2.01 Page 34 F.4.5 Code covered with a transparent film Appendix H - Bubble-Jet – Best Practice (informative) These printer systems often have a cartridge system with an integrated print head. Other similar systems use print heads, which are separated from the ink reservoir. All such printer systems have a specific resolution (e.g. 300, 600, 720 dpi). Furthermore, the ink drops overlap to create a smooth edge. The print density can be affected by the ink type and amount. These variables must be considered in the printer setting. It is advantageous if the printing system only allows tho- If the code is covered by a packaging film, this film se code size settings that can be printed without dis- must fit tightly. There may be no air bubbles between tortion. If the recommended size gradation of the code the code and foil. Weld seams, wrinkles and markings that is enforced by the printer‘s resolution is not obser- on the film at the code position are not allowed. ved, then printing errors will become worse as the print resolution is reduced (necessary at higher speeds) Appendix G - Layout –Best Practice (informative) These examples show how even on relatively small areas the available code and plain text may be printed: All contents copyright © IFA GmbH | Information Center for Medicinal Products | English V 2.01 Page 35 Appendix I - Data Matrix Code –Symbology description (informative) I.2 Matrix size The matrix size is determined by the number of modu- The Data Matrix Code, in the current version ECC200, les. ISO/IEC 16022 is the minimum size of a matrix of can be either square or rectangular. 10x10 square version, modules, and the maximum size is 144x144 modules. I.1 Module sizes The rectangular version starts with the matrix size 8x16 Module size means the dimension of a matrix cell of and increases to 16x48 modules. In Chapter 5.2, the the complete code. The module size is freely scaleable PPN matrix sizes are described within the dimensions described in Chapter 5.2 and determined by the printing and scanning technology used Example matrix size 32x32 module: Examples of identical codes in different module sizes: Example matrix size 16x16 module: Example matrix size 16x48 module: Example matrix size 104x104 module: All contents copyright © IFA GmbH | Information Center for Medicinal Products | English V 2.01 Page 36 I.3 Fixed pattern I.4 Data area The Data Matrix Code comprises of fixed pattern andan area for the code data. The red area is for data storage of the data matrix codes. In this area there are the code words for data The red marked portion of the fixed pattern is called the and for error correction. Symbols up to to a matrix size finder pattern "L". This pattern allows the scanner tolo- of 26x26 modules only have one red data segment. cate and orientate the code. I.5 Pad characters The table shown in Chapter 5.2 with the two square 26x26 and 32x32 versions of code modules have 44 or 62 codewords for data. If e.g. 48 codewords are to be used then the capacity of a 26x26 matrix is not sufHere the red marked portion of the fixed pattern is ficient. A 32x32 matrix with 62 codewords must then be called the clock track. The clock track indicates the ma- used. The difference between the capacity of 62 code trix of the code. words and the required 48 code words is filled with pad characters. The padding must be performed in a fixed schema, which is defined in the Data Matrix ISO/IEC 16022. If the application is always with a fixed matrix size e.g. 26x26 modules, although sometimes 22x22 or 24x24 The red areas of the fixed pattern are only used in code modules or modules would be sufficient, the excess from a matrix code sizes of 32x32 modules and larger. code capacity should be filled with padding characters. The above illustrated L- and clock patterns are repeated in these codes If filled with (scanner) readable data, the data structure is destroyed and the code is unusable. The red-marked outline of the code is the lowest permissible Quiet Zone width. The width is a matrix row or column. It is recommended, in practice, to use the treble the width. All contents copyright © IFA GmbH | Information Center for Medicinal Products | English V 2.01 Page 37 I.6 Error correction The error correction of the data matrix codes is defined in ISO / IEC 16022. The Reed Solomon method is employed. It should be noted that the process of error correction is based on the code words and not on the individual matrix cells. In the illustration, a codeword consisting of 8 displayed matrix cells is displayed. Each matrix cell is highlighted in the picture with the red checkerboard pattern. If a matrix cell appears light instead of dark, then the codeword is invalid. If all matrix cells are the wrong colour, the codeword remains invalid. If a partial area of the code is ruined, then the code words from this area are impacted. But it is possible that even the data from relatively large areas of seemingly faulty (continuous) areas may be reconstructed by the error correction. If many small, matrix sites randomly scattered over the entire symbol are impacted, then many code words will be impacted and the error correction capability has reached its limits. All contents copyright © IFA GmbH | Information Center for Medicinal Products | English V 2.01 Page 38 Appendix J - Glossary • Data Identifier (DI): From the "ASC MH 10 Data As a matter of principle, the terms and definitions of ISO Identifier Maintenance Committee" assigned Data /IEC 19 762 Part 1 and Part 2 apply in this specification. Identifiers, listed in the standard ANSI MH10.8.2 The following are additional terms and abbreviations (normative reference: ISO/IEC 15418). The Data used in this document. Identifier always is terminated with an alphabetic characters. These can to provide differentiation with • AMG:The purpose of the German Medicinal Pro- variants have a one, two or three digit prefix. ducts Act (AMG) is to guarantee, in the interest of • Data Matrix Code: Two dimensional Matrix code furnishing both human beings and animals with a which comprises of square elements. In the version proper supply of medicinal products, safety in res- ECC 200 of ISO/IEC 16022 the Code uses an error pect of the trade in medicinal products ensuring in correction for missing spots or damaged places. particular the quality, efficacy and safety of medici- Adjacent code elements of the same colour should nal products in accordance with the AMG contained continue into one another without break. provisions (refer to § 1 AMG). • Data storage medium: The term "Data storage • Application Identifier (AI): By the users of GS1 medium" is a general description for any medium specified numeric Identifier, which are listed in the which can be used to record or store data. Ideally it standard ANSI MH10.8.2 (normative referenz: ISO/ is irrelevant the nature of data which is to be stored. IEC 15418) Data storage media include hard drives, CD-ROM, • BARCODE: Optical data carrier consisting of lines. DVD and USB-Sticks. Further in the area of automa- Colloquially, two dimensional matrix codes are so- tic idenfication, RFID Transponder, OCR fonts, bar- metimes referred to as 2D barcodes. This includes codes und matrix codes are used as data media. the Data Matrix Code. Code rules securPharm: • DFI – Data Format Identifier: Defines the para- Used as short form for the document "Coding rules meters according to the ISO standard. Additionally, for medicines requiring verification for the German sets out the guidelines for the use and form of the market". See http://www.securpharm.de following parts; the envelope data according to ISO/ • Code 39: A bar code type specified in ISO/IEC IEC 15434, the specific application identifier (AI or 16388. The printed space requirements of this code DI), which macro is to be used (ISO/IEC 16022) and is high for a relatively low data volume. the appropriate syntax. Currently, the value for the • Continous Ink-Jet (CIJ): This is a form of inkjet DFI "IFA" or "GS1" are defined. printing. Usually this printing process generates • Dot code: These are two-dimensional codes, dot codes, which are explained in the glossary. The which are typically composed of round, detached printing process creates a constant stream of ink dots. The Data Matrix standard does not specify droplets, which is deflected electrostatically. The a dot code variant. In reality there are many dot solvent evaporates rapidly. Due to the high sol- code data matrix applications. Scanners would vent content, the ink dries and adheres very well be needed which are capable of reading such to all non-porous surfaces. The resolution is low. forms. In the PPN application as an open system, scanners types are not specified. For this reason, the Data Matrix Dotcode variant is not allowed. All contents copyright © IFA GmbH | Information Center for Medicinal Products | English V 2.01 Page 39 • European Medicines Agency (EMA): European • OTC Medicines: Over the counter is a term for non- regulatory agency for medicines for use in the Eu- prescription medicines. According to § 48 AMG me- ropean Union. di- cines are classified as non-prescription, if they • Global Trade Item Number (GTIN): A globally do not endanger the health of user, when used as unique article number for retail use. Typically this intended, even if they are used without medical su- article number is coded in a EAN-13 bar code pervision. Non- prescription medicines are grouped form. Other codings such as Code 128, Data into pharmacy-on- ly and freely-sold medicines. Matrix Code and GS1-Databar are possible. • Pharmaceutical entrepreneur (PU): is, in the The issuing IA is GS1. case of medicines which require authorization or • GS1 – registered Trademark: GS1 is the abbre- registration, the owner (called: "Pharmazeutischer viation for Global Standards One, which is registe- Unternehmer (PU)" in Germany). PU is also whoever red as IA and administrates the global GS1 number introduces in his name medicines into the supply system. chain (§4 Abs. 18 AMG). This means that if the me- • HIBC – Health Industry Bar Code: The HIBC is dicine is brought into the supply chain by another a compressed structure and is mainly used for the party other than the owner then both parties must labelling of medicinal products. The HIBC system be specified in the identification e.g. both as PU or identifier is prefixed with a "+", alphanumeric pro- as "Owner" and "Distributor". This applies when in duct codes of 2 to 18 digits may be used, followed addition to the authorisation/registration owner one by the variable product data (refer to www.hibc.de). or more parties distribute medicines then the latter • IFA: Informationsstelle für Arzneispezialitäten IFA should be identified as "(further) PU" or as "Co-dis- GmbH (www.ifaffm.de). German Information Center tributor". In both legal and the secur- Pharm project for Medicinal Products, agency responsible for issu- terms, all the above named parties are PU and thus ing the PZN and the PRA-Code. responsible for the compliance of the appropriate • IFA Coding System: Specifications issued by the responsibilities where applicable. IFA , in which the rules of the German pharmaceu- • Pharmacy Product Number (PPN): A globally tical market stakeholders are implemented and it‘s unique article number for products in the area of extension covering all common pharmacy products health care in which the national article number is (e.g. food supplements) It includes the identification embedded. It consists of a two-digit prefix (Product of Retail packages and transport units Registration Agency code) followed by the national • Issuing Agency Code (IAC): The registration product number (PZN in Germany) and a two digit code assigned to an approved Issuing Agency(IA) check digit. The national product number is thus by the "Registration Authority for ISO/IEC 15459". converted into a globally unique product number to An Issuing Agency is able to offer its’ participants a be unique in international business transac- tions. system for glo- bally unique identification of objects. The responsible IA is IFA. The NS (Neder- landse Norm) is mandated by the ISO to act as a Regis- tration Authority. • Module size: Specifies the size of a cell in the matrix Data Matrix Code • National Trade Item Number (NTIN): A globally unique article number, in which the national article • Pharmazentralnummer (PZN): German National Number Product number for , pharmaceutical products and pharmacy typical products available. The issuance of the PZN number is regulated by law and under the responsibility of the IFA. Refer to http://www.ifaffm.de/service/_index.html number is embedded through the use of a GS1-pre- • PPN-Code: Describes a Data Matrix ECC 200 code fix. For the PZN, the prefix 4150 has been assigned. according to ISO/IEC 16022 and the data structure The GTIN Data Identifier is the AI "01". and syntax of ISO/IEC 15418/ANSI MH10.8.2 and • Optical readable media (ORM): A generic term ISO/IEC 15434. The leading data element contains for coding, that are captured with optical devices. the code of the PPN "Pharmacy- Product Number" This in- cludes OCR fonts, barcodes and 2D-Codes (PPN) and depending on the application, additional etc. data elements. For medicines requiring verification, All contents copyright © IFA GmbH | Information Center for Medicinal Products | English V 2.01 Page 40 this would be "seri- al number", "batch number" and "expiry date". • Product Registration Agency (PRA): The assigning authority for national product numbers, which in con- junction with the PRA-Code can be converted to PPN. • Product Registration Agency Code (PRACode): Two digit prefix to the unique identifier of a PPN. Assig- ned to and administered by the IFA • Random serial number: Non-deterministically gene- rated serial number • RX-Medicines: Prescription drugs were often referred as RX drugs. • securPharm: An Association founded by the confederation of pharmaceutical manufacturers, pharmacists and wholesalers in order to develop and pilot test a concept for the verification of medicines. • SI – System Identifier: A System Identifier consists of a character or a combination, and refers to the code at the beginning of the data structure used, or syntax. System Identifiers are standardized according to DIN 66401. • Verification: The process of detecting counterfeits or duplicates medicines, by the printing of unique a serial number on packages, is understood here as verifica-tion. In the field of optical codes, the term verification and quality control for the printing of codes is used. In order to achieve clarity of the terms used in the present specification, verification only in the context of fraud detection. The print quality control is always referred to as a bar code or matrix code testing verification (cf. English "bar code verification" within the meaning of the printing quality control). • XML: Extensible Markup Language (XML) is a markup language which defines a set of rules for hierarchical structured data in text form. All contents copyright © IFA GmbH | Information Center for Medicinal Products | English V 2.01 Page 41 Appendix K - Bibliography K.1 Standards: ISO 3951: Sampling procedures and charts for inspection by variables for per cent nonconforming ISO 22742: Packaging - Linear bar code and two-dimensional symbols for product packaging ISO/IEC 10646: Information technology -- Universal Coded Character Set (UCS) ANSI MH10.8.2: Data Identifier and Application Identifier Standard K.2 Further References ISO/IEC 15418: Information technology -- Automatic Handbuch der automatischen Identifikation, Band 2, identification and data capture techniques -- GS1 Ap- ISBN 3-935551-00-2 , Autor Bernhard Lenk plication Identifiers and ASC MH10 Data Identifiers and maintenance Reference to ANSI MH10.8.2 Barcode - Das Profibuch der Lesetechnik, ISBN 3-935551-04-5 ISO/IEC 15415: Information technology -- Automatic identification and data capture techniques -- Bar code Einführung in die Identifikation - Opt. ID / RFID, ISBN print quality test specification -- Two-dimensional sym- 3-935551-03-7 bols K.3 Links ISO/IEC 15434: Information technology -- Automatic identification and data capture techniques -- Syntax for AutoID: http://www.autoid.org high-capacity ADC media Eurodata Council: www.eurodatacouncil.org ISO/IEC 15459-2: Information technology -- Unique identifiers -- Part 2: Registration procedures GS1: http://www.gs1.org ISO/IEC 15459-3: Information technology -- Unique HIBC: http://www.hibc.de identifiers -- Part 3: Common rules for unique identifiers IFA Frankfurt: http://www.ifaffm.de ISO/IEC 16022: Information technology -- Automatic identification and data capture techniques -- Data Mat- SecurPharm: http://www.securpharm.de rix bar code symbology specification ISO/IEC 19762-1: Information technology -- Automatic identification and data capture (AIDC) techniques -- Harmonized vocabulary -- Part 1: General terms relating to AIDC ISO/IEC 19762-2: Information technology -- Automatic identification and data capture (AIDC) techniques -- Harmonized vocabulary -- Part 2: Optically readable media (ORM) ISO 2859-1: Sampling procedures for inspection by attributes Part 1: Sampling plans indexed by acceptable quality level (AQL) for lot-by-lot inspection All contents copyright © IFA GmbH | Information Center for Medicinal Products | English V 2.01 Page 42 Appendix L - Document Maintenance Summary Version Date Type of Change Change 1.0 2012-01-05 First release 1.01 2012-01-23 Layout/Notation Correctionr Document (layout); Chap. 1, App F1.6, F2 (text); Chap. 3.3 (link); App. L (new) 2.00 2013-02-18 IContent, Layout/Notation Correction Complete document: Additions and corrections, taking into account the publication of the Coding rules securPharm, particularly in Chapters 1 and 2. 2.01 2013-06-26 Layout-/Notation Correction Update WEB-Links All contents copyright © IFA GmbH | Information Center for Medicinal Products | English V 2.01 Page 43 Appendix M - Imprint IFA GmbH Informationsstelle für Arzneispezialitäten Hamburger Allee 26 - 28 60486 Frankfurt am Main Postfach 15 02 61 60062 Frankfurt am Main Phone: +49 69 / 97 99 19-0 Fax: +49 69 / 97 99 19-39 E-Mail: [email protected] Internet: www.ifaffm.de The content has been created with great care. If you discover errors or omissions then please let us know. Remark on the preparation of this specification: The Working Group (WG) "Coding" of the securPharm Projects has prepared this specification up to Version 1.02. In addition to the members of the WG Coding other professionals have provided occasional assistance in the preparation of the above documentation. The participants were (in alphabetical name order: • Klaus Appel, Informationsstelle für Arzneispezialitäten (IFA), (Information Center for Medicinal Products) Frankfurt/Main * • Dr. Ehrhard Anhalt, Bundesverband der Arzneimittel-Hersteller (BAH), (German Medicines Manufacturers` Association), Bonn * • Thomas Brückner, Bundesverband der Pharmazeutischen Industrie (BPI), (German Pharmaceutical Industry Association), Berlin • Dr. Stefan Gimmel, Stada Arzneimittel AG, Bad Vilbel • Dr. Clemens Haas, Fresenius Kabi Deutschland GmbH, Oberursel • Gerhard Haas, ABDATA Pharma-Daten-Service, Eschborn • Stefan Lustig, Boehringer Ingelheim Pharma GmbH & Co. KG, Ingelheim • Heinrich Oehlmann, Eurodata Council, Naumburg/The Hague * • Helmut Reichert, ABDATA Pharma-Daten-Service, Eschborn • Dr. Joachim Reineck, Merz Group Services GmbH, Reinheim • Kay Reinhardt, Salutas Pharma GmbH, Barleben • Christian Riediger, Bayer Health Care, Berlin • Paul Rupp, (Leader of the working group) formerly Sanofi-Aventis, Schwalbach * • Dr. Stephan Schwarze, Bayer Health Care, Berlin • Wilfried Weigelt, Member of DIN standards committee NIA-01-31 * The persons identified with * made significant contribution to version 2.00. All contents copyright © IFA GmbH | Information Center for Medicinal Products | English V 2.01 Page 44