From Python to Web3 — Part 1 of 3

Build This: A FHIR Consent Vault for Your Healthcare + Blockchain Portfolio

If you’re a Python developer thinking about Web3, the hard question isn’t “should I learn Solidity?” It’s “what should I actually build to prove I can do this work?”

I’m going to walk you through a specific project that punches well above its weight on a freelance portfolio. It combines three things — healthcare data standards, decentralized identity, and cryptographic verifiability — that almost nobody in the global freelance market handles together in Python.

The project: a FHIR Consent Vault — a system where patients manage consent for their medical data, every consent record is cryptographically signed and anchored in a tamper-proof ledger, and third parties (insurance companies, researchers) can verify consent without trusting a central authority.

You can build a working version in four weeks of evening work. By the end, you’ll have something that demonstrates skills priced at $80–$150/hour on Upwork.

Why This Combination Wins

Three standards converge in this project, and all three are accelerating right now.

FHIR (Fast Healthcare Interoperability Resources) is HL7’s international standard for medical data exchange. The US 21st Century Cures Act mandated FHIR APIs for all EHR systems in 2022. The EU, UK, Australia, and Canada have all adopted it. Every healthcare startup on the planet needs people who can work with FHIR. Most of them are looking in the Java/C# world. Python expertise here is rare.

DID and Verifiable Credentials are W3C standards for portable digital identity. Vaccine passes, university degrees, employment credentials — all moving to this model. The EU Digital Identity Wallet, mandated for member states in 2026, runs on these standards.

Merkle Trees and cryptographic anchoring are the bridge to blockchain. You don’t need to actually deploy a blockchain to demonstrate the pattern — a local SQLite “ledger” plus proper hashing logic is enough to prove you understand it.

A developer who can speak all three languages — FHIR data, DID/VC identity, and on-chain verification patterns — is the kind of person healthcare-blockchain startups can’t find. Be that person.

The System Design

There are three actors:

• Patient — owns medical data, grants and revokes consent
• Data Holder — a simulated hospital running a FHIR server
• Requester — a simulated insurance company or research institution

The flow:

1. Insurer requests access to “diabetes-related observations from the past 6 months”
2. Patient reviews and approves → system creates a FHIR Consent resource, signs it with patient’s key
3. Hash of the signed consent goes into a Merkle Tree, which periodically commits a root to the ledger
4. Hospital verifies the patient’s signature, releases the requested FHIR resources to the insurer
5. Insurer verifies the data hash matches what was committed → confirms authenticity
6. Patient can revoke consent at any time; revocation also goes on the ledger

What this proves: you understand healthcare data semantics, identity cryptography, and verifiable systems. That’s a strong demonstration.

The Stack

# Core
fastapi              # REST API backend
fhir.resources       # FHIR Python library (Patient, Consent, Observation)
cryptography         # ECDSA signing, SHA-256 hashing
pymerkle             # Merkle Tree implementation
sqlalchemy + sqlite  # Local ledger simulation

# Identity
didkit               # DID Document, Verifiable Credential issuance
# (or implement did:key manually — it's surprisingly simple)

# Demo UI
streamlit            # Three-panel demo: patient / hospital / insurer

# Testing
pytest

Generate fake patient data with Synthea, an open-source project that produces realistic FHIR-format synthetic medical histories. One command gives you ten patients with 30 years of medical records each — no legal risk since none of it is real.

The Four-Week Build

Week 1 — FHIR Foundations

• Generate 10 synthetic patients with Synthea
• Use fhir.resources to parse Patient, Observation, Condition, and Consent resources
• Build FastAPI endpoints: GET /patients, GET /patients/{id}/observations, POST /consents
• Deliverable: a working FHIR CRUD API with a Postman collection

Week 2 — Consent Ledger and Merkle Trees

• Implement consent issuance: patient signs with ECDSA, system generates and stores hash
• Hourly Merkle Tree commits: bundle hashes, compute root, store root in ledger table
• Verification endpoint: given a consent, return its Merkle proof and verify against the stored root
• Deliverable: tamper-evident consent system with unit tests

Week 3 — DID and Verifiable Credentials

• Issue each patient a did:key (simplest DID method, generated from a public key directly)
• Wrap consent records as W3C Verifiable Credentials
• Implement verifier-side validation: check VC signature, validate issuer DID, check expiration
• Deliverable: portable, self-contained consent credentials that work without your server running

Week 4 — Demo and Documentation

• Build a three-panel Streamlit UI: patient (grant consent), hospital (view requests), insurer (verify received data)
• Record a 3-minute demo video walking through the insurance claim scenario
• Write a comprehensive README with architecture diagram and sequence diagrams
• Publish one blog post (in English): “Building a HIPAA-friendly Consent Ledger with FHIR and DIDs in Python”

A Smaller Version If You’re Starting Out

If four weeks feels like too much commitment, start with a two-week mini version: FHIR Hash Notary.

A single CLI tool that:

• Takes a FHIR JSON file as input
• Computes SHA-256 hash + adds an RFC 3161 timestamp + signs with ECDSA
• Outputs a “notary token” JSON file
• Has a separate verify command that validates the token against the original

This teaches you the cryptographic pieces and FHIR parsing without the full system complexity. Two weeks of evenings. Then if you enjoy it, extend it into the full Consent Vault.

Day One

You can start today:

# 1. Generate fake patient data with Synthea (requires Java)
git clone https://github.com/synthetichealth/synthea
cd synthea && ./run_synthea -p 10 Massachusetts

# 2. Look at what came out
ls output/fhir/

# 3. Set up Python environment
pip install fhir.resources fastapi pymerkle cryptography uvicorn

The first thing to do — really the only first thing — is to load one Synthea output JSON in Python and print out the patient’s full medication history. Half an hour, maybe an hour. That single exercise will teach you more about FHIR than any tutorial, because you’ll have to wrestle with the structure yourself.

After that, the project unfolds naturally.

Why This Matters

There’s a temptation when learning a new technical area to try to learn “everything” — read every tutorial, watch every video. That path leads to perpetual student status, not employment.

The shortcut is to build one specific thing well, then write about it. A working FHIR Consent Vault with proper tests, clean code, a video demo, and a thoughtful blog post is worth more on a portfolio than ten half-finished projects across ten technologies.

If you ship this, you have something genuinely rare: Python expertise in a Java-dominated standard, applied to a problem that real companies are trying to solve.

That’s enough to start a freelance practice on.

---

Next in this series: once you’ve built something in Python, you’ll start hearing about Solidity and Rust. Which one should a Python developer learn — and how does the choice change what you can charge? Coming in Part 2.

---

Written by ChainLab — Chain Within Your Life. We build blockchain infrastructure for the real world. chainlab.dev