Creation et récupération des fichiers dicom ne marchent plus

[Mockinbird]

Bonjour,
J'utilise Medshake avec le module ostéo et depuis peu j'ai un problème pour récupérer les images faites avec phone capture alors que jusque là tout fonctionnait bien.
Le problème :
lorsque dans un dossier patient je clique sur l’icône permettant d'afficher toutes les images d'une études DICOM, le log d'apache me renvoi cette erreur :

Code : Tout sélectionner

E: SOP Class UID does not match one of the known SR document classes
F: dsr2xml: error (Unknown Document Type) parsing file: /home/ehr/public_html//workingDirectory/3/c7b16735-ffb3d7ff-6ea6e700-34c72d0f-48eb0699.dcm

La SOP class UID de ce fichier dcm est 1.2.840.10008.5.1.4.1.1.7 (Secondary Capture Image Storage).
Or selon la doc de dsr2xml (https://manpages.ubuntu.com/manpages/bi ... xml.1.html) ce SOPClassUID n'est pas accepté. D'où l"rreur donc. Ce que je ne comprends pas c'est pourquoi jusque là ça passait.

Autre erreur, cette fois au moment de l'envoi de la photo prise par phonecapture :

Code : Tout sélectionner

W: DcmFileFormat: Value of SOPClassUID in MetaHeader and Dataset is different
W: DcmFileFormat: Value of SOPInstanceUID in MetaHeader and Dataset is different
E: Store Failed, file: /home/ehr/public_html/workingDirectory/3/dicomInstanceDCM.dcm:
E: 0006:0317 Peer aborted Association (or never connected)

Si j'ai bien compris, les en-têtes du fichier dcm final sont pré-remplies par le fichier dicomCreateDCM.html.twig auquel sont ajoutés le StudyInstanceUID et le SeriesInstanceUID puis passage par dump2dcm pour en faire un fichier dcm puis injection du jpeg via img2dcm.
Il apparait effectivement dans dicomCreateDCM que les MediaStorageSOPClassUID et SOPClassUID diffèrent, tout comme les MediaStorageSOPInstanceUID et SOP Instance UID :

Code : Tout sélectionner

== HEADER ==
(0002,0002) UI [1.2.276.0.7230010.3.0.0.9]                                      #  26, 1 MediaStorageSOPClassUID
(0002,0003) UI [1.2.276.0.7230010.3.0.0.9.11154.1448031138.805061]              #  58, 1 MediaStorageSOPInstanceUID
== DATASET ==
(0008,0016) UI [1.2.840.10008.5.1.4.1.1.77.1.4] #SOPClassUID
(0008,0018) UI [1.2.276.0.7230010.3.0.0.9.11154.1448031138.{{ "now"|date("Ymd") }}.{{ "now"|date("His") }}] #SOPInstanceUID

Or il semblerait, selon la section C.12.1.1.1 du standard dicom que les SOPClassUID et les SOPInstanceUID doivent être identiques entre eux.
Mais encore une fois, pourquoi ce problème n’apparaît que maintenant alors qu'avant tout fonctionnait bien.

Ce qui m'étonne toutefois c'est que ces SOPClass et ces SOPInstance sont, dans les fichiers dcm "finaux" déjà créés, identiques entre elles. Peut-être est-ce un mécanisme de sécurité de dump2dcm que de les faire correspondre au cas où ?
En tout cas je n'ai rien trouvé dans la config d'Orthanc qui permette une "mutation" des SOPClass et SOPInstance en cas de différence.

Quelqu'un y voit-il un peu plus clair que moi ?
Merci

[Bertrand]

Salut,

Désolé, je ne suis pas en situation de cheker rapidement ce problème ces heures-ci.
Je pense que tu as trouvé la solution, en tout cas, tu as bien analysé le parcours de création que j'ai en tête sur l'envoi vers le serveur dicom.
Il faut donc bidouiller le dicomCreateDCM.html.twig pour qu'il passe, rien de sorcier c'est du texte, et voir si ensuite ça roule.

Enfin ça c'est pour la création. Si je comprends bien, en sortie de serveur DICOM ca beurre aussi ?

Je relis tout ça dès que possible.

B.

[marsante]

Salut,

Je n'utilise pas dicom, mais pour expliquer un changement brutal de comportement, y'a-t-il eu une montée en version d'Ubuntu / Debian qui modifierait la version de PHP ou d'Orthanc par exemple ?

[Mockinbird]

Bonjour,

Merci pour vos réponses.
Je n'ai pas l'impression qu'il y ait eu de mise à jour (pas de changement de version d'ubuntu, pas trace de màj de dcmtk dans mes logs apt, pas de modif de config d'orthanc) mais je ne peux m'intéresser au problème que part intermittence en ce moment.
Je vous tiens au courant si j'ai du neuf