PharmaLedger framework architecture

This project has received funding from the Innovative Medicines Initiative 2 Joint Undertaking under grant agreement No 853992. This Joint Undertaking receives
support from the European Union’s Horizon 2020 research and innovation programme and EFPIA.
Copyright © PharmaLedger Consortium 2020 – 2023 PharmaLedger: www.pharmaledger.eu IMI: www.imi.europa.eu
D3.1 PharmaLedger framework architecture
Deliverable No D3.1
Work package No. and Title WP3 Architecture and Reference Implementation
Version - Status Final
Date of Issue January 2021
Dissemination Level Public
Filename D3.1 PharmaLedger framework architecture
Ref. Ares(2021)2766626 - 26/04/2021

PharmaLedger – 853992 | Deliverable D3.1 v2.0 | PUBLIC 2/17
DOCUMENT INFO
Authors
Authors Organization
Zeev Pritzker (editor) AVO
Sinica Alboaie RMS
Marco Cuomo NVS
Christos Patsonakis CERTH
Contributors Organization
Anastasia Theodouli CERTH
Noa Arazi AVO
Ana Balan RMS
Document History
Date Version Change Status
June 2020 0.1 Initial TOC draft
October 2020 0.8 Contributions by authors and partners incorporated
October 2020 0.9 Contributions by authors and partners incorporated
December 2020 1.0 Contributions by authors and partners incorporated
December 2020 1.3 Pre-final - submitted for quality control In progress
January 2021 2.0 Final version to submit to EC-IMI Final
Acronyms
DID Decentralized Identities
DLT Distributed Ledger Technology
DSU Data Sharing Unit
KeySSI Key and Self Sovereign Identifier
OOP Object-Oriented Programming
SSApps Self-Sovereign Applications
Disclaimer: Any information on this deliverable solely reflects the author’s view and neither IMI nor the European
Union or EFPIA are responsible for any use that may be made of the information contained herein.

Executive summary
This document describes an initial architecture of PharmaLedger, an open blockchain platform for
healthcare industry. It is based on work performed in the first 12 months of the PharmaLedger project, to
be followed by the final architecture specification that will be delivered in M24 of the project.
The main PharmaLedger architecture design principles are established, including a hierarchical
technology-neutral blockchain structure. The design principles are based on independent dedicated
blockchains that implement individual use cases and key platform functions such as decentralized identity
management. The blockchain functionality is abstracted away from applications, allowing the replacement
of the blockchain technologies without changing the application code.
The PharmaLedger architecture is based on a minimal use of smart contracts. The latter are used mainly
for anchoring off-chain data and code, with emphasis placed on encapsulation of self-sovereign code and
data in Data Sharing Units (DSUs). At a minimum, DSUs should be used for implementation of generalized
wallets; however, the PharmaLedger architecture supports implementation of entire healthcare
applications in DSUs, including integration with the existing health applications. OpenDSU libraries, tools
and SDKs are specified for this purpose, along with network deployment, monitoring and reporting tools.
Security, privacy and confidentiality of healthcare data and code are built into the architecture, with
user/cloud edge wallets and client-side encryption playing a key role. Initial description of the
PharmaLedger platform governance is provided, based on work performed in WP4.
A selected early implementation of the ePI/eLeaflet is provided, to demonstrate the first practical use of
the PharmaLedger architecture.

Table of Contents
Executive summary ...........................................................................................................................3
1. Overview and relation to other work packages ...........................................................................5
2. Main design principles................................................................................................................5
3. Key elements of PharmaLedger architecture...............................................................................7
3.1 Data Sharing Units ..........................................................................................................................7
3.2 Deployment ..................................................................................................................................10
3.3 Monitoring and reporting.............................................................................................................10
3.4 Security .........................................................................................................................................11
3.5 Privacy and confidentiality............................................................................................................11
3.6 Flexibility of technology, future proofing .....................................................................................11
3.7 Integration with existing systems.................................................................................................12
3.8 Interoperability with foreign chains .............................................................................................12
3.9 Platform governance ....................................................................................................................12
3.10 Libraries.........................................................................................................................................12
4. Selected implementations of PharmaLedger use cases ..............................................................13
4.1 Overview.......................................................................................................................................13
4.2 Adoption of the DSU-based architecture in PharmaLedger use cases.........................................14
4.3 eLeaflet/ePI use case implementation (preliminary) ...................................................................14
4.4 Clinical trials supply chain use case implementation considerations...........................................17
5. Conclusions and future evolution .............................................................................................17

