ACS-MAH-Guideline. ACS PharmaProtect GmbH. Readiness for Compliance with the Falsified Medicines Directive. As of: May 17, 2016

Size: px
Start display at page:

Download "ACS-MAH-Guideline. ACS PharmaProtect GmbH. Readiness for Compliance with the Falsified Medicines Directive. As of: May 17, 2016"

Transcription

1 2016 For participating in ACS PharmaProtect GmbH Readiness for 2019 Compliance with the Falsified Medicines Directive As of: May 17, 2016

2 Contents 1. INTRODUCTION 3 OBJECTIVE AND PURPOSE 3 2. HOW PROTECTION FROM FALSIFICATION WORKS 4 THE END-TO-END VERIFICATION 4 3. DISTRIBUTED SYSTEMS 5 THE SECURITY FEATURES OF THE EU DIRECTIVE 6 THE EUROPEAN NETWORK FOR PROTECTION FROM FALSIFICATION 6 ROADMAP FOR THE SECURPHARM PROJECT 7 4. CONSEQUENCES FOR MAHS 8 SCHEDULE FOR IMPLEMENTATION WITHIN THE COMPANY 8 ORGANISATIONAL UNITS THAT SHOULD PARTICIPATE IN THE IMPLEMENTATION WITHIN THE COMPANY 9 RECOMMENDATION FOR THE STEPWISE INTRODUCTION THE TECHNICAL REQUIREMENTS 11 THE DATA MATRIX CODE 11 DATA MANAGEMENT ON THE PACKAGING LINE 16 STEPS FOR ONLINE PRINTING OF THE DATA MATRIX CODE (DMC) AND THE VARIABLE DATA 17 DATA UPLOAD TO THE ACS-MAH-SYSTEM INFORMATION REGARDING SPECIAL PACKAGE TYPES 19 CLINIC PACKS BENEFITS DUE TO EARLY PARTICIPATION STEPS TO PARTICIPATE IN SECURPHARM THE ACS PRICING MODEL THE ACS-MAH-PORTAL CONTACT INFORMATION 25 ACS HEAD OFFICE 25 SECURPHARM PROJECT OFFICE 25 IFA PRODUCT REPORTING 25 ABDA 25 WUV ADDITIONAL PUBLICATIONS 26

3 1. Introduction 1. Introduction Directive 2011/62/EU (Falsified Medicines Directive) aims to protect patients from falsified medicines. It stipulates a series of measures to prevent falsified medicines from entering the legal supply chain. This includes e.g. the obligation that, in principle, every single prescription medicine pack must be equipped with security features. These should demonstrate the integrity of the packaging and facilitate verification for authenticity (see Article 54a of Directive 2001/83/EC in particular). European directives must be transposed into national law, which has been done by the German legislature. Accordingly, Section 10 para. 1c of the German Medicinal Products Act (AMG) basically requires the inclusion of security features on the outer packaging of medicinal products for human use. In this respect, the AMG explicitly refers to the European requirements. The EU Commission has published additional technical details for the further design of security features with the Delegated Regulation (EU) 2016/161 on February 9, 2016, in the Official Journal of the European Union. The securpharm e.v. organisation, which was founded by the stakeholders in the German pharmaceutical market (ABDA, BAH, BPI, PHAGRO, vfa), has established a system that complies with the implementation of Directive 2011/62/EU and takes into account the requirements from the Delegated Regulation (EU) 2016/161. Objective and purpose This guideline is meant to provide you as a marketing authorisation holder (MAH) with assistance in the upcoming implementation of the requirements for protection against falsification. The requirements result from the abovementioned regulatory documents (directives, laws, etc.). This guideline will show you what tasks you will have to perform to be able to participate in the securpharm system. For the associations sponsored by the MAHs, it is a special concern to point out the complexity of these responsibilities and the urgency of certain tasks. They make it necessary to deal with the new requirements early on in order to avoid non-compliance. 3

