How Sectra PACS Connects with RIS, EPR and HIS Platforms

A Sectra picture archiving and communication system, or Sectra PACS, rarely operates as an isolated clinical application. Its value depends on how effectively it exchanges information with the wider healthcare technology environment, particularly the radiology information system, electronic patient record and hospital information system. Together, these platforms coordinate the patient journey from registration and referral to image acquisition, interpretation, reporting and follow-up care.

The connection is more complex than simply passing images between systems. A dependable integration must keep patient identities aligned, communicate examination orders, maintain scheduling information, supply imaging devices with accurate worklists, return diagnostic results, open the correct images from the clinical record and record workflow status changes. It must do this without introducing duplicate patients, mismatched studies, lost reports or unsafe delays.

Sectra PACS integration therefore combines clinical workflow design with healthcare interoperability engineering. Technologies such as DICOM, HL7 version 2, DICOMweb, web application interfaces, IHE integration profiles and, increasingly, FHIR-based services each address different parts of the problem. Understanding where these standards fit is essential when connecting Sectra PACS to a RIS, EPR or HIS.

The role of each system in an integrated imaging workflow

The terms RIS, EPR and HIS are sometimes used loosely, and their responsibilities often overlap. This can cause confusion during integration projects because the same workflow function may sit in different systems at different healthcare organisations. One hospital may use its EPR as the main source of imaging orders, while another may pass orders from the HIS into a dedicated RIS. A third may use a combined RIS and PACS product with parts of the scheduling and reporting workflow tightly linked within one platform.

A hospital information system traditionally manages broad administrative and operational information across the healthcare organisation. It may support patient registration, admissions, discharges, transfers, appointments, billing, bed management and departmental activity. In an integrated environment, the HIS is frequently an authoritative source of patient demographics and encounter information. When a patient is registered or their details change, the HIS can send the relevant update to downstream systems, including the RIS and Sectra PACS.

An electronic patient record, sometimes called an electronic health record or electronic medical record, presents a more clinically focused view of the patient. It typically contains diagnoses, observations, medications, referrals, clinical documents, test results and links to diagnostic images. For many clinicians, the EPR is the principal application used throughout the working day. Sectra PACS must therefore connect to the EPR in a way that gives authorised users rapid access to imaging without forcing them to search for the patient or examination again.

The radiology information system manages the operational workflow of the imaging department. Depending on the implementation, it can receive imaging requests, support vetting and protocol selection, schedule appointments, track patient attendance, manage examination status, coordinate reporting and distribute results. The RIS may also create the data used to populate modality worklists, although the technical worklist service can be provided by the RIS, the PACS or a dedicated broker.

Sectra PACS is primarily responsible for receiving, managing, storing, displaying and distributing medical images and related information. It provides diagnostic worklists and viewing tools for radiologists, as well as clinical viewing capabilities for other healthcare professionals. In broader enterprise imaging deployments, the same platform may manage content from cardiology, pathology, ophthalmology, orthopaedics and other image-producing specialties.

A useful way to view the architecture is to separate the responsibilities into three connected information domains. The HIS or EPR establishes who the patient is and why they are receiving care. The RIS manages what imaging activity has been requested and how the imaging department will perform it. Sectra PACS manages the resulting images, the diagnostic interpretation workflow and access to imaging content. The integration layer ensures that all three domains refer to the same patient, encounter, order and examination.

The boundaries are not fixed. An EPR may contain its own radiology ordering and scheduling modules, reducing the role of a separate RIS. Sectra may be deployed with integrated workflow functions that replace or supplement parts of a traditional RIS. A regional imaging network may also connect several EPRs and hospital systems to one shared Sectra environment. Successful integration begins by identifying the authoritative system for every important item of data rather than assuming that a particular product category always owns it.

How patient, order and examination data move between the platforms

