IFA Coding System PPN-Code Specification for - · PDF fileIFA Coding System PPN-Code...

IFA Coding System PPN-Code Specification for Retail Packaging

Version: 2.01 Date of issue: 2013-06-26

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

Page 2All contents copyright © IFA GmbH | Information Center for Medicinal Products | English V 2.01

Table of Content

1 Foreword and Introduction 4

2 Scope 4

3 Coding agreements 5

3.1 General 53.2 Pharmacy Product Number (PPN) – use in Germany 53.3 Further global uses of the PPN 63.4 Codes und data content of retail packages 63.5 Multi Country Packs 7

4 Data content and requirements 7

4.1 Data structure 74.2 Data Identifiers and data 8

5 Marking with code and clear text 10

5.1 Symbology 105.2 Matrix size 115.3 Code size and quiet zone 115.4 Positioning of the Data Matrix Code 115.5 Emblem Data Matrix Code 125.6 Clear Text information 125.7 Code examples 125.8 Print quality 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 148.2 Interoperability based on XML-Standards 15


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.1 General 19D.2 Data Format Identifier (DFI) 19D.3 XML-Node for Data 19D.4 Implementation 20D.5 Examples 21

Appendix E - Quality and control of the code content 22

E.1 Data Matrix Code as dot code 22E.2 Qualification and validation measures 22E.3 Checking codes for data content and print quality 22E.4 Printing variants 23E.5 Quality control statistics 23E.6 Testing equipment 24E.7 Colours and materials 25E.8 Quality criteria in accordance with ISO/IEC 15415 and ISO/IEC 16022 25

Appendix F - Common problems 26

F.1 Faults in the data structures 26F.2 Data content errors 29F.3 Printing errors 30F.4 Material related errors 34

Appendix G - Layout –Best Practice 35

Appendix H - Bubble-Jet – Best Practice 35

Appendix I - Data Matrix Code –Symbology description 36

I.1 Module sizes 36I.2 Matrix size 36I.3 Fixed pattern 37I.4 Data area 37I.5 Pad characters 37I.6 Error correction 38

Appendix J - Glossary 39

Appendix K - Bibliography 42

K.1 Standards: 42K.2 Further References 42K.3 Links 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 4

1 Foreword and Introduction

As part of the "securPharm" project framework, to

develop and pilot a system to implement the require-

ments of the European Directive 2011/62/EU to pro-

tect against counterfeiting of drugs, for the German

associations of pharmaceutical manufacturers,

wholesalers and pharmacists (Stakeholders) the

need arose, to transform the German reimbursement

number (PZN), as defined in social legislation, into a

globally unique product number.

In this context, the "Informationsstelle für Arzneispezia-

litäten GmbH (IFA)" [http://www.ifaffm.de] (German

Information Center for Medicinal Products), which

manages the allocation of PZN, has acquired the status

of an Issuing Agency and has created a coding system

(IFA Coding System).

While securPharm system focused on drug packaging

to meet the specific legislative requirements, IFA

Coding System extended the securPharm system firstly

to cover all common pharmacy products (eg food

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

Industry Association)

• Bundesverband des Pharmazeutischen

Großhandels – PHAGRO e.V. (Association

of Pharmaceutical Wholesalers)

• Pro Generika e.V. (Association of Generic

Medical Manufacturers)

• Verband Forschender Arzneimittelhersteller

e.V. (vfa) (Association of Research-Based

Pharmaceutical Companies)

Figure 1 shows a typical packing hierarchy from a single

component (e.g. a blister pack or a bottle) through to a

transport pallet. For the stages of retail packaging and

transport units, IFA has corresponding coding specifi-

cations, referred to as the IFA Coding System.

2 Scope

This document is the specification for the identification

of retail packages (see arrow in Figure 1).

Figure 1: Packing hierarchy

(as in ISO/DTS 16791-2012)

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

http://http://www.ifa-coding-system.org/en/home

http://www.ifaffm.de/mandanten/1/documents/04_ifa_coding_system/IFA_Spec_Transport_Logistik_EN.pdf

http://www.ifaffm.de/mandanten/1/documents/04_ifa_coding_system/IFA_Spec_Transport_Logistik_EN.pdf


This specification which is based on the rules "Coding

rules for medicines requiring verification for the German

market to protect against counterfeiting of medicinal

products (Coding rules securPharm)", issued by secur-

Pharm e.V describes in particular the conversion of the

PZN into a globally unique "Pharmacy Product Number

(PPN )". Further details are to be found in Chapter 3.2.

An essential component of this specification is the

description of the Data Matrix Code, which holds the

necessary data elements for automatic identification.

Based on the PPN, as product number, it describes

the coding and the associated marking of medicinal

product packages,the data structures and the forms of

data elements as well as the coding with code size and

print quality.

All essential and mandatory coding components have

been adopted from the "Coding rules securPharm" into

this specification. However, in regard to the generation

of serial numbers, refer to Chapter 3.1 of the above

mentioned rules.

Thus by using this specification it is ensured that all

the guidelines of securPharm are covered.

In addition this specification covers the detailed

description of typical faults or problems (refer to

Appendix F).

3 Coding agreements

3.1 General

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

Code (SGB V).

Additionally the German pharmaceutical market stake-

holders 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

The "Coding rules securPharm" provide for the

coding in Data Matrix Code as per ISO/ IEC 16022

(refer to Chapter 5.1) of this specification and the data

structure and syntax according to ISO/IEC 15418 and

ISO/IEC 15434 (refer to Chapter 4). In this way, the

machine readability of the data elementsis assured

and the technical prerequisite for the implementation

of the EU directive for protection against counterfeit

medicines and also the anticipated additional require-

ments for verification of medicinal product packages.

This code is referred to in its totality as PPN-Code.

3.2 Pharmacy Product Number (PPN) – use in Germany

Many processes e.g. reimbursement system and

medicinal product identification are dependent on the

PZN product number. However to provide verification in

terms of the EU directive it is necessary to use a unique

pan-European product number. To fulfil this require-

ment the Pharmacy-Product-Number (PPN) has been

created. The Data Identifier "9N" was assigned uniquely

to the PPN.

The PZN is converted into the globally unique PPN as

illustrated below:

Pharmacy Product Number (PPN)

11 12345678 42

Product Registration PZN Check-Digits PPN Agency Code for PZN

Figure 2: PPN generation


The PPN consists of three parts which are identified

here with the colours red, blue and green. The 11 (in red)

is a "Product Registration Agency Code" (PRA-Code or

PRAC). This code is administered and assigned by the

IFA. The 11 is reserved for the PZN. Following the 11,

(in blue), is the national product number, this being the

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,

as shown in the example, the result is the value "42".

In the PPN, the PRA-Code, PZN and PPN-check digits

are used without separators. By use of embedded PZN

with the PPN Data Identifier "9N" and PRA-Code "11",

the PPN is unique and the hyphen is not required as an

indicator.

Existing data base and software systems can use an

algorithm to create the PPN from the PZN and vice

versa. Databases can thus continue to work with the

PZN. Alternatively translation tables can easily be

created. As an IFA service, the PPN will be provided as

a supplementary attribute to the PZN.

The interoperability with other number systems, e.g.

GTIN (GS1 as responsible IA) or HIBC (EHIBCC as

responsible IA), is safeguarded by the common use of

international standards.

The use of the PPN is licence-free.

3.3 Further global uses of the PPN

With the provisions of the PPN other healthcare parti-

cipants can uniquely map their national or proprietary

number systems to a globally unique numbering system,

e.g. the Eurocode IBLS of Blood banks, Austria-system

(PZN), Belgian system (CNK-number), Greece system

(EOF-number), Italy system (AIC-number), etc. The IFA

as Issuing Agency ensures with the assignment and

registration of the PRA-Code the conflict-free correlation

