Instruction de conformité DICOM v1
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.
Method | 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 StudyInstanceUID
DICOM . Si elle est spécifiée, toute instance qui n’appartient pas à l’étude fournie est rejetée avec un 43265
code d’avertissement.
L’en-tête suivant Accept
pour la réponse est 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 LO
VR
type.
Chaque fichier stocké doit avoir une combinaison unique de StudyInstanceUID
, SeriesInstanceUID
et 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 celle-ci StudyInstanceUID a été fournie 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 |
Raison pour laquelle cette instance n’a pas pu stocker |
(0074, 1048) | FailedAttributesSequence |
Séquence de ce qui inclut la raison de ErrorComment 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 StudyInstanceUID objet , SeriesInstanceUID et 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 nettoyage 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.
Method | 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 instance unique |
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 surapplication/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 surapplication/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 surapplication/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 : la
HTTP 304 (Not Modified)
réponse est envoyée sans corps de réponse. - Les données ont changé depuis la dernière requête : la
HTTP 200 (OK)
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, par défaut, seul le premier frame est rendu en tant qu’image.
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 allant de 1
à 100
inclusive (1 étant la pire qualité et 100 étant de meilleure qualité) peut être passée comme 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. S’il n’est pas spécifié, le paramètre est défini par défaut sur 100
.
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. Dans ce cas, le contenu n’est pas ajouté au corps de la réponse. Pour plus d’informations, consultez la section précédente 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 une 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.
Method | 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 |
L’en-tête suivant Accept
est 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é | Valeurs de prise en charge | Nombre autorisé | Description |
---|---|---|---|
{attributeID}= |
{value} |
0...N | Rechercher 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 prises en charge. Quand all est fourni. Pour plus d’informations sur les attributs retournés pour chaque type de requête, reportez-vous à la réponse de recherche.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, par défaut sur 100. |
offset= |
{value} |
0..1 | Ignorer les {value} résultats ; Si un décalage supérieur au nombre de résultats de la requête de recherche est fourni, une 204 (no content) réponse 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, qui 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 |
Voici un exemple de requête qui recherche des 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
, lesStudy
attributs de niveau sontSeries
é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 auStudy
niveauincludeField
.NumberOfSeriesRelatedInstances
l’attribut agrégé est pris en charge auSeries
niveauincludeField
.
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 n’est pas sensible à la casse et n’est pas sensible aux accents pour les types PN VR.
- La correspondance n’est pas sensible à la casse et respecte l’accentuation pour les autres types VR de chaîne.
- Seule la première valeur est indexée si un élément de données à valeur unique 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.
Method | Path | Description |
---|---|---|
DELETE | .. /studies/{study} | Supprimer toutes les instances d’une étude spécifique |
DELETE | .. /studies/{study}/series/{series} | Supprimer toutes les instances d’une série spécifique dans une étude |
DELETE | .. /studies/{study}/series/{series}/instances/{instance} | Supprimer une instance spécifique dans une série |
Les paramètres study
, series
et instance
correspondent aux attributs StudyInstanceUID
DICOM , SeriesInstanceUID
et 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.
Method | Path | Description |
---|---|---|
POST | .. /workitems | Créer 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’INTERFACE UTILISATEUR 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 PROGRESS
sur . À 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 des classes Watch et Event SOP qui autorisent le transfert des demandes d’annulation et d’autres événements, ce service DICOM n’implémente pas ces classes, et donc les demandes d’annulation sur les éléments de travail qui IN PROGRESS
retournent un échec. Un workitem appartenant peut être annulé via la transaction Change Workitem State .
Method | 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.
Faire référence à: 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 est 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.
Method | 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.
Faire référence à: https://dicom.nema.org/medical/dicom/current/output/html/part18.html#sect_11.6
Pour mettre à jour un 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)
.
Method | 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 aucune charge utile ou une 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.
Faire référence à: 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 est 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.
Method | 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 contient 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 requête inclut 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
, ouCOMPLETED
CANCELED
.
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 demande 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.
Method | Path | Description |
---|---|---|
GET | .. /workitems ? | Rechercher des éléments de travail |
L’en-tête suivant Accept
est 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é | Valeurs de prise en charge | Nombre autorisé | Description |
---|---|---|---|
{attributeID}= |
{value} |
0...N | Rechercher 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 , définie par défaut sur 100 . |
offset= |
{value} |
0...1 | Ignorez les résultats {value} ; Si un décalage supérieur au nombre de résultats de la requête de recherche est fourni, 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) (VR) ; Une correspondance de mot de préfixe de n’importe quelle partie de nom à l’intérieur de ces attributs est effectuée. Par exemple, si PatientName c’est John^Doe , joh puis , do , jo do , et Doe John 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 correspondants.
Type de recherche | Attribut pris en charge | Exemple |
---|---|---|
Requête de plage | ScheduledProcedureStepStartDateTime |
{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 de la table 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 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.
- 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 n’est pas sensible à la casse et n’est pas sensible aux accents pour les types PN VR.
- La correspondance n’est pas sensible à la casse et respecte l’accentuation pour les autres types VR de chaîne.
- S’il existe un scénario où l’annulation d’un workitem et l’interrogation du même élément de travail 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.