Health information people can actually use

Start with the moment someone needs help

An appointment message arrives. The date is there, somewhere. The building has several entrances. There is a link to a portal, but the person reading it cannot remember the password. They want to answer a small question: where do I go, and what do I need to do next?

That is a useful place to begin thinking about access to healthcare. It gives us something specific to improve and a way to find out whether the improvement worked. A beautifully written explanation has limited value if the person still needs three phone calls to work out what it means for them.

At JDGMNT, our proposed starting point is the information around care: appointment messages, explanations of a process, and routes to help. We would begin with one agreed task and qualified reviewers. We have not run a patient study or demonstrated an improvement in clinical outcomes. This article sets out how we would approach the work.

Decide what the reader needs to do

Before rewriting a message, write down its purpose in one sentence. For an appointment reminder, that might be: help someone find the correct time and place, and understand how to ask for assistance. If the team cannot agree on that sentence, more polished wording will not resolve the disagreement.

AHRQ's communication guidance recommends familiar language, limiting the information presented at once, and checking understanding. Those principles provide a sensible starting point for a team reviewing how it explains a service. They do not remove the need to check the facts or the local context. ^[1]

The CDC Clear Communication Index begins with the audience, communication objective, and main message. Its guidance also places the main message prominently and asks writers to make the intended action clear. We would use those questions before choosing a layout or an AI model. ^[2]

For each message, our working brief would record the intended reader, the task, the authoritative source, the facts that must remain unchanged, and the person responsible for approving an update. Keeping that brief small makes it easier to use during a real review.

Keep the facts, change the effort

Consider a fictional appointment record: 6 November 2026, 10:30, East entrance, Reception 2. It also says to use the contact details in the original confirmation if help is needed. Both versions below contain the same facts.

Dense version: Your attendance is requested on 6 November 2026 at 10:30, with access via the East entrance and reporting to Reception 2; should assistance be required, please refer to the contact details supplied in your original confirmation.

Clearer version: Your appointment is on 6 November 2026 at 10:30. Use the East entrance and go to Reception 2. Need help? Use the contact details in your original confirmation.

The revision separates the task into parts and uses ordinary language. On a screen, we would give the time, location, and help route their own labels. We have not added an arrival time, an address, an instruction about medication, or a preparation requirement. If a necessary detail is missing from the source, the next step is to ask its owner.

This is our design example, not evidence that the revision improves attendance or understanding. Someone might still need a map, an accessible entrance, or a number they can call directly. Testing should reveal those gaps rather than reward the page for looking tidy.

Give AI a small, checkable job

An AI system could help draft a simpler version, suggest headings, or identify details that appear to be missing. A useful instruction would include the approved source and require the system to preserve dates, locations, conditions, and uncertainty. The output would remain a draft until a responsible reviewer checks it against that source.

WHO's guidance on large multi-modal models in health describes risks from false, inaccurate, biased, and incomplete output. Fluent wording does not establish that a message is reliable. That is one reason we would keep the initial task narrow and require review before any patient-facing use. ^[3]

For an early prototype, we would use fictional records and public information. There is no need to upload a patient's letter to see whether a layout helps people find a date. Moving to real records would require a separate decision about permission, data handling, the service being used, and who is accountable for the work.

The team should also have a workable process when the model fails: return to the approved wording, log the problem, and make the unresolved question visible. An AI feature earns its place only if the complete workflow is useful after checking and correction.

Make language and delivery part of the job

Translation needs its own review. A translated sentence may be fluent while losing a condition, using an unfamiliar term, or changing the implied next step. We would ask a qualified language reviewer to compare the translated message with its source and check it in the context where it will be used.

The website should not hide essential instructions inside an image. A text version can be copied, enlarged, read with assistive technology, and retained when the photograph does not load. That makes it a practical baseline for our proposed work, alongside a printable version where that is useful.

We would also inspect dates, time formats, address conventions, text wrapping, and the help route in each supported language. The question is whether a person can complete the task in their circumstances. A language menu by itself does not answer it.

Start with the smallest useful delivery format. If a plain page can carry the explanation, do not make a video or a new account necessary to understand it. Where another format helps, keep the core information available alongside it.

Test understanding, then decide

We would first review the source accuracy and the proposed study with appropriate specialists. Any work with participants would need a suitable plan for consent, privacy, recruitment, and support. A fictional appointment task lets the team examine the design without asking people to make a real healthcare decision.

Instead of asking only whether someone likes the page, ask them to find the appointment time, explain where they would go, and show how they would get help. Record the answer, the time taken, where they looked, and whether assistance was needed. Give people a way to say that the message is incomplete or does not fit their situation.

Agree on the decision criteria before reviewing the results. Define which errors would stop the test, what needs revision, and what would justify a further study. Keep the observations separate: a fast answer can still be wrong, and a correct answer after substantial help may expose a design problem.

We would report the task, participants, conditions, limitations, and unsuccessful attempts alongside any promising result. A small usability exercise would not establish a clinical benefit or justify a wider claim about access to care.

Give the information an owner

A message can be correct when it is published and wrong after a service changes its entrance, schedule, or contact process. Our proposed workflow therefore ends with a named owner, an approved source, a review date, and a way to withdraw or correct the page.

For a small first project, the deliverable could be modest: one reviewed message, one accessible text page, one printable version, and a short record of what testing revealed. That is enough to learn whether the approach deserves another iteration.

Explore the Healthcare focus page to see the proposed direction and compare the fictional messages. The downloadable review sheet below captures the source, fixed facts, review questions, and next decision. It is a starting point for a team discussion, not a clinical assessment tool.