IFA Coding System PPN-Code Specification for Retail Packaging

Transcription

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
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
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.
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
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
1234567
Field-Separator
GS
Data Field 2 DI
D
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
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.
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
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
element for the code.
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).
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.
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
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
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).
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).
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 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 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.
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.
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.
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
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.
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
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
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
Serial number: 1234567890123456
If you have any questions or suggestions about this appendix, please send them to IFA GmbH.
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.
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.
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.
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.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.
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
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.
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.
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.
.
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.
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.
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.
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
.
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).
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:
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:
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.
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.
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.
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-only 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 globally 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 includes OCR fonts, barcodes and 2D-Codes
(PPN) and depending on the application, additional
etc.
data elements. For medicines requiring verification,
Page 40
this would be "serial 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 generated 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.
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
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
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
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
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
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.
Page 44

IFA Coding System PPN-Code Specification for Retail Packaging

Transcription

Similar documents

Siemens TransformHUV Mexico

PDF

SC 255-96M SC 260-96M SC 265-96M

Components company profile

LMT Brochure - Gichner Shelter Systems

Processing the dots

P15/S1546/FUL - 1 Coopers Close, Littleworth

Certificate of Registration Hoover Precision Products, Inc