Blockchain protocols in clinical trials: Transparency and traceability of consent

Dear Reviewer, 

We have just answered to the last two referees report. We are going now to answer yours.

Thank you for your understanding and patience

Best regards,

Dear reviewer, 

Thank you for giving us the opportunity to make the text more clear and by so improving its quality

In this proof of concept (POC), the authors have implemented the use of blockchain technology to obtain secure, unfalsifiable consent in a clinical trial. Although the authors have a done a good job in explaining the methods of this POC and how they achieved the aims of the study, there are still remain some concerns, which, if addressed, can substantially improve the manuscript.


While talking about a public ledger, authors should explain what ‘publically verifiable’ means in the context of a clinical trial. To the understanding from the manuscript, the authors have used the timestamping feature of blockchain as the basis to explain how the verification will work. This is a vital facet of blockchain, but the extent of this in a clinical trial consent would only be limited to the fact that a consent was signed at a particular time. Whether the consent can be ‘verified’ to be legitimate is still unclear. 

Here, we explain what we mean by “Publically verifiable”. The main output of the experience is what we called a ChainScript document. This document summarize all the tracked interactions of the user with our web platform: for instance, consent status, protocol versions, re-consent status with regards to a specific version. For each user participating to the POC and each tracked website actions, a transaction was triggered into the bitcoin network.  When the bitcoin network validates a transaction then a block is added to the ongoing blockchain. Our ChainScript documents stands for this block. Since, bitcoin is a public blockchain, anyone can verifies that a transaction is indeed present in some block of the blockchain. In our context, suppose you want to verify that the consent status for some user, then one have to take the corresponding hash of the alleged transaction in the ChainsScript document and verify that this really exists in the blockchain. So now, how to verify that this transaction exists in the blockchain : either verifies `by hand`, one downloads the whole bitcoin blockchain, which corresponds to around 160Gb [1] (at the time of the writing), and check the actual transaction exists. In a more useful way, one use some services offered by public website that verifies that the transaction one is looking to verify actually exists and check the proof-of-data is indeed in this transaction. `blockchain.info` or `live.blockcypher.com` are such sites.

We stress the fact that we throw to the blockchain not the data itself, but an encrypted hashed, so that we store a proof of data. Emails, consent status, protocol versions and all related informations won’t appear in clear, these informations are encrypted. And so when a validator wants to check an alleged consent status or a specific version of the protocol, than he has to use the public key and verifies the concordance between the claimed data and the transaction stored in the blockchain as explained in the previous paragraph.
Besides, there is an other concern about the user authentication, but we will go this point in the next answer.

Besides, from a more in-depth technical point of view, transactions stored inside bitcoin blocks are stored following a powerful data-structure called a Merckle Tree, this corresponds to a tree with, at the bottom, transactions that are hashed by joint pairs as and when the hashing scheme bubbles up to the top of the tree where one finds the so-called Merckle root. Hence, this enables verifying that alleged data lies indeed in some transactions by adding the hash value of the Merckle root in a consistent and efficient way. As for the ChainScript, we grouped together all the transactions in order to validate them as a whole, which enables to be cost-savy and not expense bitcoin each time a user triggers an action on our web-platform.
We updated the manuscript in order to make more clear what we mean by publically verifiable.

[1] https://bitinfocharts.com/

This then boils down to the physical identity crisis, which in itself can be a separate research manuscript. The authors can add a paragraph explaining the limitations of this crucial drawback in detail. So far there is only a brief description in the manuscript. Additionally, a public ledger may be unpopular with patients for enrollment. A detailed explanation on what ‘public’ means and which entities will be able to see the participant’s consent data from the distributed ledger needs to be highlighted.

In the context of this POC, we are aware that our solution is functional but do not tackle the question of ensuring user detains keys authentication engaging directly the blockchain transaction when submitting action on the website, since this was not our primary concern. And we agree that this could give us the opportunity to go through a new research manuscript. First, we want to separate 2 issues that are different kind of concerns. 

- The first one is the authentication by itself, i.e. ensuring that the person presently answering is precisely the person that is supposed to do so. If for sure this is an important issue, this is related to the online nature of the consent and not the specifics of our blockchain implementation. This subject is also known as KYC problem, Know Your Customer. Lots of services face this issue, such as banks, public institutions for online administrative process, tax payments for instance and many solutions are currently deployed and we won’t focus on them. 

- The second one is related to the fact that cryptographic key pairs are generated by a third party, which for sure is not fully satisfactory. This can find solutions that we could test in a new implementation. Here’s how 

1) One way to tackle this issue can consist in storing the keys in physical objects, such as USB keys, protected by a password or a PIN code [1]. There are plenty of such material bitcoin wallets that allow storing the key in some material, in so called cold or hot storages. Examples of cold storage are paper wallets that suppose to flash QR code to get back private key,  there are also specific hardwares that enables the off-line decryption/encryption with a private key. Hot storage may enable keeping the pair of keys on a computer without protecting them from the online environment, which is still secure and which we believe to be sufficient in our case. Since in a real life clinical trial, there is a meeting point between subjects and investigators, one of these materials could be given by hand to the subjects. 

