Building Healthcare · Technology & practice
A Surgeon Builds
Designing useful technology around clinical work: start with a real task, make the next step clear, and keep responsibility visible.
Published by GeNext MedEd Foundation
In this article
Begin with the work
A surgeon learns to notice where a process becomes difficult: a missing record, an unclear instruction, a decision postponed because the right information has not arrived. These moments also offer a starting point for building technology. Before choosing a screen, a platform or an AI model, there is a simpler question: what should become easier for the person using it?
Building a clinical service extends beyond the consultation and the operation. It includes helping a patient find the right centre, helping a colleague understand a referral and helping a trainee return to a lesson when it matters. A useful digital tool should serve one of those tasks clearly. Its value lies in the work it helps someone complete.
This essay proposes a practical approach to clinician-led design. Websites, assisted registration and remote ENT consultations are used as design examples. It does not claim that every example is an operational Santosh service, or that any tool described has demonstrated clinical benefit.
Give the first version one job
A broad ambition can produce a crowded first screen. A patient arrives to find a clinic and encounters announcements, multiple brands, an account request and a long list of services. Each item may have a reason to exist, but the patient still needs an address, a time and a reliable way to contact someone.
The first version should have a small, observable purpose. For a clinic page, that might be finding the correct location and requesting an appointment. For a teaching resource, it might be opening one chapter and returning to the same place. For a referral tool, it might be delivering a clear question to a named receiving team.
Write that purpose in ordinary language. Then remove the elements that compete with it. More features can be considered after the basic task works for the people who will actually use it.
Observe the task
Watch where someone needs help, repeats a step or stops.
Build a small version
Make one complete journey visible and testable.
Review and revise
Check completion, errors and the need for assistance.
Three screens, three different responsibilities
A public website, a registration kiosk and a clinical consultation interface may share colours and typography. Their responsibilities are different. Treating them as interchangeable can obscure the boundary between information, administration and clinical care.
| Design example | Useful first task | Boundary to make visible |
|---|---|---|
| A clinic website | Find the right centre, available service and contact route. | Clearly label planned services and explain when an appointment request is confirmed. |
| An assisted registration kiosk | Record the minimum necessary administrative details, with staff help available. | Registration is not clinical triage. Provide a direct route to staff for urgent concerns. |
| A remote ENT consultation interface | Help an appropriate consultation take place and leave a documented next step. | The clinician determines suitability, examination limits and the need for in-person assessment. |
These examples are proposed design exercises, not a catalogue of deployed products. A prototype can show how a journey might work; clinical use requires appropriate professional, technical and regulatory review for its intended purpose.
Design for the person holding the phone
A design can look composed on a large monitor and become exhausting on a phone. Three narrow columns force the reader to enlarge the page. A long paragraph can hide the only action that matters. A button may look attractive yet give no clue about what happens after it is pressed.
Readable text, generous spacing and descriptive actions deserve attention before decoration. “Request an appointment” is more useful than “Continue” when that is the action being taken. The confirmation should say whether the request has merely been received or whether a time has actually been reserved.
People also need ways to recover. They may enter the wrong number, lose the connection or be unable to read the available language comfortably. A useful service allows corrections, preserves an understandable next step and offers human assistance. A digital route should not become the only route into care.
One appointment request, from beginning to end
Imagine a patient opening a centre page on a phone. This example tests the design of an administrative journey; it is not a real patient report.
- Choose the centre
The page names the location and distinguishes available services from future plans.
- Understand the request
The form explains which details are needed and how the care desk will respond.
- Receive a clear status
The confirmation distinguishes “request received” from “appointment confirmed”.
- Keep a way back
The patient can find contact details, correct a mistake or ask for help without repeating the whole process.
Working with AI still requires judgement
AI tools can be used to explore wording, compare layouts and help produce a prototype. The clinician brings the intended task and the context in which it will be used. Technical collaborators bring skills needed to assess implementation, security and reliability. None of these contributions removes the need to check what has been produced.
A convincing screen is not evidence that the underlying system works. A successful demonstration does not establish that access permissions, data handling or failure recovery are correct. A polished clinical explanation may still contain an error. Review must address the function and the consequences, as well as the appearance.
WHO’s guidance on AI for health places ethics, human rights and accountability at the centre of design and use. [1] For the approach proposed here, that means giving human review a defined place, explaining the tool’s limits and keeping clinical responsibility identifiable.
The work behind the screen
Before a form is published, someone must know who receives it. Before a result appears, someone must know who checks it. Before a reminder is sent, someone must know what happens if the patient replies with a concern. These are service decisions, even when software carries them out.
A small team needs a clear account of ownership: who maintains the content, who responds to requests, who can correct a record and who investigates a failure. If a tool depends on one person remembering every unfinished task, the screen has changed more than the process.
Maintenance should be part of the original design. Clinic details change. Staff move. Links break. A responsible service needs a way to update information, identify an outdated version and withdraw a function that is no longer dependable. Publishing is the beginning of that responsibility.
Measure the task, not the excitement
A useful early review can be modest. Ask people to attempt the intended task without coaching, observe where they hesitate and record whether they complete it. Include users with different levels of confidence and people who need assistance. Then revise the design and repeat the same task.
For an appointment request, possible measures include completion, duplicate entries, time spent seeking help and whether the receiving team responds as intended. For a learning page, ask whether a reader can find the chapter, understand its publication status and return to it later. These are proposed checks, not reported results.
Clinical effectiveness is a separate question. Easier navigation or higher usage does not by itself show better diagnosis, safer treatment or improved outcomes. Any claim of clinical benefit needs evidence appropriate to that claim.
Build with the people who carry the work
The surgeon’s perspective can identify a problem worth solving. It cannot represent everyone who will use the solution. Reception staff, nurses, trainees, patients, caregivers and technical colleagues encounter different parts of the same process. Their feedback should shape the design while changes are still easy to make.
The most useful contribution may be a simple observation: this question is asked twice; this label is unclear; this step has no owner. Listening to those observations helps turn an individual idea into something a team can maintain.
A surgeon builds well by keeping the purpose close to the work. Start with a real difficulty. Make a small response. Test it honestly. Revise it with the people who depend on it. The aim is a service that makes the next step clearer and leaves responsibility easier to find.
Publication notes
Author: Dr Bhushan Kathuria. Published by GeNext MedEd Foundation, 25 October 2026. This is a professional perspective, not a clinical validation study or a peer-reviewed research report. Examples and proposed measures are illustrative. The author is associated with Santosh Advanced ENT Healthcare, GeNext MedEd Foundation and GeNext Connect. Text preparation and original vector illustrations were assisted by AI.
Reference
1. World Health Organization. Ethics and governance of artificial intelligence for health: WHO guidance. Geneva: WHO; 2021. Read the WHO guidance ↗
Cite this article
Kathuria B. A surgeon builds: designing useful technology around clinical work. GeNext MedEd Foundation; 2026. https://www.genextmed.org/perspectives/a-surgeon-builds
Version 1.0 · © 2026 Dr Bhushan Kathuria. No DOI has been assigned.