of the PPN. Additional information can be accessed

under the following link www.ifa-coding-system.org.

Applications in connection with the PPN are described

in Chapter 3.4

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)

Symbology: Code 39PPN-Code 2)

Symbology: Data Matrix Code

PZN PPN SN LOT EXP GTIN

Medicinal products requiring verification

√ √ √ √ √ optional 3)

Medicinal products – not requiring verification

√ √ optional optional optional optional 3)

Other common pharmacy products √ √ 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.

http://http://www.ifa-coding-system.org/en/home

www.ifa-coding-system.org.


3.5 Multi Country Packs

Multi Country Packs are retail packages, which are

available for dispensing in a number of countries. These

packages have in the "Blue Box" several national

product numbers for reimbursement needs, logistical

requirements and various country-specific information.

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

countries, requiring verification should be con-

tained within the PPN-Code. The one serial num-

ber contained within the Code should correspond

during verification with the product number of the

respective country.

Further details of the Data content are in Chapter 4.2.8

and the "Clear text" information in Chapter 5.6.

Figure 4: Multi Country Pack

4 Data content and requirements

4.1 Data structureIn order that data elements in a data string should be un-

ambiguously identified, they are embedded in accordance

with the syntax of ISO/IEC 15434 (refer to Figure 5).

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

Message Header

Message E

nvelope

[ ) > RS

Envelope Form

at

Format Header

Format Trailer

Formatted Data

RS

Envelope Form

at

Format Header

Format Trailer

Formatted Data

RS

Message Trailer EOT

Figure 5: Envelope structure as in ISO/IEC 15434

In the application described here, data element grouping

is not required so that all data is embedded in one

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 HEX Purpose

[ 91 5B Message Header

) 41 29 Message Header

> 62 3E Message Header

RS 30 1E Record Separator

GS 29 1D Field Separator

EOT 04 04 Message Trailer

Figure 6: ISO/IEC 15434 Character set Envelope

control characters


Data string

Inter- pretation

Code content

Messageheader [)>RSCodeword 237

Formatheader 06 GS

Data Field 1 DI 9N

Data Field 1 Content 111234567842

Field-Separator GS

Data Field 2 DI 1T


Field-Separator GS

Data Field 2 DI D


Field-Separator GS

Data Field 4 DI S


Field-Separator GS (optional)

Formattrailer RS

Messagetrailer EOT

Figure 7: Example of a complete data string with data

elements PPN, batch number, expiry date and serial

number

The order of the data elements (fields) is not defined.

Apart from the usual data elements, additional elements

may be used if necessary. Details are provided in the

following chapters.

4.1.1 Message Header

Data Matrix Code according to ISO/IEC 16022 "ASCII

encodation" provides a means of abbreviating the header

and trailer in one Macro codeword "237" der Header

"[)> RS 06 GS" as is shown and interpreted in Figure 7

and following table:

Macro- Codeword Name Interpretation

HeaderInterpretationTrailer

237 06 Macro [)>RS06GS RS EOT

4.1.2 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.

4.1.3 Message Trailer

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.

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

Identifier). In this application, only the ASC Data Identifier

(DI) is used in accordance with this standard, the form is

defined in the following chapters. For a better overview

this information is shown in table form in Appendix A.

Although the standards may leave room for specific

characteristics of the data elements, this specification,

which is binding for all parties, defines the data type,

data length and character sets (refer to Appendix A).

If additional DI are required, a request should be made

to IFA.

Data Identifiers that are not in this specification, which

however use the syntax of the MH10.8.2, should be

correctly applied and thus lead to defined states. The

data acquisition and verification processes may not be

compromised. The specified data structures may not be

corrupted through any such extensions. The Data Identi-

fier as set out in ANSI MH10.8.2 is strictly alphanumeric.

The Data Identifier always terminates with an alphabetic

character which may be prefixed with a number.

Approved data types, character sets and string length

etc., of the data to be encoded are presented in

Appendix A.


4.2.2 Product number

Data Identifier: "9N"

For product identification, the Pharmacy Product

Number is used. All further data elements in the data

string correspond to the PPN. The PZN is contained in the

PPN and can be extracted from it (refer to Chapter 3.2).

The expanded 8 digit PZN (PZN8) must be used. This

yields a 12 digit PPN.

The Product number is available for use with other

national number systems and for this reason has been

defined in the ANSI MH10.8.2 as a 22 character alpha-

numeric string.

Example:

DI Data9N 110375286414

4.2.3 Batch number

Data Identifier: "1T"

The batch number is generated by the pharmaceutical

entrepreneur and forms therefore the relevant data

element for the code.

To demarcate batch parts special defined characters

can be used (refer to Appendix A).

Example:

DI Data

1T 12345ABCD

4.2.4 Expiry date

Data Identifier: "D"

The expiry date is generated by the pharmaceutical


element for the code.

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).

MM = 2 digit Month (01-12))

DD = Day

a) Expiry date with day, month and year (DD = 01-31)

b) Expiry date with month and year (DD = 00)

Example: Expiry date June 2016

DI Data

D 160600

This example represents the date as required by Ger-

man Drug Law.

Example: Expiry date 17 June 2016

DI DataD 160617

This example shows the precise expiry date.

Note: : In the ANSI MH.10.8.2 standard "D" is defined as

a general date. In the context of PPN, "D" is only to be

used for the product expiry date. Other dates like e.g.

production dates must use other Data Identifiers (see

Chapter 4.2.6).

4.2.5 Serial number

Data Identifier: "S"

The serial number is generated by the pharmaceutical


element for the code. It is mandatory for the medicinal

product verification process. For products, where

verification is not mandated, it is optional. With regard

to the generation of serial numbers refer to "Coding

rules securPharm ".


Example:

DI Data

S 12345ABCDEF98765

The usable characters are described in Appendix A.

4.2.6 Date of manufacture

Data Identifier: "16D"

The date of manufacture is generated by the pharma-

ceutical entrepreneur and forms therefore the relevant

data element for the code.

It can be used for internal purposes or when agree-

ments between market partners require it.

Date of manufacture has the format "YYYYMMDD"

YYYY = 4 digit year

MM = 2 digit month (01-12)

DD = Day

a) Manufacture date with day, month and year

(DD = 01-31)

b) Manufacture date with month and year

(DD = 00)

Example: Date of manufacture March 2012

DI Data16D 20120300

Example:Date of manufacture 15 March 2012

DI Data16D 20120315

4.2.7 GTIN

Data Identifier: "8P"

The manufacturer generates a GTIN following the GS1

rules. It is to be used for products where, in addition to

the PPN a GTIN is given, e.g. for dietary supplements.

Example: GTIN with the number 01234567891234

DI Data8P 01234567891234

4.2.8 Product numbers for Multi Country Packs

The special characteristic of Multi Country Packs is the

use of multiple, country specific product numbers. The

relevant number for the country must be recognised by

the commercial systems and at the dispensing point.

Depending on whether the product number is a PPN

or a GTIN/NTIN, either the Data Identifier "9N" or "8P"

should be used, possibly more than once.

Example:

PPN with the number 110375286414 and

GTIN with the number 01234567891231 and

NTIN with the number 03400123456789

DI Data

9N 110375286414

8P 01234567891234

8P 03400123456789

All other data elements can be added without restric-

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.

The data medium or the symbology is Data Matrix

in accordance with ISO/IEC 16022. Error correction

adheres to ECC 220. Other error correction methods

(ECC000 to EC140) are not allowed. The characteristics

of the Data Matrix Code are described separately

(refer to Appendix I). If a consistent matrix size is required

then padding characters should be used as necessary

(refer to Appendix I.5).


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 Dimension (mm) Data capacityRows Columns Typical

X = 0,35

Min

X = 0,25

Max

X = 0,615

