Written by Technical Team | Last updated 15.11.2025 | 9 minute read
Electronic patient record (EPR) platforms such as Altera Sunrise are increasingly expected to behave less like monolithic systems and more like open, extensible digital ecosystems. NHS trusts and international health systems alike want to plug in best-of-breed applications, surface external services within the clinician’s workflow, and avoid unsafe copy-and-paste behaviour between systems. SMART on FHIR is now the de facto framework for doing exactly that.
When implemented thoughtfully, SMART on FHIR turns Sunrise from a largely closed EPR into a platform that can securely launch context-aware apps, share FHIR R4 data in real time, and respect local governance and consent rules. This article explores how to implement SMART on FHIR specifically for Altera Sunrise, with a focus on practical architectural decisions, security and identity concerns, and a staged implementation roadmap that works in complex provider environments.
SMART on FHIR combines two things: FHIR as the data model and API, and SMART (Substitutable Medical Applications and Reusable Technologies) as the authorisation and app-launch framework. In practice, SMART defines how a third-party or in-house application is registered, launched from an EPR, receives a secure access token via OAuth 2.0/OpenID Connect, and uses that token to call FHIR endpoints with tightly scoped permissions.
Altera’s Sunrise EPR is positioned as a single-platform solution for acute and ambulatory care, including a UK-specific Sunrise EPR offering for trusts that already have a PAS in place. Historically, integration has relied heavily on HL7 v2 and proprietary APIs. More recently, Altera has invested in FHIR R4–compliant APIs, with particular emphasis on support for the UK Core FHIR profiles where relevant, and has exposed these APIs through its developer portal and associated test harness.
Crucially, the Altera FHIR API explicitly supports the SMART App Launch framework and profiles OAuth 2.0 and OpenID Connect for authorisation. This means that Sunrise sites can adopt the same SMART on FHIR pattern used by other major EHRs, simplifying vendor-neutral app development and avoiding bespoke integration efforts for each new solution. For organisations, this provides a path to “plug-and-play” interoperability for decision support, imaging viewers, patient-facing tools and more.
The strategic benefits are not merely technical. SMART on FHIR allows clinicians to launch an app from within a Sunrise patient chart, automatically passing patient, encounter and user context so there is no need to manually search for the same record again. That reduces time, avoids data mismatches, and supports safer, more consistent workflows. It also enables trusts to selectively grant apps just enough access – for example, read-only access to Observations and Medications for a risk-stratification tool – rather than handing over an entire data extract. Over time, a curated catalogue of SMART apps integrated with Sunrise can become a key part of the organisation’s digital strategy and supplier ecosystem.
Before writing any code, it is worth explicitly designing how SMART on FHIR apps will sit alongside existing Sunrise components and trust infrastructure. A common pattern is to treat Sunrise as both the EHR user interface and the SMART “EHR FHIR server/authorisation server”, while your SMART apps sit in a separate application tier, often in a cloud environment that is integrated into the trust’s network.
At the heart of this architecture is the SMART launch sequence. A user working in Sunrise chooses to open a SMART-enabled app – for example from a menu link or an embedded tile within the patient record. Sunrise then redirects the user’s browser to the app’s registered launch URL, including a short-lived launch identifier and the FHIR server URL. The app uses this information to initiate an OAuth 2.0 authorisation code flow against the Sunrise authorisation endpoint, ultimately receiving an access token with specific SMART scopes and, optionally, an ID token containing user identity claims.
For Sunrise deployments, the FHIR server URL corresponds to the Altera FHIR API endpoint exposed for that environment (such as non-production, shared sandbox, or production). The developer documentation describes how to register an application, configure redirect URIs and launch URLs, and obtain credentials for the FHIR sandboxes used to test Sunrise integrations. Architecturally, it is sensible to treat these endpoints as separate per region and per environment, even if your SMART app is multi-tenant; this avoids inadvertently mixing data or configuration between organisations.
Another key decision is how tightly you want to embed SMART apps into the Sunrise UI. At one extreme, you can simply launch apps in a separate browser tab. At the other, you can embed them in an iframe within a Sunrise frame or viewer, giving a more seamless experience. Both patterns are valid, but iframes require careful consideration of performance, content-security policies and responsive layout so that the integration feels natural rather than bolted on.
To keep the design coherent, most organisations define a small set of standardised integration patterns and reuse them across all SMART apps. Typical decisions to standardise include:
Finally, the architecture must respect network boundaries and data residency. Many trusts deploy SMART apps into a secure cloud tenancy connected to the on-premise Sunrise environment via VPN or private peering. In these models, it is vital to ensure the EHR can reliably reach the apps’ launch URLs and redirect URIs, and that outbound connectivity from the app tier to Sunrise FHIR endpoints is stable, secure and monitored.
Security is foundational to SMART on FHIR and becomes especially important when exposing Sunrise data to external applications. Each SMART app is registered with a client identifier, redirect URIs and, in many cases, asymmetric keys for client authentication. Access tokens issued by Sunrise contain SMART-specific scopes such as patient/Observation.read or user/MedicationRequest.write, which determine the FHIR resources the app is authorised to call.
In NHS environments, identity and authentication must align with broader trust policies. Clinician authentication to Sunrise may occur via Active Directory, NHS Smartcard or an alternative identity provider, but the SMART on FHIR flow typically reuses that upstream authentication rather than prompting users to sign in again. This is achieved through single sign-on and token exchange: the user authenticates once to Sunrise, and Sunrise issues a SMART/OIDC token to the app that includes identity and role information. It is important to review exactly which claims are exposed and whether they support the app’s internal role-based access model.
Consent and legal basis must also be accounted for. For provider-facing apps launched from Sunrise, direct care usually forms the basis for information sharing, but organisations still need to document purposes of processing, retention, and any onward transfers to third-party services. Patient-facing SMART apps introduce more explicit consent workflows: patients authenticate against the organisation’s FHIR endpoints and grant access to specific parts of their record. Implementations therefore need to support consent revocation, scope restriction and clear communication about data usage.
Operational security must not be overlooked. SMART on FHIR introduces new event types that need monitoring: failed authorisation attempts, suspicious FHIR query patterns, or excessive API usage by certain apps. Establishing monitoring and alerting early—across Sunrise logs, the SMART/OIDC layer and the FHIR API—ensures security teams can detect and respond to anomalies. Ensuring audit trails are accessible for clinical safety investigations is equally important.
Implementing SMART on FHIR for Sunrise is best approached iteratively. A discovery and alignment phase is the first step, reviewing the existing integration landscape and identifying where SMART can deliver immediate value. This might involve pathway-specific decision-support tools, observational dashboards, mobile apps for clinical teams or patient-facing tools that require real-time Sunrise data rather than scheduled extracts.
Next, establish access to the developer portal and sandbox environments. Set up developer accounts, register test applications and familiarise yourself with the SMART authorisation endpoints, FHIR base URLs and supported resource types. It is also crucial to confirm which FHIR version is implemented (typically R4) and any optional capabilities available in your region.
A proof-of-concept SMART app is often the most efficient way to validate connectivity. This minimal app verifies that Sunrise can launch it correctly, that the OAuth 2.0 flow completes, and that key FHIR endpoints such as Patient or Observation can be queried reliably. Building this PoC with detailed logging accelerates troubleshooting across environments.
As you move into full-scale implementation, standardisation becomes increasingly important. Many organisations define a repeatable integration framework that includes:
Once apps are technically integrated, clinician engagement becomes critical. Even the most seamlessly embedded SMART app can be overlooked if it is not positioned at the right point in the Sunrise workflow. Work with configuration teams to ensure app launch points appear where clinicians expect them, whether on a patient chart, prescribing screen or care-pathway dashboard. Early adopters can provide feedback that informs optimisation before a wider rollout.
Once SMART-enabled apps are live, operational excellence ensures they continue to deliver value. Because SMART interactions rely on several components—the Sunrise UI, the authorisation server, the FHIR API, the network and the app infrastructure—monitoring must be comprehensive. Capture performance metrics, token-exchange errors, FHIR latency and user-facing response times. Bringing logs and telemetry together into a unified dashboard accelerates diagnosis during incidents.
Governance structures help maintain long-term quality. Over time, organisations might accumulate multiple SMART apps targeting similar use cases or overlapping datasets. A curated application catalogue, complete with clinical sponsors, data protection assessments and technical documentation, prevents duplication and ensures accountability. Regular reviews can evaluate whether an app still meets clinical needs, whether its permissions remain appropriate, and whether updates to Sunrise’s FHIR capabilities enable more elegant integration patterns.
SMART on FHIR should become a strategic pillar of integration rather than a tactical tool for isolated projects. For Altera Sunrise customers, this shift reduces reliance on bespoke message interfaces and enables a more modular interoperability ecosystem. With a well-governed approach, SMART on FHIR empowers internal developers, external suppliers and clinical innovators to build solutions that integrate safely and reliably with Sunrise.
By investing in a robust SMART on FHIR implementation—underpinned by clear architecture, strong security, a realistic roadmap and disciplined operations—healthcare organisations can transform Altera Sunrise into a genuinely open platform capable of supporting modern, data-driven care delivery.
Is your team looking for help with Altera Sunrise integration? Click the button below.
Get in touch