Instruction de conformité DICOM v1

  • Article

Remarque

L’API version 2 est la dernière version de l’API et doit être utilisée à la place de v1. Pour plus d’informations, consultez l’instruction de conformité DICOM v2 .

Le serveur d’imagerie médicale pour DICOM® prend en charge un sous-ensemble de DICOMweb Standard. La prise en charge inclut les éléments suivants :

En outre, les API non standard suivantes sont prises en charge :

Le service utilise le contrôle de version de l’API REST. La version de l’API REST doit être spécifiée explicitement dans le cadre de l’URL de base, comme dans l’exemple suivant :

https://<service_url>/v<version>/studies

Cette version de l’instruction de conformité correspond à la v1 version des API REST.

Pour plus d’informations sur la façon de spécifier la version lors d’une demande, consultez la documentation relative au contrôle de version des API.

Vous trouverez des exemples de requêtes pour les transactions prises en charge dans la collection Postman.

Nettoyage du préambule

Le service ignore le préambule du fichier de 128 octets et remplace son contenu par des caractères null. Ce comportement garantit qu’aucun fichier transmis par le service n’est vulnérable à la vulnérabilité de préambule malveillante. Toutefois, cette assainissement du préambule signifie également que les préambules utilisés pour encoder du contenu au double format, tels que TIFF, ne peuvent pas être utilisés avec le service.

Service d’études

Le service Studies permet aux utilisateurs de stocker, récupérer et rechercher des études DICOM, des séries et des instances. Nous avons ajouté la transaction de suppression non standard pour activer un cycle de vie de ressources complet.

Store (STOW-RS)

Cette transaction utilise la méthode POST ou PUT pour stocker des représentations d’études, de séries et d’instances contenues dans la charge utile de la requête.

Méthode Path Description
POST .. /Études Stocker des instances.
POST .. /studies/{study} Stocker des instances pour une étude spécifique.
PUT .. /Études Instances Upsert.
PUT .. /studies/{study} Instances Upsert pour une étude spécifique.

Le paramètre study correspond à l’attribut DICOM StudyInstanceUID. Si elle est spécifiée, toute instance qui n’appartient pas à l’étude fournie est rejetée avec un 43265 code d’avertissement.

Les en-têtes suivants Accept pour la réponse sont pris en charge :

  • application/dicom+json

Les en-têtes suivants Content-Type sont pris en charge :

  • multipart/related; type="application/dicom"
  • application/dicom

Remarque

Le serveur ne force pas ou ne remplace pas les attributs qui entrent en conflit avec les données existantes pour les requêtes POST. Toutes les données sont stockées comme indiqué. Pour les demandes upsert (PUT), les données existantes sont remplacées par les nouvelles données reçues.

Stocker les attributs requis

Les éléments DICOM suivants doivent être présents dans chaque fichier DICOM qui tente d’être stocké :

  • StudyInstanceUID
  • SeriesInstanceUID
  • SOPInstanceUID
  • SOPClassUID
  • PatientID

Remarque

Tous les UID doivent être compris entre 1 et 64 caractères, et contiennent uniquement des caractères numériques alpha ou les caractères spéciaux suivants : ., -. PatientID est validé en fonction de son LOVR type.

Chaque fichier stocké doit avoir une combinaison unique de StudyInstanceUID, SeriesInstanceUIDet SopInstanceUID. Le code 45070 d’avertissement est retourné si un fichier contenant les mêmes identificateurs existe déjà.

Seules les syntaxes de transfert avec des représentations de valeur explicites sont acceptées.

Codes d’état de réponse du magasin

Code Description
200 (OK) Toutes les instances SOP de la requête sont stockées.
202 (Accepted) Certaines instances de la requête sont stockées, mais d’autres ont échoué.
204 (No Content) Aucun contenu n’a été fourni dans la demande de transaction de magasin.
400 (Bad Request) La demande a été mal mise en forme. Par exemple, l’identificateur d’instance d’étude fourni n’est pas conforme au format UID attendu.
401 (Unauthorized) Le client n’est pas authentifié.
403 (Forbidden) L’utilisateur n’est pas autorisé.
406 (Not Acceptable) L’en-tête spécifié Accept n’est pas pris en charge.
409 (Conflict) Aucune des instances de la demande de transaction de magasin n’a été stockée.
415 (Unsupported Media Type) L’élément fourni Content-Type n’est pas pris en charge.
503 (Service Unavailable) Le service n’est pas disponible ou occupé. Réessayez plus tard.

Charge utile de réponse du magasin

La charge utile de réponse remplit un jeu de données DICOM avec les éléments suivants :

Tag Nom Description
(0008, 1190) RetrieveURL URL de récupération de l’étude si l’StudyInstanceUID a été fourni dans la demande de magasin et qu’au moins une instance est correctement stockée.
(0008, 1198) FailedSOPSequence Séquence d’instances qui n’ont pas pu être conservées.
(0008, 1199) ReferencedSOPSequence Séquence d’instances stockées.

Chaque jeu de données dans le fichier FailedSOPSequence DICOM contient les éléments suivants (si le fichier DICOM qui tente d’être stocké peut être lu) :

Tag Nom Description
(0008, 1150) ReferencedSOPClassUID Identificateur unique de la classe SOP de l’instance qui n’a pas pu stocker.
(0008, 1155) ReferencedSOPInstanceUID Identificateur unique de l’instance SOP de l’instance qui n’a pas pu stocker.
(0008, 1197) FailureReason Code de raison pour laquelle cette instance n’a pas pu stocker.
(0074, 1048) FailedAttributesSequence Séquence de ErrorComment ce qui inclut la raison de chaque attribut ayant échoué.

Chaque jeu de données du jeu ReferencedSOPSequence de données contient les éléments suivants :

Tag Nom Description
(0008, 1150) ReferencedSOPClassUID Identificateur unique de la classe SOP de l’instance qui n’a pas pu stocker.
(0008, 1155) ReferencedSOPInstanceUID Identificateur unique de l’instance SOP de l’instance qui n’a pas pu stocker.
(0008, 1190) RetrieveURL URL de récupération de cette instance sur le serveur DICOM.

