Collector Search Failed Trial Edition Expired Amoxicillin

12/23/2017by admin

Evaluation of rational drug use based on World Health Organization core drug use indicators in selected public hospitals of eastern Ethiopia: a cross sectional study. Mekonnen SisayEmail authorView ORCID ID profile,; Getnet Mengistu,; Bereket Molla,; Firehiwot Amare and; Tesfaye Gabriel. BMC Health Services.

Clinical trial consent for protocols and their revisions should be transparent for patients and traceable for stakeholders. Our goal is to implement a process allowing for collection of patients’ informed consent, which is bound to protocol revisions, storing and tracking the consent in a secure, unfalsifiable and publicly verifiable way, and enabling the sharing of this information in real time. For that, we build a consent workflow using a trending technology called Blockchain. This is a distributed technology that brings a built-in layer of transparency and traceability.

From a more general and prospective point of view, we believe Blockchain technology brings a paradigmatical shift to the entire clinical research field. We designed a Proof-of-Concept protocol consisting of time-stamping each step of the patient’s consent collection using Blockchain, thus archiving and historicising the consent through cryptographic validation in a securely unfalsifiable and transparent way. For each protocol revision, consent was sought again. We obtained a single document, in an open format, that accounted for the whole consent collection process: a time-stamped consent status regarding each version of the protocol. This document cannot be corrupted and can be checked on any dedicated public website. It should be considered a robust proof of data. However, in a live clinical trial, the authentication system should be strengthened to remove the need for third parties, here trial stakeholders, and give participative control to the peer users.

In the future, the complex data flow of a clinical trial could be tracked by using Blockchain, which core functionality, named Smart Contract, could help prevent clinical trial events not occurring in the correct chronological order, for example including patients before they consented or analysing case report form data before freezing the database. Globally, Blockchain could help with reliability, security, transparency and could be a consistent step toward reproducibility. Introduction Patient participation is the sine qua non condition for clinical trials to happen and for medical research to improve, (). However, in practice, the informed consent process is difficult to handle in a rigorous and satisfactory way. Consent collection Blockchain workflow. Blockchain is a new technology, a giant shared datastore, stored in a secure and decentralised way (see Sotoshi Nakamoto seminal paper, ).

Collector Search Failed Trial Edition Expired Amoxicillin

It is widely considered a core infra-structure of digital assets about which we want to ensure reliability, powering a wide range of services by transparency and traceability. In this context, the Blockchain emerging and promising technology () can bring a solid basis for the enrolment phase transparently to all stakeholders of a clinical trial, especially in the context of obtaining participant consent. Three core functional principles of this technology can play a fundamental role, as follows. Unfalsifiable time-stamping information: that is, proof of existence of any piece of data. When stored, this data is provable and immutable via a strong cryptographic protocol. Moreover, these proofs of existence can be checked on a public website (, ). This transparency is of interest to any interested stakeholder.

Smart contract: a contract that is algorithmically implemented and binds any change in the protocol to the patients consent seeking renewal. Decentralized nature of the protocol: gives to the patient, or more widely to patient communities, control over their consent and its revocation. The end-to-end connectivity creates a network that empowers patients and researchers as peers. The current implementation is an application of the first principle. Ideally, we have to build a patient authentication system that does not rely on any trial stakeholder so that we can benefit from the decentralised and trustless nature of the Blockchain network. In a broader clinical trial setting, with the secure time-stamping functionality, Blockchain can directly help prevent a posteriori reconstruction of endpoints or outcomes in clinical trials (). Blockchain comes into play At a clinical trial level.

Blockchain technology can act as a SafeGuard for the complex and wide range of actors required in clinical trials. In practice, the proof of existence for consent will be time-stamped and stored in Blockchains, enabling clinical research stakeholders, such as sponsors, investigators and IRBs, which can be numerous in multi-center clinical investigations, to share consent and re-consent related data in real time, and archive and historicize consent sets, which can be matched with each revision of the protocol. At a patient level. Implementing a “privacy by design” technology, and archiving securely and transparently any dataset that needs to be stored, is a game changer toward improving enrolment phase methodology. Moreover, drawing on ways to collect securely and transparently informed consent, being careful with participants rights, and so empowering them, could improve the enrolment rate. Indeed, the participation rate in clinical trials remains quite weak. A systematic review comparing different enrolment techniques showed that, among several other explanations, the condition of collecting patients consent in an open and secure way was best at achieving an improved rate of enrolment.

Blockchain networks There are several Blockchain networks; examples are Ethereum (), Bitcoin () and Hyperledger (). For our purpose, transactions and their validations were run on the Bitcoin network because of the stability and immutability of the Bitcoin Blockchain with its large mining network, and the Application Programs Interface (API) it provides facilitates development. Moreover, it is the more widely used Blockchain network; therefore, a relatively dense community of developers enables efficient support ().

The front-end and back-end technologies that are detailed hereafter were implemented by using a Blockchain solutions provider, Stratumn SAS (). A website was developed with a simple one-page interface (). On the front-end, it displayed the consent document, a checkbox attesting that the protocol was read and understood, and a push button that triggered the consent process. Patients web-interface for Blockchained consent collection website. In practice, the online signed document contained a piece of code called “Chainscript” (), which contained all the critical information about the user, and the version of the protocol attached to the signature. Each proof of signature had a manifest that takes the form of a “hash” that is the digital proof of signature. On the back-end, pressing the “consent button” triggers Blockchain transactions: the proof of signature is time-stamped and stored in the Blockchain.

