Use case · Medicines

Pilot proposal

The QR is born with the medicine

Each 120 ml oral-solution bottle carries a unique QR from its packaging. The identity is issued, printed and activated after production; every subsequent lookup compares the unit with its record.

This case is presented as a pilot proposal addressed to a medicines regulator. It does not describe an official implementation, does not imply a contractual relationship and does not claim the participation of any agency.

The problem it sets out to solve

A lot identifies a group; the Traza QR identifies each unit. Bottle and carton support comparison of product, concentration, dosage form, manufacturer or importer, health registration, lot and expiry. The example data does not refer to an authorised medicine.

Field inspection faces a volume it cannot cover without signals to guide it. Teams go where they can, not necessarily where they are needed, and what they observe is rarely linked to the unit’s registry record.

The public, for its part, has no simple way to verify what it buys. Tools that require installing something or creating an account are not used at the moment of purchase. The proposal starts from that reality: web-based verification, with no installation or account, at the point of sale.

Proposed scope of the pilot

The pilot is proposed with a narrow scope: a set of products, a small group of chain actors and a defined period, with field inspection included from the start.

  • Signed unit-level identity

    Each unit receives a unique identifier, signed by the manufacturer or importer that places it on the market.

  • Direct printing on the packaging

    The QR is printed on the carton, label or seal during packaging. Every unit retains its identifier; one code is not reused for the entire lot.

  • Lifecycle event recording

    Issuance → printing → activation after production → lookup and control. Closing the lot record activates only the units actually produced.

  • Web-based public verification

    Anyone verifies from the browser and receives a result explained by signals, with the regulator’s context.

  • Field inspection

    Inspectors verify on site, check against the registry and record what they observe within the pilot itself.

  • Discrepancy reporting

    Whoever detects a difference between the unit and the registry can report it with minimal, optional data.

Visible identity. Connected traceability.

Twelve features of the stamp.

The proposed stamp brings together each unit’s identity and medicine details. The QR opens its lookup; the barcode represents the example print sequence.

Illustrative Traza 120 ml oral solution label designed as one complete piece.
Label design concept. The functional QR and twelve fields are shown below.

The unit data, field by field

PUBLIC AND/OR PRIVATE COMPANY EXAMPLE
Unique identifier TRZ-7F2K-4K7Q-92FA
Destination territory Defined for each implementation
Medicine name Solución oral Traza
Net contents 120 ml
Dosage form and strength Oral solution
Not stated
Manufacturer or importer · health registration Laboratorio Cerro Alto
RS-EJEMPLO
Lookup website traza.technology
Print sequence 000001 Example print sequence
BarcodeCode 128
Issue date
Production batch LOTE-VS-26-012
Example data does not identify a commercial medicine or an existing institutional relationship. Territory and printing conditions are defined for each implementation. The label image is an illustrative concept, not a print-ready label or proof of physical security or fiscal validity. Looking up the QR does not certify the package contents.
  1. QR code

    Opens this unit’s public URL. A copy of the graphic retains the same identifier.

  2. Unique identifier

    The readable ID matches the QR and can be entered manually to look up the unit.

  3. Destination territory

    Defined for each implementation. This example declares no jurisdiction or actual territorial operation.

  4. Lookup website

    The visible domain shows where to look up the identity, including outside this page.

  5. Print sequence

    An example number for the printed piece. It is separate from the unit identifier.

  6. Barcode

    A readable Code 128 symbol encoding the example print sequence. It represents neither GS1 identification nor fiscal validation.

  1. Net contents

    Volume comes from the registered presentation: 120 ml for this unit.

  2. Medicine name

    The name lets people compare the package with the record of the unit being checked.

  3. Dosage form and strength

    Dosage form and strength matching the example medicine.

  4. Responsible party and health registration

    Manufacturer or importer and declared health reference. RS-EJEMPLO does not represent official approval.

  5. Issue date

    When the identity was issued. It is separate from production, activation or expiry.

  6. Production batch

    A separate field matching the batch of the unit being looked up.