Most imaging workflows begin with patient identity. Before an examination can be ordered, scheduled or acquired, the connected systems must agree on the patient’s identifiers and demographic details. These commonly include a local hospital number, national identifier, name, date of birth, sex, address and details of the current hospital encounter.

In many environments, the HIS or EPR sends patient administration messages using HL7 version 2. Admission, discharge and transfer messages are commonly used to communicate new registrations, demographic changes, patient merges and encounter updates. An interface engine may receive these messages from the source system, transform local codes or field formats, and forward the resulting messages to the RIS and Sectra PACS.

Patient identity updates require more than copying text fields. The receiving systems must understand which identifier is being supplied, which assigning authority issued it and whether it is local, regional or national. A patient can legitimately have several identifiers, particularly in organisations formed through mergers or in regional imaging networks serving multiple hospitals. If identifier domains are not handled correctly, two different patients may be combined or one patient may be represented by several disconnected records.

Patient merges are especially sensitive. When duplicate records are discovered in the EPR or HIS, the downstream systems must reconcile the surviving and superseded identifiers without disconnecting existing images from reports or orders. The integration design should define how merges are transmitted, whether they can be reversed, which systems are allowed to initiate them and how exceptions are investigated. It should also account for trauma and emergency workflows in which imaging may be acquired before a patient’s full identity is known.

Once the patient has been identified, an imaging request is created. The order normally includes the requested examination, clinical indication, priority, requesting clinician, location, relevant questions and information about the associated encounter. The EPR or HIS may transmit this order to the RIS using an HL7 order message or another supported interface.

The RIS then applies radiology-specific workflow. The request may be vetted by a radiologist, assigned a protocol, split into several procedures, combined with another request or scheduled for a particular date and modality. For example, one clinical request might generate multiple imaging procedures, each requiring its own scheduled step. This distinction between the clinical order, requested procedure, scheduled procedure step and resulting imaging study is fundamental to reliable integration.

An accession number is normally assigned to the imaging order or procedure. It provides an important link between the order in the RIS, the study in Sectra PACS and the report returned to the EPR. The accession number should be unique within its defined scope, generated by an agreed system and transmitted consistently. Reusing accession numbers or altering them independently in separate systems can lead to reports being attached to the wrong study or images appearing under the wrong request.

The order information can be passed into Sectra PACS so that the expected examination is known before images arrive. This supports prefetching of prior studies, creation of diagnostic worklist entries and association of the incoming image data with the correct patient and request. Some deployments send orders directly from the RIS to the PACS, while others route them through an integration engine or use a tightly integrated RIS and PACS workflow.

The key information flows typically include:

• Patient registration, update, merge, admission, transfer and discharge events from the HIS or EPR to the RIS and PACS.
• New, changed and cancelled imaging orders from the ordering system to the RIS and PACS.
• Scheduling, protocol and examination status information between the RIS, PACS and modalities.
• Images and imaging metadata from modalities to Sectra PACS using DICOM.
• Diagnostic reports, result status and critical-result information from the reporting workflow to the EPR or HIS.
• Patient, encounter or study context from the EPR to Sectra viewing applications.

At the imaging device, DICOM Modality Worklist is commonly used to retrieve scheduled examination details. Instead of manually entering the patient’s name, identifier, accession number and procedure description on the scanner, the technologist selects the appropriate worklist item. The modality then includes that information in the DICOM objects it creates.

This reduces transcription errors and helps Sectra PACS match the incoming images to the correct order. It also establishes consistent identifiers across the RIS, modality and PACS. The worklist provider may be Sectra, the RIS or another system, but its data must be derived from the authoritative scheduling workflow and reflect cancellations, rescheduling and changes promptly.

Some modalities can send Modality Performed Procedure Step messages to indicate that an examination has started, progressed or completed. These updates can help the RIS and PACS track the true state of the procedure. They can also capture details such as the performed protocol, images acquired, contrast use or reasons for discontinuation, depending on the modality and implementation.

