GPWL Explained

Owned by DamienD
Last updated: Sept 01, 2006Version comment

The following is from Imaging Management Volume 6, Issue 3 (June-July 2006).  The article was written by Dr. David Harvey, and is titled PACS and Radiology Reporting Workstations - GPWL Vital to Maximise Buyer Choice.  It provides some insight to the DICOM General Purpose Worklist functionality.  dcm4che2 provides a GPWL SCU utility, and dcm4chee provides GPWL as an SCP.

Why Requirements Differ for Reporting Workstations

To understand why this barrier exists for reporting workstations, but not for clinical workstations, consider the user's starting point. On a clinical workstation, the starting point is a particular patient, making standard DICOM query/retrieve ideal, quickly providing a list of studies for that patient and access to those images without worrying about whether or not they have been reported. The short delay due to image selection and retrieval is unlikely to be significant in the context of a clinical encounter or complex image manipulation.  A radiologist however does not start by looking for a particular patient, and instead needs the digital equivalent of a "pile of film packets", so the system must provide a list of examinations which are:

  • Complete and ready for reporting
  • Not already reported
  • Not in the process of being reported by another radiologist
  • To be reported by the current user, either specifically or as part of a group

None of this information is made available by standard DICOM query/retrieve mechanisms, so a more appropriate "reporting worklist" is required, which in practice is also expected to provide filtering by urgency, modality, referral source, etc. The delays and user intervention described above, though reasonable for a clinical workstation, would not be tolerable for a high-throughput radiological reporting workstation, where the radiologist must be able to progress to the next examination immediately with one click, gesture or voice command.

Put simply, radiologists quite reasonably expect to have a "next" button, requiring studies to have been pre-loaded into the workstation for immediate display. These requirements have been present since the earliest days of PACS, and all respectable vendors provide this sort of functionality.  The problem is that virtually all of them are using proprietary mechanisms which are only usable if the PACS and the reporting station are provided by the same vendor, thereby providing a "lock-in" and denying users free choice. This approach was reasonable until 2001, as there were then no standardised alternatives.

Using GPWL Interfaces to Facilitate Buyer Choice

The proper DICOM solution, published in 2001, is not well known by users, perhaps due to its rather misleading and uninspiring name "General Purpose Worklist Management" or the acronym GPWL. This service provides all the interfaces needed to support the provision of images and associated data to a reporting workstation, and most importantly, does so in a vendor-independent manner, such that provision of this facility in a PACS and workstation would enable them to work properly together even if from different suppliers. The features provided by GPWL, as shown in the figure, are:

  • A means to query for reporting which needs to be done, including filtering by user, modality and date, as well as reporting status. As a list of studies is provided, this can be used by the workstation to "pre-fetch" the actual images
  • A "locking mechanism" to ensure that the same work is not done by two users simultaneously
  • A means to communicate to the server that the report has been completed

These operations are similar to those used for sending scheduling and update information to and from imaging equipment, as defined by the commonly used DICOM Modality Worklist (MWL) and Modality Performed Procedure Step (MPPS) services. This similarity is quite deliberate, and in fact the underlying DICOM mechanisms are almost identical, the only significant addition being the locking mechanism. Like most useful DICOM services, GPWL has an equivalent profile in Integrating the Healthcare Enterprise (IHE), and in this case the profile is called "Reporting Workflow (RWF)", which is basically an IHE "wrapper" around GPWL, with additional useful specifications about how the report itself should be transferred and stored.


 
The similarity to MWL and MPPS means that it is technically easy for vendors to introduce this new service in both servers and workstations, but a server implementation requires access to information from both the PACS and the RIS, raising the question of whether the "server" for this service should be the PACS, the RIS or even a broker. This is a local implementation issue, but fortunately does not affect the overall practicality of the service, as vendors already have the required level of data integration for their proprietary alternatives.

Getting Best of Breed Solutions

So why is this service, which has been specified for five years not more widely available? Clearly, it would always be in a buyer's interest to maintain flexibility for future purchases, in order to be able to buy a "best of breed" solution, rather than what happens to be on offer from a particular PACS supplier - after all, it is unlikely that the best provider of storage solutions will also happen to supply the best reporting workstations.  This is quite apart from the fact that a vendor with a captive market can always charge more than the open market competitive price, so the mere prospect of choice is useful to a buyer. A genuinely open market would also force vendors to adopt more customer friendly policies concerning such matters as Internet access from workstations, which is not allowed by some vendors. At present however, there are few if any compliant systems, and a user who tried to insist on having GPWL functionality in their PACS would have virtually no systems to choose from, so what is the best course of action?

Taking Advantage of GPWL

While a PACS buyer should accept a proprietary solution for workstation integration initially, they should obtain a contractual commitment, enforced by a significant retention, that GPWL server functionality will be included within two years.  Given that this requirement was part of the English national PACS procurement (Connecting for Health), for which most of the major PACS providers submitted tenders, they should be able to deliver this if pushed hard enough. Such an approach will avoid the complexities of a multi-vendor initial installation, but enable the buyer to avoid the otherwise inevitable lock-in.  Put another way, this whole situation is analogous to the position of basic DICOM services in the mid-nineties:

  • In 1994, you could buy a CT scanner which worked well with its own expensive secondary console, but if you wanted flexibility and choice for the future, you needed to insist on DICOM C-STORE
  • In 2006, you can buy a PACS which works well with its own expensive tied reporting stations, but if you want flexibility and choice in the future, you need to insist on DICOM General Purpose Worklist.