Identity linked to the unit
The manufacturer or importer describes the medicine before issuing its identifier. The target format links the signed identity with the unit’s status in the registry.
The proposal starts with a medicine unit and the people who identify, query or review it. These criteria explain what should be checked and which limits each pilot should preserve.
These are proposal criteria, subject to implementation and validation. They do not establish an operation, an institutional relationship or results from other systems.
The manufacturer or importer describes the medicine before issuing its identifier. The target format links the signed identity with the unit’s status in the registry.
The architecture proposes a read-only copy for the authorised team. The programme must agree which events it may consult and how to compare them with the primary registry.
Printing a QR does not activate the unit. Activation is proposed after production ends and the product, lot and expiry record is complete.
A pilot can cover one presentation, one packaging line and defined owners. This allows each stage to be reviewed before extending the scope.
Issuance, printing, integration, support and review must be agreed before the pilot. Funding and participation conditions must also be agreed.
The QR and readable identifier refer to the same unit. The person compares medicine, presentation, lot and expiry; a digital match does not certify the physical contents.
The QR opens a lookup URL. People can also type the identifier or read an image of the code, without installing an application or creating an account.
The pilot must turn these criteria into concrete responsibilities and checks. This website lets people explore examples; it does not establish operational implementation.
Define the medicine, presentation, lot and pilot owners, with the data that people will be able to query.
The target architecture combines a signature to check issuer and integrity with a registry that retains states and signals. Lookups on this website use sample data.
The proposal avoids exposing a production counter in the identifier. The final format requires validation; its appearance does not establish security.
Define who covers printing, integration and support, and how pilot costs will be assessed. Amounts are agreed per programme.
Agree ownership, access, key custody and data export before deployment. These are not automatically assigned to the operator or an authority.
The architecture must define how to work during an interruption and recover pending events, without showing units as activated when their records are incomplete.
Agree how to void unused codes when an issuance closes and how to record that decision without erasing history.
Complete product, lot and expiry data and confirm which codes were used before activating units. Printing alone does not establish activation.
Show what to compare with the package and what to do about a difference. On this website a report is prepared and downloaded locally; handing it over requires an organization’s channel.
Define pilot permissions and responsibilities. Physical anti-copy features and tax validation belong to phase 2 and require authorised integration; they are not available here.
A digital record describes a declared unit. When looking up a medicine, the person must compare its data with the package; a photograph or a registry match does not prove its physical contents.
The proposed registry follows issuance, labelling, activation, lookup, signals and closure. It does not record transport, distribution or sales. Activation requires production to end and the record to be complete.
An issued and labelled identifier awaiting activation requires review. This website explains the state using sample records and lets people prepare a local report, without sending it or changing the registry.
Security and trust explains the proposed layers, key custody and their limits. The medicines use case sets out the pilot’s scope and responsibilities.