We can also choose a process where keys could be generated by the user and stored in the their web browser, and this without the user having to worry of the complexity of this process generation and storage. Indeed, some platform registration “connect-button” can trigger the event of generating the pairs and attach them to the local instance of the user: either directly in the web browser, the principle being the same as some bitcoin wallet provider for instance for Chrome browser, such as `KryptoKit Bitcoin Wallet` or `Bitcoin Cash Wallet`[2]. We mention here the converging efforts of main browser providers such as Chrome, Safari, Firefox to build-in a currency-agnostic web payment standard, which supposes to bring the keys there, in the browser [3]. We can also implement a local file stored in the desktop that the subject would have to use each time he or she wants to triggers a action that will be the subject of a transaction, and this can advantageously complement the browser solution in case the user changes web browser. Depending on the design of the study, the online platform can be accessible by anyone or we can send an email with a link bound to a token to each participant. 
We believe that storing keys in the web-browser is safe enough in our context and it would have the major benefit for the user not to worry about the key manipulation. 

Any of these solutions enables the subject to throw directly the transaction to the blockchain. 

remark 1 here we address the question of decentralizing the key management but we won’t be able to address user authentication issue. KYC has plenty of solutions that are always pretty heavy, such as sending ID pictures and we can of course implement one of them. However, if we implement some smart contract and if we make an assumption, which is a strong one, that we get some trusted emails from participants then there might be a way to enforce the process though still having weaknesses and not as secure as a full KYC process. Indeed, we can bind the user email to its public key in order to prevent from the situation where some malicious investigator decides to send transaction in the behalf of some subject and there are ways to check that an email was effectively sent from the alleged sender, for instance by sending email content as an input to a smart contract and analysing the email header : the user logs into the platforms, a key pair is generated, moreover a transaction is sent binding some metadata consisting in the public key, the user email and some id corresponding to a study identifier, a smart contract checks the consistency of the email content and binds in the blockchain some public key and an email. That way, we improve the one-to-one binding between one public key and a subject email and this tracks user transactions corresponding to the ongoing study. We mention also that there are other popular blockchains, such as Namecoin, that enables the binding between keys and some other data, such as DNS, emails or other metadata. But here, we want to enforce that the study subject effectively sends the transactions. 

remark 2: let’s note that regarding the transaction binding key, email and study id, we can proceed on a dedicated blockchain, called Namecoin, which is a fork of the bitcoin blockchain and especially devoted to link names and keys, in fact and historically DNS and keys. Here, we see again that adding a study identifier is important since user may already have a some keys attached to their email.

remark 3: we want to stress the fact that even some malicious investigator consented in behalf of a subject, this very subject would still have to show up to participate to the study if this is not an online study. 

remark 4: on principle, patient invention falls beyond the scope of the Blockchain. However, we want to mention that, in the future, if we get a way to bind biometric attributes to public keys detainers, than we higher the barrier to patient invention. For instance, supposing we can generate some pair of keys through some `TouchID` Apple-like button, hence through fingerprints that are converted in pair of keys - of course this would happens on the user side -, then in case of patients invention, the fraudster would have to prove that the keys are derived through fingerprints, which suppose to recruit as many accomplices. We mention here `tokenise` solution [4] that is currently under conception and which can be interesting in this spirit.   

2) The second step is to fund the bitcoin account as soon as they are created so that each user can validate their transactions with their pair of keys. Of course, the public keys will be known at the account creation and let then the stakeholders send the correct amount of bitcoins in order for the user to process his transactions.

Though technically speaking this implementation is fully doable, one of its drawback is that the transactions are no longer grouped and one of the advantage of our current solution is that it enables the grouping of user interactions and validate them in a whole block of transactions. This is where Smart Contracts come into play. Of course, Bitcoin offers the possibility to build smart contracts, but they are quite constrained, indeed BitScript is stack-based language devoted to do some very specific tasks and is not very flexible to conceive custom smart contracts. 
This being so, we could turn to the solution of Ethereum, which is a popular blockchain and which offers a full flexibility in the use of Smart Contracts. Moreover, the high level framework allows a friendly way of coding them. In this setting, the steps detailed above would be the same and the key pair generated could be for instance stored in the web browser, but then the transactions grouping could be entirely ensured through a Smart Contract. Indeed, each user event could be queued and then depending on some settable parameters, the transaction on the Ethereum blockchain would happen globally for all the transactions when enough of them are queued. However, this Smart Contract implementation is not that simple and we’ll turn back to that question later;
 
At last, we believe that current state of the implementation is directly usable for clinical trials the way they are conducted today, and this could be a first step improvement. Sure, users won’t control their keys the way we would want and this suppose that some stakeholders have root-permissions to create key pairs to be trusted. But, the current process of clinical trials heavily relies on the existence of such stakeholders such as investigators, sponsors, regulatory agencies or IRBs, and if we consider the most trustable of them, we can still benefit from the robust, verifiable characteristics of blockchain technologies but with a supplementary point of trust towards a third party. For instance, to prevent from key forgery, external party under the supervision of the sponsor, such a regulatory agency or the IRB could play the role of forwarding the user interaction through transactions, and since user would access their pairs of keys, we could plan to give them the opportunity, if they find it necessary, to verify in an ergonomic fashion the status of their transactions in the public blockchain.  

We updated the text accordingly in order to precise how we can tackle the issue of key management.

[1] https://bitcoin.stackexchange.com/questions/19646/wallet-advice-for-users-without-technical-knowledge

[2] https://chrome.google.com/webstore/search/Bitcoin%20Wallet

[3] https://www.w3.org/blog/wpwg/2017/09/14/payment-request-api-now-being-implemented-in-all-major-browsers-advances-on-the-recommendation-track/

[4] https://tokenize.com/



In the introduction, the authors have given examples where the consents have been mishandled. Some of the examples are not specific to the consent mishandling, for example, the DECREASE studies where the concern was of falsifying the data as a whole. The manuscript would look more precise if examples of clinical trials or research studies specific to consent mishandling are given. 

