Serialization and Treacebility solution
for all requirements in Lifescience.

CureSync is enterprise level, flexible, easily integrated, high quality solution that is responding to the needs of all parties in pharmaceutical supply chain and to all known regulatory requirements accordingly.

Creative, adaptive and ever-ready solutions.

CureSync was written on pharmaceutical context having in mind full data integrity (including last MHRA, FDA and EMEA guidelines) as well as GAMP5 postulates.

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. CureSync covers L2-L5 levels of pharmaceutical serialization.

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. 

Becoming Familiar with CureSync 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. 

Application architecture
CureSync Functional Model

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.  

Overview
CureSync modules overview

 

Random number Generation

Creates and stores serial numbers, either randomized by a randomization algorithm, or sequential, with sequential steps. 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.

Random number Generation 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. 

Serial Generation

Governs all actions regarding the generation of serial numbers. In combination with the serial trader component, it enables an organization to plan and manage all possible exchanges of serial numbers, with external parties.

It consists of number generators, and template definitions, so the client may generate serial numbers using multiple random generation schemes to satisfy their different markets’ requirements. 

Serial Trader

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.

Serial number Trading

Purpose of this component is to enable sending to, and receiving from, external parties randomized numbers which will be used to create a certain number of serialized products.

CureSync Import Serials
CureSync Export Serials

This part of the system defines all external parties that will access the warehouse of serialized numbers (CMOs), or who will be the sources for accessing numbers that they produce (MAHs, or Government of China e.g.)

Product Catalogue

Is used to distinguish between different serialization needs for each individual product. The product catalogue is a hierarchical structure ending with each of the individual products. This system allows the creation of multiple catalogues, where catalogues may be assigned to organizational units if needed. Products are described by their attributes, which are defined using vocabularies.

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.

The product catalogue component can contain many product catalogues to cover the company’s complete product portfolio. This feature can be used in many ways, including to create a master product catalogue, however the simplest usage is to define products with accompanying serialization data which will be serialized, against those products that do not require serialization. Part of the Product Catalogue is packaging Configurator which defines how individual products are aggregated using templates. One product may have several packaging options, and each aggregation can be to unlimited levels, where each level may have certain attributes that are common, e.g. GTIN

CureSync Product Catalogue

Track and Trace Broker

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

Exchange data with internal and external EPCIS based systems, national agencies, distributors, etc. It receives and triggers EPCIS events, converts EPCIS to other forms, e.g. EDI, and updates the EPCIS data. It is possible to configure translation and standards and protocols, as well as vocabularies that are to be used between trading partners (e.g. EDI instead of EPCIS, or to translate between different XML-based software).

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:
    1. SFDA – Chinese national drug agency standard, which requires the party to obtain logistic and item numbers from a Central Database
    2. US DSCSA
    3. EU EMVS
    4. Brazil ANVISA agency standard for data exchange
    5. MOH Turkey standard
    6. 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.

The EPCIS component is placed at the back end of the Supply chain bus. This component can be used as:

  • An internal CureSync component
  • An external instance of an EPCIS component (CureSync)
  • A 3rd party component

Subjects (partners) management

This part of the system defines all external parties that will exchange data with the CureSync System, namely:

  • Trading partners e.g. distributors, wholesalers
  • Internal organizational units which are not included in the CureSync instance or running separately
  • Government agencies and data exchange repositories

At the highest level, the Vocabulary categories are of following types:

  • PARTNER
  • TRANSPORTATION
  • DOCUMENTATION
  • USER DEFINED 

 

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

Organizational Structure

Component allows the administrator to model their organization in terms of product serialization. It consists of serialization building blocks, which may be of different types:

  • Organizational Units represent blocks such as Headquarters, Sites and Subsidiaries where business procedures are defined, and from where business requests may start, or to where reports are delivered
  • Production Units describe the hierarchy where physical production occurs, e.g. Locations, Sites, Floors and Production Lines
  • Equipment blocks represent physical devices, including Print and Verify equipment, packaging devices, handheld devices and line managers all which require integration.
  • IT Systems represents other systems that could be sources or destinations of information and where the system integration will be performed.
  • Warehouses represents warehousing locations, which can be organized into a hierarchical structure, e.g., when a central warehouse is divided into smaller stock locations.