The images themselves are normally transmitted to Sectra PACS using DICOM storage services. Each object contains pixel data and a structured set of metadata. Important attributes include the patient identifier, study instance unique identifier, series and instance identifiers, accession number, study description, modality and acquisition time. Sectra uses this metadata to organise the examination and associate it with the corresponding patient and workflow item.

Storage Commitment can be used where the sending system needs confirmation that Sectra has taken responsibility for retaining the objects. This is stronger than a basic acknowledgement that the network transmission succeeded. It can allow a modality, gateway or upstream archive to apply a controlled deletion policy after confirmed storage, although the exact process must be designed around the organisation’s retention and resilience requirements.

The RIS or EPR may also need to know when the examination is ready for reporting. This status can be inferred from received images, communicated through HL7 messages or driven by workflow events within the connected systems. A robust design avoids relying on a single image arriving as proof that the entire examination is complete, because a study may contain many series transmitted over an extended period.

Connecting reporting, worklists and clinical image access

The diagnostic workflow begins when the examination becomes available on the radiologist’s Sectra worklist. Worklist construction can use information from the order, examination status, modality, body part, location, priority, subspecialty and assigned user group. The objective is not simply to display every unread study, but to route each case to an appropriate reader in the correct sequence.

The RIS and Sectra PACS must share enough status information to prevent conflicting workflow states. If a study is cancelled in the RIS but remains active in the PACS, it may appear unnecessarily on a diagnostic list. If a radiologist begins reporting in one system without the other recognising that the case is in progress, two people could open the same examination. Organisations should define which system owns each status and how changes such as arrived, examined, ready for reporting, in progress, preliminary, verified and amended are communicated.

A reporting application may be integrated directly into the Sectra diagnostic environment or connected as a separate system. The radiologist may select an examination in Sectra PACS and have the reporting application open the same patient and order automatically. Conversely, selecting a report in the RIS or reporting system may open the corresponding images in Sectra. This is known as context synchronisation.

Traditional context integration can use command-line parameters, URLs, proprietary application programming interfaces or desktop integration components. The launching application passes identifiers such as the patient ID, accession number or study instance UID to the target application. The target then opens the matching patient or examination, subject to the user’s permissions.

Modern integrations may use web-based approaches and FHIRcast. FHIRcast is designed to synchronise the clinical context of separate applications in real time. Applications join a shared session and publish or subscribe to events representing changes such as opening or closing a patient. In an imaging setting, this can help keep an EPR, PACS viewer and reporting application aligned while the user moves between patients or studies.

Context synchronisation improves speed, but it is also a patient-safety control. Without it, a radiologist could view one patient’s images while dictating into another patient’s report. Implementations should therefore validate the context at more than one level where possible. Matching only on a patient’s display name is unsafe. Stronger identifiers include the accession number, study instance UID, order identifier and verified patient identifier domain.

The report produced by the radiologist must return to the clinical record. In a conventional integration, a verified report is transmitted using an HL7 observation result message. The message may include the report text, result status, author, verification time, accession number, procedure code and identifiers for the patient and encounter. The EPR or HIS uses these fields to place the result in the correct patient record and link it to the originating order.

Preliminary, final, corrected and addended reports require careful status handling. A preliminary report should not appear to clinicians as a final verified diagnosis. When a report is corrected, the receiving system must update the existing result rather than display a disconnected second report without context. The integration specification should state how versioning, amendments, cancellations and replacement results are represented.

Structured data can also be exchanged in addition to narrative text. Measurements, scores and coded findings may be carried as discrete values, structured reports or FHIR resources, depending on the systems involved. This can support clinical decision support, registries, analytics and longitudinal tracking. However, discrete data introduces additional governance requirements because codes, units and value sets must be interpreted consistently by every receiving system.

