ifa coding system spezifikation ppn-code für … · ifa coding system spezifikation ppn-code für...

IFA Coding System Spezifikation PPN-Code für Handelspackungen

Version: 2.01 Ausgabedatum: 26. Juni 2013

Codierung der Verpackungen mittels Data Matrix Code zum Schutz vor Arzneimittelfälschungen

Automatische Identifikation von Handelspackungen im Apothekenbereich

www.ifa-coding-system.com

Seite 2All contents copyright © IFA GmbH | Informationsstelle für Arzneispezialitäten | Deutsch V 2.01

Inhaltsverzeichnis1 Vorwort und Einleitung 4

2 Anwendungsbereich 4

3 Vereinbarungen zur Codierung 5

3.1 Allgemeines 53.2 Pharmacy Product Number (PPN) – Anwendung in Deutschland 53.3 Weitere weltweite Anwendungen der PPN 63.4 Codes und Dateninhalte auf Handelspackungen 63.5 Multi Country Packs 7

4 Dateninhalte und Anforderungen 7

4.1 Datenstruktur 74.2 Datenidentifikatoren und Daten 8

5 Beschriftung mit Code und Klartext 10

5.1 Symbologie 105.2 Matrixgröße 115.3 Codegröße und Ruhezone 115.4 Positionierung des Data Matrix Codes 115.5 Emblem zum Data Matrix Code 125.6 Klartextinformation 125.7 Codebeispiele 125.8 Druckqualität 13

6 Drucksysteme 14

7 Lesetechnik 14

8 Interoperabilität bei unterschiedlichen Datenstrukturen und Datenidentifikatoren 14

8.1 Interoperabilität auf Basis bestehender Auto-ID 148.2 Interoperabilität auf Basis von XML-Standards 15


Anhang A Übersicht Datenelemente und Data Identifier 16

Anhang B Algorithmus zur Prüfzifferberechnung der PPN 17

Anhang C Emblem zum Code 18

Anhang D Interoperabilität auf der Basis von XMLBeschreibungen 19

D.1 Allgemeines 19D.2 Data Format Identifier (DFI) 19D.3 XML-Knoten für Daten 19D.4 Anwendung 20D.5 Beispiele 21

Anhang E Qualität und Kontrolle des Codeinhalts 22

E.1 Data Matrix Code als Punktcodes 22E.2 Qualifizierungs-und Validierungsmaßnahmen 22E.3 Kontrolle der Codes auf Dateninhalt und Druckqualität 22E.4 Varianten der Bedruckung 23E.5 Statistik in der Qualitätskontrolle 23E.6 Prüfgeräte 24E.7 Farben und Materialien 25E.8 Qualitätskriterien nach ISO/IEC 15415 mit Bezug auf ISO/IEC 16022 25

Anhang F Typische Fehler 26

F.1 Fehler in den Datenstrukturen 26F.2 Fehler in den Dateninhalten 29F.3 Fehler im Druck 30F.4 Materialbedingte Fehler 34

Anhang G Layout – Best Practice 35

Anhang H Bubble-Jet – Best Practice 35

Anhang I Data Matrix Code – Symbologiebeschreibung 36

I.1 Modulgrößen 36I.2 Matrixgröße 36I.3 Feste Muster 37I.4 Datenbereich 37I.5 Füllzeichen 37I.6 Fehlerkorrektur 38

Anhang J Glossar 39

Anhang K Bibliography 42

K.1 Normen: 42K.2 Weiterführende Literatur 42K.3 Links 42

Anhang L Dokumenthistorie 43

Anhang M Impressum 44

All contents copyright © IFA GmbH | Informationsstelle für Arzneispezialitäten | Deutsch V 2.01 Seite 4

1 Vorwort und Einleitung

Im Rahmen des Projekts „securPharm“, bei dem die

deutschen Verbände der Arzneimittelhersteller, des

Großhandels und der Apotheker (Stakeholder) ein Sys-

tem zur Umsetzung der Vorgaben aus der europäischen

Richtlinie 2011/62/EU zur Abwehr von Arzneimittelfäl-

schungen entwickelt haben und in einem Feldversuch

testen, entstand die Notwendigkeit, die sozialrechtlich

für jedes Arzneimittel geforderte Pharmazentralnum-

mer (PZN) in eine weltweit eindeutige Produktnummer

zu transformieren.

In diesem Zusammenhang hat die Informationsstelle

für Arzneispezialitäten GmbH (IFA) [http://www.ifaffm.

de], die die Vergabe der PZN verwaltet, den Status ei-

ner Issuing Agency erworben und ein Coding-System

geschaffen (IFA Coding System).

Während das securPharm-System auf die Arzneimittel-

verpackung zur Erfüllung der entsprechenden rechtli-

chen Anforderungen fokussiert, erweitert das IFA Co-

ding System das securPharm-System zum einen auf

alle apothekenüblichen Waren (z.B. auf Nahrungser-

gänzungsmittel). Zum anderen deckt es die Kennzeich-

nung von

- Handelspackungen und

- Transporteinheiten

ab.

Die vorliegende Spezifikation ist im Auftrag der die IFA

repräsentierenden Verbände erstellt worden:

• ABDA - Bundesvereinigung Deutscher Apo-

theker-verbände (German Federal Association of

Pharmacists)

• Bundesverband der Arzneimittel-Hersteller

e.V. (BAH) (German Medicines Manufacturers̀

Association)

• Bundesverband der Pharmazeutischen Indus-

trie e.V. (BPI) (German Pharmaceutical Industry

Association)

• Bundesverband des Pharmazeutischen Groß-

handels – PHAGRO e.V. (Association of Phar-

maceutical Wholesalers)

• Pro Generika e.V. (Association of Generic Medi-

cal Manufacturers)

• Verband Forschender Arzneimittelhersteller

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

maceutical Companies)

Abb. 1 veranschaulicht eine typische Verpackungskas-

kade, beginnend mit der Einzelkomponente (z.B. ein

Durchdrückblister oder eine Flasche) bis hin zur Trans-

portpalette. Für die beiden Stufen Handelspackungen

und Transporteinheiten existieren bei der IFA entspre-

chende Codierspezifikationen, die als IFA-Coding Sys-

tem bezeichnet werden.

2 Anwendungsbereich

Das vorliegende Dokument ist die Spezifikation für die

Kennzeichnung der Handelspackungen (s. Pfeil in Abb. 1).

Abbildung 1: Verpackungskaskade

(Bildquelle: Nach ISO / DTS 16791)

Die Spezifikationen zu den Transporteinheiten sind über

www.ifa-coding-system.org oder auch direkt unter:

http://www.ifaffm.de/mandanten/1/documents/04_ifa_

coding_system/IFA_Spec_Transport_Logistik_DE.pdf

verfügbar.

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

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

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


Im einzelnen beschreibt die vorliegende Spezifikation

auf Basis der von securPharm e.V. herausgegebenen

„Regeln zur Codierung verifizierungspflichtiger Arznei-

mittel im deutschen Markt zum Schutz vor Arznei-

mittelfälschungen (Codierregeln securPharm)“ die

Überführung der PZN in die weltweit eindeutige

„Pharmacy Product Number (PPN)“. Näheres dazu ist

in Kapitel 3.2 beschrieben.

Wesentlicher Bestandteil dieser Spezifikation ist die

Beschreibung des Data Matrix Codes, der die notwen-

digen Datenelemente zur maschinellen Lesung bereit

stellt. Es werden auf Basis der PPN als Produktnummer

die Codierung und die damit verbundene Kennzeich-

nung der Arzneimittelpackungen, die Datenstrukturen

und die Ausprägungen der Datenelemente sowie

die Codierung mit Codegröße und Druckqualität

beschrieben.

Alle wesentlichen und verbindlichen Teile zur Codierung

wurden aus den „Codierregeln securPharm“ in diese

Spezifikation übernommen. Bezüglich Generierung

der Seriennummern siehe jedoch Kapitel 3.1 der oben

genannten Regeln.

Somit ist sichergestellt, dass bei Anwendung dieser

Spezifikation alle Vorgaben von securPharm

berücksichtigt sind.

Darüber hinaus enthält diese Spezifikation die detaillierte

Beschreibung typischer Fehler (siehe Anhang F).

3 Vereinbarungen zur Codierung

3.1 Allgemeines

Zur Produktidentifikation von Arzneimitteln ist im Fünf-

ten Buch Sozialgesetzbuch (SGB V) die Pharmazentral-

nummer (PZN) –codiert im Code 39 – verankert.

Ergänzend dazu legten die Stakeholder im deutschen

Arzneimittelmarkt in ihren „Codierregeln securPharm“

die maschinenlesbare Kennzeichnung von Handels-

packungen mit den folgenden Datenelementen fest:

• Produktnummer

• Chargenbezeichnung

• Verfalldatum und

• Seriennummer

Die „Codierregeln securPharm“ erlauben die Codie-

rung im Data Matrix Code nach ISO/ IEC 16022 (siehe

vorliegende Spezifikation Kapitel 5.1) und der Daten-

struktur und Syntax gemäß ISO/IEC 15418 sowie ISO/

IEC 15434 (siehe Kapitel 4).

Damit ist die Maschinenlesbarkeit dieser Datenelemente

gegeben und die technische Voraussetzung für die

Umsetzung der EU-Richtlinie zum Schutz vor Arznei-

mittelfälschungen sowie der weiteren zu erwartenden

gesetzlichen Auflagen zur Verifizierung von Arzneimit-

telpackungen geschaffen.

Diese Codierung wird in ihrer Gesamtheit als

PPN-Code bezeichnet.

3.2 Pharmacy Product Number (PPN) – Anwendung in Deutschland

Viele Vorgänge, wie z.B. zur Erstattung und zur Identifi-

kation von Arzneimitteln, beziehen sich auf die PZN als

Produktnummer.

Zur Verifizierung im Sinne der EU-Richtlinie wird eine

europaweit eindeutige Produktnummer benötigt.

Um auch dieser Anforderung zu genügen, wurde die

Pharmacy Product Number (PPN) geschaffen und ihr

der Data Identifier „9N“ zugeordnet.

Aus der PZN wird, wie folgt dargestellt, die weltweit

eindeutige PPN generiert:

Pharmacy Product Number (PPN)

11 12345678 42

Product Registration PZN Check-Digits PPN Agency Code for PZN

Abbildung 2: Generierung der PPN


Die PPN besteht aus drei Teilen, die farblich rot, blau

und grün hervorgehoben sind. Die 11 steht für den

Product Registration Agency Code (PRA-Code oder

PRAC). Dieser Code wird von der IFA verwaltet und

vergeben. Die 11 ist für die PZN reserviert. Nach der 11

folgt, in blau dargestellt, die nationale Produktnummer.

Dabei handelt es sich um die unveränderte PZN

(PZN8). Die darauf folgenden Ziffern (im Bild grün

dargestellt) bilden die zweistellige, errechnete Prüfziffer

über das komplette Datenfeld.Der Algorithmus zur Prüf-

ziffernberechnung ist in Anhang B beschrieben. Mit der

im Beispiel dargestellten PZN ergibt sich der Wert „42“.

In der PPN werden PRA-Code, PZN und die PPN-

Prüfziffer ohne Trennungen abgebildet. Da die einge-

bettete PZN durch den Data Identifier„9N“ für die PPN

und den PRA-Code eindeutig identifiziert ist, entfällt

der bei der PZN-Darstellung sonst übliche, vorange-

stellte Bindestrich als Identifikator.

Existierende Datenbanken und Softwaresysteme können

algorithmisch aus der PPN eine PZN generieren und

umgekehrt. Die Datenbanken können somit unverän-

dert mit der PZN weiterarbeiten. Alternativ können auch

neue Tabellen (Übersetzungstabellen) problemlos

generiert werden. In den Diensten der IFA wird die PPN

als ergänzendes Attribut zur PZN ausgegeben.

Die Interoperabilität mit anderen Nummernsystemen,

z.B. GTIN (GS1 als zuständige IA) oder HIBC (EHIBCC

als zuständige IA), ist durch die gemeinsame Basis der

internationalen Normen zuverlässig gewährleistet

Die Nutzung der PPN ist lizenzkostenfrei!

3.3 Weitere weltweite Anwendungen der PPN

Mit diesen Festlegungen zur PPN können auch weitere

Teilnehmer im Gesundheitswesen ihre nationalen und

proprietären Nummerkreise international eindeutig

abbilden. Wie z.B. der Eurocode IBLS der Blutban-

ken, die nationalen Nummernkreise in Belgien (CNK-

number), Italien (AIC-number), Griechenland (EOF-

number), Österreich (PZN) etc. Die IFA als Issuing

Agency stellt durch die Vergabe und Registrie-

rung des PRA-Code die konfliktfreie Zuordnung

und Verwendung der PPN sicher.

Weitere Informationen können abgerufen werden unter:

www.IFA Coding System.org. Die Applikationen in Ver-

bindung mit der PPN sind im Kapitel 3.4 beschrieben.

3.4 Codes und Dateninhalte auf Handelspackungen

Je nach Produkt setzt sich der PPN-Code unterschiedlich zusammen, entweder nur die PPN allein oder die PPN

zusammen mit anderen Datenelementen. Im Folgenden sind die grundsätzlichen Varianten beschrieben:

PZN-Code 1)

Symbologie: Code 39PPN-Code 2)

Symbologie: Data Matrix Code

PZN PPN SN LOT EXP GTIN

Verifizierungspflichtiges Arzneimittel √ √ √ √ √ optional 3)

Nicht verifizierungspflichtiges Arzneimittel

√ √ optional optional optional optional 3)

Sonstige apothekenübliche Ware √ √ optional optional optional optional

Abbildung 3: Applikationsvarianten in der Codierung

1) Nach dem Fünften Buch Sozialgesetzbuch (SGB V) ist die Angabe der PZN im PZN-Code zunächst weiterhin obligatorisch. 2) Der PPN-Code ist für nicht verifizierungspflichtige Arzneimittel und sonstige apothekenübliche Waren optional und besonders dann anzuwenden, wenn neben der PZN weitere Datenelemente im Code ausgegeben werden sollen. 3) Für interne Zwecke optional verwendbar.

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


3.5 Multi Country Packs

Multi Country Packs sind Handelspackungen, die in

einer bestimmten Aufmachung in mehreren Ländern

abgabefähig sind. Sie tragen in der „Blue Box“ mehrere

nationale Produktnummern für Erstattungszwecke und

warenwirtschaftlichen Belange und weitere verschiedene

länderspezifische Informationen. Bei der Kennzeich-

