Medical doctor building useful software and exploring new ideas.
Bangkok, Thailand · Software · AI & data · Education · Research · Creative technology
Tools · GitHub activity · Projects · Approach · Collaboration
I'm Enk, a medical doctor based in Bangkok, Thailand. I build tools to make complex information easier to understand, reduce repetitive work, and turn ideas into working projects.
Medicine shapes how I think, but not everything I build is medical. My interests span software, AI, data, education, automation, and interactive applications.
More about me and my interests
My background is in clinical medicine and medical education. That perspective makes me interested in how people work with complex information: understanding evidence, learning unfamiliar concepts, and making decisions when time and resources are limited.
I approach software as a way to work on those problems directly. Sometimes that means a tool for teaching or research; sometimes it means automating a repetitive task, organizing scattered information, or building something interactive simply to explore an idea.
I'm continuing to develop my skills in programming, AI, data analysis, and software design through study and hands-on projects. I value clear explanations, thoughtful interfaces, and tools that people can understand—not just operate.
| Area | Questions and ideas I like exploring |
|---|---|
| Software and automation | How can a small, well-designed application remove repetitive steps, connect fragmented workflows, or make an everyday task easier? |
| AI and data | Where can models and data analysis genuinely help? How should their outputs be evaluated, explained, and kept open to human review? |
| Education and knowledge | How can visual explanations, interactive exercises, and better-organized information make difficult subjects easier to learn and revisit? |
| Research and scientific tools | How can literature discovery, data processing, and reproducible experiments make research easier to inspect, repeat, and build upon? |
| Interfaces and creative applications | How can dashboards, visualization, and interactive experiences make software clearer, more engaging, and more enjoyable to use? |
Healthcare is an important application of these interests, not their only destination.
Python · TypeScript · JavaScript · React · FastAPI · Three.js · Docker · GitHub Actions
Tools used across my projects—not ratings of expertise. I choose tools to fit the problem and continue learning as the work develops.
Where these tools fit
| Area | Examples from my projects |
|---|---|
| Languages | Python, TypeScript, JavaScript |
| Web applications and APIs | React, FastAPI |
| Interactive graphics | Three.js, OpenSeadragon |
| Packaging and automation | Docker, GitHub Actions |
| Testing and evaluation | Automated tests, reproducible experiments, documented acceptance criteria |
This is a view of the tools used in these repositories, not an exhaustive skills list or a claim of equal expertise in every technology.
Provider-reported activity and public-repository summaries. Language proportions describe repository code, not proficiency. These widgets are cached and may differ from GitHub's own totals.
Practical applications, information workflows, creative experiments, and research.
PathLab's desktop companion: Forge prepares supported slide datasets locally.
Project overviews, useful starting points, and limitations
These projects show different sides of my work: practical applications, information workflows, creative experiments, and research.
Tools for working with high-resolution digital microscope slides. Viewer provides private review and browser-based sharing of published slide views. Forge is its local desktop companion for inspecting supported slide datasets, preparing them for viewing, and uploading prepared packages.
Explore this for: image-heavy applications, local-to-web workflows, and privacy-conscious sharing. The projects are in development; their documentation defines supported features and readiness.
A prototype for finding and organizing pathology research literature. It gathers paper records, removes duplicates, distinguishes preprints from peer-reviewed publications, and produces structured digests. A separate workflow scouts free medical learning events.
Explore this for: information retrieval, source checking, deduplication, and scheduled workflows. Discovery and summarization are starting points for review—not substitutes for evaluating the underlying evidence.
An interactive 3D duck-race randomizer built with React and Three.js. It brings together a browser-based application, a rendered race track, and visual details such as duck models, labels, and finish effects.
Explore this for: browser graphics and playful interaction design. It represents the more experimental side of my work, outside healthcare and research.
A research framework for investigating whole-slide image compression. It uses matched comparisons, explicit acceptance criteria, and complete storage accounting to test ideas rather than assume that a smaller file is automatically a better result.
Explore this for: experimental design, image-processing evaluation, and reproducibility. The public repository contains code, synthetic fixtures, specifications, tests, and aggregate reports; it makes no clinical validation claim.
Explore all public repositories →
Each repository is the source of truth for setup, intended use, licensing, and limitations. A public repository or passing automated test does not, by itself, establish production or clinical readiness.
Explore all public repositories →
Problem first. Clear interfaces. Practical resource use. Evidence and limitations visible.
My approach and what I'm learning
Start with the problem, not the technology. I want to understand who will use a tool, what is difficult today, and what an improvement would look like. A simpler workflow can be more valuable than a longer feature list.
Make the useful parts approachable. I care about readable interfaces, clear documentation, and sensible setup requirements. Storage, bandwidth, compute, and maintenance effort are part of the design—not problems to leave until the end.
Keep evidence and limitations visible. I aim to make assumptions explicit, test important behavior, respect privacy, and distinguish working features from plans. For research and AI, I care about fair comparisons, reproducibility, and knowing when human review is still needed.
I'm interested in making the whole path from idea to useful application more understandable: organizing data, designing software, evaluating models, and maintaining a system after the first prototype works.
Questions I keep coming back to include how to make AI useful without obscuring its limitations, how to design interactive learning experiences, and how to build capable tools with modest infrastructure. These are directions for learning and future work, not promises about features already available.
I welcome practical ideas, thoughtful feedback, and perspectives from different disciplines. For project-specific questions, start with the relevant repository's README and issue tracker.
Using a project, contributing, or exploring a research idea
I welcome thoughtful feedback, practical problems, and perspectives from people with different backgrounds. Useful contributions can include a clearer explanation, a reproducible bug report, a usability observation, or a better way to test an idea—not only code.
Using a project? Start with its README for setup and supported workflows. For a non-sensitive question or bug report, use its issue tracker when available and describe what you expected, what happened, and the relevant environment.
Building on a project? Check its license, existing issues, and contribution guidance. Focused changes, documentation improvements, and tests are useful ways to participate.
Exploring a research idea? Make the question, assumptions, comparison, and evaluation method clear. I'm interested in ideas that connect disciplines and produce something others can understand, evaluate, or use.
Please keep personal data, patient information, credentials, and sensitive security details out of public issues. Use synthetic examples where possible and follow the repository's private reporting guidance for security concerns.
Please keep patient information, personal data, credentials, and sensitive security details out of public issues.
About the visual widgets
Icons: Skill Icons. Stats, language charts, and repository cards: GitHub Stats Extended. Contribution history: GitHub Profile Summary Cards. The workflow diagram is an original, static SVG stored in this repository; it makes no network requests of its own.
Light and dark image variants are provided. These external services receive the public username or public repository names in the image URLs; no personal access token is embedded or required by this README.
Widgets can be cached, delayed, rate-limited, or temporarily unavailable. Repository links and expandable descriptions remain available independently. Activity counts are not a measure of software quality, and language proportions are not skill scores. Repository documentation defines current scope, readiness, licensing, and limitations.