After picture archiving and communication systems: information technology in radiology

This is my perspective of information technology (IT) developments in radiology, based mainly on my experiences of the current situation in the English national health service (NHS) and some knowledge of the other countries of the UK. The views expressed here represent my personal opinions, and are not necessarily those of my NHS employers. I have confined my comments purely to IT matters. I shall not, therefore, be discussing developments in computer aided diagnostics, in reformatting or other image manipulation techniques, nor in imaging, such as the use of terahertz radiation.

Despite being given the title “After picture archiving and communication systems…”, the story of picture archiving and communication systems (PACS) in the NHS is far from over. PACSs are used throughout England and Scotland, but Wales and Northern Ireland still have some catching up to do. Even in England, there is still room for development in the PACS arena, in particular in regard to image and report sharing (this is less problematic in Scotland, given that they have a single PACS entity that spans the whole nation).

For completion, I would also like to consider the question in reverse: “After radiology, what next for PACS?”

Image and report sharing

The current situation in the English NHS is that all secondary care trusts have good working PACSs from reputable PACS vendors. All have local data stores, and those provided by Connecting for Health (CfH) under the National Programme for IT (NPfIT) are linked to mirrored cluster data centres (CDCs), which are based around the political boundaries of the five original contractual groups or “clusters”.

The original CDC concept was to provide three main benefits:

1. off-site, replicated back-up;

2. an alternative to local off-line storage for older studies, when the local storage becomes full;

3. facilitation of data sharing across the cluster.

The first of these benefits is being fulfilled; the second too, with the caveat that the speed and capacity of the NHS network can sometimes be limiting. The third objective, however, is not yet a reality. There are two main reasons for this.

First, across a given cluster, a single unique identifying number (UIN) is required to match up studies from a particular individual stored by different trusts. In England, this number should be the NHS number, but unfortunately this is not used often enough to allow it to be utilised as the UIN. Much effort is being made to increase the use of NHS numbers to the extent that they can be used in this way, yet a small but significant number of patients still do not have NHS numbers allocated. The reasons for this are issues of data quality, including tardiness in updating patients' demographic records (in part because some trusts do not have patient administration systems (PAS) that can be automatically updated from the demographics database held on the NHS spine). Foreign visitors, members of the armed forces and illegal immigrants are unlikely to have NHS numbers. It is not easy to allocate temporary NHS numbers to these people when they attend for imaging, and thus records without an NHS number are inevitably generated and uploaded to the CDCs.

Second, considerable concerns regarding information governance (IG) must be addressed because the CDC architecture will permit searching across all the records of many trusts. The primary restraints to be applied here are role-based access control (RBAC) and legitimate relationships (LR). In simple terms, RBAC limits access to specific sections of the electronic record according to the user's job role (e.g. a doctor will be able to see clinical areas that an appointments clerk will not), and LR controls which specific clinician has access to which specific patients' records. This is achieved by having the application check an individual's credentials against an IG database held on the NHS spine, the user having been identified at log-on by the use of a smart card.

Data for both LR and RBAC are provided from the NHS spine database, with the interface between the central spine and the local trust systems being maintained by the PAS component of the care record system (CRS). Other systems, such as PACS, the radiology information system (RIS) and pathology systems, defer to the PAS when determining legitimacy of access. Regrettably, in England many trusts' PASs are not “spine enabled” and cannot maintain these data, resulting in an absence of the built-in control over access to other trusts' patient records in the CDC. There is also on-going debate about patient consent to such widespread sharing, mainly around the question of consent being either opt in or opt out.

Even when these obstacles are overcome, the delay in images reaching the CDC (typically via overnight trickle upload due to bandwidth limitations) will preclude image sharing in the acute situation.

So, how should we be sharing images? Various methods are currently in use including compact disks, web viewers, point-to-point dipital imaging and communications in medicine (DICOM) transfers and transfers via intermediary systems.

Compact discs (CDs)

According to circumstances, guidance for which is contained on the CfH website, CDs may be encrypted or unencrypted [1, 2]. They are easy to transfer with the patient or by post, and usually contain an image viewer. Encryption is required to avoid sensitive patient information, including images and reports (which will probably contain detailed clinical information), falling into the wrong hands should the CD be lost or stolen. An encryption strength equivalent to AES256 has been mandated for NHS use. Loading data from a CD to the recipient's PACS is not always straightforward, particularly if the CD is encrypted.

The CfH method involves copying an unencrypted CD and re-burning it with encryption. This means that it will not open and run the viewer, nor will files be easily extractable for import to the recipient's PACS. The CD must be decrypted and burned onto a second CD to achieve the functionality of the original CD (some viewers will run from a hard drive folder, but most will not and need to be run either directly from the CD or using some additional script to simulate this). I must declare an interest here, having devised an encryption system that makes this task simpler for most recipient PACSs, which is provided free of charge to NHS users. The CDs can be produced directly from the PACS workstation without any intermediate step and, once the correct password has been entered, will offer to open in the viewer (as would an unencrypted CD). Further, they will open in a file explore window to allow PACS managers to move them to a new location, generally the PACS database, or (for certain recipient systems) to add the data on the CD directly to PACS with a single mouse click.

