Agentic Patient Relationship Management

We built a patient relationship management platform around the work that happens between conversations: identifying a patient, arranging an appointment, tracking a journey, preparing outreach and resolving an outstanding task.

The product combined a FastAPI backend with a Next.js dashboard, then added a conversational layer that could interpret a request and prepare structured operations. I have documented the build in 18 implementation articles, following the path from patient workflow to intent, interface and execution.

The product idea

Staff should be able to begin with the task they want to complete. “Find this patient and arrange a follow-up” should lead to a resolved patient, a usable appointment proposal and a clear account of what happened.

That requires both conversation and conventional screens. The assistant helps express intent; patient views, calendars, journey records and tickets keep the underlying work inspectable. A conversation ending should not make its unfinished work disappear.

What we built

The backend catalogue grew to 18 registered domain agents. The useful measure of completeness, however, is whether an individual workflow connects all the way from request to verified record. The articles use that standard rather than treating the catalogue size as a delivery metric.

How the architecture developed

The code history shows an early frontend agent layer in November 2025, followed by the command-bar interaction. Backend orchestration arrived in January 2026, and a unified model client with Gemini support followed in February.

The important direction was to move execution behind the backend. The browser could show what the system understood, while domain services owned persistent state. An intent became a plan; a write could become a proposal; a confirmation could refer to a specific saved action.

This also made integration work visible. Extracted fields had to match service arguments. A patient search had to yield a selected identity before booking could proceed. A successful operation needed a destination the interface could open.

The frontend idea: make intent inspectable

The assistant returns text alongside structured cards. The application maps card types to known components, keeping presentation and behavior within the frontend's control.

The command bar explores a more immediate interaction: parse the request, show the extracted entities, let the user correct a field and preview the operation. Its state model distinguishes interpretation, confirmation, execution and partial failure.

In the checked-out implementation, the command bar still simulates parsing and execution, and generic view/edit handlers remain unfinished. I describe it as an interaction prototype alongside the backend-connected assistant, rather than implying that every command already writes data and navigates to its result.

Patient journeys keep work moving

Journey instances track a patient's progress through ordered stages, recording entry, completion and notes. Stage actions can create follow-up communication records, and events expose transitions to other components.

Creating a message, submitting it to a provider and receiving a delivery receipt remain distinct steps. The code includes both an older placeholder communication path and separate provider adapters; the connection between them needs to be demonstrated for each workflow.

The implementation series

The expanded series follows the original build into practical implementation: typed tool adapters, editable action cards, versioned approvals, transactional outbox events, FHIR identity and booking, messaging receipts, MCP/A2A boundaries and workflow recovery.

It includes 18 diagrams, 47 code blocks and a downloadable offline Python lab with 43 deterministic checks. The lab exercises stale approvals, duplicate confirmations, competing bookings, tenant isolation, worker leases and delivery-state handling. It is a new reference implementation using synthetic identifiers, separate from the original application.

Later articles develop a proposed 300-case workflow benchmark with 24 starter scenario cards, multilingual voice and handoff contracts, worked capacity calculations and a sourced comparison with Polsia, Hippocratic AI and agent research. These proposals identify the next integration and evaluation work; they are not claims of measured production or clinical performance.

What the build taught me

The hard part of an agentic application is preserving meaning across boundaries: what the user asked, what the interface displayed, what they approved and what the backend actually changed.

The series explains the implemented mechanisms and the remaining integration work. It makes no claim of clinical validation or measured production outcomes. Its central acceptance example is administrative: find a patient, prepare a booking, confirm it, persist it and open the resulting record, with clear behavior when a step fails.

Read the 18-part implementation series, or download the complete reading kit.