Numeric Alphanumeric

22 22 7,7 5,5 13,5 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

The code module size may vary between 0.25 and 0.615

mm. With due attention to the printing quality (refer

to Chapter 5.8) and printing system (refer to Chapter 6),

the module size may be freely set within this size range.

Module size means the dimensions of a matrix cell

(refer to Chapter 5.2 and Appendix I.1). Typical module

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.

5.4 Positioning of the Data Matrix Code

There are no specific rules concerning the code

positioning. The manufacturer may decide the best

positioning based on the packaging layout and the

printing conditions (refer to Appendix G).

For EMA approvals, the code should be printed outside

the "Blue Box".


5.5 Emblem Data Matrix Code

The emblem "PPN" on the Data Matrix Code, indicates

to the retailer the Code, which is to be used for the

automatic identification of the product number and

further data. For products requiring verification, thisis

also the indicator for identification and verification of the

retail package.

Figure 8:Code Emblem

There are several different possible versions for the

graphical representation of the PPN-Emblem (refer to

Appendix C). It is possible to apply the emblem either

during initial printing or inline.

The minimum distance must be maintained (quiet zone).

During a transition phase the emblem may be omitted,

giving the pharmaceutical entrepreneur more latitude

during the conversion process.

5.6 Clear Text information

Product number: The PPN, or rather the PZN, is the

key element of the retail packaging. According to the

current applicable statutory rules the PZN must be

applied in text form together with Code 39 (refer to

http://www.pzn8.de/downloads/de/IFA_Spec_PZN_

Codierung_DE.pdf)For this reason, the PPN will not be

printed in text form.

Batch number and expiry date: The clear text for

batch number and expiry date is governed by statutory

regulations.

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

identification technology, which makes the data more

accessible and less prone to error than manual data

entry.

Clear text information on Multi Country Packs:

The country specific product information and together

with product codes should be displayed without altera-

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

In the following examples the sequence is initialised

with Macro 06 (Codeword 237). The data elements are

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,

automatically generates the characters RS and EOT.

The following examples illustrate the possible sizes of

codes depending on the length of the data elements.

The data elements lengths are determined by the

manufacturer, in accordance with the specification

documented in Appendix A.

Example 1

A typical size of a code is a matrix with 26x26 modu-

les. Here the Data Fields have a common length.

Code Content:

DI Data Field

9N 110375286414

1T 12345ABCD

D 150600

S 12345ABCDEF98765

Example 2

The smallest size of code has a matrix with 22x22

modules. The Data Fields have a very short length:

http://www.pzn8.de/downloads/de/IFA_Spec_PZN_Codierung_DE.pdf



Code Content:

DI Data Field

9N 110375286414

1T 1ABCDE

D 150600

S 1ABCDEF

In this variant, with a matrix of 22x22 modules, the batch

and serial number can each only have a maximum of

7 characters.

Example 3

If the data element capacity is used to the limit, then a

matrix of 32x32 modules will be required:

Code Content:

DI Data Field

9N 110375286414

1T 1A2B3C4D5E6F7G8H9I0J

D 150600

S A1B2C3D4E5F6G7H8I9J0

Example 4

This code has a rectangular format with a matrix of

16x48 modules. The data fields are identical with those

in example 1.

Code Content:

DI Data Field

9N 110375286414

1T 12345ABCD

D 150600

S 12345ABCDEF98765

5.8 Print quality

Code content testing (scan test) is fundamentally

different from print quality testing.

The basic requirement of a useful code is that it can

be read and that the content corresponds to the

established rules. The practical readability depends

on the scanner being used and the environmental

conditions.To ensure a general readability of the code,

a standardized print quality minimum is defined.

With digital printing, each print is individual and for

this reason each code has to be scanned to check the

contents (refer to Appendix E.3).

The current standard for determining print quality is

set out in ISO/IEC 15415. A red light of wave length 660

nm (+/10 nm) is used. The synthetic aperture is 80% of

the module size as defined in above standard.

Alternatively, it is possible to determine print quality

with the built-in, ISO/IEC 15415 compliant testing

capabilities of the data collection system being

employed.

The print quality is graded either numerically from

grade 4 (best) to grade 0 (worst) or alphabetically

from A (best quality) to F (worst quality) (refer to table

below).

Quality grades ISO/IEC 15415

ISO/IEC-Grades

ANSI-level

With repea-ted testing

Meaning

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


The print quality grade may not be less than 0.5

grade (adequate) in accordance with ISO/IEC 15415.

In order to ensure readability at the end of the

supply chain (and possibly during), a print quality

grade of 1.5 (satisfactory) or better should be

targeted.

The minimum print quality requirement is generally only

valid according to standard statistical quality control

methods. (refer to Appendix E.5).

Further details concerning print quality and test equip-

ment are described in the Appendix E

6 Printing systems

The printing systems must be capable of printing the

defined codes in the minimum print quality (refer to

Chapter 5.8). Printing systems can be tested according

to the international ISO/IEC 15419.

Common printing errors along with data structure and

content are described in Appendix F.

7 Scanning technology

The Data Matrix Code is read with standard commercial

scanners. The optical properties with respect to mini-

mum reading distance, depth of field and resolution

should be chosen to achieve a high accurate firstread

rate.

The code properties described in this specification, in

terms of various module sizes and matrix sizes are the

minimum requirements for the scanner. Above all, the

application determines necessary speed and depth of

field. Scanners can be tested according to International

standard ISO/IEC 15423.

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).

The probability that codes are read with wrong data

content is low but can not be completely excluded.

Technical improvements in scanners do not necessarily

improve the results.

An optimal system uses fault-tolerant scanners and

codes of good print quality, to minimize the likelihood

of successful misreads

8 Interoperability with different data structures and Identifiers

8.1 Interoperability based on existing Auto-ID

For manufacturers, wholesalers, pharmacies, clinics

and care centers, the interoperability of codes is a

prerequisite for reliable reading and unequivocal

identification of data elements. Integrated interopera-

bility helps to ensure cost-effective processes for the

involved parties.

The common basis for this is the standard ISO/IEC

15459 Unique identifiers, the system standard and

identifier standard ISO/IEC 15418 (ANSI MH10.8.2) and

the syntax standard ISO/IEC 15434.

With due regard to the standards, data from variou da-

ta sources, different symbologies and indentification

systems are transferred without conflict, as shown in

Figure 7.

The following established systems are used in the area

of health care, which can be used concurrently, without

conflict, with the data identification as set out in this

specification.


GS1

The GS1 system is based on the product item

identification using GTIN. For special solutions, the

GS1 has assigned a prefix for a so-called NTIN, which

in technical terms is equivalent to an article number of

GTIN. Important features are, according to DIN 66403,

the use of the control code "FNC1" and the use of

Application Identifier (AI). The interoperability of

Application Identifier (AI) and Data Identifier (DI) is

ensured by the reference tables of ISO/IEC 15418 (ANSI

MH10.8.2). The envelope format of ISO/IEC 15434 is not

used in the GS1 System.

HIBC

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

from all other systems. The defining characteristic of

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).

8.2 Interoperability based on XML-Standards

In Appendix D, a standard is described, which should

be used, based on XML standards and which provides

a neutral description of the Data Identifiers. This allows

for the open exchange of data as illustrated in Figure 9,

regardless of symbology and data structures.

<PPN> 11012…

<GTIN> 012345..

<SN> 12334….

<LOT> 12ABC..

<EXP> 151231

<PZN> 01234567

….

….

….

Figure 9: XML-based Data Exchange between

scanner and system

http://www.hibc.de


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 length

Character subset

Pharmacy Product Number

<PPN> 9N AN --- 4-22 0-9; A-ZNo special charactersNo lower case charactersNo diacritics

