MedVault

Inspiration

Healthcare is one of the areas where people generate an enormous amount of personal data, yet that data is often fragmented across completely different systems. A patient might have one record at a hospital, another at their primary-care provider, laboratory results somewhere else, imaging records in another portal, prescriptions through a pharmacy, and important documents sitting in email or physical folders.

Even when patients technically have access to their information, access isn't the same thing as ownership or organization. Finding a specific laboratory result, understanding when a medication changed, locating an old imaging report, or putting together a complete history can still be extremely difficult.

That is the problem that inspired MedVault.

We wanted to build something that gives people a single source of truth for their medical history. Instead of forcing patients to navigate through disconnected healthcare portals, MedVault brings their information together into one organized, chronological health record.

The idea is based on a simple philosophy:

“Your health. Your history. Your data.”

We deliberately didn't want MedVault to be another generic AI health application. We didn't want to build an “AI doctor” that tries to diagnose people or tell them what treatment they should receive. Instead, we focused on a problem that we believe is much more fundamental: helping people actually organize and control the information that already exists about them.

That led us to think of MedVault as something bigger than a document-storage application. Our long-term vision is for it to become an operating system for a person's medical history—a layer that connects the different pieces of healthcare information a patient has accumulated throughout their life.

The goal is to make healthcare information feel less fragmented and more like something the patient actually owns and understands

What it does

MedVault creates a patient-owned medical data vault that organizes healthcare information into one secure, chronological record.

The centerpiece of the platform is the Medical Timeline. Instead of forcing users to search through individual documents, MedVault organizes their healthcare history chronologically so they can see what happened, when it happened, where it happened, and what source the information came from.

A user's timeline could contain appointments, laboratory results, medications, imaging records, procedures, vaccinations, and uploaded documents. Each event can be opened to reveal additional information, related events, and its original source.

MedVault also includes a Document Library, where users can upload PDFs and images and organize them into categories such as laboratory records, imaging, prescriptions, vaccinations, referrals, insurance documents, and other healthcare records.

When a record is uploaded, the application can organize information from it into structured fields such as the document type, date, provider, facility, medical events, medications, and laboratory results. Importantly, the original document remains accessible so that users can trace information back to its source.

Another major feature is Medication History. Rather than showing only a current medication list, MedVault is designed to show how medications change over time. Users can see when a medication was started, changed, continued, or discontinued, along with the provider and source associated with that information.

We also built a Laboratory Dashboard that allows users to view recorded laboratory results over time. Instead of making medical judgments about whether a result is “good” or “bad,” the application focuses on displaying the information from the source and showing changes over time.

One of our most important features is the Medical Passport.

The Medical Passport allows users to create a portable summary of selected parts of their medical history. They can choose information such as medications, allergies, important history, procedures, vaccinations, recent laboratory records, relevant documents, and emergency contacts, then generate a professional summary that can be securely shared.

We also built Secure Sharing around the principle that patients should control their own information. Instead of giving another person unlimited access to an entire medical history, users can select exactly what information they want to share, specify how long the access should last, and revoke access when necessary.

Finally, MedVault includes Data Quality tools. Medical records aren't always perfectly consistent, so MedVault can surface potential conflicts, possible duplicate records, and potentially incomplete information. Rather than pretending to know which record is correct, the platform uses cautious language such as “Potential conflict detected” or “No matching record was found.”

Altogether, the MVP gives users a way to organize, search, understand, and selectively share their medical history without pretending to replace the healthcare professionals who actually provide medical care.

How we built it

We approached MedVault as a full-stack healthcare infrastructure product rather than simply a collection of screens.

The frontend was built using React and TypeScript, which allowed us to create a modular interface where each part of the medical record experience could operate as its own component while still feeling like one cohesive application.

The backend was built using FastAPI, providing the API layer and handling the application's core functionality.

We designed the application around several major concepts: structured medical records, timelines, documents, provenance, sharing permissions, data quality, and portability.

One of the most important technical decisions was making data provenance part of the product itself.

For a healthcare application, simply displaying information isn't enough. Users need to know where that information came from. That's why our record-detail experience includes an Original Source section and data-provenance information showing where the record originated, when it was imported, and whether it has been verified.

We also designed our document-processing flow so that extracted information is clearly identified as extracted information. The original source document remains available instead of disappearing behind a generated summary.

This was especially important because we wanted MedVault to be built around trust rather than false certainty.

The same philosophy influenced our Data Quality system. If two records contain different information, MedVault shouldn't silently decide that one is correct. Instead, it should surface the conflict and allow the user to investigate it.

For the hackathon, we used realistic fictional demo data and simulated healthcare connections. We intentionally did not pretend that integrations existed when they had not actually been implemented.

However, we also designed the architecture with the future in mind.

The eventual goal is to support healthcare interoperability through technologies and standards such as FHIR, along with patient-authorized EHR connections, pharmacy integrations, laboratory integrations, imaging systems, provider portals, and secure APIs.

This means that although our hackathon version is an MVP, the architecture is designed around the possibility of becoming a much larger platform.

Challenges we ran into

Our biggest challenge during the hackathon was deployment.

We originally planned to use Momen for deployment, but very close to the deadline, we ran into issues that meant we could no longer depend on that approach for our final demonstration.

That put us in a difficult position because deployment wasn't something we had planned to completely rethink at the end of the hackathon.

Instead of continuing to fight an unreliable deployment strategy and potentially losing the ability to demonstrate the project, we made the decision to pivot to a localhost-based setup.

This meant adapting how our frontend and backend communicated and making sure the application still functioned correctly in the new environment.

At that point, we had very little time.