These signatures were shared in real-time with a restricted group of individuals, namely the authors of this paper, who represent, in a real-life implementation, investigators, IRBs or sponsors. This group had access to a dashboard () with the following: an administrator panel displaying the consent status of each user; the protocol that transparently stores the public keys of each consenting user (through Chainscript); and the history of each released version of the protocol and the consent and re-consent of the user attached to each of these versions.

Authentication method For each user, a pair of private-public keys were provided (). These are asymmetric cryptographic data that enable authentication on Blockchain. These were randomly attached in one-to-one correspondence to the user’s emails. We focused on Blockchain’s usage in the time-stamping and archiving logic.

We did not let users create or use their own Blockchain authentication setup (i.e., if a user owned a Bitcoin account, the key and Bitcoin address were not allowed to be used). This restriction was not related to the Blockchain complexity but rather to maintain a simple and common email-focused authentication process. Other ways for authentication include the physical devices USB keys or cell phone fingerprints, but this would have led us far from the focus point of our protocol-related problematics. • • The study investigators send an email to the user.

• • The user receives the email, which contains a web hyperlink redirecting them to the web interface that displays the consent form. • • In the background, after clicking the consent button without the user experience being bothered by any blockchain transaction-related complexity, the user signature is registered to the Blockchain and is time-stamped. • • Each time the protocol is updated, investigators send an email explaining the major changes that occurred and users are invited to sign the revised consent form. • • Each step of this process is updated on the investigators’ administrator panel with the version of the consent document and the user's consenting status. Proof of existence - Chainscript Signatures of the evolving consent document were registered to the Blockchain. Moreover, all of the relevant interactions of the user with our platform were stored in the Blockchain (i.e., the consent form uploaded by the investigator; email requests to users, and patient signatures) according to the Proof-of-Process concept developed by Stratumn, a method for proving the integrity of a process between partners (). The piece of data attesting and synthesising all this information is called a Chainscript.

It is a JSON formatted data structure holding all the information related to the protocol and users’ consent. Chainscript was developed by Stratumn SAS, especially dedicated to attest the steps in trusted workflows (). Chainscript is an open standard. The philosophy behind it is to be able to prove the integrity of a process with a single JSON data structure by securing the who, when, what and where of a sequence of steps that are linked together in chronological order.

Each sequence corresponds to a segment, and each segment holds some metadata, an identifier called a hash, and a pointer to the preceding segment. The critical information maintained in Chainscript are the hashes, which are the proofs of the existence of data. Since each Blockchain transaction has a cost, we grouped the transactions. With Chainscript, a series of Blockchain transactions can be wrapped into the same logic flow, preventing too-intensive requesting to the Blockchain network, which can be costly. With this information, we need to check the proof of a specific data after they are merged. The ChainScript solution relies on a singular data structure, a Merkle Tree, which in a way “hashes the hash”, preserving in one single hash all the hashes, so that if any hash is corrupted, the entire tree is invalidated.

In our implementation, the ChainScript code is held in the PDF consent document, storing its hashed content, all its versions (corresponding to protocol revisions) and all the signing users for each version. ChainScript can be publicly verified without any proprietary tool. A positive side effect of tracking each step of a user’s interaction with the platform is that exhaustively storing the data enhances the barrier to fraud.

Technical details of the POC We sent two versions of the protocol ( and ) during the study, with which we sought users’ consent; each consent was attached to a specific version of the protocol. Users were given a digital signature and secured key, each of which consisted of a hash. Among the users of this experimental study, 14 gave their consent to the two versions of the protocol, 9 gave their consent to only one version of the protocol and 2 did not give consent at all and 2 did not respond to any consent form. The interaction of the user with the online interface, namely accepting or refusing to give consent, led to a transaction validated in Blockchain. Each version of the protocol had a unique identifier, called a hash. The hash is uniquely attached to the content of the protocol document. The correspondence between the consent document and the hash is one-to-one; namely, if one single letter is changed then the hash is broken.

Shows the identifier of the protocol document highlighted in the Chainscript master document. Displays the investigator identifiers, and reveals the consent status bound to the protocol revision version. Discussion In a context of growing mistrust of institutions and extreme sensitivity about rights to information and respecting privacy, building a consent process as irreproachable as could be achieved with the current state of knowledge and technologies is critical. Trust is the critical pivot to engage subjects in clinical trials. Blockchain is precisely a technology that was designed to enforce trust. Blockchain is an emerging, fast-evolving technology.

The intense atmosphere around the development and use of Blockchain is similar to technology development during the early stages of the Web: it took several years before formatting as html or css became Web standards. Blockchain technologies are gaining increasing attention, and Blockchain networks are proliferating, for example, Ethereum, Bitcoin, Hyperledger or private Blockchain networks. Which of these will be the Blockchain network standard is not clear or even if there will be unique standard. Public networks are interesting because of the idea of a community-driven approach and scalability, but private ones can offer a certain level of customization. We chose Bitcoin rather than Ethereum because even though Ethereum allows for implementing what we achieved through the Bitcoin networks, in our current implementation, we grouped transactions in order not to pay transaction fees at each user step and in the view of a real life clinical trial, where users will manage their own pair of keys. Therefore, we used a Bitcoin feature allowing for multiple inputs and signing transaction through multi-signatures, also named 'multisig'. There is no such a feature of multiple inputs in Ethereum, but there is a workaround; we would have used two contracts, the first receiving the transactions to queue them and depending on some threshold, an amount of ETH — Ethereum crypto-currency — or an amount of transactions; the first contract would hit a second contract that would register the proof of data, which might be a quite complex process.

