Displaying the report

The report from GET /v1/chatbot/report is medical content, and how you display it is part of what XUND verifies before production: the Implementation Guidelines require API content to be shown unmodified and name XUND's own Symptom & Illness Check App as the reference implementation partners are measured against in the acceptance test. This page describes how that reference integration renders each report field. Where the guidelines leave the presentation open, these patterns are not extra mandates — but they are what the acceptance test is calibrated against, so following them is the safe default unless you have a strong reason to diverge.

The score

Each illness in the report carries a score between 0 and 100 — and the reference integration never shows the raw number to the patient. It renders a small progress bar plus a three-tier qualitative label instead:

Two refinements make this robust: when the score is exactly 0 the indicator is hidden entirely, and the bar's fill is clamped to the 5–95% range so it never renders as completely empty or completely full. A raw number reads as a diagnostic precision the score does not claim; the qualitative rendering avoids that. The reference app also exposes the bar to assistive technology with progressbar ARIA semantics.

Urgency

A symptom check report carries an urgency object whose level is GREEN, ORANGE, RED, or NOT_APPLICABLE. The reference integration shows it as a prominent color-coded banner that replaces the report's main title — but only for symptom checks, and only for the three real levels; NOT_APPLICABLE is never displayed, and neither is urgency.method (it is diagnostic metadata, not patient content):

These are the reference app's colors. If you use your own palette, keep the green/orange/red meaning and verify contrast against your background.

On RED the banner copy directs the patient to emergency services, and the reference app additionally suppresses its own next-step service suggestions — nothing should compete with "seek emergency care now". The urgency.source object identifies the illness that drives the level; the reference app uses it to pick which illness's next-step services to offer on the non-red levels.

One interaction to copy: when the urgency banner is present, the reference app hides the per-illness treatmentShortInfo texts — the check-level urgency supersedes the per-illness advice, and showing both risks contradictory recommendations on one screen.

When the report has no illnesses

A report can legitimately come back with an urgency level but an empty illnessCategories array: the urgency classification derives its level from the patient's individual answers, so specific answers can raise it to ORANGE or RED even when the check could not identify any illness to report. Check for an empty illnessCategories before rendering the results list — don't show an empty list, and don't drop the urgency guidance, which in this state is the report's main content.

The explanation lives in urgency.reasons: an array of question/answer pairs — the answers (age, gender, the selected symptoms, individual question answers) that drove the classification. The reference integration keeps the urgency banner and, when illnessCategories is empty and urgency.reasons is non-empty, renders a "no results could be identified" screen in place of the illness list: an integrator-authored heading and description, followed by each reason's question with the patient's answer beneath it.

Treatment advice (treatmentShortInfo)

treatmentShortInfo.text ("Treat at home", "Consult with a doctor", "Go to hospital immediately", ...) is shown directly under the illness name. The field also carries a textColor hex value, but the reference integration deliberately does not apply it as-is: it keys on the optional treatmentShortInfo.recommendationType field — HOME, DOCTOR, or HOSPITAL — and colors the text from its own accessible palette (home care in green, doctor consultation in orange, hospital in red), falling back to the raw textColor only when recommendationType is absent. Treat textColor as a hint, not a contract: whatever color you render, verify it meets contrast requirements against your background.

Warning signs

When the report's warningSigns array is non-empty, the reference integration shows a prominent "potential emergency" call-out — the local emergency number plus the names of the triggered warning signs — before or above the regular results. This is additive: the report content still renders below it. Remember that the Implementation Guidelines make warning-sign display in the report mandatory, and warning signs also surface mid-flow as EMERGENCY questions — see Advanced question UI.

Quick solutions

Each illness carries quickSolutions — self-care suggestions that can quickly improve the patient's state. The reference app renders them as simple cards per illness: the solution's name as the card title and its description as the body (an icon URL is also available). They are supporting content, not results — keep them visually subordinate to the illness list.

Factor scores

factorScores explains why the results look the way they do: a title plus three entries (profile, symptoms, other), each with a localized text and a machine-readable excludeInfo (EXCLUDING, NOT_EXCLUDING, or UNKNOWN). The reference integration renders each entry as a row: an icon chosen by excludeInfo next to the text. The texts contain simple HTML markup (<b> emphasis), so render them as HTML rather than plain text. The explanation is deliberately qualitative — never convert it into numbers or percentages. For illness checks, the reference app gives the checkedIllness's own factor scores a dedicated section, since that illness is what the patient asked about.

Text you must write yourself

The API provides no display copy for three things on this page: the urgency banner's per-level wording (including the local emergency number on RED), the score-tier labels ("Very likely" / "Likely" / "Possible"), and the warning-sign call-out. These texts are integrator-authored — write them yourself and localize them to the check's language. The content-integrity rules in the Implementation Guidelines apply to API-provided medical content, not to this UI copy.

Compliance patterns worth copying

Three habits of the reference integration round out a report screen:

• A fixed medico-legal footer on every report — the report's legal disclaimer is always visible, not tucked behind a link, as the Implementation Guidelines require for legal data.
• The check id displayed on the report — it is the only handle on the check (see After the check), and showing it lets support and medical staff reference a concrete check.
• Screen-reader announcements — when the report renders, its content is announced to assistive technology, and interactive indicators (like the score bar) carry proper ARIA roles.