We did not find a study about which the problems was strictly limited to consent issues, it appears that study stained by misconducts carries a wide range of flaws, amongst which ones related to consent. We added some reference [1] about frauds in clinical trials and where the author reports the issue of backdating consent document and indicates that the most commonly fabricated documents are patient diaries and informed consent Forms. In [2] reports mishandlings of consent documents that were backdated. We refer also to the FDA report that is referred in [2] but no longer accessible on their website but we found here [3] 

Our blockchain implementation in order to improve the consent process finds its rationale in studies reporting issues compromising the consent process quality. Indeed, study compiling FDA clinical trials inspections from 1977 to 2009, revealed that 2/3rd of clinicals trials were assessed as carrying misconducts, around 15% of the latter were related to serious consent process flaws, main of which were: failure to obtain written informed consent, failure to provide copies of the document to subjects, consent document not signed or not dated, missing pages in consent document provided to subjects, failure to re-consent when new information becomes available, use of wrong forms, use of expired, non-validated or unapproved forms, the only document last page kept in study files, (reference [3,4] in the manuscript). 
According to [4], we note a decreasing global trend of the issues observed in the setting of FDA investigations: for the period from 2000 to 2009 versus 1990 to 1999, the issues related to consent process in the audited clinical trials have been divided by a factor 4. However, Seife and al. (reference 5 in the manuscript) that emits serious doubts upon the results of FDA [5] and studied clinical trials from 1998 to 2013, and grouping together failure to protect the safety of patient and consents, found that these correspond to more than a half of the issues misconduct in the scrutinized clinical trials.

We updated the text accordingly and added right references.

[1] Gupta, A. (2013). Fraud and misconduct in clinical research: A concern. Perspectives in Clinical Research, 4(2), p.144.

[2] Hazra, A. (2011). Use, abuse and misuse of notes to file. Perspectives in Clinical Research, 2(1), p.38.

[3] http://klinikfarmakoloji.com/files/ketek%20FDA%20mektubu.pdf

[4] Morgan-Linnell, S., Stewart, D. and Kurzrock, R. (2014). U.S. Food and Drug Administration Inspections of Clinical Investigators: Overview of Results from 1977 to 2009. Clinical Cancer Research, 20(13), pp.3364-3370.

[5] http://www.slate.com/articles/health_and_science/science/2015/02/fda_inspections_fraud_fabrication_and_scientific_misconduct_are_hidden_from.html



Secondly, the authors highlight the empowering the patients and improved enrollment in a clinical trial. It would help if authors expand on patient empowering. From the manuscript’s current structure, the patient empowerment remains at same status as it would be in a written consent, to the extent that patients can pull out of the study whenever they want and can see which entities are involved in the study. Hence, a discussion about this crucial aspect is worth including in the manuscript. 

Indeed, you are right to say that the current implementation of our consent workflow do not directly improve the enrollment rate. But, our point is to focus on trust, and we mean that trust is central to clinical trials engagement. As explored in [1], lack of trust of industry-sponsored clinical trials, and as indicated in this very paper especially the requirements that surrounds consent process, may create confusion or even reluctance to join clinical trials. Moreover, as detailed in [2], given the trend to design clinical studies that can leverage the opportunity of data massiveness and real time, building robust reliable online consent is of substantial importance and can help engaging more people in participating to clinical research from every where they are on the internet. From an other perspective but leading to the same idea, a recent paper published in Nature [3] asserts that privacy and consent are one of the 4 ethical priorities of Neurotechnologies and AI, we think that it is more generally the case for the whole field of clinical research which is going to be more and more tech-intensive. In this very paper, Blockchain and Smart Contracts are announced to be interesting tool to tackle this challenge. We think these tools in bringing more reliability and trust into clinical trials meet patients concerns and can form a solid ground to engage subjects. 

Indeed, Blockchain helps build reliable processes since the decentralized nature of the protocol and the validation of each transaction by consensus is key to achieve this trust. In our setting, each of the user interactions, consent status, protocol versionning, re-consent status accordingly to these very protocol versions, is “proof-checkable” by anybody. 
Culturally and historically, Blockchain technologies were invented to address the very issue of trust towards industries and even public institutions, distributed network were thought as a kind of response to the lack of trust by conceiving an interaction network architecture which do not relies on a single trusted third party, as credible as it might be, but on distributing to each node of the network a granular part of trust, so that trust compromising would suppose an unfair agreement involving strictly more than a half of the network participants, which occurrence lowers fast when the number of nodes increases. We believe that at least on principle, Blockchain technologies in distributing securely proof of data and by providing technological guarantees to consolidate a network of trust, unite the conditions to find a tool to restore confidence in building consent process reliable and getting patients to join. 

We updated the text accordingly in order to stress the fact trust is the critical pivot to engage subjects in clinical trials, and Blockchain is precisely a technology that was designed to enforce trust. We re-affirmed this point at the beginning of the Discussion section.


[1] Transforming Clinical Research in the United States: Challenges and Opportunities: Workshop Summary. Institute of Medicine (US) Forum on Drug Discovery, Development, and Translation.
Washington (DC): National Academies Press (US); 2010.

[2] New England Journal of Medicine. (2017). Informed Consent — NEJM. [online] Available at: http://www.nejm.org/doi/full/10.1056/NEJMra1603773?query=featured_clinical-trials

[3] Yuste, R & All (2017). Four ethical priorities for neurotechnologies and AI. Nature, 551(7679), pp.159-163.



