1. DICOM General Purpose Worklist The next major political battle in PACS Dr David Harvey

2. Why a DICOM Talk today ? DICOM General Purpose worklist is to reporting workstations what basic DICOM is to a CT Scanner You wouldn’t (I hope!) since 1995 buy a CT without checking the DICOM conformance You shouldn’t buy a reporting station (or PACS) in 2004 without doing the same

3. “Traditional” DICOM Queries Concerned with “static” data, which once generated is never altered. Images RT plans etc. Provides excellent methods for creating, storing, querying and retrieving such data, if your starting point is a particular patient or study

4. Why original DICOM Queries are not suitable for workstations No information or reporting status (unreported / reported / in progress) No way of querying for “things to do” If patient IDs etc. are entered by hand, then there is a delay while images are actually retrieved. Radiologists need a “NEXT” button

5. Key Features of GP Worklist Provides: A vendor independent method of interfacing efficient reporting stations to a PACS A mechanism to simulate the “reporting pile” (but in multiple places simultaneously) A Locking mechanism to prevent accidental double reporting Wide range of query and priority fields to support chosen working practices. Sufficient information to allow images to be pre-fetched.

6. Why Have a DICOM Interface? Is the best RIS/PACS supplier also the best workstation supplier? Is the best workstation supplier also the best RIS/PACS supplier Or do you compromise?

7. Hot it works (the technical bit) Modelled on the existing modality worklist (MWL) and modality performed procedure step (MPPS) services Workstation first queries for items of a requested type Then it selects and locks an item Then marks it compeleted

8. MWL/MPPS Overall Data Flow MWL/MPPS SCU (Client) MWL/MPPS SCP (Server) Query for Examinations List of those available Lock (In Progress) Lock OK OK Mark Complete Query for Work Items GP Worklist GPWL

9. Worklist Data Source Exactly the same options as used by proprietary systems: RIS PACS Broker

10. Vendors have no technical excuses Data sources already exist (used for their proprietary systems) DICOM mechanisms already exist (used for MWL/MPPS) So where is it ?

11. Can I use it Now? At present, NO – because: It has only been in DICOM for 3 years (short time by development scales) Like all such protocols, it requires support from both SCP (server/PACS) and SCU (client/workstation) PACS suppliers don’t like it’s potential to eat into the very lucrative proprietary workstation market Only a few independent workstations support it yet Users haven’t yet learnt about it and demanded it!

12. Will it become available? Perhaps ? Negative Features Not all DICOM features become adopted widely Arguments from major PACS vendors: Responsibility, Reliability etc. User ignorance May become an expensive retrofit option Positive Features Adoption into IHE will push implementation by vendors Some smaller vendors are already using it Like original DICOM, a few knowledgeable users may be sufficient to push the market

13. But won’t the national Program make this obsolete? Life of your RIS ~7-10 yrs Life of Government Initiatives ~2-4 yrs Trusts 4ys (then merged) Information for Health – 3 yrs NPfIT – 3 yrs ? You will still be using your system long after the LSP has lost interest or gone bankrupt!

14. Conclusions In 1994, you could buy a CT scanner which worked well with it’s own expensive secondary console, but if you wanted flexibility and choice for the future, you needed to insist on DICOM C-STORE In 2004, you can buy a PACS which works well with it’s own expensive tied reporting stations, but if you want flexibility and choice in the future, you need to insist on DICOM General Purpose Worklist If not there yet (insist on a firm, dated commitment, with guaranteed interconnection)

15. References DICOM Standard Home Page http://www.dclunie.com/dicom-status/status.html DICOM Newsgroup news:comp.protocols.dicom My E-mail (Dave Harvey) mailto:dave@medicalconnections.co.uk