DICOM, HL7 and FHIR in Secondary Care PACS Integration

Secondary care imaging depends on far more than the transfer of pictures from a scanner to an archive. A modern imaging pathway links patient administration, referrals, scheduling, modality worklists, image acquisition, reporting, clinical review, results acknowledgement, audit and increasingly artificial intelligence. Picture Archiving and Communication Systems sit at the centre of this pathway, but they cannot operate effectively in isolation. They must exchange information with electronic patient records, radiology information systems, patient administration systems, order communications platforms, reporting applications, clinical portals, vendor-neutral archives and regional image-sharing services.

Three standards are especially important in this environment: DICOM, HL7 and FHIR. They are sometimes discussed as competing technologies, but this is misleading. Each solves a different part of the integration problem. DICOM is primarily concerned with medical imaging objects, imaging metadata and imaging-specific network services. Traditional HL7 messaging, particularly HL7 version 2, carries much of the administrative and workflow information that connects hospital systems. FHIR provides modern, web-oriented methods for exposing and exchanging structured healthcare information through application programming interfaces.

Successful secondary care PACS integration therefore rarely involves choosing one standard. It involves using DICOM, HL7 and FHIR together, assigning each an appropriate role and managing the boundaries between them. The quality of those boundaries determines whether clinicians receive a coherent imaging record or encounter mismatched patients, missing studies, duplicate examinations, unavailable reports and fragmented workflows.

How DICOM, HL7 and FHIR Divide the Integration Work

DICOM, or Digital Imaging and Communications in Medicine, is the foundational standard for medical imaging interoperability. It defines both the format of medical imaging objects and the services used to transmit, query, retrieve, store and manage them. A DICOM object is not simply an image file. It contains pixel data or other clinical content together with structured attributes describing the patient, study, series, equipment, procedure, acquisition parameters and relationships between objects.

This combination of content and metadata allows a CT study, for example, to retain its clinical identity as it moves from the scanner to the PACS, from the PACS to a reporting workstation and from the local archive to a regional imaging platform. DICOM also supports objects other than conventional images, including structured reports, presentation states, radiation dose records, segmentation objects, waveforms and encapsulated documents. In engineering terms, DICOM gives imaging systems a shared vocabulary for packaging and transporting imaging-related information.

Traditional DICOM networking is based on associations between Application Entities. Each participating system is normally configured with an Application Entity Title, a network address and a port. During an association, the systems negotiate the services and data formats they support. Common services include C-STORE for sending objects, C-FIND for querying, C-MOVE or C-GET for retrieving objects, Modality Worklist for providing scheduled procedure information and Storage Commitment for confirming that received objects have been safely stored.

HL7 version 2 operates at a different level. It is commonly used to exchange patient, encounter, order, scheduling and result information between hospital applications. Whereas DICOM carries a diagnostic image and its imaging metadata, an HL7 message may tell the PACS that a patient has been registered, that an appointment has been booked, that an imaging procedure has been ordered, that demographic details have changed or that two patient records must be merged.

HL7 version 2 messages are event-driven and usually transmitted as delimited text over an interface connection. An ADT message can communicate an admission, discharge, transfer, registration or demographic update. An ORM or other order-related message can communicate an imaging request. An ORU message can carry a diagnostic report or result. Exact message types, trigger events and field usage vary between products and implementations, which is why a nominal claim of “HL7 support” is never sufficient evidence that two systems will interoperate safely.

FHIR, or Fast Healthcare Interoperability Resources, brings a more modern approach to clinical data exchange. It represents healthcare information as modular resources that can be accessed through web technologies. Relevant resources in an imaging pathway may include Patient, Encounter, ServiceRequest, Appointment, ImagingStudy, DiagnosticReport, Observation, Practitioner, PractitionerRole, Organization, Endpoint and DocumentReference.

FHIR is particularly useful where an EPR, clinical portal, patient application, analytics service or workflow product needs structured access to imaging information without participating directly in traditional DICOM or HL7 version 2 interfaces. An EPR might query for a patient’s ImagingStudy resources, retrieve related DiagnosticReport resources and then launch an image viewer using a secure context. A workflow service might use ServiceRequest and Task resources to coordinate a process across organisational boundaries. A patient-facing service might expose a verified imaging report without granting the application direct access to the PACS database.

