Written by Technical Team | Last updated 15.11.2025 | 9 minute read
Connecting modern clinical applications to Altera Sunrise is no longer just a technical integration problem; it’s a security, safety and governance challenge as well. Sunrise, as an enterprise Electronic Patient Record (EPR) platform used across NHS Trusts and internationally, increasingly exposes FHIR-based APIs and integration points that can be accessed using OAuth2 and related standards such as SMART on FHIR. Getting OAuth2 right is what stands between you and a serious data breach, an unhappy Information Governance team, or worse, a patient safety incident.
This article walks through a pragmatic, engineering-focused approach to designing and implementing secure OAuth2 workflows specifically for integrating with Altera Sunrise. It assumes you are building either a clinical-facing application (used by staff within a Trust) or a patient-facing or partner application that needs controlled access to Sunrise data via FHIR APIs and related services. Along the way, you’ll see how to balance usability, clinical workflows, regulatory expectations and operational realities.
Rather than treating OAuth2 as a box-ticking exercise, the aim here is to help you build an integration that will stand up to penetration tests, NHS assurance, clinical safety review and the scrutiny of experienced security architects — and still be pleasant for clinicians and patients to use.
Altera Sunrise sits at the heart of clinical workflows as an EPR platform, with modules for core clinicals, orders, observations, theatres, e-prescribing, patient administration and more. To interoperate with surrounding systems, Altera exposes FHIR-based APIs that allow applications to exchange structured clinical data in line with the FHIR standard. These APIs provide a consistent interface for resources such as Patient, Encounter, Observation, MedicationRequest and others, giving you a modern HTTP/JSON integration surface rather than legacy point-to-point interfaces.
On top of FHIR, Altera offers SMART on FHIR support. SMART on FHIR defines a profile of OAuth2 and OpenID Connect designed specifically for healthcare applications, including standardised scopes and launch context. In practice, that means your application can be launched from Sunrise, receive a context token, perform an OAuth2 authorisation code flow, and then call the FHIR APIs with an access token that encodes user identity, roles and permissions.
From an architecture perspective, you’ll be working with one or more of three broad patterns:
Understanding which pattern you’re implementing is not just a design choice; it directly determines which OAuth2 flows are appropriate, how tokens are structured, and what additional controls (such as SMART contextual constraints or identity provider integration) are expected.
Finally, it’s worth recognising that Sunrise exists within a wider ecosystem: NHS APIs, identity providers, integration engines, trust-wide single sign-on and network security controls. A secure OAuth2 workflow for Sunrise should be designed as part of that ecosystem, not as a special case. That means reusing existing IdPs where appropriate, aligning with NHS security patterns, and making sure you treat Sunrise as one of several high-value clinical systems you integrate with, rather than a one-off.
The most common pattern you’ll encounter when building Sunrise integrations is a SMART on FHIR app launched from within the EPR. In this scenario, OAuth2 is not just a login mechanism; it is the foundation of your authorisation model. The gold standard is the authorisation code flow with PKCE, using short-lived access tokens and, where appropriate, refresh tokens tightly constrained in scope. This reduces exposure to token leakage and supports modern client types.
In user-launched SMART scenarios, your first design decision is around scopes and least privilege. SMART on FHIR defines fine-grained scopes such as specific read/write permissions on individual FHIR resources. Instead of defaulting to broad or catch-all scopes, map your user stories to specific resources and operations. If your Sunrise integration is a decision support tool that only needs to read observations and medications, do not request write access or unrelated resource scopes. This reduces risk and simplifies assurance.
For system-to-system integrations, the pattern is typically an OAuth2 client credentials flow, or a JWT bearer flow where your backend signs a JWT trusted by Sunrise. The key here is segmentation: each integration should have its own identity, keys and scopes, rather than sharing credentials across environments or use cases. This allows isolation, revocation and more granular operational control.
There are several anti-patterns that should be avoided:
A more secure approach is to treat OAuth2 credentials as ephemeral. Use short-lived access tokens, rotate refresh tokens, and detect token replay or suspicious usage patterns. For mobile and browser-based apps that cannot safely hold secrets, rely on PKCE, secure device keychains and external identity services.
To maintain consistency and safety across multiple Sunrise-connected applications, many organisations benefit from defining a small set of approved OAuth2 patterns. These might include:
By constraining the patterns you support, you simplify implementation, reduce risk and make it easier for governance and security teams to maintain oversight.
The biggest security failures in OAuth2 implementations rarely arise from the protocol itself but from poor operational decisions. For Sunrise integrations, where patient data and clinical operations are at stake, designing for defence-in-depth is critical.
Start with token design. Keep access tokens short-lived and tightly audience-scoped so they can only be used against the intended Sunrise API endpoint. Include only the minimal claims required for authorisation decisions. This reduces exposure if a token is intercepted and ensures that identity details are not unnecessarily leaked.
Secret management is also vital. Client secrets and signing keys should never be stored in source code repositories or informal password stores. Instead, use an enterprise-grade secrets manager or a hardware security module-backed vault. Apply regular rotation policies, enforce strong access controls, and maintain auditable logs for all secret access.
Identity is another key pillar. Many health organisations already maintain a centralised identity provider for staff. Integrating your Sunrise-linked OAuth2 flows with that IdP allows you to benefit from MFA, corporate password controls, account lifecycle management and established role-based access models. Avoid duplicating user accounts or creating parallel identity silos unless absolutely necessary.
Beyond direct OAuth2 mechanics, reinforce your system with network and application-level protections. Ensure TLS 1.2+ is enforced end-to-end. Apply API gateway policies for rate limiting, input sanitisation and client behaviour monitoring. Track suspicious access patterns, invalid token attempts and unusual scope usage. Feed these signals into your central monitoring systems so abnormal activity is identified early.
Together, these layers significantly reduce the chance that a misconfiguration, leaked token or compromised client will lead to harmful data exposure or unintended actions within Sunrise.
Integrating with Sunrise in a UK healthcare context means your OAuth2 strategy will be scrutinised through NHS-specific lenses, not just generic cybersecurity principles. Security, Information Governance (IG), data protection and clinical safety frameworks shape what “secure integration” means at an organisational level.
From a data protection standpoint, OAuth2 scopes form part of your demonstrable commitment to data minimisation. Every scope you request should map to a justified purpose within your Data Protection Impact Assessment (DPIA). Overly broad scopes raise red flags with IG teams and complicate your documentation. Minimising scopes not only improves security but also strengthens your GDPR compliance posture.
The NHS Data Security and Protection Toolkit (DSPT) requires organisations to evidence robust technical and organisational measures around systems that access NHS data. Your OAuth2 design — including token lifetimes, revocation processes, client registration workflows and audit capabilities — forms part of that evidence. If you rely on cloud identity providers or external authentication services, you must also document how they align with NHS standards and organisational security policies.
Clinical safety is another major factor. UK standards such as DCB0129 and DCB0160 require health IT systems to identify and mitigate hazards that could affect patient safety. OAuth2 workflows may introduce clinical risks if, for example, incorrect users are bound to tokens, patient context is not enforced, or system downtime causes silent data access failures. These risks must be logged, assessed and mitigated as part of your safety case.
In practice, this means working closely with clinical safety officers to ensure that OAuth2 interactions — including user identification, role enforcement, and patient context management — are correctly represented in hazard logs and safety reports. Implement guardrails such as consistent patient context binding, clear error messaging and real-time user identity verification.
Finally, consider the broader NHS integration landscape. If your application may later connect to national APIs or external services, design your OAuth2 strategy in a way that is compatible with standard NHS patterns. Standardising early will pay off in smoother onboarding and reduced rework in future integrations.
Building a secure OAuth2 workflow is not a one-off technical task. Real security comes from continuous oversight, testing and governance once your integration is live.
A strong observability model captures OAuth2-related signals across the full flow — from authorisation server events to application behaviour and FHIR API access patterns. Centralise logs for token issuance, failures, revocations, invalid scope requests, PKCE mismatches and Sunrise API denials. Build visual dashboards that allow security teams to quickly spot anomalies such as sudden spikes in activity from a client or repeated token failures.
Your testing approach should include both automated and manual methods. Beyond simple success-path token exchanges, test failure conditions: expired tokens, revoked refresh tokens, incorrect scopes, malformed JWTs and unexpected launch contexts. For Sunrise-specific integrations, confirm that patient context is always applied correctly, especially during SMART launches. Security testing should include penetration tests and targeted red-team exercises with a focus on OAuth2 token handling and associated identity controls.
Governance ensures long-term consistency and safety. Establish a clear client registration process that includes approval of scopes, justification of access requests and periodic review. Maintain a catalogue of approved OAuth2 patterns and reference implementations that developers can follow. Conduct regular audits of registered OAuth2 clients to retire unused or outdated configurations.
It is also helpful to maintain a roadmap that tracks changes in relevant standards, identity services and organisational requirements. Keeping your OAuth2 model aligned with evolving best practices prevents technical debt and ensures you remain compliant with changing NHS expectations.
Finally, create channels for feedback from clinicians and end users. OAuth2 issues often manifest as user frustration — unexpected logouts, confusing redirects, missing permissions or inconsistent patient context. These symptoms often point to deeper architectural or configuration issues. Addressing them not only improves security but also enhances the quality of clinical workflows.
Is your team looking for help with Altera Sunrise integration? Click the button below.
Get in touch