Written by Technical Team | Last updated 15.11.2025 | 11 minute read
Altera Sunrise is a flagship electronic health record (EHR) platform from Altera Digital Health, providing an integrated acute and ambulatory solution that spans the continuum of care. It is designed to centralise clinician workflows and give care teams a single, consolidated view of patient information, whether they are working in inpatient, outpatient or community settings. For developers, the real power of Sunrise emerges when you start to treat it less as a monolithic application and more as a data platform that can be extended via standards-based APIs.
Altera’s FHIR APIs expose clinical data from Sunrise and related products through RESTful endpoints conforming to the HL7 FHIR R4 specification. The vendor has aligned its platform with FHIR R4 as part of compliance with major interoperability legislation and emerging national standards. For teams building integrations, this means that Sunrise behaves much more like any other modern web API: you authenticate, discover capabilities, then interact with resources using HTTP verbs and JSON.
The Altera Developer Portal plays a central role in this ecosystem. It provides documentation, registration for client applications, and test harnesses for FHIR access, including shared sandbox environments for Sunrise and TouchWorks. As a developer, you will typically start here: registering your app, obtaining sandbox credentials, exploring example data, and learning the idiosyncrasies of the particular FHIR implementation that Sunrise exposes.
Another important component is the FHIR Endpoint Directory. Altera maintains endpoint listings that identify FHIR base URLs for client organisations and environments, including sandbox and production deployments. In practice, this directory becomes part of your deployment pipeline: you may use it to validate connectivity, derive environment-specific base URLs, or automate configuration for multi-tenant applications that connect to multiple Sunrise instances.
Finally, it is worth recognising where Sunrise fits into a broader integration story. Altera also offers products such as dbMotion, which provide a FHIR R4 API over a harmonised, cross-organisational data layer. In some architectures, you will talk to Sunrise directly; in others, you may integrate with dbMotion’s FHIR endpoint to access a richer, longitudinal dataset that spans multiple systems. Understanding which FHIR endpoint you are actually integrating with is one of the first strategic decisions to make in any Sunrise project.
Before you write a single line of code, you should decide what kind of integration you are actually building. With Sunrise and Altera’s FHIR API, there are three common patterns: an embedded SMART on FHIR application launched from within the EHR context; an external web or mobile application that talks to Sunrise on behalf of a user; and backend services that use FHIR for server-to-server workflows such as population reporting or analytics. Each of these patterns implies a different mix of authentication flows, deployment constraints and performance expectations.
Altera’s FHIR API supports SMART on FHIR, the framework that layers OAuth 2.0 and contextual app launch semantics on top of FHIR. If you are building a clinician-facing tool that should appear inside Sunrise, SMART on FHIR will likely be your primary integration mechanism. Here, Sunrise launches your app with a specific patient, user and encounter context, and your responsibility is to use this context safely and effectively to call the FHIR API.
From a system design perspective, most teams will place their FHIR-aware services behind an API gateway or backend-for-frontend layer. This helps centralise concerns such as token management, rate limiting, logging and normalisation of FHIR responses across environments. It also allows you to shield client applications from breaking changes if Altera updates its FHIR implementation or introduces new profiles. For multi-site deployments, this gateway may also handle routing to different Sunrise or dbMotion endpoints depending on the organisation or tenant.
It is also important to think early about how FHIR fits with the rest of your interoperability stack. Many organisations running Sunrise will still use HL7 v2 messaging, proprietary APIs or flat-file integrations for certain workflows. A realistic architecture often combines FHIR R4 for interactive, request-response data access and legacy interfaces for batch or event-driven workflows. Carefully mapping which use cases will be FHIR-driven versus message-driven will prevent you from trying to force FHIR into areas where it adds little value.
As you shape your architecture, some questions are worth answering explicitly up front:
Answering these questions on paper before you open Postman or an SDK can save significant rework. The key is to remember that “we’re using FHIR R4” is not an architecture by itself. It is a powerful building block that must be shaped around genuine clinical workflows, organisational governance and the practical realities of Sunrise environments.
Most modern Sunrise integrations that involve human users rely on SMART on FHIR for authentication, authorisation and contextual launch. At a high level, SMART on FHIR standardises how an EHR launches an app—for example, from a button in a patient chart—and how that app obtains an OAuth 2.0 access token scoped to a particular user and patient. Altera’s implementation follows this model, exposing SMART-compliant endpoints through its FHIR API stack.
Your first technical step is to discover the FHIR server’s capabilities. Sunrise exposes a capability statement at the standard /metadata endpoint of its FHIR R4 base URL. Within this document you will find the OAuth 2.0 authorisation and token endpoints, supported SMART scopes and launch context parameters. It is good practice to have your app dynamically read these rather than hard-coding URLs; this makes it easier to target different Sunrise environments and future-proofs you against configuration changes.
Once you know where to send users for authorisation, you can implement the SMART App Launch workflow. When Sunrise launches your web app, it passes a launch parameter and an iss (issuer) parameter in the query string. The iss value is the FHIR base URL; the launch value is an opaque identifier tying your session to a particular launch context. Your app should redirect the user to the OAuth 2.0 authorisation endpoint with appropriate parameters, including client_id, redirect_uri, scope and the launch token.
After authentication, the authorisation server redirects back to your app with an authorisation code, which you then exchange for an access token at the token endpoint. The access token is included in the Authorization header of subsequent FHIR requests. In well-structured applications, this sequence is encapsulated within a dedicated authentication module, so the rest of your code can simply obtain a ready-to-use FHIR client.
Context handling is critical. After obtaining the access token, your app should inspect the launch context, which may include patient or encounter identifiers. Your app should treat these as authoritative for the session; do not allow users to arbitrarily switch patients without a corresponding SMART context change. It is also essential to respect granted scopes. If the token only includes read privileges, any write attempts should be disabled at the UI and code level.
SMART on FHIR is not limited to interactive clinician tools. Backend Services mode, using signed JWTs instead of user-driven OAuth flows, is also supported for system-to-system use cases. This model is suitable for analytics pipelines, quality reporting or cohort identification tasks that require large-scale access to clinical data without tying access to a specific user.
Once authentication is handled, the next challenge is interacting with FHIR R4 resources exposed by Sunrise. You can expect support for foundational resources such as Patient, Encounter, Observation, Condition, AllergyIntolerance, MedicationRequest, Immunization, DocumentReference, Organization and Location. Beyond this core set, availability may vary based on configuration, environment and regulatory requirements, making it important to inspect the capability statement early in development.
A key design consideration is whether to orient your application around generic FHIR R4 resources or to incorporate national or vendor-specific profiles. In the UK, for example, Sunrise supports UK Core where applicable, meaning a Patient resource may incorporate additional constraints, required identifiers or local extensions. Profiles improve consistency but require careful validation and awareness of what constraints your application must meet.
Efficient reading of data often depends on mastery of FHIR search operations. For example, if your application displays a clinical overview, you may need the current patient, their active encounter, recent observations and medication data. Rather than issuing multiple sequential requests, FHIR allows parameters such as _include, _revinclude, date filters and pagination. Optimised querying reduces latency and greatly improves usability, especially in healthcare environments where network conditions may be unpredictable.
Write operations require caution. While FHIR allows create, update and patch operations, local policies determine actual permissions. Many organisations initially permit only read access to external developers. When write access is granted, it often focuses on specific workflows such as questionnaires, tasks, notes or clinical documents rather than updates to core clinical data. To avoid duplicates, favour idempotent patterns such as conditional updates based on unique business identifiers.
Vendor-specific extensions are another element you will encounter. These exist to represent data not yet standardised in FHIR—such as bespoke bed management attributes or configuration flags. Extensions are legitimate and expected, but over-reliance on them may reduce your integration’s portability. A good strategy is to design an internal model that accommodates both standard and extended fields while clearly documenting Sunrise-specific dependencies.
When working with dbMotion as the integration point, the nature of the data set can change significantly. dbMotion provides a harmonised, cross-system dataset, meaning your FHIR queries may return data aggregated from multiple EHRs and community systems. This enables richer longitudinal applications but also adds complexity: normalisation layers, mapping rules and occasional discrepancies may appear. Validating assumptions against real-world workflows becomes crucial.
Once your Sunrise FHIR integration reaches production, operational considerations become vital. Performance is a common initial concern. Sunrise environments are shared clinical systems, so overly chatty FHIR clients can interfere with frontline workflows. Use caching for relatively static resources, and leverage ETags where supported to avoid re-fetching unchanged data. Efficient query design is one of the simplest ways to reduce strain on the system.
Error handling and observability matter just as much. FHIR servers return structured OperationOutcome resources for errors and warnings. Your logs should capture meaningful error information without exposing sensitive clinical data. That often means logging codes and summaries rather than full payloads. Monitoring patterns in error responses can reveal authentication issues, throttling events or changes in environment behaviour before they impact users.
Environment variability is another common challenge. Shared sandbox environments provide realistic behaviour but may not mirror the configuration, volume or customisation of production Sunrise systems. Treat sandboxes as tools for early development, not final validation. Securing access to customer-specific test environments is essential for ironing out differences in profiles, security settings and resource availability.
Security reviews and governance processes can introduce delays if unprepared. Even with SMART on FHIR providing solid authentication and authorisation foundations, organisations will expect detailed documentation: data flow diagrams, lists of accessed resources, scope usage, handling of patient identifiers, and consent considerations. Engaging information governance teams early accelerates approval and prevents last-minute surprises.
To keep your integration maintainable and resilient, many teams adopt a disciplined set of practices, including:
Above all, remain aware that Sunrise sits within a complex clinical ecosystem. FHIR R4 and SMART on FHIR offer powerful capabilities but do not eliminate real-world challenges such as network issues, clinical workflow constraints and organisational governance. Successful integrations are those built with empathy for clinical contexts, respect for system limitations and a commitment to continuous iteration.
When handled thoughtfully, Altera Sunrise becomes more than an EHR—it becomes a platform for innovation. By combining FHIR R4 standards with careful architectural planning, rigorous operational discipline and strong collaboration with clinical teams, developers can unlock new capabilities, enhance care coordination and contribute meaningfully to modern digital health transformation.
Is your team looking for help with Altera Sunrise integration? Click the button below.
Get in touch