DICOMweb extends DICOM into the web environment and creates an important bridge between DICOM and FHIR-based architectures. Its principal services include QIDO-RS for querying DICOM studies, series and instances, WADO-RS for retrieval and STOW-RS for storage. These services use HTTP and web-compatible representations while preserving the imaging semantics defined by DICOM. FHIR can therefore describe that an imaging study exists, its clinical context and its relationship to an order or report, while DICOMweb provides access to the actual imaging objects.

A clinical viewer or integration service can use a DICOMweb QIDO-RS request to locate a PACS study using identifiers such as the Patient ID and accession number. QIDO-RS searches studies, series or instances and can return DICOM metadata as application/dicom+json; image retrieval would normally follow through WADO-RS.

curl --request GET \
  --url "https://pacs.example.nhs.uk/dicom-web/studies?PatientID=H123456&AccessionNumber=ACC98765&includefield=StudyDescription" \
  --header "Accept: application/dicom+json" \
  --header "Authorization: Bearer ${ACCESS_TOKEN}"

The distinction is important. A FHIR ImagingStudy resource is not normally a replacement for the DICOM study itself. It is a clinical and administrative representation of the study, containing identifiers, status, modality information, subject references, encounter context and links to series or endpoints. The detailed image content remains within the DICOM domain. Treating FHIR as a new image archive format can lead to inefficient designs, just as trying to use DICOM alone to represent every aspect of a hospital encounter can create brittle and incomplete workflows.

A robust architecture uses the three standards as complementary layers. HL7 version 2 may remain the operational messaging backbone for established patient and order workflows. DICOM may manage modality worklists, acquisition, storage and diagnostic retrieval. FHIR may provide reusable APIs for clinical access, orchestration, mobile applications, cross-system context and newer digital services. The integration design must preserve a consistent identity across all three layers.

The End-to-End Imaging Workflow in an NHS Trust

The integration challenge becomes clearer when the standards are considered within an end-to-end secondary care workflow. A typical pathway begins before any images exist. A patient is registered in the Patient Administration System, which becomes an authoritative source for identifiers and demographics. The patient may have an NHS number, one or more local hospital numbers and identifiers inherited from previous systems or neighbouring organisations. These identifiers must be distributed accurately because a PACS study associated with the wrong patient can create a serious clinical safety incident.

The Patient Administration System or EPR commonly publishes an HL7 ADT message following a registration or demographic event. An interface engine may validate, transform and route that message to the RIS, PACS, reporting platform and other subscribing systems. The message may contain the patient’s local identifier, NHS number, name, date of birth, sex, address and encounter details. Each receiving application applies its own configuration to interpret those fields.

The next stage is the imaging request. A clinician may place an order within the EPR or an order communications system. That request must reach the RIS or imaging workflow platform with enough information for vetting, protocol selection, scheduling and reporting. Relevant data may include the requested procedure, clinical indication, priority, requesting clinician, location, encounter, mobility requirements, infection risks and questions that the examination is expected to answer.

In many established environments, the request is delivered as an HL7 order message. The RIS creates or updates the corresponding procedure and assigns an accession number. The accession number is one of the most important cross-system identifiers in the imaging pathway. It commonly links the order, scheduled procedure, acquired DICOM study and diagnostic report. If it is missing, reformatted, truncated or reused incorrectly, automated reconciliation can fail.

The following simplified HL7 v2 ORM^O01 message illustrates how an imaging request can carry the patient identifier, placer order number, RIS filler or accession number and requested procedure between an EPR and RIS. Exact field usage and assigning authorities must be defined in the local HL7 interface specification. ORM^O01 is the HL7 v2 trigger event for a general order message.

MSH|^~\&|EPR|TRUST|RIS|RADIOLOGY|20260723103000||ORM^O01|MSG00001|P|2.5
PID|1||H123456^^^TRUST^MR||SMITH^JANE||19800115|F
ORC|NW|ORD12345^EPR|ACC98765^RIS
OBR|1|ORD12345^EPR|ACC98765^RIS|CTCHEST^CT chest with contrast^LOCAL

When the examination is scheduled, the modality retrieves a DICOM Modality Worklist. Rather than requiring a radiographer to retype the patient’s name, identifier and procedure details, the scanner receives them electronically. This reduces transcription errors and allows the images produced by the scanner to inherit identifiers that match the order held by the RIS and PACS.