Thirdly, the general descriptions of blockchain (ie, 'a giant public datastore') are not entirely correct, and the strengths of the technology ('backbone of the circulation of digital assets, powering any kind of services…') are overstated.

As, for the statement `backbone of the circulation of digital assets`, if we appreciate blockchain at a generic level, one can draw our attention to Smart Contracts, and these enable the conception of wide range of generic services that supposes contract between parties agreeing on “computer-encodable” terms.
On Bitcoin blockchain, transactions are executed through some scripts, coded with a stack based langage called bitscript. The scripts are kind of rudimentary Smart Contracts, and they open the possibility to have interactions beyond the bitcoin exchanges : smart property, lotteries, proof-of-knowledge. More interestingly, an other popular blockchain, Ethereum relies heavily on Smart Contracts, these are contracts algorithmically implemented on the top of Blockchain and fix rules about which parties agree on, and in our context fixing as specific as needed criteria. A very wide range of services are now provided through Smart Contracts : vote, insurances contracts, data sharing, land property, domain name system for the internet, electronic health records even marriage contracts. 

We meant by blockchain becoming some backbone of digital assets the idea to enlarge the purpose of Blockchain beyond cryptocurrencies and manifest that the applications can be quite diverse. However, we understand that this expression is too general and we updated the manuscript accordingly.

Furthermore, the unfalsifiable nature of any particular blockchain depends on a distributed deployment, as in many implementations, the person/group owning a majority of the miners could change or alter data. Authors should elaborate on these specifics so that the readers have the understanding of the specific nuances of blockchain. Finally, many of the concerns and issues with consent noted in the introduction (not obtaining IRB approval of new consent forms, etc) are administrative issues – auditing of these updates could be done with the system presented here, but use of blockchain alone would not necessarily prevent all of these issues from occurring.

As for the resilience of the blockchain to adverse attacks, the most natural one we can think of would be to acquire some more nodes in the network and then win the game since the attacker would have a computing power advantage as for the Proof-of-Work validation, this is called the sybil attack. But, the larger the network grows, the harder is the difficulty of the Proof-of-Work problem solving, so these kind of attacks are easily defeated. In the spirit, a most well-known attack is the so-called 51% attack, when some adversary gets more than a half of the computing power. This is not to be excluded but never happened successfully so far on the Bitcoin Network. Here, we want to precise that even if such a situation happened, then first there won’t be any chance for an attacker to steal bitcoin, because each transaction supposes the digital signature of the sender, which in turn supposes to be in a possession of the related private key, second this would prevent such an attacker to continue gaining money through mining, since the “double spend” attempts would be noticeable, and so the bitcoin value will fall, and  there won’t be any interest to continue.

Besides, Blockchain is not a one-size fits-all solution and some issue can’t be addressed by the blockchain alone, but as to the issues stated, using blockchain enables to keep track of the consent document, to version it through timestamping, to control its format, its consistency and its immutability, to ensure subjects’ consent and re-consent status with respect to changes of the protocol, and to make all the process “proof checkable”, so that failure to obtain written informed consent, failure to provide copies of the document to subjects, consent document not signed or not dated, missing pages in consent document provided to subjects, failure to re-consent when new information becomes available, use of wrong forms, use of expired, non-validated or unapproved forms, the only document last page kept in study files, falls in the scope of what can be better controlled by Blockchain technologies. Binding hashed of the protocol and its versions to the consent, preventing from backdating and giving not only a timestamping but a trusted one strengths the consent process.


We updated accordingly the manuscript. 

In the methods section, the authors argue on why they opted for bitcoin blockchain (because of stability, immutability, large mining network). Given that the authors rely on smart contracts for future developments, it is difficult to understand why they did not opt for the Ethereum which has the same benefits as those of bitcoin blockchain with added benefit of smart contract platform. The manuscript would improve if the authors give more context on their choice, and also, what they envision would be used in a real-world application of their POC in a clinical trial.

The choice of bitcoin was motivated because it is a robust network, born in 2009, and because it allowed us in a rather simple manner to group the transactions in order to save the eventual clinical trials of the cost of the validation of each transaction. Moreover, though we did not use that feature, Bitcoin allows transaction taking multiple inputs (and in fact multiple outputs), and so requiring multi-sig signatures. We think that it could be an interesting feature when put in a context of a real life clinical trial where user would store on their side the pair of keys and would help group the transactions and validate them as a whole. 

Ethereum is more recent, it was released in 2015 and indeed we are definitely sure that it can host transactions we want to achieve. But in order to group the transactions, it would have required the implementation of more complicated Smart Contracts, although Smart Contract has a major benefit in that it enables a great flexibility when mastered. Indeed, Ethereum do not allow multiple inputs and to achieve our goal, it would have needed two contracts, the first would have register some transactions, when some amount of ETH (the ethereum money) or some number of transactions would have reached a pre-defined threshold, and then send the ETH to a second contract.   

We have updated the manuscript in order to motivate more clearly our choice. Besides, we refer the reviewer to the detailed first answer of this document as to a possible real life implementation.  

The authors state in prior reviews that the exact chaincode/blockchain data cannot be shared for review purposes due to the presence of private information. While this is undoubtedly true, it is difficult to understand, based on the current description, how the authors envision deploying a decentralized system if this is an issue. 

