Inspiration
Like many, we're fascinated by the blockchain technology, and wanted to develop a real use case for it. We knew that applying it to medical health records (MHR) wasn't unheard of. We read about blockchain, reviewed academic papers describing specific attempts to use it as a solution to the MHR problem, and considered the implications of touching this field: privacy, security, accessibility, and safety. We thought that we could bring something new to the table.
What it does
There are two clients: one for providers, and one for patients. Providers, after a first physical meeting with a patient, can use their desktop client to request medical records from the patient. The patient, after authenticating themselves on the mobile app, can approve or deny a request. If the request is approved, the doctor will swiftly get access to the requested records. There is no scramble for medical records and no loss of records because of the universal nature of the blockchain; every record is available to the provider insofar as the patient allows it. Importantly, the information availability is not absolute; the provider and patient get to use our UI to select which specific records are made available.
We realized that because of the nature of our technology, we could do more with it. A secure, legally legitimate way to make this massive data set available that preserves anonymity would revolutionize predictive and preventative care through the research opportunities it would avail. We make that possible in three ways. First, we can promise a higher deal of anonymity for studies because we only make available information that is necessary. For example, if I am doing a cardiovascular study, I probably don't need to know eye color, so that data is left out. Second, our security measures ensure that only the party who has ownership or consent can access our records, and that if any tampering occurs, it is nearly impossible for us not to detect it. Third, we create an incentive mechanism to get users to opt into these studies, thereby navigating legal concerns.
How we built it
When a doctor wants to make a request to their patient, they use desktop UI to select records. This goes to our patient's mailbox on the server, which the doctor can only obtain the address of through their first physical meeting with the patient. Since this is a hackathon, and you're seeing our source code, there wasn't much point in the added layer of security which would have been adding a key to verify that mail came from a OneHealth client, so we didn't add that. Still, even without that layer, a 32-byte key makes it virtually impossible to correctly identify a person's mailbox. That is to say, you can't even ask the patient for their info. In fact, assuming a billion patients, your odds of even guessing any one user's address, to ask a completely random person for their information, is still 8.64E-69.
After the patient authenticates the request through fingerprint scanning on their phone, they find all of the blocks on the blockchain which contain their medical records. However, due to the size limitations of blocks, medical records on the blockchain are defined by encrypted URIs. The URI then points to an encrypted medical record on a database. Because of the size of the data, the records themselves must live as encrypted entries in the database. However, to take advantage of blockchain's record of truth, the URI is the SHA-256 hash of the medical record. Therefore, it is (virtually) impossible for any tampering performed on the database to not be detected by the blockchain.
Once the encrypted data is obtained by the patient's client, it will be decrypted, the relevant information will be extracted, and then this new record will be encrypted with the doctor's public key. The URI to it (generated, as per usual, with a SHA-256 hash of the file) will be encrypted with the doctor's public key, and this reply will go into the doctor's mailbox. The doctor can then access the information with their private key.
To make the data available to researchers, we built off of our original APIs and UI. A research group can use their funding to be allowed to show a prompt to users asking them to opt into studies. In exchange for opting in, users will have the opportunity to be selected to win a cash prize. They will also be informed that they will be contributing to the common good of society, although the latter offer may be less persuasive to some, unfortunately.
Challenges we ran into
Making our ideas real is hard in 36 hours. Client encryption should have been straightforward but there were issues with that. Lotta stuff.
Accomplishments that we're proud of
What we learned
Learned more about blockchain and cryptography.
Log in or sign up for Devpost to join the conversation.