Who takes part

The proposal describes six roles. Each one sees the registry with the level of detail that corresponds to it.

  • Medicines regulator

    Defines the framework, governs the registry, follows anomalies and reports, and directs field inspection. In the proposal, this role corresponds to the recipient of the pilot.

  • Manufacturers and importers

    Request identities for their units and complete product, concentration, dosage form, health registration, lot and expiry. They are responsible for the declared data.

  • Production and packaging

    Print identifiers on packaging, check readability and close the record when production ends. This confirmation activates the codes used.

  • Pharmacies and dispensing points

    Make the code available to the public and compare packaging with its record. The pilot does not record sales, transport or distribution.

  • Field inspectors

    Verify on site, check the physical unit against the registry and document what they observe.

  • The public

    Verifies at the point of sale, reads a clear result and reports if something does not match.

Target architecture

The proposal describes the architecture the pilot would be designed toward. It is presented as a target, not as a built system.

  • 01

    Unit-level identity signed with ECDSA P-256

    Each identifier is signed with elliptic-curve cryptography (ECDSA P-256) using keys managed by the issuer. It is proposed as the standard for the use case.

  • 02

    Web-based public verification, with no installation or account

    A web service evaluates signature, registry status, data match and anomalies, and returns an explained result.

  • 03

    Lifecycle event registry

    A record of issuance, printing, activation, lookups, signals and closure, with responsible party and date. No logistics movements need to be recorded.

  • 04

    Field inspection within the pilot

    Tools for inspectors to verify on site and record observations linked to each unit.

  • 05

    Discrepancy reporting

    A public channel to report differences between the unit and the registry, with minimal, optional data.

  • 06

    Anti-copy and tax validation · phase 2

    Physical anti-copy measures and validation of tax payments would be evaluated in a later phase. Tax validation depends on integration with and authorisation from the competent authority; it is not available in this example. A digital signature alone does not prevent copying a label.

Target architecture for the proposal: not implemented yet. Its development and audit form part of the scope that would be agreed with the institution.

Field inspection is part of the pilot

The proposal does not defer field inspection to a later phase: it includes it from the start. Signals from the registry guide the teams, and what they observe on site flows back into the registry. What arrives later is the dedicated inspector application; at first the work is done with the same web pages and the institutional views.

  • On-site verification with the same web page the public uses, with additional views for the inspector
  • A record of each inspection linked to the unit and the point of sale
  • Prioritization based on anomalies and discrepancy reports
  • Feedback into the registry: what is observed in the field updates the status of the unit

Conditional co-brand

The proposal allows a public and/or private company to present verification alongside Traza. The band and example use the Traza palette; each participant’s brand requires authorisation.

The “EMPRESA PÚBLICA Y/O PRIVADA | TRAZA” lockup is an example of a conditional co-brand included in the pilot proposal. It is shown in typographic form, without any official emblem, and its use depends on the institution’s approval. It does not imply an official relationship, endorsement or approval.

See verification with the sample tenant

Pilot proposal Medicines

Example co-brand for a pilot proposal. It does not imply an official relationship, approval or implementation.

The tenant lockup shown is a co-brand example included in a pilot proposal. Its use is subject to approval by the corresponding institution and does not imply an official relationship, endorsement or approval.

What this proposal does not claim

To avoid confusion, we put in writing what this page does not say.

  • It does not claim that an official implementation or a working system exists.
  • It does not claim a contractual, commercial or institutional relationship with any company, authority or agency.
  • It does not present pilot figures: quantities, timelines, costs or results.
  • It does not claim production-grade security: the architecture described is a target whose implementation is audited in each deployment.
  • It does not offer legal or regulatory conclusions; the proposal does not replace the regulatory analysis that may be required.
  • It does not authorize the use of any institution’s brand or emblem; the lockup shown is a conditional example.

See the use case in the platform

Public verification with the sample tenant, the lifecycle of a medicine bottle and the institutional view show how the pilot would look.