Modality Worklist is often described as a simple query, but its implementation demands careful engineering. The PACS, RIS or dedicated worklist broker must map the hospital’s scheduling information into DICOM attributes. The modality must query using supported filters. Procedure codes, station names, modality types, accession numbers and patient identifiers must be formatted consistently. Some modalities support only limited matching behaviour or older DICOM capabilities, so a technically valid worklist can still be operationally unsuitable.

After acquisition, the modality sends the study to the PACS using DICOM C-STORE or, in newer architectures, a DICOMweb storage service. The receiving PACS validates the association, checks the accepted presentation context, receives the objects and indexes their metadata. Transfer syntax negotiation determines whether the sender transmits uncompressed data or a supported compression format. The receiving system must also handle study completion behaviour, late images, corrected series and objects generated after the initial examination.

Storage acknowledgement must not be confused with durable archiving. A successful C-STORE response generally indicates that the receiving Application Entity accepted the object, but the precise durability guarantees depend on the implementation. Where required, DICOM Storage Commitment can provide a stronger confirmation that responsibility for the object has been accepted. Trusts should understand whether data has reached primary storage, replicated storage, a VNA, backup infrastructure or only an intermediate cache before declaring the transfer complete.

The PACS makes the study available to reporting workstations and clinical viewers. A radiologist may receive the case through a worklist driven by the RIS, PACS or an orchestration layer. The workstation retrieves prior and current images, applies display protocols and may launch reporting software in the same patient and examination context. Context synchronisation is critical: opening the correct patient in two systems is not enough if the reporting application is focused on a different episode or accession number.

Once the report is verified, it may be transmitted to the EPR or results repository through an HL7 result message. The message should carry stable identifiers linking the report to the patient, order and imaging study. Depending on the design, the PACS may store a copy of the report, receive report status updates or display a report obtained from another system.

FHIR can expose the same pathway in a more API-oriented form. The original request may be represented as a ServiceRequest, the performed study as an ImagingStudy and the verified interpretation as a DiagnosticReport. The DiagnosticReport can refer to the ImagingStudy and may include coded observations or a presented report. This model gives consuming applications a structured way to discover the clinical relationships between order, imaging event and result.

This simplified FHIR R4 DiagnosticReport links a verified radiology report to both the originating ServiceRequest and the related ImagingStudy, allowing an EPR or clinical portal to navigate between the order, report and imaging event. FHIR R4 defines basedOn for the request and imagingStudy for the associated imaging study.

{
  "resourceType": "DiagnosticReport",
  "id": "ct-chest-report",
  "status": "final",
  "code": {
    "text": "CT chest report"
  },
  "subject": {
    "reference": "Patient/123"
  },
  "basedOn": [
    {
      "reference": "ServiceRequest/ORD12345"
    }
  ],
  "imagingStudy": [
    {
      "reference": "ImagingStudy/ct-chest-study"
    }
  ],
  "effectiveDateTime": "2026-07-23T11:35:00+01:00",
  "conclusion": "No acute intrathoracic abnormality."
}

An EPR integration might query for completed DiagnosticReport resources associated with a patient and then follow the reference to an ImagingStudy. The user could select the report and launch a diagnostic or enterprise viewer. Behind the launch, the viewer may use a proprietary API, a tokenised URL, an IHE profile, DICOMweb or a combination of mechanisms. From the clinician’s perspective the result should be a single action, but the underlying transaction must establish patient context, user identity, authorisation, study identity and an auditable session.

Patient record changes complicate every stage. If demographic information is corrected after image acquisition, the update must propagate to the relevant systems. If two local records are discovered to belong to the same patient, a merge event may need to update the RIS and PACS while preserving a traceable history. Some PACS products perform a logical merge, some reassign studies, and some require manual intervention for particular conflicts. A generic interface specification cannot safely assume that all systems interpret patient merges in the same way.

Unscheduled and emergency imaging introduces another class of problem. A trauma examination may be acquired before a fully verified registration is available. The modality may use a temporary identifier, after which the study must be reconciled with the definitive patient record. The architecture needs an exception workflow rather than relying on automatic demographic updates to repair every case. Reconciliation should be controlled, auditable and visible to operational teams.

