FAQ
Frequently Asked Questions.
We are currently prototyping the initial version of the platform, and we expect this prototype to be online by March 2021. The prototype would be focused on the consortium development model and be tested in a POC together with one or more commercial/academic genetics labs.
Yes, your lab or university can participate in DeBio, Please register here.
In many cases, bioinformatics labs can analyze anonymous data and provide clear insights without phenotypical context. Please see the 1000 Genome Project and the Personal Genome Project, both of which provide an anonymous database of genomes that can be accessed by researchers. Each genome here can still yield useful insights.
In cases where the genomes are utilized for purposes that require the comparison between your genotype & phenotype, our platform shall allow users to disclose specific data that are not directly personally identifiable -- gender, race, etc.
There are two options, the traditional option or the fully decentralized option. We prefer fully decentralized, but this might not be an option in all locales. Traditional payment models may also work better for consortium or private deployments of DeBio.
Enterprise/Consortium Model
We designed Debio with 2 labs per transaction since we want to solve the following global problem with personal genetic testing:
The traditional option: Consumer funds are held in escrow by a local payment gateway or bank until the lab provides valid data (report and genome) into decentralized storage. The smart contract then triggers fund disbursement into the lab's accounts. Note that this still maintains the anonymity of the genomic data, since:
- Payment gateway/bank does have access to consumer KYC but does not have access to genomic data or reports
- Labs don't have access to consumer KYC, although it does have access to anonymized genomic data.
Trustless/Decentralized Payments
All transactions happen via a Blockchain token model. Consumer onboards with their preferred cryptocurrency token, or goes through a fiat-to-crypto bridge (example here) to pay. Smart contracts hold consumer's tokens in escrow until labs provide valid data. The smart contract then triggers fund disbursement into the labs' account.
We designed DeBio with 2 labs per transaction since we want to solve the following global problem with personal genetic testing:
Unlike other categories of services, consumers can't recheck the results of DNA analytics services unless they have access to a lab or PCR device of their own.
This, we feel, places consumers at a disadvantage and may lower the quality of future genetic testing results within the ecosystem.
Thus, we designed the platform with a semi-random, rating-based selection of two labs per transaction to ensure two things:
- All labs, from garage DIYBiolabs to large companies, can join the ecosystem and compete with each other.
- The quality of the results is maintained, even with the consumers being anonymous.
In the long term, this system also allows the ecosystem to grow further -- with smaller labs helping to check the larger labs, and vice versa. The rating system associated with the labs would also provide incentives for the ecosystem to increase in quality.
For the private/consortium blockchain concept of Debio, the default option is single-lab, since consumers will choose a lab from the "Lab Marketplace".
For the private/consortium blockchain concept of DeBio, the default option is single-lab, since consumers will choose a lab from the "Lab Marketplace".
You commit fraud in any form at (in) DeBio. For example, you cheat to get rewards or apply other cheat methods.
Yes, all branches need to register their account separately since each branch might have different services offered. They are also required to have a verified account. Every branch of the laboratory will need to register as a separate account in the DeBio WebApp.
Your sample might be rejected because of several reasons that do not meet the quality standard. It can be contaminated during the shipping process, or not sufficient enough to be analyzed, or other reasons that do not match Lab’s standards.
You will receive a notification upon rejection of your sample.
Your sample might be rejected because of several reasons:
The sample does not meet the quality of standards to proceed with the test, this may be caused because of improper handling of the container, or the sampling procedure.
A notification will be issued to the user, informing the user of the rejected sample and its reason.
In the event of a sample rejection, you will get a refund for the service price after Lab has rejected the sample. You can access Payment History to check your refund status.
The private key from the original device can be backed up as a passphrase. This passphrase can be kept safe since it can be used to access the user's data! Best practices for this passphrase include writing it down on a piece of paper and physically hiding it away from view in a safe place.
If the user accesses the dApp from another device, the passphrase from the first device can be entered into the dApp to restore access to the user's genetic data and any prior reports.
There is a single private key (encoded as a passphrase) that originates the derivation of all other keys that are used by the user. For every test using the same individual's genetic material, a different public key is used.
The reason for this: To avoid "traffic analysis" which is a method of information gathering by observing the movement and reuse of public keys.
In many countries, there is no need for any return address except in specific situations that shouldn't apply here. In countries that require a return address, we have two alternatives:
In the trustless/decentralized model, the platform can use another lab's address as the return address -- so that in the event of the sample being undeliverable, the sample would still end up in a lab on the network
In the consortium/enterprise model, we can set up a PO Box to handle any undelivered mail, and embed it on every envelope as the return address.
Personal genome files are huge. How would you expect to send these files via Blockchain?
You're right -- genome files are quite large. Raw PCR output can be up to 900GB, and even VCF files hover around 10-100MB (for a subset of sequences) or 1GB (for Whole Genome Sequencing).
Here's our strategy in enabling these files to be shared and owned by the user:
First, we will focus on the VCF files exclusively. In our initial POC, only the smaller VCF files will be included in the "result package" sent to each user, along with the report.
Second, we will utilize a combination IPFS / torrent platform to act as the decentralized storage mechanism. The "result package" is encrypted off-chain (with the user's public key) and put within this decentralized storage platform.
Third, the main blockchain platform itself will link to the decentralized storage mechanism through a hash list. This means that the main blockchain platform only contains pointers to the data in decentralized storage, and not the actual genomic files.
In the enterprise/consortium strategy, the IPFS/torrent platform can be replaced with regular public or private cloud solutions.
Last modified 4mo ago