Batch number <LOT> 1T AN --- 1-20 0-9; A-Z;Allowed specialcharacters "-" and " _ "No lower case charactersNo diacritics

Expiry Date <EXP> D Date YYMMDD 6 0-9

Serial number <SN> S AN --- 1-20 0-9; A-ZNo special charactersNo lower case charactersNo 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 lower-

case 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.


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 Re-

gistration 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 PZN check digit

PPNcheck digit

PPN 1 1 0 3 7 5 2 8 6 4 1 4

ASCIIValue

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

Sum 3409 / 97 = 35 Rest 14The 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.



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:

dc

fe

a

b

Nominal dimensions:

a: results from the chosen module and matrix sizes

b: for a square code a = b; for rectangular – depends

on chosen module and matrix sizes

c: 0,4 * 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

*) 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.


Appendix D - (informative) Interope-rability based on XML-descriptors

D.1 General

For manufacturers, wholesalers, pharmacies and

clinics, the interoperability of coding is a prerequisi-

te for reading and unequivocal identification of data

elements. Integrated interoperability helps to ensure

cost-effective processes for the involved parties. The

interoperability is based on the joint use of the IEC

standards 15434 Syntax for High Capacity Media, ISO/

IEC 15459 Unique identifier, as well as System and Da-

ta Identifiers according to ISO/IEC ISO/IEC 15418.

In order to provide manufacturers and users in

the pharmaceutical field an even greater intero-

perability, in this Appendix, an XML-based stan-

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

reader to the connected systems.

The Standard set out in this appendix applies only to

the data contents, i.e. it does not refer to the layout

properties of the code, which include the provisions of

the clear text printing and symbology (eg, Data Matrix

Code). During data transmission and in accordance

with this standard, the data will be uniformly named

using XML nodes independent of the Data Identifiers

used in the code. Following layers are formed in the

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

D.2 Data Format Identifier (DFI)

By the transmission of XML-Standard data elements,

the properties for the display of the data in the Data

Matrix Code are assigned to the Data Format Identifier

(DFI) and only this is transferred.

The DFI tells us which data envelope according to ISO/

IEC 15434, which Application Identifier (AI or DI) and-

whether a macro according to ISO/IEC 16022 is used.

The DFI instructions can be found in Table 1.

XML-Data Format Identifier (DFI)

Format-ID

nach ISO/IEC

15434

Data-Typ- Identifier

nach ISO/ IEC

16022

Data Identifier/Application Identifier nach ISO/IEC

15418

IFA 06 Macro 06 DI-ASC

GS1 ------ FNC1 AI-GS1

Table 1: Data Format Identifier

The DFI can have the values "IFA" or "GS1" and is trans-

ferred in the attribute of the higher level XML node

"<Content>".

D.3 XML-Node for Data

The table below shows the XML-Nodes for data and

their mapping to the Data Identifier (DI) und Applica-

tion Identifier (AI):

XML-Knoten

DI (dfi="IFA")

AI (dfi="GS1")

Beschreibung

<PPN> 9N ---- Produktnummer

<GTIN> ---- 01 Produktnummer

<LOT> 1T 10Chargenbezeich-

nung

<EXP> D 17 Verfalldatum

<SN> S 21 Seriennummer

Table 2: XML-Nodes for Data


The complete list of currently defined nodes is shown

in Appendix A. On this technical level of the description

there is no difference between NTIN and GTIN. On this

basis the comprehensive term GTIN is used.

<Content> envelops the XML nodes <Data>

(refer to Appendix D.4 and Appendix D.5).

From the XML-Data and the DFI value contained therein,

the printer derives all necessary information to create

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

transfer to the printer driver, as well as for the data out-

put from the code readers (refer to schematic represen-

tation)

Driver

MES- System

Terminal Printer

Terminal Reader

MES- System U

ser-

/Ap

plic

atio

n-

leve

lS

yste

mle

vel

XML-Node

MH10.8.2-Data- Identifier Application Identifier

Code

Printer Reader

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.

When reading the code, the scanner puts the data

content in the XML structure, by using the corres-

ponding XML nodes. By default, data transmission

from the code reader to the higher systems only

the data is transferred without the "DFI". Output of

"DFI" is optional for cases when e.g. the correct

use of structures within the code is to be checked.

Generic XML description of data transmission to

the printer and from the code reader:

<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>

When transferring from the code reader the value of

"dfi" is optional


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 Data Identifier: DI Data Format Identifier: IFA

System

PPN: 111234567842 Batch: 1A234B5 Expiry Date: 31.12.2015 Serial number: 1234567890123456

Coding: "IFA"

<Content dfi="IFA">

<PPN>111234567842</PPN>

<LOT>1A234B5</LOT>

<EXP>151231</EXP>

<SN>1234567890123456</SN>

</Content>

Data Carrier

Mac069N111234567842Gs

1T1A234B5Gs

D151231Gs

S1234567890123456

Printer

Example 2: Data transfer to printer – GS1-Format

Product number: GTIN Data Identifier: AI Data Format Identifier: GS1

Data Carrier

FNC104150123456782

101A234B5FNC1

17151231

211234567890123456

System

GTIN: 04150123456782 Batch: 1A234B5 Expiry Date: 31.12.2015 Serial number: 1234567890123456

Coding: "GS1"

<Content dfi="GS1">

<GTIN>04150123456782</GTIN>

<LOT>1A234B5</LOT>

<EXP>151231</EXP>

<SN>1234567890123456</SN>

</Content>

Printer

Example 3: Data transfer from scanner – IFA-Format

Product number: PPN Data Identifier: DI Data Format Identifier: IFA

Data Carrier

Mac069N111234567842Gs

1T1A234B5Gs

D151231Gs

S1234567890123456

System

PPN: 1101234567842 Batch: 1A234B5 Expiry Date: 31.12.2015 Serial number: 1234567890123456

Scanner <Content>

<PPN>111234567842</PPN>

<LOT>1A234B5</LOT>

<EXP>151231</EXP>

<SN>1234567890123456</

SN></Content>

Example 4: Data transfer from scanner – GS1-Format

Product number: GTIN Data Identifier: DI Data Format Identifier: GS1

Data Carrier

FNC104150123456782

101A234B5FNC1

1717231

211234567890123456

System

GTIN: 04150123456782 Batch: 1A234B5 Expiry Date: 31.12.2015 Serial number: 1234567890123456

Scanner <Content>

<GTIN>04150123456782<GTIN>

<LOT>1A234B5</LOT>

<EXP>151231</EXP>

<SN>1234567890123456</SN>

</Content>

If you have any questions or suggestions about this appendix, please send them to IFA GmbH.


Appendix E - Quality and control of the code content (informative)

E.1 Data Matrix Code as dot code

In accordance with the minimum requirements for print

quality it is to be noted that codes such as dot code

where the printing quality is tested in accordance with

