An account of what MedicalIntake sets out to do, how it decides what to ask a patient, the limits it observes, and which parts of it are working today.
MedicalIntake is concerned with one question: how completely, and how accurately, what a patient knows reaches the people treating them.
It works in the period before triage, rather than in triage itself.
When a patient self-presents and waits, their account of the problem is at its most complete: the symptoms are recent, and whoever came with them is usually still present. Waits of 45 minutes or more are common, though the figure varies considerably between departments and across the day. Very little of that account is recorded during the wait, because the triage assessment that follows necessarily condenses history-taking into a few minutes, at the start of a shift that may already be stretched.
The consequence falls on the clinician as much as on the patient. Since no shared record exists of what the patient has already described, the same history tends to be taken again at each handover. Whether that repetition is redundancy or a useful check is a question we would rather put to clinicians than answer ourselves.
What the system proposes is fairly modest. It uses the waiting period to collect and structure the history, so that the clinical time which follows can be spent on assessment.
Reception registers the patient and issues a single-use link. The patient opens it in a phone browser; there is no application to install and no account to create.
The conversation that follows:
Three components constrain the questions, so that the language model is not the sole author of what a patient is asked.
The link is not bound to the patient's identity, so any person holding it can complete the intake from any device. Three patterns follow from this:
The third makes en-route triage possible in principle. An ambulance crew, or a nurse at a rural clinic, could complete the intake during transport, so that the receiving department holds a structured summary, and red-flag detection has already run, before the patient arrives. We should be clear that this is an implication of the design rather than a tested workflow: no ambulance service uses it, and we have not trialled it.
The patient interface is translated into 40 languages, among them te reo Māori, Samoan, Tongan, Fijian and Hawaiian. The conversation itself follows the language the patient selects, since the model is instructed to answer in it. The quality of that output has not been reviewed by native speakers, and we would welcome that review; see section 5.
The system runs an open-weight language model on self-hosted hardware, which is the configured default rather than an option. Patient data therefore does not pass to a third-party model provider. A cloud provider is supported in the code, but it is not what a New Zealand deployment would use.
The following boundaries are deliberate. We would treat movement across any of them as a fault rather than a feature.
Diagnosis. The system collects and structures what the patient already knows. Clinical interpretation remains with the clinical team.
Advice. No treatment guidance is offered to the patient at any point.
Triage. Vital signs, physical observation, and clinical judgement remain the nurse's. The system occupies the time before triage; it does not alter the assessment itself.
Workflow. No existing clinical step changes. The system operates in a period that at present carries no clinical activity.
Installation. A link and a browser are sufficient. Nothing is installed on a patient's phone.
The system is built and maintained by one developer. It is not in clinical use, and it has had neither an ethics review nor a clinical safety review. The table below separates what runs today from what has been designed but not yet written.
| Component | Status |
|---|---|
| Reception check-in and link issue | Built |
| Patient conversation in a phone browser | Built |
| Clinical knowledge graph and SNOMED CT matching | Built |
| Red flag detection and staff alert | Built |
| Nurse, doctor and reception views, updating live on the staff board | Built |
| Doctor role, able to correct the clinical state and add a clinical note | Built |
| Delivery of the link by email | Built |
| Interface translations, 40 languages | Built |
| Admin console: replays a past conversation turn by turn, and simulates a next turn without involving a real patient | Built |
| Pharmacist view. The system currently has four roles: administrator, reception, nurse, and doctor | Designed |
| Delivery of the link by text message. The code writes the message to a file rather than sending it | Designed |
| Automatic flags for drug interactions | Designed |
The question catalogue contains 438 items, of which roughly 75% were generated automatically and retain a placeholder rationale together with an unconditional trigger.
A repair tool exists, but its output requires clinical review before it enters the catalogue. We regard this as the principal constraint on the system's clinical credibility at present.
Clinical perspective would be worth more to this project at present than funding. The following are listed in order of value to us.
One open question, rather than a request. Everything above concerns information moving from the patient to the clinician. We suspect the reverse direction is at least as weak: patients often leave a consultation unable to recall much of what they were told. We have built nothing for this, and we are not certain it belongs in the same system, because relaying a clinician's instructions back to a patient sits on the other side of a line this project keeps: the intake only structures what the patient already knows, and never originates clinical content. If work already exists in this area in New Zealand, we would rather hear about it than duplicate it.
MedicalIntake is not intended as a billing or administrative instrument, and it collects nothing that a clinician cannot use.
The patient is asked one question at a time, in their own language. The clinician is given structure. A design choice that served one of those at the other's expense would, in our view, be the wrong choice.
The same reasoning accounts for this page. An early-stage clinical tool that overstates its capability creates risk for the people who would rely on it, so the table above sets what is missing beside what works.
Clinical perspective, whether from nurses, doctors, or anyone who works with patient flow, is more useful to us at this stage than anything else. We are not selling anything, and a conversation would be welcome.