Virtual Pharma company

Article Index

What is TradeTicity value proposition for MAH?

CureSync enables you satisfy all current and upcoming regulations with flexible, expandable worldwide leading solution at affordable price. 

Optimizes investment in HW equipment, maintenance and internal skills and resources, GAMP5 validation and long term maintenance and support. 

By choosing TradeTicity MAH will get:

  • Immediate compliance with all required regulations
  • Easy integration with CMOs and supply chain partners
  • Ability to expand between different licencing and pricing models
  • GAMP 5 Validated system
  • Advanced list of functions and features satisfying any demand you may have
  • Proven leading solution for serialization
  • Affordable pricing model
  • Reliable and knowledgeable partner
  • Proven, flexible and disaster resistant solution

Overview of the CureSync (MAH related)

Understanding Curesync

The CureSync Serialization System 2.0 is built after a careful analysis of clients’ perspectives about the real life challenges and requirements regarding the implementation of a serialization system, Track and Trace and managing serialized items.  

In order to satisfy the demands from different clients, from extremely small with simple production, via distribution and logistics channels, to extremely complex, multinational organizations operating in multiple countries with diverse regulatory requirements.  

After gathering experiences and needs, the following guiding principles are incorporated into version 2.0 of the CureSync Solution: 

  • Hardware and Software platform independence 
  • Modular design based on Open Standards and SOA principles 
  • Highest possible horizontal and vertical scalability 
  • Flexible delivery models to suit the most demanding needs 
  • Multipurpose usage within the integrated platform 
  • Ability to model business processes easily and adapt to any client needs 
  • Superior integration capability 
  • Configurability, to minimize customization at the programming level 
  • Adhering to Cloud principles, in terms of multi-instance, multitenant and SaaS concepts 
  • Reliability, in terms of uptime and resistance to unplanned interruptions, including disasters 
What are Cloud Principles?

No matter if CureSync is run in a client environment, or hosted in TradeTicity’s environment, basic cloud principles are followed: 

Overview of the modules

Depending on the usage of CureSync, some or all components may be active. For example, having a site utilizing numbers from some other repository, whether CureSync or not, will eliminate the need for the Serial manager. However, if the need arises for a site to request production from a third party, CureSync will retrieve the serial numbers from an external system, and use Serial trader to provide the serial numbers to the third party when needed. 

Becoming Familiar with CureSync modules

Curesync modules are formed in a way that easily describes the tasks required in both the initial phases and the maintenance phases. Those sections, marked as “Plan” are dedicated to business users. Business users may easily adjust the system, if proper authorization is granted, for example, defining new schemes for serial number generation, or maintaining vocabularies and attributes, creating new printing labels, or extending EPCIS vocabulary. 

The “Control” section represents the high-level list of views, in either tabular or tree form, where system users can monitor activities, such as the Printing dashboard, Warehouses, etc.  

Finally, “Execute” represents the execution of tasks, e.g. sending EPCIS event to an external party, or retrieving Serial numbers from an external source.  

Figure 6 details the high level functions of CureSync. 

Random number Generation

The Random number Generation component creates and stores serial numbers, either randomized by a randomization algorithm, or sequential, with sequential steps. 

This component may be shared between tenants inside the same instance, allowing all tenants to use the same component to generate serials, avoiding duplications inside the organization. There is also a setting which allows a tenant to produce serials using its own component, independent from other components.  

If a tenant has an independent random number generation component, then the propagation of serials from parent organization to lower levels will be performed using the Serial Trader component, as it is with external organizations.  

Algorithms for generation may be added or updated, and can be changed over time. All random number generation algorithms will store serials into the warehouse. 

Serial Trader 

This component defines the Serial number templates, tracking of warehouse levels of serial numbers and the exchange of serial numbers with external parties (import and export of serial numbers).  

It consists of the following high level functions: 

  • Serial Number management – responsible for template definition (syntax) of generated serial numbers and tracking of the available Serial number levels into the Serials warehouse. 
  • Import/Export Serials – is able to generate XML structure to obtain serials from an external source (Agency or MAH) or provide serial numbers to external manufacturing parties. Also, Import/Export Serials should obtain Serials from parent organizations, if required. 

Product Catalogue 

Many large companies have heterogeneous ERP systems, with several sources for retrieving product information. To centralize information exchange, including Product identification (as GTIN or IFA PZN or other, according to legislation and other relevant attributes) and send XML structure to a Central Agency, a Centralized Product Catalogue should be created. Moreover, many companies can’t integrate or replicate their current product information with GS1 GDSN (Global Data Synchronization Network), or similar catalogues available elsewhere. 