ISO/IEC TR 29 158 (Direct Part Marking should not be

used. Dot codes are not specified for Data Matrix in the

ISO/IEC 16022. Scanners can often not read dot codes

or read rates are unacceptably low. The only exception

here are dot codes where the individual dots (data cells)

are so wide and that they touch each other so that they

pass the ISO/IEC 15415 test and are generally readable.

E.2 Qualification and validation measures

The equipment for applying and testing of codes is sub-

ject to the general qualification requirements. Likewise

the ancillary processes have to meet the general valida-

tion requirements.

Definition and scope of qualification measures and the

validation process are not part of this specification.

E.3 Checking codes for data content and print quality

E.3.1 General requirements

The location and extent of testing equipment for scan

ability and print quality will depend on whether the pa-

ckaging materials are used pre-printed or in-line.

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

code labels. The achievable print quality of the code

depends on the substrate material and the printing pro-

cess and may therefore be significantly better than the

minimum requirement.

E.3.2 Scan testing

During the scan test, the built-in acquisition system

tests if:

• the code is present,

• the correct symbology was used and

• the content complies with the specifications.

It also ensures that non-existent, non-readable or incor-

rect Codes are rejected.

E.3.3 Print quality testing

The print quality can generally be tested with two diffe-

rent methods:

1. Using measurements according to ISO/IEC 15415

(for details refer to Appendix E.6.1)

2. Using built-acquisition systems (for details refer to

Appendix E.6.2) with the ability to analyze and de-

termine the print quality according to ISO/IEC 15415


E.4 Printing variants

E.4.1 Packaging with pre-printed codes

E.4.1.1 Quality control by the packaging manu-

facturer - assured print quality from the

supplier

The codes are applied by the packaging material sup-

plier. He has to ensure that the codes exist, are reada-

ble, exhibit the correct symbology, contain the defined

content and record the serial numbers. Furthermore,

he shall take the appropriate measures to ensure that

the code content and the the print quality of the printed

codes meet the minimum defined requirements. This is

checked by the pharmaceutical entrepreneur as part of

supplier qualification.

The applied codes are scanned once again during the

medicine packaging process. In these cases, a com-

plete check is carried out at the place of use of the pre-

sence, readability and use of the correct symbol and

correct content. The actual serial number is also captu-

red during this step.

E.4.2 Inline printing of packaging wit-hout pre-printed codes

E.4.2.1 Continuous scanning and spot checks

on print quality

The codes are inline printed on the packaging during

the medicine packaging process. As described in Ap-

pendix E.3.2, through the detection system each code

is subjected to scan testing. Also, the serial number of

each code is recorded. When required, additionally a

testing device should be used to carry out offline quality

control of the printed code in accordance with ISO/IEC

15415, (for details refer to Appendix E.6.1).

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-

pendix E.3.2, through the detection system each indi-

vidual 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 printing quality of each code compliance to ISO/IEC

15415 (for details refer to Appendix E.6.2).

E.5 Quality control statistics

Testing of the print quality, according to to ISO/IEC

15415, must always be performed in the context of a

standardized sampling procedure using generally ac-

cepted statistical rules. Briefly, this means: if one code

should fall below the acceptable level, then within the

production batch more products have to be checked.

If the error in the application of standardized sampling

procedure exceeds the acceptable level, appropriate

corrective action has to be taken.

Sampling procedures in accordance with ISO 2859 and

ISO 3951 should be used. In these standards, a defined

statistical method is described which leads to the as-

sessment of whether a production batch is acceptable

or not. The sampling methodology is designed to intel-

ligently control the time and effort in quality inspection

costs.

The underlying principle of this statistical method is that

a certain level of defects is acceptable.

The inline inspection of the print quality according to

ISO/IEC 15415 (refer to Appendix E.3.3) is considered,

in the context of the sampling procedure, as a very fre-

quent random sampling. The statistical method for in-

telligent control of the quality testing that can also be

used for inline inspection.


E.6 Testing equipment

E.6.1 Testing in compliance to ISO/IEC 15415

The print quality is measured in compliance to ISO/IEC

15415 with measuring devices (verifier). The measu-

ring devices meet the requirements of the international

standard ISO/IEC 15426-2. The most important require-

ments of a measuring device are:

• Calibration has to be traceable back to national-

standards (e.g PTB, NIST).

• The measurement must be performed under

predefined conditions regarding lighting, camera

angle and distance (Template: ISO/IEC 15415

reference design).

• Ambient light may only change the measurements-

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-

racy must be carried out by the user.

• The requirements of the symbology standard with-

respect to the reference decode algorithm must be

maintained, so that different decode algorithms do

not lead to different results.

The measurement is performed offline. Because of

costs, random samples tests are normal. A 100% tes-

ting using this method of measurement is not justifiable.

Reading devices such as commercially available bar-

code scanners may not be subjected to the same re-

strictions 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 diffe-

rent results. This applies even if the same codes are

tested with different verifiers.

E.6.2 Testing based on ISO/IEC 15415

Many acquisition systems for the scan testing (refer to

Appendix E.3.2) have the ability to continually analyze

and test the print quality inline. This is a test, which is

related to ISO/IEC 15415. The method is often used as

an alternative to offline testing (refer to Appendix E.3.3).

These systems use the same criteria for testing the print

quality as defined in the ISO/IEC 15415. However, there

are constraints on the scanner, such as the wavelength

and angle of incidence of the light source or repeated

code testing from various angles, which can not be pro-

vided for because of the integration in the packaging

line.

The test results are related to ISO/IEC 15415. Such re-

sults should be set in correlation to a verifier result (refer

to Appendix E.6.1), within e.g. the qualifying process.

Data capture systems which test according to the ISO/

IEC 15415 method, ensure a complete, 100% inline in-

spection (scan and print quality control) of each code.

There remains a small risk, as the acquisition system

which is primarily designed for best scanning results

e.g. adaptive lighting, auto-focus and auto-zoom lenses

or optimized decoding algorithms. In such conditions,

the data acquisition system, despite comparison with

the test results from ISO/IEC 15415, can sometimes

provide different quality results.


E.7 Colours and materials

Acceptable colours and substrates:

• The print substrate must have a uniform diffusely

reflecting surface. Surfaces that are highly reflective

(metallic, metallic effects), are unsuitable. Rough or

embossed surfaces are also not to be used. The

following colour requirements are based on the as-

sumption that commercial scanners use red light.

• Substrate colour: white, red, yellow or orange (un-

der red light).

• Module or code colour: black, blue or green (dark

under red light).

• Negative Data Matrix symbols, in which the co-

lours of the substrate material and the module or

matrix are reversed, are allowed.

• When using inkjet printing on outer packaging it

may be required to provide a corresponding recess

in the surface coating so that the ink adheres and

dries.

The minimum quality requirement (refer to Chapter 5.8)

determines the minimum contrast and thus the scope-

for coloured codes.

E.8 Quality criteria in accordance with ISO/IEC 15415 and ISO/IEC 16022

Listed below are the most important test parame-

ters from the standard with short description:

Decode – Reference decode and Code internal struc-

ture (Errors Appendix F.1 and Appendix F.1.9 and Ap-

pendix F.2).

Symbol contrast – Contrast between the brightest

and the darkest elements in the complete symbol (Error

refer to Appendix F.1.1).

Modulation (MOD) – refers to the reflectance unifor-

mity of a symbol’s light modules to each other and al-

so the reflectance of the dark modules to each other.

Reflectance margin – similar to Modulation, except that

the code words which were corrected by the Error cor-

rection are set here as Grad 0 (= Fail) in the decision-

matrix.

Reflectance margin – similar to Modulation, except

that the code words which were corrected by the Error

correction are set here as Grad 0 (= Fail) in the decision

matrix.

Contrast Uniformity – MOD values are determined

for all code words. The MOD values are used for de-

termining the modulation and the reflection area. The

contrast uniformity is the worst MOD value (informative).

Errors in Modulation, Reflection area and Contrast Uni-

formity refer to:

Appendix F.3.2.3 and




Appendix F.4.1 and

Appendix F.4.5.

Unused Error Correction (UEC) – the larger the value

the less errors had to be corrected (refer to Appendix

F.3.1.2).

Axial Non-Uniformity (AN) – code has been expan-

ded or compressed in the x or y axes (refer to Appendix

F.3.1.3).

Grid Non-Uniformity (GN) – degree of grid distortion

compared to the ideal grid. Grid non uniformity does

typically not influence axial non uniformity (Appendix

F.3.1.4).

Fixed Pattern Damage (FPD) – All code parts which

do not contain data or error correction values are che-

cked for damage. This means the L pattern for code

orientation recognition, the clock track for grid recon-

struction, and the quiet zone. Contrast non-uniformity

which is in the data area graded as modulation is an

additional aspect if it appears in the fixed pattern (refer

to Appendix F.3.2.1).

Print growth – informative parameter which shows

if black elements have been printed wider or smaller

than intended (refer to Appendix F.3.2.2 und Appendix

F.3.2.3).


Module size – – The size of a single matrix cell of a

complete code is called Module size. The size of the

module will determine the scanner specification in re-

gard to depth of field, resolution and minimum reading

distance (refer to Appendix I.1).

Matrix sizes – The complete Code is composed of

individual matrix cells (= Module) of a set identical mo-

dule size. The international standard ISO/IEC 16022 de-

fines the smallest Matrix size as 10x10 Modules and the

largest matrix size as 144x144. In practical applications

allowed matrix sizes are limited in order to restrict the

relationship of camera resolution to matrix size and to

have enough pixels per module and thus increase scan

reliability (refer to Appendix I.2).

Appendix F - Common problems (informative)

In this Appendix common faults or errors are described,

grouped into errors in data structure, data content and

printing errors.

This summary should help to avoid problems in the ge-

neration of codes and as a guideline in the creation of

software programs to give tips which errors are likely

and thus to help with error handling.

F.1 Faults in the data structures

F.1.1 FNC1 used as the start se-quence instead of Macro 06

Explanation: The PPN data structure does not use

a GS1 "Application Identifiers" (AI), but "Data Identi-

fier" (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


F.1.3 FNC1 as field separator instead of GS (ASCII 29)

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 re-

places the FNC1 character with a GS character. In the

case of the PPN, the GS character must always be en-

coded directly, and a translation is not necessary. Only

after the identification of a code with GS1 data struc-

ture, through reading an FNC1 character a the first po-

sition, translation is carried out.

F.1.4 Missing Macro 06

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

PPN correctly and to allow the further processing to

execute an additional plausibility check and as an expli-

cit way of differentiation to other ISO compliant data

structures.

F.1.5 Mixed Data Identifier (AI and DI)used

Incorrect data identifier for "batch " used. AI "10"

instead of DI "1T"

"Date" with AI "17" instead encoding of DI "D"

The serial number is coded with AI "21" insteadof

DI "S"

The AI "01" (for GS1 GTIN) has been used instea-

dof DI "9N" for the PPN


F.1.6 Incorrect Data Identifier (DI) used

The DI "14D" is used for the expiry date. In the context of

the PPN DI "D" is always used for the expiry date. This is

not a serious error but rather a case which is excluded

by this specification to limit the number of variants and

for instances, where in parallel, French CIP- and PPN-

coding allow the same date format YYMMDD to be

used. (14D has YYYYMMDD)

Here the DI "25P" has been used for the PPN together

with the IAC code PP which is assigned to the IFA. In a

general ISO context this variant is not allowed, because

"25P" requires a company identification code (CIN) after

the IAC Code PP and then a company assigned article

number.

F.1.7 Field separator GS with fixed-length 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 ex-

ception 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 se-

parator GS.

F.1.8 Wrong error correction

In this example, the PPN structure is correct. The code

version is wrong. It should use the data matrix code with

ECC200 Reed Solomon error correction. Here the data

matrix code is used with the error correction ECC040

(CRC error correction). The Data Matrix ISO/IEC 16022

recommends not using this version (method is outda-

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

An increase in the matrix size is always associated with

an increase in the data capacity e.g. from 52 to 64 al-

phanumeric characters. If e.g. 56 characters are nee-

ded, then the matrix size with a capacity of 64 charac-

ters is required. The free capacity of the code is filled

with pad characters.


F.2 Data content errors

F.2.1 PPN check digit error

The PPN definition requires check digits, calculated ac-

cording to Modulo 97, as a terminator in the Data Field

"9N" (refer to Appendix B). In this example, incorrect

check digits have been encoded.

F.2.2 PPN check digit missing

Explanation: The check digit, which is created over the

PRA-Code (11 in the PPN) and the following PZN8 is

missing . Since the Data Field is terminated with the se-

parator GS and the check digit of the PZN8 check digit

is correct, it is easy to recognise this error.

F.2.3 PZN check digit incorrect

The PPN contains a PZN8 number with the identifier

"9N" in an internationally unique data structure. In this

case, the code has a PZN with an incorrectly calculated

check digits and then the PPN check digits calculated,

embedding the error and giving it the appearance of

being correct.

F.2.4 Missing PZN check digit

The check digit is missing from the PZN code. The sub-

sequent PPN check digit has been calculated usingone

digit less.

F.2.5 PRA-Code incorrect / not plausible

The PPN system can be used with a wide variety of ap-

plications. The PPN, in which the PZN8 number is em-

bedded is always marked with the PRA-Code 11 after

DI "9N". Other PRA-Codes are possible but may never

be used to encode a number PZN8.

F.2.6 PRA-Code missing

In this example, the PRA-Code 11 is missing. The PZN8

coding comes directly after the "9N". As it can be assu-

med that the error was made unintentionally, the PPN

check digits are correct based on the existing data con-

tent.

.


F.2.7 Incorrect date

In this example, the month value is not in the range 1 to

12.

F.2.8 PZN7 used

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.

F.2.9 Incorrect conversion of PZN8 to PZN7

In this example, the 0 which should be have been inser-

ted as the first character to the PZN7 has been appen-

ded as the last character.

F.3 Printing errors

The codes in this chapter are to illustrate errors which

can occur while printing. The content has no signifi-

cance and was arbitrarily chosen.

F.3.1 General printing errors

F.3.1.1 Symbol contrast is too low

a) Good symbol contrast

b) Poor symbol contrast because background is

