SayReady

• 

  Start with your own words. Local AI suggestions remain optional, and nothing is approved automatically.

• 

  An explicitly approved card contains only selected communication requests, without the original personal reasons.

• 

  Review suggested requests beside their exact supporting words, then choose what belongs on your card. Synthetic example.

Inspiration

A healthcare conversation can start with a simple request: please write down the key information, ask one question at a time, or give me time to answer. A person should be able to express that preference without putting their diagnosis or the reasons behind it on a card.

Communication cards and hospital passports already exist. SayReady explores a narrower interaction: a private note becomes visible evidence, the person makes the selection, and only their approved requests reach the card. This is a prototype hypothesis, not an established patient benefit.

What it does

SayReady is a local web app for preparing a communication-preference card before speaking with healthcare staff. It supports five requests: information in writing, large text, one question at a time, time to answer, and a quiet explanation space if available.

The person writes a short English or Korean note. A local model proposes candidates beside exact quotations from that note. Every candidate starts unselected. The person chooses one to three requests and explicitly approves them before a card appears. The card uses fixed English or Korean sentences and leaves out the original note and personal reasons.

Manual mode offers the same five choices without a model call. Editing the note, switching modes, changing card language, or clearing the session invalidates prior approval. Nothing is sent to a healthcare provider by the app.

How it was built

The new application uses Python's standard library, HTML, CSS, and JavaScript. It runs on loopback at 127.0.0.1:8794 and calls an already installed Ollama gemma4:e4b-it-qat model at a fixed local endpoint. Model weights are not included. Manual mode runs without the model.

The model returns schema-constrained JSON with a request type, exact source quotation, subject, and polarity. Deterministic validation restricts the five types, checks quotes against the original note, and conservatively excludes detectable negative, third-person, uncertain, conflicting, and instruction-like wording. The card endpoint accepts fixed request IDs and explicit approval rather than model-written medical advice. A generation counter discards stale responses after a newer action.

The application uses session memory, with no database, browser storage, analytics, external scripts, or note logging. The server applies loopback Host/Origin checks, a custom request header, body limits, no-store responses, and a self-only connection policy. These are prototype boundaries, not a claim of a complete security audit or forensic memory erasure.

OpenAI Codex generated the implementation, design, synthetic cases, tests, and documentation, and performed automated checks and browser QA. This AI assistance is separate from the local model used at runtime. No model training or fine-tuning was performed. New source is MIT licensed; the exact model tag's license is documented separately in THIRD_PARTY.md. The entrant is not represented as having hand-written all code or conducted a patient study.

Challenges and decisions

A matching quotation proves that words occur in the note; it does not prove that they describe the writer's own positive preference. Early checks could accidentally attach a neighboring sentence to a quote. Development review also found uncertain wording and reported speech that needed more conservative treatment. These defects were corrected before the recorded model evaluation.

The remaining tradeoff is deliberate: some valid requests may be rejected, and complex phrasing can still be misread. Showing the quote, starting with no selection, requiring approval, and preserving a manual path are all necessary parts of the design. They are not replacements for future testing with intended users.

What was verified

• 19 Python test methods passed: 10 core checks and 9 isolated HTTP checks. The HTTP tests stub the model and are reported separately from real inference.
• 9 JavaScript state checks passed, including the three-request limit, approval reset, and stale-response rejection.
• An actual local-model run matched the expected request-type sets for 20 authored synthetic cases: 12 English and 8 Korean. Inputs, raw model responses, checked outputs, timing, environment, and source hashes are included in the submission.
• Median inference-plus-validation time was 687.5 ms and nearest-rank p95 was 1,090 ms in that already warmed local sequence. These are not cold-start or general hardware performance claims.
• Actual browser checks covered English and Korean cards, one selected request out of two candidates, another person's preference, instruction-like input, manual selection, and clearing prior approval after edits.

The 20 cases were written during development and are not held-out data. Their result is not a general accuracy estimate or clinical validation. No patient outcomes, user study, screen-reader conformance, or measured time saving is claimed. The demo is an edited sequence of actual browser states, not a real-time recording.

What's next

Test whether the card language and review interaction are understandable to intended users; compare the AI path with direct manual selection; and evaluate broader phrasing and assistive technology. The current submission does not diagnose, assess urgency, recommend treatment, or claim that a service can meet a request.

The ZIP contains the runnable source, README, full code PDF, one-page project summary, and reproducible technical evidence. To run it, extract the source and use python3 server.py, then open the local URL. AI suggestions additionally require the documented installed local model.

Built With

• javascript
• ollama
• python