C-FIND Performance Issues

1
C-FIND Performance Issues
2
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.

3
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.

4
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.

5
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.

6
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.

7
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.

8
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.

9
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.

10
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.

11
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.