Can You Scan a Medicine Package to Open Regulator-Authorised ePI?

What counts as regulator-authorised ePI?

Electronic product information is not simply a PDF leaflet placed on a manufacturer website. EMA describes ePI as authorised medicine product information made available in a structured electronic form.

That authority boundary is important because a medicine package can lead to many digital destinations. A manufacturer page, a private medicines-information service and a regulator-authorised ePI may all contain useful content, but they are not interchangeable.

For this question, the useful chain is:

The central point is simple: authoritative ePI, product identity and consumer scan resolution are three different layers. Progress in one does not automatically complete the others.

What became materially more concrete in 2026?

The strongest change is the implementation layer.

On 1 September 2026, the European Medicines Agency published the EMRN ePI Implementation Guide v1.0.0 as a final release. The guide is based on FHIR R5 and defines the structures used to represent ePI. That is a significant step beyond an early pilot or a high-level concept.

EMA also provides publication infrastructure for ePI and an official public API through which authorised ePI can be exposed programmatically. This means a digital service can, in principle, retrieve regulator-managed ePI through an official machine interface rather than depending on an unofficial copy.

The important qualification is deployment. A final FHIR guide tells you how the information can be structured and exchanged. An API tells you that an official electronic endpoint exists. Neither proves that an arbitrary code on an EU medicine package is already connected to that endpoint.

Where do product and package identifiers enter the architecture?

EMA's current ePI navigation guidance makes the product-binding layer much more concrete.

Published ePI can be linked to medicinal products in the Product Management Service, or PMS. Where those links exist, the ePI document can carry PMS medicinal-product identifiers and Data Carrier Identifiers associated with the linked product record.

For centrally authorised products, or CAPs, the current applicant guidance goes further: the ePI-to-authorisation and product relationship is mandatory and includes EMA and EU identifiers.

That is useful evidence because it closes an earlier architecture gap. It shows that regulator-authorised ePI does not have to sit as an isolated document. It can be bound to regulatory product identity.

But three statements still need to be kept separate:

1. a data-carrier identifier exists in the product data;
2. an authorised ePI is linked to that product;
3. a consumer scans a physical pack and is resolved to the correct current ePI.

The first two now have concrete EMA implementation support. The third is still emerging.

CAP linking is not the same as universal medicine linking

The CAP evidence is strong but bounded.

Centrally authorised products use an EMA-managed authorisation route. EMA's current applicant guidance makes the relevant ePI linking explicit for this route. That should not be generalised into a claim that every nationally authorised medicine across the EU already follows the same mandatory package-to-ePI chain.

Some wider product-document linking workflows remain optional. Optional linking can still be useful operationally, but it is not the same thing as a common consumer access rule.

This is one reason the overall maturity of the package-scan proposition remains EMERGING, even though several of its underlying components are now real and operational.

What would a medicine package scan still need to do correctly?

A safe package-scan experience needs more than a readable code.

It needs to establish the right product identity, resolve that identity through a trusted route, return the correct authorised ePI for the relevant product and jurisdiction, present the current version and fail safely when a match is unavailable or ambiguous.

For an implementation team, the minimum controls are:

That last point matters beyond medicines. Digital access does not automatically remove requirements for physical information. The wider boundary is covered in when digital product information can and cannot replace labels, manuals or CE marking.

What does the EMA package-scan work prove today?

EMA and the wider regulatory network are actively considering package scanning as a route into ePI. Current PLM material describes a direction towards an industry-led EU-wide solution.

That is meaningful because it shows the access problem is being addressed at regulatory level. It is also the strongest reason not to overstate the present state.

A reflection, consultation or implementation direction is not the same as a final common rule. It does not prove that medicine packages across the EU already carry a standard code which resolves to regulator-authorised ePI.

The correct maturity statement is therefore:

• NOW: regulator-authorised ePI infrastructure, a final implementation guide, publication/API capability and concrete product-identifier relationships exist;
• EMERGING: consumer package-to-authorised-ePI scanning and broader consistent product-document linking;
• POSSIBLE: a consistent cross-jurisdiction experience across centrally and nationally authorised products using common carrier and authoritative endpoint conventions;
• NOT SUPPORTED: universal EU deployment today, or the idea that any medicine QR/DataMatrix is automatically an EMA ePI resolver.

Do not treat the ePI pilot browser as current medicine advice

EMA maintains a publicly browsable ePI pilot environment. It is useful evidence that structured ePI can be displayed and navigated.

It is not evidence that the pilot is the authoritative source a patient should use for current medicine advice, and it is not proof of production package scanning. The pilot needs to remain labelled as a pilot.

This distinction is especially important in medicines because the consequence of stale or wrongly matched information is much higher than on a generic marketing page.

What should an implementation team do now?

If you are designing a medicine package-to-digital-information journey, start from authority rather than from the code format.

First, identify which regulator-authorised product information must be returned and which authorisation route it belongs to. Then map the product and package identifiers that can bind the physical presentation to that information. Only after that should you decide how the package carrier and resolver will expose the route to a user.

Do not use the existence of a DataMatrix, QR code or FHIR endpoint as a proxy for the whole chain being complete.

And do not design the digital path on the assumption that physical medicine information can simply disappear. The existence of ePI does not, by itself, remove every paper, label or package-information obligation.

Claims not to make yet

The current evidence does not support the following statements:

• every EU medicine package can already be scanned to regulator-authorised ePI;
• an arbitrary medicine QR code or DataMatrix is an EMA resolver;
• final EMRN FHIR v1.0.0 means market-wide package scanning is deployed;
• ePI universally replaces the package leaflet or all physical product information;
• the EMA ePI pilot browser should be treated as current medicine advice.

Those are deployment or legal conclusions that go beyond what the accepted evidence proves.

What would change this answer?

Recheck this page if EMA or the Heads of Medicines Agencies publish a final package-scan position, a common carrier or resolver requirement, wider mandatory product-linking rules, a material change to the public ePI API or a move from pilot package scanning to formal production use.

While package-scan policy remains active, this boundary should be checked frequently.

Status as at 4 September 2026: the regulator-authorised ePI rail is real; the universal consumer package-scan route is not.

Primary sources

• European Medicines Agency, EMRN ePI Implementation Guide releases, v1.0.0 final, 1 September 2026: final structured implementation milestone. It does not prove universal package-scan deployment.
• European Medicines Agency, Electronic product information (ePI): regulator definition and implementation context for authorised ePI.
• European Medicines Agency PLM, ePI Navigation guide for Applicants: product/ePI linking, CAP requirements and data-carrier identifier relationships.
• European Medicines Agency, ePI public API: official programmatic access layer.
• European Medicines Agency PLM, package scan reflection / consultation: evidence that an EU-wide package-scan route remains under development rather than universally deployed.
• European Medicines Agency PLM, ePI pilot browser: pilot evidence only, not a current-authoritative medicine-advice surface.