Alongside this fast-developing technology, there are still some infrastructure obstructions that need addressing, namely, delays in transaction validation. On the Bitcoin network, the validation process (via the so-called mining) takes about 10 minutes (). In the present study’s context, we are not tied by real-time requirements measured in seconds, so it is not a major obstruction. Moreover, the ChainScript logic we implemented in our POC allows for grouped network request validation, which prevents the Blockchain network from computation overload and allows for scaling our method to a large patient cohort. To get an idea of the transaction costs, the fees of the Bitcoin transactions vary, at the time of the writing, between 0.0015 BTC to 0.0016 BTC, depending on the priority of the transactions, which corresponds to around 10€.

But, we stress the fact that in our implemetation, we used a special data-strcuture, called a Merkle tree, to group the data we want to store the proof-of-evidence. This tree, which critical element is the root, called the Merkle root located at the top of the tree, can hold hundred of thousand of hasches, so that validating the transactions by batches of 10.000 or even more hashes, allows to control the cost of the Bitcoin network requests to some milli-bitcoins. We refer the reader to to check the cost of the Bitcoin fees More generally, to tackle this challenge of scaling the network, with a massive amount of transactions, there are some implementations of Bitcoin-based protocol isolated from the Blockchain; the most renown is called SideChain (; ). As a remark and in a close spirit of deploying energy-savvy solutions that could reasonably absorb the costs of an important amount of transactions with a large clinical trial, some Blockchain implementations are based on Proof-of-Storage rather than Proof-of-Work, the latter being the cryptographic problem that nodes have to be solved in order to validate a transaction, which is extremely power-intensive. In a Proof-of-Storage network, nodes agreeing to store files allows for validating transactions.

