instant.healthcare: technical documentation

Future Health Digital Innovation Challenge, statement 01, Male Reproductive Health. Prototype on synthetic data only, November 2026. The clinical protocol is a draft for specialist sign-off and must not be used with patients.

Demo: https://demo.instant.healthcare (guest access, no login). Video: https://demo.instant.healthcare/video

What it is

A private intake and routing service for men's reproductive health, in Arabic and English. A man answers up to 24 short questions by chat. A yes to an emergency question ends the interview at once with the emergency message. Otherwise each finding is routed to one of five destinations: urgent assessment, fertility services, an andrology or urology clinic, primary care, or self-care information. A clinician reviews every answer set and confirms every referral. The service screens and refers. It does not diagnose, treat or prescribe.

Architecture

patient (chat, Arabic / English / Arabizi / mixed)
  -> consent and data-use screen
  -> interviewer: phrases the question the engine chose     [planned: our language model; demo: fixed protocol text]
  -> safety sweep on every message: red-flag word lists in 8 languages
  -> answer reader: 3 readings must agree, each with a verbatim quote
  -> engine: deterministic evaluation of the protocol AT-MRH-001-AE
  -> read-back to the patient for confirmation
  -> fixed outcome message + one fixed message per destination
  -> clinician handoff (SBAR) with quotes, rules and destinations to confirm
every step -> append-only, hash-chained audit log

How a decision is made

1. Emergency questions come first. A yes to sudden severe testicular or scrotal pain, or to an erection lasting more than four hours, stops the interview immediately with the fixed emergency message: call 998 for an ambulance or go to the nearest emergency department.
2. Entry criteria: male at birth, age 18 to 65, and a visit about fertility or reproductive health. A man outside them is routed to primary care.
3. Every remaining finding is asked before deciding, so routing sees all of them. Asking more can only raise the outcome.
4. The outcome is the most severe level among the findings. Each finding names a destination, and the decision lists every destination reached, most severe first.
5. An unknown or contradictory answer is never read as no. On a finding that escalates, it escalates at that finding's level. Advice items add self-care text and never escalate.
6. If the readings disagree, the question is asked once more, then the case goes to a clinician.
7. Outcome and destination messages come only from the protocol. The interviewer may rephrase a question only behind a guard that rejects leading wording; it never writes an outcome or a destination message.

The language model cannot choose a question, an outcome or a destination. It reads answers, and deterministic rules evaluate what it read. Because a misread answer could still change which rule fires, uncertain or disputed readings go to a clarifying question and then to a clinician.

Routing table (draft, for the signing specialist)

Sources for the draft:

• WHO laboratory manual for the examination and processing of human semen, 6th edition, 2021.
• Schlegel PN et al. Diagnosis and Treatment of Infertility in Men: AUA/ASRM Guideline. Journal of Urology, 2021.
• ASRM Practice Committee. Definitions of infertility and recurrent pregnancy loss. Fertility and Sterility, 2020: evaluation after 12 months of trying, or after 6 months when the female partner is over 35. The draft asks about a partner aged 35 or older; NICE CG156 uses 36 or older. The signing specialist sets the threshold.
• EAU Guidelines on Sexual and Reproductive Health.
• NICE NG12, Suspected cancer: recognition and referral (testicular lump).

Clinical points the signing specialist will decide

• Varicocele: which men to refer (palpable, symptomatic, abnormal semen test, or trying to conceive).
• Blood in semen: persistence and age criteria for a faster route.
• Painful scrotal swelling with fever: same-day urology or emergency, and which signs (skin changes, crepitus, feeling very unwell) make it an emergency.
• An erection lasting more than four hours: emergency urology, with its own emergency wording.
• Medicines: which drug classes that affect fertility route to andrology or fertility services rather than primary care.
• Smoking and shisha: adding cessation support to the self-care information.
• A new testicular lump: urgent urology with ultrasound, and its time frame.

Safety design

• Deterministic code reading the protocol picks every question, outcome and destination. An independent second implementation of the evaluator is fuzz-tested against it.
• Three readings of every answer must agree, each with a verbatim quote from the patient; a quote not found in the message is rejected. In live use the three readers are two language models from different base families and a rule-based reader. In the demo they are three offline rule-based readers with different settings.
• Fail closed: when a model errors, refuses, truncates or times out, its reading counts as silence, never a guess. The empty reading is still written to the audit log, the three readings no longer agree, and the question goes to a clarification and then to a clinician.
• A safety sweep reads every message for red flags in eight languages, and a hit escalates. Concepts the protocol asks about directly (for example testicular pain) are handled by those questions, so a man answering "no" to one of them does not trigger the sweep.
• The patient can ask for a human at any point.
• Every protocol version is hashed and signed; live mode refuses an unsigned or changed protocol.
• The audit log is append-only and hash-chained, and any session can be replayed.

Privacy and data use

• A consent and data-use screen comes before the first question.
• Data minimisation: no name and no contact details are asked. The only question about the partner herself is whether she is 35 or older and the couple has been trying for 6 months or more; "not sure" is accepted and sends the answer set to a clinician.
• Health data stays in the UAE: live serving and every model endpoint refuse to start without an attested UAE cloud region (Federal Law No. 2 of 2019, Art. 13).
• Answers are used to route the request and for the safety audit, never for employment, insurance or any unrelated decision.
• For a pilot, set with the partner facility: clinician roles and authentication, retention and deletion periods, consent withdrawal, how a man chooses to share his referral, and a data protection impact assessment.

What is synthetic

Everything. The demo plays back recorded runs of the engine on synthetic sample patients we wrote. The test cases, patient phrases and word lists are our own work. No real patient data and no organiser data were used.

Results so far (development run, synthetic)

AT-MRH-001-AE has 78 protocol test cases, each with the exact expected outcome and destinations. 77 of them can be played by the simulator; the other tests a reader disagreement on one specific answer, which the simulator's scripted patients do not produce on demand. The development run used 20 of the 77 in all 16 writing styles, one run each, with the offline readers: 320 conversations.

Destination match was 95 percent in each language group, on the same 20 synthetic cases. All 16 differences come from one case, where the patient gives a contradictory answer about smoking. The readers disagree, so the conversation sends him to a clinician instead of straight to self-care information, which is the cautious direction. These results test the software against its own protocol; they are not clinical accuracy. The full run of every case in every style is part of our continuous integration gate, and that result is pending.

Assumptions

• A UAE-licensed urologist or andrologist reviews and signs the protocol; until then every clinical choice is a draft.
• It runs under a DoH-licensed facility's telehealth licence (Abu Dhabi does not license stand-alone telemedicine providers).
• Men write in Arabic, English, Arabizi or a mix.

Dependencies

• Python 3.12 or later; PyYAML; FastAPI and Uvicorn for the web app; Postgres optional.
• For live use: our own language models behind an OpenAI-compatible endpoint in a UAE cloud region (Azure UAE North or Central, or Core42). The demo needs no model.

Limitations

• The protocol is a draft and must not be used with patients until a specialist signs it.
• The demo uses the offline rule-based readers. The training data requirements for our in-country models are written; the models are not trained yet.
• No validation with real patients. Results on synthetic patients we wrote test the software, not clinical accuracy, and the same authors wrote the cases and the patient phrases.
• Not a registered medical device. Classification with the regulator comes before live use, and a clinician confirms every referral.
• The Arabic text needs certified medical translation with back-translation.
• Follow-up messages after the visit still use the shared text written for the urinary tract infection pathway and need pathway-specific versions before any pilot.

Open the demo · Watch the video