Picture the agents being built for healthcare right now. An ambient scribe listens to the visit and drafts the clinical note. A care-coordination agent preps tomorrow's schedule: pulls each patient's chart, checks their active medications, flags an allergy conflict before the physician walks in. A prior-authorization agent chases an insurance approval while the patient is still in the room. A follow-up agent makes sure the diagnostic report from last week's lab work actually made it into the record.
Every one of those, past the first step, needs access to the patient record, and in the US the patient record lives inside an EHR. The category's trajectory shows how fast this is becoming the constraint: ambient scribes were healthcare AI's first breakout, roughly $600 million in 2025 revenue, and the leaders are already pushing past documentation into actions like in-visit prior authorization. Every healthcare agent that moves from producing text to acting on patient data has to implement one standard first: SMART on FHIR. Scalekit now handles it end to end.
Point us at any EHR's FHIR base URL and we discover the login flow automatically. For AdvancedMD, a pre-built connector ships with 30 ready-made tools your agent calls as the authenticated user. You keep your backend; Scalekit handles auth, access, and audit between your agent and the EHR.
EHR data access is required by law. The 21st Century Cures Act (2016) and the ONC Interoperability Rule (2020) require every certified EHR in the US to expose patient data through SMART on FHIR, and enforcement is active: since September 2023, the HHS Office of Inspector General can fine EHR vendors and health information networks up to $1 million per information-blocking violation. Epic, which runs 43.7% of US acute care hospitals and 56.9% of hospital beds, implements it. So do Oracle Health (21.9% of hospitals), Meditech (14.7%), AdvancedMD, Athenahealth, eClinicalWorks, NextGen, Allscripts, and Veradigm.
The standard itself is substantial. SMART on FHIR is HL7's authorization framework for clinical data, built on OAuth 2.0. The authorization endpoints are not published in developer docs; they are discovered from the FHIR server itself, through the capability statement at /metadata and its oauth-uris extension. Tokens are bound to a specific FHIR server through the aud parameter, so an authorization granted for one hospital's system cannot be replayed against another's. Permissions use SMART's own scope grammar, which encodes clinical resources and access mode into strings like patient/MedicationRequest.read and distinguishes patient-context from user-context access. Launch context is part of the protocol too: a standalone launch initiated by the application works differently from an EHR launch initiated inside the hospital's own software, and identity claims like fhirUser tie the token back to the actual clinician or patient who authorized it.
Each EHR vendor implements this framework against its own tenancy model, registration process, and quirks. Multiply that by every hospital customer your agent serves, add token lifecycle across all of those tenants, and finish with a security review that will ask exactly who authorized each action. Healthcare AI teams end up staffing an OAuth-in-healthcare specialty they never planned to have, while their actual product waits.
Three pieces work together.
Custom authorize parameters. SMART on FHIR needs the aud parameter injected into the login redirect. Scalekit's OAuth connectors accept arbitrary custom parameters for any provider, which also unblocks any future provider with non-standard OAuth requirements.
A generic SMART on FHIR connector. Give it any EHR's FHIR base URL. Scalekit calls the server's /metadata endpoint, reads the published OAuth URIs, and configures the authorize URL, token URL, and aud value for you. This works against any FHIR-compliant system, including ones we have not named yet, and ships with 30 tools covering patient records (including the $everything operation for full-chart retrieval), medication requests, allergies, care plans, goals, diagnostic reports, and immunizations. Explore the SMART on FHIR connector.
A named AdvancedMD connector with tool-call support. For AdvancedMD the configuration is pre-built, with no discovery step, and 30 tools mapped to AdvancedMD's FHIR API: read and search patient records, search encounters and immunizations, manage allergy records, create and update medication requests, and file diagnostic reports. Explore the AdvancedMD connector.
Consider medication reconciliation, a workflow every clinical team runs. The agent reads the patient's record, pulls their active medication requests, cross-checks them against recorded allergies and immunization history, and updates the medication list where the clinician approves a change. Every step is a distinct FHIR call, made against a specific hospital's tenant, under a specific user's authorization.
Most infrastructure in this space stops at authentication: the agent gets a token, and everything after that is your engineering problem. Scalekit ships the actions themselves, and every call runs as the specific user who authorized it rather than a service account. In healthcare this determines whether the deployment passes review. An action logged against a bot account fails the audit; an action attributed to the clinician or patient who authorized it passes. This is the same delegated authentication model Scalekit applies across every connector.
If you are building for healthcare, your security lead will ask about the data path before anything else. Here is the answer, plainly.
Tool-call payloads are never stored. When your agent calls patient_read against an EHR, Scalekit makes the call in real time. Request and response pass through in memory only and are never written to disk. Patient data does not persist anywhere in Scalekit's database layer.
What is stored is encrypted per customer. The credentials that grant access, OAuth tokens and API keys, are AES-256 encrypted with a key unique to each customer, wrapped by a KMS master key. Everything in transit runs over TLS 1.3.
Scopes are enforced before the API is touched. Every request is checked against what the user actually approved. A call outside those scopes never reaches the EHR.
Audit logs are metadata only. Every tool call is logged: who authorized it, which agent, which tool, which scope, status, latency. The log never includes request or response payloads, so it satisfies the audit requirement without becoming a place patient data could end up. Logs are exportable to Datadog, Splunk, or any SIEM.
Deployment fits your boundary. Run Scalekit self-hosted in your own cloud or your customer's cloud, or in our cloud with bring-your-own-key encryption (GCP and AWS KMS). SOC 2 Type II and ISO 27001 certified, GDPR and CCPA compliant, and we sign HIPAA BAAs and custom DPA terms on our Enterprise plan.
Scalekit sits between your agent and the EHR as an MCP gateway. Your backend stays yours; Scalekit handles authentication, access control, and audit in the path.
Scalekit supports standalone launch, the agent-initiated login flow, which is how AI agent products work today. EHR-launch, where the hospital's EHR software opens an app from inside its own UI with a per-session launch token, is a structurally different flow that Scalekit does not cover. Version coverage is broad because the standard is consistent: DSTU2, STU3, R4, and R5 all use the identical OAuth flow, so discovery works across all of them.
Most teams in this position are comparing integration platforms that were built for general SaaS connectivity and asking whether healthcare can be made to fit. The questions that decide it are specific: can the platform speak SMART on FHIR without custom work, can it show you exactly where PHI does and does not travel, and will it sign a BAA. If those are the questions on your list, talk to us about your EHR.
SMART on FHIR is HL7's authorization framework for clinical data, built on OAuth 2.0. It adds endpoint discovery from the FHIR server's /metadata capability statement, an aud parameter binding tokens to a specific FHIR server, a clinical scope grammar such as patient/MedicationRequest.read, and identity claims like fhirUser. Every certified US EHR is required to support it under the 21st Century Cures Act.
Any FHIR-compliant EHR through the generic SMART on FHIR connector, which auto-discovers the OAuth configuration from the EHR's FHIR base URL. AdvancedMD also has a named, pre-configured connector with 30 tools for patient records, medication requests, allergies, encounters, immunizations, and diagnostic reports.
No. Tool-call requests and responses pass through Scalekit in memory only and are never written to disk. Scalekit stores only the encrypted credentials (OAuth tokens, API keys) needed to act on the user's behalf, and audit logs record metadata only, never payloads.
Yes. HIPAA BAA execution and custom DPA terms are available on the Enterprise plan. Scalekit is SOC 2 Type II and ISO 27001 certified, and supports self-hosted deployment and bring-your-own-key encryption.
Scalekit supports standalone launch, the agent-initiated flow used by AI agent products. EHR launch, where the hospital's EHR opens an app from inside its own interface with a per-session launch token, is not currently covered.
