Symptom capture before a consultation

A structured way for a person to describe what is wrong before anyone clinical looks at it: a guided set of questions about symptoms, duration and context, whose answers travel with the request for care. It sits at the front of a symptom checker, a triage service or a telehealth booking, and its output is a summary a person can check and a clinician can read.

The first account of a problem shapes everything after it. Captured well, it lets a service route the person to the right level of care, saves the consultation from beginning at zero, and gives the clinician a record of what the person said in their own terms. Captured badly, it produces false reassurance or unnecessary alarm, and a person who has already answered twenty questions will not answer them again with the same care.

Because the same questions are asked of people who are frightened, in pain or unwell, the design of the questions is a clinical decision as much as a product one.

A symptom capture step sits close to the boundary between information and advice, and the products in this space describe themselves carefully. Ada's help pages say it cannot provide a diagnosis and is not intended to replace a doctor; Infermedica's triage interview ends in a level of care, alongside basic information about the most probable conditions. Where an output reads as a recommendation, regulators take an interest: the FDA's guidance on clinical decision support turns on whether a professional can independently review the basis for what software suggests.

The step also has to fail safely. Red-flag symptoms need an exit to emergency care that appears before the questions finish, not after; the NHS service manual's care cards show the three-level shape (see a GP, ask for an urgent appointment, call 999) that such an exit can take.

Finally, whatever a person types is health information. How it is stored, who sees it and whether it reaches the record are questions the product has to answer before it collects a word.

Long question flows are where accessibility failures compound. WCAG 2.2's Redundant Entry criterion (3.3.7) asks that information a person has already given is not demanded again; Labels or Instructions (3.3.2) and Error Identification (3.3.1) require every question to say what it needs and every rejected answer to explain why, in text.

Health literacy is the larger constraint. The NHS service manual reports that more than 4 in 10 adults struggle with health content written for the public, so symptom questions need plain words, one idea per question, and a way to say “I don't know”. Timing matters too: a session that expires mid-flow, or a step that cannot be resumed, discards work that was hard to do while unwell (Timing Adjustable, 2.2.1).

The products in the library approach symptom capture from three directions. Ada and Infermedica build the capture itself: a dynamic interview that adapts its next question to the previous answers, ending in possible causes (Ada) or a level of care (Infermedica), and both are careful to say what the result is not. Practo uses a much lighter version: an online consultation begins by selecting a speciality or a symptom, which routes the person rather than assessing them.

The common thread is that the output of the step is a summary handed onward, not a decision taken by the software. What none of these public pages describes is what the clinician sees at the other end, whether the captured answers arrive as a structured summary, a transcript, or not at all. That hand-off is the part of the pattern that most decides whether the questions were worth asking, and the part the library most wants to document as products describe it.