4 2. How protection from falsification works 2. How protection from falsification works The stakeholders decided on a system for verification of the authenticity of a medicinal product pack in which each product packaging is tagged with a randomised, uniquely assigned serial number. The necessary data are affixed to the medicine pack in the form of an ISO/IEC data matrix code. During the sale of the medicinal product at the pharmacy, the serial number on the pack is verified against the database system of the pharmaceutical industry. The prerequisite for verification is that each pack be tagged with a globally unambiguous product code as well as an assigned randomised serial number. As a result, it is necessary to extend the product number from the Pharmazentralnummer (PZN) to the Pharmacy Product Number (PPN) or National Trade Item Number (NTIN). To automate the verification process, the data must be affixed to the pack in standardised, machine-readable format. The data matrix code (DMC) contains either the PPN or NTIN. Both include the eight-digit PZN as required by social law, which is mandatory for reimbursement. Apart from a serial number, the code also always includes the batch identifier/number and the expiry date. The End-to-End verification 4

5 3. Distributed systems 3. Distributed systems The securpharm system is a distributed system, which is composed of a system for pharmacies (AP system) and a system for marketing authorisation holders (MAH system). Following the principle that each party remains in charge of its own data, the systems in securpharm are set up in such a manner that the marketing authorisation holder cannot track from which pharmacy the verification inquiries originate and, likewise, the pharmacies cannot view the marketing authorization holder s data. In the database system of ACS PharmaProtect GmbH, the operating company of the MAH system, the data are managed for the marketing authorisation holders and protected data areas are provided for each manufacturer. Each marketing authorisation holder can only view and access his own data inventory. Verification is done as an anonymised data exchange between the AP- and MAH-system. securpharm e.v. functions as a top-level organisation. securpharm stipulates the rules of the overall system and acts on anything conspicuous that may suggest suspected falsification. The latter function will only be performed by securpharm once all systems have started mandatory operations. Currently, the systems are still undergoing a technical testing process during which the focus is not yet on the detection of falsifications. 5

6 3. Distributed systems The security features of the EU Directive The outer packaging of each medicinal product must contain the information below: 1. Security features that enable wholesalers and individuals authorised to sell medicinal products to the public Ê Ê To verify the authenticity of the medicinal product To identify individual packs 2. A feature that allows verification as to whether the outer packaging was tampered with. CENstandardisation The anti-tampering device is not a focus of securpharm. Implementation of this requirement, part of which is very elaborate, must be done by the MAH and must not be neglected under any circumstances! The European network for protection from falsification 6

7 3. Distributed systems securpharm and ACS consider themselves a model and component of the European shield against the falsification of medicines. If you as an MAH have to place prescription medicines on the market in more than one European country, you need to ensure that the associated pack data are stored in the databases of the respective national verification systems. To make the process of data provision to the national verification system easier, the so-called European Hub (EU-Hub, for short) is supposed to work in the form of a router: During the centralised upload of the data files, they are prefixed with a country code, which enables the EU-Hub to transmit the data to the correct national database. As a result, you will need only one interface and have to upload only once. The start of the EU Hub and connection to the German verification system of securpharm was achieved in Of course, the established interface to the ACS-MAH-system will remain operational. You will therefore have free choice of access. If you decide to upload your pack data via the EU Hub, you will need to conclude the obligatory IT user agreement as well as an additional contract with ACS and a contract ( Participation Contract ) with the European Medicines Verification Organisation (EMVO). For more information, please contact info@pharmaprotect.de. Roadmap for the securpharm project January 2013 April 2011 July 2011 June Development of technology/ organization Pilot 3 years Expansion of the ACS MAH systems EU Directive became effective/ Preparation of delegated act Publication of Delegated act EU Directive successfully implented Start of securpharm Founding of ACS Connection to the EU Hub Publication of the Delegated Regulation. Start of the transitional phase start of pilot phase 7

8 4. Consequences for MAHs 4. Consequences for MAHs Schedule for implementation within the company 2015 Juli 2016 Juli 2017 Juli 2018 Project decisions, provision of budgets and resources Create the technical prerequisites for the packaging lines Implement IT systems Implement changes in packaging materials Establish process changes The schedule shows that assuming the usual project times introduction for serialisation should begin as early as now in order to be able to deliver all affected products at the start on February 9, Shortening the project time will be associated with much higher costs and risks! In any case, the complexity of the project, the internal interaction of the individual functions and the dependence on external suppliers and service providers involves a lot of imponderabilities as it is. With the effectiveness date of the Falsified Medicines Directive in February 2019, only serialised packs of medicine can be produced and placed on the market. 8

