Written by Technical Team | Last updated 15.11.2025 | 11 minute read
Monitoring and observability for Altera Sunrise integration estates is ultimately about safeguarding safe, timely and accurate patient care. When Sunrise is the clinical backbone for an NHS trust or hospital group, every HL7 message, FHIR transaction and interface engine route translates directly into a ward round, a discharge, a prescription or a diagnostic result. An apparently “technical” degradation – a stuck ADT feed or a slow pharmacy interface – quickly becomes cancelled theatres, delayed admissions and frustrated clinicians.
Altera Sunrise is typically deployed as a modular electronic patient record (EPR) platform spanning core clinicals, order communications, eObservations, theatres, e-prescribing, pharmacy and an integrated PAS layer in many UK deployments. Around it sit integration tools such as Sunrise Integration Module (SIM), Sunrise eLink and third-party engines like Rhapsody or Mirth Connect, which handle HL7 routing and translation between Sunrise and diagnostic, specialist and legacy systems. These layers together form what this article calls “Altera Sunrise integration systems”.
Because these estates are complex, highly coupled and safety-critical, monitoring them cannot be left to generic infrastructure dashboards alone. What distinguishes a mature organisation is not just that it monitors CPU, memory and disk, but that it can answer, in real time: “Is Sunrise safely enabling patient care right now?” Achieving that demands a deliberate observability strategy that combines technical telemetry, clinical pathway awareness and operational governance.
Effective monitoring starts with a clear mental model of the integration landscape. A typical Sunrise deployment includes core Sunrise Clinical Manager and associated modules such as Pharmacy, Emergency Care and Surgical Care, connected to laboratory, radiology, PAS, bed management, ambulance and community systems. The Sunrise Integration Module and related connectors broker HL7 ADT, orders, results, MDM and other message types, often in concert with a central trust integration engine. An observability strategy must begin with an up-to-date integration topology showing these flows, including message directions, critical dependencies and failover paths.
Once the topology is understood, the next step is to establish a layered monitoring architecture. At the lowest layer sit infrastructure metrics for servers, virtual machines, container platforms and databases. Above that are application-level indicators from Sunrise components, interface engines and supporting services such as middleware and file transfer utilities. On top of this, a dedicated interface and workflow monitoring layer tracks message queues, routing, transformation success and end-to-end round-trip times for key clinical journeys. Bringing these sources together in a single observability platform is far more valuable than maintaining a patchwork of uncorrelated tools.
A critical design choice is to treat integration monitoring as a first-class domain within the trust’s wider clinical safety and digital operations framework. That means defining explicit service level objectives (SLOs) around clinical capabilities rather than just technology: for example, “95% of GP referrals appear in Sunrise within five minutes”, or “stat lab results for inpatients are visible within 10 minutes of analyser completion”. These SLOs drive what the monitoring actually measures. Without them, teams often collect large volumes of telemetry without being able to say whether care is materially compromised.
Security and data protection considerations must be woven into the observability foundation from the outset. Logging HL7 or FHIR payloads in full can be tempting for troubleshooting but can introduce unnecessary exposure of sensitive clinical data. Strong use of field masking, tokenisation and role-based access to logs is essential. Equally, auditability requirements for EPRs – such as tracking who accessed records and when – must not be undermined by monitoring approaches that duplicate or fragment audit data. Instead, observability should complement, not compete with, the platform’s own audit trails.
The telemetry that matters most in production Sunrise estates is that which reflects the health of clinical workflows. Traditional metrics such as CPU and memory utilisation are necessary but far from sufficient. Integration teams need a curated set of health indicators that reveal, at a glance, whether patients are being registered correctly, bed moves are flowing, orders are reaching downstream systems and results are returning in time for ward rounds and clinics.
A useful way to structure this is to think in terms of telemetry domains:
Interface telemetry is often the most immediately actionable. For Sunrise Integration Module and related connectors, monitoring should capture both transport-level errors (e.g., TCP connection failures, TLS issues) and message-level problems (e.g., schema validation failures, unknown codes, routing rule mis-matches). Queue depth and queue age are particularly important: a slowly growing queue might be tolerable overnight but critical during the morning bed management cycle. Visualising metrics by message type – ADT, ORM, ORU, RDE and others – helps teams quickly understand which pathways are affected.
Clinical workflow telemetry is what aligns monitoring with patient outcomes. For example, an observability dashboard might show the number of admissions, discharges and transfers flowing into Sunrise from the PAS per hour, alongside messages that failed to process. Spikes or troughs relative to expected patterns can indicate upstream problems before clinicians notice missing patients on their lists. Similarly, tracking the elapsed time between order entry in Sunrise, arrival at the laboratory system and return of a result can reveal performance degradations in downstream systems that would otherwise present as “the system is slow”.
Application and user experience telemetry round out the picture. Sunrise Pharmacy and e-prescribing, for instance, are highly sensitive to latency and error rates: slow order entry or frequent timeouts can lead to workarounds or delays in medication administration. Usage patterns, such as concurrent session counts or peak load windows for specific modules, inform capacity planning and change scheduling. Correlating user-visible errors with underlying integration failures allows teams to prioritise issues that materially impact care.
As organisations adopt solutions like Sunrise Axon to bring real-time, normalised external data into the EPR, telemetry around data aggregation and transformation becomes increasingly important. Monitoring must track upstream connectivity, data freshness, volumes by source and any transformation failures that may lead to incomplete or inconsistent views in Sunrise. When clinicians begin to rely on aggregated histories for decision-making, a silent failure in these pipelines can be just as dangerous as an obvious application outage.
Telemetry only becomes valuable when it informs the right actions. For Sunrise integration estates, alerting rules should be tightly aligned to SLOs and clinical risk assessments. A common mistake is to generate alerts directly from low-level metrics – such as CPU thresholds – without considering their impact on care, leading to noise, alert fatigue and missed critical issues.
Instead, alerts should be organised around clinical capabilities and critical flows. For example, a trust may structure its alerting around domains such as “Admissions and bed management”, “Emergency department workflows”, “Theatres and perioperative care” and “Medication ordering and administration”. Within each domain, alert conditions can be expressed in terms of message flow degradation, error rates or latency breaches that materially impair those capabilities. For example: “Trigger a major incident if more than 5% of ADT messages fail validation for five minutes”, or “Escalate if median stat lab turnaround exceeds the established threshold for a defined period”.
Runbooks are the operational translation of alerts into action. For a Sunrise Integration Module routing failure, a well-written runbook might guide the engineer through checking router health, reviewing recent configuration changes, inspecting queue depths, validating HL7 segment structures and, if needed, initiating a rollback or failover. The runbook should also state which clinical pathways are affected, propose temporary workarounds for frontline staff and provide predefined communication templates for digital nursing and clinical leads.
Incident response in an EPR environment demands clear coordination across IT operations, clinical safety officers, data protection teams and vendor support. For significant Sunrise or integration incidents, well-practised virtual “war room” structures help maintain order: roles such as incident commander, clinical liaison, integration lead and Sunrise application lead should be clearly defined. Trusts should also have criteria for when to escalate to Altera support or third-party system suppliers, and how to coordinate shared investigations.
Post-incident reviews are central to continuous improvement. These should not only catalogue technical failures but assess whether monitoring behaved as expected: Did telemetry detect the issue early? Were alerts delivered to the right people with adequate context? Did dashboards make the impact clear? These insights should inform refinement of metrics, dashboards and runbooks, strengthening the integration landscape over time.
Monitoring production Sunrise estates is not solely about detecting failures; it is equally about anticipating and preventing them. Capacity planning is a key example. By analysing historical telemetry on message volumes, concurrent user sessions, module throughput and infrastructure utilisation, organisations can identify cyclical or seasonal patterns. This is particularly valuable for trusts facing winter pressures, elective care surges or service reconfigurations.
Performance tuning is most effective when guided by real telemetry. If dashboards indicate that Pharmacy workflows slow at midday peaks, teams can correlate this with prescription volumes, automation interactions, clinical decision support load or database contention. Evidence-informed changes – such as adjusting indexing strategies, optimising caching, increasing application server capacity or revising message routing – can then be implemented and validated.
Release and change management benefit significantly from observability. Deploying new Sunrise modules, enabling new workflow features or integrating new partner systems all introduce risk. A disciplined, telemetry-driven approach uses three phases:
For large-scale transformations – such as onboarding a new hospital, adopting new datasets via Sunrise Axon or decommissioning legacy systems – telemetry can help model expected load and validate assumptions. For example, message volume analysis from existing sites can be used to forecast load for a new site before cutover, supporting right-sizing of databases, integration servers and application tiers.
Observability also improves change timing. By analysing usage and workflow patterns, teams can identify low-risk change windows and revise them as operational models evolve. Some observability platforms can enforce “change guardrails”, flagging attempted deployments during high-risk periods such as winter escalation or major clinical reporting windows.
Because Altera Sunrise deployments often sit at the heart of NHS digital strategies, monitoring and observability must be governed as strategic capabilities. Many organisations benefit from establishing a cross-functional observability working group or embedding observability oversight within existing governance structures. Representation typically includes IT operations, integration specialists, clinical informatics, clinical safety, information governance and vendor liaison roles.
A key governance deliverable is a set of standard observability requirements for Sunrise and its integrations. These may mandate that every new interface exposes core metrics, uses consistent log formats and propagates trace identifiers end-to-end. They may also require that any new clinical workflow has defined SLOs and monitoring dashboards before go-live. Such standards prevent fragmentation of the monitoring estate as the EPR footprint expands.
Auditability is an important dimension. Observability data can materially improve the ability to reconstruct events during clinical incidents, data quality issues or cybersecurity investigations. Message traces, transformation logs and time-stamped metrics provide valuable evidence on whether data were transmitted, received and presented correctly. However, observability platforms must be secured with robust access controls, retention rules and audit trails to meet regulatory obligations. Careful design ensures useful diagnostics without unnecessary duplication of patient-identifiable data.
Embedding continuous improvement closes the loop. Regular observability reviews can evaluate whether current telemetry, alerting and dashboards support operational and clinical objectives. Insights from incidents, service desk patterns, optimisation projects and new Sunrise capabilities can all feed into iterative refinement. Over time, organisations evolve from reactive monitoring to proactive service improvement, where observability becomes a core contributor to digital clinical maturity.
Ultimately, monitoring and observability strategies for production Altera Sunrise integration systems are not about dashboards alone. They are about ensuring that a hospital’s digital nervous system functions reliably, safely and efficiently. By grounding observability in clinical workflows, selecting telemetry that reflects patient impact and governing it as a strategic asset, NHS organisations can ensure that Sunrise continues to enable high-quality care even as demands, technology and expectations evolve.
Is your team looking for help with Altera Sunrise integration? Click the button below.
Get in touch