AI Agents for Healthcare

The agent extracts relevant clinical criteria from patient records using FHIR R4 resource types (Condition, Observation, MedicationRequest, Procedure) as the structured input format, matches them against payer-specific guidelines retrieved from a knowledge base, and submits authorisation requests to payer portals or clearinghouses via the X12 278 transaction format or payer API where available. CDS Hooks (Clinical Decision Support Hooks) integration allows the agent to trigger directly from EHR workflow events -- for example, when a clinician creates a MedicationRequest for a drug that requires prior auth, the CDS Hook fires and the agent begins the extraction and matching process in the background.

Submission status tracking polls payer portals or clearinghouse status endpoints on the defined follow-up schedule. Pending requests approaching payer response deadlines are escalated automatically. Clinical staff see only the exceptions: incomplete documentation flagged by the agent, criteria mismatches that require clinician input to resolve, and denials that the agent has assessed as viable for appeal based on the denial code and available clinical documentation.

The agent is built using LangGraph for stateful workflow management -- the multi-step prior auth process (extract, match, submit, track, escalate) is modelled as a directed graph with explicit state transitions and human-in-the-loop checkpoints before any submission action. Checkpoints before submission are mandatory for high-value or complex requests, configurable per request type. The audit trail captures every step per 45 CFR 164.312 access control and audit log requirements.

The agent drafts SOAP notes and encounter summaries from structured input -- dictation transcripts, structured form responses, or clinical data already in the EHR accessed via FHIR R4 resource queries. It uses BioBERT or Med-PaLM for clinical NLP tasks such as extracting diagnosis and treatment information from unstructured dictation, and structured output with JSON Schema validation to ensure the generated note content maps to your EHR's template fields before pre-population.

The pre-population step writes draft content to the EHR via the FHIR R4 DocumentReference or clinical note API endpoints (where the EHR supports write-back) or formats the draft as a structured display for the clinician to copy-confirm. A human-in-the-loop checkpoint is mandatory before any note is finalised -- the clinician reviews the pre-populated draft, edits where the agent has made errors or missed context, and signs the finalized note. The agent does not have the ability to finalise or sign clinical documentation without clinician action.

CDS Hooks integration can trigger the documentation agent from an EHR context event, such as the end of a telehealth visit or the completion of a clinical assessment form, so the draft note is ready in the clinician's queue when the encounter ends. Note generation scope is constrained to your approved template structure and is reviewed by your clinical team during a 2--4 week clinical validation phase before the agent is deployed to a live patient population. Structured output validation using JSON Schema catches format errors before they reach the EHR, eliminating the class of documentation errors caused by incomplete note templates.

The agent queries your EHR or population health data via FHIR R4 Patient/$everything to retrieve the complete patient health record and identify care gaps against evidence-based screening guidelines: USPSTF mammogram recommendations, colonoscopy intervals by risk tier, HbA1c measurement frequency for diabetic patients, annual wellness visit eligibility, and chronic disease follow-up milestones specific to your patient panel's condition mix.

Patient identification uses FHIR CQL (Clinical Quality Language) expressions or HEDIS measure logic to define the eligible population and gap criteria in a standardised format that can be reviewed and updated by clinical staff without code changes. The vector database (Pinecone with VPC peering for HIPAA-compliant deployment) stores patient context embeddings that the outreach personalisation layer uses to tailor message content -- a patient's preferred communication channel, language, past engagement history, and care team relationship.

Outreach messages are generated using the LLM with structured prompts that include the specific care gap, the patient's relevant health context, and the outreach template approved by the clinical team. All generated messages pass through a JSON Schema validation step confirming they contain the required elements before delivery. Multi-channel outreach runs across SMS, email, and patient portal notifications with channel preference respected. Response tracking updates the patient record via FHIR R4 write-back. Appointments scheduled through the outreach link are written to the scheduling system directly. Non-responders are flagged for manual outreach review after a configurable interval, with the agent's full outreach history available to the staff member handling follow-up.

