Post

MedCertify: Final Year Project

Posted Updated
By Lukman Azri
5 min read
MedCertify: Final Year Project

Building “MedCertify”: my student attempt at a blockchain-based health certificate. MedCertify is my FYP: a low-key blockchain prototype for health certificates using hash-on-chain, data-off-chain. Tamper-evident, privacy-minded, and honest about limitations.

Background

I first heard about blockchain when I was studying for CompTIA Security+. The idea of an immutable ledger stuck with me, but I parked it in my head until final-year project season came around. When it was time to pick an FYP, I decided to challenge myself and actually build something with it. That’s how MedCertify was born: a prototype that issues and verifies health certificates using blockchain without pretending it’s perfect.

Why even bother with blockchain for certificates?

Health certificates (fitness-to-work, vaccination proof, lab results summaries) are typically PDFs or database records. Those can be:

  • Tampered (edited after issuance),
  • Hard to verify (you must trust whoever emails you the PDF),
  • Centralized (single server = single point of failure). My goal wasn’t to “blockchain everything,” but to test whether blockchain can add tamper-evidence and independent verification without exposing sensitive data.

What I actually built

In plain English

MedCertify is a simple web app for clinics:

  • Staff record patient info and results.
  • The doctor issues a certificate PDF.
  • The PDF stays off-chain (normal storage).
  • A cryptographic hash (fingerprint) of that PDF is written on-chain.
  • Anyone can later verify the PDF by comparing its hash to the one on the blockchain.

No personal health data goes on-chain only the hash that proves integrity.

Tech stack (student-budget edition)

(I chose familiar tools so I could focus on the integrity/verification logic.)

  • Frontend: Single-page app (e.g., React)
  • Backend: Node.js/Express API (roles, cert generation, hashing)
  • Blockchain: Small smart contract (stores certificate hashes + minimal metadata)
  • Storage: Off-chain file storage for PDFs (e.g., local/cloud; IPFS in the prototype)
  • Database: MongoDB/Postgres for app state and logs
  • Auth & Roles: Role-Based Access Control (receptionist, nurse, doctor, admin, patient); only doctors can issue certificates

How verification works (the core idea)

When issuing a certificate:

  • Generate the PDF.
  • Compute its SHA-256 hash.
  • Store only that hash on the blockchain (plus a simple ID/timestamp).

When verifying later:

  • Recompute the hash of the PDF you have,
  • Compare it to the on-chain hash,
  • If they match: the file hasn’t changed since issuance.
1
2
3
4
5

issue:
  PDF -> SHA-256 -> on-chain hash

verify:
  your PDF -> SHA-256 -> equals on-chain hash? (valid/invalid)

A quick walkthrough

  • Reception/Nurse: Register patient and capture vitals/tests.
  • Doctor: Review, then click Issue Certificate.
  • App: Generates PDF -> hashes it -> uploads PDF off-chain -> writes hash on-chain.
  • Patient/Verifier: Scans a QR or opens a link -> downloads PDF -> “Verify” button recomputes hash and checks the chain.

What worked (for a prototype)

  • End-to-end flow: Staff create records; doctors issue certs; patients can view/download.
  • Tamper detection: If someone edits the PDF, verification shows a hash mismatch.
  • Privacy by design: Sensitive data remains off-chain; blockchain is used purely as an integrity anchor.
  • RBAC sanity: Non-doctors can’t issue certificates.

It’s not production-grade, but the core learning goals (hashing, on-chain anchoring, basic clinic roles) came together.

Where it’s not perfect (yet)

Keeping it real:

  • Key management & encryption: Prototype-level only. Real systems need KMS/Vault, key rotation, and audits.
  • Revocation & updates: No polished on-chain revoke/reissue flow yet.
  • Wallet/UX friction: Blockchain wallets can confuse non-technical users; more user-friendly login options would help.
  • Compliance: I avoided storing personal data on-chain, but there’s no formal PDPA/HIPAA review yet.
  • Performance & scale: Not load-tested in a real clinic; minimal monitoring/hardening.

If I keep going: my next steps

  • Managed key security: Integrate AWS KMS/HashiCorp Vault; remove app-stored secrets.
  • Revocation & reissue: On-chain events + admin UI to revoke/replace certificates.
  • Better UX: Keep wallets for staff; let patients verify via simple web links/QR (no extensions).
  • Deployment hardening: Enforce HTTPS, rate limiting, audit logs, and basic SIEM alerts.
  • Pilot with a clinic: Validate workflow, collect feedback, measure real-world performance.

What I learned (as a student)

  • Blockchain is best for integrity, not storage. The hash-on-chain, data-off-chain pattern is practical.
  • Minimize on-chain data. Store only what’s needed for verification; keep personal data off-chain.
  • RBAC matters. Map app roles to real clinic responsibilities to prevent misuse.
  • Prototype - iterate. Ship something small, learn from it, then improve security and usability.

Final thoughts

This FYP isn’t claiming enterprise readiness. It’s a learning journey taking the blockchain concepts I first saw during Security+, applying them to a focused problem, and being honest about trade-offs. If you’re also a student, start with one clear integrity problem and try hash-on-chain + data-off-chain. You’ll quickly see where blockchain helps, where it doesn’t, and how to design with privacy first.

Repo & demo

References (short & friendly)

Project
Blockchain HealthTech Smart Contract Verification FYP Ethereum IPFS
This post is licensed under CC BY 4.0 by the author.