Web viewers

Many trusts share access to their web viewers across the NHS network, allowing registered users from other trusts to view patient images and reports. Image quality may be limited by the monitor being used, and may or may not be suitable for diagnostic purposes (as opposed to image review). Also, there are significant considerations regarding IG until LR and RBAC are fully instituted. Because users must be registered with each PACS they wish to view, significant administrative overheads are involved in approving and managing these users, particularly for junior staff, who regularly move between posts.

Point-to-point DICOM transfers

Point-to-point DICOM transfers may be effected by query-retrieve (which raises IG concerns in the current absence of LR) or, better, by C-move (pushing a specific study to the recipient's PACS). In the latter, the originating trust is in control of what is viewable by staff at the recipient trust. For security, only the NHS network may be used (so transfers outside the NHS may be difficult), and virtual private networks (VPNs) must be set up to provide secure transit of data. Many trusts find it hard to get IT departments to set up VPNs at either end of the connection. Image sharing agreements [3] are required, and must be approved by the Caldicott Guardian (a senior clinician with board-level responsibility for oversight and approval of patient data flows and confidentiality), making the setting up of such links time-consuming. Once set up, however, they work well in transferring studies from one PACS to another. A disadvantage of this type of transfer is the human input required. Studies have to be located and directed to the correct recipient; and at the receiving end, the study has to be manually linked to the patient record in the recipient PACS and RIS. There is also a risk of the duplication of studies at the CDC if the same data are archived from each PACS.

Transfers via intermediary systems

Systems using intermediaries to exchange data involve transferring studies to a temporary store, which is managed by a commercial operator or by an NHS body, from which the intended recipient(s) can download them within a specified period of time. A local temporary store is needed at the recipient trust from which images may be viewed before deciding whether or not to add them to the main PACS.

Since I began writing this paper, CfH has announced its own version of such an application, referred to as the image exchange portal (IEP) [4]. This is a development of the “independent sector router”, a project originally intended to facilitate the secure transfer of images from private sector organisations (with no NHS network connection) to NHS institutions. By the time this paper is published, testing should be complete and the system should be in use by the early adopters. It uses a central server to store images that are intended for sharing, with the process of image transfer being controlled by a web-based interface for ease and consistency of use. Images may be transferred between workstations, can be imported directly to PACSs or may remain on the server for viewing over a web interface. The latter is best for large institutions which have a high traffic of studies for review (e.g. for second opinions and multidisciplinary team review), but do not necessarily need to retain the images in perpetuity (which would incur storage costs and the duplication of studies on the CDC).

Are any of these methods ideal? Probably not, but each has merit in different circumstances. In particular, the initial presentations of the IEP show considerable promise and this system seems likely to become widely used.

One of the original high-level requirements of NPfIT was compliance to pre-existing standards wherever possible. In the realm of healthcare records, the relevant standards derive from Integrating the Healthcare Enterprise (IHE) [5]. A developing standard for image sharing is emerging from this body, the Cross-Enterprise Document Sharing — Imaging (XDS-I) protocol [6], and this should be the best approach. There may be some concerns about instituting nationally a system based on a standard that has not yet reached maturity. As a major user, however, the NHS would be well placed to influence the evolution of XDS-I as experience is gained in a large-scale arena. The alternative is to develop the system within the rather more limited environment of the connectathons in which XDS-I has been tested to date.

The basic concept of XDS-I derives from that of XDS, in which a document to be shared is uploaded to a file repository and information about the document, for example its author, site of origin, contents and keywords (i.e. metadata), is stored in a registry. The registry is indexed and searchable, and, when a document is found, it can be downloaded using a link to the file in the repository [7]. For XDS-I, the large file sizes of imaging studies would make duplication in a repository impractical. Instead, the (searchable) metadata held in the registry link directly to the original location of the images. Thus, a user who wanted to share some images (a document source in XDS terminology) would publish the metadata in the registry, and the recipient (document user) would locate the metadata that would enable the images to be downloaded from the originator's PACS (which acts as proxy for the document repository in the XDS scenario). The whole system would be protected by access controls and the metadata would include information on who is entitled to access the images.

The huge advantage of this approach is that the radiology report, which is treated like any other document, could also be referenced in the metadata and shared along with the images. This is essential to good radiological practice and difficult to achieve by other means, particularly if you need to ensure that you always have the latest version of the report with current addenda (e.g. after review by a multidisciplinary team). As the registry links to the original source document, anyone following that link will gain access to the updated data. For more technical detail, a presentation from IHE is available on the internet [8].

All three of the NPfIT PACS vendors claim IHE compliance, which they have demonstrated at connectathon and radiology conferences, and all indicate a desire to maintain IHE and XDS-I compliance as the standard evolves. The use of XDS-I for image and report sharing is supported by the Royal College of Radiologists [9], and there is an ideal opportunity for the NHS to benefit from this standard and the technology that flows from it.

Requesting and results reporting

Requesting and results reporting is now more widely referred to using the American terminology “order-comms”. This is not new technology, but represents another aspect of NPfIT that has not yet flourished. Some radiology requesting is available in the CRS, but third-party systems are currently the only option for fully fledged order-comms that include both primary and secondary care requesting with decision support and management of results acknowledgment. Such third-party systems are being procured in many places. Because CfH has developed the Choose and Book (C&B) system for hospital appointments, there is pressure on trusts to use this application for radiology requesting and appointing. Unfortunately, at present there is no interoperability between C&B and RIS, which is necessary for the safe and legal electronic processing of radiology requests. C&B was designed to work with CRS rather than RIS, but even with CRS there is limited electronic functionality, with many users resorting to an intermediate paper-based step. Interfacing with the RIS is essential for proper vetting of requests with access to previous imaging, as is required by the Ionising Radiation (Medical Examinations) Regulations (IR(ME)R) [10]. This is an area for future development, but I have seen little evidence of progress in this direction. If left much longer, most trusts will have separate order-comms systems in situ, perhaps rendering C&B unnecessary for radiology. If the use of C&B is mandated, it may be easier to interface this application with the order-comms systems rather than directly to RIS.

Of course, the original vision was for an all-encompassing CRS that would include within it the RIS (and other “subsystem”) functionality. This would have given the benefits including cross-enterprise scheduling and resource management, which would greatly enhance and integrate requesting and scheduling. A further benefit of order-comms systems is their ability to receive acknowledgments confirming that a report has been viewed, and by whom. This facilitates compliance with a recent directive of the National Patient Safety Agency (NPSA) [11], though unfortunately it does not fulfil the requirement to confirm that appropriate action has been taken, only that the report has been opened for reading.

After radiology – what next for PACS?

Well, the many possibilities include cardiology, ophthalmology, pathology, medical imaging, dermatology, trauma and endoscopy.

Throughout this article I have used “DICOM” as a word, as we all do in the world of radiology. It must not be forgotten that it is an abbreviation of Digital Imaging and Communications in Medicine. Note that this term includes an “M” for medicine, not an “R” for radiology, and that the general term “imaging” is used. This includes visible light imaging (digital photography), as well as infrared imaging, and any emerging medical imaging modalities entering mainstream usage. I would expect cardiology to be easy to integrate with PACSs, as cardiological imaging uses the same modalities as radiology. It may be that specialised cardiology information systems (CISs) are used to manage the data, rather than adding cardiology codes to RIS. However, RIS remains an option and would be sensible in trusts where cardiology is performed by both radiologists and cardiologists. Visible light images are generally acquired in formats such as that specified by the Joint Photographics Expert Group (JPEG), but the DICOM standard includes modules for visible light imaging (still and video) that package standard file types within a DICOM “wrapper”. Thus wrapped, the PACS deals with them as it would any other DICOM file. Software is readily available to make this conversion, and we can expect future developments to include the imaging output from many specialties to be stored in PACs. Capacity and bandwidth limitations will need to be overcome, but a future radiologist may well sit down to report the current CT virtual colonoscopy on one monitor with the relevant previous study, a conventional colonoscopy, open for comparison on another.

However, if different information systems are used for different specialties this level of integration may not be so easy to achieve and the whole “imaging record” of the patient may not be accessible at one time. I think this would be regrettable and, although speciality-specific information systems will probably prevail owing to the differing requirements of different specialties, we should be looking at ways to present a coherent record of all of a patient's images in one place. From the clinical user's perspective, the logical system to co-ordinate this would eventually be the CRS. For the reporting clinician, this will be the RIS or other speciality workstation. To facilitate reporting with cross-specialty comparison, further development of the default display protocols (DDPs, also known as “hanging protocols”) will be required. They will need to recognise the originating specialty of the various image types and, more importantly, when cross-speciality co-operative work is relevant (as in the colonoscopy scenario), and when it is not, to avoid the reporter being bombarded with irrelevant prior images, such as a retinal photograph, when reporting a chest radiograph.

Conclusion

In defiance of the title given to me, I do not think we are yet in a post-PACS environment. PACS has much more to offer both radiology and, especially, other medical disciplines. This increased utility will require the continuing development of PACS itself and of associated applications such as RIS, CRS and other speciality systems. There is a risk, particularly in these times of financial constraint, that the budget-setters will gain the impression that PACS is “done and dusted”, and cut the budget accordingly. This would be most regrettable and would deprive patients of the benefits PACS is yet to bring in support of their care.