Before an appointment or telehealth visit, the agent collects structured intake data in a guided conversation -- chief complaint, symptoms, onset and duration, severity (1--10 scale), relevant medical history, current medications, and recent care elsewhere. The conversation uses a dynamic branching structure: the questions asked depend on the chief complaint, so a patient presenting with chest pain gets a different intake sequence than one presenting with a rash, without requiring the patient to answer generic questions irrelevant to their situation.

Symptom patterns are screened against urgency criteria using a structured clinical reasoning layer. Red-flag symptoms (chest pain with dyspnea and left arm radiation, sudden severe headache, signs of stroke) trigger immediate routing to emergency escalation rather than queuing for a standard appointment. The triage logic is defined by your clinical team and reviewed before deployment -- the agent applies the criteria, it does not set them. Human-in-the-loop checkpoints are mandatory for any triage decision that redirects a patient to a higher acuity setting.

Collected data is structured as FHIR R4 resources (Patient, Condition, Observation, MedicationStatement) and submitted to the EHR via the FHIR R4 write API, pre-populating the provider's pre-visit note. CDS Hooks fires a notification to the provider's EHR interface when the intake is complete and the patient is in the waiting queue. Providers arrive at the appointment with structured intake already confirmed in the EHR record, not a blank screen requiring five minutes of verbal history gathering. The audit trail captures every patient response and the agent's routing decisions per 45 CFR 164.312 requirements.

The agent processes inbound refill requests against the patient's medication history (retrieved via FHIR R4 MedicationRequest and MedicationDispense resources), refill eligibility rules, controlled substance requirements, and any formulary or quantity limits defined for the practice. The eligibility check runs in seconds: last dispense date, days of supply dispensed, refill count against authorized refills, any controlled substance refill interval restrictions, and required monitoring lab values for medications that need them (INR for warfarin, creatinine for metformin, etc.).

Requests that meet all criteria generate a structured refill task for pharmacist or prescriber approval via the FHIR R4 Task resource in the EHR. The task includes the medication, quantity, days of supply, the eligibility check results, and the patient's relevant lab values -- everything the approver needs to confirm the request in 15 seconds rather than 3 minutes. The agent handles the matching and documentation; the clinical decision (approval or modification) remains with the prescriber.

Requests that fail eligibility checks are flagged with the specific gap noted: "refill requested 5 days early -- last dispense was 25 days ago for a 30-day supply," or "INR not on file in last 90 days -- required before warfarin refill." This specificity means the patient-facing response or the manual review task contains actionable information rather than a generic denial. The audit trail per 45 CFR 164.312 captures every refill request processed, every eligibility check run, and every approval or exception decision, providing a complete record for compliance and quality review purposes.

The agent handles scheduling, rescheduling, and cancellation requests across provider calendars using real-time availability from your scheduling system via the FHIR R4 Schedule and Slot resources (where the EHR exposes them) or the scheduling system's native API. Appointment type rules -- which appointment types can be booked online, minimum notice requirements, provider-specific block scheduling, and age or condition eligibility for specific visit types -- are configured during setup so the agent applies the same rules a front desk agent would apply manually.

Booking confirmation writes the FHIR R4 Appointment resource to the EHR and sends the patient a confirmation message with the appointment details, location or telehealth link, and preparation instructions specific to the appointment type. Reminder messages are sent at the configured intervals (typically 72 hours and 24 hours before) with a confirm or reschedule action. Cancellations received more than 24 hours before the appointment trigger a slot release and waitlist offer -- patients who have opted into the waitlist and match the appointment type and provider criteria receive an offer for the newly available slot, typically recovering 30--50% of cancelled appointments as rebooked visits rather than empty slots.

The agent escalates to front desk staff for requests that fall outside its configured scope: complex multi-provider scheduling, requests from patients with active care plans that require clinical input on scheduling decisions, and scheduling requests where the patient reports a symptom that suggests they may need a different appointment type than requested. Front desk staff handle relationship management and complex requests; the agent handles the volume of routine scheduling interactions that represent 60--80% of scheduling contacts for a typical ambulatory practice.