DEV Community

Fuyuto Miyake
Fuyuto Miyake

Posted on

How a Frontline Doctor Entered a 4,800+Participant AI Hackathon in Dubai Alone and Won, Revealing the Future of Healthcare

Driven by a genuine desire to change the challenges faced in clinical practice, I began teaching myself programming just six months ago.

I then entered a 4,000-participant AI hackathon in Dubai—completely on my own—and won 1st prize in my division.

My name is Fuyuto Miyake, and I am a junior resident physician.

Hackathons are typically team-based competitions involving multiple engineers, but in my case, I handled everything—from planning and design to implementation and the final presentation—entirely by myself.

In this article, I share:

• Why a frontline doctor decided to build a product
• The strategy that took me from self-taught development to winning the competition
• And the future of healthcare illuminated by the stage of a 4,000-person hackathon in Dubai

I’ve met many clinicians and students who wish they could take on challenges but feel held back by a lack of funding or environment.

That is exactly why I am publishing this article for free.

If this can push even one person to take their first step, that will be the greatest outcome.

The technical details will be released separately; here, I focus on the concepts and strategy.

What Is a Hackathon?

A hackathon is essentially “a rapid development sprint where ideas are turned into working products in a short period of time.”

Normally, engineers, designers, and presenters form a team and divide roles:

discussion → implementation → documentation → presentation

But at this hackathon in Dubai, I handled every step entirely on my own:

Concept building, requirements definition, design, implementation, UI, demo creation, slide preparation, and the final pitch.

I completed everything solo.

“Why was that possible?”

The answer to that question is one of the core themes of this article.

I’ll explain it in detail below.


Why I Joined the Hackathon

In one sentence:

I wanted to prove my ability to build real solutions and demonstrate a new form of healthcare to the world.

As a resident physician, I’ve encountered countless problems that people dismiss as “inevitable”:

  • Endless nighttime crowding in emergency departments
  • Psychiatric patients and older adults being transported repeatedly
  • The conflict between clinicians who foresee functional decline during long hospitalizations and patients who still hope for recovery

These are not problems that can be solved through the effort of healthcare workers alone.

I felt discomfort with a system where all we can do is complain and accept the status quo.

Through my administrative training, I realized something important:

The barrier isn’t the laziness of healthcare workers—it’s the structure of the system, which makes it inherently difficult for policymakers to understand what’s really happening on the ground.

This gap between frontline reality and administration is, I believe, the root cause of why healthcare problems remain unresolved for decades.

And I became certain:

Technology—especially AI—can fundamentally change this structure.

But I also recognized another gap:

A gap between medicine and engineering.

That is why I want to become a translator between frontline care, public administration, and technology.

So why a hackathon?

Because even if you understand the issues, even if you have ideas and a vision,

systems do not move without demonstrated results.

That is why I decided to take on the challenge.

To prove. To show. To move the system.

To Dubai—into a 4,000-participant AI hackathon.


My Hackathon Theme

I worked on improving triage efficiency in low-acuity emergency care.

While I drew inspiration from the guidelines of the Japanese Association for Acute Medicine, the real issue in practice is that text-based triage has fundamental limitations.

In emergency settings, physicians initially judge patients by:

what they see, what they hear, changes in breathing, and subtle shifts in facial expression.

In other words, true evaluation is multimodal, not text-driven.

So I chose to build a system that automatically extracts vital signs and symptom cues from video and estimates acuity.

My aim was to digitally reproduce the real-time nuance of the clinical encounter—something text alone cannot capture.


Overview of the Product

Why video + smartphone?

Because practical deployability in real clinical environments matters more than anything else.

Specialized hardware and expensive devices rarely spread in medical settings where investment culture is limited.

Hospitals face repeated reimbursement revisions and unstable revenue models, making long-term investment difficult.

So I focused on creating a system that works with a single smartphone—the one every hospital already has.

This drastically lowers the implementation barrier.

Below are a few screens from the application.

(The backend Opus workflow design is not shown here.)

1. Press the start button

2. Record a video with the smartphone

3. Enter the chief complaint at the bottom

4. Vital signs are detected and sent to the Opus Agent Workflow

5. The triage result generated by Opus appears on the smartphone


Why I Was Able to Win Alone

This time, I entered with the clear intention to win—so I designed a strategy from the very beginning.

1. Analysis

I studied technology trends by reviewing GitHub’s latest repositories and past award-winning projects.

Through iterative discussions with ChatGPT, I explored which technologies were reproducible and which fields were rapidly growing.

I concluded that this year’s dominant trend was multimodal AI, which aligned perfectly with the theme I wanted to build.

So I conducted deeper research into technologies with high applicability.

2. Design

I invested the most time into design.

Out of the one-week preparation period, I spent five full days just on system design.

I prioritized the balance of feasibility × societal impact × technical novelty over rapid implementation.

A solid architecture dramatically reduces rework during development.

3. Development

Modern app development rewards design capability more than raw coding skill, especially when leveraging AI tools.

I used Claude Code and Codex to translate requirements into code, refining detailed behavior through natural-language specifications.

The most time-consuming part was building the workflow in Opus, which, while highly auditable and consistent, also has a complex configuration structure.

To accelerate iterations, I used:

  • Comet (AI browser) for automated UI operations, and
  • Screenshots + ChatGPT for step-by-step workflow refinement

allowing rapid cycles of design → revise → adjust.

4. Preparing the Presentation

Since I also needed to prepare the pitch alone, I had limited time.

To streamline the process, I:

  1. Fed the README into an AI model—preloaded with the judging criteria—to auto-generate a draft slide script

  2. Used the Majin Prompt method to create slides + speaker notes in about 30 minutes

  1. Practiced with Google AI Studio, receiving voice feedback to optimize delivery and clarity

Why My Project Stood Out (Compared to Other Participants)

Many teams focused on efficiency tools or workflow automation.

Even with 4,000 participants, few projects aimed to reshape societal structures.

There were projects on environmental or energy challenges, but many remained abstract, failing to connect deeply with the real pain points of users.

Even when teams presented numbers or statistical models, many struggled to translate them into practical solutions—revealing difficulties at the design stage.

In contrast, I had spent years observing the structural issues in everyday clinical care and continuously thinking about how to solve them.

This allowed me to set a theme quickly and strike a balance between social impact and feasibility.

I believe what was truly evaluated was not just technical skill, but my ability to translate frontline pain into product design.


Next: Toward Real-World Implementation

Beyond this project, I am working on several applications in parallel.

My goal is to build deployable solutions that address systemic problems in healthcare.

The first step is to test the app in real clinical environments, gather feedback, evaluate accuracy, and publish the results to establish international credibility.

After that, I plan to collaborate with public health agencies and expand the implementation based on proven outcomes.


Closing Thoughts

Healthcare challenges are not just the concerns of healthcare workers.

They affect patients, families, local communities, the economy, and the future of the nation.

I want to build a society where frontline clinicians do not merely endure problems, but where they can discuss, propose, and implement solutions themselves.

As a first step, I aim to create products directly from clinical experience and demonstrate that change is possible.

And in the long term—

I want to empower every healthcare worker to become an innovator.

I will continue shaping the systems needed to make that future real, together with experts across disciplines.

Top comments (0)