Written by Technical Team | Last updated 15.11.2025 | 9 minute read
Electronic medical record (EMR) interoperability has shifted from being a desirable objective to a non-negotiable requirement. Health systems are under pressure to share clean, timely and context-rich data with regional partners, national networks, virtual care platforms and patient-facing apps. Altera Sunrise sits at the centre of many acute and multi-site organisations as the core electronic health record (EHR) / electronic patient record (EPR), and its openness has increased significantly in recent years with API enablement, FHIR R4 support and new interoperability partnerships.
However, simply having interfaces enabled does not automatically deliver interoperability. The real value emerges when organisations design deliberate, well-governed integration pipelines around Sunrise, treating interoperability as a product rather than a collection of one-off interfaces. Building custom pipelines that work with Sunrise’s native capabilities – HL7 v2 messaging, read-only FHIR APIs, SMART on FHIR launch, Unity/Altera Connect APIs and new interoperability services – allows you to orchestrate data flows that are reliable, observable and future-proof.
This article explores how to design and implement those pipelines in a way that genuinely improves EMR interoperability, reduces technical debt and supports clinicians with richer, more complete information at the point of care.
Before attempting sophisticated pipelines, it is worth being explicit about what Sunrise can already do. Sunrise is designed as an open, interoperable EHR platform that supports acute and ambulatory workflows on a single clinical record. In the UK this is often delivered as Sunrise EPR, underpinning hospitals’ digital maturity programmes and integrated care initiatives. Its architecture supports integrations with departmental systems, imaging, patient administration systems (PAS), third-party decision support tools and external shared care platforms.
A cornerstone of modern interoperability is FHIR. Sunrise supports FHIR R4 and the SMART on FHIR application launch framework, enabling both standalone and EHR-launched applications to retrieve clinical data in a standardised way. This is especially powerful for embedding apps into clinician workflows: patient, encounter and organisation context can be securely passed from Sunrise into the app, allowing developers to build predictable and safe integrations.
At the same time, Sunrise has a deliberate separation between read-optimised APIs and transactional interfaces. FHIR is often read-only, providing safe and consistent visibility of clinical information. Write-backs and workflow-critical updates are handled through Altera Connect, Unity APIs or inbound HL7 v2 messages. Rather than being a restriction, this allows Sunrise to maintain data integrity while still offering modern interoperability options.
The platform is also increasingly integrated with national and regional data-sharing frameworks. Integrated care programmes, shared care records and emerging national data exchange platforms can be tied into Sunrise through FHIR, document exchange and HL7 messaging. Newer aggregation services provide real-time access to external patient data directly within Sunrise, reducing the need for clinicians to access multiple portals.
Understanding this landscape – FHIR for read access, SMART for app launch, Unity and HL7 for transactions, and external data aggregation services – is the critical foundation for designing realistic, robust and scalable integration pipelines.
A custom integration pipeline around Sunrise is more than an interface. It is an engineered flow that defines how data is captured, validated, transformed, routed, stored and monitored across the organisation. Thinking in terms of pipelines helps ensure that interoperability becomes repeatable and governed rather than a series of ad-hoc interface builds.
One of the first architectural decisions is choosing between a centralised integration engine or a more distributed architecture using microservices. A hub-and-spoke integration engine is often helpful for HL7 v2 traffic because it centralises message handling, mapping and monitoring. In contrast, API gateways and microservices work well for FHIR and REST-based interactions. In practice, most organisations end up with a hybrid: an integration engine for HL7 v2 and an API gateway for FHIR.
Another essential principle is adopting a canonical data model. Sunrise, partner systems and external data sources rarely share identical codesets or formats. To prevent downstream inconsistencies, you need robust mapping and terminology services that normalise SNOMED CT, LOINC, local codes, national identifiers and location structures. Without a consistent data model, interoperability quickly becomes unmanageable.
Custom integration pipelines typically follow predictable processing stages, regardless of the exact technology:
Separation of environments is another critical requirement. At minimum, your Sunrise integrations need development, test and production environments, each with realistic test data and connected test interfaces. Performance testing is also vital; poorly designed or unoptimised pipelines can affect perceived EPR responsiveness, even if Sunrise itself is performing well.
Most importantly, pipeline design must reflect clinical workflow. Technical correctness does not guarantee clinical usability. Integration teams need to work closely with clinical leaders to determine how external data is displayed, reconciled and prioritised. If data appears in the wrong clinical view or at the wrong time, clinicians may ignore it — undermining interoperability regardless of technical success.
Improving EMR interoperability around Sunrise depends on choosing the right standard for each workflow. HL7 v2 remains the backbone for event messaging — admissions, transfers, discharges, orders and results. FHIR excels at real-time API-based access. SMART on FHIR adds secure, context-aware launch mechanisms for embedded apps.
HL7 v2 interfaces are often the first layer of any Sunrise integration programme. ADT messages build the master patient and encounter context across systems. ORM and ORU messages manage orders and results between Sunrise and diagnostics. MDM messages transmit documents and clinical correspondence. These interfaces are typically orchestrated through an integration engine that validates structures, handles Sunrise-specific Z-segments and manages multi-site routing.
FHIR and SMART on FHIR complement HL7 rather than replace it. Sunrise publishes FHIR resources representing patients, encounters, medications, observations, conditions and more. SMART on FHIR enables applications to launch from inside Sunrise with contextual data, reducing manual re-entry and increasing safety. FHIR APIs are often read-only, so transactional updates are handled through HL7 inbound messages or Unity/Altera Connect APIs.
This leads to a common architectural pattern: use FHIR for clinical visibility and HL7 or Unity for transactions. For example, a SMART prescribing app may retrieve medicines and allergies through FHIR, conduct clinical decision support, and then write new orders back into Sunrise via HL7 ORM messages. To the clinician, the workflow appears seamless, even though multiple standards and pipelines are being orchestrated in the background.
As data-aggregation services mature, Sunrise can also surface external patient history directly within the EMR. This creates further opportunities for integration pipelines to normalise, store, reconcile or augment external data. For UK organisations interacting with shared care records, this mirrors the challenge of ingesting and reconciling multiple external FHIR feeds and documents into a unified clinical view.
Done well, these patterns turn Sunrise into an interoperability hub rather than an isolated system.
Once pipelines are built, they need to be operated like production-grade services. Many interoperability programmes collapse not because of design flaws but because of poor monitoring, governance or change control.
Testing is the first foundation. Any change in Sunrise, partner systems, FHIR profiles or HL7 message formats can cause failures. Automated test suites — spanning HL7 replay tools, FHIR validation scripts and full end-to-end workflow scenarios — are essential. High-volume and stress testing ensure that pipelines behave correctly during peak loads, such as large batch releases of discharge summaries or bulk appointment updates.
Monitoring and observability form the second foundation. A mature Sunrise integration landscape includes dashboards for throughput, latency, error rates, message queues, API utilisation and endpoint health. Alerts should be prioritised based on clinical impact. For example, a delayed ADT message feed is far more urgent than a slow non-clinical batch process. Many teams use “golden path” monitoring — ensuring that a full clinical workflow (admission → treatment → discharge) is uninterrupted.
Security and privacy must be designed into the pipeline. SMART on FHIR relies on OAuth 2.0 and OpenID Connect, issuing tightly scoped tokens. Unity, Altera Connect and HL7 interfaces require secure transport, network segmentation and strict credential management. Audit trails must show who accessed what and when, in compliance with local and national regulatory frameworks.
Governance ties all of this together. Strong interoperability governance ensures consistent standards, prioritisation and accountability. Effective governance frameworks often maintain:
Operational maturity is what transforms bespoke integrations into an enduring capability. It also accelerates future projects, because new partners can be onboarded into existing patterns rather than starting from scratch.
Interoperability is not a finite project but a long-term capability that must evolve with organisational strategy, national policy and technology shifts. A strong roadmap helps organisations get maximum value from Sunrise and avoid accumulating technical debt.
A good starting point is consolidation. Many organisations have grown an array of historical point-to-point interfaces that overlap or conflict. Rationalising these integrations, documenting them and aligning them with a canonical data model provides stability and clarity. Once the foundation is stable, attention can shift to higher-value initiatives such as embedding SMART on FHIR apps, connecting to regional shared care records, ingesting external data sources or enabling secure APIs for innovation partners.
Over time, architecture can evolve away from message-passing alone toward event-driven interoperability. FHIR subscriptions, near real-time event streams and bulk-data APIs can provide richer insights to analytics platforms, research environments and AI models. Semi-automated tools for schema mapping and FHIR resource generation can further reduce manual effort.
A future-proof roadmap is anchored in clear principles: standards first, open APIs, security by design, robust observability, and clinician-centred user experience. Every new integration should be evaluated against these principles. While legacy HL7 feeds will persist for years, they can co-exist with modern API-driven workflows within a coherent architecture.
Most importantly, the roadmap must remain focused on clinical value: ensuring that whenever a patient interacts with the system, their information is accurate, complete and available at the point of care.
By treating custom Altera Sunrise integration pipelines as a strategic capability rather than a technical afterthought, health organisations can unlock the full value of their EMR, reduce duplication and manual work, and create a foundation for truly connected care.
Is your team looking for help with Altera Sunrise integration? Click the button below.
Get in touch