1. Overview and relation to other work packages
PharmaLedger is open blockchain platform for healthcare industry. Based on a flexible, technology-neutral
architecture, it allows independent implementation of multiple use cases. This document describes the
initial PharmaLedger architecture, and will be followed by deliverable D3.2 - PharmaLedger Framework
Architecture for Healthcare Industry (updated), to be delivered in M24 of the PharmaLedger project.
This document is based on work performed in the first 12 months of the PharmaLedger project. It relies on
parallel efforts performed in Work Package 3, including a survey of the existing blockchain platforms1
,
deployment and configuration of tools2
and initial skeleton implementation3
.
The architecture design effort was also affected by the parallel work in Work Package 1 (Requirements &
Business Use Cases), and in particular the definition of functional and technical requirements4 5
and the full
definition of use cases6
. Due to the parallel work on the definition and initial implementation of the
PharmaLedger EPI use case, feedback from this use case has affected the initial definition of the
PharmaLedger architecture and is reflected in this document.
Finally, the work on development of the architecture has resulted in bi-directional feedback to and from
the related work performed in Work Package 4 (Governance) on research of potential PharmaLedger
governance options7 8
.
2. Main design principles
The PharmaLedger platform architecture relies heavily on the OpenDSU technology that was described in
the DSU Blue Paper drafted with the participation of the PharmaLedger team9
. The main design principles
of PharmaLedger architecture are as follows:
Hierarchical blockchain structure. As shown in Figure 1, the PharmaLedger platform is a hierarchy of
blockchains. For security, traceability and verification of integrity and authenticity, data stored in leaf
blockchains is cryptographically anchored on parent blockchains, whose data is in turn anchored on their
parents and so on. The highest level in the hierarchy is the PharmaLedger root blockchain, which may be
public or private (this has not been decided yet). A blockchain naming service may be provided to facilitate
addressing entities throughout the PharmaLedger blockchain tree.
Independent blockchains. Leaf blockchains are independent of each other and may use different
blockchain protocols. They may use minimal smart contracts to anchor their data on their parent
blockchain and support anchoring of data from their leaf blockchains.
Dedicated blockchains for use cases and PharmaLedger platform functions. Typically, a dedicated leaf
blockchain will serve each PharmaLedger use case. Other functions, typically such that serve the entire
PharmaLedger blockchain ecosystem, may also be implemented on dedicated blockchains (such as
decentralized identity management).
Blockchains should be replaceable without changing application code. It should be possible to switch a
PharmaLedger application to a different blockchain infrastructure and protocol, without changing the
application code (by changing only wrappers and APIs).
1
Deliverable D3.3 – Blockchain Platform Research, PharmaLedger project (work in progress)
2
Deliverable D3.14 - Deployment and configuration of the shared tools, PharmaLedger project
3
Deliverable D3.17 – Initial skeleton implementation, PharmaLedger project
4
Deliverable D1.2 – Definition of functional requirements, PharmaLedger project
5
Deliverable D1.3 – Definition of technical requirements, PharmaLedger project
6
Deliverable D1.4 – Full definition of use cases, PharmaLedger project (work in progress)
7
Deliverable D4.1 - Report of the governance options, PharmaLedger project
8
Deliverable D4.2 - Recommendation report for PharmaLedger governance, PharmaLedger project (work in progress)
9
OpenDSU Blue Paper

