FluBioscience
project
FluBioscience · Yamma
build
Android prototype in development
tested with
synthetic data only
released
not yet
planning since

Yamma, a personal health record.

FluBioscience is developing Yamma, an Android app that helps you keep a steady record of your symptoms and bring it into each stage of a medical visit.

Concept · sample data
Concept: the confirmed record card from the Yamma symptom record screen, showing onset date, body area, type, intensity, duration, and recording date, all sample data.

The screens on this page are concept designs filled with sample data, not screenshots of a finished app.

Where things stand

Prototype

Works in our Android prototype.

Manual records & daily review

Manual symptom entry, encrypted on-device storage, a symptom diary, and an intensity timeline by date and body area.

In development

Being built; not yet working end to end.

Structured symptom records

Turning a symptom conversation into a structured record. AI-extracted entries can’t be saved until validation checks run and pass.

On-device urgency rules

A rule-engine skeleton with no clinical rules yet, so for now it answers “not evaluable”.

Planned

Specified in our planning documents; not built yet.

The visit journey

Optional department and hospital guidance, factual visit summaries, prescription capture and review, medication records, and a health calendar.

Before, during, and after a visit

Planned How we want one set of records to carry through a visit. Every screen here is a planned design; manual entry and the diary already work in the prototype.

1

Before a visit

Start with a symptom record. Choose what comes next.

Describe a symptom in a conversation or enter it directly, then check the record before it’s saved. Whether you go further is up to you.

Yamma symptom record concept with a conversation, confirmed fields, and equal No, record only and Yes choices.
Concept · sample data

Record and choose

Check the details, then keep the record or ask for guidance.

  • 아니오 · 기록만 No, record only

    Keep the entry in your symptom diary. The diary works on its own.

  • 예 Yes

    Continue to a few follow-up questions, then department and hospital guidance.

Planned Yamma department and hospital navigation, showing an unconfirmed urgency state and fictional hospital examples.
Concept · sample data

Find a route to care

Department guidance leads to hospital search, then a booking page or a phone call.

If urgency can’t be determined, Yamma says so instead of guessing. Opening a booking page or calling a hospital doesn’t confirm a reservation.

2

During a visit

Bring your recorded history into the conversation.

We plan to gather the main symptom, how it has changed, known medications, and health history into a factual summary a clinician can read. The summary adds no diagnosis or treatment plan.

Planned Yamma factual visit summary with symptoms, medication and health history, an onset-date timeline, and text sharing.
  • The timeline is organized by onset date.
  • Missing medication or history details are marked as unknown.
Concept · sample data

A factual visit summary

Recorded facts and a symptom-onset timeline, ready to share as text.

3

After a visit

Carry the visit record into daily medication tracking.

Add a prescription or visit record from a photo or by typing it in. Review it, save it, and then use it for a medication schedule.

Also planned: rule-based checks of new and existing medication records for interactions, a log of doses taken, general care information, and daily symptom updates.

Any change to your medication is for your prescribing clinician or pharmacist to decide.

Planned Yamma prescription or medical-record capture with direct entry and information review before saving.
Concept · sample data

Review the visit record

Photo capture and direct entry both lead to a review step. Review and save the record before preparing a medication schedule.

Planned Yamma medication schedule based on a reviewed prescription record, with a dose-taken action and daily symptom recording.
Concept · sample data

Record doses taken

The schedule uses the reviewed record. Dose and frequency stay unconfirmed in this example.

Planned Yamma health calendar showing a synthetic symptom record, a medication schedule with no intake recorded, and no registered visit.
Concept · sample data

Review a day’s records

Symptom entries, recorded doses, and visit dates in one daily view.

Logging a dose would update the record that the calendar and future visit summaries read from. From the calendar, you can go back to the symptom diary and keep recording.

Rules we set before writing code.

Health records deserve caution. These rules come first in our development guidelines. Next to each one is where it stands today.

  1. Saved records stay on the phone, encrypted.

    Symptom records are kept in an encrypted database on the device, with the key protected by Android Keystore. Our rule is that servers don’t store the original record permanently.

    Prototype Encrypted storage is built and covered by 3 instrumented Android tests. This describes our approach. It is not a security certification.

  2. Identifiers are filtered before anything leaves the phone.

    Before text is sent for symptom structuring, a filter masks phone numbers, ID numbers, email addresses, and names written in a labeled or self-introduction form. The server also rejects requests that still contain known patterns.

    Prototype The filter is pattern-based and can miss things, which is one reason we use only synthetic data for now.

  3. No check, no save.

    An AI-extracted symptom is saved only after it passes a schema check and a separate medical-terminology check, and both have to actually run. Entries you type yourself go through their own confirmation step and are never labeled as AI-verified.

    In development The second check isn’t set up yet, so AI-extracted records are not saved. They are returned for review instead.

  4. Safety calls aren’t left to a language model.

    Emergency flags and medication-interaction warnings should come from fixed rules that can be tested, not from an AI model’s judgment.

    In development We’ve built an on-device urgency rule engine with no clinical rules yet. When it can’t decide, it reports “not evaluable” and never defaults to “routine”. Medication-interaction rules are planned.

  5. Synthetic data only, for now.

    Every test and demo so far uses invented scenarios. We plan to run production on self-hosted open models in South Korea. Until that is in place, no real health information goes into the prototype.

    Current practice

Yamma is for keeping and organizing personal records. It does not diagnose, prescribe, or assess emergencies, and it hasn’t been clinically validated.

Build log

May 2026 to now

