Brazil is one of the markets that is pushing hard to implement legislation. While anti-counterfeiting is one of the drivers for the initiative the high risk of tax evasion is definitely an additional issue that the BRazilian Government wants to tackle.

The Brazilian government body ANVISA published Resolution RDC 54  on December 10th, 2013. RDC54 already covers quite some details about how track and trace in Brazil should look like. It clearly states the applicability to all prescription drugs subject to registration at the National Health Surveillance Agency and explicitely includes free samples!

In addition the following requirements are included:

  • Serialization on unit level is explicitly required.
  • It is also required by the Registration Holder to track any unit down to the point of dispensing.
  • Imported products have to be serialized before import.
  • Tracking will be based on the Unique Medication Identifier Code (UIM), which includes
    • Medication Record number at Anvisa (13 digits),
    • Serial Number (numeric 13 digits),
    • Expiration Date,
    • Lot Number.
  • Aggregation is required as per Art 9 §2 which states that the transport packaging must contain an identification code in which all IUM that composes the packaging is related.

Chapter 3, Art 7 explicitely calls for non-deterministic randomization of serial numbers and for serial numbers that must be unique across the product produced by the MAH. In the meantime it was clarified however that both requirements wil be implemented in a reduced fashion: deterministic randomization will be accepted and only the serial numbers for products that will be sold in Brazil have to be unique.

As per the orginal legislation as defined in RDC 54, no central government operated database was planned. However, in the recently published “Normative Instruction” of August 2014 a government database is explicitly mentioned. In addition, the Normative Instruction covers the following:

  • Necessity to communicate events from Medication Registration Holder (=MAH) to Anvisa (Art. 1, Art. 10)
  • Necessity to communicate events between supply chain participants (Art. 1,§1, Chapter III). This means that every participant in the supply chain has to send logistic events
    • to the MAH (Art. 4),
    • to the receiving chain member (Art. 6) and
    • to the previous supply chain member (Art. 4) .

Supply Chain members also have to send all communication received from the posterior chain member to the previous chain member and the MAH (Art. 5) and have to send differences between declaration and real product to both to previous supply chain member and MAH (Art. 6, §2)

  • The MAH is responsible to monitor logistic movements (Art. 1,§4) as defined in Art 2, Chapter II, including the Creation (medication “emerges”), Change of ownership (“passage between members”) and Decommissioning (“extinction”) of medicinal products.
  • Art. 3 cover the definition of “Logistic Events” and includes „purchase“ and „sales“ which in SAP‘s view are not logistic events and needs to be further clarified, but it also explicitely includes Free Samples.
  • The normative instruction also includes the requirement to report “anormalous events” (Art. 12) like movement of medication with IDs not generated by MAH, Duplication of IDs and rReporting of decommissioned IDs.

So overall, this will result in a huge number of messages being sent back and forth as layed out in the use cases below.





To ease the pain of sending all the messages back and forth a network model is currently in discussion and in the past few weeks some more details have emerged through the collaboration with the different stakeholder organizations like interfarma and Sindusfarma. Stay tuned for some more news!

PS: The original documents and english translations are available and can be shared with SAP Customers.

To report this post you need to login first.


You must be Logged on to comment or reply to a post.

    1. Oliver Nuernberg Post author

      Hi Karthik,

      I think that’s already available through the SGTINs. Those are basically a combination of a GTIN and the serial number. As the GTIN in itself differs by Country, MAH (Market Authorization Holder) and product, the additional serial number should make any unit absoluely unique. So there shouldn’t be any 2 units worldwide that carry the same SGTIN.

  1. Oliver Nuernberg Post author

    One additional thought with regards to the message volume that the choreography displayed in the blog will result in:

    In Pic #4 I depicted a 3-tier supply chain. If we assume that a drug will be dispensed to the patients in the smallest sellable unit, each unit will result in 3 messages that reach the MAH. So roughly, just for scenario #4, we can assume that any batch of x (e.g. 10.000) units that will be distributed along a suppy chanin of y (e.g. 3) tiers will result in x*y (e.g. 10.000 * 3 = 30.000) messages.  Right?

  2. Oliver Nuernberg Post author

    Additional Comment: The TECHNICAL NOTE No 01-2015 clarified that the dispensing doesn’t have to be reported back along the supply chain, i.e. Art. 4 doesn’t apply for the dispensing operation. Therefore also the messages according to Art. 5 and Chapter VI in the picture above do not apply and the last picture is therefore obsolete. Original can be found here.

    A translation of the relevant Chapter V.1 from one of our customers reads like this:

    The RDC No. 54/2013 establishes that the tracking in the point of view of the registration holder will be performed until the entry into the dispensing unit. This will result in the registration of dispensation/release event in the database of dispensing units, which is not
    communicated to the previous links.

  3. Stefan Artlich

    Let me just add two remarks that will be definitely interesting for the colleagues responsible to equip the production lines but maybe as well for the IT guys:

    • ANVISA has not defined the details of the data carrier to be used. The industry i.e. all stakeholders incl. wholesalers and pharmacists seems to be aligned to use the GS1 DataMatrix code. This means that in addition to the IUM elements listed in the article above the GTIN needs to be added as data element.
    • With regard to the human-readable printing of the data it must not be forgotten that due to a legislation from 2009 manufacturers are obliged to print the manufacturing date in human-readable format. However, this does not need to be encoded in the DataMatrix code.

Leave a Reply