In the current implementation, the current bitcoin transactions can absolutely be made public since any entries are hashed and so encrypted. However, the ChainScript, which is the master document holds the raw data of the consent process. If some stakeholder wants to claim that these are the true data, then any regulator or any body in charge of the verification of the sincerity of the data, either a regulatory, a stakeholder, a publisher willing to verify them, is in a situation to prove the data sincerity on public website, as `blockchain.info` or `live.blockcypher.com` (cf. the above response to the question you raised about the “ ‘publically verifiable’ ” nature of the data, or to be more precise the proof-of-data).


We agree with concerns from other reviewers regarding how much of a proof of concept was implemented, and concerns with key steps of the process such as identify verification. While it is understood that this is a proof of concept, it would be helpful as a method paper to at least detail how these issues would be resolved in an actual application deployed beyond the proof of concept stage.


We detailed in the answer of your question beginning with “This then boils down to the physical identity crisis...” how we would deal in a real life clinical trial. It appears that there are different interesting reasonable solutions : to summarize, one way is to equip them with USB keys, already available on the market, that could be sent or given by hand by investigators when meeting the subjects, this USB key is then plugged in any user device and let them activate their transaction with a simple 4 digits PIN code, an other by directly attaching the pair of keys to his browser. Then these bitcoin addresses would be funded by the stakeholder in order for the user to proceed the transactions. 

A second concern is related to the choice of the blockchain network. Bitcoin seems to us a good and robust choice, however if we want to go to further implementation, such as automating the re-consent process when protocol is the subject of major changes, then Ethereum can be a relevant choice in the sense that it allows benefit of the full flexibility of Smart Contracts. Besides and for the record, we mention a possible alternative with regard to the blockchain network: we could think of using permissionned blockchain, or even private blockchains that we briefly evoked in the manuscript, but we believe that public blockchains unite conditions of trust, since nodes participating to the validation are not selected by any third-party.

We updated accordingly the manuscript by indicating the range of solutions that we envision as for the public/private key management and the choice of the Blockchain network.  


Another aspect of the blockchain important to discuss is the cost effectiveness. Blockchain is resource intensive technology which requires a lot of computational power. Given that the funding of the many research studies is limited, a calculated investment is always required. If authors can talk a little about the logistics and cost effectiveness of this blockchain setup, it would bring a new dimension to the manuscript.  

As mentioned sooner in these responses, we took a great care to integrate by design the cost-effectiveness. This is the reason why we build a data-structure allowing to group transactions in order to limit the cost. We can host in one binary tree called a Merkle tree hundred of thousands of hashes represented by their Merkle root and these informations are stored in a bitcoin transaction. For memory, the transaction fees are around 0.0015 BTC to 0.0016 BTC, depending on the priority of the transactions and we can group transactions by slices of 1000 or 10.000 batches of data, or even more, so that even for large clinical trials the cost would be controlled to the level of some milli-bitcoins. We refer the reader to [1] to check the cost of the bitcoin fees

From an other point of view, there are currently many implementations that tries to tackle the mobilization of such energy consumption in a context of global environment issues. There are Altcoins, that uses Proof-of-Storage instead of Proof-Of-Work, so that the transaction fees consists in accepting to fill some disk space rather than consuming CPUs processing. Some of these, as StoreJ or file.io are quite popular and one can consider them as interesting blockchain on the top of which one can build advanced processes. Ethereum announced their next implementation, called CASPER, based on a Proof-of-Stake rather than Proof-of-Work consensus algorithms, which propose to replace the provision of CPU power by a economic contribution depending on the size of a deposit.

We updated the manuscript to tackle this issue. 

[1] https://live.blockcypher.com/btc/


Finally, the manuscript can improve on the language. Even after three revisions, there are typing and grammatical errors which are concerning. Manuscript can improve a lot if the authors can thoroughly proof read the manuscript and revise accordingly.

Thank you for drawing our attention to this point, we updated our manuscript and corrected typing and grammatical errors.

Dear reviewer,
 
Thank you for these precious remarks and letting us have the possibility to improve the quality of our work. Hereafter, we provided responses to the raised issues
 
1. The centrality of consent is incontrovertible. What the authors propose here is a radical solution that has enormous infrastructural and resource implications. The paper would be more compelling if the authors demonstrated that there was a systematic problem in how consents are currently obtained and that, in theory at least, that this method would address these problems, in particular the issue of the need for changing consents.
 
 
The rationale to implement blockchain solutions to improve the consent process is based on issues undermining the quality of the latter, these were for instance reported by FDA. Indeed, a study compiling FDA inspected clinical trials from 1977 to 2009, revealed that 2/3rd of clinicals trials were misconduct, around 15% of the latter were related to serious consent process flaws, main of which were failure to obtain written informed consent, failure to provide copies of the document to subjects, consent document not signed or not dated, missing pages in consent document provided to subjects, failure to re-consent when new information becomes available, use of wrong forms, use of expired, non-validated or unapproved forms, the only document last page kept in study files, (reference [3,4] in the manuscript). However, we note that the global trend is the decrease of the issues observed in the setting of FDA investigations, for the period from 2000 to 2009 versus 1990 to 1999, the issues related to consent process in the audited clinical trials have been divided by a factor 4 [1]. From a similar perspective, studying clinical trials from 1998 to 2013, Seife and al. (reference 5 in the manuscript), grouping together  failure to protect the safety of patient and consents, found that these correspond to more than a half of the issues misconduct in the scrutinized clinical trials.
In this context, using blockchain enables to keep track of the consent document, to version it through timestamping, to control its format, its consistency and its immutability, to ensure subjects’ consent and re-consent status with respect to changes of the protocol, and to make all the process “proof checkable”. Indeed, one core functionality is unfalsifiable timestamping, so that our implementation outputs a single master document accounting for the whole consent process and if any single datum would be corrupted then the whole consent would be broken. This master document can then be checked in any public website offering a service consisting in verifying the correspondence between data and its hashed counterpart, i.e. its proof of existence stored in the blockchain.
 