Exemple de réponse avec Accept en-tête application/dicom+json:

{
  "00081190":
  {
    "vr":"UR",
    "Value":["http://localhost/studies/d09e8215-e1e1-4c7a-8496-b4f6641ed232"]
  },
  "00081198":
  {
    "vr":"SQ",
    "Value":
    [{
      "00081150":
      {
        "vr":"UI","Value":["cd70f89a-05bc-4dab-b6b8-1f3d2fcafeec"]
      },
      "00081155":
      {
        "vr":"UI",
        "Value":["22c35d16-11ce-43fa-8f86-90ceed6cf4e7"]
      },
      "00081197":
      {
        "vr":"US",
        "Value":[43265]
      }
    }]
  },
  "00081199":
  {
    "vr":"SQ",
    "Value":
    [{
      "00081150":
      {
        "vr":"UI",
        "Value":["d246deb5-18c8-4336-a591-aeb6f8596664"]
      },
      "00081155":
      {
        "vr":"UI",
        "Value":["4a858cbb-a71f-4c01-b9b5-85f88b031365"]
      },
      "00081190":
      {
        "vr":"UR",
        "Value":["http://localhost/studies/d09e8215-e1e1-4c7a-8496-b4f6641ed232/series/8c4915f5-cc54-4e50-aa1f-9b06f6e58485/instances/4a858cbb-a71f-4c01-b9b5-85f88b031365"]
      }
    }]
  }
}

Codes de raison de l’échec du magasin

Code Description
272 La transaction de magasin n’a pas stocker l’instance en raison d’un échec général lors du traitement de l’opération.
43264 L’instance DICOM a échoué la validation.
43265 L’instance StudyInstanceUID fournie ne correspond pas à celle spécifiée StudyInstanceUID dans la demande de magasin.
45070 Une instance DICOM avec le même StudyInstanceUIDobjet , SeriesInstanceUIDet SopInstanceUID qui est déjà stockée. Si vous souhaitez mettre à jour le contenu, supprimez d’abord cette instance.
45071 Une instance DICOM est créée par un autre processus, ou la tentative précédente de création a échoué et le processus de propre up n’est pas terminé. Supprimez d’abord l’instance avant de tenter de créer à nouveau.

Stocker les codes de raison de l’avertissement

Code Description
45063 Un jeu de données d’instance DICOM ne correspond pas à la classe SOP. La transaction du magasin d’études (section 10.5) a observé que le jeu de données ne correspondait pas aux contraintes de la classe SOP pendant le stockage de l’instance.

Codes d’erreur du magasin

Code Description
100 Les attributs d’instance fournis ne répondent pas aux critères de validation.

Retrieve (WADO-RS)

Cette transaction de récupération offre la prise en charge de la récupération d’études stockées, de séries, d’instances et de trames par référence.

Méthode Path Description
GET .. /studies/{study} Récupère toutes les instances d’une étude.
GET .. /studies/{study}/metadata Récupère les métadonnées de toutes les instances d’une étude.
GET .. /studies/{study}/series/{series} Récupère toutes les instances d’une série.
GET .. /studies/{study}/series/{series}/metadata Récupère les métadonnées de toutes les instances d’une série.
GET .. /studies/{study}/series/{series}/instances/{instance} Récupère une seule instance.
GET .. /studies/{study}/series/{series}/instances/{instance}/metadata Récupère les métadonnées d’une instance unique.
GET .. /studies/{study}/series/{series}/instances/{instance}/rendu Récupère une instance rendue dans un format d’image
GET .. /studies/{study}/series/{series}/instances/{instance}/frames/{frames} Récupère une ou plusieurs images à partir d’une seule instance. Pour spécifier plusieurs images, utilisez une virgule pour séparer chaque image à retourner. Par exemple : /studies/1/series/2/instance/3/frames/4,5,6.
GET .. /studies/{study}/series/{series}/instances/{instance}/frames/{frame}/rendu Récupère un cadre unique rendu dans un format d’image.

Récupérer des instances au sein d’une étude ou d’une série

Les en-têtes suivants Accept sont pris en charge pour récupérer des instances au sein d’une étude ou d’une série :

  • multipart/related; type="application/dicom"; transfer-syntax=*
  • multipart/related; type="application/dicom"; (lorsque la syntaxe de transfert n’est pas spécifiée, la version 1.2.840.10008.1.2.1 est utilisée comme valeur par défaut)
  • multipart/related; type="application/dicom"; transfer-syntax=1.2.840.10008.1.2.1
  • multipart/related; type="application/dicom"; transfer-syntax=1.2.840.10008.1.2.4.90
  • */* (lorsque la syntaxe de transfert n’est pas spécifiée, * est utilisée comme valeur par défaut et mediaType par défaut sur application/dicom)

Récupérer une instance

Les en-têtes suivants Accept sont pris en charge pour récupérer une instance spécifique :

  • application/dicom; transfer-syntax=*
  • multipart/related; type="application/dicom"; transfer-syntax=*
  • application/dicom; (lorsque la syntaxe de transfert n’est pas spécifiée, 1.2.840.10008.1.2.1 est utilisée comme valeur par défaut)
  • multipart/related; type="application/dicom" (lorsque la syntaxe de transfert n’est pas spécifiée, 1.2.840.10008.1.2.1 est utilisée comme valeur par défaut)
  • application/dicom; transfer-syntax=1.2.840.10008.1.2.1
  • multipart/related; type="application/dicom"; transfer-syntax=1.2.840.10008.1.2.1
  • application/dicom; transfer-syntax=1.2.840.10008.1.2.4.90
  • multipart/related; type="application/dicom"; transfer-syntax=1.2.840.10008.1.2.4.90
  • */* (lorsque la syntaxe de transfert n’est pas spécifiée, * est utilisée comme valeur par défaut et mediaType par défaut sur application/dicom)

