Inspiration
In March 2023, the Hospital Clínic of Barcelona was hit by ransomware. Doctors lost access to patient records for weeks. Thousands of surgeries were cancelled. Sensitive data ended up for sale on the dark web. The root cause was simple: every record lived on a single centralized server. One breach, total catastrophe. We kept asking ourselves why hospitals own our medical data in the first place — and decided to flip that.
What it does
MediOwn is a decentralized medical records app where the patient owns the data, not the hospital. The patient generates a temporary access code as a QR. The doctor scans it with their webcam and a peer-to-peer connection is established directly between the two devices, with no servers in between. During the consultation, the doctor can read the history and add diagnoses or prescriptions. When the patient ends the consultation, the connection is severed instantly and the doctor can no longer read or write anything new. If every hospital server went down tomorrow, MediOwn users would still have their records.
How we built it
The technical foundation is the Holepunch P2P stack — Pear Runtime and Autopass, built on Hypercore, Autobase and Hyperswarm. We deliberately chose pure P2P over blockchain. Existing decentralized health record projects all rely on Ethereum or similar chains, with their gas fees, latency and speculative tokens. None of that adds value to a doctor seeing a patient. Pure P2P is faster, cheaper and architecturally cleaner. The app is built on Electron. Patient data lives in a local Corestore. Autopass handles invites, pairing and multi-writer sync. Hyperswarm discovers peers via a global DHT. When the patient revokes access, the connection tears down and the UI on both sides reflects it.
Challenges we ran into
Getting the P2P pairing to work between two physical machines on different networks was the biggest hurdle. Our first attempt over a hotspot took 81 seconds — well above the 5-30 seconds typical of less restrictive networks. We learned that mobile carriers often use Carrier-Grade NAT, which makes peer discovery painful but not impossible. Understanding Electron's multi-process model took time too — every P2P operation has to flow through a tightly controlled IPC bridge, which we now actually defend in our pitch as a security feature. And we had to be honest about what revocation can and can't guarantee: once data leaves the patient's device, you can't verify what happens to the copy on the other side, so we redesigned the feature around what we can actually deliver.
Accomplishments that we're proud of
We achieved serverless P2P sync across different devices. From a cold start, a patient grants access via an invite, and the doctor can securely document the encounter. Watching the medical record update on the patient’s device seconds after the doctor hits a key — with no middleman in between — felt like a breakthrough for data ownership. We also resisted scope creep — picked one real problem with real human stakes, built the smallest thing that proves it, and stayed honest about what's done versus what's a next step.
What we learned
Decentralization is not a buzzword. It's a set of design trade-offs around discovery, identity, conflict resolution, revocation and key management. Each has elegant solutions in the Holepunch stack but they only make sense once you've gotten your hands dirty. We also learned that the hardest part of P2P isn't the cryptography — it's the network. Routers, ISPs and mobile carriers were not designed with P2P in mind, and that fragility is something the whole decentralization movement still needs to solve.
What's next for MediOwn
- An immutable audit log so the patient can see exactly which doctor accessed or modified what, and when.
- Cryptographic data minimization at session end, where per-session encryption keys turn revocation from a trust-based promise into a cryptographic guarantee.
Built With
- autobase
- autopass
- corestore
- css
- electron
- html
- html5-qrcode
- hypercore
- hyperswarm
- javascript
- node.js
- p2p
- pear-runtime
- qrcode.js
Log in or sign up for Devpost to join the conversation.