We would also like to underline some additional points which justify in our view the potential of blockchain and smart contracts for consent, as we have implemented her. Indeed, in a more prospective way,
 
- we anticipate that Smart Contracts which are contracts algorithmically implemented on the top of Blockchain and fix rules about which parties agree on, and in our context fixing as specific as needed criteria that would account for what clinical trial stakeholders consider as consent process quality rules, could help automate a large part of consent process validity checking. For instance, we can realistically bind automatically any change in the protocol to the patient re-consent seeking, the latter being a vast subject of concern (reference 1 in the manuscript). 
 
- besides, there is strong trend of research to build clinical studies design that can be adapted to the massiveness and real time of data. In this context as developed in [2], building robust reliable online consent is of substantial importance and can help engaging more people in participating to clinical research from every where they are on the internet. In the view of developing observational studies based on the analysis of real life data, developing reliable online consent is of importance. Indeed, we live in a current era of massively produced data, by 2020 one will count 20 billions devices and according to some studies, by 2030, 500 billion devices and objects will be connected to the internet [3,4]. In addition to the 2.5 exabytes of data produced each day, i.e. 10^18 bytes of data, the expected billions of connected objects will receive and produce data in the so called IoT, and this can be considered as many data that can have a potentially health significance given the power of new algorithms and artificial intelligence (AI) techniques derived from Machine learning. There are current implementations of Blockchain specifically designed for the IoT network, such as IOTA [5] and there is a lot to be done to build consent processes adapted to these kind of studies.
A recent paper published in Nature [6] asserts that privacy and consent are one of the 4 ethical priorities of Neurotechnologies and AI, we think that it is more generally the case for the whole field of clinical research which is going to be more and more tech-intensive. In this very paper, Blockchain and Smart Contracts are announced to be interesting tool to tackle this challenge.
 
- From a general point of view, as explored in [7], lack of trust of industry-sponsored clinical trials, especially the requirements that surrounds consent process, may create confusion or even reluctance to join clinical trial.
But, culturally and historically, Blockchain technologies were invented to address the very issue of trust towards industries and even public institutions, distributed network were thought as a kind of response to the lack of trust by conceiving an interaction network architecture which do not relies on a single trusted third party, as credible as it might be, but on distributing to each node of the network a granular part of trust, so that trust compromising would suppose an unfair agreement involving strictly more than a half of the network participants, which occurrence lowers fast when the number of nodes increases. We believe that at least on principle, Blockchain technologies in distributing securely proof of data and by providing technological guarantees to consolidate a network of trust, unite the conditions to find a tool to restore confidence in building consent process reliable and getting patients to join.
 
 
We updated the manuscript in order to add some consent process issues, for example "failure to provide copies of the document to subjects", and precise that while issues regarding the consent process in clinical trials are substantial, we notice in the same time that the global trend of FDA studies shows a decreasing trend of the so called OIA, and this concerns consent as well.
 
Besides, in a context of an extreme sensitivity about right to informations, privacy respect, building a consent process as irreproachable as what could be achieved using the current state of knowledge and technologies, is critical: trust is the critical pivot to engage subjects in clinical trials, and Blockchain is precisely a technology that was designed to enforce trust. We re-affirmed this point at the beginning of the Discussion section. Besides, again in Discussion section, we updated the document in order to put in perspective that quality of consent process is critical, especially in a remote setting given the place that should take online studies in current Big Data and connected devices era.
 
 
[1] Morgan-Linnell, S., Stewart, D. and Kurzrock, R. (2014). U.S. Food and Drug Administration Inspections of Clinical Investigators: Overview of Results from 1977 to 2009. Clinical Cancer Research, 20(13), pp.3364-3370.
 
[2] New England Journal of Medicine. (2017). Informed Consent — NEJM. [online] Available at: http://www.nejm.org/doi/full/10.1056/NEJMra1603773?query=featured_clinical-trials
 
[3] Internet of Things report, Cisco https://www.cisco.com/c/r/en/us/internet-of-everything-ioe/internet-of-things-iot/index.html
 
[4] https://www.gartner.com/newsroom/id/3598917
 
[5] IOTA, https://iota.org/
 
[6] Yuste, R & All (2017). Four ethical priorities for neurotechnologies and AI. Nature, 551(7679), pp.159-163.
 
[7] Transforming Clinical Research in the United States: Challenges and Opportunities: Workshop Summary. Institute of Medicine (US) Forum on Drug Discovery, Development, and Translation.
Washington (DC): National Academies Press (US); 2010.
 
 
2. The IT requirements around clinical trials in particular is already substantial. The notion of a parallel process for all of the data management systems and then for consent sounds particularly daunting. Is it possible that the two systems could be integrated? Otherwise I fear that this approach has limited feasibility.
 
We think that the consent process we suggest can be without hassle fully integrated in a data management system. Indeed, it can be wrapped up as a plugin or even more simply accessible from an API - Application Program Interface. Indeed, the main issue is to access a notarization tool from any data management system. In our implementation, in the `README.md` file -https://github.com/benchoufi/DocChain/blob/master/README.md- we refered to an API handling the bitcoin interactions, exposed through URL such as https://docchain.stratumn.net/some/path/to/some/services. This gives an endpoint to connect a data system to blockchain transactions. 
 
