C-FIND Performance Issues

Multiple Patient IDs

• PACS increasingly have records transferred between facilities (IHE and otherwise)

• Transferred patient records have different Patient IDs (issued by the original facility) in many cases.

• Typical real patient queries now often require 3-10 distinct separate patient level queries.

• MPI, IHE PIX/PDQ, etc deal with obtaining the list of patient IDs related to the real world patient.

• PACS query overhead is a problem.

Multi-ID Overhead

• Two sources of overhead penalties– Failure to implement multiple asynchronous

requests for C-FIND.• Cannot overlap queries

• Do not overlap/stream C-FIND responses

– Less efficient query processing• Most index systems can handle a query for a short

list of IDs faster than a list of individual queries.

Multi-ID magnitude

• There is a 2-3 fold increase in query volume compared with Y2k, due to rapidly increasing sharing of patient data.

• There are now thousands of workstations issuing queries to the PACS archive.

Large Query Responses

• For a large series (e.g., spiral CT), MWL, etc. there are often very large responses. These have problems:– (Small) each response must be in a separate P-DATA

response. This incurs P-DATA and PDV overhead. – (Large) the responses cannot be compressed. For a

spiral CT with 1,000 slices and a query with a significant list of return keys, this is a lot of data. It would compress very well with GZIP.

– (Variable) The many individual P-DATA transfers often interact very badly with high latency TCP links.

Compression Fix

• Simply adding G-ZIP on a per P-DATA basis does not provide much improvement.

• Adding G-ZIP compression on a stream basis introduces problems for cancellation, but achieves very high compression for highly redundant responses like those for a spiral CT.

• Sample implementation:– Collect P-DATA responses, compress them, and send.

The last few bytes will not be sent until the next P-DATA. The last few bytes of the last response will not be sent until the P-DATA for complete.

Query volume increases

• Number of active workstations has increased, and now reaches thousands per PACS archive.

• Number of SOP instances has increased from hundreds per patient to many thousands per patient. – Multi-frame new objects will help slow the growth as

old CT/MR/… are replaced.

– New kinds of objects for new imaging purposes continues to increase the objects per query response.

Large queries

• This is similar to the “no pixel data” transfer syntax, but only sends the implemented return keys.

• The current system for C-FIND requires the SCU to list every possible interesting index attribute. This list can be very large.

• A much smaller query would be for “all implemented return keys”.

• The major performance advantage is that this does not require any access to the bulk data storage. It only needs to access the database keys.

Large Query volume

• As MWL, Hanging Protocol, and other query intensive SOPs gain use, this volume is increasing.

• The query based data retrieval for any SOP with extensible return keys results in large queries and configuration work to include the complete list of potential return keys in every query.

Multi-valued queries

• Increasingly queries involve matching a list of attribute values. Patient ID is just one example. Another is a search for matching “foot”, “ankle”, or “toe” in a search. Another is a MWL query for machine rooms A, B, and C.

• Present C-FIND requires multiple independent queries.

• Cross-product explosion occurs when there are several multi-valued attribute queries.– DBMS systems are designed to handle problems like this.

– The only current DICOM option is to ship all the candidate object indices to the SCU and have the SCU manage the cross product.

Multi-valued Queries

• The network DBMS standards do not provide a good solution.– Network SQL cross vendor interoperability is poor.– Network SQL cross application interoperability is poor.– XSLT, XPATH, and related technologies are being used,

but again with poor cross application interoperability.

• It may be beyond the state of the art to reach a general solution, but some modest extensions to add limited range/ list to DICOM query might reduce the query volume sufficiently.