Cross-organisational imaging adds further complexity. A patient may have studies held by several NHS Trusts, independent sector providers or regional archives. Local identifiers may not match, procedure coding may differ and reports may be distributed separately from images. FHIR can help represent organisations, endpoints and cross-system clinical references, while DICOM and DICOMweb continue to provide imaging access. However, standards do not remove the need for information governance, identity matching, routing rules, consent handling and agreed operational ownership.

Engineering Reliable Interfaces Rather Than Merely Connecting Systems

The difference between a demonstration interface and a production-grade integration lies in how it handles ambiguity, failure and change. A successful test in which one study passes from a scanner to a PACS proves very little about long-term operational reliability. Secondary care environments must process large volumes of transactions from many systems, including old modalities, specialist workstations and applications configured according to local conventions.

The first engineering task is to define systems of record. The Patient Administration System or EPR may be authoritative for patient demographics, while the RIS is authoritative for imaging scheduling and procedure status. The PACS may be authoritative for stored DICOM objects, and the reporting application may be authoritative for report content. Without an agreed authority model, systems can overwrite one another with older or less reliable data.

The second task is identifier governance. Engineers should identify every identifier used within the workflow, where it originates, whether it is globally or locally unique and how it is represented in DICOM, HL7 and FHIR. This typically includes the NHS number, local hospital number, enterprise patient identifier, visit number, order number, placer order number, filler order number, accession number, Study Instance UID, Series Instance UID and SOP Instance UID.

DICOM UIDs and business identifiers serve different purposes. A Study Instance UID uniquely identifies a DICOM study, while an accession number normally links the study to a requested procedure. Changing or duplicating either can disrupt retrieval, priors matching, reporting and reconciliation. Implementations should not generate new Study Instance UIDs casually when routing or migrating studies, nor should they assume that accession numbers are unique beyond their agreed assigning domain.

A third task is to translate meaning rather than merely copy fields. An interface engine can move a value from an HL7 segment into a DICOM attribute or FHIR element, but syntactic mapping does not guarantee semantic equivalence. A procedure description entered as free text may not provide the stable coded meaning required for analytics or decision support. A patient class code used by one application may have a different interpretation in another. A report status of “final” may not be equivalent to the PACS state labelled “verified” unless the workflow has been explicitly defined.

A practical integration specification should document at least the following:

• The source, destination, trigger, transport, acknowledgement behaviour and retry policy for every interface.
• The field-level mapping rules, identifier domains, code translations, default values and handling of missing data.
• The expected sequence of events, including corrections, cancellations, merges, late updates and duplicated messages.
• The security controls, service accounts, certificates, network routes, audit events and support ownership.
• The test cases and acceptance criteria for normal workflows, exceptions, downtime and recovery.

Acknowledgements require particular attention. An HL7 transport acknowledgement may confirm that a message was received, but it may not prove that the destination applied the update successfully. Some applications acknowledge structurally acceptable messages even when local processing later fails. Similarly, an HTTP success response from a FHIR endpoint may confirm resource creation without proving that a downstream imaging workflow has completed. Monitoring must therefore distinguish transport success, validation success, business processing success and clinical workflow completion.

Message ordering is another common source of defects. A report may arrive before the corresponding order has been created in the destination system. A demographic update may overtake the initial registration message. A retry may result in the same message being delivered more than once. Production interfaces should be idempotent wherever possible and should use queues, correlation identifiers, timestamps and replay mechanisms to tolerate these conditions.

Interface engines are often used to centralise these controls. They can transform HL7 messages, route events, invoke APIs, manage queues and log transactions. However, the engine should not become an undocumented repository of business logic. Complex transformations hidden in channels or scripts can make upgrades and incident investigation difficult. Mapping logic, code sets, version control, test data and deployment procedures should be treated as managed software assets.

FHIR introduces familiar web engineering practices but also new governance requirements. An endpoint must publish or otherwise communicate the profiles, operations, search parameters and terminology bindings it supports. Authentication and authorisation must be designed around clinical roles and purposes, not simply possession of an API key. Pagination, rate limiting, conditional operations, version history and error responses must be considered before high-volume clients are connected.