Independent use case architectures. Within a leaf blockchain dedicated to a specific use case, an arbitrary
implementation can be used. For example, a use case may be implemented using a blockchain from the
Ethereum blockchain family, while using no or minimal smart contracts; while another use case may be
implemented on HyperLedger Fabric and rely heavily on chaincode.
Minimal use of smart contracts and on-chain data is encouraged. While this is not a mandatory
requirement, minimization of code and data implemented and stored on-chain, is encouraged.
Use of OpenDSU and self-sovereign code and data is encouraged. In line with the previous principle, use
of DSUs for implementing business logic of use cases and for storing off-chain data is encouraged. DSUs
contain self-sovereign code and data9
. The DSU code will be typically executed in user-controlled execution
environments. DSU code and data self-sovereignty is implemented using client-side encryption and user
wallets. Use of DSUs is described in greater detail in section 3.1.
Blockchain wallets should be implemented in DSUs. At a minimum, DSUs should be used for implementing
wallets (even if the use case application code is not implemented in DSUs). The wallets, at a minimum,
store private keys and facilitate making blockchain transactions but may implement also other arbitrary
functions.
Standard APIs (translated to DSUs) for interfacing with external applications. For interface to external
applications, standard APIs such as REST may be used. For example, APIs may be used for interfacing with
legacy health applications, non-PharmaLedger use cases or external blockchains. Such APIs may be
translated into DSUs using wrappers.
Decentralized identities may be used. The use of decentralized identities throughout the PharmaLedger
ecosystem is currently under consideration. The definition of the required DID methods is work in progress.
Verifiable credentials may be used. The use of verifiable credentials throughout the PharmaLedger
ecosystem or in individual use cases is currently under consideration.
Figure 1 PharmaLedger’s hierarchical blockchain structure

PharmaLedger libraries, tools and SDK will be provided to simplify application development. The libraries
will include, among other things, the commonly used DSU types.
Kubernetes-based deployment. Deployment of all components including applications, blockchain nodes,
microservices etc. will be performed using Kubernetes.
Use case specific requirements. The minimalist nature of the PharmaLedger platform as a hierarchical
blockchain whose main function is security and hierarchical anchoring of data, with self-sovereign code
and data stored mainly off-chain and with dedicated blockchain leaves for use cases and major functions,
implies that the main functional and non-functional requirements will be use-case specific. While this
document provides an overview of the blockchain platform and examples of use cases and their
requirements, detailed requirements for each use case should be described elsewhere.
3. Key elements of PharmaLedger architecture
3.1 Data Sharing Units
Data Sharing Units (DSU) are, along with the hierarchical blockchain structure, the basic building blocks of
the PharmaLedger architecture. While a detailed description of DSUs is provided in the OpenDSU
Bluepaper9
, here we provide a general overview of their structure, features and use for developing
PharmaLedger applications.
DSUs are functionally similar to objects in object-oriented programming (OOP). They contain arbitrary code
and data and may exchange messages. For portability, DSU code is written in JavaScript or WebAssembly,
which allows running the code in virtualized execution environments, including Web browsers. Types of
DSUs (that are similar to classes in OOP) can be defined arbitrarily.
DSUs are client-side encrypted and can therefore be stored anywhere without giving control over their
content to a storage or hosting operator. They use a low-level method called “bricks” for efficient storage,
as shown in Figure 2.
To instantiate a DSU (i.e., to run a DSU code or access its data), the DSU must be “mounted”, meaning that
it must be resolved, accessed, assembled from bricks, decrypted and loaded into a controlled virtualized
execution environment. The execution environment can be server- or client-based and may, in the latter
case, be implemented inside a web browser. Instantiation of a DSU and its relationship to the
corresponding DSU type is depicted in Figure 5.
Access to the DSUs is controlled by private keys that are used for client-side encryption and for signing DSU
contents. This enables the disintermediation of access to code and data, with only the owner of the proper
Figure 3 DSU structure example Figure 2 Storage of DSUs in "bricks"