Besides, if one wants to build such a tool from scratch, it needs expertise but can be done : in substance the core part of the software logic relies on the notarization process, which deals with blockchain transactions, precisely the possibility to put on a blockchain the proof of informations which are believed to be critical and about which we want to ensure sincerity. Since all the pieces of softwares to build such a solution are largely available in Open Source, the required IT tools can be found easily. However, to build a solid, professional notarization tool, keeping track of protocol versions, and compliant with a careful use of the bitcoin valued transactions that can be costly if considered in a context of a large clinical trial, then this requires more advanced skills. For instance, we make use of specific data-structures which enables to group together transactions and then validate them in a same pool. This has the advantage of using with parsimony the blockchain bitcoin-costly transactions though preserving the integrity of the data, since any bit of data in this data-structure would have been flawed, the entire data-structure would be broken. Again, a tool that would be build up in this manner could be fully integrated to a current data management system, blockchain interactions would be designed as API calls to services.
 
For the record, we indicate in the manuscript that the transaction fees vary between 0.0015 BTC to 0.0016 BTC, depending on the priority attached to these transactions. In our setting, thanks to the data-structure, wich is a binary tree called Merkle tree, we can manage hundred of thousand of hashes in a single transaction. Then, in a live clinical trial; we can group transactions by slices of 1000 or 10.000 batches of data, or even more, so that cost can be controlled to the level of some milli-bitcoins. We refer the reader to [1] to check the cost of the bitcoin fees
 
 
With regards to the mentioned expertise for developers to build such tool. We want here to stress two facts
- in the upcoming months, blockchain programming tools will to be considerably simplified thanks to the current great effort led by open source communities to abstract out all the complexity into frameworks. We can draw a consistent parallelism with the web tools which were rather complicated in the mid 90's and that were rapidly proposed through high level frameworks usable by anyone including anybody not familiar with web development but able to click-and-deploy webiste, being only concerned by adding some text and image contents.
- a good example to build a notarization service that would not require so much expertise would be to access the notarization process from services that offer ready-to-use APIs. A good example of such a service can be found in [2].
 
[1] https://live.blockcypher.com/btc/
[2] https://poex.io/developers
 
We updated the document and proposed a `Guide to installation` document in which whe detail the tools needed to reproduce the experiment.
 
3. I'm sure the authors would agree that a trial among a group of research-literate participants is very different to typical research participants. One critical element around proof of concept is not the IT/software capability but whether participants would even use such an approach once, let alone multiple times. As it stands the current study is pre-proof of concept perhaps.
 
Thank you for giving the opportunity to say that what we consider to be interesting in the current setting is that the solution is almost ready to use in a production setting. Indeed, the blockchain complexity is totally hidden from the interacting user. So that in practice, from a user point of view, there is no burden in the front-end website interactions, though they should be informed that technical - blockchain - guarantees have been taken to ensure transparency and security of the consent process. None of the complex technical aspects interferes with their experience. The process is transparent for the user in the sense that all the complexity of blockchain transactions is taken care by the back-end server. However, the essential part of the issues that can be raised are related to the online nature of the implemented process.
 
As mentioned in your comments, what we considered as a proof-of-concept needs to be customized and validated in real context. Our work needs a feasibility study that we will to conduct. And, two main points may be worked out in a real production clinical trial
 
1. Keys authentication forwarding issue
 
In the context of this POC, we are aware that we implemented a functional solution about which we did not tackle the question of ensuring user detains keys authentication engaging directly the blockchain transaction when submitting action on the website, since this was not our primary concern. In a production setting, we could go through storing the authentication keys on line, or to store them in physical objects, such as USB keys, protected by a password or a PIN code. There are plenty of  so called Hardware Wallet [1].
In this spirit, we believe the simplest way to improve user authentication is to store keys in the web-browser. We think that it is safe enough in our context and it would have the major benefit for the user not to worry a single time about this authentication process. Besides, this would suppose that the stakeholders fund the bitcoin account - or anly Blockhain related network account - of each subjects in order for them to process directly the transactions. Moreover, using Smart Contracts network, for instance on ethereum, these very transactions could be grouped together in a simple manner.
 
However, we believe that the current state of the implementation is directly usable for clinical trials the way they are conducted today. Indeed, we won’t deal in that case with advanced double keys user authentication process. This supposes that some stakeholders have root-permissions to create key pairs to be trusted. The current process of clinical trials heavily relies on the existence of such stakeholders such as investigators, sponsors, regulatory agencies or IRBs, and if we consider the most trustable of them, we can still benefit from the robust, verifiable characteristics of blockchain technologies but with a supplementary point of trust towards a third party. For instance, to prevent from key forgery, these could be generated by the sponsor or any other external party under the supervision of the sponsor, such as regulatory agency or the IRB, and given by hand to the patient in an USB keys or any other support along with information documents through.
 
2. ensure that the informations have correctly been understood by the reader. Though this is not related with the blockchain based tool but the on-line nature of the online consent tool, we believe that there could be improvement by ensuring the correct understanding of the user by first proposing a pedagogical presentation video and suggesting him a quizz after the reading of the protocol he is about to consent or not. There are bunch of tools and references on the subject. Here's some :
 
We updated accordingly the manuscript to signify that no peculiar expertise is required to make use of the tool. However, we indicate that the current process can be strengthened, especially to ensure subject understanding of protocol leading to an improved consent decision.
 
