Rxly.ai

An AI consultation assistant that analyses the visit in real time and produces the chart. It took a month from idea to submission. I designed and built it alone, and worked out the clinical requirements with physicians practising in the US. It was submitted to Anthropic’s Built with Opus 4.6 Claude Code hackathon and reached the final 230 out of roughly 13,000 applicants, where I was the only Korean.

The problem

A large part of a consultation is not the consultation but the record of it. The clinician writes the chart while seeing the patient, and finishes the paperwork after they leave. None of that time is spent on the patient.

A tool that only transcribes solves half of it. A transcript is not a chart, and turning the transcript into a chart is where the work actually is.

The pipeline

Rxly.ai treats everything from the conversation to the EMR record as one path.

1. Transcription and diarisation — the visit is transcribed live by STT tuned for medical vocabulary, with clinician and patient speech separated automatically.
2. Clinical insight — key findings, risk signals and an action checklist are generated while the consultation is still happening. The point is that they are usable during the visit, not after it.
3. Differential diagnosis — an evidence-based differential is generated automatically, with ICD-11 codes attached.
4. SOAP note — a structured draft record is produced and handed to the EMR over FHIR R4. Exporting to a standard rather than a house format is the only condition under which this can enter a hospital system at all.

How answers are grounded

Clinical information generated by an LLM is unusable without provenance, so answers are grounded by retrieval over five public medical sources — OpenFDA, ClinicalTrials.gov, DailyMed, PubMed and Europe PMC.

There are five because their coverage differs. Drug labelling is in DailyMed, post-market safety signals are in OpenFDA, active trials are in ClinicalTrials.gov, and the literature splits between PubMed and Europe PMC. With only one source wired in, questions outside that source’s coverage return no evidence at all.

Clinical requirements

An engineer can decide the feature list but cannot decide what is clinically useful. The requirements were worked out with physicians practising in the US, and one thing that changed as a result was the decision to surface insight during the visit rather than after it.

Security

Handling clinical data makes security a requirement rather than a feature. Taking HIPAA as the reference standard, the build applies AES-256-GCM encryption, audit logging, CSP, HSTS and rate limiting.

Audit logging went into a hackathon entry because a product like this only becomes usable if it can answer “who saw what, and when” — and that is not something bolted on afterwards.

Result

• Final 230 of roughly 13,000 in Anthropic’s Built with Opus 4.6 Claude Code hackathon, and the only Korean among the finalists
• One month from idea to submission, designed and built alone

Limitations

• It was built during a hackathon and has not been clinically validated. Real clinical use would require separate validation and a regulatory path.
• Transcription accuracy is bounded by the STT it runs on. Medical-vocabulary tuning was applied but not measured separately.
• The FHIR R4 integration follows the standard; interoperability with a real hospital EMR was not tested.

Demo

Submission video · rxly.ai