9 4. Consequences for MAHs Organisational units that should participate in the implementation within the company MANAGEMENT Planning of time line and budget for the project Define responsibilities Communication of changes to employees and stakeholders QUALITY MANAGEMENT IT Changes in production processes, IT processes (SOPs) Creation of rules related to the handling of randomised serial numbers Define processes regarding the handling of conspicuity and suspected falsifications Additional requirements related to data safety and data storage (mass and long-term storage) New procedure: generation and management of serial numers across all production sites Define the time of data upload to the MAH system and merchandise shipping PRODUCTION Use of new equipment (space requirements) Changes in existing work processes and addition of new working steps Changes in packaging (varnish windows) regarding serialisation and tamper verification features MARKETING/SALES Communication of the changes to consumers and patients Clarification of questions from vendors and end users regarding the data matrix code Inclusion of all existing sales channels HR Employee training and qualification Possibly creation of new jobs in data storage and data management PURCHASING Procurement of all necessary equipment for serialisation and verification (machines, IT, awarding of service contracts and third-party services) Purchasing of modified packaging regarding printing and tamper verification features REGULATORY AFFAIRS Regulatory processes: Submission of updated QRD templates The implementation of the Falsified Medicines Directive is a project with distinct interdisciplinary collaboration across all company units! In some European and non-european countries, guidelines for serialisation already exist. 9

10 4. Consequences for MAHs Recommendation for the stepwise introduction Package 1 Online printing: Ê Ê Ê Ê Start of online printing of variable data Regulatory processes: Submission of updated QRD templates For additional information on products with central marketing authorisation, see EMA, Human Medicines Evaluation Division, document EMA/785582/2014 of February 9, 2016, Implementation plan for the introduction of the safety features on the packaging of centrally authorised medicinal products for human use For additional information for MR/DC and purely national marketing authorisation procedures, see Coordination Group for Mutual Recognition and Decentralised Procedures human, document CMDh/345/2016, February 2016, Implementation plan for the introduction of the safety features on the packaging of nationally authorised medicinal products for human use This results in the required descriptions (prefixes) for serial numbers, product code and national reimbursement number in human-readable format Implementing changes in packaging materials Coding of pharmaceutical packages Affixing of the product code and the serial number in human-readable format Package 2 Tamper verification features: Ê Implementing the security feature pursuant to the EU Directive Ê Use standard DIN EN 16679: for assistance Package 3 Data management in the production line: Ê Establish data management (target data) in the production line Ê Include all code readers and printers Package 4 Serialisation: Ê Serialisation at the individual package level Ê Generation of randomised serial numbers Ê Interim storage of serial numbers produced Ê XML upload to the MAH system Package 5 IT system: Ê Long-term storage / transfer of serial numbers Ê (Aggregation of the data) Ê Security aspects Ê Data interface with the contracting party 10

11 5. The technical requirements 5. The technical requirements The data matrix code Two versions for enveloping the PZN two formats for coding: i The determination described in the securpharm coding rules for coding of medicines requiring verification for the German market is obliged to apply. Version 1 (IFA format) Version 2 (GS1 format) Agency Code für PZN Data content DMC: Ê PPN (envelops PZN) * Ê Serial number Ê Batch identifier / number Ê Expiry date Data Identifier (DI) according to ISO/IEC / ANSI MH Data content DMC: Ê NTIN (envelops PZN) ** Ê Serial number Ê Batch identifier / number Ê Expiry date Application Identifier (AI) according to ISO/IEC / ANSI MH * Contain PZN in form of PPN ** Contain PZN in form of NTIN 11

12 5. The technical requirements In addition to the requirements from the German Social Code Book V (SGB V), the stakeholders in the German pharmaceutical market have in principle agreed on the machine-readable coding of retail packs with the following data elements: Product code (PPN/NTIN) Serial number Batch identifier / number Expiry date Coding is performed in the data matrix code according to ISO/IEC and the data structure and syntax pursuant to ISO/ IEC and ISO/IEC The label PPN is affixed to the code. To the vendors, this shows the code being used for machine reading of the product number and additional data. The coding ensures machine readability of the above-mentioned data elements and the technical implementation of the requirements from the EU Directive for protection from falsified medicines as well as the Delegated Regulation of February 9, 2016, for the verification of medicinal products. For the product identification of medicinal products, the Central Pharmaceutical Number (PZN) is embodies in the German Social Code Book V (SGB V) encoded in Code 39. Participation in securpharm in the testing phase is no substitute for the requirement of affixing the PZN in Code 39 on the pack! Many processes, such as billing, reimbursement and identification of medicinal products, refer to the PZN as the product number. For verification in terms of the EU Directive, a product number that is unambiguous on a Europe-wide scale is needed. In order to meet this requirement as well, the Pharmacy Product Number (PPN) and the National Trade Item Number (NTIN) were created, each of which is generated from the 8-digit PZN. The marketing authorization holder can decide between the two above-mentioned coding schemes in consideration of the applicable licencing terms and switch between the two versions at any point in time, since the pharmaceutical verification system by securpharm supports both and works without conflict. Algorithmically, existing databases and software systems can extract a PZN from the PPN or NTIN and, conversely, generate a PPN or NTIN from the PZN. In both versions, the data content for batch identifier/number, expiry date and serial number is identifical. 12