[1] https://bitcoin.stackexchange.com/questions/19646/wallet-advice-for-users-without-technical-knowledge

Dear reviewer, 

Thank you for drawing our attention on the questions you raised. Our answer focuses mainly on the issue related to the binding between digital identities and physical entities. 

We updated the revised version accordingly to all the questions you raised.  

Target of the POC and digitale identities

POC as a response to FDA raised issues

Thank you for your constructive remarks. In fact, there are two main issues regarding the consent process. The first one is related to the quality of the process itself and the second one is related to the identity of the individual consenting. Monitoring of trials by the FDA has identified serious issues in about 10% of trials, major concerns being failure to obtain written informed consent, consent document not signed or not dated, missing pages in consent document provided to subjects,failure to re-consent when new information becomes available, use of expired, non-validated or unapproved forms (reference [3,4] in the manuscript and this link). In this POC study, we aimed at fighting these issues, where existing patients were included in a study in the presence of their physician or staff. In our implementation, we ensured that all the consent process was tracked in time all along the inclusion period, that the documents made available to the subjects were not corrupted, that they were in conformity with the current version of the protocol, and that (re-)consent was asked as many time as required. We however did not address the cases where consents were falsified by the investigating teams or where fake patients were invented for instance, which are more related to the second (identity) issue. This should be more explicit in the text, and has been emphasized in the revised manuscript.  

Linking digital identities and physical entities

We then agree with the reviewer that the second issue is important in the context of a real clinical trial. This relates to the question of pairing digital identification with physical persons. In our implementation of the POC study, the link between a participant and his/her digital identity is done through his/her email address. A participant cannot simply generate any Bitcoin address and use it to sign, because the private key is created on the server by the agent (but not saved on the server), then is sent to the email address. So the only guarantee is that the participant had access to that email address. This is pretty light, but seemed to be satisfactory given the scope and focus of the POC. Moreover, in the setting of a real online consent process, there is no chance that a patient who would not effectively consent—for instance if there were some fraudulous operation registering him/her as a consenting subject—would actually participate to the study.
However, in a production application we must implement a more secure mechanism, and we thank the reviewer again for outlining the possibilities. There are indeed several solution to secure the digital identity of participants.

First, we can mention that KYC processes are now quite widespread and there are plenty of examples where digital identities are linked to physical entities or human beings in the context of sensitive data: in most western countries the fiscal administration allows online service for taxpayers to declare their income and proceed to related operations, banking services also provides their services online such as bank transfer, account consultation. All these examples have in common that users (taxpayers, bank clients) are given a physical material, often by sending a document by regular postal service, or by giving a first card or document by hand. These documents carry an identification number. This approach could be implemented in production.

Second, even in regular off-line consent process, ensuring that the patient really signed the document is not without carrying problems. We have in mind that the patient must meet the medical doctor and receive by hand their consent document. So that, when they go back to the medical doctor with the signed document, there is no way to prove that it was signed by the patients himself or that the patient was not influenced at the time of signing the consent form.
Regarding a possible implementation of our blockchained consent process in a real clinical trial, we can provide, at the moment the patient meets the doctor, authentication cards with an identification number and so strengthen the binding between the electronic signature id and the physical one. Let’s mention that some bitcoin companies also provide material keys, such as USB keys, that hold the cryptographic signature, which can be unlocked by an easy-to-remember code. This can be an excellent candidate to get stronger digital-physical binding. These issues are now covered in the revised discussion.

Besides, we think that full online consent collection process raises more the issue to reach subjects that the one related to ensuring the targeted patient is really the one consenting.

Patients invention

Going further, we can summarily refer to the extreme case of patients invention. Unfortunately, there is almost no way to prevent data invention. And there are some documented case in the medical literature, fortunately very rare, where clinical trial patients and all related clinical data were invented from end to end. Let’s notice here that, in the first implementation of our POC, we timestamped an extensive part of interactions between the subjects and the online email and web platform : time of the email sending, reception, time email was opened, the links being clicked on. We then validated the transactions into the blockchain, this way we could at least detect anomalies if such data appear grouped in time, so that it does not prevent from invention but higher the barrier to fraud.  

Further technical improvements

On a more technical side, Stratumn’s technology, via proof-of-process, provide an implementation that would allow one to create an audit trail of the the different steps that happened until the participant provided enough evidence to convince the verifier of his/her identity, which is quite an upgrade to current KYC processes, because there would be a permanent record of what happened, and the process would impose rules that must be respected to the letter (by computer code) before moving to the next step. In short, this is not a complete out-of-the-box solution to linking digital identities, but Stratumn has the tools to build one. While implementing such a verification process with the technology is possible, this was beyond the scope of the POC.

Smart Contracts

Indeed, we did not implement it in our setting, we meant to mention that Smart Contract can bind the modifications occurred in the protocol and some to be defined events on which parties can agree.  
Besides, we did not detail or implement in the article all the advantages that can be derived from the algorithmic nature of the Smart Contracts: the way consent process is monitored, the way the related informations are shared between the stakeholders, the investigators and the IRB or building Smart contracts with the condition patients will only be included when the enrolment is complete or building one checking the whole consistency between the data and the blockchained proof of data, preventing from the whole hassle of gathering the documents and checking them by hand


Figures

Indeed, some figures are in french and we complied to the F1000 policy that invited us to proceed so.

Bibliography

We thank the reviewer for the precious remarks about bibliography and to have brought to the knowledge of the authors two of them, namely the one referred as `OriginStamp` and the Carlisle blogpost. We add and referenced them in the revised document.


Best regards,