Project Overview
MediAssist is a clinical management web application built for healthcare providers. It sits at the intersection of two distinct needs: structured patient record management and intelligent, AI-driven clinical support. The platform gives doctors a unified workspace where they can register and manage patients, review medical histories, and interact with an AI assistant that understands medical context, all without switching between systems.
The domain is outpatient and clinical care, where doctors handle large patient volumes and need fast, reliable access to accurate records. Every part of the system was designed with HIPAA compliance in mind, from how patient data is stored and transmitted to how the AI interacts with protected health information. The application is a full-stack web platform built with a React frontend, a Python API, a PostgreSQL database, and AWS Bedrock powering the AI layer.
The Problem
Clinicians face a familiar frustration. The tools meant to help them spend more time with patients often do the opposite. Electronic health record systems are designed for compliance and billing, not for clinical thinking. Searching a patient's history means navigating rigid forms. Updating a record after a consultation requires clicking through multiple screens. Getting a quick summary of a patient's allergies or current medications before a procedure can take longer than it should.
Existing solutions fall short in two ways. General EHR platforms are powerful but heavy, and they weren't designed for speed or natural interaction. Lighter practice management tools handle scheduling and billing well but offer little support for the clinical workflow itself. Neither category gives a doctor the ability to simply ask a question about a patient and get a meaningful, context-aware answer.
On top of that, many AI tools available to clinicians today are built for general consumer use. They weren't designed to handle protected health information responsibly, and they weren't built with the audit trails, access controls, or data handling requirements that a clinical environment demands.
The gap we set out to close was building a system where the medical record and the AI assistant aren't two separate products, and where neither one cuts corners on patient data safety.
Our Approach
We started by mapping the actual workflow of a doctor during a patient encounter: look up the patient, review relevant history, make notes, and flag anything that needs follow-up. That workflow is mostly information retrieval and annotation, which is exactly where AI can add the most value with the least friction.
Rather than layering a chatbot on top of a traditional records system, we designed the AI as a first-class citizen of the platform. The chat interface isn't a help widget. It's a clinical workspace where a doctor can ask about a patient's allergies, check for drug interactions, or request a pre-visit summary and get a grounded, data-driven answer in seconds.
Compliance wasn't an afterthought. Before writing a single line of feature code, we established the data handling principles the platform would follow: all protected health information stays within a controlled infrastructure, the AI layer never sends raw patient data to third-party services without appropriate agreements in place, and every write action taken by the AI is validated before it touches the database.
We chose to build a custom platform rather than extend an existing framework because the integration between the AI layer, the data layer, and the compliance requirements had to be tight. Intent classification, structured data extraction, real-time record retrieval, and audit logging all needed to work as a single, coherent flow.
Technical Architecture
On the frontend, we used React 18 with TypeScript and Vite. React was chosen for its component model and ecosystem maturity. TypeScript enforces data contracts across a domain where correctness matters, because a wrong type on a medication field isn't just a bug, it's a patient safety concern. Vite keeps the development cycle fast, and the codebase is organized by feature rather than by file type, making it easy to reason about each domain in isolation.
The backend runs on FastAPI with Python 3.11. FastAPI gave us automatic request validation through Pydantic, async-native request handling, and auto-generated API documentation. The async-first design with SQLAlchemy 2.0 and asyncpg means the server handles concurrent requests without blocking, which matters when AI inference calls can take a second or two. All API communication is encrypted in transit using TLS, and authentication is handled through token-based access with session expiry controls to meet HIPAA's access management requirements.
For the database, we went with PostgreSQL extended with the pgvector extension. PostgreSQL is the right choice for healthcare data given its transactional integrity, mature tooling, and predictable behavior under load. Patient data is stored with field-level sensitivity in mind, and the database is hosted in an environment that supports HIPAA-eligible infrastructure with encryption at rest. The pgvector extension lets us store vector embeddings directly in the same database, so clinical notes are chunked, embedded, and indexed alongside the relational patient data they describe, without routing sensitive data through an external service.
The AI layer runs on AWS Bedrock, which operates under AWS's HIPAA-eligible services program. This was a deliberate infrastructure decision. Using Bedrock means the language model inference and embedding generation happen within an environment that supports Business Associate Agreement coverage, keeping protected health information within a compliant boundary. Claude Sonnet handles intent classification and response generation, and Amazon Titan Embed V2 handles semantic embeddings for clinical note retrieval.
When a doctor sends a message, the system retrieves the most semantically relevant chunks from that patient's clinical history using cosine similarity on the embedding vectors, then injects that context into the language model prompt. The model answers from the patient's actual record, not from generic medical training data, and the retrieved context never leaves the controlled infrastructure.
Key Features
The patient management module is a complete interface for patient records, covering demographics, blood group, national identification number, allergies, active conditions, and current medications. Search works across multiple fields simultaneously so a doctor can find who they need without knowing exactly what to type. Filter options let them quickly surface patients with known allergies, active conditions, or clean records, and results paginate cleanly for large rosters.
Clicking any patient opens a full detail view showing demographics, identification details, allergies with color-coded flags, active conditions, current medications, and clinical notes. From the same screen, a single button loads that patient directly into the AI chat workspace with no re-searching and no re-entering context.
Patient registration uses a structured form with real-time validation on required fields. Allergies, conditions, and medications are entered as natural comma-separated values rather than rigid dropdowns, keeping data entry fast without sacrificing structure.
The AI chat workspace is the centerpiece of the platform. Once a patient is loaded, the interface seeds itself with a contextual greeting that surfaces key clinical flags like documented allergies and active conditions before the doctor types a single character. Doctors ask natural language questions and receive answers grounded in that patient's record. The AI classifies the intent, retrieves or updates the relevant data, and responds in clinical language with appropriate safety caveats.
The system handles ten intent types across both read and write operations, covering allergy queries, medication lookups, condition checks, interaction checks, pre-visit summaries, and adding new records directly through the conversation. Write intents go through a strict validation layer before any record is updated. The model returns a structured JSON payload, the backend parses and validates it, and only then does the change persist. This approach protects against malformed or hallucinated outputs making their way into a patient's medical record.
Throughout every chat session, a persistent sidebar shows the loaded patient's allergies, active conditions, and current medications. It's always visible so critical safety information is never more than a glance away.
A quick-query panel surfaces the most common clinical questions as one-click prompts, covering allergy checks, medication lists, vitals, visit summaries, and interaction checks. The settings screen gives doctors control over retrieval scope, response tone, AI source citations, and security options including two-factor authentication and session auto-lock timers, which support HIPAA's requirement for automatic logoff on inactive sessions.
Challenges and How We Solved Them
The first challenge was getting structured data out of unstructured input reliably. A doctor might say "she's allergic to aspirin and ibuprofen" or simply "add aspirin allergy." Both mean the same thing, but the system needs to extract a consistent data structure either way, and in a clinical context, inconsistency in a medication or allergy record can have real consequences. We addressed this by designing a strict JSON output format for the language model with explicit slots for each intent type. The system prompt defines the contract, and the backend validates and parses the response before any database read or write occurs.
The second challenge was making semantic search fast enough to feel invisible. The retrieval step runs on every chat message, so it sits in the critical path for perceived response time. Using pgvector with an IVFFlat index on the embedding column brought vector similarity search down to single-digit milliseconds even as the notes table grows. Storing embeddings in the same database as patient records also eliminated a network round-trip to an external vector store, which was important both for performance and for keeping protected health information within a single, controlled environment.
The third challenge was keeping the interface coherent across an AI-driven workflow where data can change mid-session. Keeping the sidebar, the patient detail view, and the chat responses consistent required careful state management using scoped stores per feature with targeted refetches after confirmed AI responses, rather than a shared global state that would create more coupling than it solved.
Outcome
The finished product is a coherent clinical workspace where patient record management and AI-assisted care sit side by side, within a compliance architecture designed for real healthcare environments. A doctor can find a patient in seconds, open their full record, load them into the chat workspace with one click, and immediately ask whether a planned medication conflicts with anything in their allergy history, all without leaving the application or touching a traditional form workflow.
The RAG pipeline means the AI's answers are grounded in the patient's actual data. Intent classification means the system understands what a doctor is asking for, not just what words they used. The validation layer means no AI output reaches the database without passing a structural check. And the infrastructure choices, AWS Bedrock, encrypted storage, token-based auth, and session controls, mean the platform is built on a foundation that healthcare providers can actually trust.
Lessons Learned
The most valuable decision we made early was treating compliance as an architectural constraint rather than a checklist to complete at the end. Choosing HIPAA-eligible infrastructure from the start, particularly AWS Bedrock for the AI layer, meant we never had to retrofit data handling decisions after the features were already built. That saved significant rework and gave us confidence that the system behaved correctly at every layer.
If we were to extend this further, we would invest in structured audit logging for every AI-driven interaction. In a clinical context, knowing not just what changed in a patient's record but what the doctor asked, which AI response triggered the update, and when it happened, matters for both regulatory accountability and for improving the system over time. We would also explore streaming language model responses to shorten perceived latency on longer answers, and role-based access controls to distinguish between what a physician, a nurse, and an administrative user can view or modify.
One thing we wouldn't change is using the same PostgreSQL instance for both relational data and vector embeddings. The operational simplicity of a single database with one backup strategy, one connection pool, and one migration system was worth more than the theoretical performance gains of a dedicated vector store, and it kept our data boundary clean from a compliance standpoint.
Let's Build Something Like This
If you're working on a product that needs to combine structured data management with intelligent, context-aware AI, whether in healthcare, legal, finance, or any knowledge-intensive domain where data compliance matters, we'd like to talk. Get in touch with our team to explore what's possible.