To simplify this process, CureSync has a flexible module for centralizing product specific data, where information can be made in alignment with EPCIS standard and GDSN requirements.  

Product Catalogue consists of following services 

  • Product management – products could be grouped in hierarchies, where each hierarchical level can inherit the product vocabulary, and be extended using further vocabularies which includes level-specific attributes.  
  • Aggregation Data Management – The hierarchical structure of aggregation data, could be assigned to a Product. This means that a product can have a predefined aggregation scheme which will be used as default unless it is changed during the process execution. This is especially important when a product is made as a bundle of other products. 
  • Import-Export product Catalogue – Data that will form the product catalogue could have its origin in ERP or other Enterprise systems, but changes may occur in either or both systems. Also, the system allows import/export from GDSN, so that the company can easily transfer product specific data if needed. 

Track and Trace Broker 

This component manages the aggregation and deaggregation of the products. Products at the item level, with its specific Product Identification number (GTIN, IFA PPN, Self-defined, etc.) are bundled into bigger packages. Bundling options may be several, e.g. packaging could be of 12 or 6 bottles of pills on first level, and then this can be further bundled. Each aggregation level should have separate Product number (e.g. GTIN), but if the manufacturer prefers not to define products with the standard GS1 principle, the system has to assign the product identification internally. However, some aggregation bundles can consist of different types of products, e.g. 6 pieces of one, and 6 pieces of different type of product, which is important when the system is used as distributor system. 

The Track and Trace Broker consists of following services: 

  • Aggregation schemas – enables creation of aggregation schemas – templating. This function enables the creation of unlimited numbers of schemas for aggregation, and the assignment of schemas to products. 
  • Aggregation management – performs all aggregation functions, from identifying the product, verifying packaging options, to the formation of the SSCC number to be printed on the packaging. Enables insertion of the items into the aggregated product. The total quantity for aggregation may or may not be known, and the service will listen for an External device to submit item serials for aggregation, but also should push aggregation triggers to external devices. 
  • Deaggregation management – performs deaggregation action on the package, returning items in the package and change the status to deaggregated. 

Supply Chain Bus 

The main purpose of this component is to exchange data with internal and external EPCIS based systems, national agencies, distributors, etc. The component receives and triggers EPCIS events, converts EPCIS to other forms, e.g. EDI, and updates the EPCIS data.  

It consists of following services: 

  • EPCIS Proxy – this recognizes the EPCIS location (internal or external) and prevents the direct connection by internal parties to the EPCIS layer in order to retrieve data. Additionally, it enables predefinition of the Trading subjects. However, other subjects are allowed to report to EPCIS (in order to update current location of the items, as may be required by some regulations) and the service automatically adds subjects to the EPCIS.  
  • EPCIS Translator – although EPCIS is commonly regarded as a standard, there are some minor adaptations between different agencies as well as requirements for communication using EDI instead of EPCIS. Thus, the standard EPCIS structure may have to be adapted for: 
    • SFDA – Chinese national drug agency standard, which requires the party to obtain logistic and item numbers from a Central Database 
    • US DSCSA  
    • EU EMVS 
    • Brazil ANVISA agency standard for data exchange  
    • MOH Turkey standard 
    • EDI 

Translator Layer is a set of predefined schemes that are used to adapt to any standard. It uses the Integration layer to meet current, but also upcoming legislative requirements. 

Job Scheduler 

In serialization scenarios, Work Orders, coming from External systems or manually entered, are routed to production lines. There can be many production lines, often not all at the same location. Thus, theoretically, one work order could be split into smaller parts, e.g. production of 10,000 pieces may be divided between 3 production lines, each with their own distribution. Moreover in this example, production will most likely not start at the same time on all production lines. Also, it may be necessary to cancel production on one line, and complete the production on another other line (e.g. in the case of a malfunction of the production line). 

The Job Scheduler thus is used to distribute production workload between different lines,  determine when serial numbers should be ready, cancel production on one line, and move to another or plan some lag in time, so that serial numbers may, if internet connection is not reliable be downloaded to printer or line server. 