not white

nicht weiß ist

c) Poor symbol contrast because code is gray

instead of black

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 cor-

rectly decoded because the error correction allows the-

correct decoding, despite the error.


F.3.1.3 Axial Nonuniformity (AN)

a) Symbol distorted in Y Axis

b) Symbol distorted in X Axis

F.3.1.4 Grid Nonuniformity (GN)

Here are two examples where the grid inside the sym-

bol has been distorted without changing the outer

square form of the symbol.

F.3.2 Bubble-jet printing

A tiny heating element in the nozzle, vaporises the inkto

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.

F.3.2.2 Excessive ink

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

F.3.2.3 Code too thin

The printer setting is wrong.

F.3.2.4 Irregular code print

The irregular image can have several causes. The nozz-

le plate may be dirty. The gap between the print head

and the substrate is possibly too great. The print head

possibly has a static charge, which attracts a part of the

ink droplet back to the head.


F.3.2.5 Shadows in the code image

The shadows in the print image are caused by a timing

error. The print head has several rows of nozzles where

the timed release of the ink droplets is vital for printing

quality. If the timing of the release of the ink droplets is

incorrect, this leads to the formation of a shadow which

can be seen here to the left of the matrix elements.

Similar effects may appear if the print head is dirty, is

statically charged or is too far from the substrate.

The following example shows quite distinctly the sha-

dows caused by the wrong speed setting

F.3.2.6 Incorrect ink

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-

pear irregular and frayed.

.

F.3.2.7 Printing without speed sensor (Product

speed unknown and variable) (Code-

distorted)

The code is distorted. There may be axial distortion

(code does not appear quadratic). With slippage or

operation without a speed sensor, the individual matrix

columns and rows (depending on the print direction)

can vary widely in their widths. This causes grid dis-

tortion.

F.3.2.8 Printing with ink for highly absorbent

materials on lacquered packaging (or

metal or plastic)

In this case, the ink does not dry fast enough and sme-

ars. To make matters worse, in this example, the part

had a curved surface.

F.3.2.9 Printing on a very strongly absorbing-

surface

There has been here an excessive ink absorption into

the substrate (blotting paper effect). The printing ele-

ments 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.