nung mittels PPN-Code können die unterschiedlichen

Produktnummern ebenfalls im Data Matrix Code ent-

halten sein.

Für verifizierungspflichtige Produkte ist es zwin-

gend, die Produktnummern aller Länder, in denen

verifiziert wird, in den PPN-Code mit aufzunehmen.

Im Code ist nur eine Seriennummer enthalten, sie

bezieht sich bei der Verifizierung jeweils auf die

Produktnummer des betreffenden Landes.

Die Details zum Dateninhalt sind in Kapitel 4.2.8. und

die zur Klartextinformation in Kapitel 5.6 beschrieben.

Abbildung 4: Multi Country Pack

4 Dateninhalte und Anforderungen

4.1 DatenstrukturDamit Datenelemente aneinandergereiht eindeutig im

Datenstring identifizierbar sind, werden diese gem. der

Syntax ISO/IEC 15434 eingebettet (siehe Abbildung 5).

Die Startsequenz verweist als „Systemidentifikator (SI)“

eindeutig auf die verwendete Struktur.

Formal besteht der Datenstring aus:

• Message Header

• Format Header

• Datenfelder 1 bis 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

Abbildung 5: Envelope-Struktur nach

ISO/IEC 15434

In dieser hier beschriebenen Applikation wird auf die

Gruppierung von Datenelementen verzichtet und somit

alle Daten in ein einziges Envelope-Format eingebettet. Für

die Kennung der Datenelemente werden Datenidentifika-

toren benutzt. Die Anwendung der Datenidentifikatoren ist

zwingend. Ein komplettes Datenelement besteht immer aus

einem Datenidentifikator und dem Datenfeld. Mehrerer

Datenelemente werden in einem Code zusammenge-

fasst, indem die Datenelemente jeweils durch ein Trenn-

zeichen abgeschlossen werden (siehe Abbildung 7).

Das Trennzeichen (Field Separator) am Ende der

Datenfelder ist zwingend erforderlich (ASCII29 siehe

Abbildung 6).

Zeichensatztabelle

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

Abbildung 6: Zeichensatztabelle der ISO/IEC 15434

Envelope Steuerzeichen


Datenstring


Zeichensatztabelle:

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

Abbildung 5: Zeichensatztabelle der ISO/IEC 15434

Envelope Steuerzeichen

Datenstring:

Interpretation Codeinhalt

Messageheader [)> RSCodewort 237

Formatheader 06 GS

Datenfeld 1 DI 9N

Datenfeld 1 Inhalt 111234567842

Field-Separator GS

Datenfeld 2 DI 1T


Field-Separator GS

Datenfeld 3 DI D


Field-Separator GS

Datenfeld 4 DI S


Field-Separator GS (optional)

Formattrailer RS

Messagetrailer EOT

Abbildung 6: Beispiel eines kompletten Daten-

strings mit den Datenelementen PPN, Chargenbe-

zeichnung, Verfallsdatum und Seriennummer

Die Reihenfolge der Datenfelder ist beliebig. Es können

außer den obligatorischen Datenelementen auch ggf.

weitere verwendet werden. Details sind in den folgen-

den Kapiteln beschrieben.

4.2 Header

Zur komprimierten Darstellung im Data Matrix Code

nach ISO/IEC 16022 „ASCII encodation“ werden über

ein Macro-Codewort der Header „[)> RS 06 GS“ und

der Trailer wie in Abbildung 7 dargestellt interpretiert:

Macro-Codewort

Name Interpretation Header

Interpretation Trailer

237 06 Macro [)>RS06GS RS EOT

Abbildung 7: Macro 06

4.3 Fieldseparator

Jedes Datenfeld wird mit dem Field Separator GS ab-

geschlossen. Am Ende des letzen Datenfeldes kann

der Field-Separator entfallen, da der Format- und Mes-

sagetrailer den Datenstring definiert abschließen.

4.4 Trailer

Der Datenstring wird mit dem Formattrailer RS und EOT

abgeschlossen. Dieser Trailer ist gemäß ISO/IEC 16022

über das Macro 06 impliziert.

4.5 Zeichensätze

Zulässige Datentypen, Zeichensätze sowie Datenlänge

etc. der zu codierenden Daten sind in einem separaten

Anhang dargestellt (siehe Anhang A).

4.6 Produktnummer

Datenbezeichner: „9N“

Zur Produktidentifikation wird die Pharmacy-Product-

Number herangezogen. Alle weiteren, im Datenstring

enthaltenen Datenelemente beziehen sich auf die PPN.

In der PPN ist die PZN enthalten und kann daraus extra-

hiert werden (siehe Kapitel 3.2)

Es muss die auf 8 Stellen erweiterte PZN verwendet

werden. Daraus ergibt sich eine 12-stellige numerische

PPN.

Die Produktnummer steht auch anderen nationalen

Nummernkreisen offen und ist deshalb in der Norm

Abbildung 7: Beispiel eines kompletten Datenstrings

mit den Datenelementen PPN, Chargenbezeichnung,

Verfalldatum und Seriennummer

Die Reihenfolge der Datenfelder ist beliebig. Es können

außer den obligatorischen Datenelementen auch ggf.

weitere verwendet werden. Details sind in den folgen-

den Kapiteln beschrieben.

4.1.1 Message Header

Zur komprimierten Darstellung im Data Matrix Code

nach ISO/IEC 16022 „ASCII encodation“ werden über

das Macro-Codewort „237“ der Header „[)> RS 06 GS“

und der Trailer interpretiert (siehe Abbildung 7

und folgende Tabelle):

Macro- Codewort Name Interpretation

HeaderInterpretationTrailer

237 06 Macro [)>RS06GS RS EOT

4.1.2 Field Separator

Jedes Datenfeld wird mit dem Field Separator GS

abgeschlossen. Am Ende des letzten Datenfeldes kann

der Field Separator entfallen, da der Format Trailer und

Message Trailer den Datenstring definiert abschließen.

4.1.3 Message Trailer

Der Datenstring wird mit dem Format Trailer RS und

EOT abgeschlossen. Dieser Trailer ist gemäß ISO/IEC

16022 über das Macro 06 impliziert.

4.2 Datenidentifikatoren und Daten

4.2.1 Allgemeines

Die notwendigen Datenidentifikatoren sind in der

internationalen Datenstrukturnorm ISO/IEC 15418

(verweist auf ANSI MH10.8.2: Data Identifier and Appli-

cation Identifier) definiert. In dieser Anwendung werden

ausschließlich die ASC Data Identifier (DI) nach dieser

Norm verwendet, deren Ausprägung in den folgenden

Kapiteln definiert wird. Zur besseren Übersicht sind die

Data Identifier in Anhang A tabellarisch dargestellt.

Die Normen lassen die Ausprägung der Datenelemente

in der Regel offen. Deshalb sind in dieser Spezifikation,

für alle Markteilnehmer verbindlich, der jeweilige Da-

tentyp, die Datenlänge und der Zeichenvorrat definiert

(siehe Anhang A).

Sollen weitere Data Identifier spezifiziert werden, so ist

ein entsprechender Antrag bei der IFA zu stellen.

Nicht in dieser Spezifikation verwendete Data Identifier,

die jedoch der Syntax der MH10.8.2. folgen, sollen in

den Applikationen korrekt ausgegeben werden und zu

definierten Zuständen führen. Der Datenerfassungs-

vorgang und der Verifizierungsprozess dürfen dadurch

nicht gefährdet werden. Die normierten Datenstruktu-

ren dürfen durch solche Erweiterungen nicht verletzt

werden. Grundsätzlich ist das Format der Data Iden-

tifier nach ANSI MH10.8.2 alphanumerisch. Der Data

Identifier schließt immer mit einem Alphazeichen ab,

dem kann eine Zahl vorangestellt sein.

Zulässige Datentypen, Zeichensätze sowie Datenlänge

etc. der zu codierenden Daten sind in Anhang A dar-

gestellt.


4.2.2 Produktnummer

Data Identifier: „9N“

Zur Produktidentifikation wird die Pharmacy Product

Number (PPN) herangezogen. Alle weiteren, im Daten-

string enthaltenen Datenelemente beziehen sich auf die

PPN. In der PPN ist die PZN enthalten und kann daraus

extrahiert werden (siehe Kapitel 3.2)

Es muss die auf 8 Stellen erweiterte PZN (PZN8) verwen-

det werden. Daraus ergibt sich eine 12-stellige numeri-

sche PPN.

Die Produktnummer steht auch anderen nationalen

Nummernkreisen offen und ist deshalb in der Norm

ANSI MH10.8.2 als alphanumerisches Feld mit 22

Zeichen definiert.

Beispiel:

DI Daten9N 110375286414

4.2.3 Chargenbezeichnung

Data Identifier: „1T“

Die Chargenbezeichnung wird vom Pharmazeutischen

Unternehmer generiert und bildet somit das entspre-

chende Datenelement für den Code.

Zur Abgrenzung von Teil-/Unterchargen können definierte

Sonderzeichen verwendet werden (siehe Anhang A).

Beispiel:

DI Daten

1T 12345ABCD

4.2.4 Verfalldatum

Data Identifier: „D“

Das Verfalldatum wird vom Pharmazeutischen Unter-

nehmer generiert und bildet somit das entsprechende

Datenelement für den Code.

Das Verfalldatum hat das Format „YYMMDD“

YY = zweistellige Jahreszahl

Da das Verfalldatum ausschließlich in

der Zukunft liegt, handelt es sich um

Datumsangaben für das 21. Jahrhundert

(2000-2099).

MM = Numerische Monatsangabe (01-12)

DD = Tag

a) Verfalldatum mit Tages-/ Monats- und Jahresangabe

(DD = 01-31)

b) Verfalldatum mit Monats- und Jahresangabe

(DD = 00)

Beispiel: Verfalldatum Juni 2016

DI Daten

D 160600

Dieses Beispiel stellt die vom AMG vorgegebene

Datumsangabe dar.

Beispiel: Verfalldatum 17. Juni 2016

DI DatenD 160617

Dieses Beispiel stellt die Möglichkeit einer tages-

genauen Datumsangabe dar.

Anmerkung: In der ANSI MH10.8.2 ist „D“ als Datum

allgemein definiert. Im Kontext der PPN ist das Datum

zwangsweise das Verfalldatum. Bei anderen Datums-

angaben, wie z.B. dem Produktionsdatum, sind andere

Datenidentifikatoren zu verwenden. Beim Produktions-

datum wäre dies der DI „16“ (siehe Kapitel 4.2.6).

4.2.5 Seriennummer

Data Identifier: „S“

Die Seriennummer wird vom Pharmazeutischen Unter-


Datenelement für den Code. Sie ist für den Verifizie-

rungsprozess zur Arzneimittelsicherheit obligatorisch.

Für Produkte, die nicht darunterfallen, kann diese

optional aufgebracht werden. Bezüglich Generierung

der Seriennummern siehe „Codierregeln securPharm“.


Beispiel:

DI Daten

S 12345ABCDEF98765

Die verwendbaren Zeichen sind im Anhang A be-

schrieben.

4.2.6 Herstelldatum

Data Identifier: „16D“

Das Herstelldatum wird vom Pharmazeutischen Unter-


Datenelement für den Code.

Es kann für interne Zwecke oder dann ausgegeben

werden, wenn zwischen Marktpartnern dedizierte

Vereinbarungen bestehen.

Das Herstelldatum hat das Format „YYYYMMDD“

YYYY = vierstellige Jahreszahl

MM = Numerische Monatsangabe (01-12)

DD = Tag

a) Herstelldatum mit Tages-/ Monats- und

Jahresangabe

(DD = 01-31)

b) Herstelldatum mit Monats- und Jahresangabe

(DD = 00)

Beispiel: Herstelldatum März 2012

DI Daten

16D 20120300

Beispiel: Herstelldatum 15. März 2012

DI Daten16D 20120315

4.2.7 GTIN

Data Identifier: „8P“

Die GTIN generiert der Hersteller nach den Regeln

der GS1 für sein Produkt. Sie kann dann ausgegeben

werden, wenn für Produkte neben der PZN (PPN) auch

eine GTIN vergeben ist, zum Beispiel für Nahrungs-

ergänzungsmittel.

Beispiel: GTIN mit der Nummer 01234567891234

DI Daten8P 01234567891234

4.2.8 Produktnummer bei Multi Country Packs

Die Besonderheit bei Multi Country Packs sind mehrfach

enthaltene, länderspezifische Produktnummern. Die für

das jeweilige Land relevante Produktnummer muss

durch die Systeme im Handel und bei den Abgabe-

stellen erkannt werden. Je nachdem, ob es sich bei den

Produktnummern um eine PPN oder um eine GTIN/

NTIN handelt, wird der Data Identifier „9N“ oder „8P“

verwendet, gegebenenfalls auch mehrfach.

Beispiel:

PPN mit der Nummer 110375286414 und

GTIN mit der Nummer 01234567891231 und

NTIN mit der Nummer 03400123456789

DI Daten

9N 110375286414

8P 01234567891234

8P 03400123456789

Alle weiteren Datenelemente können ohne Einschrän-

kung entsprechend hinzugefügt werden.

5 Beschriftung mit Code und Klartext

5.1 Symbologie

Dieses Kapitel beschreibt die Codierung mit den Vorga-

ben für den Klartext und Elementen wie z.B. das Emb-

lem zum Code.

Der verwendete Datenträger bzw. die Symbologie

ist der Data Matrix gemäß ISO/IEC 16022. Die Feh-

lerkorrektur erfolgt nach ECC200. Die anderen Feh-

lerkorrekturmethoden (ECC000 bis ECC140) dürfen

nicht eingesetzt werden. Eigenschaften des Data

Matrix Codes sind separat beschrieben (siehe Anhang I).

Sofern immer eine gleichbleibende Matrixgröße

gedruckt werden soll, sind ggf. Füllzeichen einzufügen

(siehe Anhang I.5).


5.2 Matrixgröße

Typischerweise soll die Matrixgröße von 26x26 bzw. 16x48 Modulen nicht überschritten werden. Klei-

nere Matrixgrößen sind erlaubt, sofern die Kapazität für die zu kodierenden Daten ausreicht.

Vorzugsweise sind die quadratischen Codes zu verwenden. Sofern das Packmitteldesign oder die Drucktechnolo-

gie es erfordern, sind auch die rechteckigen Varianten verwendbar.

Quadratische Symbole

Matrixgröße Dimension (mm) DatenkapazitätZeilen Spalten Typisch

X = 0,35

Min

X = 0,25

Max