We had to quickly identify what was actually breaking, separate deployment problems from application problems, verify our API communication, test the major user flows, and make sure that the application we had built could still be demonstrated reliably.

It was one of the most stressful parts of the hackathon because we were making an architectural change when we should have been polishing the final product.

However, it also became one of the most valuable experiences.

We learned that hackathons aren't always about following the plan you created at the beginning. Sometimes the most important engineering skill is recognizing when a plan isn't working and pivoting before it becomes a bigger problem.

We also faced a broader challenge with the healthcare domain itself.

Healthcare data requires a much higher level of caution than ordinary application data. We couldn't simply design features around assumptions. We had to think about what information came from a source, how it should be represented, what the user should be allowed to control, and how the application should communicate uncertainty.

That influenced several of our design decisions, particularly our emphasis on source documents, provenance, cautious language, and patient-controlled sharing.

Accomplishments that we're proud of

We're proud that we didn't just build a single feature—we built an entire end-to-end product experience around a complicated real-world problem.

Within the scope of the hackathon, we created the foundation for a patient-owned medical vault with a large number of interconnected features.

We built a complete medical timeline that can organize different types of healthcare events.

We built a document-management system that allows medical records to be organized and connected back to their sources.

We built medication and laboratory views that allow information to be understood across time.

We created the Medical Passport concept so that a patient can take a selected summary of their medical history and make it portable.

We built user-controlled sharing around the idea that someone shouldn't have to hand over their entire medical history just because they need to share one part of it.

We also built the Data Quality concept, which we believe is particularly important because healthcare information isn't always perfectly clean or consistent.

Instead of treating every piece of information as automatically correct, MedVault can identify potential conflicts, possible duplicates, and missing relationships between records.

We're also proud of the product direction and design.

We wanted MedVault to look like serious healthcare infrastructure rather than a generic health dashboard. The design direction emphasizes clean typography, organization, trust, restrained colors, professional dashboards, and clear visual hierarchy.

Most importantly, we believe we successfully communicated the bigger idea behind the product.

We didn't want the judges to look at MedVault and think:

“This is an app for uploading medical PDFs.”

We wanted them to see:

“This could become the operating system for someone's personal medical history.”

That distinction is what we're most proud of.

What we learned

The biggest lesson we learned was that building a product is fundamentally different from simply building features.

It's easy to start a hackathon by making a checklist:

Build the dashboard.

Build the upload system.

Build search.

Build the backend.

Build the AI functionality.

Build the sharing system.

But once we started putting all of those pieces together, we realized that the real challenge was making them feel like one coherent product.

Every feature had to contribute to the same central idea: giving patients a single, organized, trustworthy view of their healthcare history.

We also learned how important trust and transparency are when dealing with sensitive information.

In a normal application, an algorithm making a reasonable guess might be acceptable.

In healthcare, we need to be much more careful.

If two records disagree, we shouldn't automatically decide which one is right.

If a record doesn't contain something, we shouldn't assume it never happened.

If information was extracted from a document, we should preserve the original document so the user can verify it.

Those principles changed how we thought about the entire product.

We also learned a major lesson about deployment and engineering under pressure.

Our last-second transition from Momen to localhost showed us that having a backup plan matters. More importantly, it showed us that good engineering isn't just about preventing problems—it's also about being able to recover quickly when problems happen.

Finally, we learned that scope matters.

MedVault could theoretically become an enormous project because healthcare interoperability itself is incredibly complex. During the hackathon, we had to determine which parts were important enough to demonstrate the vision while keeping the MVP achievable.

That taught us how to distinguish between the core product idea, the features needed to demonstrate it, and the infrastructure that belongs in the future roadmap.

What's next for MedVault

The hackathon MVP is only the beginning of what we envision for MedVault.

The biggest next step is moving beyond simulated healthcare connections and toward real healthcare interoperability.

Our long-term goal is for patients to be able to authorize MedVault to retrieve their information from different healthcare systems instead of manually collecting documents themselves.

That could eventually include hospitals, primary-care providers, specialists, pharmacies, laboratories, imaging centers, and other healthcare organizations.

FHIR-based interoperability would be an important part of that future architecture.

We also want to make the Medical Passport significantly more powerful.

Instead of being just a generated summary, it could eventually become a truly portable representation of a patient's important healthcare information—something they could securely bring with them when changing providers, traveling, visiting specialists, or dealing with emergencies.

Another major area we'd like to develop is the medical data graph.

Rather than thinking of healthcare information as isolated documents, we want MedVault to understand relationships between events:

a medication connected to a prescription,

a prescription connected to a provider,

a provider connected to an appointment,

an appointment connected to laboratory results,

and those results connected back to their original source.

That would make it possible to navigate healthcare history in a much more intuitive way.

We also see opportunities to expand patient-controlled sharing.

Users could eventually create different permission profiles for doctors, specialists, caregivers, family members, emergency situations, or other trusted individuals—while still maintaining complete visibility into who has access to what information.

Beyond that, the roadmap could include:

Real EHR integrations FHIR-based healthcare interoperability Pharmacy integrations Laboratory integrations Imaging integrations Provider portals Secure healthcare APIs International health-record portability Family and caregiver accounts Emergency medical profiles Advanced audit logs More sophisticated record relationships Improved document processing Expanded search capabilities

The long-term vision is much larger than simply storing medical documents.

We want MedVault to become a patient-controlled infrastructure layer for healthcare information.

Healthcare systems may change. Doctors may change. Insurance providers may change. People may move between hospitals, states, and even countries.

But their medical history should remain portable, organized, understandable, and owned by them.

That is ultimately what MedVault is trying to build:

A future where your healthcare data follows you—not the other way around