National Blueprint System Slovakia Kick-Off Meeting Kick-off Meeting Slovakia 2.pdfOffline bulk transactions contain transactions with heterogeneous products and transaction types

Nov. 22th, 2017 | Kick-Off | SOOL 1

National Blueprint System SlovakiaKick-Off Meeting

BratislavaNovember 22th, 2017


Agenda

Arvato

Architecture

NMVS Web Service Interface

Important Business Processes

Project Plan high level


Bertelsmann at a Glance

€17.0 billionGroup revenues

€2.6 billionOperating EBITDA

€1.1 billionGroup profit

116,434Employees


Arvato –A leading international service provider

Service portfolio

CRM solutions

170 million online credit checks performed per year

SCM solutions

more than 1,1 billion parcels delivered a year

Financial services

600 million customers serviced in customer loyalty systems

IT services

Runs more than 70 online shops for numerous international fashion brands

€3,838mRevenues

€359mOperating EBITDA

68,463Employees

GüterslohHeadquarters


Estimating to cover more than 70% of all FMD packs within the EEA by 2019

Agreements and ongoing projects:

Arvato‘s NMVS Customers


Agenda

Arvato

Architecture





We have to master one central challenge

But many stakeholders are involved in the establishment of a NMVS

a) Organizer

• NMVO

• EMVO

b) Primary distributors

• Marketing authorization holders

• Contract manufacturers

• Wholesalers

• Parallel distributors

• Public pharmacies

• Hospital pharmacies

c) Software providers

• Solidsoft (EMVS/EU Hub)

• Arvato (NMVS)

• Pharmacy/hospital/wholesalerSW providers/IT departments

d) Authorities

b1) Secondary distributors

• Army

• Prisons

• Airlines

• Nursing homes

• Drug treatment centers

• NGOs

• ...


What is the time for a new serialized medicine to make its wayfrom the manufacturer to the patient?

MAH PatientPharmacyWholesalerManufacturer

How long it takes until new serialized medicines arrive at thepharmacies depend on several things. (In Germany ~140 days)

How long will it take in Slovakia?

Dependencies have significant effects


System Architecture Overview Decentralized integration scenario

Disp. DoctorDisp. Doctor

MAHMAH

Pharmacy

MAH

Hospital

European Hub(EMVS)

Local pharmacy software installation, bundles communication with all dispensestations

Product/pack data upload

Legend

Verification dispense,etc.

Disp. Doctor

Pharmacy

Pharmacy

Pharmacy

Hospital

Hospital

National Repository(SOOL)

Local hospital software installation, bundles communication with all dispensestations

Wholesaler

Wholesaler

Local wholesaler/par. distr. software installation, bundles communication with all local stations for verification etc.

Dispense(Web GUI)

Par. Distr.Par. Distr.

(MAH)

Par. Distr.(Wholesaler)

Legend

Digital certificate, issued by Arvato

Digital certificate, issued by EMVO

Pharmacy

Product/ pack data

upload

Multicountryrequests


Agenda

Arvato

Architecture





Pack Status Transitions

Supplied(Dispensed)

Active

Exported

Checked Out

Free Sample

Sample

Destroyed

Locked

Stolen

Verify Pack

Legend

Active states

Inactive states

Terminal inactive states

Dispense

UndoDispense

UndoExport Undo

Check Out

UndoSample

UndoFree Sample

Undo Lock

Lock

Destroy 2)

Mark as Stolen 2)

Export

Check Out

Sample

Free Sample

Verify Pack 1)

1) Verify Pack is available in all states2) Undo destroy/stolen is technically available in Arvato‘s NMVS

but will not be authorized for usage until the URS says so.

Verify Pack 1)

Verify Pack 1)


Status of a Pack (Serial Number)

1)

Inactive

1) The expiry data can be extended or shortened by the MAH after the batch data have been submitted.

Extract from the EMVO URS:


(1) Single Pack transactions

• Submit Single Pack TransactionSingle pack transactions, e.g. Verify Single Pack, Dispense Single Pack, Destroy Single Pack

