AI-Powered Patient History Platform

The scope

The product needed to collect detailed patient history before a clinical encounter without presenting every patient with the same static form. The work combined patient-facing and clinic-admin applications, document capture, an AI-assisted sequencing layer, and planning for a SMART on FHIR R4 connection to compatible EHR environments.

Why the questionnaire was hard

A questionnaire of this size creates product and engineering problems at several layers. Questions are conditional, answers can change what should appear next, documents may be required at specific points, and incomplete sessions need to resume without losing context. Clinical stakeholders need control over content, while engineering needs a predictable data model and testable branching behavior.

Adding AI does not remove those constraints. The system still needs explicit boundaries around which questions are eligible for resequencing, what information the model can use, how the original clinical structure is preserved, and what happens when an AI service is unavailable or returns an unsuitable result.

Technical product owner and technical lead

I owned the work across discovery, architecture, product decisions, and delivery leadership. That included translating clinical and founder requirements into an executable scope, evaluating cloud and AI vendors under HIPAA and BAA constraints, shaping the prototype, planning the EHR integration, and coordinating the team responsible for the patient and administrative experiences.

• Ran technical discovery with clinical and non-technical stakeholders.
• Turned the intake flow into product behavior, data structures, backlog items, and acceptance criteria.
• Evaluated cloud and LLM options based on data exposure and available BAA coverage.
• Defined how AI-assisted sequencing would fit around deterministic questionnaire rules.
• Planned document capture and EHR integration boundaries.
• Led engineering delivery across application and infrastructure concerns.

Keep clinical structure explicit

Represent branching as product data

Conditional behavior needs to be inspectable and testable independently of the interface. Treating question definitions, prerequisites, branching conditions, and completion state as structured product data makes it possible to validate the flow and evolve content without hiding critical rules inside UI components.

Use AI as a bounded sequencing capability

The model can assist with selecting or ordering the next relevant questions, but deterministic clinical rules remain the authority. The workflow needs fallbacks so it can continue when AI output is missing, invalid, or unavailable.

Separate patient and clinic responsibilities

Patient capture, clinic review, administrative configuration, and integration operations have different access needs. Keeping those boundaries explicit supports clearer authorization, audit events, and user experiences.

Treat the EHR connection as an integration contract

For the planned SMART on FHIR connection, the team must decide launch context, authorization scopes, resource mappings, source-of-truth behavior, and how failures or partial writes are surfaced to operational users.

What the work produced

The main outcome was not only a prototype. It was a clearer product and delivery shape for a compliance-sensitive healthcare workflow: patient and clinic surfaces, structured intake data, document capture boundaries, AI sequencing rules, vendor assumptions, and a path toward EHR integration.

What mattered in practice

• Clinical branching should remain understandable without asking an LLM to explain what happened.
• AI vendor evaluation must begin with the exact data sent to the service, not the vendor's general healthcare marketing.
• Long intake flows need resumability, progress semantics, and content versioning as first-class product requirements.
• Healthcare resource mapping belongs in discovery because it changes the data model and workflow, not only the integration sprint.
• Prototype decisions should leave a clear path toward security, observability, and operational ownership.

For the integration side of this work, read Planning my first SMART on FHIR integration.

What I would formalize earlier

I would make the first discovery artifact a shared readiness map: PHI data flow, vendor scope, role model, audit events, AI prompts and retention, document lifecycle, and integration assumptions. That gives product, clinical, engineering, and compliance owners one operating picture before implementation begins.

Use the HIPAA Software Readiness Checklist for that review.