Scatola nera testare un server DICOM Q/R remoto

Question

Mi chiedo se qualcuno abbia mai provato a lavorare al seguente problema. Devo eseguire una serie di test su un server DICOM Q/R remoto. Ciò consentirebbe un semplice controllo della dichiarazione di conformità DICOM.

Come un dettaglio di implementazione della suite di test, io sono in esecuzione il seguente (comando stile DCMTK):

$ findscu --study --cancel 1 --key 0020,0010=* --key 8,52=STUDY --aetitle MINE --call THEIR dicom.example.com 11112 

L'obiettivo qui è quello di trovare una valida StudyID (in seguito userò che StudyID per eseguire C-FIND di livello inferiore e alcune query C-MOVE correlate). Naturalmente sarebbe molto più facile se potessi caricare il mio set di dati e provare a recuperarlo, ma non posso farlo contro un PACS in esecuzione in un ambiente clinico. Devo definire con un numero minimo di query come trovare un ID studio valido.

Tuttavia temo che qualche applicazione DICOM può avere policies dove quering il database intera è vietata.

Quindi mi chiedevo se qualcuno ha scritto un elenco di quelli policies e forse descrive un modo per recuperare uno StudyID valido da un server remoto con un numero minimo di query C-FIND.

Answer 1

Credo di poter semplicemente andare con:

TODAY=`date +"%Y%m%d"` 
findscu --study --key 0008,0020="$TODAY-" --key 0020,0010=* --key 8,52=STUDY --aetitle MINE --call THEIR dicom.example.com 11112 

Se questo non funziona (tornare vuoto), vado a controllare yesterday risultati.

Answer 2

Benvenuti in DICOM-paese delle meraviglie.

Hai ragione che dovresti essere molto, molto, molto, molto attento a eseguire query a caso su un PACS clinico. Ho visto i PAC commerciali inviare il loro intero (!) Database come risultato di una query che non capiva. Non è una bella vista. Questo (e privacy) è uno dei motivi per cui in molti ospedali in tutto il mondo gli amministratori PACS hanno molta paura di dare accesso diretto ai loro PACS tramite DICOM.

In generale, direi che la standardizzazione non ti aiuterà. Quindi devi trovare qualcosa che funzioni per te, e che non porterà il PACS verso il basso. Nessuna garanzia qui.

Solo un elenco di osservazioni da PACSes interrogazione negli ospedali:

• Alcuni sono case sensitive nella loro corrispondenza, alcuni non lo sono.
• La maggior parte supporta una specie di jolly. Questo normalmente è un '*'. ma ho anche visto '%' (dato che è un carattere jolly SQL e la query è appena passata come stringa SQL). Questo non è ben definito, penso.
• L'elenco che si otterrà potrebbe essere limitato a pronunciare le prime 500 voci. O 1000. O numero casuale compreso tra 500 e 1000. O l'intero PACS. Non lo sai.
• DICOM e cancellazione non funzionano bene. L'annullamento di una query non è implementato correttamente. Normalmente un PACS lo vede come un trasferimento fallito e riproverà dopo un po 'di tempo. E la coda dei tentativi è di dimensioni limitate, quindi potrebbe ignorare nuove query. Quindi, fai sempre funzionare il tuo server STORE-SCP per drenare questa coda.
• A volte le query richiedono minuti, soprattutto per il recupero. La prossima volta potrebbe essere stato recuperato (dal nastro?) Ed essere veloce per un po '.
• Una query DICOM può richiedere molte risorse dal PACS, a seconda del PACS. Non essere sorpreso se si presenta un amministratore PACS se si sperimenta un po 'troppo.
• Le query supportate sono molto diverse. Solo le query di base sono supportate da tutti: elenco di pazienti, elenco di studyID/studio instanceuid per i pazienti, elenco di serie per studio, recupero studio o serie. A meno che non si ottenga un reparto di ricerca funky che utilizza Osirix, che non supporta le query a livello di paziente ma solo le query a livello di studio.

Quindi quello che vi consiglio se si vuole avere qualcosa di lavorare su qualsiasi PACS casuale:

• Usa empty-ritorno-chiave invece di '*'. Questo è il modo DICOM per recuperare le informazioni.
• Non utilizzare '-cancel'. Se è davvero necessario annullare, basta chiudere la connessione TCP (non supportata in DCMTK)
• Utilizzare una query su PatientId, PatientName, Birthdate, StudyDate per ottenere un elenco di StudyIDs/StudyInstanceUids.

Il più semplice è semplicemente utilizzare un StudyID fisso, supponendo che rimanga nel PACS abbastanza a lungo. In caso contrario, pensate a una query limitante per non sovraccaricare il PACS (il suggerimento "OGGI" di voi ha adattato quella descrizione).

Buona fortuna!