The Russia Serialization Pilot Guideline

The Russia Ministry of Health (MoH) is conducting a serialization and tracing pilot with a number of supply chain members between February 1, 2017 and December 31, 2017 (see “Russia Begins Its Pharma Supply Chain Pilot”).  The MoH is due to publish an assessment of the pilot by next February 1st

Two weeks ago the Russian Minister of Health, Veroníka Skvortsova, signed the guidelines document for the pilot.  The 42-page document appears to be written as a pilot setup document, as opposed to a firm regulation.  As such, it is clearly not intended to serve as a draft for a regulation, but is strictly describing a pilot (an “experiment”).  We can’t be sure what elements of the pilot will end up making it to the final regulation (assuming there will be one someday), but it is detailed enough that we can see where they are headed.  From that, you can make some pretty strong assumptions about what will likely be in the final regulation.  One translated sentence in the document is, “If the Pilot is successful, these methods of applying the barcode to the medicinal product package are planned to be maintained.”

The original document, in Russian, can be found on the website of the Ministry of Health of the Russian Federation (also known as the Federal Service For Surveillance in Healthcare, or “Roszdravnadzor”).  I have used Google Translate to construct a reasonable English translation, which you may download here.  This translation is OK, but it is definitely not perfect.  Please only use this translation as a check on your own professional translation and not as your sole basis for participation in the pilot or for compliance.

I noted the following details about the pilot in the English translation:

  • It makes solid use of GS1 identification standards, including:
    • Datamatrix barcodes on units and homogeneous cases;
    • GTIN-14 plus serial numbers that are more GS1 conformant, but are more restricted than the full GS1 specification (see below);
    • SSCC in Code-128 barcodes on non-homogeneous cases or logistics containers;
  • It does not make use of GS1 EPCIS;
  • It uses a non-GS1 conformant but “analogy” of the SSCC encoding of Code-128 barcodes for wholesaler constructed logistics containers, intended so that those companies do not need to obtain a GS1 Company Prefix (GCP) from GS1 Russia;
  • The unique identifier on secondary packaging (or the primary package in the absence of secondary packaging) (referred to as the smallest saleable package in the U.S.) includes the following data elements in any order (except the first element):
    • GTIN-14 using a GCP issued by any GS1 member organization (AI-01);
    • A unique (to the GTIN) serial number chosen by the barcode issuer (the manufacturer) (AI=21) (terminated with an FNC1 character);
    • TH Code, which is the first four digits of the 10-digit TN VED code (using AI=240) (terminated with an FNC1 character unless it is the last element) (Google “ТН ВЭД” for an explanation in Russian);
    • Optional batch identifier (up to 20 alphanumeric Latin alphabet characters) (AI=10) (terminated with an FNC1 character);
    • Optional expiration date YYMMDD (AI=17).
  • If the “DD” day of the month is not established by the manufacturer the data must be filled in with “01” to indicate the first day of the month.  Note that this does not conform to US Pharmacopeia guidance which recommends making this the last day of the month (see page 3 of USP General Chapter 7, Labeling).
  • The unique serial number data element must be 13 alphanumeric Latin alphabet characters long. This is a limited subset of the available serial numbers as defined by GS1;
  • The unique serial number data element must be randomly generated so that the probability of guessing the individual serial number is negligible and, in any case, less than one in ten thousand. This is comparable to the requirement of the European Union Delegated Regulation (EUDR) (see “Meeting U.S. and E.U. Drug Serialization Requirements With A Single Solution“).
  • Serial numbers may not be reused until the longer of:
    • One year after the expiration date of the product, or;
    • Five years after issuance;
  • Human readable text may appear on the secondary packaging at the discretion of the manufacturer.  Only the GTIN, serial number, lot and expiration data is recommended and a specific format is recommended in the document.
  • Homogeneous cases may be marked by the manufacturer with the following data elements in a Code-128 or Datamatrix barcode:
    • GTIN-14 (AI=01);
    • TH Code, (using AI=240) (terminated with an FNC1 character unless it is the last element);
    • A unique (to the GTIN) serial number chosen by the barcode issuer (the manufacturer) (AI=21);
  • End users will communicate with a government-run central repository. The central repository will apparently communicate with existing government licensing and registration databases using an existing (or under development) communications protocol/architecture/system, which includes the use of electronic signatures.
  • Instructions and applications are provided for Russian and foreign marketing authorization holders to apply for participation in the pilot.
  • Aggregation data should be captured and transmitted to the central repository.
  • Purchase/selling price is one of the data elements provided to the central repository.
  • Changes of custody between “addresses of the place of activity (under license)” without a change of ownership must be reported to the central repository.
  • Drugs removed from the supply chain must be reported with one of 20 reason codes that explain the removal.
  • Shipments and receipts of drugs must be reported to the central repository.
  • Five Russian governmental agencies will monitor various data supplied to the central repository.
  • The document provides the list of data element that must be reported to the central repository but does not provide the specific structure of the data or the communications protocol to use (except perhaps by reference to existing systems or those that may be under development).
  • End users appear to have 5 “working” days to register information in the central repository after the corresponding events occur.

What else do you see that should be noted?

Dirk.