private keys being able to run their code and have a meaningful access to the DSU’s data, even if the DSUs
are stored in an externally operated storage facility.
DSUs are typically notarized by anchoring them to a blockchain (see Figure 4) for verification of their
integrity and for traceability, and can be used in a hierarchical blockchain system, as shown in Figure 6. The
anchoring of DSUs to a blockchain can also be used for resolving the DSUs, provided that a proper
addressing/naming scheme and resolvers are provided. For this, there exist a number of anchor types
(implicit, explicit, light, heavy) the serve different purposes9
.
DSUs can be used as a means of interoperable data
exchange between different systems and
applications, since their code can be designed to
map the data that they contain into a target schema
or representation format, and to implement an API
for the connected system (which could for example,
be an existing health IT application). That is, the
DSUs can have an embedded data access layer.
A special kind of cryptographic
identifier called KeySSI is used with
DSUs. KeySSIs have a dual function:
they serve as decryption keys for
DSUs or for elements stored within
the DSUs, and as self-sovereign
identifiers (SSI) of these items. A
KeySSI includes all the required
information to identify a DSU on the
blockchain to which it is anchored. A
DSU resolver will resolve the KeySSI
to a blockchain-anchored DSU and
load the latter into an execution
environment9
.
One of the key applications of DSUs is
implementation of wallets in
enterprise environments. Rather
than placing the wallets in a highly
secure zone and making signing requests to them by applications located in a less secure zone through a
Figure 5 DSU type instantiation
Figure 6 Anchoring DSUs to a hierarchical blockchain platform
Figure 4 DSU anchoring on the blockchain

Web API, which entails communication and authentication security risks, the DSU is mounted in the user-
controlled secure execution environment and communicates with the application using APIs stored in the
DSU, which results in a major increase in security.
The fact that the DSUs are anchored in the blockchain allows digital signing of data and code in the initial
version of the DSU as well as in all subsequent updates.
“Brick storage” are one of the core elements of the OpenDSU ecosystem. DSUs are divided into blocks
(“bricks”) for storage. The brick storage servers are web services capable of storing and retrieving a brick if
the user provides its hash. The Brick Storage concept works well in an open, permissionless network and is
easy to implement. More complicated implementations are required only in case of access revocation to
the shared data or an expiration date for data access granted ta a third party.
DSU is compatible with any type of code (e. g. HTML, CSS, JS) required to launch and run an application in
a browser. The code can be contained in a DSU or in another environment that is capable of executing the
application code loaded from the DSU.
The OpenDSU concept supports the standardization of APIs for loading web applications from DSUs. Such
applications are called Self Sovereign Applications (SSApps). An instance of an SSApp in a DSU will contain
all the code required to launch the SSApp and display a user interface.
The SSApp approach presents two main advantages. The first one is that the code for the UI and for the
business logic is signed and thus is verifiable by the edge client. The second advantage is the
disintermediation and self-sovereignty at the application level. The blockchain, anchoring, and brick
storages are services consumed from the cloud. A server is replaced by a service worker that runs on the
edge device and therefore possibilities of data leakage are drastically limited compared to classic web
services.
Technical aspects of DSUs are described in the OpenDSU Blue Paper9
. Development of business applications
with DSUs is further described in the OpenDSU White Paper10
and OpenDSU Use Cases Development
Guide11
. Brick storages and their usage with JavaScript are documented at the OpenDSU website12
.
10
OpenDSU White Paper
11
OpenDSU Use Cases Implementation Guide
12
OpenDSU website
Figure 7 DSU-based implementation of multiple use cases in the PharmaLedger heterogeneous multi-blockchain
system

3.2 Deployment
PharmaLedger deployment is performed using Kubernetes, a portable open-source platform for managing
containerized workloads and services13
. Kubernetes facilitates both declarative configuration and
automation. Its services, support and tools are widely available and represent a large, rapidly growing
ecosystem14
. In a Kubernetes based deployment, a cluster of worker machines, called nodes15
, run
containerized applications. Every cluster has at least one node. The nodes host the components of the
application workload, called pods16
. The Kubernetes control plane17
manages the nodes and the pods in a
cluster. In production environments, the control plane usually runs across multiple computers and a cluster
usually runs multiple nodes, providing fault-tolerance and high availability. The Kubernetes Component
document18
outlines the various components needed to have a complete and working Kubernetes cluster.
PharmaLedger’s Kubernetes-based deployment methodology is adopted from the PrivateSky project19
, as
shown in Figure 8.
3.3 Monitoring and reporting
The workload in Kubernetes is run by placing containers on pods. Depending on the cluster, the nodes can
be virtual or physical machines. The components of a node include a kubelet, a container runtime, and a
kube-proxy. PharmaLedger monitoring tools for Kubernetes are currently under research and the precise
details will be presented in the following deliverables.
13
Kubernetes overview
14
Kubernetes concepts
15
Kubernetes nodes
16
Kubernetes pods
17
Kubernetes control plane
18
Kubernetes components
19
PrivateSky Architecture
Figure 8 Deployment using Kubernetes in PrivateSky