For this purpose, the Job scheduler component should make use of templating, where the following attributes should be taken into consideration: 

  • Point of print – this can be an actual printer, but it can also be separate facility running a different CureSync instance or tenant. The Work order can come with a predefined printer or production line, floor or facility. Or, manual entry may be required if data is missing. Also, it must be possible to distribute the workload to several printing points, cancel printing, or to transfer any remaining quantity to a different location. 
  • Schedule – adjustment of exact deadlines when serial numbers are required by printers or line servers 
  • Assignment of other templates based on a work order – this enables the component to use data from the work order (product, territory/market, etc) what labeling will be used, structure of serial numbers, what type of logistic, etc.
  • Other than the printer, an aggregation station can be used, and those tasks are also scheduled using the same principle. 

Task Forwarder 

Complex organizations may use several tenants to streamline their production. Some tenants may simply pass part or whole production details to other tenants, or even other instances – e.g. subsidiary company, CMO, etc. In these cases, the parent company and subsidiary may have different market authorizations, and licensing may be non-exclusive. To move a production order (meaning an order for printers to print and verify labels) to a physical printer, sometimes a hierarchy will be formed, where the Task Forwarder will simply route a request to lower levels of the organization, where further data will be added as needed. If the requestor is not aware of the actual printers and workload distribution, the Task Forwarder will route the production order to the Scheduler, who will define the next routing, until the actual print and verify equipment is reached and order processed.  

A return message should be returned to the initial requestor, however at the tenant level, operators and users can interrupt the process and perform the tasks (through Job Scheduler). 


This component communicates with the external enterprise environment, if needed, using native language to communicate to devices such as printers, aggregation stations, bar code readers, etc.  

Due to the diversity of external enterprise systems, translation algorithms used to communicate to the production line are built as separate components. The component is integrated with the Serialization Orchestration component, as commands for data exchange are commonly executed from the process server.  

The component itself has internal inputs, listeners that are receiving messages through the integration layer or from the application itself, and communicates to external systems and devices. Those components it is integrated with include:

  • Electronic Product Code Information Services (EPCIS) 
    EPCIS is a GS1 standard that enables trading partners to share information about the physical movement and status of products as they travel throughout the supply chain – from business to business and ultimately to consumers. It helps to answer the “what, where, when and why” questions to meet consumer and regulatory demands for accurate and detailed product information. 
    The goal of EPCIS is to enable disparate applications to create and share visibility event data, both within and across enterprises. This sharing is aimed at enabling users to gain a shared view of physical or digital objects within a relevant business context. 

    The EPCIS component includes the following parts: 
     - Data Definition Layer that defines a standard model for visibility events.
     - A Service Layer that defines two standard interfaces:  
       - The EPCIS Capture Interface (events) by which EPCIS data may be delivered from a capturing application to an EPCIS repository or other system capable of receiving EPCIS data.
       - The EPCIS Query Interface by which EPCIS accesses applications and trading partners may obtain EPCIS data after capture, typically by interacting with an EPCIS Repository. 

The basic unit of data in EPCIS is a structure that describes the completion of one business step within an overall business process; this structure is called an EPCIS event. A collection of EPCIS events provides a detailed picture of a business process in terms of time and place. 

The information content of a single EPCIS event is organized into four dimensions:  

  • What  
    The identifiers of the object(s) or other entities that are the subject of the event 
  • When   
    The date and time when the event took place, and the local time zone in effect 
  • Where  
    The identifier of the location at which the event occurred, and identifier of the location where the object(s) are expected to be following the event 
  • Why   
    Information about the business context, including: an identifier that indicates the business step taking place (e.g., shipping, receiving, etc.), an identifier that indicates the business state of the object(s) following the event (e.g., active, recalled, damaged, etc.), identifiers of the shipping and receiving parties (if the event is part of a process of transfer between parties), links to relevant business transaction documents (e.g., a purchase order, an invoice, etc.), instance- or lot-level master data, and/or other information defined via user extensions. 
  • Who  
    Information about the user/device who performed the action. 

Serialization Orchestration 

This component is a standard, readymade component that is integrated into the CureSync. It uses Business Process Modeling Language (BPML) to create executive structures (BPEL – Business Process Execution Language) and support graphical interfaces to describe serialization processes at the customer site.  

This component handles serialization process and orchestrates functionalities, events, alarms and notifications. It covers the following high level functions: 

  • Long running stateful processes and short running stateless or stateful processes 
  • In memory process execution for short running processes 
  • Message and time triggered message handling 
  • Secure invocation of partners, processes securely 
  • Supports task, sub-process and call activity types 
  • Supports user, manual, receive, script, service and task types 
  • Define Workflows Interacting with People 
  • Supports Human  
  • Integration of people for performing tasks and receiving notifications 
  • Role based access control for activities 