• Undo Single Pack TransactionReverse single pack transactions, e.g. Undo Dispense

(2) Homogenous Bulk transactions

• Submit Homogenous Bulk TransactionsBulk transactions are lists of transactions with the same product, batch id and transaction type. They are generated by wholesalers to handle large quantities of packs, e.g. Bulk Verify Packs, Bulk Export Packs.

• Request Homogenous Bulk Transactions ResultBulk transactions are processed asynchronously. These web services are used to fetch the results of previously submitted bulk transactions.

(3) Mixed Bulk transactions

• Submit Mixed Bulk Transactions (“Offline Recap”)Offline bulk transactions contain transactions with heterogeneous products and transaction types. They are generated by pharmacies when the local transaction buffer is emptied after an offline period.

• Request Mixed Bulk Transactions Result (“Offline Recap”)Offline bulk transactions are processed asynchronously. These web services are used to fetch the results of previously submitted offline bulk transactions.

Transaction typesOverview


Agenda

Arvato

Architecture





EU Hub Product Data Model

Extract from EMVO User Requirement Specification (URS) :

A part of the product

master data is to be

provided per market

Product master data

(especially market

specific data) may

change over time.

Only GTIN and PPN formats are possible


MAH FI

OBP 4)

Product Master Data & Market Data Distribution - Example

MAH SE

MAH NO

European Hub(EMVO)

Product Master Data(Multi Market Product FI/SE/NO)

OBP uploads Product Master Data (product data common to all markets)

MAH NO uploadsProduct per Market Data NO 1,2)

to OBP system

NMVS FI

NMVS SE

NMVS NO

Product Master Data 3)

Product per Market Data NO 1)

Product per Market Data SE 1)

Product per Market Data FI 1)

1) Product per Market Data must contain the MAH Name of the corresponding MAH.2) An OBP uploads Product per Market Data on behalf of the MAHs.3) The EU Hub does not send the OBP ID to the National Systems.4) An OBP (Onboarding Partner, e.g. Roche, Bayer) grants marketing rights for its own medicaments (patents, brand names) to localMAHs

(Marketing Authorization Holders). See also https://emvo-medicines.eu/faq/ „What is an OBP? What is an MAH?“

EU Hub sends Product Master Data andProduct per Market Data as a joint data set

MAH SE uploadsProduct per Market Data SE 1,2)

to OBP system

MAH FI uploadsProduct per Market Data FI 1,2)

to OBP system

OBPSystem

With each change, the OBP systemsends Product Master Data andProduct per Market Data as a jointdata set (all data need to be presentbefore that)

Example: Multi-market product is available in FI, SE, and NO

4)

4)

4)

https://emvo-medicines.eu/faq/


Batch and Pack Data DistributionMulti-Market Product

MAH FR 1)

NMVS FRBatch FRQXF OBP

Batch and pack data (Batch ID „FRXQF“)for product 04266567890128uploaded by French MAHvia OBP system

MAH BE 1)

NMVS BE

European Hub(EMVO)

OBPSystem

The EU Hub sends each batch of multi-market product 04266567890128to FR and BE, i.e. each market where it is available

Batch BET9K

Batch and pack data (Batch ID „BET9K“)for product 04266567890128uploaded by Belgian MAHvia OBP system

Batch FRQXF

Batch BET9K

Example: Multi-market product with GTIN = 04266567890128 is available in FR and BE

1) Both MAHs have marketing authorizations for the same product, but on different markets


What happens when a Multi-Market Pack is dispensed? Example:

European Hub(EMVO)

Dispense pack XYZ/1234

(2) Norwegian NMVS informs EU Hub about dispense of the multi-market pack

National Repository

National Repository

Dispense packXYZ/1234

Dispense packXYZ/1234

(4) EU Hub informs NMVS‘s in Finland and Sweden about the dispense of the multi-market pack somewhere else

National Repository

Dispense pack XYZ/1234

DispenseProduct XYZ

Serial Nr 1234

Database entries:

...XYZ = Multi market product....XYZ/1234 => „Supplied“