Images can be made available from the EPR through a context-sensitive link or an embedded viewer. When a clinician opens an imaging result, the EPR passes the relevant context to Sectra’s clinical viewer. The user should arrive at the intended study or patient timeline without signing in again or repeating a search. Depending on the workflow, the viewer may open a single examination, a set of related studies or the patient’s complete imaging history.

Single sign-on is commonly used to make this experience seamless. The EPR and Sectra environment can rely on an agreed identity provider or authentication mechanism, allowing Sectra to recognise the logged-in user. Authentication confirms the user’s identity, while authorisation determines which patients, studies and functions that user may access. Passing a trusted username in a URL without appropriate authentication is not an adequate security design.

The clinical viewer may be launched in a new window, embedded in the EPR interface or displayed through a web component. The technical choice depends on the capabilities of the EPR, browser security policies, Sectra configuration and local user experience requirements. Embedded access can feel more integrated, but it may introduce considerations involving browser frames, cross-origin restrictions, session management and screen space.

A high-quality EPR-to-PACS integration should preserve the clinician’s workflow rather than simply expose a generic PACS search page. Useful launch patterns include:

• Opening the exact examination associated with a selected result.
• Opening all relevant imaging for the current encounter.
• Opening the patient’s longitudinal imaging timeline.
• Launching a diagnostic-grade application for authorised specialist users.
• Opening a zero-footprint clinical viewer for general clinical access.
• Passing the current patient context while allowing the user to select a specific study.

The integration should also return the user safely to the EPR when the viewing session ends. Session time-outs, patient-context changes and browser navigation need to be considered. If the clinician changes patient in the EPR, an already-open viewer should not silently remain on the previous patient without a clear warning or synchronised update.

Clinical access differs from diagnostic access. General clinicians may need convenient review of images and reports, while radiologists require calibrated displays, advanced tools, hanging protocols, comparison workflows and reliable access to priors. The integration must launch the appropriate Sectra application and feature set for the user’s role rather than treating every viewer as interchangeable.

Standards, interfaces and the integration architecture

DICOM and HL7 solve different parts of the integration problem. DICOM is centred on medical imaging objects and imaging workflow services. It handles the storage, query, retrieval and display of images, as well as services such as modality worklist and storage commitment. HL7 version 2 is widely used for administrative and clinical messages, including patient updates, orders and diagnostic results.

FHIR provides a modern resource-based approach to healthcare data exchange. It may be used for patient, order, encounter, diagnostic report and imaging-related information, as well as application launch and context synchronisation. FHIR does not automatically replace DICOM or established HL7 interfaces. In many real deployments, the technologies coexist: HL7 version 2 carries high-volume operational messages, DICOM transports image objects, DICOMweb provides web-oriented imaging access and FHIR supports newer application and data-sharing use cases.

DICOMweb applies web technologies to DICOM services. QIDO-RS supports searches for studies, series and instances; WADO-RS supports retrieval; and STOW-RS supports storage. These interfaces can make it easier for web applications, cloud services and integration platforms to interact with imaging repositories without implementing traditional DICOM network services. Availability and supported operations depend on the Sectra product version and licensed configuration, so the applicable conformance statements must be reviewed for each deployment.

IHE integration profiles bring these standards together into defined clinical workflows. The Scheduled Workflow profile, for example, coordinates ordering, scheduling, image acquisition, storage and viewing. Patient Information Reconciliation addresses situations in which images were acquired for an unidentified or incorrectly identified patient. Other profiles cover cross-enterprise image sharing, document access, evidence objects and workflow communication.

An interface engine commonly sits between Sectra and the RIS, EPR or HIS. Its purpose is not merely to relay messages. It can map local procedure codes, translate identifier domains, filter events, enrich messages, route information to several destinations, manage acknowledgements and place failed transactions into an exception queue. It also provides a central point for monitoring integrations across the organisation.

