MedVault: The EHR That Lets Patients Hand Out Time-Limited Access

A Spring Boot and React health-record system built around patient ownership, audit trails, and role-based access instead of a static provider database.

9 min read • View on GitHub • More from Vinayreddy765

A patient stands before a vault door while clinicians receive small access slips that visibly expire. The scene explains the article's central idea: medical records are not a permanent open file, but a vault that can be granted, revoked, and audited. — MedVault reframes the record as something the patient lends, not something the provider simply owns.

Key Takeaways

MedVault’s real innovation is not storage, but consent, because it treats access as a first-class record with an expiry date.
The stack is conventional on purpose, with Spring Security, JWT, and role mapping doing the heavy lifting instead of exotic infrastructure.
Its audit trail and manual file checks show how regulated software often comes down to disciplined data modeling and enforcement.
The project reads like a useful prototype for patient-centric systems, while its blockchain branding and its implementation stack point in different directions.

The first thing MedVault gets right is the mental model. It does not behave like a shared drive with a login screen. It behaves like a vault, where the patient controls who gets in, for how long, and with what level of access.

That matters because healthcare software lives or dies on trust. If access can be granted, logged, and revoked cleanly, a lot of the surrounding compliance story becomes less mystical and more like ordinary software engineering.

The record belongs to the patient

MedVault’s strongest idea is simple: the medical record is linked to the patient, not parked in a provider-owned archive. That flips the default ownership model and makes the system easier to explain to both users and auditors.

The repository research points to a deliberately patient-centric design, with records, permissions, and access events modeled as separate concerns. Even the repository description leans into the same theme, framing the project as a secure, tamper-proof health record system.

A close-up record token moves through three distinct gates labeled by their function: identity, consent, and audit. The image explains that access is not a single switch but a sequence of checks that culminates in a logged event. — MedVault’s access flow is procedural, not magical. Identity, consent, and audit are separate checkpoints.

Time-bound consent is the real product

The core workflow is a consent lifecycle, not a one-time permission switch. A record moves through identity checks, consent validation, authorization, and audit logging before access is granted.

The centerpiece of the system is the RecordAccessPermission model. It ties a patient to a healthcare professional, records the access level, and adds an expiration timestamp. That is the whole trick, and it is a good one.

Instead of treating consent as a checkbox at account creation, MedVault treats it as a living data structure. Access can lapse naturally. That design is simpler to reason about than a permanent grant with ad hoc exceptions later.

This is also why the project feels more practical than ideological. The governance model is visible in the schema. You do not need a white paper to understand what the code wants to protect.

Security is layered, not magical

The backend security story is standard Spring, used well. A JWT filter validates the token, the user lands in the SecurityContextHolder, and role-based checks such as @PreAuthorize decide what happens next.

That stack matters because it keeps the trust boundary explicit. Authentication happens once, authorization happens everywhere else, and the controller layer still has enough context to enforce business rules around records and appointments.

The implementation research also points to BCrypt password hashing and a single user entity that maps to patient and doctor roles. That is not flashy, but it is exactly the sort of structure that makes a prototype understandable and extensible.

Records are files, but files need rules

MedVault handles actual uploads and downloads, not just metadata. That means file storage cannot be an afterthought. The controller checks access manually before serving a record, and the audit trail records usage events so the system can explain who touched what.

The tradeoff is obvious: local file storage is easy to build, but harder to scale cleanly. For a prototype, that is acceptable. For a production system, storage and revocation would need more infrastructure around them.

Still, the architecture is coherent. The file is not the product. The policy around the file is the product.

Appointments make the vault operational

The appointment system turns MedVault from a document locker into a clinical workflow. Doctors define availability, patients book into those slots, and appointments move through states like pending, approved, rejected, and completed.

That matters because access to a record is only useful when it connects to care delivery. The schedule model gives the consent model a reason to exist in daily use.

In other words, MedVault is not just about retrieving records. It is about making the record available at the right time, to the right role, for the right visit.

Model	Who controls access	How consent works	How revocation works	Audit trail strength	Main tradeoff
Traditional provider-owned EHR	Provider or institution	Often implicit in patient registration and care relationship	Usually policy-driven, not patient-driven	Depends on vendor and deployment	Simple operations, weaker patient control
MedVault consent-first vault	Patient	Time-limited permission record with access level	Expires automatically or can be revoked	Strong if audit writes on each view/download	Cleaner ownership model, prototype-scale storage
Blockchain-first healthcare system	Network rules or smart contracts	Encoded in contract logic or ledger workflow	Harder if permissions are immutable	Potentially strong for provenance	More complexity, often higher operational cost

That comparison is also where MedVault becomes interesting as a prototype. It borrows the language of decentralized trust, but the implementation reads like a disciplined full-stack app. The result is less exotic than blockchain branding suggests, and more useful as a pattern library.

What MedVault borrows, and what it avoids

The repository description talks about blockchain, while the implementation research points to Spring Boot, React, MySQL, and JWT. That tension is worth noting, but not overstating. The more durable story is the consent architecture, not the marketing label.

Against mainstream EHRs, MedVault is more legible and more patient-facing. Against ledger-heavy health systems, it is lighter, easier to inspect, and much closer to a conventional application stack. That makes it a good educational project, even if it is not a finished clinical product.

Its real value is that it shows how far you can get with ordinary tools when the data model is well chosen. Consent windows, audit logs, role checks, and explicit availability are enough to express a serious policy layer.

Why this prototype matters

MedVault is useful because it compresses several hard healthcare problems into familiar engineering patterns. You can read it as a lesson in regulated software: model ownership clearly, keep permissions time-bound, log the important events, and do not let access rules drift into tribal knowledge.

That is a strong foundation even if the project stays at prototype scale. In a space where software often obscures accountability, MedVault’s design makes the rules visible.