Introduction

Picture Archiving and Communication Systems (PACSs) were initially often considered to be purely a radiologist’s thing. With the introduction of large-scale PACS and the capability for web-based image distribution [1–3], this impression began to change. The need for integration with the Hospital Information System (HIS) [4–7] and the Electronic Patient Record (EPR) [8–10] became evident, although the latter is still not seen too often [11], making PACS a well perceived part of the hospital’s IT-landscape.

Today a radiologist may be confronted with questions from clinical colleagues on whether their modalities could be hooked up to the PACS or from hospital administration inquiring whether and how departmental storage solutions, perhaps due to a lacking image distribution possibility or for financial reasons, could be migrated into the PACS. In fact, a series of potential advantages but also drawbacks can be identified for such an approach (Table 1). The aim of this review is to help radiologists to answer those questions by describing the technical requirements for a transition from a departmental “radiology” PACS into a multi-departmental (MD) PACS based on the possibilities offered by widely adopted system integration standards and especially DICOM (Digital Imaging and Communications in Medicine). After an introduction to system integration technology, four different modality integration approaches will be presented. Finally, the requirements of selected clinical disciplines and widely used modality types shall be described, based on existing literature, and compared with the possibilities of a DICOM-based MD-PACS.

Table 1 Some potential advantages and disadvantages of a MD-PACS
Full size table

System integration technology

For the ease of understanding and because it is technology-wise the superior approach, HIS and EPR are assumed to be in one integrated system.

Data Integration

In Data Integration some kind of patient-related information is exchanged between different applications. This exchange can occur in-between servers, which is often supported by so-called “communication servers”, or clients, and it can be standardised or un-standardised. The most used standards for Data Integration in the medical environment are HL7 (Health Level 7) [12] and DICOM [13, 14]. HL7 covers the exchange of textual or alpha-numerical data, while DICOM (DC) is manly dedicated to multimedia objects (MMO). IHE (Integrating the Healthcare Enterprise) [15–20] bundles parts from both and has introduced additional elements in order to facilitate the overall integration process.

Unique identifiers in HL7, DICOM and IHE

Each standard defines a set of Identifiers (IDs) or numbers which have the main purpose to precisely identify an instance, e.g. a patient, an order, a study or an image. Those sets are not completely coherent, but in order to understand integration a simplified introduction to the terminology is sufficient. The IDs have a certain hierarchical structure which implies that one ID does always also include information about the higher IDs, e.g. a Study-ID will always allow to identify the patient and they are worldwide unique and hence Unique Identifiers (UIDs).

With registration the most important ID, the Patient-ID, is generated. When a procedure is requested (Requested Procedure) by a system (Order Placer) a “Placer Order Number” is allocated. Scheduling or booking the procedure (Scheduled Procedure) by an Order Filler creates a “Filler Order Number”, which is very close to the Accession-UID in DICOM, which is often also called Accession Number. The Accession Number is the most frequently used way to precisely identify an examination in the PACS context. Performing an examination (Performed Procedure) will generate DICOM UIDs for a Study, the Series and the Images attached to the Accession Number.

HL7

The HL7 standard itself is very extensive and covers multiple areas of clinical data exchange between HIS-EPR and Specialised Information Systems (SPIS), but in the practical routine only a subset of message types is frequently used, which are explained in the context of a typical radiological integration framework (see below, Table 2, Fig. 1).

Table 2 Workflow for a typical system integration scenario in Radiology. The numbers correspond to those in Fig. 1
Full size table
Fig. 1
figure 1

Schematic diagram of a generic radiology integration framework. The figure does neglect potentially existing communication servers or PACS-brokers. The circled numbers correspond to the described steps in Table 2, which also explains the HL7 and DICOM acronyms. Black continuous line Data Integration; red continuous line Visual Integration; black dotted line Client-Server communication (mostly proprietary)

Full size image

DICOM

Similar to the HL7 standard, the DICOM standard also offers multiple features, of which some are of particular importance for routine implementations. The principle concept is that DICOM defines objects [Information Object Definitions (IOD)] and services (e.g. storage, print). Both together provide Service-Object-Pairs (SOP), which allow a precise description of which service is provided for which objects.

Among the IODs, firstly Single-frame objects (one single image) have to be differentiated from Multi-frame objects (multiple still images displayed in a row at a distinct speed or videos). Besides the classical radiological objects DICOM also defines Single- and Multi-frame Visible Lights (VL) objects (e.g. Endoscopy, Microscopy, Photography), Waveform objects [e.g. electrocardiography (ECG)] and the Secondary Capture (SC) objects, which are of particular importance here. Those are non-DICOM objects that can be converted to DICOM. Initially only Single-frame SC objects were supported, but after a revision [21] Multi-frame objects (including MPEG2) are also allowed. Another special DICOM object are Structured Reports (SR) [22, 23], which can contain structured or unstructured text as well as references (links) to other objects (e.g. images). SR objects can be communicated via DICOM and even be stored in a PACS. The most common DICOM services are presented together with the typical radiological integration framework (Table 2, Fig. 1).

IHE