(1) Norwegian NMVS sets pack status to „supplied“ and detects that XYZ is a multi-market product.

(0) Product XYZ is available in Norway, Finland, Sweden

(3) EU Hub looks up in which other countries the multi-market pack would be dispenseable

Database entries:

...XYZ = Multi market product....XYZ dispenseable in Norway, Sweden, Finland ....

(5) Finnish and Swedish NMVS‘s set pack status to „supplied“.

Database entries:


Database entries:



European Hub(EMVO)

Dispense pack ABC/5678

(2) Norwegian NMVS reports dispense to EU Hub to check if product/pack is known elsewhere

Database entries:

...ABC/5678 is dispenseableABC/5678 => „Supplied“ ....

National RepositoryDispense packABC/5678

(4) EU Hub forwards dispense information to German NMVS

Report backABC/5678

(5) German NMVS reports back that pack was found and that its status has been set to „Supplied“

Report backABC/5678 (6) EU Hub reports back that pack

was found in another NMVS

What is an Inter-Market Transaction? Example:

(3) EU Hub looks up in which other countries the product ABC is known Database entries:

...Product ABCdispenseable in Germany....

Dispense pack ABC/5678

DispenseProduct ABC

Serial Nr 5678

(0) Pack ABC/5678 has been imported from Germany to cover a drug shortage.

(1) Norwegian NMVS cannot find product ABC in its database National Repository

Database entries:

....Product ABC unknown....

(7) NMVS reports back that an Inter-Market Transaction was executed


Agenda

Arvato

Architecture





Time Planning, High Level Perspective

There are roughly 15 months left until medicine verification becomes mandatory in Europe

This is our plan to complete the project within the available time frame from Slovakia:

What are the results of each phase?Let‘s go through the five phases shown.

Feb 9, 2019Nov. 1st, 2017

Phase 1InitializationPreparation

Phase 2Ramp-up A

Start onboarding of

MAHs

Phase 3Ramp-up B

Start onboarding ofpharmacies/wholesalers

and hospitals

Phase 4Ramp-up C

Onboarding of remainingpharmacies/wholesalers and hospitals

Phase 5Production

Onboarding of last minute stakeholders, official production start


MAH

EU Hub(EMVS)

Parallel Distributor

National Blueprint System(SOOL)

Data upload(products, packs)

Planning, Detail ViewPhase 2: Ramp-up A (Mar 2018 – Apr 2018)

During phase 2, the highlighted information flows will be observed:


Phase 3Ramp-up B


and hospitals

Phase 4Ramp-up C

Onboarding of remainingpharmacies/wholesalers and

hospitalsFeb 9, 2019

Phase 5Production


Phase 2Ramp-up A

Start onboarding ofMAHs


During Phase 3, additional data flows will be included:

Planning, Detail ViewPhase 3: Ramp-up B (Apr 2018 – May 2018)

Officine, hôpital

MAH

European Hub(EMVS)



Wholesaler

Verification,dispense

Requests and pack status changesRequests and pack status changesfor multi-market products

Web app Web appWholesaler software

Pharmacy software

„early birds“

Pharmacy



Phase 2Ramp-up A


Phase 4Ramp-up C


hospitalsFeb 9, 2019

Phase 5Production


Phase 3Ramp-up B


and hospitals


PharmacyWholesaler

During Phase 4, the functionality of the various pharmacy and wholesaler software systems will beincluded:

Planning, Detail ViewPhase 4: Ramp-up C (Jun 2018 – Oct 2018)

Phase 2Ramp-up A


Phase 3Ramp-up B


and hospitalsFeb 9, 2019

Phase 5Production


Phase 4Ramp-up C


hospitals

Officine, hôpital

MAH

European Hub(EMVS)



Wholesaler

Verification,dispense

Requests and pack status changesRequests and pack status changesfor multi-market products

Web app Web appWholesaler software

Pharmacy software

Pharmacy




Results until Feb 9, 2019:

New functionalities The new developed pharmacy/wholesaler software systems have been installed at all pharmacies and wholesalers