Implementers should also avoid assuming that support for the same FHIR version guarantees compatibility. One system may expose a base ImagingStudy resource while another expects a constrained national or local profile. Optional elements may be essential to the consuming workflow. Search parameters can differ, references may be literal or logical, and extensions may carry locally required information. A CapabilityStatement is a starting point, not a substitute for bilateral testing.

The same principle applies to DICOM conformance statements and HL7 interface specifications. Two applications can claim support for DICOM C-STORE yet support different SOP Classes, transfer syntaxes or role combinations. Two products can support HL7 ADT messages while expecting different trigger events, identifier fields or merge semantics. Conformance documentation should be compared line by line against the required use cases.

Testing must include more than valid, idealised messages. Engineers should test patients with multiple identifiers, apostrophes and hyphens in names, long procedure descriptions, missing NHS numbers, temporary registrations, cancelled requests, merged records, corrected reports, amended studies, duplicate messages and network interruptions. DICOM testing should include every modality and object type expected in production, including specialist objects such as structured reports, presentation states, dose records or encapsulated PDFs where relevant.

Performance testing should model clinical peaks rather than daily averages. A PACS may receive large CT or MR studies while simultaneously servicing diagnostic workstations, enterprise viewers, AI services and regional queries. DICOM retrieval can consume significant bandwidth, and poorly controlled prefetching can affect interactive reporting. DICOMweb services may need separate capacity planning for metadata queries, rendered image access and full-fidelity object retrieval.

Observability should connect technical events to clinical transactions. Support teams need to trace a patient, order, accession number, Study Instance UID and report across multiple platforms. Logs should show where a workflow stopped, whether a message was rejected and what action is required. Dashboards based only on server availability can show every component as healthy while a queue of unprocessed reports grows unnoticed.

Downtime behaviour must also be explicit. Modalities may continue acquiring images when the RIS, PACS or network is unavailable. Local modality storage has finite capacity, and manual demographic entry increases reconciliation risk. Trusts need agreed procedures for worklist outages, store-and-forward recovery, report distribution failures and restoration sequencing. Recovery should prevent uncontrolled duplication when queued transactions resume.

Integrating AGFA, Insignia, Philips and Sectra PACS

NHS Trusts in England operate heterogeneous imaging estates, and integrations must often accommodate PACS platforms from AGFA HealthCare, Insignia, Philips and Sectra. Although these products are built around industry standards, each has its own architecture, supported interfaces, configuration model and version-specific behaviour. Integration should therefore be based on the installed product’s conformance documentation and tested capabilities rather than on assumptions about the supplier’s portfolio as a whole.

AGFA Enterprise Imaging is designed as a broader enterprise imaging platform rather than only a departmental image archive. Its integration options can include DICOM, HL7, IHE-oriented workflows, web technologies and FHIR-related capabilities, depending on the licensed modules and deployed version. In a Trust architecture, AGFA Enterprise Imaging may act as the principal PACS, a multi-specialty imaging platform, a viewer layer or part of an environment incorporating a vendor-neutral archive.

When integrating with AGFA Enterprise Imaging, engineers should establish which component receives patient and order messages, which component owns the diagnostic worklist, where DICOM objects are committed and how external applications launch the viewer. A single product name can cover several services, and the visible clinician workflow may depend on scheduling, reporting, workflow orchestration and archive components. Interface specifications should identify actual endpoints and responsibilities rather than referring generically to “AGFA”.

AGFA environments may accept both DICOM and non-DICOM imaging content, but this does not make all content interchangeable. Native DICOM ingestion preserves imaging semantics and allows standard query and retrieval. Non-DICOM content may require wrapping, metadata capture or specialist acquisition workflows. A Trust seeking a longitudinal imaging record should define how photographs, videos, scanned documents and specialist clinical media are associated with the correct patient, encounter and procedure.

Insignia PACS, now associated with Intelerad, has a significant presence in UK imaging environments. Its published conformance material illustrates an important general principle: DICOM and HL7 behaviour must be evaluated at the level of supported operations and configuration. The Insignia RIS interface can use incoming HL7 messages to update patient demographics, bookings, reports, cancellations and patient merges, but the exact mapping depends on the local configuration.

An Insignia PACS integration should examine acknowledgement behaviour closely. A transport-level acceptance may not necessarily mean that all business content has been applied successfully. Monitoring should therefore include local interface errors and application-level exceptions rather than relying solely on upstream message acknowledgements. This is especially important where an interface engine would otherwise mark the transaction as complete.