F.3.3 Continuous inkjet printing (CIJ)

(a continuous stream of ink droplets is electrostatically

deflected)

F.3.3.1 Printing as a dot code

In this case, the individual dots are compressed to-

gether. A print image has been produced that may be

used as a normal printed code rather than as a DPM

code.

F.3.3.2 Distorted

In this code the dots of the matrix are not positioned

correctly. The print head gap to the printed pattern is

too large and / or there is insufficient electrostatic de-

flection of the ink droplets.

If these errors were corrected and the code is no longer

distorted, then the code remains a DPM code because

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

.

F.3.3.3 Direct Laser marking

A powerful laser changes the colour of the labeling ma-

terial or printed ink is removed.

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)

F.3.4 Thermal transfer printing

Heat is transmitted to a ribbon which then transfers

theimage to the product or a label.

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

• Pressure of the printing head (head runner) is too

low

• Heating elements are not working

• Wrinkles in the ribbon

• Ribbon position changes

• Label position changes

• Printing too close to the edge


F.4 Material related errors

F.4.1 Printing on translucent plastic

In this case, a code was printed on a plastic materi-

al. The plastic is translucent. Light penetrates relatively

deeply into the material and then is partially reflected

back. The resulting effect is an apparent formation of

shadows on the edges of print. This is because the lar-

ge unprinted area of the material reflects more light than

in the small unprinted structures.

F.4.2 Opaque white on transparent-plastic film to thin

When a code is printed on a thin film which has been

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.

F.4.3 Print on shiny metallic surface

The reflective metal surface causes an uneven illumina-

tion, depending on the angle of the illumination source

(scanner) to the code. Partial reflections make the dark

parts of the code appear light.

This case is a typical DPM code. This is not approved

for use as an IFA product code, because scanning re-

quires special DOME light (very diffuse, non-directional

lighting, which minimises reflections and angle depen-

dencies).

F.4.4 Code printed on screen printed-substrate

When a code is printed on the raster of a screen-printed