Récupérer des images

Les en-têtes suivants Accept sont pris en charge pour récupérer des images :

  • multipart/related; type="application/octet-stream"; transfer-syntax=*
  • multipart/related; type="application/octet-stream"; (lorsque la syntaxe de transfert n’est pas spécifiée, 1.2.840.10008.1.2.1 est utilisée comme valeur par défaut)
  • multipart/related; type="application/octet-stream"; transfer-syntax=1.2.840.10008.1.2.1
  • multipart/related; type="image/jp2"; (lorsque la syntaxe de transfert n’est pas spécifiée, 1.2.840.10008.1.2.4.90 est utilisée comme valeur par défaut)
  • multipart/related; type="image/jp2";transfer-syntax=1.2.840.10008.1.2.4.90
  • */* (lorsque la syntaxe de transfert n’est pas spécifiée, * est utilisée comme valeur par défaut et mediaType par défaut sur application/octet-stream)

Récupérer la syntaxe de transfert

Lorsque la syntaxe de transfert demandée est différente du fichier d’origine, le fichier d’origine est transcodé en syntaxe de transfert demandée. Le fichier d’origine doit être l’un des formats suivants pour que le transcodage réussisse, sinon le transcodage peut échouer :

  • 1.2.840.10008.1.2 (Little Endian Implicit)
  • 1.2.840.10008.1.2.1 (Little Endian Explicit)
  • 1.2.840.10008.1.2.2 (Explicit VR Big Endian)
  • 1.2.840.10008.1.2.4.50 (processus de référence JPEG 1)
  • 1.2.840.10008.1.2.4.57 (JPEG Lossless)
  • 1.2.840.10008.1.2.4.70 (valeur de sélection sans perte JPEG 1)
  • 1.2.840.10008.1.2.4.90 (JPEG 2000 Sans perte uniquement)
  • 1.2.840.10008.1.2.4.91 (JPEG 2000)
  • 1.2.840.10008.1.2.5 (RLE Lossless)

Un résultat non pris en charge transfer-syntax est .406 Not Acceptable

Récupérer des métadonnées (pour l’étude, la série ou l’instance)

L’en-tête suivant Accept est pris en charge pour récupérer les métadonnées d’une étude, d’une série ou d’une instance :

  • application/dicom+json

La récupération des métadonnées ne retourne pas d’attributs avec les représentations de valeur suivantes :

Nom vr Description
OB Autres octets
OD Autre double
OF Autre float
OL Autre long
OV Autre 64 bits très long
OW Autre mot
UN Inconnu

Récupérer la validation du cache de métadonnées (pour l’étude, la série ou l’instance)

La validation du cache est prise en charge à l’aide du ETag mécanisme. Dans la réponse à une demande de métadonnées, ETag est retourné en tant qu’en-têtes. Cet ETag peut être mis en cache et ajouté en tant qu’en-tête If-None-Match dans les requêtes ultérieures pour les mêmes métadonnées. Deux types de réponses sont possibles si les données existent :

  • Les données sont inchangées depuis la dernière requête : HTTP 304 (Not Modified) la réponse est envoyée sans corps de réponse.
  • Données modifiées depuis la dernière requête : HTTP 200 (OK) la réponse est envoyée avec eTag mis à jour. Les données requises sont également retournées dans le corps.

Récupérer l’image rendue (par exemple ou frame)

Les en-têtes suivants Accept sont pris en charge pour récupérer une image rendue, une instance ou un frame :

  • image/jpeg
  • image/png

Dans le cas où aucun en-tête n’est Accept spécifié, le service affiche un image/jpeg par défaut.

Le service prend uniquement en charge le rendu d’une trame unique. Si le rendu est demandé pour une instance avec plusieurs images, seule la première image est rendue en tant qu’image par défaut.

Lors de la spécification d’une trame particulière à retourner, l’indexation d’images commence à 1.

Le quality paramètre de requête est également pris en charge. Une valeur entière comprise entre 1 et 100 inclusive (1 étant la pire qualité, et 100 étant de meilleure qualité) peut être passée en tant que valeur pour le paramètre de requête. Ce paramètre est utilisé pour les images rendues en tant que jpeg, et est ignoré pour les png demandes de rendu. Si ce paramètre n’est pas spécifié par défaut 100, la valeur est .

Récupérer les codes d’état de réponse

Code Description
200 (OK) Toutes les données demandées ont été récupérées.
304 (Not Modified) Les données demandées n’ont pas été modifiées depuis la dernière requête. Le contenu n’est pas ajouté au corps de la réponse dans ce cas. Pour plus d’informations, consultez la section ci-dessus : Récupérer la validation du cache de métadonnées (pour l’étude, la série ou l’instance).
400 (Bad Request) La demande a été mal mise en forme. Par exemple, l’identificateur d’instance d’étude fourni n’est pas conforme au format UID attendu, ou l’encodage de syntaxe de transfert demandé n’est pas pris en charge.
401 (Unauthorized) Le client n’est pas authentifié.
403 (Forbidden) L’utilisateur n’est pas autorisé.
404 (Not Found) La ressource DICOM spécifiée n’a pas pu être trouvée, ou pour la requête rendue, l’instance ne contenait pas de données de pixels.
406 (Not Acceptable) L’en-tête spécifié Accept n’est pas pris en charge, ou pour les requêtes rendues et transcode les demandes demandées étaient trop volumineuses.
503 (Service Unavailable) Le service n’est pas disponible ou occupé. Réessayez plus tard.

Rechercher (QIDO-RS)

La requête basée sur l’ID des objets DICOM (QIDO) vous permet de rechercher des études, des séries et des instances par attributs.

Méthode Path Description
Rechercher des études
GET .. /Études?... Rechercher des études
Rechercher une série
GET .. /Série?... Rechercher des séries
GET .. /studies/{study}/series?... Rechercher des séries dans une étude
Rechercher des instances
GET .. /Cas?... Rechercher des instances
GET .. /studies/{study}/instances?... Rechercher des instances dans une étude
GET .. /studies/{study}/series/{series}/instances?... Rechercher des instances dans une série

Les en-têtes suivants Accept sont pris en charge pour la recherche :

  • application/dicom+json

Paramètres de recherche pris en charge

Les paramètres suivants pour chaque requête sont pris en charge :

Clé Valeur(s) de support Nombre autorisé Description
{attributeID}= {value} 0...N Recherchez la correspondance d’attribut/valeur dans la requête.
includefield= {attributeID}
all		 0...N Les autres attributs à retourner dans la réponse. Les balises publiques et privées sont toutes deux prises en charge.
Une fois all fourni, reportez-vous à la réponse de recherche pour plus d’informations sur les attributs retournés pour chaque type de requête.
Si un mélange est {attributeID}all fourni, le serveur utilise par défaut all.
limit= {value} 0..1 Valeur entière pour limiter le nombre de valeurs retournées dans la réponse.
La valeur peut être comprise entre la plage 1 >= x <= 200. Valeur par défaut 100.
offset= {value} 0..1 Ignorez les {value} résultats.
Si un décalage est fourni plus grand que le nombre de résultats de la requête de recherche, une réponse 204 (aucun contenu) est retournée.
fuzzymatching= true / false 0..1 Si la correspondance approximative vraie est appliquée à l’attribut PatientName. Il effectue une correspondance de mot de préfixe de n’importe quelle partie de nom dans la valeur PatientName. Par exemple, si PatientName est « John^Doe », « joh », « do », « jo do », « Doe » et « John Doe » correspondent tous. Cependant, « ohn » ne correspond pas.

Attributs pouvant faire l’objet d’une recherche

Nous prenons en charge la recherche dans les attributs et types de recherche suivants.

Mot clé d’attribut Toutes les études Toutes les séries Toutes les instances Série d’études Instances de l’étude Instances de la série d’études
StudyInstanceUID X X X
PatientName X X X
PatientID X X X
PatientBirthDate X X X
AccessionNumber X X X
ReferringPhysicianName X X X
StudyDate X X X
StudyDescription X X X
ModalitiesInStudy X X X
SeriesInstanceUID X X X X
Modality X X X X
PerformedProcedureStepStartDate X X X X
ManufacturerModelName X X X X
SOPInstanceUID X X X

Correspondance de recherche

Nous prenons en charge les types correspondants suivants.

Type de recherche Attribut pris en charge Exemple
Requête de plage StudyDate/PatientBirthDate {attributeID}={value1}-{value2}. Pour les valeurs de date/heure, nous prenons en charge une plage inclusive sur la balise. Cette opération est mappée à attributeID >= {value1} AND attributeID <= {value2}. Si {value1} ce n’est pas spécifié, toutes les occurrences de dates/heures antérieures et comprises {value2} sont mises en correspondance. De même, s’il {value2} n’est pas spécifié, toutes les occurrences des {value1} dates/heures suivantes sont mises en correspondance. Toutefois, l’une de ces valeurs doit être présente. {attributeID}={value1}- et {attributeID}=-{value2} sont valides, cependant, {attributeID}=- n’est pas valide.
Correspondance exacte Tous les attributs pris en charge {attributeID}={value1}
Correspondance approximative PatientName, ReferringPhysicianName Correspond à n’importe quel composant du nom qui commence par la valeur.

ID d’attribut

Les balises peuvent être encodées de plusieurs façons pour le paramètre de requête. Nous avons partiellement implémenté la norme telle que définie dans PS3.18 6.7.1.1.1. Les encodages suivants pour une balise sont pris en charge :

Valeur Exemple
{group}{element} 0020000D
{dicomKeyword} StudyInstanceUID

Exemple de requête de recherche d’instances :

../instances?Modality=CT&00280011=512&includefield=00280010&limit=5&offset=0

Réponse de recherche

La réponse est un tableau de jeux de données DICOM. Selon la ressource, par défaut , les attributs suivants sont retournés :

Balises d’étude par défaut

Tag Nom de l’attribut
(0008, 0005) SpecificCharacterSet
(0008, 0020) StudyDate
(0008, 0030) StudyTime
(0008, 0050) AccessionNumber
(0008, 0056) InstanceAvailability
(0008, 0090) ReferringPhysicianName
(0008, 0201) TimezoneOffsetFromUTC
(0010, 0010) PatientName
(0010, 0020) PatientID
(0010, 0030) PatientBirthDate
(0010, 0040) PatientSex
(0020, 0010) StudyID
(0020, 000D) StudyInstanceUID

Balises de série par défaut

Tag Nom de l’attribut
(0008, 0005) SpecificCharacterSet
(0008, 0060) Modality
(0008, 0201) TimezoneOffsetFromUTC
(0008, 103E) SeriesDescription
(0020, 000E) SeriesInstanceUID
(0040, 0244) PerformedProcedureStepStartDate
(0040, 0245) PerformedProcedureStepStartTime
(0040, 0275) RequestAttributesSequence

Balises d’instance par défaut

Tag Nom de l’attribut
(0008, 0005) SpecificCharacterSet
(0008, 0016) SOPClassUID
(0008, 0018) SOPInstanceUID
(0008, 0056) InstanceAvailability
(0008, 0201) TimezoneOffsetFromUTC
(0020, 0013) InstanceNumber
(0028, 0010) Rows
(0028, 0011) Columns
(0028, 0100) BitsAllocated
(0028, 0008) NumberOfFrames

Si includefield=all, les attributs suivants sont inclus avec les attributs par défaut. Outre les attributs par défaut, il s’agit de la liste complète des attributs pris en charge à chaque niveau de ressource.

Balises d’étude supplémentaires

Tag Nom de l’attribut
(0008, 1030) Study Description
(0008, 0063) AnatomicRegionsInStudyCodeSequence
(0008, 1032) ProcedureCodeSequence
(0008, 1060) NameOfPhysiciansReadingStudy
(0008, 1080) AdmittingDiagnosesDescription
(0008, 1110) ReferencedStudySequence
(0010, 1010) PatientAge
(0010, 1020) PatientSize
(0010, 1030) PatientWeight
(0010, 2180) Occupation
(0010, 21B0) AdditionalPatientHistory

Autres balises de série

Tag Nom de l’attribut
(0020, 0011) SeriesNumber
(0020, 0060) Laterality
(0008, 0021) SeriesDate
(0008, 0031) SeriesTime

Les attributs suivants sont retournés :

  • Tous les paramètres de requête et UID de correspondance dans l’URL de la ressource.
  • IncludeField attributs pris en charge au niveau de cette ressource.
  • Si la ressource cible est All Series, Study les attributs de niveau sont également retournés.
  • Si la ressource cible est All Instances, les Study attributs de niveau sont Series également retournés.
  • Si la ressource cible est Study's Instances, Series les attributs de niveau sont également retournés.
  • NumberOfStudyRelatedInstances l’attribut agrégé est pris en charge au Study niveau includeField.
  • NumberOfSeriesRelatedInstances l’attribut agrégé est pris en charge au Series niveau includeField.

Codes de réponse de recherche

L’API de requête retourne l’un des codes d’état suivants dans la réponse :

Code Description
200 (OK) La charge utile de réponse contient toutes les ressources correspondantes.
204 (No Content) La recherche s’est terminée avec succès, mais aucun résultat n’a été retourné.
400 (Bad Request) Le serveur n’a pas pu effectuer la requête, car le composant de requête n’était pas valide. Le corps de la réponse contient les détails de l’échec.
401 (Unauthorized) Le client n’est pas authentifié.
403 (Forbidden) L’utilisateur n’est pas autorisé.
503 (Service Unavailable) Le service n’est pas disponible ou occupé. Réessayez plus tard.

Autres remarques

  • L’interrogation à l’aide du TimezoneOffsetFromUTC (00080201) fichier n’est pas prise en charge.
  • L’API de requête ne retourne 413 (request entity too large)pas . Si la limite de réponse de requête demandée est en dehors de la plage acceptable, une requête incorrecte est retournée. Tout ce qui est demandé dans la plage acceptable est résolu.
  • Lorsque la ressource cible est Study/Series, il existe un risque de métadonnées de niveau étude/série incohérentes sur plusieurs instances. Par exemple, deux instances peuvent avoir un patientName différent. Dans ce cas, les dernières victoires et vous ne pouvez rechercher que sur les données les plus récentes.
  • Les résultats paginés sont optimisés pour retourner la dernière instance correspondante en premier, ce qui peut entraîner des enregistrements en double dans les pages suivantes si des données plus récentes correspondant à la requête ont été ajoutées.
  • La correspondance est sensible à la casse et sensible aux accents pour les types PN VR.
  • La correspondance est sensible à la casse et sensible aux accents pour les autres types VR de chaîne.
  • Seule la première valeur est indexée d’un élément de données à valeur unique qui a incorrectement plusieurs valeurs.

Supprimer

Cette transaction ne fait pas partie du DICOMwe Standard officiel. Il utilise la méthode DELETE pour supprimer les représentations des études, des séries et des instances du magasin.

Méthode Path Description
DELETE .. /studies/{study} Supprimez toutes les instances d’une étude spécifique.
DELETE .. /studies/{study}/series/{series} Supprimez toutes les instances d’une série spécifique dans une étude.
DELETE .. /studies/{study}/series/{series}/instances/{instance} Supprimez une instance spécifique dans une série.

Paramètres study, serieset instance correspondent aux attributs StudyInstanceUIDDICOM , SeriesInstanceUIDet SopInstanceUID respectivement.

Il n’existe aucune restriction sur l’en-tête, Content-Type l’en-tête ou le contenu du corps de Accept la requête.

Remarque

Après une transaction Delete, les instances supprimées ne sont pas récupérables.

Codes d’état de réponse

Code Description
204 (No Content) Lorsque toutes les instances SOP sont supprimées.
400 (Bad Request) La demande a été mal mise en forme.
401 (Unauthorized) Le client n’est pas authentifié.
403 (Forbidden) L’utilisateur n’est pas autorisé.
404 (Not Found) Lorsque la série spécifiée n’a pas été trouvée dans une étude ou que l’instance spécifiée n’a pas été trouvée dans la série.
503 (Service Unavailable) Le service n’est pas disponible ou occupé. Réessayez plus tard.

Supprimer la charge utile de réponse

Le corps de la réponse est vide. Le code d’état est la seule information utile retournée.

Service de liste de travail (UPS-RS)

Le service DICOM prend en charge les fournisseurs de services Envoyer (push) et Extraire (pull) du Service de liste de travail (UPS-RS). Le service Worklist fournit l’accès à une liste de travail contenant des éléments de travail, chacun représentant une étape de procédure unifiée (UPS).

Tout au long de l’ensemble, la variable {workitem} d’un modèle d’URI correspond à un UID Workitem.

Les points de terminaison UPS-RS disponibles sont les suivants :

Verbe Path Description
POST {s}/workitems{ ? AffectedSOPInstanceUID} Créer un élément de travail
POST {s}/workitems/{instance}{ ?transaction} Mettre à jour un élément de travail
GET {s}/workitems{ ?query*} Rechercher des éléments de travail
GET {s}/workitems/{instance} Récupérer un élément de travail
PUT {s}/workitems/{instance}/state Modifier l’état de l’élément de travail
POST {s}/workitems/{instance}/cancelrequest Annuler l’élément de travail
POST {s}/workitems/{instance}/subscribers/{AETitle}{ ?deletionlock} Créer un abonnement
POST {s}/workitems/1.2.840.10008.5.1.4.34.5/ Suspendre l’abonnement
DELETE {s}/workitems/{instance}/subscribers/{AETitle} Supprimer l’abonnement
GET {s}/subscribers/{AETitle} Ouvrir le canal d’abonnement

Créer un élément de travail

Cette transaction utilise la méthode POST pour créer un élément Workitem.

Méthode Path Description
POST .. /workitems Créez un workitem.
POST .. /workitems ? {workitem} Crée un workitem avec l’UID spécifié.

S’il n’est pas spécifié dans l’URI, le jeu de données de charge utile doit contenir l’élément Workitem dans l’attribut SOPInstanceUID .

Les Accept en-têtes et Content-Type les en-têtes sont requis dans la requête et doivent avoir la valeur application/dicom+json.

Il existe plusieurs exigences liées aux attributs de données DICOM dans le contexte d’une transaction spécifique. Les attributs peuvent être tenus d’être présents, de ne pas être présents, d’être vides ou de ne pas être vides. Ces exigences sont disponibles dans ce tableau.

Remarque

Bien que le tableau de référence indique que l’INTERFACE UTILISATEUR de l’instance SOP ne doit pas être présente, cette aide est spécifique au protocole DIMSE et est gérée différemment dans DICOMWeb. L’UID de l’instance SOP doit être présente dans le jeu de données, si ce n’est pas dans l’URI.

Remarque

Tous les codes d’exigence conditionnelle, y compris 1C et 2C, sont traités comme facultatifs.

Créer des codes d’état de réponse

Code Description
201 (Created) L’élément Workitem cible a été créé avec succès.
400 (Bad Request) Il y a eu un problème avec la demande. Par exemple, la charge utile de la demande ne répondait pas aux exigences.
401 (Unauthorized) Le client n’est pas authentifié.
403 (Forbidden) L’utilisateur n’est pas autorisé.
409 (Conflict) L’élément Workitem existe déjà.
415 (Unsupported Media Type) L’élément fourni Content-Type n’est pas pris en charge.
503 (Service Unavailable) Le service n’est pas disponible ou occupé. Réessayez plus tard.

Créer une charge utile de réponse

Une réponse de réussite n’a aucune charge utile. Les Location en-têtes de réponse et Content-Location les en-têtes contiennent une référence d’URI à l’élément Workitem créé.

Une charge utile de réponse d’échec contient un message décrivant l’échec.

Annulation de la demande

Cette transaction permet à l’utilisateur de demander l’annulation d’un Workitem non noyé.

Il existe quatre états Workitem valides :

  • SCHEDULED
  • IN PROGRESS
  • CANCELED
  • COMPLETED

Cette transaction réussit uniquement sur Workitems dans l’état SCHEDULED . Tout utilisateur peut revendiquer la propriété d’un workitem en définissant son UID transactionnel et en modifiant son état IN PROGRESSsur . À partir de là, un utilisateur peut uniquement modifier l’élément Workitem en fournissant l’INTERFACE utilisateur de transaction correcte. Bien que UPS définit les classes Watch et Event SOP qui autorisent les demandes d’annulation et d’autres événements à transférer, ce service DICOM n’implémente pas ces classes, et donc les demandes d’annulation sur les éléments de travail qui retournent IN PROGRESS un échec. Un workitem appartenant peut être annulé via la transaction Change Workitem State .

Méthode Path Description
POST .. /workitems/{workitem}/cancelrequest Demander l’annulation d’un workitem planifié

L’en-tête Content-Type est obligatoire et doit avoir la valeur application/dicom+json.

La charge utile de la demande peut inclure des informations d’action telles que définies dans la norme DICOM.

Codes d’état de la réponse d’annulation de demande

Code Description
202 (Accepted) La demande a été acceptée par le serveur, mais l’état de l’élément de travail cible n’est pas modifié.
400 (Bad Request) Il y a eu un problème avec la syntaxe de la requête.
401 (Unauthorized) Le client n’est pas authentifié.
403 (Forbidden) L’utilisateur n’est pas autorisé.
404 (Not Found) L’objet Workitem cible n’a pas été trouvé.
409 (Conflict) La requête est incohérente avec l’état actuel de l’élément de travail cible. Par exemple, l’élément Workitem cible est dans l’état ou COMPLETED dans l’étatSCHEDULED.
415 (Unsupported Media Type) L’élément fourni Content-Type n’est pas pris en charge.

Charge utile de réponse d’annulation de requête

Une réponse de réussite n’a pas de charge utile et une charge utile de réponse d’échec contient un message décrivant l’échec. Si l’instance Workitem est déjà dans un état annulé, la réponse inclut l’en-tête d’avertissement HTTP suivant : 299: The UPS is already in the requested state of CANCELED.

Récupérer Workitem

Cette transaction récupère un workitem. Il correspond à l’opération UPS DIMSE N-GET.

Reportez-vous à : https://dicom.nema.org/medical/dicom/current/output/html/part18.html#sect_11.5

Si l’élément Workitem existe sur le serveur d’origine, l’élément Workitem doit être retourné dans un type de média acceptable. L’élément Workitem retourné ne contient pas l’attribut TRANSACTION UID (0008,1195). Cela est nécessaire pour conserver le rôle de l’attribut en tant que verrou d’accès.

Méthode Path Description
GET .. /workitems/{workitem} Demande de récupération d’un objet Workitem

L’en-tête Accept est obligatoire et doit avoir la valeur application/dicom+json.

Récupérer les codes d’état de réponse Workitem

Code Description
200 (OK) L’instance Workitem a été récupérée avec succès.
400 (Requête incorrecte) Il y a eu un problème avec la demande.
401 (Non autorisé) Le client n’est pas authentifié.
403 (Interdit) L’utilisateur n’est pas autorisé.
404 (Introuvable) L’objet Workitem cible n’a pas été trouvé.

Récupérer la charge utile de réponse Workitem

  • Une réponse de réussite a une charge utile de partie unique contenant l’élément Workitem demandé dans le type de média sélectionné.
  • L’élément Workitem retourné ne contient pas l’attribut Transaction UID (0008, 1195) de l’élément Workitem, car cela ne doit être connu que du propriétaire.

Mettre à jour Workitem

Cette transaction modifie les attributs d’un workitem existant. Il correspond à l’opération UPS DIMSE N-SET.

Reportez-vous à : https://dicom.nema.org/medical/dicom/current/output/html/part18.html#sect_11.6

Pour mettre à jour un élément Workitem actuellement dans l’état SCHEDULED , l’attribut Transaction UID ne doit pas être présent. Pour un workitem dans l’état IN PROGRESS , la requête doit inclure l’UID transactionnel actuel en tant que paramètre de requête. Si l’élément Workitem est déjà dans le COMPLETED ou CANCELED les états, la réponse est 400 (Bad Request).

Méthode Path Description
POST .. /workitems/{workitem} ? {transaction-uid} Mettre à jour la transaction Workitem

L’en-tête Content-Type est obligatoire et doit avoir la valeur application/dicom+json.

La charge utile de la requête contient un jeu de données avec les modifications à appliquer à l’élément Workitem cible. Lorsqu’une séquence est modifiée, la requête doit inclure tous les éléments de la séquence, pas seulement les éléments à modifier. Lorsque plusieurs attributs doivent être mis à jour en tant que groupe, effectuez la mise à jour en tant qu’attributs multiples dans une seule requête, et non comme plusieurs requêtes.

Il existe de nombreuses exigences liées aux attributs de données DICOM dans le contexte d’une transaction spécifique. Les attributs peuvent être tenus d’être présents, de ne pas être présents, d’être vides ou de ne pas être vides. Ces exigences sont disponibles dans ce tableau.

Remarque

Tous les codes d’exigence conditionnelle, y compris 1C et 2C, sont traités comme facultatifs.

Remarque

La requête ne peut pas définir la valeur de l’attribut État de l’étape de procédure (0074 1000). L’état de l’étape de procédure est géré à l’aide de la transaction d’état de modification ou de la transaction d’annulation de demande.

Mettre à jour les codes d’état de la réponse de transaction Workitem

Code Description
200 (OK) L’objet Workitem cible a été mis à jour.
400 (Bad Request) Il y a eu un problème avec la demande. Par exemple : (1) l’élément de travail cible était dans l’état ou CANCELED dans l’étatCOMPLETED. (2) l’UID de transaction est manquant. (3) l’UID de transaction est incorrect. (4) le jeu de données n’est pas conforme aux exigences.
401 (Unauthorized) Le client n’est pas authentifié.
403 (Forbidden) L’utilisateur n’est pas autorisé.
404 (Not Found) L’objet Workitem cible n’a pas été trouvé.
409 (Conflict) La requête est incohérente avec l’état actuel de l’élément de travail cible.
415 (Unsupported Media Type) L’élément fourni Content-Type n’est pas pris en charge.

Mettre à jour la charge utile de réponse de transaction Workitem

Le serveur d’origine prend en charge les champs d’en-tête requis dans le tableau 11.6.3-2.

Une réponse de réussite n’a pas de charge utile ou de charge utile contenant un document Rapport d’état.

Une charge utile de réponse d’échec peut contenir un rapport d’état décrivant les échecs, avertissements ou autres informations utiles.

Modifier l’état workitem

Cette transaction est utilisée pour modifier l’état d’un workitem. Il correspond à l’opération UPS DIMSE N-ACTION « Modifier l’état UPS ». Les modifications d’état sont utilisées pour revendiquer la propriété, terminer ou annuler un workitem.

Reportez-vous à : https://dicom.nema.org/medical/dicom/current/output/html/part18.html#sect_11.7

Si l’élément Workitem existe sur le serveur d’origine, l’élément Workitem doit être retourné dans un type de média acceptable. L’élément Workitem retourné ne contient pas l’attribut Transaction UID (0008,1195). Cela est nécessaire pour conserver le rôle de cet attribut en tant que verrou d’accès, comme décrit ici.

Méthode Path Description
PUT .. /workitems/{workitem}/state Modifier l’état de l’élément de travail

L’en-tête Accept est obligatoire et doit avoir la valeur application/dicom+json.

La charge utile de la requête doit contenir les éléments de données d’état UPS de modification. Ces éléments de données sont les suivants :

  • UID de transaction (0008, 1195). La charge utile de la demande doit inclure un UID de transaction. L’agent utilisateur crée l’UID de transaction lors de la demande d’une transition vers l’état IN PROGRESS d’un workitem donné. L’agent utilisateur fournit cet UID transactionnel dans les transactions suivantes avec cet élément Workitem.
  • État de l’étape de procédure (0074, 1000). Les valeurs légales correspondent à la transition d’état demandée. Ils sont : IN PROGRESS, ou COMPLETEDCANCELED.

Modifier les codes d’état de réponse de l’état Workitem

Code Description
200 (OK) L’instance Workitem a été récupérée avec succès.
400 (Bad Request) La requête ne peut pas être effectuée pour l’une des raisons suivantes : (1) la requête n’est pas valide en fonction de l’état actuel de l’élément de travail cible. (2) l’UID de transaction est manquant. (3) l’UID de transaction est incorrect
401 (Unauthorized) Le client n’est pas authentifié.
403 (Forbidden) L’utilisateur n’est pas autorisé.
404 (Not Found) L’objet Workitem cible n’a pas été trouvé.
409 (Conflict) La requête est incohérente avec l’état actuel de l’élément de travail cible.

Modifier la charge utile de réponse de l’état Workitem

  • Les réponses incluent les champs d’en-tête spécifiés dans la section 11.7.3.2.
  • Une réponse de réussite n’a aucune charge utile.
  • Une charge utile de réponse d’échec peut contenir un rapport d’état décrivant les échecs, avertissements ou autres informations utiles.

Rechercher des éléments de travail

Cette transaction vous permet de rechercher des workitems par attributs.

Méthode Path Description
GET .. /workitems ? Rechercher des éléments de travail

Les en-têtes suivants Accept sont pris en charge pour la recherche :

  • application/dicom+json

Paramètres de recherche pris en charge

Les paramètres suivants pour chaque requête sont pris en charge :

Clé Valeur(s) de support Nombre autorisé Description
{attributeID}= {value} 0...N Recherchez la correspondance d’attribut/valeur dans la requête.
includefield= {attributeID}
all		 0...N Les autres attributs à retourner dans la réponse. Seuls les attributs de niveau supérieur peuvent être inclus , et non pas les attributs qui font partie de séquences. Les balises publiques et privées sont prises en charge. Une fois all fourni, consultez La réponse de recherche pour plus d’informations sur les attributs retournés pour chaque type de requête. Si un mélange est {attributeID}all fourni, le serveur utilise par défaut « all ».
limit= {value} 0...1 Valeur entière pour limiter le nombre de valeurs retournées dans la réponse. La valeur peut être comprise entre la plage 1 >= x <= 200. Valeur par défaut : 100.
offset= {value} 0...1 Ignorez les résultats {value}. Si un décalage est fourni plus grand que le nombre de résultats de la requête de recherche, une 204 (no content) réponse est retournée.
fuzzymatching= true | false 0...1 Si la correspondance approximative vraie est appliquée à tous les attributs avec la représentation de valeur PN (Person Name). Il effectue une correspondance de mot de préfixe de n’importe quelle partie de nom à l’intérieur de ces attributs. Par exemple, si PatientName c’est John^Doe, johpuis , do, jo do, et DoeJohn Doe toutes les correspondances. Toutefois ohn , ne correspond pas .
Attributs pouvant faire l’objet d’une recherche

Nous prenons en charge la recherche sur ces attributs :

Mot clé d’attribut
PatientName
PatientID
ReferencedRequestSequence.AccessionNumber
ReferencedRequestSequence.RequestedProcedureID
ScheduledProcedureStepStartDateTime
ScheduledStationNameCodeSequence.CodeValue
ScheduledStationClassCodeSequence.CodeValue
ScheduledStationGeographicLocationCodeSequence.CodeValue
ProcedureStepState
StudyInstanceUID
Correspondance de recherche

Nous prenons en charge ces types de correspondances :

Type de recherche Attribut pris en charge Exemple
Requête de plage Scheduled​Procedure​Step​Start​Date​Time {attributeID}={value1}-{value2}. Pour les valeurs de date/heure, nous prenons en charge une plage inclusive sur la balise. Cette opération est mappée à attributeID >= {value1} AND attributeID <= {value2}. Si {value1} ce n’est pas spécifié, toutes les occurrences de dates/heures antérieures et comprises {value2} sont mises en correspondance. De même, s’il {value2} n’est pas spécifié, toutes les occurrences des {value1} dates/heures suivantes sont mises en correspondance. Toutefois, l’une de ces valeurs doit être présente. {attributeID}={value1}- et {attributeID}=-{value2} sont valides, cependant, {attributeID}=- n’est pas valide.
Correspondance exacte Tous les attributs pris en charge {attributeID}={value1}
Correspondance approximative PatientName Correspond à n’importe quel composant du nom qui commence par la valeur.

Remarque

Bien que nous ne prenions pas en charge la correspondance de séquence complète, nous prenons en charge la correspondance exacte sur les attributs répertoriés dans une séquence.

ID d’attribut

Les balises peuvent être encodées de plusieurs façons pour le paramètre de requête. Nous avons partiellement implémenté la norme telle que définie dans PS3.18 6.7.1.1.1. Les encodages suivants pour une balise sont pris en charge :

Valeur Exemple
{group}{element} 00100010
{dicomKeyword} PatientName

Exemple de requête :

../workitems?PatientID=K123&0040A370.00080050=1423JS&includefield=00404005&limit=5&offset=0

Réponse de recherche

La réponse est un tableau de jeux de 0...N données DICOM avec les attributs suivants retournés :

  • Tous les attributs dans DICOM PowerShell 3.4 Table CC.2.5-3 avec un type de clé de retour de 1 ou 2
  • Tous les attributs de la table DICOM PowerShell 3.4 Table CC.2.5-3 avec un type de clé de retour de 1C pour lequel les exigences conditionnelles sont remplies
  • Tous les autres attributs Workitem passés en tant que paramètres de correspondance
  • Tous les autres attributs Workitem passés en tant que includefield valeurs de paramètre

Codes de réponse de recherche

L’API de requête retourne l’un des codes d’état suivants dans la réponse :

Code Description
200 (OK) La charge utile de réponse contient toutes les ressources correspondantes.
206 (Partial Content) La charge utile de réponse contient uniquement certains des résultats de la recherche, et le reste peut être demandé par le biais de la requête appropriée.
204 (No Content) La recherche s’est terminée avec succès, mais aucun résultat n’a été retourné.
400 (Bad Request) Il y a eu un problème avec la demande. Par exemple, syntaxe de paramètre de requête non valide. Le corps de la réponse contient les détails de l’échec.
401 (Unauthorized) Le client n’est pas authentifié.
403 (Forbidden) L’utilisateur n’est pas autorisé.
503 (Service Unavailable) Le service n’est pas disponible ou occupé. Réessayez plus tard.

Autres notes

L’API de requête n’est pas 413 (request entity too large). Si la limite de réponse de requête demandée est en dehors de la plage acceptable, une requête incorrecte est retournée. Tout ce qui est demandé dans la plage acceptable est résolu.

  • Les résultats paginés sont optimisés pour retourner la dernière instance correspondante en premier, ce qui peut entraîner des enregistrements en double dans les pages suivantes si des données plus récentes correspondant à la requête ont été ajoutées.
  • La correspondance ne respecte pas la casse et ne respecte pas les accents pour les types PN VR.
  • La correspondance ne respecte pas la casse et respecte les accents pour les autres types VR de chaîne.
  • S’il existe un scénario dans lequel l’annulation d’un workitem et l’interrogation se produisent en même temps, la requête exclut probablement l’élément Workitem qui est mis à jour et le code de réponse est 206 (Partial Content).

Remarque

DICOM® est une marque déposée de la National Electrical Manufacturers Association pour ses publications de standards relatifs aux communications numériques des informations médicales.