By Ubaid Pisuwala, Co-Founder & CTO, Peerbits
LinkedIn: Ubaid Pisuwala
LinkedIn: Peerbits
A SMART on FHIR integration that works perfectly in a sandbox rarely tells you anything about how it will behave in production. I have watched this play out the same way more than once: a pilot app authenticates cleanly against a vendor’s public test server, pulls patient context without issue, and gets signed off by a technical team that is understandably relieved after weeks of setup. Then the same app goes live at an actual health system, and within the first week, sessions start dropping, scopes come back different from what was expected, and someone is paged because a clinician can no longer see the data the app was built to display.
None of this happens because the SMART on FHIR specification is flawed. It happens because a demo environment and a production environment test two different things, and most implementation timelines are built around the one that is easier to meet.
Sandbox Sessions Do Not Behave Like Production Sessions
Public sandboxes are designed to make onboarding fast, which means they are also designed to be forgiving. Token lifetimes in a sandbox are often short and predictable, and refresh flows rarely get stressed the way they do once real clinicians are opening and closing an app dozens of times a day across a full shift. A team that builds and validates its token refresh logic exclusively against sandbox behavior is validating the easy case. The failures that matter- silent re-authentication errors, expired sessions that do not surface a clear error to the user, and tokens that refresh correctly in isolation but not under concurrent use- only show up once real usage patterns start hitting the system.
Every Production Instance Is Its Own Approval Process
This is the part that catches technical teams off guard even when they know it intellectually. A SMART app that has been approved and tested against one health system’s Epic instance is not automatically approved anywhere else. Each customer instance typically requires its own registration, its own review, and its own production credentials, and that per-site approval process commonly runs four to six weeks per site. A rollout plan built around a single successful pilot deployment, without accounting for this per-instance overhead, will consistently run behind schedule the moment it tries to scale past one site.
The Specification Is Standardized. The Implementations Are Not.
SMART on FHIR and the underlying FHIR data standard define a consistent contract on paper, but every EHR vendor implements that contract with its own gaps, undocumented behaviors, and proprietary extensions. Two systems that both claim FHIR R4 conformance can still disagree on how they populate an optional field, how strictly they enforce a scope, or how they represent a value in an edge case the specification left ambiguous. A team that tests against one vendor’s sandbox and assumes the behavior generalizes across every EHR it plans to connect to is building on an assumption the market does not actually support.
Scope Handling Fails Silently, Not Loudly
A common assumption in early builds is that the scopes an app requests are the scopes it receives. In production, that is often not true. Users, administrators, and organizational policy can all narrow what gets granted, and an app that does not explicitly check the scope field on its token response will eventually hit an unexpected access error with no clear explanation for the user or the support team fielding the complaint. The SMART App Launch specification itself is explicit that granted scopes can differ from requested scopes, which makes this a documented behavior teams still routinely build around incorrectly.
What Production Readiness Actually Requires
Closing this gap is less about writing more code and more about testing a different set of conditions before go-live. That means running token refresh under realistic session lengths and concurrent use, not just a single clean pass. It means budgeting the per-site registration and credentialing timeline into the project plan from day one instead of treating it as an afterthought once the pilot succeeds. It means validating against more than one EHR vendor’s actual behavior rather than assuming sandbox conformance generalizes. And it means building explicit scope verification into the application logic rather than assuming the token response will always match the request.
A sandbox environment answers one question: can this integration technically work? Production asks a different one: will it keep working reliably across every site, every session, and every edge case the specification allows but does not guarantee? Teams that treat those as the same question are the ones who find out the difference during their first real go-live instead of before it.