X = 0,615

Numerisch Alpha-

numerisch

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

Rechteckige Symbole

Matrixgröße Dimension (mm) Datenkapazität

Zeilen Spalten Typisch X = 0,35

Min X = 0,25

Max X = 0,615

Numerisch Alpha-numerisch

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 = Modulgröße in mm

Details zur Symbologie siehe Anhang I

5.3 Codegröße und Ruhezone

Die Modulgröße des Codes darf zwischen 0,25 und

0,615 mm variieren. Innerhalb dieses Bereiches dürfen

die Modulgrößen unter Beachtung der Druckqualität

(siehe Kapitel 5.8) sowie der einzusetzenden Druck-

systeme (siehe Kapitel 6) beliebig skaliert werden.

Mit der Modulgröße ist die Größe einer Matrixzelle

gemeint (siehe Kapitel 5.2 und Anhang I.1). Typische

Modulgrößen liegen zwischen 0,33 und 0,45 mm.

Die an den Code angrenzenden Flächen sind von

weiterer Bedruckung freizuhalten. Dieser Abstand, die

so genannte Ruhezone, soll mindestens drei Module

betragen.

5.4 Positionierung des Data Matrix Codes

Für die Positionierung werden keine besonderen Festle-

gungen getroffen. Die Position bestimmt der Hersteller

aufgrund des Packungslayouts und der Gegebenheiten

des Bedruckens (siehe Anhang G).

Bei Zulassungen durch die EMA wird der Code außer-

halb der „Blue Box“ aufgebracht.


5.5 Emblem zum Data Matrix Code

Das Emblem „PPN“ am Data Matrix Code, weist den

Handel auf den Code hin, der zum maschinellen

Erfassen der Produktnummer und den weiteren Daten

herangezogen wird. Bei verifizierungspflichtigen Pro-

dukten ist dies gleichzeitig der Hinweis zur Identifikation

und Verifizierung der Handelspackung.

Abbildung 8: Emblem zum Code

Es sind verschiedene Varianten und Details zur

graphischen Gestaltung des Emblems möglich (siehe

Anhang C).

Die minimalen Abstände zum Code (Ruhezonen) sind

zu beachten.

Das Emblem kann in einer Übergangsphase entfallen.

Somit hat der pharmazeutische Hersteller mehr Freihei-

ten bei den Umstellungsprozessen.

5.6 Klartextinformation

PPN: Die PPN respektive die PZN sind das Schlüssel-

element der Verkaufspackung. Nach den aktuellen

gesetzlich geltenden Regeln muss die PZN in Klar-

schrift mit dem Code 39 aufgebracht werden (siehe

Spezifikation zur PZN (http://www.pzn8.de/downloads/

de/IFA_Spec_PZN_Codierung_DE.pdf). Die PPN wird

daher im Klartext nicht mitgedruckt.

Chargenbezeichnung und Verfalldatum: Für die

Klartextinformation bzgl. der Chargenbezeichnung

und des Verfalldatums gelten die arzneimittelrechtlich

vorgegebenen Anforderungen zur Kennzeichnung.

Seriennummer: Die Seriennummer ist nicht im

Klartext auszugeben, da der Verifizierungsprozess des

Arzneimittels ausschließlich automatisch erfolgen soll

und nach dem Stand der Technik die maschinen-

lesbare Information verfügbarer und fehlerfreier als eine

manuelle Eingabe ist.

Klartextinformationen bei Multi Country Packs:

Unverändert sind in der „Blue Box“ neben den länder-

spezifischen Produktinformationen die Produktcodes

abzubilden. Weitere textliche Kennzeichnungen am

Data Matrix Code sind nicht vorgesehen.

Weitere optionale Datenelemente: Die ggf. notwen-

dige Klartextinformation unterliegt individuellen Regeln,

die nicht Bestandteil dieser Spezifikation sind.

5.7 Codebeispiele

Die folgenden Beispiele verwenden als Startsequenz

immer das Macro 06 (Codewort 237). Die Datenfelder

sind immer mit dem Zeichen GS (ASCII 29) abge-

schlossen. Hinter dem letzten Datenfeld ist kein GS Zeichen kodiert, da das Lesegerät aufgrund des Macro

06 die Zeichen RS und EOT automatisch generiert.

Folgende Beispiele zeigen, welche Größen der Code je

nach Länge der Datenfelder annehmen kann. Die Länge

der Datenfelder bestimmt der Hersteller, unter Beach-

tung der in Anhang A aufgeführten Spezifikationen.

Beispiel 1

Ein typische Größe ist ein Code mit einer Matrix von

26x26 Modulen. Die Datenfelder weisen hierbei eine

häufig verwendete Länge auf:

Codeinhalt:

DI Datenfeld

9N 110375286414

1T 12345ABCD

D 150600

S 12345ABCDEF98765

Beispiel 2

Die minimale Größe wäre eine Matrix von 22x22

Modulen. Die Datenfelder weisen hierbei eine sehr

kurze Datenlänge auf:

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



Codeinhalt:

DI Datenfeld

9N 110375286414

1T 1ABCDE

D 150600

S 1ABCDEF

In der Variante mit einer Matrixgröße von 22x22 Modu-

len kann die Chargenbezeichnung und die Seriennum-

mer jeweils maximal 7 Zeichen umfassen.

Beispiel 3

Wird die Datenfeldkapazität für die vier Standard-

elemente bis zum Limit genutzt, muss mit einer Matrix

von 32x32 Modulen gerechnet werden:

Codeinhalt:

DI Datenfeld

9N 110375286414

1T 1A2B3C4D5E6F7G8H9I0J

D 150600

S A1B2C3D4E5F6G7H8I9J0

Beispiel 4

Dieser Code zeigt ein rechteckiges Format mit einer

Matrix von 16x48 Modulen. Die Datenfelder sind identisch

mit denen im Beispiel 1.

Codeinhalt:

DI Datenfeld

9N 110375286414

1T 12345ABCD

D 150600

S 12345ABCDEF98765

5.8 Druckqualität

Die Prüfung des Codeinhalts (Lesekontrolle) ist

grundsätzlich von der Prüfung der Druckqualität

(Druckqualitätskontrolle) zu unterscheiden.

Grundvoraussetzung für einen nutzbaren Code ist,

dass dieser gelesen werden kann und der Inhalt

den festgelegten Regeln entspricht. Die praktische

Lesbarkeit hängt vom jeweils verwendeten Lesegerät

und den Rand- bzw. Umgebungsbedingungen ab. Zur

Sicherstellung der allgemeinen Lesbarkeit eines Codes

wird eine Mindestdruckqualität, entsprechend einer

Konventionsmethode definiert.

Bei Digitaldruck ist jeder Druck als individuell zu

betrachten. Daher muss der Codeinhalt jeweils mittels

Lesekontrolle überprüft werden (siehe Anhang E.3).

Der aktuelle technische Standard für die Bestimmung

der Druckqualität ist in der ISO/IEC 15415 beschrieben.

Die Lichtart, mit der geprüft wird, ist Rotlicht mit ei-

ner Wellenlänge von 660 nm (+/- 10 nm). Die syn-

thetische Apertur ist 80% der jeweiligen Codegröße

gemäß dem oben genannten ISO-Standard. Alter-

nativ gibt es die Möglichkeit, eingebaute Analyse-

fähigkeiten der verwendeten Erfassungssysteme zu

nutzen, die angelehnt an ISO/IEC 15415 die Druck-

qualität bestimmen.

Die Druckqualität wird mit Ziffern von 4 bzw. Buchstaben

von A (beste Qualität) bis 0 bzw. F (schlechteste Qualität)

ausgedrückt (siehe nachfolgende Tabelle).

Qualitätsstufen nach ISO/IEC 15415

ISO/IEC-Klasse

ANSI-Grad

Bei Mehr-fachmes-sung

Bedeutung

4 A 3,5 - 4,0 Sehr Gut

3 B 2,5 - 3,49 Gut

2 C 1,5 - 2,49 Befriedigend

1 D 0,5 - 1,49 Ausreichend

0 F Unter 0,5 Durchgefallen

Die Druckqualität darf den Grad 0,5 (ausreichend)


gemäß ISO/IEC 15415 nicht unterschreiten. Um

die Lesbarkeit am Ende (und ggf. während) der

Lieferkette sicher zu gewährleisten, muss eine

Druckqualität von Grad 1,5 (befriedigend) ange-

strebt werden.

Die Mindestqualitätsanforderung an die Druckqualität

gilt grundsätzlich nur im Zusammenhang mit allgemein

anerkannten Methoden der Statistik in der Qualitäts-

kontrolle (siehe Anhang E.5).

Weitere Details zur Druckqualität und den Prüfgeräten

sind in Anhang E beschrieben.

6 Drucksysteme

Die Drucksysteme müssen in der Lage sein, die Codes

in der definierten Mindestdruckqualität (siehe Kapitel

5.8) Drucksysteme können gemäß der internationalen

Norm ISO/IEC 15419 geprüft werden.

Typische Fehler im Druck sind neben denen der Daten-

struktur und des Dateninhaltes in Anhang F beschrieben.

7 Lesetechnik

Gelesen wird der Data Matrix Code durch handelsübli-

che Scanner für 2D Matrixcodes. Die optischen Eigen-

schaften bezüglich Mindestleseabstand, Tiefenschärfe

und Auflösung müssen so gewählt sein, dass eine hohe

Erstleserate erzielt wird.

Die in dieser Spezifikation beschriebenen Codeeigen-

schaften bezüglich Modulgrößenvariation und Matrix-

größenvariation sind die Vorgabe für die Scannereigen-

schaften. Darüber hinaus bestimmt die Applikation die

notwendige Lesegeschwindigkeit und Schärfentiefe.

Scanner können gemäß der internationalen Norm ISO/

IEC 15423 getestet werden.

Die Anforderungen an die Codequalität steigen mit dem

Automatisierungsgrad. Manuell bediente Scanner sind

am tolerantesten gegen schlechte Codedruckqualitä-

ten. Vollautomatische Leseeinrichtungen reagieren am

empfindlichsten auf schlechte Codedruckqualitäten.

Die Anzahl der Leseausfälle steigt mit abnehmender

Druckqualität und mit zunehmender Prozessgeschwin-

digkeit (siehe auch Kapitel 5.8 und Anhang E).

Die Wahrscheinlichkeit, dass Codes mit falschem

Dateninhalt gelesen werden, ist gering, aber nicht

unmöglich. Aus diesem Grund stößt eine Verbesserung

der Scanner ab einem bestimmten Punkt an Grenzen.

Ein optimales System verwendet fehlertolerante Scanner

und Codes mit einer guten Druckqualität, um die Wahr-

scheinlichkeit von erfolgreichen Falschlesungen zu mi-

nimieren.

8 Interoperabilität bei unter-schiedlichen Datenstrukturen und Datenidentifikatoren

8.1 Interoperabilität auf Basis bestehender Auto-ID

Für die Hersteller, den Großhandel, die Apotheken, die

Kliniken, aber auch die Praxen ist die Interoperabilität

der Codierungen eine Voraussetzung für das Lesen

und der eindeutigen Identifikation der Datenelemente.

Bei einer durchgängigen Interoperabilität ist es den

Beteiligten möglich, ihre Prozesse kostengünstig zu

betreiben.

Die gemeinsame Basis dafür sind die Norm ISO/IEC

15459 Unique Identification, die System- und Daten-

identifikatoren Norm ISO/IEC 15418 (ANSI MH10.8.2)

und die Syntaxnorm ISO/IEC 15434.

Unter Beachtung der Normen können Daten aus

verschiedenen Datenträgern, unterschiedlichen Sym-

bologien und Kennzeichnungssystemen konfliktfrei

übertragen werden, wie in Abbildung 5 gezeigt.

Im Folgenden sind die im Gesundheitsbereich gängigen

Systeme aufgeführt, die konfliktfrei neben der in dieser

Spezifikation beschriebenen Kennzeichnung von Daten

eingesetzt werden können.


GS1

Das System der GS1 basiert auf der Artikelkennzeich-

nung mittels GTIN. Für spezielle Lösungen hat die GS1

auch einen Präfix für eine so genannte NTIN, die daten-

technisch als Artikelnummer einer GTIN gleichzusetzen

ist, vergeben. Wesentliche Merkmale sind der nach DIN

66403 als Systemidentifikator verwendete Steuercode

„FNC1“ und die Verwendung von Application Identifier

(AI) als Datenindentifikatoren. Die Interoperabilität

zwischen den AI und den Data Identifier (DI) ist über

die Referenztabellen der ANSI MH10.8.2 sichergestellt.

Das Envelope Format der Norm ISO/IEC 15434 wird

vom GS1 System nicht benutzt.

HIBC

Der Healthcare Industry Bar Code – HIBC wird von der

EHIBCC-Organisation verwaltet. EHIBCC ist eine Issuing

Agency nach ISO/IEC 15459. Der klassische HIBC wird

von dem registriertem Systemidentifikator „+“ (Plus)

angeführt und ist damit von allen anderen Systemen

verwechslungsfrei identifizierbar. Das entscheidende

Merkmal des HIBC ist der kompakte Aufbau und die

Kapazität für alphanumerische Produktcodes von

2 bis 18 Stellen. Der HIBC-Standard ist auf die alter-

native Verwendung von Datenidentifikatoren für alle

logistischen Ebenen erweitert worden (DI 25P); (siehe

www.HIBC.de).

8.2 Interoperabilität auf Basis von XML-Standards

Im Anhang D ist ein vorzugsweise anzuwendender

Standard beschrieben, der auf allgemeinen XML-

Standards beruht und die Datenidentifikatoren neutral

beschreibt. Dies ermöglicht den offenen Datenaus-

tausch wie z.B in Abbildung 9 beschrieben, unabhän-

gig von Symbolik und Datenstrukturen.

<PPN> 11012…

<GTIN> 012345..

<SN> 12334….

<LOT> 12ABC..

<EXP> 151231

<PZN> 01234567

….

….

….

Abbildung 9: Datenaustausch zwischen Lesegerät

und System auf XML-Basis

http://www.HIBC.de


Anhang A Übersicht Datenelemente und Data Identifier Die folgende Tabelle spezifiziert die Ausprägung der einzelnen Datenelemente und der zugehörigen Data Identifier:

Datenelemente XML-Knoten

DI Datentyp Daten-format

Zeichen-länge

Zeichenvorrat

Pharmacy Product Number

<PPN> 9N AN --- 4-22 0-9; A-Z Keine Sonderzeichen keine Kleinschreibung keine Umlaute

Chargenbe-zeichnung

<LOT> 1T AN --- 1-20 0-9; A-Z Erlaubte Sonderzeichen „-“ und „_“ keine Kleinschreibung keine Umlaute

Verfalldatum <EXP> D Datum YYMMDD 6 0-9

Seriennummer <SN> S AN --- 1-20 0-9; A-Z Keine Sonderzeichen keine Kleinschreibung keine Umlaute

Herstelldatum <MFD> 16D Datum YYYYMMDD 8 0-9

GTIN oder NTIN <GTIN> 8P N --- 14 0-9

Anmerkung zum Datenformat:

Lediglich bei den Datumsangaben ist ein festes Datenformat vorgegeben

Anmerkung zum Zeichenvorrat bezüglich Chargenbezeichnung:

Erlaubte Sonderzeichen bei der Chargenbezeichnung sind der Unterstrich „_“ und der Bindestrich „-“. Alle

anderen Sonderzeichen werden in verschiedenen Anwendungen unterschiedlich verwendet. Die Anwendung solcher

Zeichen birgt ein hohes Risiko der Fehlinterpretation und wird daher hier ausgeschlossen.

Kleinbuchstaben sind nicht erlaubt, weil einige Systeme zwischen Kleinbuchstaben und Großbuchstaben unter-

scheiden und andere nicht. Auch wegen der Verwechslungsgefahr von Kleinbuchstaben und Großbuchstaben

sind Kleinbuchstaben ausgeschlossen Zur Aufnahme weiterer Data Identifier in diese Spezifikation wenden Sie sich

bitte an die IFA.


Anhang B Algorithmus zur Prüfzifferberechnung der PPN Die Prüfziffer der PPN (Beschreibung der PPN siehe Kapitel 3.2 wird nach dem Modulo 97 berechnet.

Dabei werden den Zeichen der PPN die Dezimalwerte der ASCII-Tabelle von 00 bis 127 zugeordnet. Jede Stelle

der PPN wird mit einem Faktor gewichtet. Das Produkt der ASCII-Dezimalwerte wird addiert und durch 97 geteilt.

Der verbleibende Rest bildet als Zahlenwert die zweistellige Prüfziffer von 00 bis 99. Ein einstelliger Restwert wird

mit führender Null aufgefüllt. Die Gewichtung der Stellen beginnt links mit „2“ und erhöht sich für die jeweils

folgende Stelle um „1“.

Dieser Algorithmus liefert die Prüfziffer sowohl für rein numerische, als auch für alphanumerische PPN.

Beispiel zur PPN und Bildung der Prüfziffer:

Für den deutschen Markt enthält die PPN die Pharmazentralnummer (PZN) mit dem vorangestellten

„Product-Registration Agency Code“ „11“. Die PPN enthält ausschließlich die 8-stellige PZN (PZN8).

Die PZN7 (siebenstellige PZN) wird durch eine führende Null in eine PZN8 überführt.

Details zur PZN8 siehe: http://www.pzn8.de/downloads/de/IFA_Spec_PZN_Codierung_DE.pdf

Für die PZN mit dem Präfix 11 „1103752864“ berechnet sich die PPN Prüfziffer wie folgt:

PRA-Code PZN PZN Prüf-ziffer

PPN Prüfziffer

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

ASCII Dez-Wert

49 49 48 51 55 53 50 56 54 52

Gewichtung 2 3 4 5 6 7 8 9 10 11

Produkt aus ASCII Wert und Gewichtung

98 147 192 255 330 371 400 504 540 572

Summe 3409 / 97 = 35 Rest 14

Die Prüfziffer ist der numerische Rest 14 und bildet die letzten beiden Stellen der PPN. Die vollständige

PPN lautet damit: 110375286414.

Der Rest wird als numerischer Wert übernommen und nicht durch das entsprechende ASCII-Zeichnen

dargestellt. Somit ist sichergestellt, dass die Prüfziffer nur aus den Ziffern von 0 bis 9 besteht.

Numerische Folgen bleiben damit auch numerisch.

Hinweis:

Nach der Überprüfung der PPN-Prüfziffer kann bei korrektem Ergebnis noch zusätzlich die in der PZN enthaltene

Prüfziffer verifiziert werden. Ist auch diese korrekt, so können übliche Eingabefehler ausgeschlossen werden.


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


Anhang C Emblem zum Code

Als Emblem zum Code ist die Zeichenfolge „PPN“ in der Schriftart „OCR-B“ festgelegt.

Die graphische Ausprägung ist nachstehender Skizze zu entnehmen:

dc

fe

a

b

Nominale Maße:

a: ergibt sich aus gewählter Modul- und Matrixgröße

b: ist bei quadratischen Codes gleich a, bei recht-

eckigen Codes entsprechend der Modul- und

Matrixgröße

c: 0,4 * a

d: *)

e: ergibt sich aus der geforderten Ruhezone*)