For DICOM integration with Insignia PACS or VNA services, the relevant conformance statement should be used to compare supported Service-Object Pair Classes, transfer syntaxes, query keys and storage roles. Engineers should test the actual modality and workflow combination. A generic DICOM sender may successfully store conventional CT images but fail when transmitting specialised objects, compressed images or content generated by an AI application.

Philips PACS environments may include IntelliSpace PACS, enterprise imaging services, web viewing components and integration products from the wider Philips informatics portfolio. Older and newer deployments can therefore differ substantially. A Trust should first establish the exact product versions, archive topology and interface endpoints before defining the integration.

Philips publishes DICOM conformance information for PACS and viewing products, which should be used to verify storage, query, retrieval and supported object behaviour. Where Philips integration middleware is present, HL7 traffic may be routed through a central integration service rather than delivered directly to the PACS. The operational design must make clear whether transformations occur in the Trust interface engine, the Philips PACS integration layer or both.

Layered transformation can be useful, but it can also make troubleshooting difficult. For example, a Trust interface engine may convert an EPR order into the locally agreed HL7 format, after which a vendor component performs a second mapping into the internal PACS model. When a field is lost or altered, support teams need access to both sides of each transformation. End-to-end correlation identifiers and retained payload logs are essential.

Sectra PACS and RIS products support established DICOM and HL7 integration patterns and publish detailed conformance and IHE integration information. Sectra deployments may cover radiology as well as wider enterprise imaging use cases, and regional configurations can involve shared archives, distributed workflow and cross-site reporting. As with other platforms, the precise integration surface depends on version, modules and local design.

When a Sectra environment includes both RIS and PACS capabilities, engineers must determine whether patient and order messages should enter through the RIS layer, a workflow component or the Sectra PACS integration directly. Sending the same event independently to several components can produce inconsistent data if the products do not apply identical matching rules. A controlled fan-out through an integration engine may be appropriate, but only when the ownership of each field is understood.

Sectra’s IHE-oriented support can help define repeatable workflows, but an IHE integration statement does not guarantee plug-and-play interoperability. IHE profiles constrain how standards are used for particular clinical transactions, yet products may implement different actors, options or profile versions. The Trust must match the required workflow to the supported actors and then test the complete transaction sequence.

Across AGFA Enterprise Imaging, Insignia PACS, Philips PACS and Sectra PACS, several practical rules remain constant. Product names are not interface specifications. Supplier statements about supporting DICOM, HL7 or FHIR must be translated into version-specific capabilities. The Trust should obtain the relevant DICOM conformance statement, HL7 interface specification, FHIR CapabilityStatement and IHE integration statement where available.

The Trust should also avoid designing an integration that depends unnecessarily on supplier-specific database access. Direct database integration can appear efficient, but it bypasses supported validation, audit and upgrade boundaries. Standards-based services or documented vendor APIs are usually more maintainable. Where proprietary interfaces are unavoidable, they should be isolated behind a controlled integration layer and covered by regression testing.

PACS replacement programmes make these distinctions especially important. During migration, the old and new systems may operate in parallel. Patient and order messages may need to reach both, while image routing rules determine which archive is authoritative. Prior studies may be migrated in bulk, fetched on demand or accessed through a federated viewer. FHIR and DICOMweb can support newer access patterns, but migration still depends on accurate DICOM metadata, preserved UIDs and reliable patient identity mapping.

Designing a Future-Ready Secondary Care PACS Architecture

A future-ready PACS architecture should not be defined simply as one that uses FHIR or runs in the cloud. It is an architecture that can evolve without losing clinical context, compromising patient safety or creating unmanageable dependencies. The central design objective is to separate stable clinical meaning from replaceable technical components.

DICOM is likely to remain the authoritative representation for diagnostic imaging objects because it captures details that generic clinical resources do not. HL7 version 2 will also remain important in NHS Trusts because many operational systems depend on it and because it provides reliable event-driven integration when well implemented. FHIR should be introduced where its resource model, web compatibility and API ecosystem create genuine value, not merely as a superficial wrapper around existing interfaces.