Moreover, with regard to the authentication process, when the use of Blockchain technologies becomes more common, users may already possess a Blockchain public-private-key identity. Therefore, sending keys for access and identification later in the signing process will be obsolete. This situation will require maintenance of a double key attribution (as explained above in the “Authentication method' section) for users who do not have any Blockchain network identity and to be able to account for those who have already one. In the latter case, verification of the digital signature of these users will have to occur. As for the resilience of the network to malicious attacks, this is a vast subject and draws intensive interest by the whole Bitcoin developer community.

Basically, the first attack is an attacker controlling multiple nodes to try to solve the Proof-Of-Work problem, thus increasing the probability to gain more mining coins. Unfortunately, this so-called “Sybil attack” would fail because the difficulty of the problem increases with the number of nodes. A more substantial attack, at least among the Blockchain developers, is the well-known 51% attack, whereby an attacker gains more than a half of the network computing power, giving them the authority to control block addition. However, even in that case, the attacker will not be able to corrupt data or steal money because it requires the private key attached to the Bitcoin account, and this attack will never happen successfully on the Bitcoin network.

Even if it were the case, “double spend” will lead the non-accomplice nodes to distrust the Blockchain network. Another remark related to attacks is that since Blockchain is a shared database, anyone has a copy and no data will be missing or corrupted. We refer the reader to a thorough treatment in detailing the potential attacks with Blockchains. One step further, we can schematically consider two main issues regarding the consent process, the first related to the quality of the process itself and the second to the identity of the individual consenting. We chose to focus on the first point and tackle the issues raised by the FDA, (). Indeed, in this POC study, we considered problems in which existing patients were included in a study in the presence of their physician or staff so that ensuring that the consenting participant was precisely the one expected was not a critical matter.

With regard to the issues reported in the literature and by regulatory bodies, binding the hashed protocol and its versions to the consent, preventing from backdating and giving not only a time-stamping but a trusted one, gives more strength to the consent process, which is what we were looking for in this POC. Moreover, in the setting of a real online consent process, a patient who would not effectively consent (e.g., if there were some fraudulous operation registering him/her as a consenting participant) would actually participate to the study. However, the issue related to asserting the identity will be of importance in the context of a real clinical trial and should be done in a more secure manner than linking between a participant and his/her digital identity via an email address. In a production application, we could implement several solutions to secure the digital identity of participants, at least implementing a Know Your Customer (KYC)-like solution to bind digital identities and physical entities. KYC solutions are techniques used by fiscal administrations or banks to secure their online services. Another technique could use a Blockchain-based solution to provide material objects such as USB keys, holding the cryptographic signatures, which can be unlocked by an easy-to-remember code.

In regarding with the interplay between individual identity and effective consenting participants, we could design an online solution using Smart Contract, considering that the major forgery can come from a malicious party trying to consent on behalf of a user. Conclusion Keeping track of consent collection is consolidated through the use of Blockchain technology. In this proof-of-concept study, all consent-related data can leave an unfalsifiable and verifiable fingerprint on the Blockchain. This is important both from the stakeholder’s viewpoint, letting them prove the existence and the consistency of the data, and on the patient’s viewpoint, giving them more visibility, transparency, and hence control over their consent.

Moreover, although not the focus of this paper, Blockchain technology, in that it does not rely trust on third party but inversely empowers peer-to-peer users by granting them control over consent agreement and revocation, can help gather conditions of improved privacy-respected freely given consent. Besides, given its decentralized protocol, it can help introduce communities to contemporary clinical research, opening, for clinical research, the path to implementing community management techniques to enrol patients by using a more targeted approach.

From a global perspective, the application of Blockchain technologies in the context of clinical research is broad and promising. Indeed, tracking the complex data flow with numerous diverse stakeholders and documenting it in real-time through a time-stamping workflow is a key step toward proving data consistency and inviolability and will therefore improve clinical trial methodology. Gupta UC: Informed consent in clinical research: Revisiting few concepts and areas.

Perspect Clin Res. 2013; 4(1): 26–32. • 2. Lloyd Wendy, BA, LPN, CIP, CCRP, Regulatory Affairs and Compliance Specialist: Part 2 of 3 Part Series: Informed Consent, the process. Office of Scientific Investigations, Metrics.

US Food and Drug Administration. Barney JR, Antisdel M: Common problems in informed consent. Human Research Protection Program (HRPP). Gupta A: Fraud and misconduct in clinical research: A concern. Perspect Clin Res. 2013; 4(2): 144–7. • 6. Hazra A: Use, abuse and misuse of notes to file.

Perspect Clin Res. 2011; 2(1): 38–40. • 7. Morgan-Linnell SK, Stewart DJ, Kurzrock R: U.S. Food and Drug Administration inspections of clinical investigators: overview of results from 1977 to 2009. Clin Cancer Res. 2014; 20(13): 3364–3370. • 9. Seife C: Research misconduct identified by the US Food and Drug Administration: out of sight, out of mind, out of the peer-reviewed literature.

JAMA Intern Med. 2015; 175(4): 567–77. • 10. Dillner L: BSE linked to new variant of CJD in humans. 1996; 312(7034): 795–800. • 12.

WMA Declaration of Helsinki - Ethical Principles for Medical Research Involving Human Subjects. Myles PS, Williamson E, Oakley J, et al.: Ethical and scientific considerations for patient enrollment into concurrent clinical trials. 2014; 15: 470. • 14. Informed Consent Information Sheet Guidance for IRBs, Clinical Investigators, and Sponsors. Resnik DB: Re-consenting human subjects: ethical, legal and practical issues. J Med Ethics. 2009; 35(11): 656–657. • 16.

McDonald AM, Knight RC, Campbell MK, et al.: What influences recruitment to randomised controlled trials? A review of trials funded by two UK funding agencies. 2006; 7: 9. • 17. Swanson GM, Ward AJ: Recruiting minorities into clinical trials: toward a participant-friendly system.

J Natl Cancer Inst. 1995; 87(23): 1747–59. • 18. Lovato LC, Hill K, Hertert S, et al.: Recruitment for controlled clinical trials: literature summary and annotated bibliography. Control Clin Trials.

1997; 18(4): 328–52. • 19. Hazen RA, Eder M, Drotar D, et al.: A feasibility trial of a video intervention to improve informed consent for parents of children with leukemia.

Pediatr Blood Cancer. 2010; 55(1): 113–8. • 20. Internet of Things report. New England Journal of Medicine: Informed Consent — NEJM [online]. Yuste R, Goering S, Arcas BAY, et al.: Four ethical priorities for neurotechnologies and AI. 2017; 551(7679): 159–163. • 24.

Brehaut JC, Carroll K, Elwyn G, et al.: Informed consent documents do not encourage good-quality decision making. J Clin Epidemiol. 2012; 65(7): 708–724. • 25. Pandiya A: Readability and comprehensibility of informed consent forms for clinical trials. Perspect Clin Res.

2010; 1(3): 98–100. • 26. Paris A, Brandt C, Cornu C, et al.: Informed consent document improvement does not increase patients' comprehension in biomedical research. Br J Clin Pharmacol. 2010; 69(3): 231–237. • 27. Mills EJ, Seely D, Rachlis B, et al.: Barriers to participation in clinical trials of cancer: a meta-analysis and systematic review of patient-reported factors. Lancet Oncol.

2006; 7(2): 141–148. • 28. Caldwell PH, Hamilton S, Tan A, et al.: Strategies for increasing recruitment to randomised controlled trials: systematic review. 2010; 7(11): e1000368. • 29. Eder ML, Yamokoski AD, Wittmann PW, et al.: Improving informed consent: suggestions from parents of children with leukemia.

2007; 119(4): e849–59. • 30. Smyth RM, Jacoby A, Elbourne D: Deciding to join a perinatal randomised controlled trial: experiences and views of pregnant women enroled in the Magpie Trial. 2012; 28(4): E478–85. • 31. 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. . This article describes a proof of concept system which leverages the Bitcoin blockchain and Chainscript proof of process in order to enforce patients' informed consent during clinical trials.

The method relies on the timestamping characteristic of blockchain transactions to ensure that consent was given by the patient in light of modifications to the trial protocol. While it is possible to follow the description of the method, there are many typographic and grammatical errors.

The manuscript needs to be improved and these numerous errors corrected. There are a number of issues that need to be addressed. • Bitcoin here seems inappropriate for the task at hand.

The authors discuss Ethereum but choose Bitcoin as it is perceived to be more stable and immutable. Both chains have experienced hard forks, and both are susceptible to 51% attacks. Ethereum's flexible smart contracts would seem entirely appropriate to use for data storage here, given that any tampering of the chain would be much more likely to seek economic gain than attempt to modify the trial record. In any case, even on Ethereum the cost of such an attack is essentially prohibitive.

• If using a public chain of any sort, the cost in terms of transactions fees and confirmation times should be discussed. For large scale trials, these costs are likely to be substantial. • Authors state that subjects are assigned a key - assigned by who?

Surely this introduces a security risk as there exists no mechanism to ensure that these keys are deleted by whoever creates and assigns them. There are various mechanism that allow key pairs to be created by end users (e.g.

In a web browser using client-side Javascript) • How are public keys associated with subject identities (or their email addresses)? Linking these is non-trivial (assuming the keys are not generated by a central entity). Services exists to link e.g.

OAuth 2 tokens with blockchain addresses - the manuscript should at the very least cover some of the identity solutions that may be appropriate here. • Is the rationale for developing the new method (or application) clearly explained? Partly • Is the description of the method technically sound? Partly • Are sufficient details provided to allow replication of the method development and its use by others? No • If any results are presented, are all the source data underlying the results available to ensure full reproducibility? Partly • Are the conclusions about the method and its performance adequately supported by the findings presented in the article? Partly Competing Interests: No competing interests were disclosed.

Referee Expertise: Blockchain, Bitcoin, Ethereum, Smart Contract, Clinical Trials, Pharmacology, Bioinformatics. 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. 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 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.

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. 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. 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. 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 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. 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. 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.

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. • Is the rationale for developing the new method (or application) clearly explained? Partly • Is the description of the method technically sound? Partly • Are sufficient details provided to allow replication of the method development and its use by others?

No • If any results are presented, are all the source data underlying the results available to ensure full reproducibility? Partly • Are the conclusions about the method and its performance adequately supported by the findings presented in the article? Partly Competing Interests: No competing interests were disclosed. Referee Expertise: Cardiology, Outcomes Research, Blockchain Technology, Data Science.

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. Continue reading 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.

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] 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.

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.

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.

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] 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.

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. 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. Continue reading 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.

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.