3.4 Security
Security is an important aspect of all information processing activities, especially in environments or
domains which involve critical and confidential data, as is the case in a majority of healthcare settings.
Design of a secure system requires a rigorous identification and classification of the threats to which it will
be exposed. This may involve generic threats which the majority of ICT systems are subject to, and other
threats that apply to particular domain at hand. Furthermore, since applications in the healthcare domain
are subject to strict regulatory frameworks with respect to security, privacy and confidentiality, it is
imperative to incorporate regulatory compliance in the system design phase.
PharmaLedger architecture has security as a focal design principle, to deliver a decentralized, blockchain-
based system that aims at practical, real-world adoption. To address the issue of regulatory compliance,
PharmaLedger will build on relevant and pervasive frameworks and standards for the health domain, such
as HIPAA and ISO 27799:2016. However, since PharmaLedger vision is to provide a healthcare platform for
the future, the platform involves novelties both in terms of the technical constructs employed and in
digitization of use case workflows. It is therefore expected that either new applicable regulation, or
extensions to the one already in place, may emerge.
From a technical standpoint, PharmaLedger will address threats and risks by building on top of strong
cryptography across all of its constituent layers. The OpenDSU framework will provide a trustworthy
framework for involved stakeholders to engage in transactions by providing a common and trusted
application codebase and data storage solution, thus, limiting reliance and risks introduced by using third-
party software. Moreover, PharmaLedger’s blockchain-based decentralization and replication support data
availability and overall system resilience, even in the event of catastrophic failures.
3.5 Privacy and confidentiality
The PharmaLedger architecture was designed to satisfy even the strictest privacy and confidentiality
requirements. This includes:
Self-sovereign, client-side encrypted data. The constituent blockchains serve only for anchoring and
resolving DSUs. Data stored in the blockchain cannot be used to read the content of the DSUs without the
reader having control of the corresponding private keys.
Self-sovereign, client-side encrypted and client-side executed code. Smart contract code on the
blockchain is minimized to that required to anchor and resolve the DSUs, and is not sufficient to read the
content of the DSUs. The DSU code is loaded and executed only in the DSU owner-controlled execution
environment, and only if the actor loading the code has the corresponding private keys.
The above features ensure that the code can be run and the data can be accessed only by authorized
parties. Access is granted to such parties by allowing them to have the private keys required to decrypt the
DSU data and code. GDPR privacy requirements are satisfied even of the data are not deleted: to render
the data unreadable and thus “erased” for all practical purposes, the data owner needs only to destroy the
private keys (that never leave the owner’s possession anyhow).
3.6 Flexibility of technology, future proofing
The minimalist platform architecture of PharmaLedger, in which hierarchical blockchains are used only to
anchor DSUs, decouples the blockchain from the applications and allows switching to a different blockchain
without modifying the application code. This makes PharmaLedger future-proof and flexible with respect
to blockchain and the anchoring technology used – different blockchains can be easily substituted for the
root and/or the leaves of the PharmaLedger blockchain hierarchy (see Figure 1).
Moreover, PharmaLedger does not impose any restrictions on the implementation of use cases (although
OpenDSU is recommended): any DLT technology and smart contract methodology can be used for every
particular use case (such as Hyperledger Fabric, Corda or any member of the of the of enterprise Ethereum
family).