13 5. The technical requirements Overview and data identifier references* The table below specifies the characteristics of the individual data identifiers: Data elements XML node DI** AI** Data type Data format Character length Character set Pharmacy Product Number (PPN) <PPN> 9N AN ; A-Z no special characters no use of lowercase letters no national characters National Trade Item Number (NTIN) <GTIN> 8P 01 N Serial number <SN> S 21 AN Numeric or alphanumeric characters no national characters Batch identifier/number <LOT> 1T 10 AN Numeric or alphanumeric characters no national characters Expiry date <EXP> D 17 Date YYMMDD * The specifications outlined in the securpharm coding rules are binding. ** The data identifiers in accordance with the international standard ISO/IEC (referencing ANSI MH10.8.2; Data Identifier and Application Identifier Standard) will be used. IFA uses the Data Identifier (DI) and GS1 uses the Application Identifier (AI). Recommendations to the MAHs regarding the character set for serial number and batch identifier/number: The character string should only include either uppercase letters or lower case letters of the Latin alphabet. To avoid human reading errors and depending on the font used and print quality, the MAH should exclude characters that are prone to be mistaken for each other. These include: i, j, l, o, q, u and I, J, L, O, Q, U. 13

14 5.The technical requirements While some special characters are technically processed, they should not be used because the risk of misinterpretation is very high. A misinterpreted code results in a package being unable to be verified, thereby making it ineligible to be dispensed. ACS expressly points out that no liability is assumed for malfunctions upon reading whenever these special characters are used. If separating characters are necessary within a batch identifier, the use of a hypen - or underscore _ or the dot. 2 is recommended. Examples 14 1 The special characters with the decimal ASCII code values of 35 (#), 36 ($), 64 (@), 91 ([), 92 (\), 93 (]), 94 (^), 96 (`), 123 ({), 124( ), 125 (}), 126 (~) and 127 ( ) and all control characters (ASCII code value 00-31) are excluded from technical processing. In principle, all ASCII characters with a decimal value of more than 127 are excluded. 2 The use of the dot is highly recommended due the identical occupation on the German and English keyboards. In case of wrong language selection of the used keyboard-scanner, the risk of misinter-pretation per se does not happen.

15 5. The technical requirements Rules for serial numbers The generation and management of serial numbers is the responsibility of the marketing authorisation holders. They can use existing software solutions in the market and the corresponding service providers or their own solutions. The serial number required for verification is a numeric or alphanumeric sequence of a maximum of 20 characters generated by the marketing authorisation holder (MAH). To make it as difficult as possible for forgers to guess or reproduce assigned serial numbers, they must be generated based on a deterministic or non-deterministric randomisation algorithm. In any case, the probability of being able to derive a serial number must be less than 1: In addition, the randomized serial number in combination with the PZN-based product code for each pharmaceutical package must be individual for a time period of at least one year from the expiry date of the package or at least five years from the date a pharmaceutical is placed in the market (the longer time period shall apply). The reuse of serial numbers represents a potential source of errors and is therefore not recommended. 1. Methods for generating serial numbers completely in the discretion of the marketing authorisation holder Centralised (within the group of companies) Consequence: Ensure security in the centralised systems and in transmission Or decentralised on the production line / on site Consequence: Exclude duplicates at multiple production sites for the same product 2. Additional information on the structure of serial numbers completely in the discretion of the marketing authorisation holder Serial numbers can include fixed partial strings that make it easier to ensure unambiguity. The partial strings can be related to the batch, packaging line/site or chronology If there is a technical malfunction, the optional extension of the sets of numbers (for the mandatory verification) represents the possibility to continue to ensure unambiguity of the serial number 15

16 5. The technical requirements Data management on the packaging line Online printing and the associated data management is a very complex process. Apart from the actual printing and implementation of the corresponding technology, the packaging materials used must also be adjusted as needed. The timely and complete provision of printing data on the production line and the verification of the correctness of the printed data round out the process. 1. Provide order data for online printing Develop a future-oriented concept for data handling and implement in stepwise fashion! Data transfer from ERP system, or Centralised manual entry at the packaging line (MES system, if applicable) Take into account the many different national requirements on a global scale (automated data generation based on national requirements) 2. Provide serial numbers Download from the corresponding system (see p. 17) 3. Capture data on the packaging line Develop and implement a security concept regarding loss of data and misuse! Capture printed serial numbers in the last possible process step (after the usual output stations) Interim storage of the printed serial numbers on the packaging line for transmission to IT systems If applicable, generate XML file for data upload to the MAH system directly on the packaging line 4. Transmit data to IT systems Data transfer to internal IT systems (T&T module) for data backup and long-term storage 16

17 5. The technical requirements Steps for online printing of the data matrix code (DMC) and the variable data 1. Determine the printing method Note dependencies on the packaging material! Bubble jet, or Laser, or UV ink jet, or Printing at the packaging material supplier s place of business 2. System selection Aim for modularity! Printer Code reader Determine the method for print control (code and variable data)! Implement data management on the production line 3. Implement packaging material changes Standardise the layout! Varnish windows for bubble jet printing Varnish application for laser printing Determination of the cardboard texture depending on the printing method Positioning of the code, determine for the variable data in human-readable format and for the preprinted texts (labelling pursuant to Section 10 of the German Medicinal Products Act (AMG)) Affix product code and serial number in human-readable format 4. Integrate systems into the packaging line Integration into existing cartoners, or Separate printing unit, or New cartoner with integrated system 5. Integrate the process into the packaging operations Adjust production orders Update SOPs (IPC, output, line clearing, etc.) Update order / product master data 17

18 5. The technical requirements Data upload to the ACS-MAH-system 1. Set up communication pathways to the ACS-MAH-system Apply for and set up portal access with ACS Apply for and set up a machine interface, if applicable Set up the process organisation for uploads, receipt of notifications and access to statistical data (for the MAH s own products) 2. Generate XML file for data upload To be generated from the internal IT system, or To be generated directly on the packaging line 3. Upload XML file Provide file after production or release but prior to placing the products on the market Provision via the ACS-MAH-portal (HTTPS) Provision via the ACS machine interface (SFTP) Provision via the EU-Hub 18

19 6. Information regarding special package types 6. Information regarding special package types Clinic Packs In principle, clinic packs are coded identically to pharmacy retail packs. Clinic packs consisting of clinic components 3 represent a special scenario. In this case, the clinic pack, not the clinic component, represents the retail pack. As a result, the unique identifier must be affixed to the clinic pack, not the clinic component. Clinic components may bear a DMC, e.g. for logistical reasons, but the data elements must not be transmitted to the ACS MAH system or used for verification (see table below). i The determination described in the securpharm coding rules for coding of medicines requiring verification for the German market is obliged to apply Apothecary retail packs Clinic packs Clinic packs with clinic components Pack contents Single objects (blister, coated tablets, vials ) Single objects (blister, coated tablets, vials ) Bundled single packs (clinic components) 3 IFA master data Retail pack (PZN) Retail pack (PZN) Clinic pack (PZN) with clinic component (PZN clinic component) 3 PZN in the code 39 (bar code) Retail pack Clinic pack Clinic pack Clinic component Data Matrix Code (DMC) DMC obligatory - Product code - Serial number - Batch number - Expiry date DMC obligatory - Product code - Serial number - Batch number - Expiry date DMC obligatory - Product code - Serial number - Batch number - Expiry date DMC optional - Product code - Batch number - Expiry date ACS-MAHsystem NTIN/PPN SN LOT EXP NTIN/PPN SN LOT EXP NTIN/PPN SN LOT EXP... Verification against Retail pack Clinic pack Clinic pack... 3 A clinic pack is a pack that resembles the pharmacy retail packs but cannot be sold individually. A PZN is attributed to the clinic component for identification, and which refers to the characteristic clinic component. Bundled clinic components form clinic packs, which are attributed with the PZN relevant for retail. 19

20 7. Benefits due to early participation 7. Benefits due to early participation 1. Cost reductions Based on early experience, system selection and process design can be optimised. This will generate cost savings in investments and process conversions. Lowers the overall cost of implementation, since the (stepwise) realisation can be combined with other activities. This applies to: Changes in packaging materials Technical changes incl. qualification and validation Process changes incl. SOPs and training seminars During the technical testing phase, errors in coding, serialisation and data storage or transmission do not result in economic or legal consequences. During the mandatory phase, batch devaluations 2. Safeguarding products marketability With the effectiveness of the Delegated Regulation on February 9, 2019, products subject to verification must be produced with security features that can be verified. Companies with a late start of implementation run the risk that their products may no longer be marketable or can no longer be dispensed. 3. Participation in the securpharm/ ACS exchange of experience Participate in the regularly organised exchanges of experience and benefit from the expert knowledge and the experience of other companies participating in the project. You have the opportunity to participate in work groups and panels, thereby actively shaping the system. 4. More effective design of internal processes by means of serialisation If there are process deviations, the packaged batch can be narrowed down in a targeted manner, possibly even to a single pack. Serial numbers allow more exact, intra-company tracking whenever there are conspicuities in the market. 5. Implement the process in packaging operations The data matrix code indicates to patients, vendors and physicians that the product is tagged with a special feature. Preparation for better medicinal product protection is signalled to the public. Vendors and pharmacists can automatically register batch and expiry date. The serialisation results in numerous changes in process organisation, packaging equipment, IT systems and packaging materials. To implement these investments and process changes effectively and efficiently, all factors must be known. 20

21 8. Steps to participate in securpharm 8. Steps to participate in securpharm 1. Conclude an agreement with ACS PharmaProtect GmbH This agreement governs the rights and obligations for participation during the technical testing phase and entitles manufacturers to use the MAH system. The organisational costs and expenses for securpharm e.v. at the moment are mainly borne by the associations. Since 2014, the MAHs have incurred costs based on the use of the MAH system. Increasing provision costs can be significantly reduced through early participation. The pricing model of ACS PharmaProtect GmbH makes the early conclusion of an agreement financially attractive. 2. Report the products to be verified to the IFA In order to be able to manage retail processes (pharmacies) correctly, the retail sector must be aware that your medicinal products are participating in the verification effort. Based on the corresponding flag in the product master data, the retail sector will be provided with this information. The corresponding medicinal products (PZNs) must be communicated to the IFA by the person designated by your company for such reporting duties and who is registered with IFA. After reporting of the publication date to the IFA, the product information is available to the retail sector and the product master data are transmitted to the ACS- MAH-system. The presence of the product master data in the ACS-MAH-system are a necessary condition for the upload of the serial numbers into the system. 21

22 9. The ACS pricing model 9. The ACS pricing model After the expenses incurred since 2010 for the development and operation of the database system for the pharmaceutical industry were initially fully covered by the associations of BAH, BPI and vfa, the marketing authorisation holders were successively integrated into the funding effort from 2014 onward. However, apart from their own contributions, the associations will sponsor about 75% of the expenses for system evolution and provision again in No later than 2019 the year in which mandatory verification becomes effective the system has to be able to pay for itself from usage fees. The role of the manufacturers associations as shareholders of ACS PharmaProtect GmbH ensures that a system with an efficient cost-benefit ratio is provided. In order to protect the interests of all categories of manufacturers, the ACS pricing model is based on the following three components: Component A / Initial set-up fee In the pricing model, the initial set-up fee primarily supports overall funding for the system, which will ensure the data exchange for the verification of pharmaceuticals as part of protection from falsification. This one-time fee component must be paid when a participant is established in the database system. The fee will increase in stepwise fashion through This expands the existing incentives for an earlier contract conclusion in such a manner that joining early is more worthwhile financially. COMPONENT A Initial set-up fee COMPONENT C Fee per data set COMPONENT B Operating fee In order to strengthen the early adopter effect, ACS has adjusted the initial set-up fee for January 1, Date Initial set-up fee in EUR (net) January 1, , July 1, , January 1, , July 1, , January 1, ,

23 9. The ACS pricing model Component B / Operating fee The monthly operating fee is due for system provision and basic support. The operating fee is degressively scaled, which means that the operating flat fee will decrease with an increasing number of new users (degression ends at 100 participants). Component C / Fee per data set (package volume) This variable fee is due for each data set (package volume) that is provided via the database system. This component is degressively scaled, i.e. with an increasing number of packages provided by a marketing authorisation holder the costs will decrease. The last uploaded data set in a year determines the price for all data sets entered during that year. This is based on all data sets of the marketing authorisation holder in question (degression ends at 10 million packages). Case studies on the pricing model The case studies below serve as an example of the costs incurred by four different companies depending on the number of packages entered by the pharmaceutical company in question into the database system of the pharmaceutical industry (Component C). The above information represents general information about the pricing model of ACS PharmaProtect GmbH. It is no substitute for a specific quotation. Only the user agreement in its current version will be binding. Please contact us anytime for additional information or a specific model calculation for your company. 23

24 10. The ACS-MAH-portal 10. The ACS-MAH-portal The intuitively operated ACS-MAH-system convinces users with its clear-cut design and allows a quick overview of your activities. Reports are stored with graphic elements that will make it easier for you to generate management reports. Process overviews for events that occurred can be represented monthly or weekly, as desired. A journal on delayed processes (e.g. the upload of serial numbers) and reports allows you to also track past events. The ACS- MAH-system will be successively expanded and further prepared for the market phase of the system with each new release. The multilingual set-up of the ACS-MAHsystem allows the involvement of international colleagues tasked with serialisation processes. 24

25 11. Contact information 11. Contact information ACS Head Office ABDA ACS PharmaProtect GmbH Taubenstrasse Berlin Germany Phone: +49 (0)30 / Fax: +49 (0)30 / info@pharmaprotect.de Web: ABDA Bubdesvereinigung Deutscher Apothekenverbände e.v. Unter den Linden Berlin Germany Phone: +49 (0)30 / Fax: +49 (0)30 / abda@abda.de Web: securpharm Project Office WUV securpharm e.v. Hamburger Allee Frankfurt am Main Germany Phone: +49 (0)69 / Fax: +49 (0)69 / info@securpharm.de Web: IFA Product Reporting Werbe- und Vertriebsgesellschaft Deutscher Apotheker mbh Carl-Mannich-Straße Eschborn Germany Phone: +49 (0)6196/ Fax: +49 (0)6196/ wuv@wuv.aponet.de Web: Informationsstelle für Arzneispezialitäten GmbH Hamburger Allee Frankfurt am Main Germany Phone: +49 (0)69 / Fax: +49 (0)69 / ifa@ifaffm.de Web: 25

26 12. Additional publications 12. Additional publications securpharm coding rules (Rules for the coding of medicinal products subject to verification in the German market) IFA coding system (Specification of the PPN code for retail packs) IFA extension of the PZN to the PPN Excerpt from Directive 2011/62/EU Excerpt from Directive 2001/83/EC Excerpt from Section 10 para. 1c of the German Medicinal Products Act (AMG) Excerpt from the German Social Code Book V (SGB V) Delegated Regulation (EU) 2016/161 Additional links Version 1.8 Picture credits Frontpage securpharm, p. 10 SecurPharm; DIN EN 16679: / Beuth Verlag*, p. 12 securpharm Codierregeln, p. 14 Boerhinger-Ingelheim Pharma mbh & Co. KG; Sanofi Aventis Deutschland GmbH, p. 16 shock / fotolia.com, p. 18 VRD / fotolia.com, p. 19 securpharm, p. 21 momius / fotolia.com *Reproduced with the permission of DIN Deutsches Institut für Normung e. V. Decisive for the application of a DIN standard is the use of the latest version, which is available at Beuth Verlag GmbH, Am DIN Platz, Burggrafenstraße 6, Berlin. Authors ACS PharmaProtect GmbH / Paul Rupp (Consultant) Editors (Q2/2016 edition) Dr. Norbert Gerbsch Tobias Beer Dr. Hermann Kortland Antje Gerlach Peter Krug Kai Hajostek Dr. Wolfgang Stock Thomas Imiela 26 Published by ACS PharmaProtect GmbH, Taubenstrasse 20, Berlin, Germany

27 ACS PharmaProtect GmbH Readiness for 2019 Compliance with the Falsified Medicines Directive Version