(Ruhezone siehe Kapitel 5.3)

f: ergibt sich aus der Schrifttype und Maß c

*) Die Maße d und e sind so zu wählen, dass das

Emblem dem Code zugeordnet ist.

Toleranzen:

Die Toleranzen können entsprechend dem gewählten Druckverfahren frei festgelegt werden.

Folgende Ausrichtungen sind prinzipiell möglich:

Folgende Ausrichtungen sind prinzipiell möglich:

In Ausnahmefällen kann das Emblem auch auf einer anderen, angrenzenden Fläche aufgebracht werden.


Anhang D Interoperabilität auf der Basis von XMLBeschreibungen (informativ)

D.1 Allgemeines

Für die Hersteller, den Großhandel, die Apotheken und

die Kliniken ist die Interoperabilität der Codierungen eine

Voraussetzung für das Lesen und die eindeutige Iden-

tifikation der Datenelemente. Bei einer durchgängigen

Interoperabilität ist es den Beteiligten möglich, ihre

Prozesse kostengünstig zu betreiben. Die gemeinsame

Basis dafür sind die Standards IEC 15434 Syntax

for High Capacity Media, ISO/IEC 15459 Unique

Identification sowie die System- und Datenidenti-

fikatoren nach ISO/IEC 15418.

Um Herstellern und Nutzern im pharmazeutischen

Bereich eine noch höhere Interoperabilität zu

bieten, wird in diesem Anhang ein Standard zur

Interpretation der Daten, basierend auf XML

beschrieben. Dies gilt sowohl für die Daten-

übertragung zum Drucker als auch für die

Datenübertragung vom Codeleser an die ange-

schlossenen Systeme.

Der in diesem Anhang beschriebene XML-Standard

bezieht sich ausschließlich auf die Dateninhalte und

damit nicht auf die Layouteigenschaften des Codes, zu

denen die Festlegungen der Klarschriftbedruckung und

die der Symbologie (z.B. Data Matrix Code) gehören.

Bei der Datenübertragung werden nach dem hier

beschriebenen Standard die Daten unabhängig von

den im Code verwendeten Datenbezeichnern einheit-

lich mit neutralen XML-Knoten bezeichnet. Es bilden

sich folgende Ebenen in der Darstellung der Daten

aus:

Applikation: XML-Knoten

Datenhülle: nach ISO/IEC 15434 z.B. Format 06 oder Systemidentifikator nach DIN 66403 z.B. „FNC1“

Datenstruktur Data Identifier (DI) oder Application Identifier (AI)

Symbologie z. B. Data Matrix Code

D.2 Data Format Identifier (DFI)

Bei der Übertragung der Datenelemente im XML-

Standard werden die Eigenschaften zur Darstellung

der Daten im Code dem Data Format Identifier (DFI)

zugeordnet und lediglich dieser übertragen.

Der DFI sagt aus, welche Datenhülle nach ISO/IEC

15434, welche Datenbezeichner (AI oder DI) und ob

ein Makro nach ISO/IEC 16022 zu verwenden ist. Die

Zuweisungen des DFI können aus Tabelle 1 entnommen

werden.

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

Tabelle 1: Data Format Identifier (DFI)

Der DFI kann die Werte „IFA“ oder „GS1“ annehmen

und wird im dem gleichlautenden Attribut des überge-

ordneten XML-Knoten <Content> übertragen.

D.3 XML-Knoten für Daten

In unten stehender Tabelle sind die XML-Knoten für die

Daten und deren Zuordnung zu den Data Identifier (DI)

und Application Identifier (AI) aufgeführt:

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

Tabelle 2: XML-Knoten für Daten


Die vollständige Auflistung der derzeit definierten Knoten

ist im Anhang A aufgeführt. Auf dieser technischen

Ebene der Beschreibung gibt es zwischen NTIN

und GTIN keine Unterscheidung. Deshalb wird der

umfassende Begriff GTIN verwendet.

Der XML-Knoten <Content> umhüllt die „Daten-

knoten“ (siehe Anhang D.4 und Anhang D.5).

Aus den XML-Daten und dem darin enthaltenen Wert

des „DFI“ leiten die Drucker alle notwendigen Infor-

mationen zur Erzeugung des Data Matrix Codes ab.

Das beinhaltet die Datenelemente, die Data Identifier

respektive die Application Identifier, die Trennzeichen

und den Header.

D.4 Anwendung

Sowohl bei der Datenübergabe an die Druckertreiber,

als auch bei der Datenausgabe von den Codelesern

kann die XML-Beschreibung angewendet werden

(siehe schematische Darstellung):

Driver

MES- System

Terminal Printer

Terminal Reader

MES- System A

nwen

der

- A

pp

likat

ions

eben

eS

yste

meb

ene

XML-Tag

MH10.8.2- Daten- bezeich-ner

Code

Printer Reader

Abbildung 7: Datenaustausch auf XML-Basis

Die Treiber zur Interpretation der XML-Beschreibung

können Bestandteil der übergeordneten Systeme (MES)

oder der Drucker (Printer) und Codeleser (Reader) sein.

Die Verwendung der einheitlichen Beschreibung stei-

gert die Interoperabilität und hilft Fehler zu vermeiden.

Auch die Unsicherheit hinsichtlich nichtdruckbarer

Steuerzeichen in Übertragung und Interpretation ist

bei der XML- Beschreibung eliminiert. Beim Lesen der

Codes setzen die Codeleser den Dateninhalt in die

XML-Struktur und die entsprechenden Knoten um.

Bei der Datenübertragung vom Codeleser an die über-

geordneten Systeme werden standardmäßig lediglich

die Daten ohne den „DFI“ übertragen. Optional kann

dieser zusätzlich mit ausgegeben werden und ist

dann von Interesse, wenn im Code z.B. die korrekte

Verwendung der Strukturen zu verifizieren ist.

Allgemeine XML-Beschreibung bei der Daten-

übertragung zum Drucker und vom Codeleser:

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

Bei der Übertragung vom Codeleser ist der Wert „dfi“

optional.


D.5 Beispiele

An folgenden Beispielen soll unter Verwendung der vier Datenelemente Produktnummer, Chargenbezeichnung,

Verfalldatum und Seriennummer die Anwendung gezeigt werden:

Beispiel 1: Datenübertragung an Drucker – IFA-Format

Produktnummer: PPN Datenbezeichner: DI Data Format Identifier: IFA

System

PPN: 111234567842

Batch: 1A234B5

Verfalldatum: 31.12.2015

Serien-Nr.: 1234567890123456

Codierung: „IFA“

<Content dfi=“IFA“>

<PPN>111234567842</PPN>

<LOT>1A234B5</LOT>

<EXP>151231</EXP>

<SN>1234567890123456</SN>

</Content>

Data Carrier

Mac069N111234567842Gs

1T1A234B5Gs

D151231Gs

S1234567890123456

Drucker

Beispiel 2: Datenübertragung an Drucker – GS1-Format

Produktnummer: GTIN Datenbezeichner: AI Data Format Identifier: GS1

Data Carrier

FNC104150123456782

101A234B5FNC1

17151231

211234567890123456

System

GTIN: 04150123456782

Batch: 1A234B5


Serien-Nr.: 1234567890123456

Codierung: „GS1“

<Content dfi=“GS1“>

<GTIN>04150123456782<GTIN>

<LOT>1A234B5</LOT>

<EXP>151231</EXP>

<SN>1234567890123456</SN>

</Content>

Drucker

Beispiel 3: Datenübertragung vom Codeleser – IFA-Format

Produktnummer: PPN Datenbezeichner: DI Data Format Identifier: IFA

Data Carrier

Mac069N111234567842Gs

1T1A234B5Gs

D151231Gs

S1234567890123456

System

PPN: 1101234567842

Batch: 1A234B5


Serien-Nr.: 1234567890123456

Codele-ser

<Content>

<PPN>111234567842</PPN>

<LOT>1A234B5</LOT>

<EXP>151231</EXP>

<SN>1234567890123456</SN>

</Content>

Beispiel 4: Datenübertragung vom Codeleser – GS1-Format

Produktnummer: GTIN Datenbezeichner: AI Data Format Identifier: GS1

Data Carrier

FNC104150123456782

101A234B5FNC1

1717231

211234567890123456

System

GTIN: 04150123456782

Batch: 1A234B5


Serien-Nr.: 1234567890123456

Codele-ser

<Content>

<GTIN>04150123456782<GTIN>

<LOT>1A234B5</LOT>

<EXP>151231</EXP>

<SN>1234567890123456</SN>

</Content>

Rückfragen und Anregungen zu den in diesem Anhang beschriebenen Festlegungen sind willkommen und an die

IFA GmbH zu richten.


Anhang E Qualität und Kontrolle des Codeinhalts (informativ)

E.1 Data Matrix Code als Punktcodes

In Zusammenhang mit der Mindestqualitätsanforde-

rung an die Druckqualität ist festzuhalten, dass Codes

wie bspw. Punktcodes, deren Druckqualität nach der

Prüfmethodik gemäß ISO/IEC TR 29158 (Direct Part

Marking – Direkte Teilekennzeichnung) gemessen

werden muss, für diese Anwendung nicht zum Einsatz

kommen sollen. Punktcodes sind in der Data Matrix

Norm ISO/IEC 16022 nicht spezifiziert. Standard-

lesegeräte können Punktcodes daher oft nicht lesen

bzw. die Leseraten sind inakzeptabel niedrig. Davon

ausgenommen sind lediglich Punktcodes, deren

einzelne Punkte (Datenzellen) so breit und einander

berührend ausgeführt sind, dass diese gemäß ISO/IEC

15415 prüfbar und damit allgemein lesbar sind.

E.2 Qualifizierungs- und Validierungsmaßnahmen

Die Ausrüstung zum Aufbringen und Kontrollieren von