substrate (here black, yellow and blue dots, which ap-

pear 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 remo-

ved by filtering (highly magnified example).


F.4.5 Code covered with a transparent film

If the code is covered by a packaging film, this film

must fit tightly. There may be no air bubbles between

the code and foil. Weld seams, wrinkles and markings

on the film at the code position are not allowed.

Appendix G - Layout –Best Practice

(informative)

These examples show how even on relatively small are-

as the available code and plain text may be printed:

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 over-

lap 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-

se code size settings that can be printed without dis-

tortion. If the recommended size gradation of the code

that is enforced by the printer‘s resolution is not obser-

ved, then printing errors will become worse as the print

resolution is reduced (necessary at higher speeds)


Appendix I - Data Matrix Code –Sym-bology description (informative)

The Data Matrix Code, in the current version ECC200,

can be either square or rectangular.

I.1 Module sizes

Module size means the dimension of a matrix cell of

the complete code. The module size is freely scaleable

within the dimensions described in Chapter 5.2 and de-

termined by the printing and scanning technology used

Examples of identical codes in different module

sizes:

I.2 Matrix size

The matrix size is determined by the number of modu-

les. ISO/IEC 16022 is the minimum size of a matrix of

10x10 square version, modules, and the maximum size

is 144x144 modules.

The rectangular version starts with the matrix size 8x16

and increases to 16x48 modules. In Chapter 5.2, the

PPN matrix sizes are described

Example matrix size 32x32 module:





I.3 Fixed pattern

The Data Matrix Code comprises of fixed pattern andan

area for the code data.

The red marked portion of the fixed pattern is called the

finder pattern "L". This pattern allows the scanner tolo-

cate and orientate the code.

Here the red marked portion of the fixed pattern is

called the clock track. The clock track indicates the ma-

trix of the code.

The red areas of the fixed pattern are only used in code

from a matrix code sizes of 32x32 modules and larger.

The above illustrated L- and clock patterns are repeated

in these codes

The red-marked outline of the code is the lowest per-

missible Quiet Zone width. The width is a matrix row or

column. It is recommended, in practice, to use the treb-

le the width.

I.4 Data area

The red area is for data storage of the data matrix

codes. In this area there are the code words for data

and for error correction. Symbols up to to a matrix size

of 26x26 modules only have one red data segment.

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 suf-

ficient. A 32x32 matrix with 62 codewords must then be

used. The difference between the capacity of 62 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

modules or modules would be sufficient, the excess

code capacity should be filled with padding characters.

If filled with (scanner) readable data, the data

structure is destroyed and the code is unusable.


I.6 Error correction

The error correction of the data matrix codes is defined

in ISO / IEC 16022. The Reed Solomon method is em-

ployed.

It should be noted that the process of error cor-

rection 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 code-

word 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 rela-

tively 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.


Appendix J - Glossary

As a matter of principle, the terms and definitions of ISO

/IEC 19 762 Part 1 and Part 2 apply in this specification.

The following are additional terms and abbreviations

used in this document.

• AMG:The purpose of the German Medicinal Pro-

ducts Act (AMG) is to guarantee, in the interest of

furnishing both human beings and animals with a

proper supply of medicinal products, safety in res-

pect of the trade in medicinal products ensuring in

particular the quality, efficacy and safety of medici-

nal products in accordance with the AMG contained

provisions (refer to § 1 AMG).

• Application Identifier (AI): By the users of GS1

specified numeric Identifier, which are listed in the

standard ANSI MH10.8.2 (normative referenz: ISO/

IEC 15418)

• BARCODE: Optical data carrier consisting of lines.

Colloquially, two dimensional matrix codes are so-

metimes referred to as 2D barcodes. This includes

the Data Matrix Code. Code rules securPharm:

Used as short form for the document "Coding rules

for medicines requiring verification for the German

market". See http://www.securpharm.de

• Code 39: A bar code type specified in ISO/IEC

16388. The printed space requirements of this code

is high for a relatively low data volume.

• Continous Ink-Jet (CIJ): This is a form of inkjet

printing. Usually this printing process generates

dot codes, which are explained in the glossary. The

printing process creates a constant stream of ink

droplets, which is deflected electrostatically. The

solvent evaporates rapidly. Due to the high sol-

vent content, the ink dries and adheres very well

to all non-porous surfaces. The resolution is low.

• Data Identifier (DI): From the "ASC MH 10 Data

Identifier Maintenance Committee" assigned Data

Identifiers, listed in the standard ANSI MH10.8.2

(normative reference: ISO/IEC 15418). The Data

Identifier always is terminated with an alphabetic

characters. These can to provide differentiation with

variants have a one, two or three digit prefix.

• Data Matrix Code: Two dimensional Matrix code

which comprises of square elements. In the version

ECC 200 of ISO/IEC 16022 the Code uses an error

correction for missing spots or damaged places.

Adjacent code elements of the same colour should

continue into one another without break.

• Data storage medium: The term "Data storage

medium" is a general description for any medium

which can be used to record or store data. Ideally it

is irrelevant the nature of data which is to be stored.

Data storage media include hard drives, CD-ROM,

DVD and USB-Sticks. Further in the area of automa-

tic idenfication, RFID Transponder, OCR fonts, bar-

codes und matrix codes are used as data media.

• DFI – Data Format Identifier: Defines the para-

meters according to the ISO standard. Additionally,

sets out the guidelines for the use and form of the

following parts; the envelope data according to ISO/

IEC 15434, the specific application identifier (AI or

DI), which macro is to be used (ISO/IEC 16022) and

the appropriate syntax. Currently, the value for the

DFI "IFA" or "GS1" are defined.

• Dot code: These are two-dimensional codes,

which are typically composed of round, detached

dots. The Data Matrix standard does not specify

a dot code variant. In reality there are many dot

code data matrix applications. Scanners would

be needed which are capable of reading such

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.

http://www.securpharm.de


• European Medicines Agency (EMA): European

regulatory agency for medicines for use in the Eu-

ropean Union.

• Global Trade Item Number (GTIN): A globally

unique article number for retail use. Typically this

article number is coded in a EAN-13 bar code

form. Other codings such as Code 128, Data

Matrix Code and GS1-Databar are possible.

The issuing IA is GS1.

• GS1 – registered Trademark: GS1 is the abbre-

viation for Global Standards One, which is registe-

red as IA and administrates the global GS1 number

system.

• HIBC – Health Industry Bar Code: The HIBC is

a compressed structure and is mainly used for the

labelling of medicinal products. The HIBC system

identifier is prefixed with a "+", alphanumeric pro-

duct codes of 2 to 18 digits may be used, followed

by the variable product data (refer to www.hibc.de).

• IFA: Informationsstelle für Arzneispezialitäten IFA

GmbH (www.ifaffm.de). German Information Center

for Medicinal Products, agency responsible for issu-

ing the PZN and the PRA-Code.

• IFA Coding System: Specifications issued by the

IFA , in which the rules of the German pharmaceu-

tical market stakeholders are implemented and it‘s

extension covering all common pharmacy products

(e.g. food supplements) It includes the identification

of Retail packages and transport units

• Issuing Agency Code (IAC): The registration

code assigned to an approved Issuing Agency(IA)

by the "Registration Authority for ISO/IEC 15459".

An Issuing Agency is able to offer its’ participants a

system for globally unique identification of objects.

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 ma-

trix Data Matrix Code

• National Trade Item Number (NTIN): A globally

unique article number, in which the national article

number is embedded through the use of a GS1-pre-

fix. For the PZN, the prefix 4150 has been assigned.

The GTIN Data Identifier is the AI "01".

• Optical readable media (ORM): A generic term

for coding, that are captured with optical devices.

This includes OCR fonts, barcodes and 2D-Codes

etc.

• OTC Medicines: Over the counter is a term for non-

prescription medicines. According to § 48 AMG me-

di- cines are classified as non-prescription, if they

do not endanger the health of user, when used as

intended, even if they are used without medical su-

pervision. Non- prescription medicines are grouped

into pharmacy-only and freely-sold medicines.

• Pharmaceutical entrepreneur (PU): is, in the

case of medicines which require authorization or

registration, the owner (called: "Pharmazeutischer

Unternehmer (PU)" in Germany). PU is also whoever

introduces in his name medicines into the supply

chain (§4 Abs. 18 AMG). This means that if the me-

dicine is brought into the supply chain by another

party other than the owner then both parties must

be specified in the identification e.g. both as PU or

as "Owner" and "Distributor". This applies when in

addition to the authorisation/registration owner one

or more parties distribute medicines then the latter

should be identified as "(further) PU" or as "Co-dis-

tributor". In both legal and the secur- Pharm project

terms, all the above named parties are PU and thus

responsible for the compliance of the appropriate

responsibilities where applicable.

• Pharmacy Product Number (PPN): A globally

unique article number for products in the area of

health care in which the national article number is

embedded. It consists of a two-digit prefix (Product

Registration Agency code) followed by the national

product number (PZN in Germany) and a two digit

check digit. The national product number is thus

converted into a globally unique product number to

be unique in international business transac- tions.

The responsible IA is IFA.

• Pharmazentralnummer (PZN): German Natio-

nal 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

• PPN-Code: Describes a Data Matrix ECC 200 code

according to ISO/IEC 16022 and the data structure

and syntax of ISO/IEC 15418/ANSI MH10.8.2 and

ISO/IEC 15434. The leading data element contains

the code of the PPN "Pharmacy- Product Number"

(PPN) and depending on the application, additional

data elements. For medicines requiring verification,

http://www.hibc.de

http://www.ifaffm.de

http://www.ifaffm.de/service/_index.html


this would be "serial number", "batch number" and

"expiry date".

• Product Registration Agency (PRA): The assig-

ning authority for national product numbers, which

in con- junction with the PRA-Code can be conver-

ted to PPN.

• Product Registration Agency Code (PRA-

Code): Two digit prefix to the unique identifier of a

PPN. Assig- ned to and administered by the IFA

• Random serial number: Non-deterministically ge-

ne- rated serial number

• RX-Medicines: Prescription drugs were often re-

ferred as RX drugs.

• securPharm: An Association founded by the con-

federation of pharmaceutical manufacturers, phar-

macists and wholesalers in order to develop and

pilot test a concept for the verification of medicines.

• SI – System Identifier: A System Identifier con-

sists 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, verifica-

tion 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 mar-

kup language which defines a set of rules for hierar-

chical structured data in text form.


Appendix K - Bibliography

K.1 Standards:

ISO 22742: Packaging - Linear bar code and two-di-

mensional symbols for product packaging

ANSI MH10.8.2: Data Identifier and Application Iden-

tifier Standard

ISO/IEC 15418: Information technology -- Automatic

identification and data capture techniques -- GS1 Ap-

plication Identifiers and ASC MH10 Data Identifiers and

maintenance Reference to ANSI MH10.8.2


identification and data capture techniques -- Bar code

print quality test specification -- Two-dimensional sym-

bols


identification and data capture techniques -- Syntax for

high-capacity ADC media

ISO/IEC 15459-2: Information technology -- Unique

identifiers -- Part 2: Registration procedures

ISO/IEC 15459-3: Information technology -- Unique

identifiers -- Part 3: Common rules for unique identifiers


identification and data capture techniques -- Data Mat-

rix bar code symbology specification

ISO/IEC 19762-1: Information technology -- Automa-

tic identification and data capture (AIDC) techniques

-- Harmonized vocabulary -- Part 1: General terms re-

lating to AIDC

ISO/IEC 19762-2: Information technology -- Automa-

tic identification and data capture (AIDC) techniques

-- Harmonized vocabulary -- Part 2: Optically readable

media (ORM)

ISO 2859-1: Sampling procedures for inspection by at-

tributes Part 1: Sampling plans indexed by acceptable

quality level (AQL) for lot-by-lot inspection

ISO 3951: Sampling procedures and charts for inspec-

tion by variables for per cent nonconforming

ISO/IEC 10646: Information technology -- Universal

Coded Character Set (UCS)

K.2 Further References

Handbuch der automatischen Identifikation, Band 2,

ISBN 3-935551-00-2 , Autor Bernhard Lenk

Barcode - Das Profibuch der Lesetechnik, ISBN

3-935551-04-5

Einführung in die Identifikation - Opt. ID / RFID, ISBN

3-935551-03-7

K.3 Links

AutoID: http://www.autoid.org

Eurodata Council: www.eurodatacouncil.org

GS1: http://www.gs1.org

HIBC: http://www.hibc.de

IFA Frankfurt: http://www.ifaffm.de

SecurPharm: http://www.securpharm.de

http://www.autoid.org

http://www.eurodatacouncil.org

http://www.gs1.org

http://www.hibc.de


http://www.securpharm.de


Appendix L - Document Maintenance Summary

Version Date Type of Change Change1.0 2012-01-05 First release

1.01 2012-01-23 Layout/Notati-on Correctionr

Document (layout); Chap. 1, App F1.6, F2 (text); Chap. 3.3 (link); App. L (new)

2.00 2013-02-18 IContent, Layout/No-tation 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


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 Pro-

ducts) Frankfurt/Main *

• Dr. Ehrhard Anhalt, Bundesverband der Arzneimittel-Hersteller (BAH), (German Medicines Manufac-

turers̀ 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.


Date post:	30-Jan-2018
Category:	Documents
Upload:	phungthuan
View:	229 times
Download:	3 times

IFA Coding System PPN-Code Specification for - · PDF fileIFA Coding System PPN-Code...

Documents