However, excessive transformation can make the architecture difficult to support. If the interface engine changes patient identifiers, accession numbers, procedure descriptions and status codes in undocumented ways, troubleshooting becomes dependent on a small number of specialists. Transformations should be deliberate, version-controlled, testable and traceable to a defined business rule.

The integration architecture should distinguish synchronous interactions from asynchronous messages. Opening a study from the EPR is generally a real-time request: the user expects an immediate response. Patient updates and result messages are often asynchronous: they are placed on a queue, transmitted and acknowledged. Each pattern needs different handling for time-outs, retries and failures.

Network topology also affects the design. An on-premises Sectra deployment may communicate with local EPR, RIS and interface-engine servers across protected hospital networks. A cloud-hosted deployment may require secure connections between the healthcare organisation and Sectra’s cloud environment. Firewalls, private connectivity, proxy servers, certificates, domain name resolution and outbound access policies can all influence whether an interface functions reliably.

Large regional deployments add another level of complexity. A shared Sectra PACS may receive patient and order information from several hospitals, each with its own identifiers, procedure catalogue and EPR. The architecture must prevent identifier collisions and establish whether patient records are linked through a regional master patient index, a national identifier or carefully managed assigning authorities.

A shared platform also needs clear data-segregation and access rules. Clinicians may need to see images acquired elsewhere in the region, but administrative users may be restricted to their own organisation. The technical integration therefore has to carry sufficient information about the source organisation, care context and security domain for Sectra to apply the intended policy.

Conformance statements are essential engineering documents in this process. A DICOM conformance statement describes the services, roles, transfer syntaxes and information objects supported by a particular product version. An IHE integration statement identifies the profiles and actors implemented. Similar interface specifications may document supported HL7 messages, fields, trigger events and application behaviour.

The fact that two systems both claim to support DICOM, HL7 or FHIR does not guarantee that they will work together without configuration. One system may require an accession number in a field the other leaves empty. One may support a patient-merge event that the other ignores. One may use local procedure codes while the other expects national terminology. Interoperability is achieved through compatible implementation details, not through standards labels alone.

Choosing standards for Sectra PACS integration with RIS, EPR and HIS

Traditional HL7 and DICOM interfaces continue to support the core exchange of patient information, imaging orders, results and medical images. Additional interoperability standards can address more specific requirements, including secure EPR launches, real-time application synchronisation, browser-based image access and regional imaging exchange.

The following comparison shows which standards may be relevant to different Sectra PACS integration tasks. These technologies are generally complementary rather than interchangeable, and support should always be confirmed against the applicable Sectra PACS version, licences and conformance statements.

Engineering, testing and operating a dependable connection

A Sectra PACS integration project should begin with workflow discovery rather than interface configuration. Technical teams need to observe how referrals are created, vetted, scheduled, performed, reported and reviewed. They should identify variations for inpatients, outpatients, emergency cases, external referrals, research studies and examinations imported from other organisations.

The next step is to create a data ownership matrix. Each important field should have an authoritative source and a defined lifecycle. This includes patient identifiers, demographic details, encounter numbers, order numbers, accession numbers, procedure codes, scheduling information, study UIDs, examination status and report status. The matrix should also state which systems may modify a value and how corrections are propagated.

An interface specification should document the expected transaction sequence, not merely provide example messages. It should explain what happens when an order is created, changed, cancelled, split or merged; when the patient fails to attend; when the modality performs a different procedure; when images arrive before an order; and when a report is amended after verification.

Code mapping deserves particular attention. The EPR may order examinations using one catalogue, while the RIS and modalities use more detailed local codes. A single EPR request may map to several RIS procedures, and historical studies may contain retired descriptions. Mapping tables need owners, change control and testing because an apparently minor catalogue update can disrupt worklist routing or hanging protocols.

Testing should include complete clinical journeys rather than isolated message delivery. A successful HL7 acknowledgement proves only that the receiving interface accepted a message. It does not prove that the patient appeared correctly, the order reached the right worklist, the modality selected the correct procedure, the images matched the order or the final report returned to the correct record.