Codes unterliegt den allgemeinen Vorgaben zur Qualifi-

zierung. Ebenso gelten für die damit in Zusammenhang

stehenden Prozesse die allgemeinen Anforderungen

bzgl. einer Validierung.

Definition und Umfang der Qualifizierungsmaßnahmen

und der Prozessvalidierungen sind nicht Bestandteil

dieser Spezifikation.

E.3 Kontrolle der Codes auf Dateninhalt und Druckqualität

E.3.1 Allgemeine Festlegungen

Ort und ggf. Umfang der Prüfungen zur Lesekontrolle

und der Druckqualität unterscheiden sich, je nachdem,

ob die Packmittel vorbedruckt eingesetzt oder inline

bedruckt werden.

Die Eingangskontrolle für Packmittel muss vorgedruckte

Codes oder Platzhalter für die Anbringung von Codes

bei Umfang und Art der Prüfungen in angemessener

Weise berücksichtigen.

Die erreichbare Druckqualität der Codes hängt vom

verwendeten Substrat, dem Material und Druckverfahren

ab und kann daher deutlich besser als die Mindest-

anforderung sein.

E.3.2 Lesekontrolle

Im Rahmen der Lesekontrolle wird mittels eingebauter

Erfassungssysteme geprüft, ob

• der Code vorhanden ist,

• die korrekte Symbologie verwendet wurde und

• der Inhalt mit den Vorgaben übereinstimmt.

Es wird darüber hinaus sichergestellt, dass nicht

vorhandene oder nicht lesbare oder von den Vorgaben

abweichende Codes ausgeschleust werden.

E.3.3 Druckqualitätskontrolle

Die Druckqualität kann grundsätzlich mit zwei unter-

schiedlichen Verfahren geprüft werden:

1. Mittels Messungen gemäß ISO/IEC 15415 (Näheres

siehe Anhang E.6.1)

2. Mittels eingebauter Erfassungssysteme (Näheres

siehe Anhang E.6.2) mit der Fähigkeit zur Analyse

und Bestimmung der Druckqualität in Anlehnung an

ISO/IEC 15415


E.4 Varianten der Bedruckung

E.4.1 Packmittel mit vorgedruckten Codes

E.4.1.1 Prüfung der Lesbarkeit durch den

Verpacker – Sicherstellung der Druck-

qualität durch den Lieferanten

Die Codes werden durch den Packmittellieferanten

aufgebracht. Er hat sicherzustellen, dass die Codes

grundsätzlich vorhanden und lesbar sind, die festgelegte

Symbologie aufweisen, den definierten Inhalt haben

und die Seriennummern erfasst sind. Weiterhin stellt er

durch geeignete Maßnahmen sicher, dass der Code-

inhalt und die Druckqualität der aufgebrachten Codes

den definierten (Mindest)anforderungen genügen.

Das wird vom Arzneimittel-Hersteller im Rahmen der

Lieferantenqualifizierung geprüft.

Die aufgebrachten Codes werden im Rahmen des

Verpackungsprozesses des Arzneimittels ggf. erneut

eingelesen. In diesen Fällen wird am Ort der Nutzung

eine vollständige Überprüfung des Vorhandenseins

und der Lesbarkeit aller Codes, der Verwendung der

korrekten Symbologie und deren korrekte Inhalte

sichergestellt. Zusätzlich werden die tatsächlich

genutzten Seriennummern erfasst.

E.4.2 Inline Bedruckung von Pack- mitteln ohne vorgedruckte Codes

E.4.2.1 Kontinuierliche Lesekontrolle und

Stichprobenkontrolle der Druckqualität

Die Codes werden inline während des Verpackungs-

prozesses des Arzneimittels auf die Packmittel

aufgebracht. Wie im Anhang E.3.2 beschrieben, wird

durch die Erfassungssysteme jeder Code einer Lese-

kontrolle unterzogen. Auch die Seriennummer jedes

Codes wird erfasst. Bei Bedarf wird gemäß ISO/IEC

15415 zusätzlich die Qualität der aufgebrachten Codes

offline mit einem entsprechendem Prüfgerät kontrolliert

(Näheres siehe Anhang E.6.1).

E.4.2.2 Kontinuierliche Lese- und Stichproben-

kontrolle der Druckqualität

Die Codes werden inline während des Verpackungs-

prozesses des Arzneimittels auf die Packmittel aufge-

bracht. Wie im Anhang E.3.2 beschrieben, wird durch

die Erfassungssysteme jeder einzelne Code einer

Lesekontrolle unterzogen. Auch die Seriennummer

jedes Codes wird erfasst. Abweichend von Anhang

E.4.2.1 wird mittels der Erfassungssysteme inline die

Druckqualität in Anlehnung an ISO/IEC 15415 (Näheres

siehe Anhang E.6.2) jedes Codes kontrolliert.

E.5 Statistik in der Qualitätskontrolle

Die Prüfung der Druckqualität nach ISO/IEC 15415

muss immer im Kontext einer normierten Stichproben-

prozedur nach allgemein anerkannten Regeln der

Statistik durchgeführt werden. Kurz zusammengefasst

bedeutet das: Wenn eine Unterschreitung der Mindest-

druckqualität festgestellt wird, dann sind innerhalb der

Fertigungscharge weitere Produkte zu prüfen. Wenn die

Fehler, bei Anwendung der normierten Stichproben-

prozedur das akzeptable Maß überschreiten, sind

geeignete Maßnahmen zur Korrektur einzuleiten.

Es sind die Stichprobenprozeduren gemäß ISO 2859

und ISO 3951 anzuwenden. In diesen Normen wird eine

definierte statistische Methode beschrieben, die zu der

Beurteilung führt, ob ein Fertigungslos akzeptabel ist

oder nicht. Die Stichprobenmethodik soll den Aufwand

für die Qualitätskontrolle intelligent steuern.

Grundlegend ist dabei, dass im Rahmen dieser statisti-

schen Methode immer eine bestimmte Fehlerquote

zulässig ist.

Die inline Kontrollen der Druckqualität in Anlehnung an

ISO/IEC 15415 (siehe Anhang E.3.3) werden im Kontext

der Stichprobenprozedur als sehr häufige Stichproben-

nahmen betrachtet. Die statistische Methode zur

intelligenten Steuerung der Qualitätskontrolle kann

damit auch für die inline Kontrolle eingesetzt werden.


E.6 Prüfgeräte

E.6.1 Prüfung gemäß ISO/IEC 15415

Die Druckqualität gemäß ISO/IEC 15415 wird mit

entsprechend geeigneten Prüfgeräten (sog. Verifier)

kontrolliert. Die Prüfgeräte müssen die Anforderungen

der internationalen Norm ISO/IEC 15426-2 erfüllen. Die

wichtigsten Anforderungen an ein Messgerät sind:

• Die Kalibrierung muss auf Messstandards rück-

führbar sein (PTB, N.I.S.T).

• Die Messung muss unter definierten Bedingungen

bezüglich Beleuchtung, Abstand und Kamerawin-

kel erfolgen (Vorlage : ISO/IEC 15415 Referenzauf-

bau).

• Umgebungslicht darf die Messung nur innerhalb

der erlaubten Toleranzen gemäß ISO/IEC 15426-2

verändern.

• Es muss eine regelmäßige Kalibrierung der Geräte

beim Anwender erfolgen.

• Es muss eine regelmäßige Kontrolle der Mess-

genauigkeit beim Anwender erfolgen.

• Die Vorgaben der Symbologienorm bezüglich der

Referenzdekodierung muss eingehalten werden,

damit unterschiedliche Dekodieralgorithmen nicht

zu unterschiedlichen Ergebnissen führen.

Die Messung erfolgt offline. Aufgrund des Mess-

aufwandes sind stichprobenhafte Prüfungen üblich.

Eine vollständige, 100%ige Kontrolle ist mit dieser

Messmethodik nicht realistisch darstellbar.

Lesegeräte wie bspw. handelsübliche Barcodescan-

ner dürfen den für Prüfgeräte geltenden Restriktionen

nicht unterworfen werden, weil Lesegeräte unter mög-

lichst beliebigen Bedingungen bezüglich Leseabstand,

Lesewinkel, Beleuchtungswinkel und Umgebungslicht-

einflüssen die Codes erfassen müssen. Die definierte

Mindestdruckqualität unterstützt dies.

Es verbleibt ein geringes Restrisiko, dass - bedingt durch

die Messung der Druckqualität als Konventionsmethode -

wiederholte Messungen des gleichen Codes zu gering-

fügig abweichenden Messergebnissen führen. Dies gilt

auch, wenn dieselben Codes mit unterschiedlichen

Verifiern geprüft werden. Wenn auch nach der aktuell

gültigen technischen Norm gemessen wird, ist, bedingt

durch den Messaufwand und den Einsatz offline, nur eine

stichprobenhafte Prüfung der Druckqualität möglich.

E.6.2 Prüfung angelehnt an ISO/IEC 15415

Viele Erfassungssysteme für die Lesekontrolle (siehe

Anhang E.3.2) haben die Fähigkeit, die Druckqualität

kontinuierlich inline zu analysieren und zu prüfen. Es

handelt sich um eine Prüfung, die sich an die ISO/

IEC 15415 Methode anlehnt und die häufig, alterna-

tiv zur offline Prüfung gemäß ISO/IEC 15415 (siehe

Anhang E.3.3) eingesetzt wird. Diese Systeme nutzen die

gleichen für die Prüfung der Druckqualität in der ISO/IEC

15415 definierten Kriterien. Allerdings sind die dort fest-

gelegten Randbedingungen wie bspw. die Wellenlänge

und Einstrahlwinkel der verwendeten Lichtquelle oder

Mehrfachprüfung des Codes aus unterschiedlichen

Winkeln bauartbedingt, u. a. durch die Integration in die

Verpackungslinie, nicht zu gewährleisten.

Die, in Anlehnung an die ISO/IEC 15415, erhaltenen

Ergebnisse sind im Rahmen der Qualifizierung der Druck-

und Erfassungssysteme mit den Messergebnissen

eines sog. Verifiers (siehe Anhang E.6.1) zu korrelieren.

Erfassungssysteme mit einer Prüfung, in Anlehnung an

die ISO/IEC 15415 Methode, stellen eine vollständige,

100%ige inline Kontrolle (Lesekontrolle und Druck-

qualitätskontrolle) jedes einzelnen Codes sicher.

Es verbleibt ein geringes Restrisiko, dass das Erfassungs-

system primär als Lesegerät konstruiert ist, das auf best-

mögliche Leseergebnisse optimiert ist z.B. adaptive

Beleuchtungen, Autofocus- und Autozoom-Objektive

oder für die Lesung optimierte Dekodieralgorithmen. In

diesem Fall kann das Erfassungssystem, trotz Abgleich

mit dem Messergebnissen nach ISO/IEC 15415, fallweise

abweichende Qualitätsergebnisse liefern.


E.7 Farben und Materialien

Erlaubte Farben und Trägermaterialien:

• Das Trägermaterial muss eine gleichmäßig diffus

reflektierende Oberfläche haben. Oberflächen, die

stark spiegelnd sind (metallisch, Metalliceffekte),

sind ungeeignet. Raue oder geprägte Oberflächen

sind ebenfalls schlecht geeignet. Die folgenden

farblichen Vorgaben ergeben sich aus der Annah-

me, dass handelsübliche Lesegeräte mit Rotlicht

beleuchten.

• Trägermaterialfarbe: Weiß, rot, gelb oder orange

(hell unter Rotlicht).

• Modul- bzw. Codefarbe: Schwarz, blau oder grün

(dunkel unter Rotlicht).

• Negative Data Matrix Symbole, bei denen die

Trägermaterialfarbe und die Modul bzw. Codefarbe

vertauscht werden, sind erlaubt.

• Bei den Beschriftungsverfahren im Tintenstrahl-

druck ist ggf. auf Faltschachteln eine entsprechen-

de Aussparung der Oberflächenbeschichtung erfor-

derlich, damit die Beschriftung haftet und trocknet.

Die Mindestqualitätsanforderung (siehe Kapitel 5.8) legt

u.a. den Mindestkontrast fest und damit auch die Spiel-

räume für farbige Codes.

E.8 Qualitätskriterien nach ISO/IEC 15415 mit Bezug auf ISO/IEC 16022

Nachfolgend sind die wichtigsten in der Norm

enthaltenen Prüfparameter aufgelistet und kurz

beschrieben:

Dekodierung – Referenzdekodierung und Code-

aufbau (Fehler siehe Anhang F.1 und Anhang F.1.9 und

Anhang F.2).

Symbolkontrast – Kontrast zwischen der hellsten und

dunkelsten Reflexion im gesamten Symbol (Fehler siehe

Anhang F.1.1).

Modulation – Gleichmäßigkeit der Reflexionen der

hellen Module jeweils zueinander sowie die Gleich-

mäßigkeit der Reflexionen der dunklen Module jeweils

zueinander.

Reflexionsbereich – wie Modulation, nur die durch die

Fehlerkorrektur zu korrigierenden Codeworte werden

hier als Grad 0 (= durchgefallen) in die Entscheidungs-

matrix einbezogen.

Kontrastgleichmäßigkeit – Es werden MOD Werte für

alle Codewörter bestimmt. Die MOD Werte werden für

die Bestimmung der Modulation und des Reflexions-

bereiches verwendet. Die Kontrastgleichmäßigkeit ist

der schlechteste MOD Wert (informativ).

Fehler zu Modulation, Reflexionsbereich und Kontrast-

gleichmäßigkeit siehe unter:

Anhang F.3.2.3 und

Anhang F.3.2.4 und

Anhang F.3.2.9 und

Anhang F.3.3.2 und

Anhang F.4.1 und

Anhang F.4.5.

Unused Error Correction (UEC) – Nicht benutzte

Fehlerkorrektur d.h. je größer der Wert ist umso weniger

müssen Fehler korrigiert werden (Fehler siehe Anhang

F.3.1.2).

Axial Non-Uniformity (AN) – wie stark ist das Symbol

in x oder y Achse gestreckt oder gestaucht (Fehler siehe

Anhang F.3.1.3).

Grid Non-Uniformity (GN) – wie stark ist das idealer

weise gleichmäßige, schachbrettartige Modulgitter in

sich verzerrt ohne nach außen als AN in Erscheinung

zu treten (Fehler siehe Anhang F.3.1.4).

Fixed Pattern Damage (FPD) – Alle Teile des Codes,

die keine Daten und keine Fehlerkorrekturwerte

enthalten, werden auf Beschädigung überprüft. Dies ist

