I built Health Skillz to connect to EHRs via SMART on FHIR, but since all my own records are in Epic, I’d never bothered registering or testing it elsewhere.

Then a colleague wanted to pull her records from eClinicalWorks. I pointed GPT-6 Astra at the eCW developer portal and asked it to register an account, create an app, wire up the integration, and test it against their sandbox. I just fed it email and SMS verification codes when prompted.

The original federal deadline for rolling out these certified FHIR APIs was the end of 2022.

Watching the agent work through the integration exposed three classic EHR interoperability headaches—and showed how good agents have become at routing around them:

1. No CORS support on the FHIR APIs.

Pure in-browser SMART apps that talk directly to the EHR have been a core pattern since we demoed the Pediatric Growth Chart in 2014. Because eCW doesn’t set CORS headers, browser apps fail out of the box. Astra worked around this by standing up a small, stateless relay to proxy the requests. I hate having to do this: the privacy model is much cleaner when a patient’s data flows straight from the EHR to their browser without touching an intermediary server. eCW’s missing headers force an unnecessary trust relationship.

2. Broken asymmetric auth registration.

Astra first registered a JWKS URL for asymmetric client authentication. Then I received what looked like an automated email saying URLs outside certain categories would need network whitelisting, typically taking 2–3 business days, with no notification when it was done. It named categories like “Computer & Technology” and “Healthcare and Medicine,” but didn’t say which category our URL was in or whether we were waiting for review.

Astra’s access-token request, authenticated with a signed JWT, failed with 401 invalid_client. I then asked Astra to submit the JWKS directly so we could keep moving. It checked the registration form, the existing-app editor, and the portal’s JavaScript for saving JWKS settings, but couldn’t find a way to do it. The SMART spec requires servers to support both, and ONC tests asymmetric auth under AUT-PAT-30.

So I had Astra register a separate client using a symmetric client secret. That went through immediately. Another security and architectural downgrade we shouldn’t have had to make.

3. Hard failures on _count.

Once auth worked, the Patient read succeeded, but almost every resource search failed with an HTTP 400: "Unsupported query parameter(s): _count. These parameters are not allowed." _count is a standard FHIR parameter for page size. FHIR R4 allows smaller result pages and recommends ignoring unsupported parameters. eCW instead rejects the entire search. Astra inspected the error, added a vendor flag to strip _count for eCW, and relied on the server’s pagination links instead.

After deploying those fixes, Astra pulled 112 resources and four attachments from the sandbox, verified state persistence across page reloads, and tested token refreshes.

My colleague tried it against her live patient portal, and it worked on the first try.

It’s maddening that in 2026, connecting to a certified, “standards-based” API still requires a custom proxy, downgraded client auth, and per-vendor query flags. The silver lining is that an agent can now click through the registration portal, hit those walls, read the error logs, write the workarounds, and ship a working integration in a single session.