ARNA Panacea permissioned Blockchain

This is the 2nd post about ARNA Genomics. From the previous one you can get a brief introduction to the synergy of ARNA BC and Panacea Blockchain, which makes the ecosystem for clinical research.

The most complicated task in building the core of Panacea blockchain is to implement a standardized protocol, which further would ease an integration with other blockchains. In this article we’ll go through the research we’ve done and solutions to be applied.

Users roles.

Let’s list the roles and interactions inside the product to have a background for the requirements.

— — — — — — — Pic#1. Roles of users in ARNA Panacea. — — — — — — —

The list of primary ARNA Panacea user roles:

  • Researcher — the author of pharma product to be tested during the clinical trial
  • Investor / Charity giver. Invests to the developments presented by the Researcher
  • Patient — a person whose PHI is used during the trial cycle. Has full access to his PHI
  • FDA and regulatory agencies in other countries of interest.
  • Record keeper. Issues, extends or terminates a license to use the technology (drug or medical device) in certain jurisdiction.
  • CRO (Monitor). A research organization contractor which coordinates clinical trials
  • Insurance company
  • Pharmaceutical company. Has access to data from clinical trials performed, as well as to patient data apart from the personal information.
  • Health clinic. Interacts with the system by submitting patient’s data for undergoing clinical trials.
  • Expert. Conducts evaluation of the results submitted by the Researcher for further report to the Regulator.
  • Software developer (near-clinical mobile applications)
  • Big Data processors(analysts, scientist). Has access to the accumulated information.
  • Statisticians. Develop data distribution models to verify obtained results.

Each user can combine roles in one or several various projects.


After defining major roles and interactions, we made a research to find the proper solution for the Panacea implementation. Let’s try to understand which transaction properties should conform to our needs. To provide a background for a solution requirements, here’s the the ideal case of criterias which transactions should follow:

  • transactions should conform to the present state of the system: e.g., in the case of ARNA BC, in a certain clinical trial there always have to be only one concrete test result for the patient A.
  • transactions should be authorized, i.e., only the clinic which owns ePHI should have an access to perform transactions on it. The appropriate patient should always have a full control on all the operations performed over his PHI
  • transactions should be immutable: once transaction has entered the ledger, it should be impossible to modify its information; e.g., initial patients diagnosis posted by a clinic could not be changed; or the results of ARNA BC tests on blood samples could not be altered.
  • transactions should be final: once transaction is recorded in the ledger, it should be impossible to delete it. Being extremely critical, this property guarantees reproducibility to each result got on every stage of clinical trials.
  • censorship resistance: if a transaction conforms to a ledger protocol, it should be eventually stored.

Blockchains classification.

When we just started, the main topic to discover was the blockchain type to choose from for building Panacea. Presence of that many different roles dictates the necessity to be able to verify consistency of data stored in transactions in order to audit the state of blockchain.

Classification of blockchains are presented below:

  • public blockchain, where transaction could be submitted and data read from any node
  • private blockchain, where direct access to data and submitting transactions is limited to a predefined list of entities
  • permissionless blockchain, where are no restrictions on identities of transaction processors (i.e., users that are eligible to create blocks of transactions)
  • permissioned blockchain, where transaction processing is performed by a predefined list of subjects with known identities.

Let’s observe the pros and cons of each type to find the right solution.

The major reasons to doubt using permissionless blockchain for healthcare industry are as follows:

  • Inability to control miners. According to many jurisdictions, identities of transactions processors need to be known.
  • Related to the first problem, there are concerns about clients’ confidentiality in a public environment.
  • Permissioned ledgers can be more efficient for testing purposes, quickly applying modifications to the protocol, and so on.
  • Proof of work is made largely redundant on private blockchains; this allows the increase of transaction throughput and reduction of the cost of operations.

Then, we distinguished the following advantages of using permissioned blockchain:

  • regulated read access to transactions and block headers could be granted to major roles(Patient, CRO, Health clinic) in order to provide a transparent and reliable way of ensuring the the precision and validity of results gained on any step of clinical trial
  • full read access to the data could be granted to the Regulators in order to prove the policy compliance(e.g. HIPAA)
  • all interactions rights and data access could be flexibly regulated with compliance to the blockchain protocol

As you may guess from the post title we decided to build custom permissioned ARNA Panacea blockchain. Permissioned ledger considers for healthcare blockchain more attractive than public one because of processing critical timestamped registries, as most jurisdictions require registration of registry processors. Permissioned blockchain state could be accessibly controlled, what makes it easier to comply different regulators and jurisdictions.

Unlike cryptocurrencies, in permissioned blockchains transaction processors are not required to be rewarded by native tokens. Which is a case in Panacea as well.


The authorization of users is implemented with a public-key cryptography. Each user is granted a pair of private and public keys. The public one is published to set the identity, the private is stored on the side of user.

Blockchain Anchoring

Blockchain anchoring is used in order to provide additional guarantees of permissioned blockchains immutability by periodically submitting hashes of block headers for inclusion into a supporting permissionless blockchain in the form of witness transactions.

A witness transaction on Chain A (the supporting blockchain) witnessing a block on the Chain B (the main blockchain) is a valid transaction according to the protocol of Chain A, which contains the unique identifier of the block in question constructed according to the protocol of Chain B (e.g., a 32-byte cryptographic hash of its header) as a part of transaction data.

In Panacea there are several roles who need such guarantees to be verified. E.g. CRO, Regulator and Investor. So, we gonna submit witness transactions to the Bitcoin public blockchain due to:

  • relatively small number of mining pools with known identities, which could act as validators
  • high level of security provided by the hash rate of the Bitcoin

Summarizing, permissioned blockchain looks like the best solution for ARNA Panacea blockchain architecture, as it operates by timestamped registries of clinical trials and research.


Big thanks to the authors of the articles below, which we extensively used to found a proper solution.

PS: review our road map
panacea repo
check out tokensale site
and please follow me on twitter @magomed_chatuev