A comprehensive test set should include routine cases and deliberate exceptions. Examples include a new patient, an existing patient with changed demographics, a duplicate record merge, two patients with similar names, an order cancellation, a rescheduled appointment, multiple procedures under one request, an emergency unidentified patient, an examination performed differently from the original order and a corrected report.

Testing should also confirm behaviour during partial failures. If the RIS is unavailable, can modalities continue to access cached worklists? If the interface engine is restarted, are queued messages delivered in order? If the connection to a cloud-hosted Sectra environment is interrupted, are images retained locally and retransmitted automatically? If an acknowledgement is lost, does the sending system create a duplicate transaction?

Idempotency is important in message processing. A retry should not create a second patient, order, report or study. Systems should use stable identifiers to recognise a transaction or clinical object that has already been processed. Where an interface cannot guarantee idempotent behaviour, operational monitoring must identify duplicates quickly.

Performance testing should reflect realistic and peak workloads. Imaging data is significantly larger than typical administrative messages, and some studies contain thousands of objects. The network and storage path should be tested with representative CT, MR, mammography, cardiology and other high-volume data. The EPR launch experience should also be measured, because clinicians will perceive an integration as unsuccessful if the correct viewer takes too long to open.

Security testing must cover both technical and clinical risks. Connections should use appropriate encryption, certificate validation and network controls. Service accounts should have only the privileges required. User-facing launches should not expose sensitive identifiers unnecessarily in browser history, logs or unsecured URLs. Audit records should show who viewed patient data and through which application context.

The organisation should establish operational monitoring before go-live. Monitoring needs to answer more than whether a server is running. It should reveal whether patient messages are flowing, whether order queues are growing, whether images are arriving, whether reports are being acknowledged and whether EPR viewer launches are succeeding.

Useful operational measures include message volumes, rejected transactions, acknowledgement latency, worklist query failures, unmatched studies, report-delivery failures, duplicate patients, interface queue depth and image-transfer time. Thresholds should reflect normal operating patterns, and alerts should be directed to teams capable of taking action.

Exception queues require defined ownership. An unmatched study may need investigation by radiology administration, PACS support or the integration team depending on the cause. Without an agreed process, errors remain in technical queues until a clinician discovers missing information. Every high-risk exception should have a responsible team, target response time and escalation route.

Changes to any connected platform can affect the entire workflow. An EPR upgrade may alter launch parameters or authentication behaviour. A RIS upgrade may change HL7 fields. A Sectra upgrade may introduce new interfaces or require updated certificates. A modality replacement may transmit different DICOM attributes. Integration regression testing should therefore form part of every significant change.

Version-specific documentation must be maintained. Healthcare organisations often retain old interface specifications that describe the original deployment but not later modifications. The current production design should record endpoint details, message routes, transformations, code maps, certificates, supported standards, recovery procedures and known limitations.

Clinical representatives should participate in acceptance testing. Engineers can confirm that identifiers and messages are correct, but radiologists, radiographers, referrers and records staff can identify workflow problems that technical testing misses. A process may be technically valid yet still require unnecessary searches, display misleading statuses or make urgent examinations difficult to recognise.

A dependable connection ultimately depends on governance as much as technology. Sectra PACS, the RIS, the EPR and the HIS are often managed by different teams and supplied by different vendors. When a problem crosses system boundaries, each component may appear to be operating correctly in isolation. Joint support procedures, shared evidence and end-to-end monitoring help prevent prolonged disputes over where the fault lies.

The most successful integrations treat the imaging workflow as one clinical service rather than a chain of separate products. Patient identity is managed consistently. Orders and status changes move predictably. Modalities receive reliable worklists. Images reach Sectra with accurate metadata. Reports return to the clinical record. Clinicians can open the correct imaging directly from the EPR, while radiologists receive the context and priors needed for diagnosis.