das L Muster zur Codeorientierungsbestimmung, das

Taktmuster zur Gitterrekonstruktion und die Ruhezone.

Kontrastungleichmäßigkeiten, die im Datenbereich als

Modulation bewertet werden, werden hier für die festen

Muster mit einbezogen (Fehler siehe Anhang F.3.2.1).

Druckzuwachs – informativer Parameter der angibt,

ob ein Symbol überdruckt oder unterdruckt ist (Fehler

siehe Anhang F.3.2.2 und Anhang F.3.2.3).


Modulgröße – Die Größe einer Matrixzelle des

Gesamtcodes wird als Modulgröße bezeichnet. Von

der Modulgröße hängen die Lesegeräteeigenschaften,

bezüglich der Scannertiefenschärfe, der Scannerauf-

lösung und des Mindestleseabstandes ab (siehe An-

hang I.1).

Matrixgröße – Der gesamte Code baut sich aus

einzelne Matrixzellen (= Module) einer bestimmten,

identischen Modulgröße auf. Die Norm ISO/IEC 16022

definiert als kleinste Matrixgröße 10x10 Module und als

maximale Matrixgröße 144x144. In praktischen Anwen-

dungen wird der Bereich der erlaubten Matrixgrößen

eingeschränkt, um das Verhältnis der Kameraauflö-

sung zur Größe der Matrix zu begrenzen und um eine

ausreichend große Anzahl von Kamerapixeln pro Modul

zur Verfügung zu haben. Dies ist für die Lesesicherheit

erforderlich (siehe Anhang I.2).

Anhang F Typische Fehler (informativ)

In diesem Anhang werden typische Fehler, unterteilt

nach Fehlern in der Datenstruktur, dem Dateninhalt und

in dem Druck beschrieben.

Diese Auflistung soll helfen, die Fehler bei der Generie-

rung des Codes zu vermeiden und den Programmierern

von Verarbeitungssoftware Anhaltspunkte geben, mit

welchen Fehlern zu rechnen ist, um daraus entspre-

chende Fehlerreaktionen zu implementieren.

F.1 Fehler in den Datenstrukturen

F.1.1 FNC1 als Startsequenz anstelle von Macro 06

Erklärung: Die bei der PPN verwendete Datenstruktur

verwendet als Datenidentifikator keine GS1 „Application

Identifier“ (AI), sondern „Data Identifier“ (DI). In diesem

Fall darf das FNC1 Zeichen nicht verwendet werden,

weil es kennzeichnet, dass eine GS1 Struktur folgt.

Stattdessen ist das Macro 06 Codewort die korrekte

Wahl anstelle von dem FNC1 zur Kennzeichnung, dass

die DI Datenstruktur verwendet wird.

F.1.2 Macro 05 anstelle von Macro06 verwendet

Erklärung: Das Macro 05 ist ebenfalls eine Kennzeich-

nung der GS1 AI Struktur und darf nicht anstelle von

Macro 06 eingesetzt werden.


F.1.3 FNC1 als Feldtrenner anstelle von GS (ASCII 29)

Erklärung : In der PPN werden mehrere Datenfelder

nacheinander verwendet. Um zu erkennen, wann ein

Datenfeld endet und das nächste Element beginnt ist

ein Feldtrennzeichen erforderlich. Im Falle von GS1

Datenstrukturen wird immer ein FNC1 Zeichen kodiert,

das der Lesegerätedecoder durch ein GS Zeichen

ersetzen muss. Im Falle der PPN muss das GS Zeichen

immer direkt kodiert werden, und eine Übersetzung ist

damit nicht mehr erforderlich. Die Übersetzung der

FNC1 Zeichen als Feldtrenner darf nur vorgenommen

werden, wenn der Code mit dem FNC1 Zeichen an der

ersten Position als Code mit GS1 Datenstruktur identifi-

ziert wurde.

F.1.4 Macro 06 fehlt

Erklärung: Die PPN verwendet das „Message envelo-

pe“ gemäß ISO/IEC 15434. Das Macro 06 muss

verpflichtend als erstes Zeichen kodiert werden, um die

Bildungsvorschrift der PPN korrekt einzuhalten und um

den nachgeschalteten Programmen eine zusätzliche

Plausibilitätskontrolle und eindeutige Unterscheidungs-

möglichkeit zu anderen ISO konformen Datenstrukturen

zu ermöglichen.

F.1.5 Data Identifier (DI) und Application Identifier (AI) gemischt verwendet

Falscher Datenidentifikator für Charge AI „10“

anstelle von DI „1T“

Datum mit AI „17“ anstelle von DI „D“ kodiert

Die Seriennummer ist mit AI „21“ anstelle von DI

„S“ kodiert

Es wird die AI „01“ (für GS1 GTIN) anstelle von DI

„9N“ für die PPN verwendet


F.1.6 Falsche Data Identifier (DI) verwendet

Es wird für das Verfalldatum DI „14D“ verwendet. Im

Kontext der PPN soll immer DI „D“ für das Verfalldatum

verwendet wird. Es handelt sich hier um keinen harten

Fehler, sondern um einen Fall, der in dieser Spezifikati-

on ausgeschlossen wird, um die Variantenvielfalt zu

begrenzen und um bei parallelen Einsatz der französi-

schen C.I.P. Kodierung und der PPN Kodierung das

gleiche Datumsformat YYMMDD einsetzten zu können

(14D hat YYYYMMDD).

Es wird für die PPN der DI „25P“ verwendet zusammen

mit dem IAC Code PP, der der IFA zugeordnet ist. Diese

Variante ist im allgemeinen ISO Kontext nicht erlaubt. Im

Rahmen der PPN Anwendung soll diese Variante nicht

verwendet werden weil „25P“ nach dem IAC Code PP

eine Code für die Firmenidentifizierung (Company Iden-

tification Code - CIN) verlangt und danach eine

Artikelnummer.

F.1.7 Feldtrenner GS bei Datenfeldern mit fixer Länge fehlt

Die der PPN zugrundeliegende DI Definition gemäß

ISO/IEC 15418 verlangt nach jedem Datenfeld einen

Feldtrenner (GS). Die GS1 Struktur verwendet eine

Ausnahmebehandlung bei einigen Datenfeldern mit

fester Länge. Diese Ausnahme erlaubt es keinen Feld-

trenner bei bestimmten Datenfeldern zu benutzen.

Diese Variante ist hier mit der PPN umgesetzt.

Die Felder mit fester Länge sind nicht mit dem

Feldtrenner GS abgeschlossen.

F.1.8 Falsche Fehlerkorrektur

In diesem Beispiel ist die PPN Struktur korrekt. Die

Codevariante ist falsch. Es muss der Data Matrix Code

mit der Reed Solomon Fehlerkorrektur, die als ECC200

bezeichnet wird, benutzt werden. Hier kommt der Data

Matrix Code mit der Fehlerkorrektur ECC040 zum

Einsatz (CRC Fehlerkorrektur). Die Data Matrix Norm

ISO/IEC 16022 rät vom Einsatz dieser Variante ab

(Grund veraltet und Fehlerkorrektur weniger Leistungs-

fähig). Diese PPN Spezifikation erlaubt nur die ECC200

Version.

F.1.9 Code mit falschen Füllzeichen (pad character)

Die Änderung der Matrixgröße geht immer mit einem

Sprung in der Datenkapazität von z.B. 52 auf 64 alpha-

numerische Zeichen einher. Wenn z.B. 56 Zeichen

benötigt werden, dann muss die Matrixgröße mit der

Kapazität von 64 Zeichen benutzt werden. Die freie

Kapazität des Codes wird mit den Füllzeichen aufge-

füllt.


F.2 Fehler in den Dateninhalten

F.2.1 Prüfziffer PPN falsch

Die PPN Bildungsvorschrift verlangt eine Prüfziffer nach

Modulo 97 in dem Datenfeld „9N“ als Abschluss (siehe

Anhang B). In diesem Beispiel ist eine falsche Prüfziffer

kodiert worden.

F.2.2 Prüfziffer PPN fehlt

Erklärung: Die Prüfziffer, die über den PRA-Code (11

bei der PPN) und der folgenden PZN-8 gebildet wird

fehlt. Da das Datenfeld durch den Trenner GS abge-

schlossen ist und die Prüfziffer der PZN-8 korrekt ist, ist

dieser Fehler leicht zu erkennen.

F.2.3 PZN Prüfziffer falsch

Die PPN bettet eine PZN-8 Nummer mit dem Identifier

„9N“ in eine international eindeutige Datenstruktur ein.

In diesem Fall wurde eine PZN mit einer falsch berech-

neten Prüfziffer eingesetzt und dann eine PPN Prüfziffer

berechnet, die den Fehler mit einbezieht und damit

richtig erscheint.

F.2.4 PZN Prüfziffer fehlt

Die Prüfziffer des PZN Codes fehlt und die darauf

folgende PPN Prüfziffer wurde über eine Stelle zu wenig

berechnet.

F.2.5 PRA-Code falsch / nicht plausibel

Das System der PPN erlaubt es, dieses System mit

einer Vielzahl von Anwendungen zu benutzen. Die PPN,

die die PZN-8 Nummer einbettet wird immer mit dem

PRA-Code 11 nach dem DI „9N“ gekennzeichnet.

Andere PRA-Codes sind möglich dürfen aber nie eine

PZN-8 Nummer kodieren.

F.2.6 PRA-Code fehlt

In diesem Beispiel ist der PRA-Code 11 nicht vorhan-

den. Nach „9N“ kommt direkt die PZN-8 Codierung.

Da davon ausgegangen wird, dass der Fehler unbeab-

sichtigt gemacht wurde, stimmt die PPN Prüfziffer

bezogen auf den vorhandenen Dateninhalt.


F.2.7 Datum falsch

In diesem Beispiel liegt beim Datum der Wert für den

Monat nicht im Bereich von 1 bis 12.

F.2.8 PZN 7 verwendet

In der PPN muss immer eine PZN 8 verwendet werden.

Dieses Beispiel benutzt eine alte PZN 7 Nummer. Um

aus einer PZN-7 eine PZN-8 zu machen, wird dem

Code eine 0 (Null) vorangestellt.

F.2.9 PZN-8 aus PZN-7 falsch erzeugt

In diesem Beispiel wurde die 0, die die PZN-7 auf eine

PZN-8 auffüllt, hinten angehängt und nicht als erste

Ziffer vorangestellt.

F.3 Fehler im Druck

Die in diesem Kapitel gezeigten Codes dienen zur

Illustration der Fehler, die bei der Bedruckung entstehen

können. Die Codeinhalte sind willkürlich gewählt.

F.3.1 Allgemeine Druckfehler

F.3.1.1 Unzureichender Symbolkontrast

a) Symbolkontrast gut

b) Symbolkontrast schlecht weil der Hintergrund

nicht weiß ist

c) Symbolkontrast schlecht weil die Beschriftung

grau anstelle von schwarz ist

F.3.1.2 Zu hell gedruckte Module – Niedrige

UEC

Die roten Punkte erscheinen unter Rotlicht weiß. Es sind

aber Teile der Matrix die schwarz sein sollten. Die Fehler

werden durch die Unbenutzte Fehlerkorrektur bewertet,

da die Fehlerkorrektur die korrekte Dekodierung trotz

der Fehler erlaubt.


F.3.1.3 Axial Nonuniformity (AN)

a) Symbol in Y-Richtung Axial verzerrt

b) Symbol in X-Richtung Axial verzerrt

F.3.1.4 Grid Nonuniformity (GN)

Zwei Beispiele mit einem verzerrten Gitter ohne die

äußere quadratische Form des Symbols zu ändern

F.3.2 Druckverfahren Bubble-Jet

Ein Heizelement in der Düse erzeugt eine Dampfblase,

die den Tintentropfen herausschießt

F.3.2.1 Düsenausfälle im Inkjetdruck

Einzelne Düsen des Druckers sind verstopft und führen

zu Linien im Code. Der Druckkopf muss ersetzt oder

gereinigt werden. Die Reinigung sollte nach den Her-

stellervorgaben vorgenommen werden.

F.3.2.2 Code zu fett gedruckt

Durch zu viel Tinte, zu starkes Saugverhalten des Mate-

rials oder durch eine falsche Druckeinstellung können

die Codes zu fett gedruckt werden. Abhilfe schafft z.B.

eine Pixelreduktion.

F.3.2.3 Code zu dünn gedruckt

Die Druckereinstellung ist falsch.

F.3.2.4 Unregelmäßiges Druckbild

Das unregelmäßige Druckbild kann mehrere Ursachen

haben. Die Düsenplatte kann verschmutzt sein. Der

Abstand des Druckkopfes vom zu beschriftenden

Material kann zu groß sein. Der Druckkopf kann eine

statische Aufladung haben, die einen Teil der Tinten-

tropfen wieder zum Kopf zurückzieht.


F.3.2.5 Schatten im Druckbild

Die Schattenbilddung im Druckbild wird durch eine

falsche Geschwindigkeitseinstellung hervorgerufen. Der

Druckkopf hat mehrere Düsenreihen die mit dem rich-

tigen Zeitverhalten die Tintentropfen abgeben müssen.

Wenn die Tintentropfen zum falschen Zeitpunkt kom-

men, führt dies zu den Schattenbildungen die hier links

neben den Matrixelementen zu sehen sind.

Zusätzlich besteht die Möglichkeit, dass der Druckkopf

verschmutzt ist, statisch aufgeladen ist und dass der

Abstand zu groß ist.

Das folgende Beispiel zeigt als ausgeprägtes Merkmal

die Schattenbildung durch die falsche Geschwindig-

keitseinstellung.

F.3.2.6 Falsche Tinte

Durch eine falsche Tintenauswahl wird ein schlechtes

Anschreibverhalten verursacht. Dies ist daran zu erken-

nen, dass bei jedem Druckstart die vertikalen Linien auf

der linken Seite unregelmäßig und ausgefranst

erscheinen.

F.3.2.7 Druck ohne Weggeber (Produkt-

geschwindigkeit beim Druck unbekannt

und variabel)

Der Code ist verzerrt. Es können Axiale Verzerrungen

auftreten (Symbol erscheint nicht mehr quadratisch).

Bei Schlupf oder Betrieb ohne Drehgeber können die

einzelnen Matrixspalten bzw. Zeilen (je nach Druckrich-

tung) unterschiedlich breit erscheinen. Dies hat eine

Gitterverzerrung zur Folge.

F.3.2.8 Druck mit Tinte für saugfähige Materi-

alien auf lackierter Faltschachtelober-