Milestones from our planning documents and our private code repository. Commit IDs are listed for reference only. The repository isn’t public.

  1. Planning archive

    Project planning begins

    First product plan drafted May 21–23, alongside background research and an early flowchart of the app.

  2. –Design doc,

    A change of architecture

    We dropped the plan to run everything through a general-purpose cloud AI service. Instead: open models we plan to host ourselves, fixed rules for safety checks, and a separate validation layer for AI output. App design settled in July.

  3. 1d9f9cf

    Clinician review

    A university physician reviewed our plan: feedback on symptom-to-department mapping, building test cases in a standardized clinical-exam (CPX) format, and making medication summaries the first priority. The same day, plans, specs, and code moved into one repository.

  4. 97a69b7

    Shared module and Android prototype

    Shared data contract, symptom collection, encrypted diary, and an Android demo. 161 backend (Python), 14 Android unit, and 3 instrumented Android tests passed in the development environment, on synthetic data.

    Detailed test record, Sep 5
    • The 3 instrumented Android tests covered opening the encrypted database, reopening it, and rejecting a wrong key or plain-text access.
    • Also checked by hand: a request containing personal identifiers was rejected without echoing the input, and saved records survived a force-quit and an app update.
    • Not yet tested: the quality of AI extraction. The model access and the medical-term checker weren’t set up, so AI-extracted records are blocked from saving.

    These are development checks recorded at the time and not re-run for this page. They say nothing about clinical accuracy or real-world use.

  5. 68452ff

    Consistency check and cleanup

    Checked the shared module against the specs, then simplified the backend and Android code with no intended change in behavior.

  6. ffbb56e

    On-device urgency engine (skeleton)

    A rule engine that runs offline. It has no clinical rules yet and reports “not evaluable” rather than guessing.

  7. 9f4da8c

    Data contracts for the next features

    Documented how the visit summary, medication records, and calendar will reuse the same records.

  8. –

    FluBioscience and flu-bio.com

    Brand, domain, contact address, and this site.

  9. Next

    What’s next

    Connect the modules end to end, then start the conversations and usability tasks below. No fixed dates.

What we’re testing next

Planned None of this has started yet. Here is what we plan to check, roughly in this order.

QuestionHow we plan to check it
1 Is the problem real and frequent? Short conversations about how people prepared for a recent visit: what they wrote down, what they forgot, and why they stopped keeping notes. We’ll treat what people say and what they actually do as separate findings.
2 Is Yamma less work than a notes app? Using the same made-up symptom history, people organize it once in an ordinary notes app and once in a Yamma concept. We’ll compare time taken, missed details, entry errors, and requests for help. Small samples will be reported as exploratory.
3 Is a factual summary useful to the person reading it? Reviewers compare a summary built from a synthetic record with the original. They look for missing or added facts, readability, and whether the medication information is enough. This tests the format. It is not a clinical study.
4 Would people keep using it, and pay for it? “Looks nice” and “I’d use it again” are different answers, and we’ll record them separately. We’ll also ask about willingness to pay for visit-preparation features. Pricing hasn’t been decided.

When we share results, we’ll include the sample size, the method, and what didn’t work.

Questions

Can I download Yamma?

Not yet. Yamma hasn’t been released. The prototype is a development build that we test only with synthetic data.

Who is behind FluBioscience?

FluBioscience was started by Woojin Jung, a medical student at Chungnam National University College of Medicine, in Daejeon, South Korea. So far one clinician has reviewed our plan, and we intend to keep asking clinicians for feedback as the product grows.

FluBioscience is an early-stage project that isn’t incorporated and hasn’t raised outside funding. Project planning began in May 2026. The FluBioscience name, domain, and this site followed in October 2026.

Where does AI come in?

The plan is to use AI to turn a symptom conversation into a structured record, and later to help organize factual visit summaries. AI output is saved only after validation checks pass, and safety decisions are left to fixed rules. Today, AI-extracted records aren’t saved at all, because one of those checks isn’t set up yet.

Why do the screens look finished?

They’re concept designs based on our planning documents and filled with sample data. The working prototype is simpler. It covers manual entry, encrypted storage, and the diary. The labels on each section show which is which.

Contact

Questions about Yamma, the build log, or the tests we’re planning?

Get involved: Have a follow-up visit coming up, or work as a clinician or pharmacist? We’d like to hear from you. We won’t ask you to enter real health information into the prototype. Please don’t include health details in your email.

founder
Woojin Jung 정우진
studies
Medical student at Chungnam National University College of Medicine, now finishing the first year of the four-year MD program (after two years of pre-med).
building
Started planning Yamma in May 2026 and builds it alongside medical school.

So far one clinician has reviewed our plan, and we intend to keep asking clinicians for feedback as the product grows.

FluBioscience is an independent project and is not affiliated with or endorsed by Chungnam National University.

한국어 요약

FluBioscience는 증상 기록을 진료 전·중·후에 다시 쓸 수 있도록 돕는 Android 앱 Yamma를 개발하는 초기 프로젝트입니다. 2026년 5월에 기획을 시작했습니다. 현재 프로토타입은 수동 증상 입력, 기기 내 암호화 저장, 증상 다이어리와 강도 타임라인을 갖추고 있으며, 합성 데이터로만 시험했습니다. 진료과·병원 안내, 진료용 사실 요약, 처방 기록 확인과 복약·건강 캘린더는 계획 단계입니다. 아직 법인·사업자 등록 전이며, 외부 투자는 받지 않았습니다. 출시된 앱이 아니며, 진단·처방·응급 평가를 하지 않습니다.

정우진 · 창업자. 충남대학교 의과대학 의학과 1학년 재학 중. 2026년 5월 Yamma 기획을 시작해 학업과 병행하며 개발하고 있습니다. 지금까지 임상의 한 분께 기획 검토를 받았고, 앞으로도 계속 임상의 피드백을 구할 계획입니다.

FluBioscience는 독립 프로젝트이며 충남대학교와 제휴하거나 보증을 받은 것이 아닙니다.