Health4You Patient Chronicle

A secure patient timeline that unifies medical events and lets clinicians ask questions through source-grounded RAG with traceable, evidence-based answers.

Comment

About the Project

Current Working Demo (June 28, 2026)

The submitted demo is working now and can be tested at:

The current build uses synthetic data only. It does not contain real PHI/PII, real patient names, or real medical records.

What works in the current application:

  • clinician login / role switching for different doctors and organizations,
  • organization-scoped patient access based on consent, membership, role, and source accessibility,
  • 200 synthetic patients visible to the clinician workspace,
  • searchable patient selection across synthetic ID, diagnosis, medication, organization, consent, and access status,
  • longitudinal patient timeline with source-linked events,
  • patient-specific dashboard, medication view, laboratory analytics, imaging analytics, document view, dataset intake view, audit view, and privacy/compliance view,
  • urgent review queue for patients who need rapid analysis or a clinical decision,
  • urgent signals based on oncology surveillance status, AI-derived review flags, critical laboratory values, stale imaging, unresolved contradictions, and stale/review-needed data,
  • alert acknowledgement workflow: clinicians can mark an alarm as read, remove it from the active queue, review read-and-hidden alerts, restore an alert, or clear the read list for the current session,
  • laboratory visualizations: trend line by analyte, latest values by analyte, abnormality mix, and measurements by episode,
  • imaging visualizations: modality distribution, verification status, normalized measurements, procedure-planning relevance, and stale-imaging warnings,
  • AI assistant for the selected patient, with deterministic retrieval filters and an AWS Bedrock path that sends only authorized synthetic evidence to the model,
  • source-grounded AI answers with citations, uncertainty, missing-data warnings, contradiction handling, and audit identifiers,
  • privacy guardrails that reject prompts containing likely direct identifiers before they reach the answer pipeline,
  • public health endpoints confirming the deployment boundary: Vercel frontend + AWS backend path, synthetic-only data mode, and AWS-only runtime for the container deployment.

The project is therefore no longer only a static concept or mockup. It is a functional clinical workflow prototype showing patient search, clinician scoping, timeline review, trend analysis, imaging review, urgent triage, acknowledgement of alerts, and evidence-grounded AI over synthetic patient data.

Inspiration

Healthcare data is rarely available as one coherent patient story.

A clinician may need to review information spread across electronic health records, laboratory systems, prescriptions, hospital discharge summaries, imaging reports, referrals, procedures, and documents supplied by the patient. Even when all these records exist, reconstructing what happened, when it happened, and why it matters can take significant time.

We built Health4You Patient Chronicle to transform fragmented healthcare information into a structured, longitudinal patient timeline.

Our goal was not to create another generic medical chatbot. We wanted to build a system that allows clinicians to ask questions about a patient’s complete history while keeping every answer connected to its original evidence.

Examples include:

  • What changed after the patient’s previous hospitalization?
  • Which medications were introduced after a specific diagnosis?
  • How have laboratory results changed over time?
  • What findings are relevant to a planned cardiac procedure?
  • Are there contradictory diagnoses or measurements in the record?
  • Which source confirms a reported allergy or previous intervention?

The core principle is simple:

AI-generated clinical context should be traceable, verifiable, and limited to the data the user is authorized to access.

⸻

What It Does

Health4You Patient Chronicle collects medical information from multiple sources and converts it into normalized, timestamped patient events.

These events may include:

  • clinical encounters,
  • diagnoses and symptoms,
  • laboratory results,
  • vital signs,
  • medications and allergies,
  • admissions and discharge summaries,
  • procedures and referrals,
  • radiology reports,
  • medical imaging measurements,
  • patient-uploaded documents,
  • AI-generated analytical results.

The application presents these events as an interactive patient timeline and provides a source-grounded Retrieval-Augmented Generation, or RAG, assistant.

Instead of passing the entire medical record to a language model, the system first retrieves the events relevant to the clinician’s question. Retrieval is restricted by patient identity, organization, permissions, event type, and time range.

A simplified relevance model can be represented as:

R(e,q)= \alpha S_{\text{semantic}}(e,q) +\beta S_{\text{temporal}}(e,q) +\gamma S_{\text{clinical}}(e,q)

where:

  • e is a patient event,
  • q is the clinician’s question,
  • S_{\text{semantic}} measures semantic similarity,
  • S_{\text{temporal}} prioritizes the relevant period,
  • S_{\text{clinical}} reflects structured medical relationships,
  • \alpha,\beta,\gamma are configurable weights.

