The overview

When the question loop returns a FUNCTION question with detailedType: "OVERVIEW", the patient reviews their symptoms: fetch the overview, let them edit it, then confirm it.

Fetching the overview

GET /v1/chatbot/overview returns two symptom lists for the ongoing check:

{
  "addedSymptoms": [
    {
      "id": "5e63f95e-ef3b-42ce-9027-ff6e021e19ef",
      "name": "Abdominal pain",
      "actionInfo": {
        "title": "Do you want to erase or edit the symptom?",
        "actions": [
          { "title": "Edit", "type": "EDIT" },
          { "title": "Delete", "type": "DELETE" }
        ]
      }
    }
  ],
  "suggestedNotAddedSymptoms": [
    { "id": "78ea9475-7630-4947-89a5-d7d5d8ee3eed", "name": "Diarrhoea" },
    { "id": "86181145-376a-47ec-9a00-f84d4bc3d15d", "name": "Nausea" }
  ]
}

Showing this screen is not optional: the Implementation Guidelines require that all added and suggested symptoms are visible to the patient, and that the patient can add, edit, or remove symptoms from the overview before the check moves on.

Editing from the overview

The mutation requests at a glance:

// POST /v1/chatbot/overview/symptoms — ids from suggestedNotAddedSymptoms
{ "symptomIds": ["78ea9475-7630-4947-89a5-d7d5d8ee3eed", "86181145-376a-47ec-9a00-f84d4bc3d15d"] }

// PATCH /v1/chatbot/overview/answer — same body shapes as POST /v1/chatbot/answer
{ "questionId": "e38f994b-6464-4c49-8b11-28687031d46d", "answer": { "id": "ebf2b5b3-1d42-40ec-bba0-6a43f9da5b5a" } }
{ "questionId": "183d2cd6-567f-416b-befb-065500cbaf57" } // change to a skip

// PATCH /v1/chatbot/overview/answer/batch — an array of those bodies (max 100)
[
  { "questionId": "e38f994b-6464-4c49-8b11-28687031d46d", "answer": { "id": "ebf2b5b3-1d42-40ec-bba0-6a43f9da5b5a" } },
  { "questionId": "183d2cd6-567f-416b-befb-065500cbaf57" }
]

DELETE /v1/chatbot/overview/symptoms/5e63f95e-ef3b-42ce-9027-ff6e021e19ef

The delete takes no body — the symptom id is the path parameter. The symptom-related questions endpoint returns the Question objects asked about one added symptom, with isAnswered and the selected options marked — use it to build the "edit this symptom" screen. Requesting it for a symptom that is not part of the check fails with status code 404 (SYMPTOM_NOT_FOUND).

The batch edit is not atomic. PATCH /v1/chatbot/overview/answer/batch accepts up to 100 elements (larger payloads are rejected with status code 400) and applies them one by one, in order. If one element fails, the API responds with status code 500 — but the edits before the failing element remain applied. After a batch failure, do not blindly re-send the same payload; re-read the check's state (for example with GET /v1/chatbot/status or the overview endpoints) and reconcile first.

The trap: confirm requires a prior fetch

POST /v1/chatbot/overview/confirm fails with status code 403 and customType: "OVERVIEW_CAN_NOT_BE_SKIPPED" unless GET /v1/chatbot/overview has been called for the check first.

This is deliberate: XUND is a certified medical device and the patient must have had the chance to review their symptoms. Always fetch and display the overview, then confirm. After a successful confirm, the question loop resumes — go back to GET /v1/chatbot/question.

The overview can come back

Confirming the overview does not retire it for the rest of the check. After the confirm and the after-overview survey questions, the check evaluates its results — and if they are not specific enough, it asks a SINGLE_SELECT question with detailedType: "DISCLAIMER" ("your symptoms aren't specific enough — would you like to add more symptoms?") whose two options are add more symptoms and continue. If the patient chooses to add, the check loops back through body-part selection and a symptom survey for the new symptom, asks a CHECK_IF_ADD_MORE_SYMPTOMS question — and then raises a new OVERVIEW FUNCTION question, which must be fetched and confirmed again exactly like the first one.

The practical consequence: do not implement the overview as a one-shot phase flag ("overview done, never show it again"). Handle FUNCTION questions statelessly — whenever GET /v1/chatbot/question returns one, run its flow, however many times that happens in a check.