Virgil

Virgil is a Cal Poly bioinformatics capstone prototype focused on inflammatory bowel disease, or IBD. The earlier system accepted genetics files and health information. My team and I expanded that concept into a mobile experience for recording daily check-ins, reviewing history, managing genetics documents, and viewing saved results.

I worked directly with physicians to bring their vision for Virgil to life. That collaboration gave me a chance to learn from doctors while building something for people living with IBD.

The team’s clinician discussions identified a gap between appointments: symptoms, medication changes, treatment responses, and how someone felt over several weeks can be difficult to reconstruct later. Virgil’s goal was to collect dated, structured entries that a patient could return to before a visit.

The application also needed to connect that history with a separate recommendation workflow. The challenge was to make entering information, reviewing past check-ins, and viewing saved results feel like parts of the same mobile experience.

As the lead software developer, my job was to turn the clinical vision into a working mobile experience and connect it to the existing genetics system. That responsibility covered:

• Mobile development: Built the navigation, onboarding, home dashboard, daily check-in, and timeline workflows.
• Accounts and patient records: Integrated Supabase authentication, session persistence, patient profiles, and saved health data.
• Backend integration: Extended the inherited Flask backend with a patient-context adapter and connected storage-backed recommendation runs to the mobile app.
• AI Insights: Implemented an optional service that uses saved patient context to explain recorded information and prepare questions for a doctor.
• Technical handoff: Documented setup, architecture, app flows, and remaining limitations so future student developers could continue the project.

My team and I worked across engineering and clinical research, building on the genetics engine and clinical mappings inherited from earlier contributors.

I built the navigation around a simple question: what does this person need to do next? The opening screen restores the session, sends signed-out users through onboarding, and checks whether a signed-in user has a patient profile. A valid login alone is not enough to start saving health records.

The engineering challenge was bringing a newer patient app together with an inherited genetics system. I integrated a shared Supabase data layer and extended the backend connection so the two generations could work with the same patient context.

The older engine expected patient information in its own format. I extended the backend with an adapter that translated the newer shared records into that format, rather than rebuilding the original genetics engine.

That let the mobile app focus on collecting and presenting information while reusing the project’s existing Python processing. The integration still needed agreement on identifiers, field meanings, and result structure. A shared database does not make those differences disappear.

The legacy web upload remains a separate path: it sends an upload to Flask and displays returned results. That ordinary upload does not, by itself, establish that a result was saved into a mobile patient’s history.

The inspected backend used a limited curated dataset. These counts describe the rules I was integrating with, rather than a dataset I independently created.

I delivered a mobile prototype with accounts, patient profiles, daily check-ins, a history timeline, document management, and saved-result screens. The backend integration connected that newer experience to the inherited genetics system, and the optional Insights service added a way to ask questions using saved patient context.

Those pieces addressed the gap that motivated Virgil: keeping track of what happens between appointments. The prototype gives patients a place to record symptoms and medication use as they happen, with a dated history intended to support conversations with their clinicians. It turns information that could be difficult to remember later into records that can be revisited.

Physicians tested the prototype. That brought the work beyond implementation and into the hands of the people whose clinical perspective shaped the project. They had something concrete to try, and the next team has an implemented experience to continue testing and improving.

My team and I prepared Virgil for continuation, and I wrote the technical handoff covering setup, architecture, workflows, and remaining work. Deployment is the next step for the new team. The result so far is a prototype tested by physicians and a documented foundation for future developers; broader patient use is still ahead. I’m proud that the work can continue toward the people it was built for.

The next iteration needs to correct medication interpretation: the backend currently ignores the daily taken flag and can treat unchecked medications as already taken. Check-in saving also needs an all-or-nothing operation or recovery path so a failed related save does not leave an incomplete record.

Backend requests need caller authentication and ownership checks. The inspected recommendation trigger does not send a caller token, and the Flask routes do not verify one. Matching a document and check-in to the same profile is useful validation, but it does not establish that the caller owns that profile.

Finally, I want the full upload → active file → check-in → backend run → saved-result journey to be easy for the next developer to demonstrate. The schema, access policies, summary calculations, and service setup need to be documented and verified alongside that flow.

Virgil is my favorite project because it brought together two things I care about: healthcare and computer science. I worked with physicians to turn their vision into something people could use, and I learned so much from that experience.

That collaboration made me care about how information moved through every part of the app. A field in a form could become a saved record, an input to the older system, and something a patient would review later. Connecting those pieces taught me how much thought goes into making one workflow work across different systems.

Seeing how the work could support people living with IBD made this project mean more to me. I got to connect what I was building with the people it was meant for. That is what made me so passionate about Virgil, and why I want to keep putting time and energy into it.