fläche (oder Metall oder Kunststoff)

In diesem Fall kann die Tinte nicht schnell genug trock-

nen und verwischt. Erschwerend kommt in diesem Fall

dazu dass das Teil zum Bedrucken gewölbt ist.

F.3.2.9 Druck auf einer sehr stark saugenden

Oberfläche

Die Tinte verläuft sehr stark im Material (Löschpapier-

effekt), Dadurch So werden die Druckelemente viel

dicker als das normalerweise zu erwarten wäre. Abhilfe

kann man durch eine Pixelreduktion und ggf. durch eine

schneller trocknende Tinte schaffen.


F.3.3 Druckverfahren Continuous Ink-Jet (CIJ)

(ein kontinuierlicher Strom aus Tintentropfen wird elektro-

statisch abgelenkt)

F.3.3.1 Druck als Dot Code

In diesem Fall sind die einzelnen Punkte zusammen-

geschoben. Damit wird ein Druckbild erreicht, dass

auch als normaler gedruckter Code und nicht als DPM

Code benutzt werden kann.

F.3.3.2 Code verzerrt

Bei diesem Code sind die Punkte der Matrix nicht kor-

rekt positioniert. Die Druckkopf hat einen zu großen

Abstand zum Druckmuster und / oder die elektrostatische

Ablenkung der Tintentropfen in die richtige Position

ist unzureichend.

Wenn diese Fehler korrigiert werden und der Code nicht

mehr verzerrt ist, dann bleibt der Code ein DPM Code,

weil die Punkte in der Matrix einzeln stehen. Wenn solche

Drucker eingesetzt werden, sollte er so eingestellt

werden, dass das Druckbild aus dem vorhergehenden

Anhang F.3.3.1 entsteht.

F.3.3.3 Druckverfahren Laserdirektbeschriftung

Mit Hilfe eines starken Lasers wird das Beschriftungs-

material in der Farbe verändert (Farbumschlag) oder es

wird aufgedruckte Farbe entfernt.

Mögliche Fehlerquellen:

• Farbe mit Laser nicht vollständig entfernt

• Laser zu stark eingestellt

• Druck als Dotcode

• Falsche Farbkombination (für Rotlichtscanner)

F.3.4 Druckverfahren Thermotransfer

Es wird Farbe von einem Farbband mit Hilfe von Hitze

auf das Produkt direkt gedruckt oder es wird indirekt

mit einem Etikett gearbeitet.

Mögliche Fehlerquellen:

• Nicht wischfestes Thermotransferband

• Temperatureinstellung zu hoch

• Temperatureinstellung zu niedrig

• Geschwindigkeit zu hoch

• Andruck des Druckkopfes (Kopfleiste) zu niedrig

• Ausfall von Heizelementen

• Falten im Farbband

• Farbband pendelt

• Etikettenposition pendelt

• Zu dicht am Rand gedruckt


F.4 Materialbedingte Fehler

F.4.1 Druck auf durchscheinenden Kunststoff

In diesem Fall wurde ein Code auf einem Kunststoffma-

terial gedruckt. Der Kunststoff ist durchscheinend. Da-

mit kann relativ viel Licht tief in das Material eindringen

und von dort wieder partiell zurück reflektiert werden.

Der daraus entstehende Effekt ist die scheinbare Schat-

tenbildung an den Rändern der Beschriftung. Das liegt

darin begründet, dass in den großen unbedruckten

Flächen mehr Licht aus dem Material reflektiert wird als

in den kleinen unbedruckten Strukturen.

F.4.2 Deckweiß auf transparenter Kunststofffolie zu dünn

Wenn ein Code auf eine dünne Folie gedruckt wird, die

vorher weiß bedruckt wurde, entstehen zwei Effekte.

Wenn sich unter der Folie ein Hohlraum befindet bzw.

die Folie auf schwarzem Untergrund liegt, wird alles

Licht, dass die dünnen weiße Schicht passiert, absor-

biert. Der Code verliert an Kontrast.

Wenn sich die Folie auf hellem Untergrund befindet,

wird das durchgedrungene Licht von der hellen Fläche

reflektiert. Die Reflexion wird ungleichmäßig und zeigt

das gleiche Bild wie im Anhang F.4.1.

F.4.3 Druck auf spiegelndem Metall

Die spiegelnde Metalloberfläche verursacht unregel-

mäßige Ausleuchtungen, die vom Winkel der

Beleuchtungsquelle (Scanner) zum Code abhängen. Es

erscheinen partielle Spiegelungen, die selbst dunkle

Codeteile weiß erscheinen lassen.

Dieser Fall ist ein typischer DPM Code. Für die

Anwendung als IFA Produkt Code ist das nicht zuge-

lassen, weil zum Lesen spezielle DOME Beleuchtungen

erforderlich sind (sehr diffuse, ungerichtete Beleuch-

tung, die alle Spiegelungen und Winkelabhängigkeiten

vermeidet).

F.4.4 Code auf Rasterdruck

Wenn ein Code auf einer Rasterfläche gedruckt wird

(hier schwarze, gelbe und blaue Punkte, wobei die Ras-

terfläche für das menschliche Auge in der Summe grün

erscheint) stören diese Punkte die Codes. Je größer die

Modulgröße des Codes in Relation zur Rastergröße ist,

umso besser lässt sich das Raster durch Filtern entfer-

nen (Aufnahme stark vergrößert).


F.4.5 Code unter einer transparenten Folie

Wenn über den Codedruck eine Folie liegt, muss diese

Folie eng anliegen. Es dürfen keine Luftblasen zwi-

schen Code und Folie sein. Schweißnähte, Falten und

Beschriftungen auf der Folie sind an der Position des

Codes verboten.

Anhang G Layout – Best Practice

(informativ)

Diese Beispiele zeigen, wie auch bei kleiner zur

Verfügung stehender Fläche der Code und der Klartext

dargestellt werden können:

Anhang H Bubble-Jet – Best Practice

(informativ)

Diese Drucksysteme basieren typischerweise auf

einem Kartuschensystem mit integriertem Druckkopf.

Andere, ähnliche Drucksysteme benutzen Druckköpfe,

die vom Tintenvorrat getrennt sind. Diese Drucksysteme

weisen alle eine bestimmte Auflösung auf (z.B. 300,

600, 720 dpi). Des Weiteren werden die Druckpunkte

überlappend gedruckt, um eine Kantenglättung zu

erzeugen. Teilweise kann durch die Tintenmenge und/

oder Tintenart die Schwärzung des Druckes beeinflusst

werden.

Diese Variablen müssen in der Druckereinstellung

berücksichtigt werden. Es ist von Vorteil, wenn das

Drucksystem nur solche Codegrößeneinstellungen

zulässt, die verzerrungsfrei gedruckt werden können.

Wenn die Abstufung der Codegröße, die durch die

Druckerauflösung erzwungen wird, nicht beachtet wird,

werden die Druckfehler mit sinkender Auflösung (notwen-

dig bei höherer Geschwindigkeit) immer gravierender.


Anhang I Data Matrix Code – Symbologiebeschreibung (informativ)

Den Data Matrix Code in der modernen Variante

ECC200 gibt es in einer quadratischen und in einer

rechteckigen Version.

I.1 Modulgrößen

Mit Modulgröße ist die Dimension einer Matrixzelle des

Gesamtcodes bezeichnet. Diese ist im Rahmen der in

Kapitel 5.2 genannten Dimensionen frei skalierbar und

wird von der in der Applikation verwendeten Druck- und

Lesetechnik bestimmt.

Beispiele identischer Codes in verschiedenen

Modulgrößen:

I.2 Matrixgröße

Die Matrixgröße ist bestimmt durch die Anzahl der

Module. Nach ISO/IEC 16022 ist die minimale Größe

der quadratischen Version ist eine Matrix von 10x10

Modulen und die maximale Größe ist 144x144 Module.

Die rechteckige Version beginnt mit der Matrixgröße

8x16 und geht bis maximal 16x48 Module. Im Kapitel

5.2 sind die für die PPN vorgesehenen Matrixgrößen

beschrieben.

Beispiel Matrixgröße 32x32 Module:





I.3 Feste Muster

Der Data Matrix Code besteht aus festen Mustern (Fixed

Pattern) und aus dem Bereich für die kodierten Daten.

Der rot markierte Teil des festen Musters wird auch als

„L“ bezeichnet. Anhand des Musters wird die Orientie-

rung des Codes im Bild bestimmt.

Der rot markierte Teil des festen Musters wird als Takt-

muster bzw. als Clock Track bezeichnet. Das Taktmuster

zeigt die Matrix des Codes an.

Die rot markierten Bereiche des festen Musters treten

nur bei Codes ab einer Matrixgröße von 32x32 Modulen

auf. Die oben gezeigten L- und Taktmuster werden im

Code wiederholt.

Die rot markierte Umrandung des Codes ist die kleinste

erlaubte Ruhezonenbreite. Die Breite ist eine Matrixzeile

bzw. Spalte. Es wird empfohlen, die 3-fache Breite in

der Praxis zu verwenden.

I.4 Datenbereich

Die rot markierten Bereiche zeigen den Datenbereich

des Data Matrix Codes an. In diesem Bereich befinden

sich die Codewörter für die Daten und für die Fehler-

korrektur. Symbole bis zu einer Matrixgröße von 26x26

Modulen weisen nur ein rotes Datensegment auf.

I.5 Füllzeichen

Die im Kapitel 5.2 gezeigte Tabelle mit den beiden

quadratischen Codeversionen 26x26 und 32x32

Modulen beinhalten 44 bzw. 62 Codewörter für die

Daten. Wenn z.B. die kodierten Daten 48 Codewörter

benötigen, reicht die Kapazität der 26x26 Matrix dafür

nicht mehr aus. Es muss die 32x32 Matrix mit 62 Code-

wörtern eingesetzt werden. Die Differenz zwischen der

Kapazität von 62 Codewörtern und den benötigten

48 Codewörtern wird mit Füllzeichen aufgefüllt (Pad

Character). Das Auffüllen muss in einem festgelegten

Schema vorgenommen werden, das in der Data Matrix

Norm ISO/IEC 16022 definiert ist.

Wenn in der Anwendung immer eine feste Matrixgröße

von z.B. 26x26 Modulen verwendet werden soll, obwohl

manchmal auch 22x22 Module oder 24x24 Module

ausreichend wäre, muss die überschüssige Kodier-

kapazität mit den Füllzeichen aufgefüllt werden.

Wenn mit (Scanner)lesbaren Daten aufgefüllt

wird, ist die Datenstruktur zerstört und der Code

unbrauchbar.


I.6 Fehlerkorrektur

Die Fehlerkorrektur des Data Matrix Codes ist in der

Data Matrix Norm ISO/IEC 16022 definiert . Es wird das

Reed Solomon Verfahren dafür eingesetzt.

Zu beachten ist, dass das Verfahren der Fehler-

korrektur auf den Codewörtern und nicht auf den

Einzelzellen der Matrix beruht.

Im Bild ist ein Codewort, bestehend aus 8 Matrixzellen,

dargestellt. Jede Matrixzelle ist in dem Bild durch das

rote Schachbrettmuster hervorgehoben. Wenn eine

Matrixzelle hell statt dunkel ist, dann ist das Codewort

zerstört. Wenn alle Matrixzellen die falsche Farbe ha-

ben, bleibt es bei einem zerstörten Codewort. Wenn

eine Teilfläche des Codes zerstört ist, sind damit die

Codewörter betroffen, die in diesem Bereich liegen.

Aber selbst die Daten aus relativ groß erscheinenden

defekten Bereichen (zusammenhängend) können

durch die Fehlerkorrektur rekonstruiert werden. Handelt

es sich aber zwar um kleine zerstörte Matrixstellen, die

jedoch über das gesamte Symbol zufällig verteilt sind,

sind sehr viele Codewörter betroffen und die Fehlerkor-

rekturfähigkeit stößt viel eher an die Grenzen.


Anhang J Glossar

Grundsätzlich gelten die Begriffe und Definitionen der

ISO/IEC 19762 Teil 1 und Teil 2. Im folgenden aufgeführt

sind die in diesem Dokument verwendeten Begriffe und

Abkürzungen

• AMG: Zweck des Arzneimittelgesetzes (AMG) ist es,

im Interesse einer ordnungsgemäßen Arzneimittel-

versorgung von Mensch und Tier für die Sicherheit

im Verkehr mit Arzneimitteln, insbesondere für die

Qualität, Wirksamkeit und Unbedenklichkeit der

Arzneimittel nach Maßgabe der im AMG enthaltenen

Vorschriften zu sorgen (s. § 1 AMG).

• Application Identifier (AI): Durch die Anwender

von GS1 entwickelte numerische Datenbezeichner,

die in dem Standard ANSI MH10.8.2 (normative

Referenz: ISO/IEC 15418) gelistet sind.

• BARCODE: Optischer Datenträger aus Strichen

bestehend (auch Strichcode genannt). Umgangs-

sprachlich werden 2-dimensionale Matrixcodes u.a.

als 2D Barcodes bezeichnet. Dazu zählt auch der

Data Matrix Code.

• Code 39: Ein Barcode bzw. Strichcodetyp der in

der ISO/IEC 16388 spezifiziert ist. Der Platzbedarf

dieses Codes ist, bei vergleichsweise geringen

Datenmengen, groß.

• Codierregeln securPharm: Steht als Kurzform

für das Dokument „Regeln zur Codierung verifizie-

rungspflichtiger Arzneimittel im deutschen Markt“.

Siehe http://www.securpharm.de/fileadmin/pdf/

Pharmahersteller/2013-01-11_securPharm_Regeln_

Codierung_DE_V1_02%5B1%5D.pdf

• Continous Ink-Jet (CIJ): Damit wird ein Tinten-

strahldruckverfahren bezeichnet. Typischerweise

erzeugt dieses Druckverfahren Dotcodes, die hier

im Glossar erwähnt werden. Das Druckverfahren

erzeugt einen ständig laufenden Strahl aus Tinten-

tropfen, der elektrostatisch abgelenkt wird. Dabei

verdunstet Lösemittel. Aufgrund des hohen Löse-

mittelanteiles trocknet und haftet die Tinte sehr gut

auf allen nicht saugenden Oberflächen. Die Auflö-

sung ist niedrig.

• Data Matrix Code: Zweidimensionaler Matrixcode

der aus quadratischen Elementen besteht. In der

Ausführung ECC 200 nach ISO/IEC 16022 beinhaltet

der Code eine Fehlerkorrektur für fehlende Punk-