The original aim of the IHE initiative is to facilitate the system integration process in healthcare in order to improve clinical care (http://www.ihe.net). IHE is a cooperation activity between healthcare professionals and the industry similar to HL7 and DICOM. IHE develops detailed technical frameworks, which consist of two parts: the Integration Profiles and the Transactions. The Integration Profiles model a process problem and offer a solution to the problem; the Transactions section defines in thorough detail the way in which current standards are used to solve the problem. So IHE combines out of both standards HL7 and DICOM the essential parts to solve the integration tasks. Until today frameworks for the following areas have been defined: IT Infrastructure, Patient Care Coordination, Radiology, Cardiology, Eye Care and Laboratory. The technical implementation of the frameworks by manufacturers is tested and reviewed in so-called Connectathons. IHE has substantially facilitated the very complex integration process in radiology and is likely to demonstrate the same effect in other clinical areas. However, for explanatory reasons this review will concentrate on the required specific HL7 and DICOM elements.

Functional integration

The goal of Functional Integration is to synchronise the “context” between different software (SW) applications, which in the medical field is usually a patient. Typical examples for Functional Integration are the synchronisation between the Software of a RIS and a PACS Workstation (WS) or between an HIS-EPR Client-SW and a PACS Web-Client-SW (Fig. 1). Data or commands are only exchanged in order to ensure that the same patient is visualised in both, but do not represent medical “content”. Therefore, Functional Integration is more frequently called “Visual Integration”, which will be used in the following. But also the term “Front-End integration” is sometimes used, since the integration is a client oriented procedure which only takes place locally on the Front-End of the system, the PC.

The standard CCOW (Clinical Context Object Workgroup) [24], which is associated with the HL7 organisation, was created for Visual Integration. A “context manager” is used as a central dispatcher and can synchronise the patient context, amongst other features, between the applications to be connected. But until today CCOW is not in widespread usage. So Visual Integration is still mainly un-standardised. The synchronisation between a RIS and PACS WS-Client-SW, which is an essential feature for a radiologist, is a typical example. Ideally, this Visual Integration should work bi-directionally so that a change of patient in the RIS Client-SW would automatically lead to the loading of the related images in the PACS WS-Client-SW and vice versa. This is usually possible when both systems are from the same vendor, but otherwise often difficult.

The second example for Visual Integration is the synchronisation of a HIS-EPR (or RIS) Client-SW and a PACS Web-Client-SW. For this integration the HIS-EPR Client-SW composes a URL (unique resource locator), including the DICOM UIDs, which is then–including login information (user and password)–transmitted to the PACS Web-Client-SW, which retrieves the requested images. The degree of functionality of this integration will depend on the possibilities of both products. The most frequent way is to retrieve one particular study (Study-level Visual Integration); alternatively, a study selection window of the PACS Web-Client-SW is opened for one patient, allowing the manual selection of multiple studies (Patient-level Visual Integration). This integration is often solved in proprietary ways, but now DICOM “Web Access to DICOM Objects” (WADO) [25] provides a standardised approach. Usually the administration and allocation of access rights is left to the HIS-EPR. It is evident that this integration approach requires the necessary UID information in the HIS-EPR, which is mostly obtained from the PACS via DC-IAN (Instance Availability Notification) or from the RIS, e.g. via HL7-ORU (Observation Results).

General integration framework for radiology

With the above-described system integration technology, a typical integration configuration between the three core systems, HIS-EPR, RIS and PACS, as existing today in diagnostic radiology, shall be described as an example for how those elements interact and have to be seen in conjunction (Table 2, Fig. 1). This approach applies in a very similar way to integration scenarios where another SPIS covers a RIS-like functionality and will therefore in the following be called “RIS-like” integration. There are more interfaces between HIS-EPR and RIS (e.g. for the materials management process), but those are neglected.

Critical success factors for system integration

For all integration approaches there are some core requirements that should always be fulfilled in order to achieve a proper overall functionality including campus-wide image distribution with HIS-EPR integration. In general it is essential to establish a closed and uninterrupted information cycle from the HIS-EPR down to the lowest system in the specific approach where the MMOs are stored (PACS or SPIS) and all the way back to the HIS-EPR in order to ensure synchronicity of the most important UIDs, the Patient-ID and the Accession Number.

Outside of radiology one will not find a RIS and hence the HIS-EPR, besides its own tasks, has to cover this functionality. The first HIS-EPR core requirement is to perform the complete order communication process (Order Placer and Order Filler together) and to deliver a Worklist to as well the modalities as the PACS or SPIS [DC-MWL (Modality Worklist)]. This process can be facilitated by a “PACS broker”. When either the HIS-EPR or the SPIS and PACS do not support a DC-MWL there is a feasible workaround: to let the HIS-EPR create an HL7 message containing the Scheduled Procedure and the Filler Order Number and direct that to the SPIS or PACS. This message can be called HL7-ORR-like (Order Result).

The core task of the modality integration technology is to produce DICOM objects and to export those via DICOM to the PACS. Besides accepting the Worklist from the HIS-EPR the PACS has to have the capability to import, store and display the various DICOM objects both on the PACS WS-Client-SW as on the PACS Web-Client-SW. So each particular DICOM-Object has to be supported by at least four instances: the sending device (modality), the PACS archive, the PACS WS-Client-SW and the PACS Web-Client-SW, otherwise integration is useless.

After storing the objects, the PACS has to generate an availability notification to the HIS-EPR. As mentioned above, this would ideally be achieved by DC-IAN, but also HL7 or proprietary approaches can be accepted depending on the systems capabilities. The last core requirement for the HIS-EPR is to establish an either Study- or Patient-level Visual Integration between the HIS-EPR Client-SW and the PACS Web-Client-SW.

Modality integration technology

In enterprise imaging, a variety of devices produce a very heterogeneous mixture of objects and signals which are summarised as multimedia objects (MMO). Those can be analogue (e.g. paper, analogue video), various digital formats of still images (e.g. JPEG, BMP, TIFF, GIF, PNG), videos (e.g. mpeg, avi, Quicktime) but also waveforms in mostly proprietary formats or very specialized visualisations like scatter plots or electrophoresis results from laboratory machines. Apart from their different nature, all devices shall here be summarised as “modalities”. On the other hand most “classical Radiology” PACS can directly only import DICOM-objects. For MD-PACS it is hence essential that all analogue objects are digitised and all digital non-DICOM MMOs are converted into a DICOM-Object.

But there are not only MMOs. Some modalities additionally produce alpha-numerical content. This can be texts (e.g. automatically generated ECG reports), values or measurements derived from image or video analysis (e.g. echocardiography) or from the analysis of waveforms (e.g. haemodynamic pressure values in cardiac angiography). Theoretically this information could be stored in the PACS using DC-SR objects. The problem is that this information is required in the HIS-EPR either as a report itself or in order to facilitate report editing. For this integration three options can be chosen, of which each has its advantages and disadvantages: using DICOM via DC-SR or DC-MPPS (Modality Performed Procedure Steps) or using HL7 via ORU. Conceptually the application of DC-SR is the superior way [22] but unfortunately not supported by many HIS-EPR. Since it is not likely that one of the mentioned approaches will be supported by all modalities or systems to be connected, one may end up having to implement all three alternatives, of which each is difficult to solve and may lack stability. In order to avoid this, it is recommendable to carefully analyse the need for integration and to consider whether one can abstain from having the alpha-numerical information in the HIS-EPR.

To summarise, the guideline for integration should be that MMOs are stored in the MD-PACS, while alpha-numerical information is transferred to the HIS-EPR. Based on the technical approach, how different modalities can be integrated into an MD-PACS four integration alternatives are described. Theoretically more integration approaches can be imagined, but it is the aim to review presently existing possibilities. Some aspects could not be supported by literature and are therefore based on the author’s experiences. Those may not be applicable on a worldwide basis; however, the basic concepts should remain identical and allow the radiologists to assess how and to what extent integration into MD-PACS is possible.

Type-I: Direct modality integration

Principles

In the Type-I approach the HIS-EPR replaces the RIS, performs the complete order process (Order Placer and Filler) and provides the DC-MWL and also the report editing. The modalities are directly integrated via DICOM and the MD-PACS takes care of storage and display.

Integration concept

In order to generate a Worklist, all examinations have to be requested, scheduled and booked in the HIS-EPR, even if this happens in the unit performing the examination itself. The HIS-EPR will then provide the Worklist either via DC-MWL or proprietary implementations (Fig. 2) to the modalities as well as the PACS. The modalities optionally return study information (DC-MPPS) or alpha-numerical data (DC-SR, DC-MPPS) and store the MMOs to the PACS [DC-Store (Storage), DC-STCM (Storage Commitment)]. The reading of the MMOs is conducted with the regular PACS WS-Client-SW and the report editing process is performed in the HIS-EPR Client-SW. Both are ideally interconnected using Visual Integration. Should liability reasons prevent the installation of a HIS-EPR Client-SW on the PACS-PC terminal server concepts (e.g. Microsoft, Citrix) can provide a solution. In this case the Visual Integration between the HIS-EPR and PACS WS-Client-SW can be difficult. As for radiology the access to the campus-wide image distribution (Fig. 1) is solved via the HIS-EPR Client-SW and the PACS Web-Client-SW Visual Integration based on UIDs from the DC-IAN.

Fig. 2
figure 2

Schematic diagram of Type-I modality integration approach. For HL7 and DICOM acronyms see Table 2. Black continuous line Data Integration; red continuous line Visual Integration; black dotted line Client-Server communication

Full size image

Assessment

Since HIS-EPR has to replace the RIS it also has to offer all equivalent functionality. Most HIS-EPR systems which include a RIS module are very likely to have the capability to provide DC-MWL, but may be lacking DC-SR or DC-MPPS support. In this case the import of alpha-numerical data is a problem since hardly any modality supports the alternative HL7-ORU. Also, DC-IAN as a quite recent element in DICOM might be lacking on the HIS-EPR or PACS side, but proprietary implementations are usually possible.

On the modality side, DC-Store of Ultrasound and Cardiac Angiography Multi-frame objects will mostly be possible, but the export of Waveform objects from haemodynamic (HD) and electrophysiology (EP) measurement systems in cardiac angiography will often not succeed. Here the modality and PACS vendors should be pushed for an extended DICOM support. Mobile Ultrasound machinery is frequently used in an ad-hoc fashion and the generation of an order in the HIS-EPR may be perceived as cumbersome by the user, but there is no way around. Modalities which may produce alpha-numerical data in addition to MMOs are echocardiography and HD and EP measurement systems, and especially in paediatric cardiology a quite extensive set of measurement values may arise from echocardiography. The most promising way for the export of these data is DC-MPPS, which–as mentioned above–may not be supported by the HIS-EPR.

As for modalities, the PACS will usually support Ultrasound and Cardiac Angiography objects, but Waveform objects can often neither be imported nor displayed. For the reading of cardiac angiography special post-processing features like quantitative coronary and ventricular analysis (QCA and QVA) are required on the PACS WS-Client-SW. Some vendors have recently provided those features. A DC-IAN functionality is mandatory and mostly possible, although often by proprietary means.

Areas of application

Recent ultrasound machines, MRI (e.g. in cardiology, orthopaedics) or cardiac angiography including HD and EP measurement systems.

Summary

To summarise, Type-I integration is the easiest of all four and it should therefore always be considered first.

Type-II: Modality integration via DICOM Acquisition-SW

Principles

As for Type-I, the HIS-EPR performs the complete order process, including Worklist provision and the report editing. The essential part of Type-II integration is an Acquisition-PC with a DICOM Acquisition-SW which behaves like a DICOM modality (Fig. 3). Using different technologies, this SW can acquire various kinds of analogue or non-DICOM digital MMO, wrap them with a DICOM header and then store them as SC or VL objects to the PACS.

Fig. 3
figure 3

Schematic diagram of Type-II modality integration approach. For DICOM acronyms see Table 2. Black continuous line Data Integration; red continuous line Visual Integration; black dotted line Client-Server communication

Full size image

Integration concept

After receiving the Worklist from HIS-EPR (DC-MWL) the DICOM Acquisition-SW creates an empty folder to which it can import MMOs on three different ways:

  • Frame grabber: this is an additional hardware card, which is inserted into the DICOM Acquisition-PC. The video signal output of an analogue or digital video camera is connected to the frame grabber, which can then either grab one frame (a still image) or multiple frames (a video) and convert those to digital files. So basically a frame grabber is one kind of Analogue/Digital-Converter (ADC). Frequency and quality usually can be adjusted and foot switches to start and stop the grabbing process are supported. The grabbed images or video clips are stored into the empty folder of the DICOM Acquisition-SW and can directly be displayed. Alternatively, the frame grabber can be connected to any standard image processing or video editing-SW [26] for optimization or editing prior to an import into the DICOM Acquisition-SW. For this purpose the images or clips are first stored by the image processing or video editing-SW to the file system in a format that can be read by the DICOM Acquisition-SW and then imported into the DICOM Acquisition-SW.

  • File Import: digital photo and video cameras can generate still images or video clips, which are both stored in files that can directly be copied to a PC. For still images, one alternative to achieve this would be an off-line exchange. All photo and some video cameras store their still images on storage cards like Compaq Flash (CF), Multimedia Card (MMC), Memory Stick (MS) and others, which can be inserted into a card reader, attached to the PC via USB (Universal Serial Bus) and then copied into the file system or an application. The other alternative is the on-line way by direct cable connections. Almost all photo and some video cameras do support USB for on-line connections. For video cameras the Firewire (IEEE 1394) interface is more common. As well photo as video cameras store their still images in JPEG, which can be imported directly from the local file system into the DICOM Acquisition-SW’s empty folder when image processing is not required. Video cameras, however, mainly deliver their videos in a “raw-like” format, which requires rendering with a video editing-SW [26] in order to produce a format readable for the PACS-Acquisition-SW. This process can be time-consuming and even in hardware-based real-time rendering it takes approximately the duration of the video clip.

  • Scanner: recent scanners usually support USB. The integration process into the DICOM Acquisition-SW is unproblematic since the majority of scanners do support the TWAIN standard. Using the TWAIN driver, which is directly opened by the Acquisition-SW the images are scanned and then automatically copied for display into the DICOM Acquisition-SW. Alternatively the image is first scanned with an image processing-SW and then moved to the DICOM Acquisition-SW.

The MMOs acquired to the empty folder are stored by the DICOM Acquisition-SW to the PACS (DC-Store). DC-MPPS is often not applied in Type-II integrations. The reading of the studies can be conducted directly on the DICOM Acquisition-PC or on a PACS-PC, both of which ideally offer a Visual Integration with the HIS-EPR Client-SW where the report editing takes place. In some clinical disciplines key images shall be added directly into the clinical report forming a “Multimedia-report”. Although HIS-EPR applications are neither intended nor designed to handle large volumes of MMO data, most products have the capability to display images and store them either in an associated file system or as Binary Large Objects (BLOB) in the database. A MMO exchange to the HIS-EPR Client-SW for the production of a Multimedia-report can always be achieved through an offline file exchange and sometimes other ways (e.g. clipboard features) are supported for still images.

The remaining parts of the integration concept are identical to the Type-I approach and ultimately also require a DC-MWL and DC-IAN connection between the HIS-EPR and PACS. Alpha-numerical data does not play any role in the Type-II scenario.

Assessment

The HIS-EPR related issues of Type-I also identically apply to Type-II. More than for Type-I, it may be difficult to convince the users that they have to request/book an examination in the HIS-EPR in order to obtain a Worklist for each MMO that they want to acquire. But when the advantages of having the studies in the PACS associated to all HIS-EPR information become evident this should be accepted. DICOM Acquisition-SW which provides the features required for Type-II integration is available from most PACS vendors and also delivered by a series of equipment manufactures together with their instruments (e.g. endoscope, microscope). Frame grabbing and importing still images from the file system is quite easy in handling and should not cause any problems. The formats that the DICOM Acquisition-SW supports for import vary by vendor but JPEG will usually be supported. Manually scanning objects is unproblematic but certainly an approach that is self-restricting due to the inherent effort. The main problem is videos. Apart from the fact that video-rendering is cumbersome and time-consuming, which can be bypassed by frame grabbing, most DICOM Acquisition-SW today can neither import video formats nor store them as Multi-frame SC or VL objects.

The same applies to the PACS import and display capabilities. Still images are supported but Multi-frame SC or VL objects mostly cannot be stored nor displayed on the WS-Client-SW and the Web-Client-SW. Most vendors claim to be working on those issues and to deliver in due time, which has to be awaited.

Areas of application

The basic concept of Type-II integration can be used for a huge variety of modalities, including all analogue or digital devices with a video interface; all digital devices that deliver still image or video formats that either directly or indirectly via an image processing or video editing-SW provide objects that can be imported into a PACS-Acquisition-SW. Additionally all objects that can be scanned are applicable. Its clinical application areas can be Endoscopy and Ultrasound in all disciplines or Ophthalmology, Dermatology and Pathology (amongst others).

Summary

Type-II integration is quite powerful due to the variety of devices that can be integrated. When the “video problem” is solved it could be a strong asset in setting up MD-PACS by opening the non-DICOM MMO world. Today departments with mainly still images (e.g. dermatology, ophthalmology) will benefit.

Type-III: Modality integration via Specialised Information Systems (SPIS) with PACS connection

Principles

Type-III and Type-IV integration are quite similar. The common parts are in brief: patient registration and complete order process including the Worklist are performed by the HIS-EPR. The image acquisition from the modality is conducted via a SPIS. For this purpose techniques described for Type-I and II can be used, but this approach also offers the unique possibility for a direct integration of proprietary modalities delivered by the SPIS vendor. Finally, the reading and usually also the report editing is conducted in the SPIS. The main difference exists in the image storage and distribution. In Type-III, the MMOs are stored exclusively or additionally in the PACS and distributed via the PACS Web-Client-SW (Fig. 4). In Type-IV, the MMOs remain inside the SPIS and can be accessed via a dedicated web-system of the SPIS coupled with the HIS-EPR Client-SW (Fig. 5).

Fig. 4
figure 4

Schematic diagram of Type-III modality integration approach. For HL7 and DICOM acronyms see Table 2. Black continuous line Data Integration; red continuous line Visual Integration; black dotted line Client-Server communication

Full size image
Fig. 5
figure 5

Schematic diagram of Type-IV modality integration approach. For HL7 abbreviations see Table 2. Black continuous line Data Integration; red continuous line Visual Integration; black dotted line Client-Server communication

Full size image

Integration concept

The communication between the HIS-EPR and the SPIS is based on HL7 as usual for information systems. Patient registration is performed in the HIS-EPR and the patient’s demographics are communicated to the SPIS [HL7-ADT (-Admission-Discharge-Transfer)]. The order process is also conducted in the HIS-EPR since the SPIS discussed here do usually not offer scheduling and booking (if the SPIS was the Order Filler it would be a RIS-like integration). Consequently the HIS-EPR does provide the Worklist to the PACS and also to the SPIS and this can become the main implementation problem of this approach in reality: the SPIS discussed here very often do not support DC-MWL, at least not as a DICOM-User. So the workaround the “HL7-ORR-like” message can be tried which may more often be supported. Only when this is not successful an “order-less” scenario with an interrupted communication chain between the HIS-EPR and the PACS should be considered as a last option.

In this case no Worklist or any other order information about the Scheduled Procedure is sent from HIS-EPR to the SPIS. If no Worklist is communicated the SPIS only knows the patient-ID (derived from the HL7-ADT) and just generates its own Accession Number and Study UIDs for an examination. Those are returned to the HIS-EPR together with the final report (HL7-ORU) and can be expanded by alpha-numerical values if required. This will not allow matching with the Scheduled Procedure (if there is one) but at least with the Patient.

The modalities can be integrated to the SPIS Acquisition-PC via the respective SPIS Client-SW using different approaches. Proprietary integrations are very frequent (e.g. ECG machines, spirometry but also echocardiography) and also allow the acquisition of proprietary alpha-numerical information to the SPIS. Examples are automatically generated ECG reports or velocities in echocardiography. In addition to the proprietary integration SPIS can, similar to the DICOM Acquisition-SW, also use Type-II like approaches (frame grabber, file import, scanners) to integrate devices (e.g. endoscopes) or sometimes directly interface modalities via DICOM (e.g. ultrasound) similar to Type-I. After the acquisition the MMOs are first stored either locally or in a network-based storage for reading and reporting. The reports that are transmitted to the HIS-EPR (HL7-ORU) should at least have a low-level structure with a separation of description and summary. If desired, alpha-numerical data can be added to the HL7 message for later exploitation in the HIS-EPR. Depending on the SPIS the communication to the HIS-EPR can in addition to the report be expanded to diagnosis and procedure codes [HL7-BAR (Add/Change Billing Account)] and seldom to billing information [HL7-DFT (Detail Financial Transaction)].

Depending on the initial MMO type and the SPIS, the DICOM objects that are generated by the SPIS and communicated to the PACS (DC-Store) can be SC, VL, Waveforms or Encapsulated PDFs (Portable Document Format) [27]. After storage in the PACS this generates a feedback to the HIS-EPR (DC-IAN), which is again used for the Visual Integration between HIS-EPR Client-SW and PACS Web-Client-SW. In an order-less scenario, this Visual Integration is additionally possible based on the Accession Number and Study UID communicated from the SPIS to the HIS-EPR together with the report (HL7-ORU), which are hopefully identical to those derived from the DC-IAN.

Assessment

The most difficult problem to address for Type-III integration is the Worklist issue between the HIS-EPR and SPIS. The right way to do it (DC-MWL) is frequently not supported by the SPIS. The HL7-ORM/ORR way may be easier on the SPIS side but more difficult for the HIS-EPR and the order-less approach is only a weak option. So it is to a certain extent likely that trying Type-III may not lead to a proper and stable integration. The easy part in Type-III is the exchange of alpha-numerical values, which can just be done with the report (HL7-ORU) and presents no substantial problems.

Problems may also arise associated to the DICOM storage process and MMO display by the PACS. Again the requirements are that the SPIS can export their potentially proprietary MMOs via DICOM and that the PACS is capable of importing and displaying those adequately on both the PACS WS-Client-SW and Web-Client-SW. The availability of DICOM capabilities varies strongly with the object types to be handled. Decreasing in terms of likelihood that the requirements will be fulfilled by both sides, the SPIS and the PACS, the following order can be provided as an approximation: DICOM SC Single-frame objects (e.g. from Endoscopy and Ultrasound SPIS), DICOM VL Single-frame objects, DICOM SC or VL Multi-frame objects and Waveform data (e.g. ECG). Few SPIS and even fewer PACS will directly support the latter DICOM object type. One solution, and perhaps the most realistic one, is to let the SPIS store the MMO as a PDF and encapsulate that in DICOM which is also a supported way in the cardiology IHE integration profiles. Again, the PACS and the PACS clients would have to support DICOM Encapsulated PDFs, but this is much more frequent and realistic.

Another issue which may occur with some SPIS are Multimedia-Reports which are textual reports including MMOs like, for example, key images. Those cannot be transferred via HL7 to the HIS-EPR, so one has to exchange the textual information alone and retrieve the MMO via the PACS Web-Client, which is certainly cumbersome, apart from legal problems with this procedure. This applies identically to Type-IV apart from the fact that the MMOs then will have to be reviewed via the SPIS’s web-system.

Areas of application

The two main reasons why a Type-III integration may be considered are: firstly a SPIS is required because the functionality cannot be provided by HIS-EPR and the MMOs shall be included in the PACS either for campus-wide image distribution with Visual Integration into the HIS-EPR or for long-term storage; secondly, the SPIS is required because the modalities do deliver fully or partially proprietary interfaces and can otherwise not be integrated. Frequent examples for the first justification would be SPIS dedicated to Endoscopy and Ultrasound. The latter reasoning can often be found for modalities delivering Waveform data like ECG and Spirometry and for SPIS integrating those devices. Unfortunately, especially in the latter group, DICOM capabilities are often lacking.

Summary

Type-III integration is the best and often the only solution for devices which offer only proprietary interfaces and hence cannot be integrated by other means, provided that the SPIS fulfil the described prerequisites. It also offers a reasonable way of integrating SPIS that can or shall not be replaced for functional reasons.

Type-IV: Modality integration via Specialised Information Systems (SPIS) without PACS connection

Principles

The principle concept of Type-III and IV integration is identical. The main difference is that with Type-IV the MMOs remain inside the SPIS and can be accessed via a dedicated web-system of the SPIS coupled with the HIS-EPR Client-SW (Fig. 5). So there is no connection between the SPIS and the PACS. From a straight point of view this no real integration approach since the MMOs are not included into the MD-PACS. But it may be raised from the departmental viewpoint and therefore the radiologist should know the advantages and drawbacks.

Integration concept

As for Type-III, there is an HL7-ADT connection between the HIS-EPR and the SPIS and the preferred way to communicate the Worklist is DC-MWL with the HIS-EPR-created HL7-ORR-like message or the order-less scenario as workarounds.

The modality integration is identical to Type-III, but the reading of the MMOs can in this case solely be performed on the SPIS Client-SW since the MMOs never reach the PACS. After editing with the SPIS Client-SW, the report is transmitted to the HIS-EPR (HL7-ORU). It is important to realise that this is the first and usually the only feedback to the HIS-EPR since there is no DC-IAN in this integration approach. This implies that before the report is available a Visual Integration with the SPIS Web-client is a “blind” query and in the case of the order-less scenario can only be performed on the Patient-level. The user outside the department will not know whether there are images for review or not.

Assessment

As for Type-III, the two main reasons why a SPIS may be required are either functional deficits of the HIS-EPR or modalities that can only be integrated via the SPIS. The Type-IV approach can offer a solution if neither the SPIS nor the MD-PACS do provide the DICOM capabilities required for Type-III integration. But also the functionality of the SPIS-associated web-system can be a reason to choose this approach. The web-system may offer dedicated documentation elements, viewers or reporting features that are specially geared towards the application scenario and can therefore not be replaced by the generic PACS Web-Client. As mentioned, a prerequisite for Type-IV is the availability of a dedicated web module for campus-wide MMO distribution which also allows for Visual Integration with the HIS-EPR. If this is not available, the campus-wide installation of local SPIS-clients should certainly not be considered as an alternative due to the massive inherent support effort.

The major disadvantage of Type-IV is that all SPIS Web-systems have to be connected to the HIS-EPR Client-SW for Visual Integration. The fact that there are usually modalities from multiple vendors (e.g. ECG) could, due to the required proprietary integration, even lead to multiple SPIS for the same modality type, e.g. multiple ECG management systems. This could create a very heterogeneous IT-architecture and it is know that complexity usually rises exponentially with the increasing number of SPIS. It should therefore always be considered whether integration is mandatory and it may very often be wiser to avoid the MMO integration attempt at all and stick to the textual information instead of creating an unmanageable IT-architecture. A second disadvantage of multiple SPIS web-systems is that they all present different user interfaces decreasing the overall usability for the clinical staff.

Areas of application

Usually there are many SPIS in large care facilities out of which few may provide web-systems for integration. This is perhaps most often the case for Endoscopy and Ultrasound SPIS, Laboratory information systems (LIS) and sometimes for ECG management systems.

Summary

The Type-IV approach can be very problematic and it is essential to keep the amount of SPIS to be integrated at the lowest possible level. This can be supported by a high degree of standardisation of the modalities. Ideally it is restricted to cases where either the modalities can only be integrated via the SPIS or the SPIS’s web-system provides a unique functionality.

System and modality integration examples

Ultrasound

Ultrasound is present and part of the daily routine in many clinical departments. More recent machines are usually DICOM-compatible, delivering Single- or Multi-frame objects. Older machinery can provide an analogue video signal. SPIS are frequently seen in gastroenterology, obstetrics and gynaecology and surgery but uncommon in other departments, unless in conjunction with one of the first-mentioned units. Those SPIS can sometimes deliver Multimedia-reports which integrate key images from the examination into the textual part. Especially in gastroenterology, but also in other clinical disciplines, the SPIS can include an Endoscopy module in addition.

Should there be no SPIS in the department, a Type-I integration of the DICOM-compatible Ultrasound machines and a Type-II integration of all other devices is the preferable approach. The inclusion of the clinical documentation in the HIS-EPR is not a prerequisite, it can also remain paper-based. In departments with a SPIS a thorough evaluation has to take place as to whether the textual documentation can be replaced by HIS-EPR. If this is the case, again Type-I or II integrations are preferable. When a replacement of the SPIS is impossible, a Type-III approach should be targeted first and only when the SPIS does not provide this option but instead delivers a web-system Type-IV integration can be considered. Especially when the SPIS supports a strategically important department or bundles a significant number of Ultrasound machines and maybe even endoscopes in addition this can prove beneficial. If this is not the case, it is more reasonable to leave the system isolated or just integrate the reports via HL7-ADT and ORU but to abstain from trying to integrate the MMOs. Neither Type-II nor Type-IV integrations allow the transmission of Multimedia-reports to the HIS-EPR with the implications described in the Type-III section.

Endoscopy

Like Ultrasound machines, Endoscopes are used in many clinical disciplines. Usually they will not support DICOM SC or VL Single- or Multi-frame objects but just deliver a video signal [28–34], although alternatives are found for direct PC-connection [35]. SPIS are quite common for certain departments, e.g. gastroenterology [36, 37], and, as for Ultrasound, often also include report editing. MMO documentation in SPIS covers mainly still images but the acquisition of videos is also not uncommon.

If no SPIS is present, the MD-PACS integration with Type-II can be achieved without any problems for still images but since videos will often be lacking deliver an incomplete solution. Nevertheless instead of introducing a SPIS it is preferable to restrict the usage to still images and await the availability of Multi-frame DICOM VL or SC objects by the involved products. In departments with an existing SPIS, the following procedure can be recommended: the first choice would be to analyse whether a replacement of the SPIS by HIS-EPR, and hence a Type-II approach, is possible. Should this not be the case, Type-III integration can be considered if videos are not required, otherwise the integration can be restricted to the textual HL7 level. When videos are required and the SPIS offers a web-system supporting this, the decision of whether Type-IV integration is attempted has again to be based on the before-mentioned strategic considerations.

ECG

ECG is present in various clinical departments, although with a focus on cardiology and the machines usually produce a brief automatically generated report in addition to the waveform data. There are few ECGs that directly support DICOM Waveform or SR objects. SPIS (called ECG management systems) are quite common [e.g. 38, 39] and interface the machines often in different proprietary ways.

Type-I integration is usually impossible due to the proprietary nature of the ECG machinery and the lack of DICOM support. Type-II integration by scanning the ECG print-outs may be seen in the context of archival projects with document management systems where the whole conventional patient file is scanned but is otherwise uncommon, perhaps due to the inherent effort. So a SPIS-based integration will be required. As well as Type-III, Type-IV integrations are principally possible but both may be difficult since most ECG-management-SPIS or the MD-PACS are lacking certain features required for an effective integration. In order to avoid multiple ECG management-SPIS, it is essential for both approaches to connect as many ECGs as possible to the SPIS, which can be facilitated by as well by interface engines as by standardisation. Depending on the number of remaining devices which cannot be connected the introduction of a second ECG management-SPIS can be considered versus just leaving those ECGs unintegrated. Among the different possible DICOM objects with Type-III it is more likely to succeed when using DICOM Encapsulated PDF [27] instead of Waveform objects. The decision on whether a Type-III integration is preferred to Type-IV will strongly depend on the clinicians’ needs. When they are happy with PDF “print-outs”, Type-III is the choice. If the SPIS web-system delivers a specific viewer which is required, obviously Type-IV is the superior way to go.

Pathology

Digital image documentation is not a mandatory step in pathology and the diagnostic process can be performed without it. The main reasons for digital imaging are [40] educational and didactic purposes, research, quality control and assurance, Telepathology including second opinion and the so-called value-added pathology. Image documentation in pathology is almost only photography [40, 41], either in the form of macroscopic or microscopic photography, and various kinds of analogue and digital photo equipment are used. The cameras have to support remote control and especially for autopsy dedicated workplaces may be required [42, 43]. Although SPIS for the textual documentation are very common in pathology only few of them store MMOs and DICOM features or integrations with a MD-PACS [44] are not found too often. Usually the MMOs are just saved to file systems or personal databases and not associated to the SPIS.

Due to the mostly lacking DICOM capabilities of the modalities, Type-I integration is no realistic alternative. In some hospitals, the HIS-EPR does replace a SPIS. Here Type-II integration with a DICOM Acquisition-SW is applicable, which requires an electronic order process in the HIS-EPR. This can either be done by the clinical users, which is rather uncommon today, or by the pathology staff having to manually request and schedule the examination, which also may lead to compliance problems. Another aspect has to be considered: there exist special digital photo cameras which offer so-called SDKs (Software Development Kits), which allow remote control of the camera and a direct data exchange with an application. The integration of those SDKs may be difficult with standard DICOM Acquisition-SW. However, if those issues are solved or unnecessary, Type-II integration with HIS-EPR and MD-PACS is a very good solution. Type-III integration suffers from two drawbacks: it requires an order entry process similar to Type-II, which can be addressed by using the order-less approach, and the SPIS often do not support DICOM SC objects. Apart from exceptions [45], Pathology SPIS mostly do not offer web-systems making Type-IV integration impossible. But if a web-system is available this integration type has to be considered the superior option to integrate Pathology into a MD-PACS for the following reasons. It can bypass the rather uncommon order entry process by an order-less approach and it does not require DICOM capabilities of the SPIS. Also the main drawback of the order-less approach that Study-level Visual Integration is bound to the report availability is no real disadvantage here.

A special issue in pathology is Virtual Microscopy (VM) [46–48], which has been developed in the past years. In VM the whole slide is “scanned” and can be reviewed without any microscope on a PC, including seamless zooming and other features. Virtual microscopy offers significant advantages, but the scanning process is today still time-consuming and uncomfortable and it delivers data files of around 50 GB per slide [46], which can sum up to several PB per year (1 PB=1,000 TB). Although VM is very likely to be a future technology in pathology, solely from the cost perspective, it is today no reasonable replacement for conventional shelf archiving of the slides and hence there is no need for its inclusion into a MD-PACS. It may, however, very well be used for Telepathology.

Dermatology

The modalities in Dermatology are mainly photo cameras with a high amount of digital cameras [49, 50]. The MMOs produced are either analogue or digital still images [51, 52] both of which can be integrated using Type-II. SPIS [50] are an exception and hence do not affect integration. Also, since there are no further special aspects which have to be considered, dermatology is perhaps the hottest candidate for an easy inclusion into a MD-PACS.

With respect to dermato-histopathology [53], what was said for pathology is applicable. Since there is hardly any SPIS solely dedicated to dermato-histopathology, an inclusion of the MMOs into the MD-PACS using Type-II is the most feasible approach.

Ophthalmology

Ophthalmology as a visual discipline has a long history of analogue but also digital documentation and a variety of different modalities. Most of them will deliver still images but few will support DICOM objects. Ophthalmologic practices frequently use dedicated SPIS, but equivalent systems are not so usual in the hospital context [54–56].

So Type-II integration appears to be the superior approach in Ophthalmology, storing the still images as DICOM SC objects, which can easily be integrated into the MD-PACS. With respect to ophthalmologic objects, the DICOM standard provides additional features [57] which may not be supported today by standard DICOM Acquisition-SW but offer possibilities for more elaborate integrations in the future. Altogether ophthalmology offers a large potential for inclusion into a MD-PACS. In this case the clinical documentation is ideally solved in the HIS-EPR.

Cardiology

Besides ECG, the core modalities in cardiology are cardiac angiography [58–60] in conjunction with the HD and EP measurement systems and echocardiography [61–65]. Most of today’s cardiac angiography and echocardiography devices are DICOM-compliant and do at least offer DC-MWL and DC-Store also for Multi-frame objects. The HD and EP measurement systems do also mostly support DC-MWL and DC-MPPS but not DC-Store of the Waveform Objects and also support of the PACS for those is usually lacking. Alpha-numerical values can result from echocardiography and HD and EP measurement systems but a communication of those values to either the HIS-EPR or a SPIS is not too often found. There is a variety of SPIS in cardiology which cover different application areas. Besides the classical Cardiology Information System (CIS), which is comparable to the RIS, there are products which, for example, combine CIS with HD/EP measurement components or PACS with report editing. This makes a description of all integration alternatives impossible.

Since all recent cardiac angiography and echocardiography modalities support DICOM, Cardiology is a good example for a Type-I approach, when some specific requirements are fulfilled by the PACS. Of course the respective Single- and Multi-frame DICOM Objects have to be supported and displayable on the PACS WS-Client-SW and in the Web-Client-SW. But the PACS WS-Client-SW should offer in addition analysis features like quantitative coronary and ventricular analysis (QCA and QVA). Since those requirements have recently been fulfilled by some PACS products the inclusion of cardiology in the MD-PACS using Type-I is principally possible and also the preferable approach. Older modalities without DICOM can be included by Type-II integration techniques but will remain restricted to still images. The inclusion of Waveform data from the HD an EP measurements systems into a MD-PACS is very difficult. All four presented modality integration approaches can fail for different reasons. This may also be due to the fact that there is no ultimate need to have the full HD or EP protocol in the PACS. But if an inclusion is desired a Type-I integration appears to be the most feasible approach which would require the modality and PACS vendors to implement the necessary DICOM features. However, one should not be too optimistic about the success of this attempt. With respect to the Alpha-numerical values, there exist interface engines for echocardiography modalities which support various in- and output protocols. For HD and EP measurement systems all initially described alternatives (DC-SR, DC-MPPS and HL7-ORU) can be tried depending on the involved products but the expectations should not be too high. The main issue in cardiology today is not the modality integration but the SPIS integration. The coupling of HIS-EPR and CIS is even more complex than the HIS-EPR-RIS integration and it is therefore reasonable to avoid this integration and try to implement the “CIS”-functionality in the HIS-EPR when this supports all requirements. If SPIS integration cannot be abandoned, a highly sophisticated architecture will be required, which is beyond the scope of this review to describe.

Summary

In the scope of a review focuses have to be set. The main objective was to discuss the approaches for an extension of the classical “radiology-PACS” into an MD-PACS by employing the possibilities circumscribed by the framework of the standards HL7, DICOM and IHE. Within this range other potential candidates for an inclusion into a MD-PACS–like, for example, Radiotherapy, Dentistry and Teleradiology–had to be neglected.

But also one very recent trend was excluded, the extension of Document Management Systems (DMS) or generic Archiving solutions into the classical PACS domain, trying to integrate the DICOM and Non-DICOM worlds and vice versa. DMS have a long history in association with HIS-EPR installations for the archiving of as well analogue paper documents after scanning but also primarily digital documents via archival interfaces. Some DMS manufactures have recently expanded their systems by DICOM capabilities and viewers, and also PACS companies try to enter the DMS market segment. However, an in depth discussion of those approaches would be a review on its own.

Leaving Virtual Microscopy aside, to establish a MD-PACS is an integration task but not a storage capacity issue. Although there are no precise numbers and the amount of generated data will often strongly vary with the individual user’s behaviour, the data amounts are comparatively low and will not substantially add up to the storage capacity required for radiology and cardiology.

The implementation of a MD-PACS provides a set of advantages and especially those units and departments which produce mainly still images and do not already have a SPIS for image archival will benefit from an inclusion using Type-I and II approaches (e.g. dermatology, ophthalmology, ENT). The solution is more difficult for departments with a SPIS. Very often those will not allow Type-III or IV integration due to lacking DICOM capabilities or dedicated web-systems. If such departments shall be included in the MD-PACS, a replacement of the SPIS by HIS-EPR with the utilisation of Type-I or II integration approaches appears as the only reasonable way. Whether this is possible will depend on both the functionality of the HIS-EPR and the MD-PACS. Especially in this context HIS-EPR and PACS have to be perceived as a tightly coupled pair which only together can achieve its objectives. Hence PACS is becoming one of the core systems of the hospital IT landscape and has to be considered an essential pillar together with the ERP (Enterprise Resource Planning) and HIS-EPR systems which may also have implications on the support strategies [66, 67]. In this process, the radiologist, with his dedicated PACS know-how, is a key player and partner for other departments, hospital administration and central IT.

Finally, it can be concluded that MD-PACS can for some modality types and clinical departments be implemented today and demonstrate substantial advantages. With the evolving general PACS development it is very likely that it will become an important IT trend in the near future.