We updated the manuscript in order to make more clear what we mean by publically verifiable. [1] 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. 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.

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. This article addresses a critical element in the research process that involves humans. Their goal of adapting a technology for use in clinical research for the purpose of consent is laudable and to be encouraged. Innovation is desperately needed. The authors may wish to consider the following as they iteratively seek to improve their paper 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 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. Torrent Fringe Season 2 Episode 1.

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.

• Is the rationale for developing the new method (or application) clearly explained? Partly • Is the description of the method technically sound? Partly • Are sufficient details provided to allow replication of the method development and its use by others? Partly • If any results are presented, are all the source data underlying the results available to ensure full reproducibility? Yes • Are the conclusions about the method and its performance adequately supported by the findings presented in the article?

Partly Competing Interests: Professor Ravaud and I are both involved in Cochrane. 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. Continue reading 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. 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. 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. Continue reading 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.

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. After the previous two rounds of revision, there are still major outstanding issues.

The revisions only minimally react to my previous reviews and do not include the substantial changes that would be necessary for me to approve this study. For context, see the.

Here are the main factors weighing on my decision: • The digital signature scheme that was implemented is worthless in terms of proving that a participant consented. Hence, I entirely ignore and discount this aspect of the proposal. • The 'proof of concept' justification provided by the authors for the methodological shortcomings and incomplete nature of their study is frustrating. The authors make statements such as (manuscript typos bolded): >The current implementation is an application of the frst principle.

Ideally, we would have to build a patient authentication system which does not relies on any trial stackholder >It would be possible to build a Smart Contract that will be executed with the only condition that patients will only be included when the enrolment is complete. The assertion that solutions to these problems will come later is insufficient. The authors have to implement the solutions or cease promoting their benefits.

In my opinion, these are unsolved problems. Implementing such solutions is difficult: suggesting that a solution exists but not offering an implementation is therefore worthless. • The study continues to overstate its reliance on blockchain technology. As our previous dialogue has confirmed, the study only uses the a blockchain for timestamping. Timestamping is an important addition, but does not justify titling the study 'blockchain protocols in clinical trials' nor the abundant discussion of blockchains when their role is relatively minor in the actual proposal. To help explain my decision, I'll elaborate on the theoretically sound aspects of the authors' proposal. The following workflow is theoretically sound, albeit poorly communicated in the manuscript: • A webapp is created to administer an electronic consenting process.

The webapp can be designed to enforce a rigid workflow that ensures the right steps are performed in the right order. • The user interactions and inputs from the electronic consent process can be recorded via a Chainscript JSON file. Therefore, one can store the digital equivalent of paper forms from a traditional physical consent process.

• The Chainscript JSON file can be timestamped using the Bitcoin blockchain. This prevents predating the existence of a consent record. Now while a clear, compelling, and clean implementation of the previous steps would be of interest, the study fails to achieve this. Specifically, the webapp is not publicly hosted, so users can experiment with and observe the proposed electronic consent implementation. Second, the authors do not provide any Chainscript JSON files for their study. In their previous response to, they link to a unrelated to their study. Even more troubling is that their Chainscript example from the manuscript appears to be manually edited from an example Chainscript document rather than computer-generated output from their consent application.