CureSync Organizational Units

Settings and templates

are used to satisfy the most demanding requirements, CureSync supports the creation of different templates and settings.

Market Content Standard

This feature enables the configuration of different labeling standards. It defines how the label is created, and the content of code identifiers (AI in GS1).

CureSync Templating

Market Templates

Market templates are templates that are a central heart of all printing logic. Each market template contains:

  • A descriptive name, referring to a market, e.g. Germany
  • Unique product identification used for that market, e.g. IFA PZN
  • External interface describing the translation schema for communication between CureSync and the central repository, where numbers will be received
  • Serial number template, describing the template which will be used for the generation of serial numbers
  • Selected content template, containing what is coded into the barcode (either 1D or 2D) and how.
  • Descriptive names for the human readable data (if required)
  • Additional printable labels, if needed (e.g. Product name, etc.)

eServiceConnector

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)

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.
CureSync EPCIS

Serialization Orchestration and Integration component

is a standard, readymade component that is integrated into the CureSync. Business Process Modeling Language (BPML) is used to create executive structures (BPEL – Business Process Execution Language) and support graphical interfaces to describe serialization processes at the customer site. Integration layer is used to easily integrate solution internally, within the Client environment (MES, ERP, WMS, P&V etc.) and externally (National Agency, CMO’s, MAH’s Wholesales etc.).

Serialization Orchestration 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
CureSync Process Model

Adapted Integration layer, able to handle all necessary communication and easily transform and transfer messages between different standards and protocols. It includes 45 Enterprise integration patterns with over 150 endpoints which enable connection to various sources and end point seamlessly.

CureSync Integration

User management, roles and responsibilities

In order to provide maximum security, the system supports an internal or external authentication method, while authorization can fine-tuned using set activities grouped in roles, e.g add new product, edit product, etc.

Activities are grouped into roles, and roles are finally assigned to users.;

CureSync Templating
  • 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.
  • User lock – configurable automatic user locking upon reached number of unsuccessful login attempts. Administrator of the system can manually disable user rights to login to the system.
  • Logging log – each logging attempt, successful or unsuccessful, is registered within the system.



Quality standards

To ensure alignment with quality standards within organization compliant with 21 CFR Part 11 additional components (Approval paths, Signature confirmation, Audit trail) are incorporated within the CureSync Solution.

Approval paths

This ensures alignment with Quality standards within the organization. For any change, made at the business level, such as adding or deleting items, modifying vocabularies, creating templates, etc., it is possible to configure in administration settings approval paths, consisting of all information needed to approve the request. A path can consist of up to 3 steps: request, review and approval, where review and approve can also be created. 

Signature confirmation

If the site operations are compliant with 21 CFR Part 11 the logged in user must confirm authenticity by retyping password. This, digital signature is assigned to any activity within the system, and can be defined when it will be triggered using Administration console.  

Audit trail

Features of this component allow users to examine changes that occurred to all information pieces. Each change is logged into system, with details of who, what, why, when are associated with the changes. If there are several changes, it is possible to drill through the history, easily noticing how the information changed over time. The Audit Trail displays the complete information entity before the change, and provides all details of all subsequent changes. Data in the audit trail can be viewed but not altered. All changes of information is captured in the audit trail.

Other CureSync Components

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

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

 

 

Solutions

  • 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

MONDAY - FRIDAY
08:00 - 17:00
SATURDAY - SUNDAY
CLOSED

eNewsletter

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, Strojarska cesta 20 / 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ć / Član uprave: Vjekoslav Benussi / Nadzorni odbor: Miodrag Mirčetić, Boštjan Bavdek, Maks Strajher / Osobe ovlaštene za zastupanje: Lidija Pozaić Frketić, Vjekoslav Krešimir Benussi / 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