Other CureSync Components 

Other CureSync components are used to support the main functions already described. Those components are: 

  • Authentication of the users, which enables CureSync to verify users’ access rights. This can use the internal credentials system, or external LDAP, e.g. Active Directory 
  • Authorization of the users is performed by assigning roles to the users, either internal (system users) or external (partners or IT systems accessing CureSync). Roles are created by assigning actions from a list of available actions. 
  • Alarms, Events, Notifications is a component that handles system behavior if something unexpected occurs. All system messages are treated as events, e.g. a print order concluding successfully, and are further processed using Serialization Orchestration, which assigns a priority, and responds in order of priority) 
  • Approval paths allows easy alignment of system configurations without unnecessary revalidations. This is used by business users to adapt, modify, add business settings, e.g. serial number generation templates or label type without it being necessary to revalidate. Once the first system is configured with the new requirements, the change is sent through the Quality system for approval, and once approval is obtained, the change will become active. 
  • Audit trail is a general component that logs all of the information about changes into the system. From a forensic perspective it is easy to get answers to Who, What, When, Where questions, and information about the previous status of certain entities are provided, so it is possible to track all the changes from the moment of entity creation 
  • Signature confirmation when needed, it is easy to configure a request to the user to re-enter their password for any of the actions in the system. 
  • Attributes, Enumerations and Vocabularies - In order to secure flexibility, configurable items are allowed to be modelled using vocabulary-attributes component. Those configurable items are:
    • Products 
    • Subjects 
    • Market templates 
    • Printable Labels (1D, 2D, NFC content) 
    • User profiles 
    • Devices 
    • Organizational units 

Vocabularies are sets of attributes. Vocabularies can be grouped into hierarchies. Attributes should have validation rules, where the following types of validations are available: 

  • Allowed characters – either numeric or alphanumeric 
  • Length 
  • Number, with verification on greater than, less than 
  • Date (from, to) 
  • List with predefined value 
  • Boolean 
  • Placeholder for another attribute from other vocabulary  
  • Enumerations, including custom defined enumerations 

Multilanguage – CureSync allows each user to select from a list of languages, and the administrator is allowed to translate or adapt the language list, based on the company’s needs.

Dashboards – The system supports several dashboards which allow users to easily navigate to the most critical tasks, and newest events. The following dashboards are supported: 

  • Print queues 
  • Approvals  
  • Alarms, events, notifications  
  • Work orders 
  • ePedigree field information  
  • EPCIS events 

ePedigree information – Allows supplementation of EPCIS subject information with further data, e.g. warehousing or transportation temperature, etc.  Enables the provision of proper information to end users, including patients or inspectors using mobile technology. 



  • CMO's

    Can you continue your work without serialization solution? Since majority of MAH companies are outsourcing manufacturing to CMO’s you are...

    Read More ...

  • Generic and Originator Pharma

    Can I have 5 different solutions for 5 different markets? Most commonly manufacturers are operating on international market and their...

    Read More ...

  • Marketing Authorization Holder

    What are MAH obligation in regards to Serialization? MAHs are, from perspective of regulatory bodies, only legally recognized entities...

    Read More ...

  • Serialization

    Serialization is applying a traceable serial number to a smallest selling item. A serial number must be assigned to each selling item as...

    Read More ...

  • Supply Chain

    Wholesalers in the whole world are obliged to adapt to different regulations and directives, for example EU FMD – Falsified medicines...

    Read More ...

Working hours

+385 1 6264 199

08:00 - 17:00


Dear visitors, register your email address to receive all important announcement and news from TradeTicity.

We are here

Tvrtka: TRADETICITY d.o.o. za usluge / Skraćena tvrtka: TRADETICITY d.o.o. / Sjedište: 10 000 Zagreb, Ulica grada Vukovara 284 / Sud: Trgovački sud u Zagrebu / MBS: 080725073 / OIB: 32457970413 / Temeljni kapital: 3.700.000,00 kuna, uplaćen u cijelosti / Predsjednik uprave: Lidija Pozaić Frketić / Nadzorni odbor: Miodrag Mirčetić / Osobe ovlaštene za zastupanje: Lidija Pozaić Frketić / Banka i broj žiro računa: PRIVREDNA BANKA ZAGREB d.d. Zagreb / IBAN: HR9323400091110426328SWIFT address: PBZG HR 2X / ZAGREBAČKA BANKA d.d. ZAGREB / IBAN: HR9123600001102551948 / SWIFT address: ZABAHR2X