As I mentioned in previous review, the JSON example contains flagrant formatting errors suggesting it was created by hand. Furthermore, the Chainscript includes a mapID of 56c11d0ea55773bc6e681fde. The same mapID is also used in the, suggesting copying and pasting from the docs. The question remains did the study actually produce any real Chainscript JSON files or timestamp even a single Chainscript file.

It's telling that the authors still haven't revealed a Chainscript file whose past existence has been timestamped. Hence, there is no evidence that the authors actually implemented their proposed 'proof of concept'. Given the severity of the outstanding issues despite the number of previous rounds of review, I do not intend to review this study again. Hence, my decision to not approve this study should be considered final.

Competing Interests: No competing interests were disclosed. Referee Expertise: data science, bitcoin, blockchains, timestamping, bioinformatics, computer science. Dear reviewer, We are surprised by the serious charges raised against the proof-of-concept work we present. There appears to be a misunderstanding. Actually, there seems to be doubts questioning whether “the. Continue reading Dear reviewer, We are surprised by the serious charges raised against the proof-of-concept work we present.

There appears to be a misunderstanding. Playlist The Very Best Of Tyrese Rarest. Actually, there seems to be doubts questioning whether “the study actually' did 'produce any real Chainscript JSON files or timestamp even a single Chainscript file”.

This is not true: we produced a JSON file which is provided in the text. 1) If you look carefully at the material we furnished, the figures 4,5,6 corresponds to the data structure we got from the production experimentation and these correspond to the validated transactions. Moreover, we let as an example a JSON data structure where we listed different entries, as any documentation oriented information, and we picked up an example file and structured it accordingly to the experiment purpose. And so the HASH ID ` 56c11d0.` is not 'flagrant errors' and is set as an example inside this merkel tree data-structure. So, if one wants to check the integrity of the transactions hashIDs, one should consider those appearing in the figures 4, 5, 6. We have sent to the only editor the production Chainscript file, according to the editor instructions. Of course, the names and emails are blanked out, to respect data privacy as requested by F1000Research. 2) We insist with the fact that we identified linking digital identities and physical entities as an important issue and as explained in our series of responses to the reviews: - We recall that major and serious issues identified by the FDA corresponds, by a proportion of about 10% of trials, to failure to obtain written informed consent, consent documents not signed or 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.

This is the context we are embedding in our work. - We want to provide solutions coherent with regards to the current state of clinical trial usages and not an idealistic one. So that, letting the investigators create keys seem not, to our point of view, the subject of major concern. Indeed, the heavy part numerous bias that entail research quality and clinical trials reproducibility are related to a posteriori reconstruction or untraceable missing information.

Despite, most of the questions we are asked are focused on Blockchain technology, one should have in mind that this is not a technology paper but medical research one. 3) Regarding the workflow that we mentioned and developed in three points, we would like to emphasise that is exactly what we have done: - input and users transactions where recorded. - the electronic consent process is “blockchained': the consent status is set into the Chainscript. Moreover, any version of the protocol document is hashed, versioned and bound to the consent status.

- the Chainscript file is timestamped on the Bitcoin network. Chainscript helps group the transactions and validate them as if it were one. The hashes of this data structure form a coherent and consistent group of hashes, any of them would be corrupted results in invalidating the whole datastructure. This “SideChain” approach enables us to reduce costs of transactions, which is especially useful when dealing with large clinical trials.

I stay at disposal for any further remark. Best regards, Mehdi.

Dear reviewer, We are surprised by the serious charges raised against the proof-of-concept work we present. There appears to be a misunderstanding.

Actually, there seems to be doubts questioning whether “the study actually' did 'produce any real Chainscript JSON files or timestamp even a single Chainscript file”. This is not true: we produced a JSON file which is provided in the text. 1) If you look carefully at the material we furnished, the figures 4,5,6 corresponds to the data structure we got from the production experimentation and these correspond to the validated transactions. Moreover, we let as an example a JSON data structure where we listed different entries, as any documentation oriented information, and we picked up an example file and structured it accordingly to the experiment purpose. And so the HASH ID ` 56c11d0.` is not 'flagrant errors' and is set as an example inside this merkel tree data-structure. So, if one wants to check the integrity of the transactions hashIDs, one should consider those appearing in the figures 4, 5, 6.

We have sent to the only editor the production Chainscript file, according to the editor instructions. Of course, the names and emails are blanked out, to respect data privacy as requested by F1000Research. 2) We insist with the fact that we identified linking digital identities and physical entities as an important issue and as explained in our series of responses to the reviews: - We recall that major and serious issues identified by the FDA corresponds, by a proportion of about 10% of trials, to failure to obtain written informed consent, consent documents not signed or 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. This is the context we are embedding in our work. - We want to provide solutions coherent with regards to the current state of clinical trial usages and not an idealistic one. So that, letting the investigators create keys seem not, to our point of view, the subject of major concern. Indeed, the heavy part numerous bias that entail research quality and clinical trials reproducibility are related to a posteriori reconstruction or untraceable missing information.