3.7 Integration with existing systems
Integration with existing or future health IT systems, even if these are centralized and are not using DLT, is
achieved by designing the appropriate APIs and loading them in DSUs. The APIs are activated upon
mounting the DSUs. This allows total flexibility in connecting legacy, existing and future health IT systems
and applications to PharmaLedger.
3.8 Interoperability with foreign chains
At this stage, interoperability with foreign chains will be achieved using APIs. Tighter integration with
foreign chains may be considered and reported in the next version of this document.
3.9 Platform governance
The design of post-project governance of the PharmaLedger platform is currently work in progress, with
initial recommendations to be reported in the upcoming Deliverable D4.28
. The following briefly describes
the emerging governance recommendations to be included int his document.
PharmaLedger’s top governing body will be a Governing Board that will include key representatives of the
healthcare ecosystem. PharmaLedger platform governance will have four main aspects, each to be
governed by a dedicated committee that will report to the Governing Board:
Technical. Technical issues including technologies and methodologies used, network deployment and
maintenance etc. will be governed by Technical Committee.
Business. Business issues such as membership in the PharmaLedger business network, engagement of
external service providers etc. will be governed by the Business Committee.
Policy and legal. Policy and legal issues such as compliance with regulation will be governed by the Policy
and Legal Committee.
Use case specific. The implementation of use cases will be governed by a dedicated Use Case Committee
for each use case - such as eLeaflet Use Case Committee, Clinical Trials Use Case Committee etc. The vertical
Use Case committees will be supported by the above horizontal Technical, Business and Policy and Legal
Committees.
Upon firming up of the proposed governance structure of PharmaLedger, a technical means for
streamlining governance processes will be studied and reported in Deliverable D4.3 – Requirements
Document for Governance Application20
.
3.10 Libraries
Created using web technologies, the concepts of DSUs and Self Sovereign Applications (SSApps) provide a
sound and comprehensive solution for interoperability and data portability between OpenDSU-compatible
wallets21
.
DSUs can contain portable Java Script or WebAssembly code, which facilitates interoperability and data
portability between wallets. The plugins/components of the wallets (the SSApps) can run in all OpenDSU
compatible wallets because web browsers act as DSU-loading agents21
. A web browser can use service
workers and other sandboxing mechanisms (iframes, workers) to execute the code and to display the
interface that is coded in the DSUs. The use of the service workers (SW) aims to replace the need for
servers. Using SWs allows to store data in DSUs and to serve data from DSUs, including the HTML files and
JavaScript used by user interfaces.
20
Deliverable D4.3 – Requirements Document for Governance Application, PharmaLedger project (planned)
21
https://privatesky.xyz/

4. Selected implementations of PharmaLedger use cases
4.1 Overview
A typical architecture for implementing uses cases in PharmaLedger, using DSUs, is shown in Figure 9.
Since the functionalities of the blockchains are almost entirely limited to anchoring, the functional and non-
functional requirements of the use cases are paramount. In general, such requirements are use case
specific and will not affect the general PharmaLedger platform architecture. However, the specific use case
requirements may affect the choice of the leaf blockchain used to implement the use case, as well as the
use and design of the DSUs for the use case. For example, some use cases may be implemented without
using DSUs or with their minimal use, e. g. only for implementing wallets, and implement the bulk of the
business logic in smart contracts. They do, however, need to anchor their blockchain data to a parent
blockchain.
While specific use case requirements and implementations are not a part of the PharmaLedger framework
architecture, the initial implementation of the eLeaflet/ePI use case is described in the following section as
an example of use of the PharmaLedger architecture in healthcare use cases.
Figure 9 Generic architecture of implementation of use cases in PharmaLedger using DSUs

