Overview
Healthcare clinics routinely spend 40–60 minutes processing new patient intake through paper forms, manual data entry, and staff-mediated Q&A. This concept demonstrates how a conversational AI layer, built with appropriate data controls, can compress that experience to under 12 minutes while producing structured, EHR-ready data that eliminates transcription error.
The Problem
Healthcare intake is a problem that looks simple on the surface — it's just forms — but hides significant complexity underneath. The data must conform to HL7 FH…
The Approach
The core architectural decision was to use a structured output LLM approach rather than a chat interface. Rather than building a chatbot, we designed a guided f…
The Outcome
Lighthouse scores on the intake pages averaged 96 Performance, 100 Accessibility, 100 Best Practices, 98 SEO. The primary performance focus was LCP: since patie…
The Challenge
Healthcare intake is a problem that looks simple on the surface — it's just forms — but hides significant complexity underneath. The data must conform to HL7 FHIR R4 standards for EHR compatibility. The questions must adapt based on previous answers (a patient with diabetes requires different follow-on questions than one without). The system must handle edge cases gracefully (contradictory answers, missing information, non-English speakers). It must meet HIPAA requirements. And it must feel genuinely easy to complete on a mobile phone in a waiting room.
Research
The research phase focused on three areas: workflow mapping (how does intake actually happen today, step by step, in a real clinic), data requirements (what does the target EHR system need to ingest a patient record), and user research with both clinical staff and patients. The most revealing finding: 60% of form completion time was not reading or thinking — it was physical form handling, pen-writing, and handing documents back to front-desk staff. The second most common failure mode was staff re-asking questions because patient handwriting was illegible.
Strategy
The core architectural decision was to use a structured output LLM approach rather than a chat interface. Rather than building a chatbot, we designed a guided form that uses AI for three specific tasks: (1) generating contextually appropriate follow-up questions based on previous answers, (2) extracting structured FHIR-compliant data from natural language responses, and (3) detecting potential clinical red flags that should be flagged for immediate clinical review. This approach is dramatically more reliable than a free-form conversational interface in a regulated setting.
Design
The interface was designed mobile-first around a single-question-at-a-time progressive disclosure pattern. Each question fills the full viewport with clear input affordances. Progress is shown as a timeline, not a percentage — "Step 4 of 12" reduces anxiety better than "33% complete." The visual language was deliberately neutral and clinical without being sterile. Accessibility was a design requirement, not an afterthought: all inputs work with screen readers, colour is never the sole differentiator, and focus management follows WCAG 2.1 AA throughout.
Development
The frontend was built in Next.js 15 with TypeScript, using server components for the initial form shell and client components for the dynamic question logic. The AI layer calls a serverless function that constructs a structured prompt from the patient's previous answers, sends it to the language model, validates the JSON response against a FHIR schema, and returns only the next question and any extraction results. No raw model outputs are stored — only structured FHIR data is persisted. The FHIR server integration uses the SMART on FHIR OAuth2 protocol for authentication.
Performance
Lighthouse scores on the intake pages averaged 96 Performance, 100 Accessibility, 100 Best Practices, 98 SEO. The primary performance focus was LCP: since patients are on mobile networks in clinical settings, we optimised heavily for Time to Interactive. The form shell loads in a single static HTML request with no JavaScript required to render the first question. Subsequent questions are fetched via API and inserted into the DOM without re-rendering the shell.
Architecture Overview
Client (Next.js SSG shell) → Question API (Next.js Route Handler) → LLM Layer (GPT-4o structured output) → FHIR Validation → PostgreSQL (structured patient record) → FHIR Server (EHR sync). The AI is entirely server-side: no LLM calls happen in the browser. The patient sees only a standard form interface.
SEO Strategy
The intake portal is not indexed (robots noindex). The marketing landing page explaining the service uses structured data (MedicalOrganization + MedicalClinic schema), condition-specific landing pages for organic search, and a content strategy around patient education that builds topical authority over time.
Accessibility Notes
Every form field has an associated label. Error messages use role="alert" and are associated with the specific field. The single-question-at-a-time layout eliminates cognitive overload. Tab order follows document flow. All interactive elements have 44×44px minimum touch targets. The system was tested with NVDA and VoiceOver screen readers.
Performance Optimisations
Static shell loaded from CDN edge. Dynamic question content fetched via API (not re-rendered). Font subset to only characters used in the UI. Images compressed to WebP/AVIF with explicit width/height. No layout shift (CLS < 0.01). Service worker caches the shell for repeat visits.
Lessons Learned
The most important lesson: in regulated environments, the AI system's job is to structure information — not to make clinical decisions. Every piece of AI output that surfaces to the clinical workflow must be traceable to a specific patient input, with a clear audit trail. "The AI said so" is not an acceptable clinical rationale. Building the audit layer first (before the AI layer) made the system dramatically more trustworthy to clinical stakeholders.
Future Improvements
The natural evolution of this system is multilingual support using the same LLM layer, voice-to-text input for patients with limited hand mobility, and integration with insurance verification APIs to pre-populate coverage information. The core architecture supports all three — the structured output approach means the AI layer is a pluggable component, not a core dependency.