We already furnish examples such as statistical analysis plan, definition of outcomes, inclusion and exclusion criteria, secondary effects traceability - Besides, this issue has to be raised in “production”. We are here proposing a POC and we already suggested in the preceding round of revision that we could provide for the patients a proper generation key online interface, and this would be doubled by a key registration with a material object: USB cards are now provided by some vendors. Despite, most of the questions we are asked are focused on Blockchain technology, one should have in mind that this is not a technology paper but medical research one. 3) Regarding the workflow that we mentioned and developed in three points, we would like to emphasise that is exactly what we have done: - input and users transactions where recorded. - the electronic consent process is “blockchained': the consent status is set into the Chainscript. Moreover, any version of the protocol document is hashed, versioned and bound to the consent status. - the Chainscript file is timestamped on the Bitcoin network.

Chainscript helps group the transactions and validate them as if it were one. The hashes of this data structure form a coherent and consistent group of hashes, any of them would be corrupted results in invalidating the whole datastructure. This “SideChain” approach enables us to reduce costs of transactions, which is especially useful when dealing with large clinical trials. I stay at disposal for any further remark. Best regards, Mehdi Competing Interests: we declare no competing interests Close.

Dear reviewer, We are surprised by the serious charges raised against the proof-of-concept work we present. There appears to be a misunderstanding. Actually, there seems to be doubts questioning whether “the. Continue reading Dear reviewer, We are surprised by the serious charges raised against the proof-of-concept work we present. There appears to be a misunderstanding.

1) If you look carefully at the material we furnished, the figures 4,5,6 corresponds to the data structure we got from the production experimentation and these correspond to the validated transactions. Moreover, we let as an example a JSON data structure where we listed different entries, as any documentation oriented information, and we picked up an example file and structured it accordingly to the experiment purpose.

And so the HASH ID ` 56c11d0.` is not 'flagrant errors' and is set as an example inside this merkel tree data-structure. So, if one wants to check the integrity of the transactions hashIDs, one should consider those appearing in the figures 4, 5, 6. We have sent to the only editor the production Chainscript file, according to the editor instructions. Of course, the names and emails are blanked out, to respect data privacy as requested by F1000Research. 2) We insist with the fact that we identified linking digital identities and physical entities as an important issue and as explained in our series of responses to the reviews: - We recall that major and serious issues identified by the FDA corresponds, by a proportion of about 10% of trials, to failure to obtain written informed consent, consent documents not signed or 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. This is the context we are embedding in our work.

- We want to provide solutions coherent with regards to the current state of clinical trial usages and not an idealistic one. So that, letting the investigators create keys seem not, to our point of view, the subject of major concern. Indeed, the heavy part numerous bias that entail research quality and clinical trials reproducibility are related to a posteriori reconstruction or untraceable missing information. We already furnish examples such as statistical analysis plan, definition of outcomes, inclusion and exclusion criteria, secondary effects traceability - Besides, this issue has to be raised in “production”. We are here proposing a POC and we already suggested in the preceding round of revision that we could provide for the patients a proper generation key online interface, and this would be doubled by a key registration with a material object: USB cards are now provided by some vendors. Despite, most of the questions we are asked are focused on Blockchain technology, one should have in mind that this is not a technology paper but medical research one. 3) Regarding the workflow that we mentioned and developed in three points, we would like to emphasise that is exactly what we have done: - input and users transactions where recorded.

- the electronic consent process is “blockchained': the consent status is set into the Chainscript. Moreover, any version of the protocol document is hashed, versioned and bound to the consent status.

I stay at disposal for any further remark. Best regards, Mehdi. Dear reviewer, We are surprised by the serious charges raised against the proof-of-concept work we present. There appears to be a misunderstanding. Actually, there seems to be doubts questioning whether “the study actually' did 'produce any real Chainscript JSON files or timestamp even a single Chainscript file”. This is not true: we produced a JSON file which is provided in the text. 1) If you look carefully at the material we furnished, the figures 4,5,6 corresponds to the data structure we got from the production experimentation and these correspond to the validated transactions.

Moreover, we let as an example a JSON data structure where we listed different entries, as any documentation oriented information, and we picked up an example file and structured it accordingly to the experiment purpose. And so the HASH ID ` 56c11d0.` is not 'flagrant errors' and is set as an example inside this merkel tree data-structure. So, if one wants to check the integrity of the transactions hashIDs, one should consider those appearing in the figures 4, 5, 6. We have sent to the only editor the production Chainscript file, according to the editor instructions. Of course, the names and emails are blanked out, to respect data privacy as requested by F1000Research.

2) We insist with the fact that we identified linking digital identities and physical entities as an important issue and as explained in our series of responses to the reviews: - We recall that major and serious issues identified by the FDA corresponds, by a proportion of about 10% of trials, to failure to obtain written informed consent, consent documents not signed or 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. This is the context we are embedding in our work.

Moreover, any version of the protocol document is hashed, versioned and bound to the consent status. - the Chainscript file is timestamped on the Bitcoin network. Chainscript helps group the transactions and validate them as if it were one. The hashes of this data structure form a coherent and consistent group of hashes, any of them would be corrupted results in invalidating the whole datastructure.

This “SideChain” approach enables us to reduce costs of transactions, which is especially useful when dealing with large clinical trials. I stay at disposal for any further remark. Best regards, Mehdi Competing Interests: we declare no competing interests Close. In, the authors updated the manuscript and responded to. I'd like to thank the authors for these additions, which provide a clearer picture of the trust model and proof of process. To assist in my review, I created a that includes a.

