IntakeOnce

Inspiration

What it does

How we built it

Challenges we ran into

Accomplishments that we're proud of

What we learned

What's next for IntakeOnce

Inspiration

Patients are often asked to repeat the same information across different intake forms. The deeper problem is not typing—it is trust. An AI can extract plausible answers, but patients should still control which facts are correct and what gets shared.

I built IntakeOnce around a simple principle: the model may propose, but the patient decides.

What it does

IntakeOnce turns a fictional patient’s own words into evidence-linked intake answers.

The patient can type, dictate, or use guided voice in English or Spanish. GPT-5.6 proposes structured answers, but every proposal remains pending until the patient reviews it beside the exact words that support it.

The patient can:

• confirm an answer;
• correct it;
• mark it unknown;
• omit it;
• resolve conflicting statements.

Only supported answers that the clinic requested and the patient approved can be shared. Deterministic TypeScript then creates a FHIR R4 QuestionnaireResponse for a simulated provider inbox.

The provider sees the submitted answers, original evidence, audit history, and generated FHIR resource. Everything remains labeled “Patient reported — not clinically reconciled.”

This is a fictional-data prototype. It does not diagnose, reconcile medications, connect to an EHR, or write to a medical chart.

How I built it

I built IntakeOnce with Next.js, React, TypeScript, Zod, the OpenAI Responses API, GPT-5.6, and the OpenAI Realtime API.

GPT-5.6 performs one narrow task: proposing evidence-linked facts from the current patient statement using strict Structured Outputs. The response is treated as untrusted data.

Deterministic code then:

1. validates the response schema;
2. rejects fields outside the allowlist or clinic request;
3. verifies that every evidence quote appears in the patient’s source text;
4. preserves unknowns, approximate dates, and contradictions;
5. assigns server-controlled identities;
6. waits for field-level patient decisions;
7. generates only the approved, requested FHIR answers.

Realtime dictation uses gpt-realtime-whisper. Guided voice uses gpt-realtime-2.1 to ask one concise question at a time. Transcripts remain editable and pass through the same verification pipeline as typed text.

How I used Codex

Codex was my primary engineering collaborator throughout Build Week.

It helped me translate the product idea into typed contracts, separate probabilistic extraction from deterministic policy, implement the patient and provider workflows, build the FHIR generator, create evaluation fixtures, refine the responsive interface, diagnose workflow bugs, and prepare the Fly.io deployment.

I retained responsibility for the key product and safety decisions: fictional data only, exact evidence visibility, explicit unknowns, patient-controlled sharing, requested-field enforcement, deterministic FHIR generation, and no diagnosis or chart-write claims.

Browser-based reviews created a tight feedback loop. For example, I noticed that the initial request preview did not name all the fields shown later during confirmation. I also found cases where corrected voice information could lose to an earlier transcription. Codex helped trace those issues across extraction, review, submission, and FHIR generation instead of applying superficial UI patches.

Challenges

The hardest challenge was preserving meaning across the entire workflow.

A date is not interchangeable with ordinary text. A member ID is not the same as a group number. “I do not know the dose” must not become a guessed dose. A corrected email must supersede the earlier spelling without erasing its evidence history.

Another challenge was keeping the experience understandable. Intake workflows can quickly become crowded with warnings, disclosures, and technical details. I refined the design toward a calm editorial interface with compact progress navigation, clear requested-field groupings, accessible controls, and one decision at a time.

Finally, I needed judges to run the live AI workflow without deploying an API key. I added a temporary key dialog that keeps the key only in volatile server memory. It is never stored in browser storage, a database, the Docker image, Fly secrets, or application logs.

Accomplishments

I am especially proud that:

• every proposed answer remains traceable to exact patient evidence;
• unknowns and conflicts stay visible instead of being silently “cleaned up”;
• the patient controls every sharing decision;
• non-requested information cannot enter the FHIR submission;
• the model never generates the final FHIR resource;
• the same trust boundary applies to typed and voice input;
• the complete patient-to-provider demonstration runs on Fly.io.

The deterministic evaluation covers 18 synthetic safety scenarios, including unsupported facts, prompt injection, self-corrections, explicit unknowns, conflicts, Spanish evidence, forbidden paths, and non-requested information.

What I learned

I learned that trustworthy AI workflows are not created by asking a model to be more careful. They require explicit boundaries around what the model may propose, what deterministic code must verify, and what the user must decide.

I also learned that provenance should be part of the product experience—not hidden in logs. Showing the supporting words beside each answer makes verification faster and gives the patient a meaningful role.

What’s next

A production version would require authentication, tenant authorization, durable encrypted storage, formal security and privacy review, retention controls, validated interoperability services, and authorized EHR integration.

The next product step is reusable patient-controlled intake across multiple questionnaires while preserving the same principle:

Tell it once. Verify every field. Share only what was requested.

Built With

• codex
• gpt-5.6