Only the selected evidence is provided to the generation layer. The resulting answer includes its underlying sources, dates, and event references.

When the available evidence is incomplete or contradictory, the application should communicate that uncertainty rather than fabricate a confident answer.

⸻

How We Built It

Front end

The clinical application is built with Next.js and deployed on Vercel. The project also has a Dockerized AWS deployment path using Amazon ECR and Amazon ECS/Fargate, with Amazon Bedrock integrated for the AWS LLM runtime.

We used v0 to accelerate the design and iteration of:

  • the patient timeline,
  • the clinical summary dashboard,
  • the conversational RAG interface,
  • evidence and citation panels,
  • document ingestion views,
  • missing-data warnings,
  • conflicting-information alerts,
  • responsive desktop and tablet layouts.

Using v0 allowed us to move rapidly from workflow concepts to a functional interface while still refining the experience around real clinical use cases.

Data layer

For the production architecture, we selected Amazon Aurora PostgreSQL as the primary persistent database. The current hackathon demo runs on a synthetic in-application dataset so reviewers can safely test the workflow without PHI/PII.

In the target production architecture, Aurora stores:

  • patient records and identity mappings,
  • healthcare organizations and users,
  • encounters and longitudinal events,
  • normalized clinical metadata,
  • source documents,
  • event relationships,
  • access-control rules,
  • patient consent information,
  • retrieval metadata,
  • vector embeddings,
  • AI-query audit logs,
  • answer-to-source references.

A relational database is important because healthcare information is not merely a collection of text chunks. It contains strict relationships between patients, visits, clinicians, organizations, documents, procedures, and dates.

Aurora PostgreSQL gives us a strong transactional foundation while also supporting the semantic-search layer required for RAG.

Hybrid retrieval

The retrieval process combines semantic search with structured SQL filters.

For example, a query can be restricted to:

  • one patient,
  • a selected clinical organization,
  • cardiovascular events,
  • the previous 12 months,
  • laboratory and imaging records only,
  • data accessible to the current user.

Conceptually:

SELECT clinical_events.* FROM clinical_events WHERE patient_id = :patient_id AND organization_id IN (:authorized_organizations) AND occurred_at BETWEEN :date_from AND :date_to AND event_type IN (:allowed_event_types) ORDER BY semantic_similarity(embedding, :query_embedding) DESC LIMIT :evidence_limit;

This is safer and more precise than relying on vector similarity alone.

Ingestion and normalization

The ingestion layer is designed to accept information from sources such as:

  • EHR and HIS platforms,
  • FHIR APIs,
  • HL7 messages,
  • laboratory systems,
  • PACS and DICOM workflows,
  • structured medical APIs,
  • PDF and text documents,
  • specialty diagnostic applications.

Incoming information is transformed into a common event model.

Each event contains fields such as:

{ "patientId": "patient-123", "eventType": "laboratory_result", "occurredAt": "2026-06-18T08:30:00Z", "sourceSystem": "hospital-lis", "clinicalCode": "creatinine", "value": 1.4, "unit": "mg/dL", "provenance": { "sourceDocumentId": "document-456", "author": "laboratory-system", "importedAt": "2026-06-18T08:32:00Z" } }

This makes chronology, provenance, filtering, and cross-source comparison possible.

⸻

Architecture

EHR / HIS ────────────────┐ Laboratory systems ───────┤ PACS / DICOM ─────────────┤ Prescriptions ────────────┤ Patient documents ────────┤ Specialty AI systems ─────┘ │ ▼ Secure ingestion layer FHIR / HL7 / APIs / files │ ▼ Normalization and validation │ ▼ Amazon Aurora PostgreSQL ┌─────────────────────────────────┐ │ Patient and organization data │ │ Longitudinal clinical events │ │ Documents and provenance │ │ Embeddings and retrieval data │ │ Consent and access policies │ │ AI audit and source references │ └─────────────────────────────────┘ │ ▼ Hybrid RAG retrieval Semantic search + SQL + permissions │ ▼ Source-grounded AI layer │ ▼ Next.js application deployed on Vercel

⸻

Challenges We Faced

  1. Normalizing incompatible medical data

Healthcare systems describe similar events in different formats. A diagnosis may appear as a coded FHIR resource, free text in a discharge document, or a field imported from a legacy HIS.

