Written by Technical Team | Last updated 20.03.2026 | 21 minute read
Digital health has moved beyond static patient portals and isolated integrations. Modern care delivery now depends on connected applications that can surface clinical context inside workflows, support remote monitoring, enable patient self-service, automate operational tasks, and help clinicians act on data without switching endlessly between systems. In that environment, SMART on FHIR has become one of the most important foundations for health app development. It gives product teams, healthcare providers, EHR vendors and digital health companies a practical framework for building applications that can connect securely to clinical systems, launch in context, and retrieve structured healthcare data in a way that is far more standardised than older integration approaches.
What makes SMART on FHIR especially powerful is that it joins two essential layers of interoperability. FHIR provides a modern API model for healthcare data, using web-friendly patterns and reusable resources such as Patient, Observation, MedicationRequest, Encounter and CarePlan. SMART adds the secure application launch and authorisation framework around that data layer, allowing apps to request only the access they need and to work either inside an EHR session or as standalone applications. Together, they create a route for building clinical apps that are not only useful, but portable, governable and capable of scaling across organisations.
For digital health teams, that matters enormously. Building one bespoke integration per hospital is not a sustainable growth model. It slows procurement, increases maintenance costs, complicates security reviews and turns every new customer into a custom engineering project. SMART on FHIR changes the commercial and technical equation. Instead of reinventing authentication, access control and clinical data retrieval for each deployment, teams can design against a common set of patterns. That does not make implementation trivial, because healthcare never is, but it does make repeatable delivery much more realistic.
The strongest SMART on FHIR products are not simply “API-connected apps”. They are workflow-aware, clinically responsible, security-first applications built around real user needs. A symptom checker embedded in a patient portal, a medicines reconciliation tool launched from the clinician workspace, a virtual ward dashboard, a digital therapeutics companion app, a discharge support solution, a coding assistant, or a care coordination tool for community services can all sit on the same underlying approach. The differentiator is not whether they can fetch data, but whether they can do so safely, performantly and in a way that respects the complexity of healthcare delivery.
That is why development teams need to think beyond basic connectivity. The real challenge in SMART on FHIR development is designing apps that are trustworthy under pressure. Clinical software has to behave well when patient context changes, when permissions are narrower than expected, when APIs are incomplete, when users have little time, when data are messy, and when governance teams demand proof that the application deserves access to sensitive records. Success comes from combining standards literacy with disciplined engineering, robust security design and a grounded understanding of clinical operations.
SMART on FHIR is best understood as an application framework for secure access to FHIR-based healthcare data. FHIR defines the structure and exchange model for health information. SMART defines how apps discover endpoints, authenticate, obtain authorisation, request scopes, receive launch context and use tokens to call FHIR APIs. In practical terms, this means a third-party app can be launched by an EHR, patient portal or another FHIR-enabled platform, receive the necessary context for that session, and then retrieve or write data according to the permissions granted. That model is far more aligned with modern software architecture than the older world of point-to-point HL7 v2 interfaces, document transfers and proprietary APIs.
The launch model is one of the reasons SMART on FHIR has become so influential. A clinician-facing app can be opened from within the patient chart, inherit patient or encounter context, and start work immediately without forcing the user to search again for the same person. A patient-facing application can connect to a portal or health record source through a standalone flow, obtain permission from the user, and then retrieve records through the same standardised framework. This ability to support both embedded and standalone experiences makes SMART on FHIR relevant across care delivery, patient engagement, operational automation and population health.
A common mistake is to treat SMART as merely an access mechanism. In reality, it shapes product design choices from the beginning. Because authorisation is scope-based, teams need to define precisely what data the application needs and why. Because launch context can vary, teams need to decide what the app can do when a patient, encounter or practitioner context is present and what happens when it is not. Because user-facing and backend patterns differ, teams need to distinguish between applications acting on behalf of an authenticated user and server-to-server services performing scheduled, system-level tasks. SMART on FHIR therefore influences architecture, UX, governance, testing strategy and commercial deployment.
It also changes how software vendors should think about interoperability maturity. A product is not truly SMART on FHIR ready just because it can parse a few FHIR resources. It must be able to handle discovery, launch, token exchange, context negotiation, token refresh, error handling and permission-aware data access reliably. It should behave predictably when the server grants less access than was requested. It should understand that “standard” does not mean “identical”, because different environments expose different capabilities, resource profiles and implementation nuances. Teams that appreciate that reality build applications that survive real deployments; teams that ignore it often end up with brittle demos rather than production systems.
From a market perspective, SMART on FHIR also supports a more modular future for healthcare software. Providers increasingly want the freedom to add specialist tools without waiting for their core platform vendor to build everything themselves. Regulators, standards bodies and procurement teams have all pushed the ecosystem in that direction by favouring open APIs, stronger patient access and more portable innovation. SMART on FHIR does not eliminate vendor dependency altogether, but it creates a stronger basis for substitutability. That is important for startups seeking market entry and equally important for established providers trying to reduce lock-in.
For digital health leaders, the broader lesson is this: SMART on FHIR is not simply a technical choice. It is an operating model for scalable clinical integration. It supports a future in which apps can be introduced faster, assessed more consistently and governed more cleanly. The organisations that benefit most are the ones that treat standards compliance as part of product strategy rather than as a late-stage implementation task.
Security in digital health is never a bolt-on concern, and SMART on FHIR makes that clear. Its architecture is built around modern authorisation patterns, but those patterns only deliver safety when the application is designed correctly. Teams need to understand the difference between public and confidential clients, between user-facing launch flows and backend services, and between broad access requests and tightly scoped permissions. They also need to appreciate that access to clinical data is not just a technical privilege; it is an ethical and regulatory responsibility. A poorly designed authorisation flow can expose patients, erode trust and derail deployment long before an application proves its clinical value.
At the centre of SMART security is the principle of delegated access. The application does not simply log into the EHR with a hard-coded service account and take whatever data it wants. Instead, it requests permission through a structured flow. It receives tokens for specific purposes and specific scopes. This supports least-privilege access and makes it easier for health systems to reason about what the app can do. A well-designed SMART app asks for the minimum necessary permissions, explains those permissions clearly, and avoids the temptation to request broad access “just in case”. That restraint is not only good security hygiene; it is a commercial advantage during technical due diligence.
Another essential concept is context. In a clinician launch flow, the application may receive patient or encounter context from the host system. That sounds simple, but it creates design obligations. The app must trust only the context established through the authorised flow, not through arbitrary query parameters or client-side assumptions. It must handle context changes carefully. It must avoid mixing data across patients if multiple tabs or sessions are open. In clinical software, context leakage is one of the most dangerous classes of defect because it can produce the appearance of correctness while showing the wrong information to the wrong user. Strong session isolation, state validation and disciplined token handling are therefore foundational, not optional extras.
Modern SMART implementations also depend on robust OAuth and OpenID Connect practices. Public apps cannot rely on embedded secrets for security, so they need correct use of code exchange protections, redirect validation and secure token storage. Confidential apps must protect their credentials or keys properly and ensure that key rotation, environment separation and auditability are built into operations. Browser-based apps must be especially careful with token exposure, cross-origin behaviour and front-end storage decisions. Teams that move fast with generic web patterns often discover that healthcare integration raises the stakes of every security assumption.
A secure architecture should include, at minimum, the following engineering practices:
Security should also shape the user experience. Consent screens, connection flows and authorisation prompts must be understandable to real users, not just to developers or security reviewers. A patient should know what an app is requesting and why. A clinician should understand whether an application is operating with patient-specific context or user-level access. An administrator should be able to review configurations without reverse-engineering the app. Good security communication reduces support burden and improves adoption because people are more likely to trust software that is transparent about access.
One area that deserves much more attention is secondary use. Many digital health teams begin with a workflow use case, such as launching an app to display observations or support a care pathway. Over time, they become interested in analytics, training models, product telemetry or longitudinal cohort insights. SMART on FHIR can support access patterns that contribute to those ambitions, but development teams must separate immediate clinical workflow access from broader data processing goals. Using a launch-derived token for purposes that were not clearly communicated or governed is a fast route to compliance trouble. Architecture needs clear lines between transactional use, operational reporting, de-identified analytics and product improvement activities.
Healthcare buyers are also becoming more sophisticated in their security questions. They want to know whether the app can operate with restricted scopes, how it handles denied permissions, whether it can revoke access cleanly, whether every API call is attributable, and whether it degrades safely when data access is incomplete. SMART on FHIR gives vendors a standard way to answer many of those questions, but only if the implementation reflects genuine maturity. Security theatre will not survive procurement scrutiny, and it certainly will not survive a major incident review.
Scalability is where many promising digital health applications falter. A prototype that works beautifully against one sandbox often becomes fragile when deployed across multiple health systems. The reason is that standards reduce variation, but they do not remove it. Different EHRs, portals and FHIR platforms expose different capabilities, resource profiles, search behaviour, performance characteristics and implementation constraints. Even within the SMART on FHIR model, developers must contend with differences in launch support, granted scopes, available resources, paging behaviour, write capabilities, terminology handling and operational governance. Building for scale means designing for that variability from the start.
The first principle of scalable SMART on FHIR development is capability awareness. Your app should discover and adapt rather than assume. Endpoint discovery, supported scopes, launch types and conformance signals should inform runtime behaviour. If a platform supports patient-level read access but not certain write interactions, the app should still provide value in a read-only mode rather than failing wholesale. If a launch arrives without the encounter context your workflow prefers, the application should respond gracefully with a context-aware fallback. Products that assume the perfect environment rarely scale; products that negotiate intelligently do.
The second principle is resource discipline. FHIR makes it easy to imagine that every app should fetch everything, but real-world performance punishes that mindset. Clinical applications need to retrieve only the data required for the task at hand, in the order that supports user value. That means prioritising problem-focused data retrieval, using search parameters carefully, respecting pagination, and caching within safe boundaries where appropriate. A medicines review app does not need the entire longitudinal chart before rendering its first meaningful screen. A remote monitoring dashboard does not need to query every possible resource type on load. Scalable apps understand the difference between what is available and what is necessary.
The third principle is abstraction. Teams should build an internal interoperability layer that decouples product features from vendor-specific quirks. Instead of scattering raw FHIR calls throughout the application, create services that normalise core workflows: patient summary retrieval, observation timelines, medication lists, care team views, appointment context, document fetches and order creation where supported. This allows you to account for profile differences, terminology mapping and server behaviour in one place. It also makes testing far more manageable. A scalable product is rarely the one with the most direct API calls; it is the one with the most disciplined integration boundary.
A practical SMART on FHIR scaling strategy often includes these building blocks:
Scalability is not only technical. It also includes onboarding speed and operational repeatability. If every customer deployment requires weeks of manual registration, custom mapping and one-off testing, your architecture may be technically standards-based but commercially unscalable. Strong teams invest early in deployment automation, connection playbooks, environment configuration templates and reusable security documentation. They know which settings must vary per organisation and which should remain fixed. They create implementation guides for customers that reduce ambiguity. They treat integration enablement as a product capability rather than a professional services afterthought.
Another underappreciated factor is data quality variance. Clinical apps frequently encounter incomplete coding, inconsistent use of profiles, missing timestamps, duplicated observations, legacy identifiers and local conventions layered onto standard resources. A scalable SMART on FHIR app does not collapse when the data are imperfect. It uses validation, ranking, reconciliation and sensible UI signalling to separate “no data”, “not available”, “not supported” and “uncertain”. In healthcare, graceful handling of ambiguity is part of scalability because the app must work not only across systems, but across the realities of documentation practice.
Finally, teams need to think about scaling beyond user-facing apps. SMART on FHIR also supports backend and service-level scenarios that matter to digital health growth: scheduled risk stratification, referral automation, document processing, population management, quality reporting support and cross-system workflow orchestration. These use cases often rely on system-level scopes and machine-to-machine authentication rather than interactive user launches. They can be powerful, but they should be architected separately from front-end launch flows. Blending them carelessly into one application stack increases complexity and risk. Mature platforms distinguish interactive clinical experiences from backend services while reusing common controls for policy, auditing and interoperability.
The best SMART on FHIR apps are not just connected; they are clinically useful. That sounds obvious, yet many interoperability projects still optimise for technical success rather than workflow success. An app can complete the launch sequence perfectly and still fail in practice because it interrupts attention, overloads the user with raw data, duplicates existing tasks, or provides recommendations without enough context. Clinical apps live or die in moments of use. They need to reduce friction, support decisions, and fit naturally into environments where time is limited and consequences are real.
Workflow fit starts with humility. Most clinicians do not want another destination. They want the right function at the right moment with as little context switching as possible. SMART on FHIR enables embedded experiences, and that should influence design. When launching inside an EHR, the app should open quickly, recognise the current task, and present an obvious first action. It should not ask the user to re-identify the patient, repeat information already available in the host system, or navigate through a consumer-style onboarding flow better suited to a lifestyle app. In clinical settings, relevance beats richness.
This is where data design matters. FHIR resources are flexible and comprehensive, but users do not think in terms of resources. They think in terms of questions: what is happening with this patient, what changed, what needs attention, what can I do next, and what is the risk of delay or error? The application should translate interoperable data into clinically legible views. That may mean a medication timeline instead of a raw list, an abnormality summary instead of a long observations table, or a task-oriented pre-assessment screen instead of a dump of encounters and conditions. The more the app exposes its underlying data structures directly, the more cognitive load it imposes.
There is also a governance dimension to UX. If an app writes data back into the record, creates orders, proposes documentation or triggers downstream workflows, users need confidence in provenance. They should know what came from the EHR, what came from the app, what has been inferred, and what still requires human confirmation. This is especially important in AI-assisted applications, where interoperability may provide the source data but the app adds summarisation, recommendations or automation. SMART on FHIR makes data exchange possible; it does not absolve the product team from designing safe human oversight.
Some of the most valuable product decisions in SMART on FHIR projects are surprisingly simple:
Patient-facing apps deserve equal care. SMART on FHIR has been central to patient access and consumer-mediated data sharing, but good patient UX requires more than successful authentication. Record data can be clinically coded, chronologically messy and emotionally difficult to interpret. A patient app that simply mirrors raw clinical records may technically satisfy access requirements while delivering very little practical value. Better products translate the record into understandable structures, explain terminology, flag uncertainty, support next steps and maintain strong privacy expectations. They also respect that not all users have high health literacy, modern devices or uninterrupted connectivity.
Another best practice is designing for partial interoperability. Many deployments will not support every resource, every interaction or every launch pattern your product roadmap envisions. Rather than seeing that as failure, treat it as a design condition. Build modular user journeys. Let features degrade in a safe, intelligible way. Offer alternate paths where patient or clinician input can supplement missing data. Surface what the app can do now rather than what the ideal future platform might eventually enable. In healthcare, incremental value often beats aspirational completeness.
It is also wise to be cautious about over-personalisation. Because SMART on FHIR can provide detailed user and patient context, teams sometimes try to infer too much too quickly. There is a difference between being workflow-aware and being presumptuous. A product that jumps to conclusions based on sparse context can undermine trust. Better to be context-sensitive, explicit about confidence, and respectful of uncertainty. Clinicians and patients are more likely to adopt tools that behave conservatively and transparently than ones that seem clever but unpredictable.
Ultimately, the UX question for any SMART on FHIR app is not “can we access the data?” but “how do we turn standards-based access into a safer, clearer and faster clinical experience?” Teams that answer that question well create products that are remembered for outcomes, not just for integration.
A durable digital health product has to survive changes in regulation, standards evolution, procurement expectations, hosting models and customer maturity. SMART on FHIR helps with future-proofing precisely because it is standards-based, but future-proofing does not happen automatically. Teams need to make architectural and organisational decisions that keep the product adaptable as the ecosystem changes.
One of the most important decisions is to treat standards support as a product capability with ownership, roadmap and investment. Too many companies let interoperability become a thin middleware layer maintained reactively. That approach fails as soon as new customers require broader scope handling, new launch patterns, additional FHIR versions, richer consent experiences or stronger machine-to-machine controls. A better model is to maintain an interoperability platform function inside the product team. That function owns standards tracking, conformance testing, cross-customer lessons, reference implementations and reusable components. It prevents integration knowledge from becoming tribal and makes the organisation faster over time.
Testing is central to this maturity. SMART on FHIR applications should not be validated only by happy-path demos in vendor sandboxes. They need repeatable tests for launch behaviour, scope negotiation, token lifecycle, error handling, profile variance and performance under realistic loads. They also need regression protection whenever dependencies, security libraries or authorisation handling change. Conformance tools and public test frameworks can help, but they should sit inside a wider engineering discipline that includes contract tests, synthetic data scenarios, negative testing and deployment-specific acceptance criteria. In healthcare, one broken authentication edge case can block an entire go-live.
Future-proofing also requires a sober view of versioning. FHIR evolves, implementation guides evolve, and customer environments may adopt standards at different speeds. The right strategy is seldom to chase every new release immediately, nor to freeze indefinitely on whatever worked first. Instead, create compatibility layers, maintain version-aware adapters and plan deprecation deliberately. Product teams should know which resources and interactions are core to the value proposition, which are optional, and which can be substituted if a server’s support is limited. Flexibility in the interoperability layer gives the business room to respond to market shifts without destabilising the whole application.
Commercial readiness matters too. Providers and health systems increasingly assess SMART on FHIR vendors not only on technical capability but on evidence of operational maturity. They expect security documentation, architectural clarity, onboarding guides, data flow descriptions, support models and transparent handling of permissions and auditability. A future-proof product organisation prepares these assets as part of its go-to-market machinery. It understands that trust is built before the first API call is made.
There is also a strategic opportunity here. As digital health products mature, the winners are likely to be those that combine standards-based interoperability with strong product focus in narrow clinical or operational domains. General-purpose integration alone is unlikely to be defensible. The more compelling position is to use SMART on FHIR as the delivery mechanism for a highly valuable capability: medication optimisation, pathway orchestration, remote monitoring escalation, pre-operative assessment, maternity support, virtual wards, oncology navigation, revenue cycle intelligence or patient communication. Standards make access possible, but domain excellence creates differentiation.
In the years ahead, SMART on FHIR will continue to matter because healthcare needs applications that are secure, modular and capable of working across organisational boundaries. But the market will become less impressed by connectivity on its own. Buyers will expect evidence that apps can scale responsibly, integrate with minimal disruption, respect patient and clinician trust, and deliver measurable value from the first deployment onwards. That raises the bar for developers, which is a good thing. It rewards the teams that build carefully.
The most successful digital health companies will treat SMART on FHIR not as an interoperability badge, but as an engineering discipline. They will invest in resilient launch flows, least-privilege access, data-aware UX, deployment automation, conformance testing and product strategies that turn standards into repeatable value. In doing so, they will build clinical apps that are not just connected, but credible. Not just deployable, but scalable. Not just compliant, but genuinely useful in the places where healthcare is delivered every day.
Is your team looking for help with Digital Health development? Click the button below.
Get in touch