One sensible pattern is to retain proven HL7 version 2 workflows for patient administration, orders and results while developing a governed FHIR API layer for new consumers. The FHIR layer can expose patient-safe, application-oriented views of requests, studies and reports without allowing each new application to connect directly to the PACS or interface engine. DICOMweb can provide standards-based image access behind the same security and identity framework.

This layered approach supports clinical portals, mobile viewers, multidisciplinary team applications, research platforms and AI services. An AI orchestrator, for example, may discover eligible studies from workflow events, retrieve images through DICOM or DICOMweb, process them and return results as DICOM objects, structured reports, segmentations or FHIR resources. The appropriate output depends on how clinicians are expected to review and act on the result.

Returning AI output as a secondary image capture may make the result visible, but it can discard structured meaning. A DICOM Structured Report, segmentation object or measurement object may integrate more effectively with diagnostic workstations. A FHIR Observation or DiagnosticReport may make selected findings accessible to an EPR or analytics service. In many cases, both imaging-domain and clinical-domain representations are required, linked by stable identifiers.

Security must be designed into every layer. Traditional DICOM services have often operated within trusted clinical networks and may not provide modern authentication by themselves. They should not be exposed directly to untrusted networks. Network segmentation, controlled gateways, encrypted transport where supported and strict access rules are necessary. DICOMweb and FHIR endpoints should use current web security controls, including authenticated clients, user-aware authorisation, certificate management, audit logging and protection against excessive querying.

Authorisation should reflect clinical purpose. A clinician who can read an imaging report may not automatically need access to full diagnostic-quality image data. A patient application may be permitted to retrieve a verified report but not hidden preliminary findings. A research service may receive de-identified images under a governed process. These distinctions should be enforced by services and policy, not left to the behaviour of a user interface.

Clinical safety also depends on user context. Single sign-on improves usability but does not by itself guarantee that the correct patient or study is displayed. A viewer launch should transmit or resolve unambiguous context, validate the user’s permissions and clearly show patient identity. If the target study cannot be found, the system should fail visibly rather than silently opening a broad patient search that creates a risk of selecting the wrong examination.

Data quality should be measured continuously. Trusts can monitor the proportion of studies without an accession number, unmatched orders, duplicate patient records, rejected DICOM objects, failed report messages, manually reconciled examinations and viewer launch failures. These measures reveal integration quality more effectively than server uptime alone.

Change control is equally important. PACS upgrades can alter supported interfaces, default behaviours, security settings or viewer launch methods. EPR changes can modify HL7 fields, code values or FHIR profiles. A formal regression suite should verify patient registration, demographic correction, ordering, scheduling, worklist retrieval, acquisition, storage, reporting, amendment, merge handling and image viewing after any significant change.

A representative integration test environment should include realistic versions of the interface engine, PACS, RIS, EPR endpoints and key modality types. Synthetic test patients should exercise normal and exceptional pathways without exposing live data. Automated testing can validate message structure, API responses and selected DICOM metadata, while clinical users confirm that the end-to-end workflow behaves safely.

Procurement should require evidence rather than generic interoperability claims. Suppliers should identify supported standards versions, IHE actors, FHIR resources, API authentication methods, DICOM SOP Classes, transfer syntaxes, HL7 events, acknowledgement behaviour, audit capabilities and known limitations. They should also explain how integrations are maintained during upgrades and how customers can access logs and diagnostic tools.

For Trusts operating AGFA Enterprise Imaging, Insignia PACS, Philips PACS or Sectra PACS, the objective should not be to force every platform into an identical technical model. It should be to establish a consistent enterprise integration contract around each platform. That contract defines identity, workflow, security, observability and support expectations while allowing the PACS-specific adapter or interface configuration to vary.

The most effective secondary care PACS integrations are therefore not those with the largest number of interfaces. They are those in which each interface has a clear purpose, a defined source of truth, controlled semantics and observable outcomes. DICOM moves and preserves imaging content. HL7 version 2 coordinates the events on which established hospital workflows depend. FHIR makes selected clinical information and services accessible through modern, reusable APIs.

Used together, these standards can create an imaging ecosystem in which orders arrive accurately, modalities receive reliable worklists, studies remain linked to the correct patient, reports reach the EPR, clinicians can launch images in context and new services can be added without repeatedly rebuilding the entire integration landscape. Used without careful governance, the same standards can produce a network of technically connected systems that still fails to deliver a coherent clinical pathway.