Written by Technical Team | Last updated 23.07.2026 | 23 minute read
Same Day Emergency Care, commonly known as SDEC, is designed to give suitable patients rapid specialist assessment, diagnosis and treatment without an unnecessary overnight admission. It is not simply a renamed assessment unit, nor is it an administrative mechanism for moving patients out of the emergency department. A mature SDEC service is a distinct clinical operating model in which referral, streaming, investigation, treatment, review and discharge are deliberately organised around completing an episode of care on the same day wherever it is clinically safe to do so.
For organisations using Optum Symphony as part of their urgent and emergency care environment, the success of SDEC depends heavily on integration. Symphony may provide important emergency-care functions, but an SDEC pathway almost never exists within one application. The patient may be referred by a GP, NHS 111, an ambulance clinician, a community service or an emergency department practitioner. Their demographics may originate in a patient administration system. Their blood tests are processed by a laboratory information management system, imaging is handled through radiology and PACS platforms, medicines may be recorded in an electronic prescribing system, and the completed episode may need to update the trust’s electronic patient record and the patient’s registered GP.
An effective Optum Symphony integration must therefore do more than transfer messages between systems. It must create a dependable clinical and operational thread across the complete same-day journey. Staff need to know why the patient was referred, whether the referral has been accepted, where the patient is physically located, which investigations are outstanding, who owns the next clinical action, whether the patient is expected to return, and whether the episode has been safely concluded. Data must be available at the point at which decisions are made, not hours later in a downstream reporting database.
Key point: Effective Optum Symphony integration for Same Day Emergency Care (SDEC) is not simply a collection of NHS system interfaces. It must connect referrals, patient administration, diagnostics, clinical workflow and discharge communication into one reliable, real-time patient journey. Clear data ownership, accurate patient and episode matching, resilient messaging and visible responsibility for outstanding actions are essential to delivering safe same-day emergency care without unnecessary hospital admission.
The engineering challenge is to support speed without sacrificing safety. SDEC pathways are intentionally fast-moving, but the underlying technology cannot assume that every patient follows a straight line from arrival to discharge. Some patients deteriorate and require admission. Some return the following day for planned treatment or review. Others are redirected before arrival, transferred to another specialty or discharged with safety-netting and community follow-up. Integration must represent these changes accurately, retain a clear audit trail and avoid creating contradictory versions of the patient’s status in different systems.
The first step in an Optum Symphony integration is to model the patient journey before designing interfaces. Many integration programmes begin with a list of systems and message types: PAS to Symphony, laboratory to Symphony, Symphony to the data warehouse and so on. That approach is technically convenient but clinically incomplete. Interfaces should be derived from the decisions that staff must make throughout the pathway. The integration team should begin by identifying the major SDEC events, the information required at each event and the system that is authoritative for each data item.
A typical journey may start before the patient reaches the hospital. A GP, ambulance service or NHS 111 clinician may contact an SDEC service and provide a reason for referral, current observations, relevant history, suspected diagnosis and information about immediate risks. The SDEC team may accept the patient, reject the referral, request additional information or advise a different route. This pre-arrival decision is operationally important because it affects staffing, capacity and the urgency of assessment. If the referral arrives only as unstructured text, a telephone note or an email, staff may need to re-enter data manually and the patient may be invisible to operational dashboards until registration.
Where local systems permit it, the integration should create a structured pre-arrival record or expected-attendance state. This record must be clearly distinguished from a confirmed physical arrival. Confusing the two can distort waiting-time calculations, create false occupancy figures and lead staff to believe that a patient is present when they have not yet reached the unit. A robust model normally separates referral received, referral clinically accepted, attendance expected, patient arrived, initial assessment completed, treatment underway, decision made and episode closed.
Registration should reuse trusted demographic data wherever possible rather than prompting repeated entry. Matching should ordinarily consider the NHS number alongside local identifiers, name, date of birth, address and other demographic attributes. Exact NHS-number matching alone may be insufficient when data has been entered incorrectly, while loose demographic matching can link the wrong records. Integration rules should therefore distinguish between a confirmed match, a probable match requiring human verification and a new patient record. Any automated matching process must expose uncertainty rather than silently selecting the closest candidate.
Once the patient arrives, SDEC staff need a single operational view of the episode. That does not necessarily mean that all information must be stored in Symphony, but it does mean Symphony users should be able to see the status of the information they depend on. For example, a clinician may not need the entire laboratory record to be replicated, but they need to know which tests have been requested, whether a specimen has been collected, whether results are available and whether any result requires urgent review. Similarly, imaging status should make it clear whether an examination has been requested, scheduled, performed, reported or cancelled.
The design should explicitly support the following pathway events:
The planned-return pathway deserves particular attention. Same-day care does not always mean that every element of treatment is completed in one uninterrupted visit. A patient may be discharged home and asked to return for a repeat blood test, scan, infusion, clinical review or ambulatory procedure. The integration must represent this as a planned continuation of care rather than an accidental duplicate attendance. Staff should be able to distinguish a new deterioration from a scheduled review, and reporting should avoid counting the return incorrectly as an unrelated emergency episode.
Patient location and clinical ownership must also be modelled separately. A patient may be registered under an SDEC service while physically waiting in the emergency department, radiology department, assessment area or discharge lounge. Equally, the patient may be physically present in SDEC while clinical responsibility has transferred to another specialty. A single overloaded “status” field cannot reliably convey location, ownership, acuity and stage of care. These concepts should be represented as separate attributes or derived from clearly defined events.
The journey ends only when the episode has been clinically and administratively reconciled. A discharge event should not be treated as complete merely because a user has clicked a discharge button. The integration should establish whether the clinical summary has been finalised, medicines and follow-up arrangements have been recorded, the GP communication has been queued or delivered, outstanding results have an identified owner, and the destination has been recorded accurately. This approach prevents the system from presenting a technically closed episode that still contains unresolved clinical work.
The integration architecture should reflect the reality that Optum Symphony is likely to sit within a mixed estate containing both modern APIs and long-established healthcare messaging. Many NHS organisations continue to rely on HL7 version 2 interfaces for admissions, discharges, transfers, orders and results, while FHIR-based APIs are increasingly used for structured access to clinical information and newer digital services. Document exchange may involve additional standards, messaging platforms or locally defined formats. A sound design accommodates this mixture without allowing each interface to develop its own incompatible interpretation of the patient journey.
An integration engine is commonly used to receive, validate, transform, route and monitor messages between Symphony and surrounding platforms. Its role should extend beyond basic field mapping. It should manage acknowledgements, enforce identifiers, apply terminology mappings, prevent uncontrolled duplication, handle retries and provide an operational view of message health. Business rules that affect patient safety should not be buried in undocumented transformation scripts. They should be specified, version-controlled, tested and reviewed with clinical input.
The organisation must identify a clear system of record for each important data domain. The patient administration system may be authoritative for core demographics and organisation-wide encounter identifiers. Symphony may be authoritative for emergency and SDEC workflow events. The laboratory system is authoritative for validated pathology results, while the radiology information system and PACS govern imaging workflow and reports. The electronic prescribing platform may hold the legal medication order and administration record. The EPR or document repository may provide the longitudinal clinical record. Integration should distribute information without obscuring these ownership boundaries.
Ambiguous ownership produces predictable failure modes. If Symphony and the PAS can both independently modify a patient’s discharge destination, the values may diverge. If an order is altered in one system but merely copied into another, staff may act on an outdated version. If observations are entered in multiple applications without a reconciliation rule, clinicians may not know which reading is current. The architecture should therefore define not only where data is stored but also where it may be created, corrected, cancelled and clinically verified.
Identifiers are central to this design. A single SDEC episode may contain an NHS number, hospital number, PAS encounter number, Symphony attendance identifier, referral identifier, order number, specimen identifier, imaging accession number and document identifier. These should not be treated as interchangeable. The integration layer must preserve the relationship between them and support traceability from a downstream result or document back to the correct patient, episode and order. Locally generated identifiers should be globally unique within the organisation’s integration scope and should never be recycled.
ADT-style messaging can support patient registration, arrival, transfer and discharge, but the local meaning of each event must be agreed. A “transfer” might represent a physical movement, a change of specialty, a change of responsible consultant or a purely administrative update. Sending every change as the same type of event can trigger incorrect actions downstream. Message specifications should define which source action generates each event, which fields change, whether the event is reversible and what consuming systems are expected to do.
Orders and results require equally careful correlation. A request created in Symphony may be sent to an order communications platform, laboratory system or radiology system. The resulting report must return against the original request and attendance, including amended or corrected results. The interface should preserve lifecycle states rather than treating the first result as final. Preliminary, partial, final, corrected and cancelled statuses have different clinical meanings. A corrected report should not simply appear as a second unrelated result, and the original value should not disappear without an audit trail.
The design should account for results that arrive after the patient has left SDEC. In a fast same-day pathway, this is not an exceptional edge case. Some tests are deliberately followed up after discharge, and others are delayed unexpectedly. Integration should make the result visible to the responsible team, support worklist generation and record acknowledgement. The route should be determined by an agreed clinical policy rather than an assumption that the patient’s original clinician remains available.
An event-driven architecture can improve responsiveness by publishing significant changes as they occur: patient arrived, triage completed, order placed, result finalised, discharge initiated or referral accepted. However, event-driven integration does not remove the need for reconciliation. Messages can be delayed, duplicated, delivered out of order or missed during downtime. Periodic comparisons between authoritative systems can identify episodes that are open in one platform and closed in another, results that lack a matching order or patients whose demographic updates have failed to propagate.
Where APIs are available, the integration should use explicit contracts, authentication controls, rate limits and versioning policies. APIs should not be assumed to be inherently safer or more modern than messaging. A poorly governed synchronous API can create tight dependencies that stop clinical work when one system is unavailable. For time-critical SDEC functions, the design should decide which calls must succeed immediately, which can be queued asynchronously and what information remains available during partial failure.
The architecture should also minimise unnecessary replication. Copying an entire longitudinal record into Symphony may increase privacy exposure, storage requirements and reconciliation complexity without improving the SDEC decision. A better approach is often to retrieve or present focused information such as current medications, allergies, recent encounters, active problems and relevant care plans. The selection must be clinically led and should include provenance, author, date and source so that users understand the context.
SDEC integration should be engineered around failure because failures will occur. Networks become unavailable, certificates expire, queues fill, interfaces receive malformed messages and downstream services enter maintenance windows. The clinically important question is not whether a component can fail but whether the organisation can detect the failure, understand its effect and continue safe care.
Each interface should define its failure behaviour. If Symphony cannot obtain demographic updates from the PAS, can users register a patient safely using a temporary process? If laboratory orders cannot be transmitted, how are staff warned and what manual route is approved? If results are delayed, does the system display an explicit outage indicator or merely continue showing an empty results panel? Silent failure is particularly hazardous because it encourages users to interpret absence of data as evidence that no data exists.
Resilience is stronger when the integration layer supports durable queues, idempotent processing and controlled replay. Durable queues protect messages during a temporary outage. Idempotency allows a repeated message to be processed without creating a duplicate attendance, order or document. Controlled replay enables engineers to recover failed transactions after correcting the underlying issue. Replay must preserve the original event time and audit context; otherwise historical messages can appear to be new clinical activity.
Message ordering also matters. A discharge event may arrive before an earlier transfer update, or a corrected result may be processed before the original result after a queue is restored. Interfaces should use timestamps, sequence information and business-state validation rather than assuming that arrival order equals clinical order. Where an incoming event conflicts with the current state, the integration should quarantine it for review or apply an agreed reconciliation rule.
Operational monitoring should focus on clinical consequences, not only technical uptime. A dashboard showing that an interface process is running does not prove that useful data is flowing. Monitoring should include message volumes, processing latency, rejection rates, queue depth, acknowledgement failures, unmatched identifiers and unusually quiet feeds. Alert thresholds should reflect the service. Ten minutes without a pathology result may be normal overnight in one setting and a serious warning during a busy daytime SDEC session.
Useful service measures include:
Usability must be treated as part of integration engineering. An interface can be technically accurate while producing a poor clinical experience. If staff must open several screens to discover whether a scan has been reported, the integration has not adequately supported the pathway. If the same referral information appears in multiple locations with different timestamps, the user may not know which version is current. If alerts are too frequent or non-specific, they will be ignored.
The most effective design presents information according to the task being performed. At streaming, staff need the referral reason, current acuity, infection risks, mobility needs and indications that SDEC may be appropriate. During assessment, clinicians need observations, history, medicines, allergies and relevant prior information. During active management, the emphasis shifts to orders, results, treatment plans and pending actions. At discharge, the interface should bring together diagnosis, medication changes, follow-up, safety-netting, transport and outstanding-result ownership.
Clinical decision support requires restraint. Rules can help identify deterioration, contraindications, overdue actions or incomplete discharge information, but they can also add friction and alert fatigue. Any rule that changes prioritisation or recommends a clinical action should have a clear evidence base, defined scope, ownership and review process. The integration should record the data used by the rule and whether the user accepted, rejected or overrode its output. It should also handle missing data explicitly rather than interpreting a missing observation as a normal observation.
Role-based access is necessary because SDEC crosses professional and organisational boundaries. Reception staff, nurses, advanced practitioners, pharmacists, doctors, specialty teams, discharge coordinators and operational managers require different functions. Access should follow legitimate clinical and operational need, while sensitive records and restricted data require additional controls. Authentication, session management and single sign-on should reduce unsafe workarounds without granting broader access than necessary.
Audit logging should reconstruct meaningful clinical activity. It should record who viewed or changed information, the patient and episode concerned, the originating system, the previous and new values, and the time of the action. For integration events, the audit should include message identifiers and processing outcomes. Logs must be protected from alteration, retained according to policy and searchable during incident investigation.
Downtime procedures should be designed alongside the live solution. Printed forms, local spreadsheets and verbal handovers often emerge when systems fail, but unmanaged workarounds create additional risks when service is restored. The recovery process must define how manually recorded referrals, orders, treatments and discharges are entered retrospectively, how duplicates are prevented and who confirms that the electronic record is complete. A downtime test should include recovery and reconciliation, not simply prove that staff can continue on paper.
Data quality in SDEC is an active clinical-safety issue. The pathway relies on rapid decisions, and incorrect or incomplete data can change whether a patient is accepted, how urgently they are reviewed and whether they can be discharged safely. Integration teams should therefore assess data quality in terms of clinical fitness, not merely whether mandatory fields are populated.
Referral data is a common source of variation. Free-text referrals may contain rich clinical reasoning but are difficult to route, prioritise and analyse consistently. Highly structured forms improve standardisation but can encourage superficial completion or omit nuance. A balanced design uses structured fields for information that drives workflow, such as referral source, presenting problem, observations, infection risk and mobility, while retaining a narrative section for clinical context.
Terminology mapping should be governed centrally. Local codes for specialties, destinations, attendance types, diagnoses and outcomes often differ between applications. A direct one-to-one mapping may not exist. Forcing several local concepts into one destination code can remove clinically or operationally important detail, while creating excessive local variants reduces comparability. Mapping decisions should be documented with owners, effective dates and handling rules for retired or unknown values.
The distinction between SDEC, emergency department care, outpatient activity and admission must be represented consistently. A patient’s physical location alone does not reliably define the care model. Local reporting categories should be derived from agreed clinical and administrative rules, and changes to those rules should be tested against operational dashboards and statutory reporting. Otherwise, a technically small configuration change can alter apparent performance without changing patient care.
Clinical-risk management should cover the integrated service rather than treating each interface as an isolated technical component. Hazards may arise from data being absent, delayed, duplicated, attributed to the wrong patient, displayed without provenance or presented after it has been superseded. Risks can also emerge from workflow design, such as allowing discharge before an outstanding-result owner is recorded or showing an accepted referral without making clear that the patient has not arrived.
A clinical safety case should link identified hazards to controls, evidence and residual risk. Controls may include validation rules, user confirmation, visible status indicators, queue monitoring, reconciliation reports, training, role restrictions and downtime procedures. Testing evidence should demonstrate that controls operate across realistic scenarios, including failure and recovery. It is not enough to show that a message succeeds when all systems are available and the data is perfect.
Privacy and information governance should be embedded in the architecture. Only information necessary for the SDEC purpose should be exchanged or displayed. Interfaces should use secure transport, managed identities, appropriate encryption and controlled service accounts. Non-production environments should avoid identifiable patient data unless an approved and protected approach is in place. Logs should not inadvertently expose clinical content to staff who do not have a legitimate reason to view it.
Testing should combine technical, workflow and clinical perspectives. Unit testing validates transformations and business rules. Interface testing confirms connectivity, acknowledgements and error handling. End-to-end testing follows a patient through connected systems. Clinical scenario testing examines whether the information supports safe decisions. Performance testing assesses peak demand and backlog recovery. Downtime testing confirms business continuity. User acceptance testing establishes whether staff can operate the pathway as intended.
Test data should include more than straightforward adult attendances. Scenarios should cover duplicate demographics, missing NHS numbers, patients whose names have changed, unknown patients, safeguarding restrictions, corrected laboratory reports, cancelled imaging, planned returns, non-attendance, deterioration requiring admission and discharge followed by a late critical result. The highest-risk scenarios are often those that cross boundaries between ordinary workflows.
Deployment should be controlled through clear entry and exit criteria. Before go-live, the organisation should know which interfaces are essential, which can be deferred and which manual controls remain temporarily in place. There should be named owners for technical incidents, clinical escalation, data quality and operational decisions. Go-live support should include representatives who understand both the systems and the SDEC workflow, because many early incidents appear technical but originate in ambiguous operating procedures.
After implementation, governance should continue through change control. A modification to a referral form, status value, diagnostic interface or discharge process can affect several systems and reports. Changes should be impact-assessed, clinically reviewed where relevant, tested across interfaces and communicated to users. Supplier upgrades to Symphony or connected applications should be assessed for changes to schemas, APIs, field lengths, code sets, authentication methods and user-interface behaviour.
The purpose of Optum Symphony integration for SDEC is not to maximise the number of interfaces. It is to make safe same-day care easier to deliver. The implementation should therefore be judged by whether it improves the reliability and speed of the pathway, reduces avoidable manual work and gives staff a trustworthy view of what needs to happen next.
A well-integrated service can make referrals visible before arrival, reduce repeated demographic entry, provide faster access to diagnostic status, clarify clinical ownership and support complete discharge communication. It can also improve operational awareness by showing demand, capacity, waiting patients, pending actions and likely discharges. These benefits depend on disciplined workflow design; automating an unclear process usually makes inconsistency faster rather than removing it.
Measures should connect technical performance with patient and service outcomes. Interface availability is useful, but it should be considered alongside referral-to-assessment time, diagnostic turnaround, length of stay in SDEC, conversion to admission, unplanned return, outstanding-result follow-up and discharge-summary completion. A change in one measure should be interpreted carefully. For example, a reduction in recorded SDEC duration may indicate improved flow, but it could also result from inaccurate arrival or discharge timestamps.
The integration should support learning at patient, pathway and population levels. At patient level, staff need clear information about the current episode. At pathway level, teams need to identify delays such as referrals awaiting acceptance, patients waiting for imaging or discharges blocked by medication. At population level, analysts may examine referral patterns, demand by time of day, common conditions, admission conversion and outcomes. These uses should be planned from the outset so that operational data has consistent definitions and adequate provenance.
Reporting should not depend entirely on extracts taken after the event. Near-real-time operational views can help teams respond during the day, while validated retrospective datasets support governance and planning. The two should be related but not assumed to be identical. Operational dashboards may use provisional states that later change, whereas formal reporting may apply reconciliation and coding rules. Users should understand the purpose and limitations of each view.
Successful delivery also requires attention to people and service design. Integration changes who enters information, where decisions are recorded and how work is handed over. Staff should be involved in designing screens, statuses, alerts and exception processes. Training should focus on the patient journey and the meaning of system states rather than only demonstrating which buttons to press. Superusers and floor support can identify mismatches between the designed process and real clinical work.
A phased implementation is often safer than attempting every interface at once. The first phase might establish reliable demographics, attendance management and discharge communication. Later phases can add structured referrals, diagnostic status, electronic orders, planned returns, workflow alerts and more advanced analytics. Each phase should deliver a coherent improvement rather than a disconnected technical component.
The integration programme should also maintain a clear boundary between standardisation and local flexibility. Common data definitions, safety controls and interface patterns reduce complexity and make support easier. However, SDEC services vary by specialty, estate, workforce and local urgent-care pathways. Configuration should accommodate legitimate differences without allowing every team to create its own undocumented statuses and workarounds.
Ultimately, Optum Symphony integration for Same Day Emergency Care should create continuity across a fragmented digital environment. The patient should not experience repeated questions because systems cannot share reliable information. Clinicians should not have to infer whether a referral has been accepted, whether a result is final or who is responsible for follow-up. Operational teams should not need to reconcile several contradictory lists to understand current demand.
Which NHS clinical safety standards apply to Optum Symphony SDEC integration?
The Symphony supplier should provide relevant DCB0129 clinical safety evidence, while the deploying NHS organisation should complete its responsibilities under DCB0160. The local assessment should cover the configured SDEC workflow, connected interfaces, upgrades, downtime arrangements and any locally developed automation.
Should Optum Symphony SDEC connect to the NHS Personal Demographics Service?
Access to the NHS Personal Demographics Service can help verify NHS numbers, current demographics and registered GP details. This may be provided through the trust’s PAS rather than through a direct Symphony connection, depending on the organisation’s architecture and approved Spine access model.
How should Optum Symphony support ECDS and APC reporting for SDEC?
The clinical workflow should be separated from the statutory reporting configuration. Because national guidance concerning SDEC, the Emergency Care Data Set and Admitted Patient Care has changed, mappings should remain configurable and be validated by the trust’s informatics, coding and contracting teams before implementation or upgrade.
Can Optum Symphony integration send SDEC appointment reminders?
An integrated SDEC pathway can trigger patient communications through NHS Notify or an approved local platform. Useful messages include pre-arrival instructions, planned-return reminders, cancellations and follow-up information delivered through SMS, email, the NHS App or letter, with delivery outcomes recorded where possible.
What assurance should NHS trusts request when procuring Optum Symphony for SDEC?
Trusts should request evidence covering supported Symphony versions, available APIs and message specifications, DCB0129 documentation, DTAC requirements where applicable, performance limits, disaster recovery, audit capabilities, test environments, upgrade compatibility and supplier support arrangements.
Is your team looking for help with Optum Symphony integration? Click the button below.
Get in touch