|
 
 |
| ORIGINAL ARTICLE |
|
| Year : 2020 | Volume
: 6
| Issue : 1 | Page : 44-52 |
|
Simulating patient matching to clinical trials using a property rights blockchain
Jay Bergeron1, Anh Nguyen2, Casey Alt2, Nicole Brewster1, Le Quy Quoc Cuong2, Thomas Krohn3, Vien Luong2, Michael Nguyen2, Amalio Telenti2, Jennifer Wulff1, Sean Moss-Pultz2
1 Pfizer Digital, Pfizer Inc., Cambridge, Massachusetts, USA
2 Bitmark Inc., Teipei, Taiwan
3 Chief Development Office, Antidote Technologies Ltd., Indianapolis, Indiana, USA
| Date of Submission | 03-Dec-2019 |
| Date of Decision | 27-Apr-2020 |
| Date of Acceptance | 07-May-2020 |
| Date of Web Publication | 26-Aug-2020 |
Correspondence Address:
Jay Bergeron
Pfizer, Inc., 600 Main St, Cambridge, Massachusetts 02142
USA
 Source of Support: None, Conflict of Interest: None  | Check |
DOI: 10.4103/digm.digm_30_19
Objective: Biomedical data processing generally requires the secure stepwise transfer of sensitive personal information across multiple parties. Mediating such operations using distributed secure digital ledgers, i.e., blockchains, is investigated in this article. Materials and Methods: The bitmark property rights blockchain was used to simulate the process of assessing individuals for enrollment to specific clinical trials. In the scenario presented, a sponsor publishes a recruitment call for a clinical trial and patients signal their willingness to participate in the trial through blockchain transactions. The blockchain creates and maintains digital references of the medical data assets of prospective study participants as well as digital property certificates for assigning access rights to corresponding medical data assets. Trial matching services review the patient blockchain records and recommend study participants that are likely to meet the enrollment criteria of recruiting clinical trials. Digital certificates assign transient access rights to the data assets of the prospective study participants. These certificates are transferred to pertinent matching services and sponsors, allowing these organizations to examine the candidacy of each prospective study participant. Results: The trial matching simulation demonstrates that property rights blockchains can implement complicated multiparty interactions, such as those associated with medical data exchange, without supplemental peer-to-peer communications. Conclusions: Blockchain-based data marketplaces of the type described, when coupled with data-controlled virtual infrastructure environments (i.e., Medical Data Trusts), provide a viable model for managing the transfer, provenance, and processing of individual health information.
Keywords: Bitmark, blockchain, clinical trial, patient matching, property rights
How to cite this article:
Bergeron J, Nguyen A, Alt C, Brewster N, Quoc Cuong LQ, Krohn T, Luong V, Nguyen M, Telenti A, Wulff J, Moss-Pultz S. Simulating patient matching to clinical trials using a property rights blockchain. Digit Med 2020;6:44-52 |
How to cite this URL:
Bergeron J, Nguyen A, Alt C, Brewster N, Quoc Cuong LQ, Krohn T, Luong V, Nguyen M, Telenti A, Wulff J, Moss-Pultz S. Simulating patient matching to clinical trials using a property rights blockchain. Digit Med [serial online] 2020 [cited 2023 Mar 26];6:44-52. Available from: http://www.digitmedicine.com/text.asp?2020/6/1/44/293504 |
| Introduction | |  |
Maintaining privacy and respecting the intended use of personal information when collecting, sharing and reusing comprehensive personal health records for clinical research is a substantial challenge.[1] Although originally designed for cryptocurrency transactions, blockchain implementations possess inherent information protection features and have been proposed as platforms for medical data exchange.[2] A blockchain is an immutable electronic ledger that is distributed (copied) across many hosts. Each new transaction is added to the independent ledger of each host participating in the blockchain network.[3] Hashing functions are generally used for rapid verification of ledger contents, and private elements of transactions are encrypted.[3] At interim-timed events, the hosts verify their new transactions for accuracy, i.e., reach consensus, and permanently add the new transactions to their ledgers.[3] In this manner, each host maintains an exact copy of the ledger. Blockchains having several independent hosts and relatively frequent consensus events are exceedingly resistant to malicious alteration.[4] Blockchains are generally positioned to disrupt processes reliant on centralized mediation or trust-based operations.[3] Blockchains interoperating with end-user applications for managing personal medical data, i.e., medical data vaults, have been envisioned as effective mechanisms for individuals to share their medical data with researchers and receive tangible rewards, such as cryptocurrency payments, for such data sharing.[2],[3]
Cryptocurrencies, such as Bitcoin, support independent two-party unidirectional payment transactions of anonymous participants.[4] The Bitcoin blockchain achieves consensus by competitive computational problem solving among the hosts with the winning host awarded cryptocurrency.[4] The combination of privacy for transacting parties, transaction visibility, and monetary incentives driving host participation enables decentralized and low-cost currency transactions.[3]
However, medical data exchange processes (e.g., 6) are complicated by the following attributes; (1) Multiparty with potentially more than two transacting participants, (2) multistep involving a set of ordered dependent transactions, (3) bidirectional with each party acting as transaction sources and recipients depending on the step of the exchange process, and (4) complicated data formats and sizable data volumes that likely require persistence external to the blockchain. Attempts to design medical data exchanges using cryptocurrency blockchains proved unsatisfying as peer to peer networks, supplemental to the blockchain itself, appeared necessary for organizing the requisite multiparty communications. However, property rights blockchains, which create digital representations for physical or digital assets and associate these assets with digital certificates that confer asset ownership and use rights,[5] led to compelling designs that were tested through implementation.
To speed clinical trial recruitment,[6] patient matching services [7] have emerged to supply trial sponsors with prospective clinical study candidates likely to meet the trial's enrollment criteria. Matching services maintain a list of potential study candidates, with their corresponding pertinent medical information and eligibility criteria, that have consented to be considered for trials and apply proprietary methods to recommend candidates for study sponsors.[7] Study matching, therefore, involves any number of parties serving in one of three roles (patient, match service, or sponsor) interacting via a series of procedural transactions.[6] The blockchain implementation described subsequently simulates trial matching services.
| Materials and Methods | | |
The bitmark blockchain is an open-source (Internet Software Consortium license) platform using Argon 2 Proof of Work consensus [8] having its source code, corresponding Software Developers Kit, application programming interface and design publicly available at https://sdk-docs.bitmark.com. A client wishing to transact through the bitmark blockchain creates an account that is identified by key pairs generated by the client software. Each account can register one or more assets to represent the digital or physical property. Each asset encapsulates descriptive metadata and a file payload. Each instance of metadata is a key: value pair that is assigned at the discretion of the account holder and can be publicly read by all blockchain participants. The file payload is stored external to the blockchain and is identified from within the ledger transaction by a uniform resource locator and a hash of the file to ensure that the file has not been modified once the transaction is written. The file payload is private by default but can be set to public read.
Once the asset is registered to the blockchain the account that created the asset can assign, to other accounts, access and use rights to the asset by generating digital property titles, called bitmark certificates or simply bitmarks, and sending these certificates to pertinent accounts using one-way (no receiver signature required) or two-way (receiver signature required) transfers. Two-way signature transfers are generally enacted as these represent a two-party voluntary binding agreement between the sender and receiver with respect to a transaction. Bitmark certificates contain references to digital payloads of an asset, if applicable, or can be used in the same manner as title documents for physical property. Certain restrictions can be programmed into the bitmark certificate, including expiration policies. A bitmark certificate can be used in multiple blockchain transactions to represent the sequential transfer of ownership, or use privileges, from one account to another. As such, bitmark certificates can persist information across transactions within the blockchain. In this manner assets, or rights to assets, can be transferred across various blockchain accounts with a record of the transaction history maintained by the certificate itself. Bitmark certificates can store information pertinent to the blockchain transactions to which they are associated. Expired/obsolete bitmark certificates are permanently disabled through transfer to a special-purpose blockchain account (i.e., trashBinAccount), although the transaction history of all disabled bitmark certificates are maintained on the blockchain. The bitmark property rights model is depicted in [Figure 1]. | Figure 1: The bitmark property rights model. Alice, an account on the bitmark blockchain, creates an asset to represent a property, e.g., a copyrighted document, which is a combination of a set of metadata (record) and a reference to the document itself (file). Alice issues three bitmark certificates on the asset. Alice transfers bitmark certificate #1 to Bob providing Bob with, for example, read access to the copyrighted document
Click here to view |
The trial matching simulation creates blockchain accounts for sponsors, match services, and candidates. A consent bitmark certificate (consent bitmark) is used to request and confirm agreement by study candidates to trial matching actions. A health data bitmark certificate (health bitmark) is used to assign rights of access to health information provided by study candidates. The metadata describing the sponsors and matching services are predefined in a configuration file, including their identities and account seed codes. The number of sponsors, match services, and candidates is determined by configuration parameters. Sponsor names are added to the sponsor's metadata. A unique identifier is added to the account metadata of each candidate. Sponsor accounts create trial assets, determined by the trials_per_sponsor configuration, and trial content is programmatically simulated. Standard bitmark certificates are generated for each new study, associated with the study's assetID, and transferred to the match services to enable the match services to create consent bitmarks against the studies. The various configuration parameters and default values are summarized in [Table 1]. | Table 1: The following parameters are modifiable when executing the simulation
Click here to view |
Matching services select trials based on select_asset_prob. Consent bitmarks are issued by the matching services and transferred to select candidates having potential suitability for the trial, based on match_prob, using a two-way signature. A candidate agrees to the trial match request based on participant_accept_trial_invite_prob and if willing, signs the consent bitmark. A consenting candidate decides to issue, and then transfer by two-way signature, a health bitmark certificate to the match service based on the participant_submit_data_prob. The matching services receiving the health bitmark sign and now possessing both consent and corresponding health data, evaluate the suitability of the candidate for the trial as determined by match_data_approval_prob.
Example code for health data asset creation, issuance of a health data bitmark and transfer via two-way signatures are provided in supplemental [Table 2], [Table 3], [Table 4], respectively. | Table 4: Example code to transfer health data bitmarks using two-way signatures
Click here to view |
If the candidate is deemed suitable for the trial, the match service transfers both the consent and health data bitmarks to the pertinent sponsor for secondary evaluation using two-way signatures. If the candidate fails trial evaluation, the match service will disable the consent bitmark and transfer the health data bitmark to the candidate using a one-way signature.
Example code for one-way signature transfer of the health data bitmark is provided in supplemental [Table 5]. | Table 5: Example code to transfer health data bitmarks using one-way signatures
Click here to view |
The outcome of the sponsor's secondary evaluation of suitable candidates is based on the sponsor_data_approval_prob parameter. If the candidate is deemed trial eligible, the sponsor sends an enrollment invitation to the candidate via the consent bitmark using the two-way signature. The candidate chooses to accept the invitation based on the participant_accept_match_prob parameter. The accepting candidate signs the consent bitmark. A declining candidate will receive the health bitmark in a one-way signature transfer initiated by the sponsor. The trial matching workflow is presented graphically in [Figure 2]. | Figure 2: A swim lane schematic representing the simulated trial matching process
Click here to view |
The source code for the presented simulation was written in the GO programming language (https://golang.org) and is available publicly at https://github.com/bitmark-inc/ct-match. Simulations were run on the “testnet” blockchain, a fully operational and public domain implementation of the bitmark blockchain for pre-production use. No transaction fees are charged for the use of testnet. The simulation can be run on a standard personal computer. An Apple Macbook having a 2.2GHz processor and 8GB 1500MHz DDR3 ran default simulations in <1 min.
| Results | | |
The results of a simulation run of four sponsors, six-match services, and one hundred candidates are provided to demonstrate the blockchain-mediated matching process. Seven key example outcomes are presented in [Table 6] and subsequently discussed with examples 2, 4, 5, 6, and 7, also noted in [Table 6]. | Table 6: Simulation examples with each row representing a bitmark certificate and columns representing key simulation events
Click here to view |
Example 1: Match failure upon initial investigation
Match service (m01) considers for subsequent evaluation a candidate (c04) for trial (t01) of sponsor (S01) (bitmark_S01_t01_m01_c04) and determines that the candidate is not appropriate for trial evaluation. The match service does not issue a consent bitmark certificate.
Example 2: Candidate does not consent to match invitation
Match service (m01) invites candidate (c11) to consent to be evaluated as a potential candidate for trial (t01) of sponsor (S01) (bitmark_S01_t01_m01_c11). Candidate c11 does not sign the bitmark certificate, thus refusing to consent. No health data bitmark certificate is created.
Example 3: Candidate consents to match invitation but does not send health data
Match service (m01) assesses candidate (c18) for trial (t01) of the sponsor (S01) (bitmark_S01_t01_m01_c18), invites the candidate to be evaluated with the candidate consenting by signing the consent bitmark but does not send health data for evaluation.
Example 4: Match service evaluation negative
Match service (m01) assesses candidate (c24) for trial (t01) of sponsor (S01) (bitmark_S01_t01_m01_c24). The candidate consents to the match service's request for evaluation by signing the consent bitmark. The candidate creates a corresponding health data bitmark certificate and issues this certificate to the match service, which signs and receives the corresponding medical information of the candidate. The match service evaluates the candidate disqualifying the candidate from the trial. The consent bitmark certificate is disabled by the match service, and the health data bitmark certificate is transferred to the candidate through one-way signature.
Example 5: Sponsor evaluation negative
A match service (m01) assesses a candidate (c34) as suitable for a trial and transfers both the consent and health bitmarks to the trial sponsor (s01) through two-way signature (bitmark_S01_t01_m01_c34). The sponsor determines that the candidate is not suitable for the trial and notes this outcome in the health bitmark. The sponsor transfers the health bitmark to the candidate through one-way signature and disables the corresponding consent bitmark.
Example 6: Candidate rejects enrollment offer
In the case of (m01), candidate (c27), trial (t01) and sponsor (S01) (bitmark_S01_t01_m01_c27), the candidate is assessed to be a qualified candidate for enrollment. However, the candidate refuses the invitation to the enrollment visit by not signing the consent bitmark. The health and consent bitmarks remain issued to the sponsor who must disable each from further use.
Example 7: Candidate accepts enrollment offer
Following the logic of the prior examples, candidate (c01) is assessed to be a suitable trial participant by the sponsor (S01). The sponsor evaluates the candidate, and finding the candidate suitable, transfers the consent bitmark certificate (bitmark_S01_t01_m01_c01) to the candidate via two-way signature as an invitation to an enrollment visit. The candidate signs this certificate accepting the invitation. The bitmark transactions, for example, 7 are listed in order of entry in [Table 7]. | Table 7: Example bitmark information for example 7, candidate accepts enrollment offer
Click here to view |
| Discussion | | |
Designing satisfactory medical data exchanges using cryptocurrency blockchains proved problematic for the authors. The cryptocurrency blockchain required supplemental peer-to-peer networking, or blockchain customization, to support multiparty procedural interactions. However, a patient matching data exchange marketplace, and by extension, any such health data exchange, was demonstrably simulated using a property rights blockchain, in which digital certificates persist state across blockchain transactions. The authors note that other blockchain frameworks, such as Ethereum (https://ethereum. org/), could have been employed in this work. However, the bitmark blockchain provided the inherent capabilities to implement the patient matching use case without extension.
In the example described, data owners were able to assign to other stakeholders, limited use rights to their data through digital blockchain title certificates, and interact procedurally to enable patient assessment for trial enrollment through blockchain transactions. This model, coupled with the inherent encryption and security features of the bitmark blockchain, promotes trust with respect to confidential handling and transfer of sensitive personal information, which can be performed at low cost with comprehensive provenance. As such, reliance on a third-party data exchange intermediary, a role traditionally served by the match service in this scenario, would become unnecessary.
Although no stakeholder is made redundant in the described trial matching marketplace, the match services can relinquish their role in coordinating interactions between candidates and sponsors. In this scenario, match services would appear to be disadvantaged as their compiled candidate collections, which would be shared in the proposed model, are likely considered intellectual property. However, the potential to greatly scale the candidate pool would promote more successful match events for both sponsors and match services. Match services would compete based on the accuracy of their proprietary matching methodologies rather than their ability to market and manage segments of candidate and sponsor populations. In addition, patients, individually or via their brokers, would be able to present themselves for trial candidacy to further enrich the candidate population. Trial matching, introduced by an author (TK) having deep expertise with trial matching operations, proved to be an excellent medical research-relevant use case that is representative of the types of multiparty transactions that underlie health care data exchange. More profoundly, this work demonstrates the potential of blockchains to serve as the foundations of open marketplaces comprised of stakeholders having diverse roles engaged in complicated procedural interactions. Small currency taxes (paid by sponsors and match services in the presented scenario) applied to key transactions (i.e., consent to match, distribution of match results, etc.) could be accumulated and used to reward independent miners and sustain an open, fair, competitive and efficient business network.[5]
Modeling the blockchain-mediated multiparty process is, of course, critical. In the example presented, the decision to distinctly represent consent and data access privileges reinforced the individual operational responsibilities of each stakeholder. It is appealing to place the consent bitmark certificate, which has tracked and enabled all transactions, in the responsibility of the party, which last processed the data as the final data processor is most likely to be the subject of process scrutiny/audit.
Alternatively, it appears prudent to place the health bitmark with the candidate regardless of how the matching process completes. In the scenario modeled, the sponsor maintains the health bitmark, and thereby access to the candidate health data, following the evaluation should the candidate accept an invitation to an enrollment visit. Although logically appropriate as the sponsor will likely need continued access to the candidate's data as enrollment progresses, returning the health bitmark to the candidate, regardless of the outcome, would reinforce the rights of candidates to retain control over their own health data. Creating two health data bitmarks, one each for the candidate/match service and candidate/sponsor interactions, would ensure that a candidate is always the source of a health data transaction. Moreover, in the modified scenario, the health data bitmark certificates would always be in possession of candidates at the completion of the process regardless of the outcome. This modified process, which could easily be implemented with the property rights blockchain, is represented in [Figure 3]. | Figure 3: A more idealized trial match implementation in which the candidate creates distinct health data assets for the match service and sponsor evaluations. In all cases the health data bitmark certificates issued against the assets are transferred to the candidate following assessment regardless of outcome
Click here to view |
The simulation does not model candidate remuneration, revocation of consent or data obsolescence during the matching process, onboarding/offboarding of roles, and data destruction. These process elements have straightforward putative designs and implementations using existing bitmark blockchain capabilities. For example, candidates could send notification of changes to their health records via a specialty bitmark allowing data processors to request an updated record if warranted.
End-user applications allowing each stakeholder to interact with the blockchain-enabled matching service would be necessary and will not be trivial to create. The authors have developed requirements for such applications and are developing medical data vaults for use by patients (work to be presented elsewhere). The current state of the art is to store complicated and/or high-volume datasets, such as medical information, external to the blockchain. The proposed model of dual consent and health data certificates provides an opportunity for efficiently distributing multi-factor authentication keys/credentials to access data referenced in blockchain transactions but stored on systems not associated with the blockchain. Data owners (e.g., candidates) will typically lose command and provenance of their data should these data be copied from source systems in the control of administrators acting on behalf of the data owners to purpose-built systems administered and operated separately by data processors (e.g., match services, and sponsors). This is a serious deficiency associated with medical data exchanges. Extending a public blockchain to support integrated large-scale data storage and high-performance computing environments does not appear to be economically or pragmatically feasible at the time of this writing. However, combining persistent blockchain tracking with data owner-controlled virtual computing environments that allow data processors transient access to consented owner data, i.e., Medical Data Trusts could address these risks to data privacy and data use beyond consent. Utilizing cloud provider-based capabilities, such as Google Cloud Platform's VPC Service Controls (https://cloud.google.com/vpc-service-controls), to realize controlled collaborative data perimeters would be a research topic well worth examination.
| Conclusion | | |
The blockchain is a brilliant concept for democratizing currency exchange and has been fully realized in many cryptocurrency implementations. However, the replacement of traditional business application platforms with blockchains, as has been discussed widely in technology forums over the past few years, has, to date, been slow to emerge. Procedural processing requirements associated with many business domains are not conducive to resolution by standard cryptocurrency blockchains. However, as demonstrated in this article, specialized blockchains, such as those having property rights extensions, can be used, without customization, to implement complicated procedures across multiple parties. These blockchains are better positioned to serve as the basis for general system designs capable of supporting a much wider variety of business applications. Such blockchain-based designs could avail the benefits of inherent data protection, provenance, and efficiencies of decentralization to many disparate business communities within and outside of the purview of health research.
Financial support and sponsorship
Nil.
Conflicts of interest
There are no conflicts of interest.
| References | | |
| 1. | Wagers, S. The Value of Medical Research Data Sharing and Reuse: A Multi-Stakeholder Discussion at the EU Parliament Organized by the eTRIKS Project. Brussels Belgium: BioSci Consulting; 2016. Available from: http://www.biosciconsulting.com. [Last accessed on 2020 Jul 20].  |
| 2. | |
| 3. | Tapscott D, Tapscott A. Blockchain Revolution: How the Technology Behind Bitcoin and Other Cryptocurrencies Is Changing the World. New York: Penguin Random House; 2016. |
| 4. | |
| 5. | |
| 6. | Atkinson N, Massett H, Mylks C, Hanna B, Deering M, Hesse B. User-centered research on breast cancer patient needs and preferences. J Med Int Res 2007;9:e13. doi:10.2196/jmir.9.2.e13. |
| 7. | |
| 8. | Birylukov A, Dinu D, Khovratovich D. Argon2: The Memory-Hard Function for Password Hashing and Other Applications. V1.2.1 PHC Release; 2015. Available from: http://password-hash ing.net/argon2-specs.pdf. [Last accessed on 2020 Jul 20]. |
[Figure 1], [Figure 2], [Figure 3]
[Table 1], [Table 2], [Table 3], [Table 4], [Table 5], [Table 6], [Table 7]
|
Search Pubmed for