te oder beschädigte Stellen. Die gleichfarbigen,

benachbarten Elemente des Codes sollen ohne

Unterbrechung direkt ineinander übergehen.

• Datenidentifikator: Der Begriff wird in diesem

Dokument übergeordnet für Data Identifier (DI) und

Application Identifier (AI) verwendet. Dateniden-

tifikatoren sind eindeutige Bezeichner für Daten-

elemente in Datencontainern (Datenträger) wie

z.B. Barcode, 2-D-Code, oder RFID und in offenen

Systemen zur sicheren Interpretation der Daten-

elemente unerlässlich.

• Data Identifier (DI): Von dem „ASC MH 10

Data Identifier Maintenance Committee“ vergebene

Datenidentifikatoren, die in dem Standard ANSI

MH10.8.2 (normative Referenz: ISO/IEC 15418)

gelistet sind. Der Datenidentifikator schließt immer

mit einem Alphazeichen ab. Diesem kann, zur

Unterscheidung von Varianten, eine ein-, zwei- oder

dreistellige Zahl vorangestellt sein.

• Datenträger: Der Begriff Datenträger ist eine

allgemeine Beschreibung für ein beliebiges Medi-

um, das Daten aufnehmen bzw. speichern kann. Im

Idealfall ist es für den Datenträger völlig gleichgültig,

welche Art von Daten auf ihm gespeichert werden.

Zu den Datenträgern gehören zum einen Festplatten,

CD-ROM, DVD und USB-Sticks. Zum anderen

werden im Bereich der automatischen Identifikation

als Datenträger RFID Transponder, OCR Schriftar-

ten, Strichcodes und Matrixcodes eingesetzt.

• DFI – Data Format Identifier: Definiert welche

Ausprägungen der Code nach den ISO-Standard

enthält. Darüber ist festgelegt, welche Datenhülle

nach ISO/ IEC 15434, welche Datenidentifikatoren

(AI oder DI), ob ein Makro nach ISO/IEC 16022 und

welche Syntax zu verwenden ist. Derzeit sind als

Wert für den DFI „IFA“ oder „GS1“ definiert.

• Dotcode: Es handelt sich dabei um zweidimen-

sionale Codes, die typischerweise aus runden und

einzeln stehenden Punkten aufgebaut sind. Die

Data Matrix Norm spezifiziert keine Dotcode Variante.

In der Praxis gibt es aber viele Dotcode Data Matrix

Anwendungen. Es werden dafür Scanner benötigt,

die solche Anwendungen lesen können. In der PPN

Anwendung, als offenes System, können die Scanner-

typen nicht vorgeschrieben werden. Auf die Data

Matrix Dotcode Variante wird daher verzichtet.

http://www.securpharm.de/fileadmin/pdf/Pharmahersteller/2013-01-11_securPharm_Regeln_Codierung_DE_V1_02%5B1%5D.pdf




• European Medicines Agency (EMA): Europäische

Zulassungsbehörde für bestimmte Arzneimittel.

• Global Trade Item Number (GTIN): Eine Artikel-

nummer im Einzelhandel. Typischerweise findet

sich diese Artikelnummer in einem Strichcode vom

Typ EAN-13 kodiert wieder. Andere Kodierungen

der GTIN im Code 128, Data Matrix Code und GS1-

DataBar sind möglich. Die zuständige IA ist GS1.

• GS1 – eingetragenes Warenzeichen: GS1 ist die

Abkürzung von Global Standards One, die als IA

registriert ist und weltweit die GS1-Nummernsysteme

verwaltet.

• HIBC – Health Industry Bar Code: Der HIBC ist eine

komprimierte Struktur und wird vornehmlich für die

Kennzeichnung von Medizinprodukten verwendet.

Der HIBC wird von dem Systemidentifikator „+“

angeführt, die Kapazität für Produktcodes ist 2 bis

18-stellig und alphanumerisch, gefolgt von den

variablen Produktdaten (siehe www.hibc.de).

• IFA: Informationsstelle für Arzneispezialitäten IFA

GmbH (www.ifaffm.de). Zuständige Vergabestelle

für die PZN und den PRA-Code.

• IFA Coding System: Von der IFA publizierte Spe-

zifikationen, die die Regeln der deutschen Stake-

holder im Arzneimittelmarkt umsetzen, erweitert auf

alle apothekenüblichen Waren (z.B. auf Nahrungs-

ergänzungsmittel). Es deckt die Kennzeichnung

von Handelspackungen und Transporteinheiten ab.

• Issuing Agency Code (IAC): Der von der

„Registration Authority for ISO/IEC 15459“ zuge-

teilte Registration-Code einer Issuing Agency (IA).

Eine Issuing Agency ist in der Lage, seinen System-

teilnehmern ein System zur weltweit eindeutigen

Identifikation von Objekten zur Verfügung zu stellen.

Die ISO hat die NEN (NEderlandse Norm) beauf-

tragt, als Registration Authority zu fungieren.

• Modulgröße: Bezeichnet die Größe einer Matrix-

zelle im Data MatrixCode

• National Trade Item Number (NTIN): Eine welt-

weit eindeutige Artikelnummer, in der nationale

Artikelnummern unter Verwendung eines GS1-

Präfix’ eingebettet sind. Für die PZN ist der Präfix

4150 vergeben. Als Datenidentifikator ist wie für die

GTIN der Application Identifier (AI) „01“ zu verwen-

den.

• Optical readable media (ORM): Oberbegriff für

Codierungen, die mit optischen Geräten erfasst

werden. Dazu gehören OCR-Schriften, Barcodes

und 2D-Codes etc.

• OTC-Arzneimittel: OTC (engl. over the counter) ist

die Bezeichnung für nicht verschreibungspflichtige

Arzneimittel. Gemäß § 48 AMG werden Arzneimittel

dann als nicht verschreibungspflichtig eingeordnet,

wenn sie bei bestimmungsgemäßen Gebrauch die

Gesundheit des Anwenders nicht gefährden, auch

wenn sie ohne ärztliche Überwachung angewendet

werden. Nicht verschreibungspflichtige Arzneimittel

werden noch unterteilt in apothekenpflichtige und

nicht apothekenpflichtige (freiverkäufliche) Arznei-

mittel.

• Pharmacy Product Number (PPN): Eine weltweit

eindeutige Artikelnummer für Produkte im Gesund-

heitswesen, in der die nationalen Artikelnummern

eingebettet sind. Sie besteht aus einem zweistel-

ligen Präfix (Product Registration Agency Code)

gefolgt von der nationalen Produktnummer (in

Deutschland PZN) und einer zweistelligen Prüfziffer.

Die nationale Produktnummer wird so in eine welt-

weit eindeutige Produktnummer überführt, um im

internationalen Geschäftsverkehr eindeutig zu sein.

Die zuständige IA ist die IFA.

• Pharmazeutischer Unternehmer (PU): Ist bei

zulassungs- oder registrierungspflichtigen

Arzneimitteln der Inhaber der Zulassung oder

Registrierung. PU ist auch, wer Arzneimittel unter

seinem Namen in den Verkehr bringt (§ 4 Abs. 18

AMG). Das bedeutet: Bringt ein anderer als der

Zulassungsinhaber das Arzneimittel in den Ver-

kehr, müssen beide Firmen in der Kennzeichnung

angegeben werden, z.B. beide als PU oder als

„Zulassungsinhaber“ und „Vertreiber“. Das gilt auch,

wenn neben dem Zulassungs-/Registrierungsinha-

ber ein oder mehrere Mitvertreiber das Arzneimittel

in den Verkehr bringen. Letztere werden dann als

„(weitere) PU“ oder als „Mitvertreiber“ angegeben.

Sowohl aus rechtlicher Sicht als auch im Rahmen des

securPharm Projekts sind alle vorher genannten

Parteien PU und für die ordnungsgemäße Erfül-

lung der entsprechenden Aufgaben verantwortlich,

soweit auf sie zutreffend.

• PPN-Code: Beschreibt einen Data Matrix Code

ECC 200 nach ISO/IEC 16022 und der Datenstruktur

und Syntax gemäß ISO/IEC 15418/ANSI MH10.8.2

sowie ISO/IEC 15434. Als führendes Datenelement

http://www.hibc.de

http://www.ifaffm.de


enthält der PPN-Code die „Pharmcy-Product-Num-

ber“ (PPN) und je nach Applikation noch weitere

Datenelemente. Bei verifizierungspflichtigen Arznei-

mitteln sind dies grundsätzlich „Seriennummer“,

„Chargenbezeichnung“ und „Verfalldatum“.

• Product Registration Agency-Code (PRA-

Code): Zweistelliger Präfix zur eindeutigen Kennung

einer PPN. Vergeben und verwaltet von der IFA

• Pharmazentralnummer (PZN): Nationale Produkt-

nummer der deutschen, pharmazeutischen Produkte

bzw. apothekenüblichen Waren. Die Vergabe der

PZN Nummer ist gesetzlich geregelt und obliegt der

IFA. Siehe www.ifaffm.de/service/_index.html

• Product Registration Agency (PRA): Vergabe-

stelle der (nationalen) Produktnummern, die in Ver-

bindung mit dem PRA-Code in die PPN überführt

werden.

• Randomisierte Serienummer: Nicht determinis-

tisch generierte Seriennummer

• RX-Arzneimittel: Verschreibungspflichtige Arznei-

mittel werden im Sprachgebrauch auch als RX-Arz-

neimittel bezeichnet.

• SecurPharm: Projektbezeichnung der Initiative der

Stakeholder im deutschen Pharmamarkt

• SI – Systemidentifikator: Ein Systemidentifikator

besteht aus einem Charakter oder aus einer

Kombination und verweist am Codeanfang auf die

verwendete Datenstruktur, bzw. Syntax. System-

identifikatoren sind nach DIN 66403 genormt.

• Symbologie: Der Begriff Symbologie wird als

Überbegriff für eine allgemeine Benennung aller

optischen Codes verwendet. Optische Codes sind

z. B. lineare Strichcodes (Barcodes), Matrixcodes,

Composite Codes oder gestapelte Codes. Unter-

schiedliche Symbologien bei linearen Strichcodes

sind z.B. der EAN Code, Code 128 und Code 39,

bei Matrixcodes z.B. der Data Matrix Code und der

QR-Code.

• Verifizierung: Unter der Verifizierung wird hier

der Prozess der Erkennung von Fälschungen oder

Duplikaten mit Hilfe einer Seriennummer auf

Arzneimittelpackungen verstanden. Im Bereich der

optischen Kodierungen wird der Begriff Verifizie-

rung auch für die Druckqualitätskontrolle der Codes

verwendet. Um eine Eindeutigkeit der Begriffe zu

erreichen, wird in der vorliegenden Spezifikation

Verifizierung nur in dem Kontext der Fälschungs-

erkennung verwendet. Die Druckqualitätskontrolle

wird immer als Strichcode- oder Matrixcodeprüfung

bezeichnet (vgl. englisch „Barcode verification“ im

Sinne der Druckqualitätskontrolle).

• XML: Der Begriff ist aus der englischen Bezeich-

nung „Extensible Markup Language“ abgeleitet.

XML ist eine Auszeichnungssprache zur Darstel-

lung hierarchisch strukturierter Daten in Form von

Textdaten.

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


Anhang K Bibliography

K.1 Normen:

ISO 22742: Packaging - Linear bar code and two-

dimensional symbols for product packaging

ANSI MH10.8.2: Data Identifier and Application

Identifier Standard

ISO/IEC 15418: Information technology -- Automatic

identification and data capture techniques -- GS1

Application Identifiers and ASC MH10 Data Identifiers

and maintenance

(Referenziert auf ANSI MH10.8.2)


identification and data capture techniques -- Bar code

print quality test specification -- Two-dimensional

symbols


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

able 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 Weiterführende Literatur

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: http://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


Anhang L Dokumenthistorie

Version Datum Kategorie der Änderung

Änderung

1.0 18.11.11 Erstausgabe

1.01 18.11.11 Layout-/Textkorrektur Kap. F. 1; (Textkorrektur); Anhang D (Layoutkorrektur)

1.02 23.01.12 Layout-/Textkorrektur Gesamtes Dokument (Layout); Kap. 1, Anhang F.1.6, F.2 (Text); Anhang F.1.6 (Inhalt ergänzt); Kap. 3.3 (Link); Anhang L (neu)

1.03 24.04.12 Layout-/Textkorrektur Anhang B (Zahl)

2.00 01.11.12 Inhalte, Layout-/Textkorrektur

Gesamtes Dokument:Ergänzungen und Textkorrekturen unter Berücksich-tigung der inzwischen veröffentlichten „Codierregeln securPharm“, insbesondere im Kapitel 1 und 2.

2.01 26.06.13 Layout-/Textkorrektur Links nachgeführt


Anhang M Impressum

IFA GmbH

Informationsstelle für Arzneispezialitäten

Hamburger Allee 26 - 28

60486 Frankfurt am Main

Postfach 15 02 61

60062 Frankfurt am Main

Telefon: +49 69 / 97 99 19-0

Telefax: +49 69 / 97 99 19-39

E-Mail: [email protected]

Internet: http://www.ifaffm.de

Die Inhalte wurden mit größter Sorgfalt erstellt. Sollten Sie Fehler entdecken oder Inhalte vermissen, so

bitten wir um Ihre Nachricht.

Anmerkung zur Erstellung dieser Spezifikation:

Die Arbeitsgruppe (AG) „Codierung“ innerhalb des securPharm-Projekts hat diese Spezifikation bis zur Ver-

sion 1.02 erarbeitet. Neben den Mitgliedern der AG Codierung haben zeitweise weitere Fachleute an der

Erstellung der o.g. Dokumentation mitgewirkt. Insgesamt waren dies (in alphabetischer Reihenfolge der

Familiennamen):

• Klaus Appel, Informationsstelle für Arzneispezialitäten (IFA), Frankfurt/Main *

• Dr. Ehrhard Anhalt, Bundesverband der Arzneimittel-Hersteller (BAH), Bonn *

• Thomas Brückner, Bundesverband der Pharmazeutischen Industrie (BPI), 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, (Leiter der AG) Sanofi-Aventis, Schwalbach *

• Dr. Stephan Schwarze, Bayer Health Care, Berlin

• Wilfried Weigelt, Mitglied im Normenausschuss NIA-01-31 *

Die mit * gekennzeichneten Personen haben maßgeblich an Version 2.00 mitgewirkt.


ifa coding system spezifikation ppn-code für … · ifa coding system spezifikation ppn-code für...

Documents