The challenge was to preserve the original information while creating a common event structure that could be searched consistently.

Our approach was to keep both:

  • a normalized representation for retrieval and analysis,
  • the original source and provenance for verification.
  1. Avoiding unsafe RAG behavior

A normal RAG application optimizes for relevance. A healthcare application must also optimize for authorization, provenance, chronology, and uncertainty.

A semantically similar record is useless—or dangerous—if it belongs to another patient, comes from an unauthorized organization, or refers to an outdated clinical context.

We therefore apply access and patient-scope restrictions before information reaches the language model.

  1. Maintaining chronology

Clinical meaning depends heavily on time.

For example:

  • a medication prescribed before hospitalization has a different meaning from one prescribed after discharge,
  • a laboratory abnormality may be temporary or progressive,
  • an imaging measurement may belong to a previous procedure-planning episode.

We learned that a useful medical RAG system must understand not only similarity, but also sequence and temporal relationships.

  1. Handling contradictory evidence

Medical records frequently contain conflicting information.

Two documents may report different diagnoses, medication doses, dates, or measurements. Silently selecting one result would produce a misleading summary.

The system therefore treats contradictions as first-class information and can surface both sources rather than pretending there is a single verified truth.

  1. Designing for clinicians rather than AI demonstrations

A visually impressive chatbot is not enough.

Clinicians need to understand:

  • where an answer came from,
  • when the event occurred,
  • whether the source is trustworthy,
  • whether important data is missing,
  • whether two sources disagree.

This shaped the interface around the patient timeline, evidence panels, warnings, and traceable citations rather than around chat alone.

  1. Balancing rapid development with production architecture

The hackathon encouraged rapid iteration, but the project concerns workflows that eventually require strong reliability and security.

Vercel and v0 helped us move quickly at the interface layer, while Aurora PostgreSQL allowed us to maintain a deliberate backend architecture rather than building a disposable prototype.

⸻

What We Learned

Structured data and semantic retrieval work best together

Embeddings are useful for finding relevant clinical information, but they are not sufficient for enforcing patient boundaries, organization permissions, dates, event types, or consent.

The strongest architecture combines:

  • relational data,
  • semantic retrieval,
  • clinical metadata,
  • deterministic authorization.

Provenance must be designed into the system

Adding citations after generating an answer is not enough. The relationship between an answer and its evidence must be preserved throughout ingestion, retrieval, and generation.

For that reason, provenance is part of the event model itself rather than an optional presentation feature.

The patient timeline is more important than the chatbot

The conversational interface makes access easier, but the durable product value lies in building a trusted longitudinal patient record.

The RAG assistant becomes useful only because the underlying timeline is structured, searchable, and auditable.

Healthcare AI should communicate uncertainty

A system that always produces an answer can be less useful than one that says:

  • there is insufficient evidence,
  • the data is outdated,
  • two records conflict,
  • the source cannot be verified.

In medical workflows, calibrated uncertainty is a feature, not a failure.

Fast prototyping does not require weak infrastructure

Using v0 and Vercel allowed us to develop the user experience rapidly, while Aurora PostgreSQL provided an architecture suitable for continued development beyond the hackathon.

This combination helped us build quickly without treating the backend as temporary.

⸻

Impact

Health4You Patient Chronicle can help medical teams reduce the time spent reconstructing patient history and improve access to relevant clinical context.

Potential users include:

  • hospitals,
  • outpatient clinics,
  • cardiology departments,
  • diagnostic networks,
  • telemedicine providers,
  • healthcare coordinators,
  • insurance and care-management organizations.

The platform is intended to support clinicians, not replace them.

Its value comes from providing a faster and more transparent path from fragmented patient data to verifiable clinical context.

⸻

What Makes the Project Different

Many RAG applications search a collection of documents.

Health4You Patient Chronicle instead creates a continuously evolving, event-based model of one person’s healthcare journey.

Its distinguishing elements are:

  • longitudinal patient-event architecture,
  • combined SQL and semantic retrieval,
  • chronology-aware context selection,
  • patient- and organization-level isolation,
  • evidence-linked AI answers,
  • explicit contradiction handling,
  • integration of structured clinical and imaging-derived data,
  • full auditability of retrieval and generation.

The result is not merely a chatbot over medical files. It is a foundation for a secure and explainable patient-context platform.

Built With

Share this project:

Updates