4.2 Adoption of the DSU-based architecture in PharmaLedger use cases
PharmaLedger architecture creates a decentralized system of direct (blockchain node-running) and indirect
(user-only) participants, as shown in Figure 10. The architecture can support any the PharmaLedger use
cases, from ePI to Supply Chain Management and eConsent, and can be based on any type of blockchain
network. It supports integration with legacy systems through web APIs and permits the participation of
users that do not have the need, interest or capabilities to run a blockchain node (“indirect participants).
Indirect participants communicate with direct (node-running) participants to anchor data on the blockchain
and to retrieve data using the blockchain.
Preliminary implementations of PharmaLedger use cases are described in the following sections.
4.3 eLeaflet/ePI use case implementation (preliminary)
The eLeaflet (also called ePI) use case implementation uses a high-level architecture that comprises the
following components (see Figure 11):
• Manufacturer application – a business application that performs ePI creation and publication on
PharmaLedger’s ePI blockchain.
• PharmaLedger ePI blockchain - maintains anchors with hash links that point to ePI content which
is stored in DSUs.
• DSU (bricks) Storage - stores DSUs as bricks and exposes read and write services.
• End User Mobile/Web application – allows end-users to scan a 2D data matrix and retrieve and
display the ePI corresponding to the scanned product using the ePI blockchain and the DSU storage.
• Content Hub – an optional content access bridge that supports very light (thin) client applications
by exposing RESTful API.
Like the other use case-specific blockchains of PharmaLedger, the ePI blockchain is meant to be anchored
to the PharmaLedger root blockchain.
Figure 10 Generic use case implementation architecture in PharmaLedger

The ePI blockchain forms a peer-to-peer (P2P) network of blockchain nodes (replicas) and supports
anchoring of hashlinks that point to versioned DSUs. The latter are stored as collections of bricks in the off-
chain DSU storage system. Hashlinks are data structures that contain pointers to records in the off-chain
DSU storage that provide the necessary information to resolve the individual DSU’s bricks and to
mount/assemble the DSUs. AnchorIDs (or KeySSIs) map to a list of hashlinks that correspond to DSU
versions.
The following figures demonstrate the various ePI use case implementation options currently under
consideration.
Figure 11 PharmaLedger eLeaflet use case implementation architecture
Figure 12 Alternative implementation of the ePI use case using a consortium blockchain

Figure 14 Base concepts of ePI use case implementation
Figure 13 Alternative implementation of the ePI use case using a single organization ledger

4.4 Clinical trials supply chain use case implementation considerations
The DSU based PharmaLedger architecture fits the technical requirements of the Clinical Supply Chain use
case. The use case implementation is planned to adopt DSUs for smart wallets, subject to a security audit
and certification by the potential adopter organizations. A detailed planning of the clinical trials use case
implementation is currently in progress.
5. Conclusions and future evolution
The initial architecture of PharmaLedger, an open blockchain platform for healthcare industry, is based on
a hierarchical technology-neutral blockchain structure that supports independent blockchains for
individual use cases and key platform functions, such as decentralized identity management. The
blockchains are used mainly for anchoring off-chain code and data, thus allowing the replacement of
blockchain technology without changing application code, and increasing privacy, confidentiality and
security of code and data.
The PharmaLedger architecture is based on minimal use of smart contracts, mainly for anchoring off-chain
data and code, with emphasis placed on use of self-sovereign code and data in sharing units (DSUs). At a
minimum, DSUs are used for the implementation of generalized wallets. The architecture supports
implementation of entire healthcare applications in DSUs, including the integration with existing health IT
applications. OpenDSU libraries, tools and SDKs are specified for this purpose, as well as the appropriate
network deployment, monitoring and reporting tools. A selected early implementation of the ePI/eLeaflet
was described to demonstrate the first practical use of the PharmaLedger architecture.
Initial description of the PharmaLedger platform governance is provided based on work performed in WP4.
Its architectural/technical aspects are expected to evolve as the WP4 work proceeds, including possible
incorporation of on-chain governance tools in the architecture. Experienced gained with the
implementation of additional use cases in WP4 is expected to elicit additional architectural needs, leading
to creation of additional features and tools. These are expected to be specified in the architecture update
document in M24 of the PharmaLedger project.
Figure 15 c Alternative implementation of the ePI use case focusing on optimization of security and performance

PharmaLedger framework architecture

Recommended

Recommended

More Related Content

What's hot

What's hot (15)

Similar to PharmaLedger framework architecture

Similar to PharmaLedger framework architecture (20)

More from PharmaLedger

More from PharmaLedger (11)

Recently uploaded

Recently uploaded (20)

PharmaLedger framework architecture