Trust model In their response, the authors clarify who generates the private key for a given participant: >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. I believe 'the agent' refers the agent folder of the source code. In their proof of concept, the clinical trial investigators host the agent.

Presumably, the agent could also be hosted by a trusted third party, such as Stratumn or a governing body like an Institutional Review Board. It's crucial to note that the proof of process for participant consent requires complete trust in the agent. Assuming the agent is hosted by the investigators, then we must trust the investigators to have faithfully run an uncompromised agent. Hence, the proposed implementation provides an equivalent trust model to the current consent process. In both cases, one must trust the investigators to truthfully collect consent.

Presently, we trust that investigators did not forge a participant's handwritten signature. In the proposed implementation, we trust that the investigators ran an agent that properly generated (and then deleted) a private key for each participant's email. For the time being, the later is perhaps even less verifiable than a handwritten signature. Regardless, the proposed digital identity solution requires a trusted party. Proof of process The authors should more clearly document the proof of process underlying their approach. The Chainscript examples (the code block and Figure 4–6) are a good start.

However, Figure 4–6 are poor resolution and difficult to read. More discussion of the Chainscript format along with instructions to verify a process and timestamp are needed. For example, there is no example Chainscript JSON file provided with step-by-step instructions on how to verify or evaluate it.

The Chainscript code block is littered with broken JSON syntax, so it's certainly an insufficient example. With more details, additional questions may arise.

For example, is the 12-byte mapID (with a best-case attack complexity of 2 96) secure against preimage attacks? The manuscript doesn't appear to specify what hash algorithm is used. Smart contracts The manuscript is misleading regarding 'smart contracts' and implies that the study proposes a smart contract enrollment protocol. Specifically: • Figure 1 includes a smart contract step in the workflow. • The abstract states 'a blockchain core functionality, named Smart Contract, can help prevent clinical trial events not to happen in the right chronological order'.

• The introduction states 'This makes it possible to build a Smart Contract that will be executed with the only condition that patients will only be included when the enrolment is complete'. As the authors admit in their response to my review of version 1, they 'did not implement' anything related to smart contracts. Implementing a smart contract to manage enrollment is not trivial.

Unless the authors actually implement such a contract, they should remove claims about its utility and applicability. Discussing smart contracts in the discussion would be justified, but it's misleading to suggest that the current proposal involves smart contracts. Overstated blockchain usage In their response to my review of version 1, the authors clarify that the primary achievement of the study is to create a web-based consent workflow that makes it most natural and easy to perform the proper consent process. However, the study only minimally leverages the guarantees provided by cryptography and secure blockchains. For example, the study does not achieve trustless consent, whereby participant consent can be provided and verified in a decentralized manner without having to trust any other parties. However, in the abstract, the authors imply the trustless & decentralized aspects of Bitcoin apply to their consent process: >This is a distributed technology that brings a built-in layer of transparency and traceability. Additionally, it removes the need for third parties, and gives participative control to the peer-to-peer users.

In reality, the only area where a blockchain was applied is for the Chainscript timestamping. I agree this timestamping is valuable for its ability to prevent retroactive consent forgery.

However, it's insufficient to verify an actual participant's identify or consent. Foremost, the use of blockchain timestamping is not sufficient to justify the grandiose claims of blockchain relevance to clinical trial consent. In other words, the proposed consent protocol would suffer little were all blockchains to immediately disappear. The blockchain is not essential to implement more automated, web-based, and reliable consent processes.

Yet the study titles itself 'blockchain protocols in clinical trials' and implies that blockchains are what allows 'transparency and traceability of consent'. The manuscript does not adequately differentiate between speculation and the actual ways in which the study leverages blockchain technology. For me to consider approving this study, the authors would need to drastically reduce their claims regarding the benefits of blockchain usage for clinical trial consent applications. In addition, greater clarity and focus on the specifics of their proof of concept implementation would be necessary. Competing Interests: No competing interests were disclosed. Referee Expertise: data science, bitcoin, blockchains, timestamping, bioinformatics, computer science.

Trust model In their response, the authors clarify who generates the private key for a given participant: >A participant cannot simply generate any Bitcoin address and use. Continue reading Trust model In their response, the authors clarify who generates the private key for a given participant: >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. I believe 'the agent' refers the agent folder of the source code. In their proof of concept, the clinical trial investigators host the agent. Presumably, the agent could also be hosted by a trusted third party, such as Stratumn or a governing body like an Institutional Review Board. It's crucial to note that the proof of process for participant consent requires complete trust in the agent. Assuming the agent is hosted by the investigators, then we must trust the investigators to have faithfully run an uncompromised agent.

Hence, the proposed implementation provides an equivalent trust model to the current consent process. In both cases, one must trust the investigators to truthfully collect consent. Presently, we trust that investigators did not forge a participant's handwritten signature. In the proposed implementation, we trust that the investigators ran an agent that properly generated (and then deleted) a private key for each participant's email.

For the time being, the later is perhaps even less verifiable than a handwritten signature. Regardless, the proposed digital identity solution requires a trusted party. Dear reviewer, Thank you for these remarks.

Indeed, you are right that, in the current setting, the “agent” hosts the entity that generates the set of keys.

Christopher Mcdougall Urodzeni Biegacze Pdf Creator

Xscan 2.3 Download

Comments are closed.