Utilization The verification of Medicines has become a routine at the pharmacies and wholesalers. Almost all medicament packs on the Slovakian market are now serialized.

Planning, Detail ViewPhase 5: Production (Nov 2018 – Feb 2019)

Phase 2Ramp-up A


Phase 3Ramp-up B


and hospitals

Phase 4Ramp-up C


hospitals

Phase 1InitializationPreparation Feb 9, 2019

Phase 5Production


Heike RikusManagerin Publishing Solutions

[email protected]

Phone: +49 (0) 5241/80-43674

Arvato Systems

https://it.arvato.com

Nikolaus GoudersProject Manager

[email protected]

Phone: +49 (0) 5241/80-5454


Backup


Process IllustrationRepackaging by Parallel Distributor

(5) Parallel Distributor uploads A-package data („checked out“) and B-package data with new batch-id(s) and serial numbers incl. reference tooriginal A-batches to EU Hub

MAHNational Repository

(NMVS)

European Hub

(3) Finnish Wholesalersells some packages of

product A to Swedish Parallel Distributor

National Repository(NMVS)

(4) Parallel Distributor re-packages A-packs into product

B-packs with new serial numbers.1)

Par. Distr.

(7) EU Hub sends B-package data with new

serial numbers to NMVS Sweden

Wholesaler

(8) EU Hub sends status updates for repacked A-packs

(„checked out“), i.e. serial numbers, to

Finnish NMVS

(1) Finnish MAHuploads package data for product A to EU-Hub

(6) EU Hub saves relationship between A-batches and B-batches in case a later recall of an A-batch should occur.

1) Important remarks:a) Both A-packs and B-packs may belong to several different batches but a 1:n relationship between A-batches and B-batches needs to be maintained.b) It is possible that only a part of an A-batch is sold to the Parallel Distributor, so other parts may remain in the original country, e.g. Finland.c) A cascading process is possible, i.e. the Parallel Distributor in Sweden might resell some packs of product B to a Parallel Distributor in Norway that repacks them into product C.

(2) EU-Hubuploads package data for product A to Finnish NMVS


Process IllustrationRecall of medicament supplied by Parallel Distributor (see also previous slide)

MAH


European Hub(EMVO)


(2) For some batch(es) of product A, send status update to „recalled“to EU Hub

Par. Distr.

(7) UpdateB-batches to status

„recalled“ 1)

(1) Some batches of product A of which parts were previously sold from a wholesaler in Finland to a

Parallel Distributor in Sweden (that repacked them to product

B) are called back by MAH

(4) Look up which batches of product B were generated from recalled batches of product A

(5) Inform Parallel Distributor about recall of product A

(7) Inform MAH about markets potentially affected by the recall (Sweden in this case)

(3) Update batches of product A to status „recalled“ 1)

1) Remarks:a) As the recalled A-batches may have been sold only partially from Finland to Sweden while other parts may have

remained in Finland, the Finnish NMVS needs to be informed about their recall as well. b) Product B might as well be a multi-market product, so other countries beyond Sweden would be affected by step 4. Dito for product A and step 5.

(5) Parallel distributor decides that B-batches

shall (or shall not) be recalled

(6) For B-batches, send status update to „recalled“ to EU Hub


Product A, Batch XQF

Product A, Batch MGP

Wholesaler Par. Distr.

sold to repacked to

Product B, Batch ZZE

Product B, Batch VUY

Product B, Batch T9K

sold to repacked to

Repacking Scenario (1)

OK


Product A, Batch XQF

Product A, Batch MGP

Wholesaler Par. Distr.

sold to

repacked toProduct B, Batch T9K

sold to

Repacking Scenario (2)

Packs from different source batches must not be repacked into the same destination batch.Otherwise, a recall of one source batch (e.g. A-XQF) could indirectly affect another source batch that was not recalled (e.g. A-MGP).

Documents

National Blueprint System Slovakia Kick-Off Meeting Kick-off Meeting Slovakia 2.pdfOffline bulk transactions contain transactions with heterogeneous products and transaction types