You are building an AI agent for healthcare. Maybe it drafts SOAP notes and needs to write them into whichever EHR your customer runs. Perhaps it verifies eligibility and files prior auths across every payer a clinic touches. Or it coordinates scheduling plus records plus billing end to end and only looks smart when the data actually moves.
The product demo works. Things get harder the moment you try to connect that agent to the systems your customers use in production.
This guide is a connection playbook for AI agent builders. We cover what FHIR actually gets you, where it stops, what to do with the legacy EHRs and payer portals that have no API, and how to give your agent reliable programmatic access to the live healthcare stack today. Not in 2027 when the mandates kick in. Today.
At Optexity, we sit at the third tier of that connection stack, which will make sense once we lay out the full picture.
The Connection Layer Problem for AI Agents
Your agent is a reasoning engine. It can only act on the healthcare stack through three concrete capabilities: read data, write data, trigger workflows. Every interesting use case (AI scribing, patient intake, RCM automation, virtual care) is just some combination of those three.
The connection layer that exposes those capabilities is uneven in ways that surprise builders coming from other verticals.
On the clinical data side, FHIR is the stated target and the partial reality. In 2024, 70% of non-federal acute care hospitals enabled patient access using apps that meet FHIR specifications, and 81% enabled access using apps that meet general API specifications.[1] Those numbers hide a large distribution problem. Hospitals running the market-leading EHR hit 83% FHIR app access while hospitals on every other EHR sit at 56%. In outpatient settings, FHIR adoption reached 64% in 2024, up from 49% in 2021. Lower-resourced hospitals (small or rural or Critical Access or independent) lag across the board on these capabilities.
Payer APIs are further behind. The CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F) mandates four FHIR-based APIs for impacted payers with compliance dates generally beginning January 1, 2027.[2] "Impacted payers" means Medicare Advantage organizations, state Medicaid and CHIP fee-for-service programs, Medicaid and CHIP managed care entities, plus Qualified Health Plan issuers on the Federally Facilitated Exchanges. That list is meaningful. Many commercial employer-sponsored plans and regional payers are not in scope.
Practical implication for your agent: the connection stack splits into three tiers, and you need all three.
- Tier 1: FHIR APIs where modern EHRs and impacted payers expose them.
- Tier 2: HL7 v2 interface engines where legacy clinical integration already runs in production.
- Tier 3: Deterministic browser automation for everything that lacks either, which today covers most payer portal workflows and a significant share of EHR writes.
The rest of this guide is how to build on each tier and how to decide per workflow.
Tier 1: When You Can Use FHIR APIs
FHIR gives your agent standardized resources (Patient plus Encounter plus Observation plus Condition plus MedicationRequest plus Coverage plus Claim) accessible through RESTful endpoints with OAuth 2.0 or SMART-on-FHIR authentication. When it works, it is the cleanest path: typed data, known pagination, predictable semantics.
It works in specific places.
CMS-0057-F is the most significant regulatory force pushing the payer side forward. The Prior Authorization API must be populated with covered items and services (excluding drugs), identify documentation requirements, and support electronic submission plus electronic decisions (approve with end date, deny with a specific reason, or request more information). The rule also grants HIPAA X12 278 enforcement discretion for covered entities implementing an all-FHIR Prior Authorization API. For impacted payers other than QHP issuers on the FFEs, expedited decisions must return within 72 hours and standard decisions within 7 calendar days.
The gap is not that FHIR is bad. FHIR is correct. The gap is that FHIR coverage is uneven across the installed base your customers actually use, and the fields your agent needs to write (clinical notes, custom forms, payer-specific prior auth attachments) are often not exposed even where an endpoint exists. An HL7 industry analysis puts it directly: without FHIR, AI agents face semantic ambiguity across EHR vendors and would require retraining per provider system, which is why the standard matters even where it is incomplete.[3]
Build Tier 1 first where it exists. Assume it does not exist for most of your customer base, and design the other two tiers so you are not blocked while you wait for 2027 to arrive.
Tier 2: When HL7 v2 and Interface Engines Fill the Gap
HL7 v2 is the 40-year workhorse of clinical data exchange. It is not going away. Most hospitals run it today through an interface engine (Mirth Connect or Rhapsody or Corepoint or Cloverleaf) that routes messages between systems. For an AI agent builder, this tier is useful for one thing above all else: feeding live clinical events into your agent's context.
The message types that matter:
- ADT (admit / discharge / transfer) for patient lifecycle events
- ORM (orders) for new labs, imaging, or medication orders
- ORU (results) for returned lab and diagnostic data
- SIU (scheduling) for appointment creation plus updates plus cancellations
- MDM (clinical documents) for transcribed notes and reports
Where this tier fits in your architecture: the interface engine subscribes to events and pipes them into your agent's store (vector index, SQL warehouse, or event bus). Your agent reads from that store to answer questions, build context, or decide what to do next.
Where this tier falls short: it is event-driven, not request-response. Writing back through HL7 v2 exists but is limited to what the receiving system exposes, and it does not help your agent drive a multi-step UI workflow (the kind prior authorization requires). Every new hospital customer adds an interface build, and interface engines are not cheap to operate.
Treat Tier 2 as a feed into your agent, not a surface your agent drives.
Tier 3: When You Need Browser Automation for the Portal Layer
This is the tier most AI agent guides skip, and it is where the majority of healthcare workflows actually live. When FHIR does not reach and HL7 v2 cannot write, the remaining path is the portal the human user is already using.
The workflows that require Tier 3 today include:
- Prior authorization submissions that need clinical attachments through payer-specific forms
- Availity Payer Space interactions where individual payers route custom workflows
- Appeals filing and status retrieval
- Clinical note entry into EHRs without open write APIs
- Custom scheduling logic that varies by practice template
- Benefits detail retrieval beyond what a standard 270/271 eligibility response returns
Browser automation is how your agent interacts with these surfaces programmatically. Done well, it looks like a deterministic workflow: record the portal steps once using a browser extension, convert the recording to structured automation steps, expose the result as an API endpoint your agent calls with parameters.
Done poorly, it looks like a brittle screen scraper that breaks every time the payer updates a CSS class. The difference is deterministic execution plus self-healing locators. Each UI element maintains multiple identification strategies so layout changes do not require manual selector repairs. LLM-driven browser agents take a different route: they call a language model on every step, which burns tokens, introduces variability, and is hard to audit for HIPAA-sensitive workflows. The trade-offs between approaches matter before you commit, especially for audit trails and cost per run.
This also explains where aggregators and clearinghouses fit. API aggregators cover standard HIPAA transactions reliably, but the data they return is often cached and does not reflect the payer portal's current state, and they cannot reach Payer Space workflows, custom forms, or appeals at all. Our breakdown of why healthcare API aggregators fall short covers the gaps in more depth. The summary: use aggregators where coverage exists, and fall back to the portal-driven tier for everything else.
A Decision Framework: Which Tier for Which Workflow
The core question for every workflow your agent needs to perform: what is the best available tier today, and what is the fallback if it is not available for this customer?
A hybrid architecture is the realistic target. Your agent should be able to call FHIR where available, subscribe to HL7 feeds where they run, and drive portal automations where neither reaches. The decision happens per customer and per workflow, not per company.
Connecting to Legacy EHRs: Concrete Paths
API maturity varies wildly across the EHRs that health tech developers actually encounter. Here is the short version across the most common systems.
eClinicalWorks (eCW)
Limited API exposure through the eCW Grid and vendor-mediated integrations. Most customer-facing workflows (clinical documentation plus scheduling plus billing) still route through the portal interface. Recommended pattern: HL7 v2 feeds for event capture, portal-driven workflows for writes and custom logic.
drchrono
Offers an API covering a subset of resources, with many clinical and scheduling workflows still sitting in the portal. Recommended pattern: API for core reads where it covers your resources, Tier 3 automation for scribe writes and scheduling.
PracticeSuite
FHIR API v18.0.0 exists using SMART-on-FHIR authentication, with documentation at academy.practicesuite.com. Developers must contact PracticeSuite support directly to obtain client ID and secret. Recommended pattern: FHIR for what it covers, portal-driven automation to fill in custom scheduling and clinical documentation entry.
AdvancedMD
Open API and FHIR endpoints are available, but production access requires an API Connect Agreement. The sandbox cannot contain real patient data under HIPAA. Clinical documentation plus scheduling customization plus practice-specific billing forms often stay in the portal. Recommended pattern: API where coverage is complete, Tier 3 workflows for everything the API does not fully expose.
AthenaOne
800-plus endpoints covering FHIR R4 plus SMART-on-FHIR plus HL7 and C-CDA interfaces. Also a three-legged OAuth 2.0 flow, per-practice base URL resolution, and sandbox IP restrictions that block many development teams. Recommended pattern: FHIR for reads, Tier 3 workflows for writes where the API is restricted or where the OAuth complexity is not worth the build.
Optimantra
No publicly documented API or developer portal for third-party integrations. Pre-built vendor partnerships exist for labs and dispensaries, but for AI agents touching patient records, appointments, or billing, the web interface is the only surface. Recommended pattern: browser automation, full stop.
The same surface area patterns show up for scheduling across eClinicalWorks, AthenaOne, and drchrono and for AI scribe note ingestion, where write APIs are largely absent.
Connecting to Insurance Portals: Concrete Paths
The payer side is where CMS-0057-F matters most, and also where the regulation's scope limits how much changes in 2027. Our deeper look at automating prior authorization and eligibility verification across payer portals covers the workflow-level details. The connection paths by payer:
Availity mediates a significant share of commercial payer transactions and exposes a multi-payer API for standard HIPAA transactions. Payer Space workflows (where individual payers route custom forms, prior auth logic, or reporting) remain portal-only. Use Tier 1 for standard 270/271 and 276/277 where coverage exists, and browser automation for Payer Space interactions.
Aetna / UnitedHealthcare / Cigna / Humana each expose some electronic access through Availity or their own portals. Each routes specific workflows (detailed eligibility, prior auth with attachments, appeals) through proprietary portal interfaces. Our analysis of the Big Four payer portals covers each in depth.
State Medicaid plans (Ambetter / Peachstate / Modemed and others) operate portals with uneven electronic access. Most are impacted payers under CMS-0057-F, which means FHIR-based Patient Access plus Provider Access plus Payer-to-Payer plus Prior Authorization APIs with compliance generally starting January 1, 2027. Until then, and for workflows the mandate does not cover, portal automation is the only reliable path.
The scope nuance is worth stating directly. CMS-0057-F covers impacted payers specifically. Commercial employer-sponsored plans outside Medicare Advantage and the Federally Facilitated Exchanges are not automatically in scope. Self-funded ERISA plans are not impacted payers. If your agent serves customers whose payer mix skews commercial or employer-sponsored, a meaningful fraction of their workflows will still require portal automation well past 2027.
HIPAA, 2FA, and the Non-Negotiables for Any Connection Path
Tier choice does not change the compliance baseline. Regardless of whether your agent touches a FHIR endpoint, an HL7 feed, or a portal UI, the same rules apply.
- Business Associate Agreements with every party in the data path
- Encryption in transit (TLS 1.2 or higher) and at rest
- Role-based access controls for every integration
- Tamper-evident audit logging that captures who accessed what and when
- Least-privilege service accounts with scoped permissions
- Human-in-the-loop for any action that carries clinical risk
Two-factor authentication is the practical friction point that most integration plans underestimate. Every payer portal and most EHR portals require it, and many rotate session tokens aggressively. For Tier 3 workflows, your automation layer needs to handle MFA natively with persistent browser sessions so your agent does not re-authenticate on every request. Concurrent request handling matters too, because running eligibility checks one at a time across four payers is not how a production agent performs.
How Optexity Fits in the Connection Stack
We built our platform for Tier 3 specifically. When FHIR and HL7 cover the workflow, use them. When they do not, which today is most prior auth, most clinical write-backs, and most payer portal workflows, our platform records the portal steps once and gives your agent a deterministic API to call from that point forward.
The specifics that matter for agent builders:
A developer records the workflow with our browser extension, reviews the generated automation steps, and the result becomes an API your agent calls with structured parameters. The same steps run on every invocation, without an LLM on each action, which is why our automations run 3x faster than comparable AI-driven alternatives at substantially lower per-run cost. Multiple identification strategies per UI element mean portal layout changes do not require manual selector repairs.
Beyond the core execution model:
- 2FA handling, persistent sessions, and concurrent requests across every major EHR and payer portal
- HIPAA and SOC2 compliance with encryption, audit logging, and role-based access controls
- Prebuilt automations for common workflows across the Big Four payers plus Availity, and across eClinicalWorks, drchrono, AthenaOne, AdvancedMD, Optimantra, and PracticeSuite
When Nanonets needed universal EHR integration for their revenue cycle platform, browser automation covered the systems that lacked complete API access. The same pattern applies to any agent builder working across multiple customers with mixed integration maturity.
Start free at Optexity's dashboard.
FAQs
Does my AI agent need browser automation if the EHR has a FHIR API?
Often yes. FHIR coverage skews toward reads and toward the resources in the US Core profile. Write operations like clinical note entry, custom scheduling fields, and payer-specific prior auth attachments are usually not exposed even when an endpoint exists. Use the FHIR API where it covers your workflow, and lean on a portal-driven automation layer for the rest.
Which legacy EHRs and payer portals still require portal-level access today?
Most of them. Optimantra has no public API. PracticeSuite requires vendor-mediated credentialing. eClinicalWorks keeps most write workflows in the portal. Among payers, Availity Payer Spaces, individual Big Four portal workflows, and state Medicaid portals outside the CMS-0057-F compliance window all require browser automation.
How does browser automation handle 2FA on payer portals?
Natively. Our automations process verification codes as part of the workflow and maintain authenticated sessions so your agent does not re-authenticate on every request. Persistent sessions plus concurrent request handling are the baseline; anything less breaks at scale.
Will CMS-0057-F eliminate the need for portal automation by 2027?
No. The rule applies to impacted payers (Medicare Advantage, state Medicaid and CHIP, QHPs on federal exchanges). Commercial employer-sponsored plans and self-funded ERISA plans are not in scope. Portal workflows, Payer Space interactions, and detailed benefits retrieval will remain outside API coverage for a meaningful share of your customers' payer mix.
Can I combine FHIR, HL7, and browser automation in one agent?
That is the target architecture. FHIR for clean reads where it exists, HL7 v2 feeds for event capture from legacy clinical systems, and Tier 3 automation for writes and portal-only workflows. Your agent's routing layer picks the tier per workflow per customer.
How do I keep clinical writes auditable when my agent drives a portal UI?
Deterministic execution is the foundation. Because the same steps run every time, each run produces a reproducible trace. Combine that with structured audit logging (who initiated, what parameters, what was returned) and tamper-evident log export, and you meet the same auditability bar as any FHIR-based write.
Is browser automation HIPAA compliant?
It can be, and our platform is. HIPAA and SOC2 compliance with encryption in transit and at rest, audit logging, role-based access controls, and BAAs across the data path. Ask any Tier 3 vendor for their HIPAA and SOC2 attestations before building against them.
How fast can I deploy an integration for a new EHR or payer portal?
For prebuilt automations, deployment takes minutes. Custom workflows for payer-specific prior auth forms or practice-specific scheduling flows typically take hours. Either way, the unit of work is a recording, not a scraper build.
How does deterministic browser automation compare to LLM-driven browser agents?
LLM agents call a language model to decide each action, which introduces variability, burns tokens, and slows each run. Deterministic automation follows the same recorded path every time. For healthcare workflows where accuracy and audit trails matter, deterministic execution is the safer default.
References
[1] Gabriel MH, Richwine C, Owusu-Mensah P, Strawley C. "Growth of Health IT-Enabled Patient Engagement Capabilities Among U.S. Hospitals: 2021-2024." Office of the Assistant Secretary for Technology Policy (ASTP/ONC) Data Brief No. 79, August 2025. https://healthit.gov/data/data-briefs/growth-health-it-enabled-patient-engagement-capabilities-among-us-hospitals-2021/
[2] Centers for Medicare & Medicaid Services. "CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F)." CMS.gov, January 17, 2024. https://www.cms.gov/newsroom/fact-sheets/cms-interoperability-prior-authorization-final-rule-cms-0057-f
[3] HL7 News Editorial. "Relevance of HL7 FHIR Standards in the Age of Agentic AI." HL7 News (Health Level Seven International), January 7, 2026. https://hl7news.hl7.org/2026/01/07/relevance-of-hl7-fhir-standards-in-the-age-of-agentic-ai/
