MediVault — Decentralised P2P Medical Records

A secure, local-first electronic medical records desktop app built for HackUPC 2026, letting patients own their medical data while doctors append and share records with no central server.

Year: 2026
Type: Hackathon
Links: Repo

Problem

Patients don’t own their medical records, and centralised record systems create a single point of trust and failure between patients and doctors.

Role

Built with a team at HackUPC 2026. I was primarily responsible for the UI, and had a hand in most other parts of the app.

How it works

MediVault is role-based: you open it as a Doctor or as a Patient, and the two roles sit on opposite ends of the same append-only log. A doctor creates the ledger. They are issued a cryptographic keypair as their identity, and the public key is the thing they hand out — there is no account, no sign-up server, and no shared database behind it. From there they write medical notes against a subject and attach images to them, so an x-ray or a photographed prescription travels in the record rather than alongside it. A patient joins with two pieces of information: their own patient ID and the doctor's public key. Hyperswarm handles discovery and gets the two peers connected; hypercore is the append-only, hashed log that then replicates across that connection. The patient's history syncs directly from the doctor's machine with nothing sitting in between. A patient can hold more than one of these connections at once, so a history that spans several doctors is assembled on the patient's side rather than in anyone's datacentre. The whole thing is a desktop application: Electron for the shell, HTML, CSS and vanilla JavaScript for the interface, and Node.js with the Pear runtime underneath it doing the networking.

Fig. — the doctor’s append-only ledger replicates straight to patient peers over the swarm.

Stack

Electron
JavaScript
Node.js
HTML/CSS
Pear
hypercore
hyperswarm
b4a

Result

Doctors create an append-only cryptographic ledger and are issued a keypair as their identity; patients join the P2P swarm using their patient ID and the doctor’s public key, receiving records directly with no intermediary. Includes a multi-doctor care-team dashboard and PDF export.

What I’d do differently

The two things that gave us the most trouble were keeping peer connections consistent and getting the privacy and security model right — both are the parts of a P2P system that a centralised backend would have quietly handled for us, and both are where more of our time would go on a second attempt. The clearest next step is multi-author writes. Today a patient can share their data with several doctors, but each doctor's ledger is their own log; doctors cannot collaborate on one file. Letting several doctors append to the same patient record — one unified, multi-author medical history — is the feature that would make it usable beyond a demo.