ISO 17432:2004

Health informatics — Messages and communication — Web access to DICOM persistent objects

ISO 17432:2005 specifies a web-based service for accessing and presenting DICOM (Digital Imaging and Communications in Medicine) persistent objects (e.g. images, medical imaging reports). This is intended for distribution of results and images to healthcare professionals. It provides a simple mechanism for accessing a DICOM persistent object from HTML pages or XML documents, through HTTP/HTTPs protocol, using DICOM UIDs (Unique Identifiers). Data may be retrieved either in a presentation-ready form as specified by the requester (e.g. JPEG or GIF) or in a native DICOM format. ISO 17432:2005 does not support facilities for web searching of DICOM images. It relates only to DICOM persistent objects (not to other DICOM objects or to non-DICOM objects). Access control beyond the security mechanisms generally available to web applications is outside the scope of this International Standard.

Informatique de santé — Messages et communication — Accès au web pour les objets persistants DICOM

L'ISO 17432:2005 spécifie un service basé sur le Web permettant l'accès et la présentation d'objets persistants DICOM (Digital Imaging and Communications in Medicine) par exemple images, comptes-rendus d'imagerie médicale. Elle a pour objet la communication de comptes-rendus et d'images aux professionnels de la santé. Elle fournit un moyen simple d'accès à un objet persistant DICOM à partir de pages HTML ou de documents XML, par l'intermédiaire d'un protocole HTTP/HTTPs, à l'aide d'identifiants uniques DICOM. Les données peuvent être récupérées soit dans un format classique comme spécifié dans la requête (par exemple JPEG ou GIF), soit dans un format DICOM natif. L'ISO 17432:2005 ne concerne pas l'interrogation de bases de données d'images DICOM via le Web. Elle s'applique uniquement aux objets persistants DICOM (non aux autres objets DICOM ni aux objets non DICOM). Le contrôle d'accès s'ajoutant aux mécanismes de sécurité généralement associés aux applications Web ne relève pas directement du domaine d'application de la présente Norme internationale

General Information

• Status: Withdrawn
• Publication Date: 30-Nov-2004
• Withdrawal Date: 30-Nov-2004
• ICS: 35.240.80 - IT applications in health care technology
• Technical Committee: ISO/TC 215 - Health informatics
• Drafting Committee: ISO/TC 215/WG 2 - Systems and Device Interoperability
• Current Stage: 9599 - Withdrawal of International Standard
• Completion Date: 03-Feb-2021

Standards Content (Sample)

INTERNATIONAL ISO
STANDARD 17432
First edition
2004-12-15

Health informatics — Messages and
communication — Web access to DICOM
persistent objects
Informatique de santé — Messages et communication — Accès au web
pour les objets persistants DICOM




Reference number
ISO 17432:2004(E)
©
ISO 2004

---------------------- Page: 1 ----------------------
ISO 17432:2004(E)
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but
shall not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In
downloading this file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat
accepts no liability in this area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation
parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In
the unlikely event that a problem relating to it is found, please inform the Central Secretariat at the address given below.


©  ISO 2004
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or
ISO's member body in the country of the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail [e-mail]
Web www.iso.org
Published in Switzerland

ii © ISO 2004 – All rights reserved

---------------------- Page: 2 ----------------------
ISO 17432:2004(E)
Contents Page
Foreword. iv
Introduction . v
1 Scope. 1
2 Normative references . 1
3 Terms and definitions. 2
4 Symbols and abbreviated terms. 2
5 Data communication Requirements. 3
5.1 Interaction. 3
5.2 HTTP request. 3
5.3 HTTP Response. 4
6 Persistent object types. 5
6.1 General. 5
6.2 Single frame image objects. 5
6.3 Multi-frame image objects. 5
6.4 Text objects . 6
6.5 Other objects . 6
7 Parameters. 7
7.1 Parameters available for all DICOM persistent objects . 7
7.2 Parameters for DICOM single frame and multi-frame image persistent objects only . 9
Annex A (informative) URL/URI transfer syntax. 13
Annex B (informative) Examples. 15
Annex C (informative) Applications. 16
Annex D (informative) IANA Mapping. 17

© ISO 2004 – All rights reserved iii

---------------------- Page: 3 ----------------------
ISO 17432:2004(E)
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies
(ISO member bodies). The work of preparing International Standards is normally carried out through ISO
technical committees. Each member body interested in a subject for which a technical committee has been
established has the right to be represented on that committee. International organizations, governmental and
non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the
International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of technical committees is to prepare International Standards. Draft International Standards
adopted by the technical committees are circulated to the member bodies for voting. Publication as an
International Standard requires approval by at least 75 % of the member bodies casting a vote.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. ISO shall not be held responsible for identifying any or all such patent rights.
ISO 17432 was prepared by Technical Committee ISO/TC 215, Health informatics in liaison with DICOM and
is equivalent to DICOM Part 18, Supplement 85.
iv © ISO 2004 – All rights reserved

---------------------- Page: 4 ----------------------
ISO 17432:2004(E)
Introduction
The DICOM standard is well accepted in the medical imaging area, including radiology, cardiology, pathology,
radiotherapy as well as specialities using visible light imaging equipment (e.g. endoscopes, microscopes).
The requesters of medical imaging studies and care providers require rapid and reliable access to reports and
images. Within computerized environments such access is increasingly based on web technologies. Access to
relevant DICOM persistent objects is required without the need for duplication of such data objects.
Clinicians need to have access either to the original data in native DICOM format that allows extensive
manipulation using specialized software which makes use of the detailed DICOM meta-data, or rendered into
a generic format (e.g. JPEG, PDF) that can be presented with off-the-shelf applications.
This International Standard specifies the means whereby a request for access to a DICOM persistent object is
to be expressed as an HTTP URL/URI (see IETF RFC2396) request which includes a pointer to a specific
DICOM persistent object in the form of its instance UID. The request also specifies the format of the result to
be returned in response to the request. Examples include:
a) (MIME) content-type (e.g. application/dicom or image/jpeg for images, application/dicom or application/rtf
or xml for reports);
b) content-encodings;
c) reports as HL7/CDA Level 1.
The parameters of the query URL as defined within this International Standard are sufficient for the HTTP
server to act as a DICOM SCU (Service Class User) to retrieve the requested object from an appropriate
DICOM SCP (Service Class Provider) using baseline DICOM functionality as defined in DICOM PS 3.4 and
DICOM PS 3.7.
Specifications of requirements for additional DICOM persistent objects and formats for the responses from the
server will be produced in the future as required.
© ISO 2004 – All rights reserved v

---------------------- Page: 5 ----------------------
INTERNATIONAL STANDARD ISO 17432:2004(E)

Health informatics — Messages and communication — Web
access to DICOM persistent objects
1 Scope
This International Standard specifies a web-based service for accessing and presenting DICOM (Digital
Imaging and Communications in Medicine) persistent objects (e.g. images, medical imaging reports). This is
intended for distribution of results and images to healthcare professionals. It provides a simple mechanism for
accessing a DICOM persistent object from HTML pages or XML documents, through HTTP/HTTPs protocol,
using DICOM UIDs (Unique Identifiers). Data may be retrieved either in a presentation-ready form as specified
by the requester (e.g. JPEG or GIF) or in a native DICOM format.
This International Standard does not support facilities for web searching of DICOM images. It relates only to
DICOM persistent objects (not to other DICOM objects or to non-DICOM objects). Access control beyond the
security mechanisms generally available to web applications is outside the scope of this International
Standard.
NOTE Systems claiming conformance to this International Standard shall function in accordance with all its
mandatory clauses.
2 Normative references
The following referenced documents are indispensable for the application of this document. For dated
references, only the edition cited applies. For undated references, the latest edition of the referenced
document (including any amendments) applies.
ISO/IEC 10918-2:1995, Information technology — Digital compression and coding of continuous-tone still
images: Compliance testing
DICOM PS 3.3, Digital Imaging and Communications in Medicine, Information Object Definitions
DICOM PS 3.4, Digital Imaging and Communications in Medicine, Service Class Specifications
DICOM PS 3.5, Digital Imaging and Communications in Medicine, Data Structures and Encoding
DICOM PS 3.6, Digital Imaging and Communications in Medicine, Data Dictionary
DICOM PS 3.7, Digital Imaging and Communications in Medicine, Message Exchange
DICOM PS 3.10, Digital Imaging and Communications in Medicine, Media Storage and File Format for Data
Interchange
DICOM PS 3.11, Digital Imaging and Communications in Medicine, Media Storage Application Profiles
DICOM PS 3.14, Digital Imaging and Communications in Medicine, Grayscale Standard Display Function
DICOM PS 3.15, Digital Imaging and Communications in Medicine, Security Profiles
HL7 CDA, Health Level Seven, Clinical Document Architecture (CDA)
© ISO 2004 – All rights reserved 1

---------------------- Page: 6 ----------------------
ISO 17432:2004(E)
IETF RFC2045 et seq., MIME Multipurpose Internet Mail Extension
IETF RFC2396, Uniform Resource Identifiers (URI): Generic Syntax
IETF RFC2616, Hypertext Transfer Protocol — HTTP/1.1
IETF RFC3240, Application/dicom MIME Sub-type Registration
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
3.1
DICOM persistent object
instance of a data object as defined by DICOM PS 3.3, which has been allocated a unique identifier in the
format specified for SOP Instance UID in DICOM PS 3.3 and has been chosen as an object to be saved
securely for some period of time
NOTE Within the DICOM Standard, a DICOM Persistent Object is referred to as a Composite Service Object Pair
(SOP) Instance.
3.2
web client system
system using internet technologies (web, e-mail) interested in retrieving DICOM persistent objects from a web
enabled DICOM server, through HTTP/HTTPs protocol
3.3
web enabled DICOM server
system managing DICOM persistent objects and able to transmit them on request to the web client system
3.4
web access to DICOM persistent objects
service enabling the web client system to retrieve DICOM persistent objects managed by a web enabled
DICOM server, through HTTP/HTTPs protocol
4 Symbols and abbreviated terms
DICOM Digital Imaging and Communications in Medicine
HL7 Health Level Seven
HTML HyperText Markup Language
HTTP HyperText Transfer Protocol
HTTPs HyperText Transfer Protocol, secured
MIME Multipurpose Internet Mail Extensions
SOP Service Object Pair
UID Unique (DICOM) Identifier
URL/URI Uniform Resource Locator/Identifier
XML eXtensible Markup Language
2 © ISO 2004 – All rights reserved

---------------------- Page: 7 ----------------------
ISO 17432:2004(E)
5 Data communication requirements
5.1 Interaction
The interaction shall be as shown in Figure 1.

Figure 1 — Interaction diagram
5.2 HTTP request
5.2.1 Method
The HTTP request shall use the GET method as defined in IETF RFC2616.
5.2.2 Parameters of the HTTP request
The parameters of the component of the request-URI to be sent to the web server through the
HTTP GET method request shall be represented as defined in IETF RFC2396.
NOTE 1 Other components of the request-URI depend on the configuration, e.g. location and script language of the
web enabled DICOM server.
NOTE 2 The means by which the web client system obtains the value of the necessary parameters for web accessing
of DICOM objects is out of the scope of this International Standard.
5.2.3 List of media types supported in the response
The “Accept” field of the GET method request shall specify the media type(s) acceptable to the web client
system. The(se) media type(s) shall include at least the items of the list of MIME (see IETF RFC2045) types
specified in Clause 6 devoted to the DICOM persistent object types.
NOTE Typically the “Accept” field will be sent by a web client as “*/*”. An optional parameter specifies the MIME
type(s) preferred by the web client, as a subset of those specified in the “Accept” field.
© ISO 2004 – All rights reserved 3

---------------------- Page: 8 ----------------------
ISO 17432:2004(E)
5.2.4 List of character sets supported in the response
The “Accept-charset” field of the GET method request shall specify the character set of the object to be
retrieved. If the “Accept-charset” field of the GET method is not present, or the web enabled DICOM server
does not support the specified character set, the character set of the response will be at the discretion of the
web enabled DICOM server.
NOTE Typically, the user of a web client does not have control over the “Accept-charset” field. An optional parameter
specifies the character set to be used in the returned object.
5.3 HTTP Response
5.3.1 General
The response shall be an HTTP response message as specified in IETF RFC2616.
NOTE The content of the message-body varies according to the MEDIA type as defined in 5.3.2.2 and 5.3.4.2.
5.3.2 Body of single DICOM MIME sub-type part response
5.3.2.1 MIME Type
The MIME type shall be “application/dicom”, as specified in IETF RFC3240 and DICOM PS 3.11.
5.3.2.2 Content
The body content shall be a “Part 10 File” which includes a meta-header as defined in DICOM PS 3.10.
5.3.3 Transfer syntax
The returned DICOM object shall be encoded using one of the transfer syntaxes specified in the transfer
syntax query parameter as defined in 7.2.12. By default, the transfer syntax shall be “Explicit VR Little Endian”.
NOTE This implies that retrieved images are sent un-compressed by default.
5.3.4 Body of non-DICOM MIME type response
5.3.4.1 MIME Type
The MIME type shall be one of the MIME types defined in the contentType parameter, preferably the most
desired by the web client, and shall be in any case compatible with the “Accept” field of the GET method.
NOTE The HTTP behaviour is that an error (406 – not acceptable) is returned if the required content type cannot be
served.
5.3.4.2 Content
The content shall be a single MIME part containing the object to be retrieved.
NOTE Multiple objects in a response are not supported by this International Standard. The parameters select only a
single object to retrieve. Most current web clients are able to retrieve single objects, within a “non-multipart” MIME body,
and are not able to support multipart/related or multipart/mixed responses.
4 © ISO 2004 – All rights reserved

---------------------- Page: 9 ----------------------
ISO 17432:2004(E)
6 Persistent object types
6.1 General
The provisions for some specific object types shall be as defined in 6.2 to 6.5.
In all cases the categorization depends on the SOP class of the objects, enabling a client or application
building an HTML page for the client, to determine in advance of the request what the requirements will be.
6.2 Single frame image objects
6.2.1 Objects accessed
In this category are all object instances of SOP classes defined in DICOM PS 3.3, which consist of a single
image frame, instances of multi-frame SOP classes that contain only one frame, or object instances that
consist of a single frame accessed from instances of multi-frame SOP classes using the “frameNumber”
parameter.
6.2.2 MIME type constraints
The server shall be able to send a response in each of the following MIME types:
 application/dicom;
 image/jpeg.
If the contentType parameter is not present in the request, the response shall contain an image/jpeg MIME
type, if compatible with the “Accept” field of the GET method.
When an image/jpeg MIME type is returned, the image shall be encoded using the JPEG baseline lossy 8 bit
Huffman encoded non-hierarchical non-sequential process in accordance with ISO/IEC 10918-2:1995.
NOTE The choice of image/jpeg as the default for continuous tone images is a consequence of the universal support
by web clients.
The server should also support the following MIME types:
 image/gif;
 image/png;
 image/jp2.
The server may also support other MIME types.
6.3 Multi-frame image objects
6.3.1 Objects included
In this category are all SOP classes defined in DICOM PS 3.3 that are multi-frame image objects.
6.3.2 MIME type constraints
The server shall be able to send a response in the following MIME type:
 application/dicom.
© ISO 2004 – All rights reserved 5

---------------------- Page: 10 ----------------------
ISO 17432:2004(E)
If the contentType parameter is not present in the request, the response shall contain an application/dicom
MIME type.
The server should also support the following MIME types:
 video/mpeg;
 image/gif.
The server may also support other MIME types.
6.4 Text objects
6.4.1 Objects included
In this category are all SOP classes defined in DICOM PS 3.3 that include the SR document content module.
NOTE This includes all SOP classes that are SR documents, such as narrative text, structured reports, CAD,
measurement reports and key object selection documents.
6.4.2 MIME type constraints
The server shall be able to send a response in each of the following MIME types:
 application/dicom;
 text/plain;
 text/html.
If the contentType parameter is not present in the request, or contains only MIME types that the server does
not support, the response shall contain a text/html MIME type.
It is recommended that the server also support the following MIME types:
 text/xml;
 application/pdf;
 text/rtf;
 a “CDA” MIME type, in conformance with HL7 CDA, e.g. application/x-hl7-cda-level-one+xml.
The server may also support other MIME types.
6.5 Other objects
6.5.1 Objects included
This category shall include all objects of all SOP classes defined in DICOM PS 3.3 that are not included in the
categories described in 6.2 to 6.4, and which are considered in DICOM PS 3.3 as classes of persistent objects.
6.5.2 MIME type constraints
The server shall be able to send a response in the following MIME type:
 application/dicom.
6 © ISO 2004 – All rights reserved

---------------------- Page: 11 ----------------------
ISO 17432:2004(E)
The server may also support other MIME types.
If the contentType parameter is not present in the request, the response shall contain an application/dicom
MIME type.
7 Parameters
7.1 Parameters available for all DICOM persistent objects
7.1.1 General
Parameters specified in 7.1.2 to 7.1.8 are applicable to all supported DICOM SOP classes.
To identify a DICOM object, only one UID is required, because any UID is globally unique. However, this
International Standard requires that the UID of the higher levels in the DICOM information model be specified
(i.e., series and study) in order to support the use of DICOM devices that support only the baseline
hierarchical (rather than extended relational) query/retrieve model, which requires the study instance UID and
series instance UID to be defined when retrieving an SOP instance, as defined in DICOM PS 3.4.
7.1.2 Request type
Type of request performed. This parameter is REQUIRED.
The parameter name shall be “requestType”.
The value shall be “WADO”.
NOTE This parameter allows other types of requests to be introduced in the future, using a similar syntax.
7.1.3 Unique identifier of the study
Study instance UID as defined in DICOM PS 3.3. This parameter is REQUIRED.
The parameter name shall be “studyUID”.
The value shall be encoded as a unique identifier (UID) string, as specified in DICOM PS 3.5, except that it
shall not be padded to an even length with a NULL character.
7.1.4 Unique identifier of the series
Series instance UID as defined in DICOM PS 3.3. This parameter is REQUIRED.
The parameter name shall be “seriesUID”.
The value shall be encoded as a unique identifier (UID) string, as specified in DICOM PS 3.5, except that it
shall not be padded to an even length with a NULL character.
7.1.5 Unique identifier of the object
SOP instance UID as defined in DICOM PS 3.3. This parameter is REQUIRED.
The parameter name shall be “objectUID”.
The value shall be encoded as a unique identifier (UID) string, as specified in DICOM PS 3.5, except that it
shall not be padded to an even length with a NULL character.
© ISO 2004 – All rights reserved 7

---------------------- Page: 12 ----------------------
ISO 17432:2004(E)
7.1.6 MIME type of the response
MIME type(s) desired by the web client for the response from the server, as defined in IETF RFC2616. This
parameter is OPTIONAL.
The parameter name shall be “contentType”.
The value shall be a list of MIME types, separated by a “,” character, and potentially associated with relative
degree of preference, as specified in IETF RFC2616.
The web client shall provide a list of content types it supports in the “Accept” field of the GET method. The
value of the contentType parameter of the request shall be one of the values specified in that field.
NOTE 1 Typically the “Accept” field will be sent by a web client as “*/*”, which is compatible with any MIME types.
NOTE 2 When this parameter is absent, the default content type of the response is dictated by the “MIME type
constraints” in 6.2.2, 6.3.2, 6.4.2, 6.5.2.
7.1.7 Charset of the response
Character set with which the returned object is to be encoded, as defined in IETF RFC2616. This parameter is
OPTIONAL.
The parameter name shall be “charset”.
The value shall be a list of character sets, separated by a “,” character, and potentially associated with relative
degree of preference, as specified in IETF RFC2616.
The web client may provide a list of character sets it supports in the “Accept-charset” field of the GET method.
If this field is present, the value of the charset parameter of the request shall be one of the values specified in
it.
The server may or may not support character set conversion. If character set conversion is supported:
 text-based DICOM objects retrieved other than as application/dicom MIME type (e.g., text/plain) may
be returned in the requested character set (converted if necessary);
 DICOM objects retrieved as application/dicom MIME type have all contained strings returned in the
requested character set (converted if necessary) and the specific character set (0008, 0005) updated
(if necessary).
The IANA character set registrations specify names and multiple aliases for most character sets. The standard
value for use in WADO is the one marked by IANA as “preferred for MIME.” If IANA has not marked one of the
aliases as “preferred for MIME”, the name used in DICOM shall be the value used for WADO.
NOTE The Table D.1 provides an informative mapping of some IANA values to DICOM specific character set defined
terms.
7.1.8 Anonymize object
Removal of all patient identification information from within the DICOM object, if not already done, as defined
in DICOM PS 3.15. This parameter is OPTIONAL. It shall only be present if contentType is application/dicom.
This parameter is optional.
The parameter name shall be “anonymize”.
The value shall be “yes”.
8 © ISO 2004 – All rights reserved

---------------------- Page: 13 ----------------------
ISO 17432:2004(E)
The server may return an error if it either cannot or refuses to anonymize that object.
The server shall return a new SOP instance UID if the content of the object has not already been anonymized.
NOTE 1 This International Standard does not introduce any security-related requirements. It is likely that the
information contained within DICOM objects identifies the patient. The protocol used (i.e. HTTP) can be replaced by
HTTPs, which is its secure extension, to protect the information in transit. The underlying DICOM implementation decides
whether or not to grant access to a particular DICOM object based on whatever security policy or mechanism it has in
place. A server is unlikely to fulfil a request from an unknown user (e.g., accessed via the HTTP protocol) unless it is
certain that the data requested has no patient-identifying information within it and has been approved for public viewing.
NOTE 2 The anonymize object enables, e.g., teaching files systems or clinical trial applications to offer an access to
original images stored in a PACS, without disclosing the patient's identity, and requiring storage of a (de-identified) copy of
the original image. Anonymization is the responsibility of the server. In order to preserve patient confidentiality, it is likely
that the server will refuse to deliver an anonymized SOP instance to an unknown or unauthorized person unless the server
is certain that the SOP instance holds no patient identifying information. This would include “blanking out” any annotation
area(s) containing nominative information burned into the pixels or in the overlays.
7.2 Parameters for DICOM single frame and multi-frame image persistent objects only
7.2.1 General
These parameters shall only be included when a request is made for a single frame image object or multi-
frame image object as defined in 6.2 and 6.3 respectively.
7.2.2 Annotation on the object
Annotation of an object retrieved and displayed as an image. This parameter is OPTIONAL. It shall not be
present if contentType is application/dicom, or is a non-image MIME type (e.g. text/*). When it is not present
for an image object, no annotation shall be burnt in.
When used in conjunction with a presentation state object, it shall be applied after the presentation on the
image. When used in conjunction with the region parameter, it shall be applied after the selection of the region.
The parameter name shall be “annotation”. Its value is a non-empty list of one or more of the following items
separated by a “,” character:
 “patient”, for displaying patient information on the image (e.g. patient's name, birth date);
 “technique”, for displaying technique information of the image (e.g. image number, study date, image
position).
The exact nature and presentation of the annotation is determined by the server. The annotation is burned
into the returned image pixels.
7.2.3 Number of pixel rows
The parameter name shall be “rows”.
The value shall be expressed as an integer, representing the image height to be returned. It is OPTIONAL. It
shall not be present if contentType is application/dicom.
If both “rows” and “columns” are specified, then each shall be interpreted as a maximum, and a size will be
chosen for the image within these constraints, maintaining the correct aspect ratio. If the number of rows is
absent and the number of columns is present, the number of rows shall be chosen in order to maintain the
correct aspect ratio. If both are absent, the image (or selected region) is sent in its original size (or the size of
the presentation state applied on the image), resulting as one pixel of screen image for each value in the
image data matrix.
The value shall be encoded as an integer string (IS), as specified in DICOM PS 3.5.
© ISO 2004 – All rights reserved 9

---------------------- Page: 14 ----------------------
ISO 17432:2004(E)
7.2.4 Number of pixel columns
The parameter name shall be “columns”.
The value shall be expressed as an integer, representing the image width to be returned. It is OPTIONAL. It
...

NORME ISO
INTERNATIONALE 17432
Première édition
2004-12-15


Informatique de santé — Messages et
communication — Accès au web pour les
objets persistants DICOM
Health informatics — Messages and communication — Web access to
DICOM persistent objects




Numéro de référence
ISO 17432:2004(F)
©
ISO 2004

---------------------- Page: 1 ----------------------
ISO 17432:2004(F)
PDF – Exonération de responsabilité
Le présent fichier PDF peut contenir des polices de caractères intégrées. Conformément aux conditions de licence d'Adobe, ce fichier
peut être imprimé ou visualisé, mais ne doit pas être modifié à moins que l'ordinateur employé à cet effet ne bénéficie d'une licence
autorisant l'utilisation de ces polices et que celles-ci y soient installées. Lors du téléchargement de ce fichier, les parties concernées
acceptent de fait la responsabilité de ne pas enfreindre les conditions de licence d'Adobe. Le Secrétariat central de l'ISO décline toute
responsabilité en la matière.
Adobe est une marque déposée d'Adobe Systems Incorporated.
Les détails relatifs aux produits logiciels utilisés pour la création du présent fichier PDF sont disponibles dans la rubrique General Info
du fichier; les paramètres de création PDF ont été optimisés pour l'impression. Toutes les mesures ont été prises pour garantir
l'exploitation de ce fichier par les comités membres de l'ISO. Dans le cas peu probable où surviendrait un problème d'utilisation,
veuillez en informer le Secrétariat central à l'adresse donnée ci-dessous.


©  ISO 2004
Droits de reproduction réservés. Sauf prescription différente, aucune partie de cette publication ne peut être reproduite ni utilisée sous
quelque forme que ce soit et par aucun procédé, électronique ou mécanique, y compris la photocopie et les microfilms, sans l'accord écrit
de l'ISO à l'adresse ci-après ou du comité membre de l'ISO dans le pays du demandeur.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax. + 41 22 749 09 47
E-mail [e-mail]
Web www.iso.org
Publié en Suisse

ii © ISO 2004 – Tous droits réservés

---------------------- Page: 2 ----------------------
ISO 17432:2004(F)
Sommaire Page
Avant-propos. iv
Introduction . v
1 Domaine d'application. 1
2 Références normatives. 1
3 Termes et définitions . 2
4 Symboles et termes abrégés . 2
5 Exigences relatives aux transferts de données. 3
5.1 Intéraction. 3
5.2 Requête HTTP. 3
5.3 Réponse HTTP. 4
6 Types d'objets persistants. 5
6.1 Généralités. 5
6.2 Objets images monotrames. 5
6.3 Objets images multitrames . 6
6.4 Objets texte. 6
6.5 Autres objets . 7
7 Paramètres. 7
7.1 Paramètres disponibles pour tous les objets persistants DICOM. 7
7.2 Paramètres pour les objets persistants images DICOM monotrames et multitrames
uniquement. 9
Annexe A (informative) Syntaxe de transfert URL/URI . 14
Annexe B (informative) Exemples. 16
Annexe C (informative) Applications. 17
Annexe D (informative) Correspondances IANA. 18

© ISO 2004 – Tous droits réservés iii

---------------------- Page: 3 ----------------------
ISO 17432:2004(F)
Avant-propos
L'ISO (Organisation internationale de normalisation) est une fédération mondiale d'organismes nationaux de
normalisation (comités membres de l'ISO). L'élaboration des Normes internationales est en général confiée
aux comités techniques de l'ISO. Chaque comité membre intéressé par une étude a le droit de faire partie du
comité technique créé à cet effet. Les organisations internationales, gouvernementales et non
gouvernementales, en liaison avec l'ISO participent également aux travaux. L'ISO collabore étroitement avec
la Commission électrotechnique internationale (CEI) en ce qui concerne la normalisation électrotechnique.
Les Normes internationales sont rédigées conformément aux règles données dans les Directives ISO/CEI,
Partie 2.
La tâche principale des comités techniques est d'élaborer les Normes internationales. Les projets de Normes
internationales adoptés par les comités techniques sont soumis aux comités membres pour vote. Leur
publication comme Normes internationales requiert l'approbation de 75 % au moins des comités membres
votants.
L'attention est appelée sur le fait que certains des éléments du présent document peuvent faire l'objet de
droits de propriété intellectuelle ou de droits analogues. L'ISO ne saurait être tenue pour responsable de ne
pas avoir identifié de tels droits de propriété et averti de leur existence.
L'ISO 17432 a été élaborée par le comité technique ISO/TC 215, Informatique de santé.
iv © ISO 2004 – Tous droits réservés

---------------------- Page: 4 ----------------------
ISO 17432:2004(F)
Introduction
La norme DICOM est bien acceptée dans le domaine de l'imagerie médicale, incluant la radiologie, la
cardiologie, la pathologie, la radiothérapie et les spécialités utilisant du matériel d'imagerie en lumière visible
(par exemple les endoscopes, microscopes).
Les prescripteurs d'examens d'imagerie médicale et les personnels soignants ont besoin d'avoir un accès
rapide et fiable aux comptes rendus d'examens et images. Dans les environnements informatisés, cet accès
est de plus en plus lié aux technologies de l'Internet. Il est nécessaire d'avoir accès aux objets persistants
DICOM correspondants sans avoir à les dupliquer.
Les cliniciens ont besoin d'avoir accès soit aux données d'origine au format natif DICOM, qui permet une
manipulation extensive à l'aide de logiciels spécialisés utilisant les méta-données gérées par DICOM, soit à
des données converties dans un format générique (par exemple JPEG, PDF) qui peut être présenté avec les
applications prêtes à être utilisées.
La présente Norme internationale indique comment une demande d'accès à un objet persistant DICOM doit
être exprimée comme une requête HTTP URL/URI (voir IETF RFC2396) incluant un pointeur vers un objet
persistant DICOM spécifique sous la forme de son identifiant unique (instance UID). La requête spécifie
également le format que devra avoir la réponse à la requête. Les exemples incluent
a) le type de contenu (MIME) (par exemple application/dicom ou image/jpeg pour les images,
application/dicom ou application/rtf ou xml pour les comptes rendus),
b) codage du contenu,
c) compte-rendu codé en HL7/CDA Niveau 1.
Les paramètres de la requête URL tels que définis dans la présente Norme internationale sont suffisants pour
que le serveur HTTP se comporte comme un «client» DICOM SCU (Service Class User) pour récupérer
l'objet demandé à partir d'un «serveur» DICOM SCP (Service Class Provider) approprié à l'aide de la fonction
DICOM de base telle qu'elle est définie dans la DICOM PS 3.4 et dans la DICOM PS 3.7.
Les spécifications des exigences pour les objets persistants DICOM et formats supplémentaires pour les
réponses du serveur seront établies ultérieurement, si nécessaires.
© ISO 2004 – Tous droits réservés v

---------------------- Page: 5 ----------------------
NORME INTERNATIONALE ISO 17432:2004(F)

Informatique de santé — Messages et communication — Accès
au web pour les objets persistants DICOM
1 Domaine d'application
La présente Norme internationale spécifie un service basé sur le Web permettant l'accès et la présentation
d'objets persistants DICOM (Digital Imaging and Communications in Medicine) par exemple images, comptes-
rendus d'imagerie médicale. Elle a pour objet la communication de comptes-rendus et d'images aux
professionnels de la santé. Elle fournit un moyen simple d'accès à un objet persistant DICOM à partir de
pages HTML ou de documents XML, par l'intermédiaire d'un protocole HTTP/HTTPs, à l'aide d'identifiants
uniques DICOM. Les données peuvent être récupérées soit dans un format classique comme spécifié dans la
requête (par exemple JPEG ou GIF), soit dans un format DICOM natif.
La présente Norme internationale ne concerne pas l'interrogation de bases de données d'images DICOM via
le Web. Elle s'applique uniquement aux objets persistants DICOM (non aux autres objets DICOM ni aux
objets non DICOM). Le contrôle d'accès s'ajoutant aux mécanismes de sécurité généralement associés aux
applications Web ne relève pas directement du domaine d'application de la présente Norme internationale.
NOTE Les systèmes déclarés conformes à la présente Norme internationale doivent fonctionner en conformité avec
l'ensemble de ses articles normatifs.
2 Références normatives
Les documents de référence suivants sont indispensables pour l'application du présent document. Pour les
références datées, seule l'édition citée s'applique. Pour les références non datées, la dernière édition du
document de référence s'applique (y compris les éventuels amendements).
ISO/CEI 10918-2:1995, Technologies de l'information — Compression et codage numériques des images
fixes à modelé continu: Tests de conformité
DICOM PS 3.3, Digital Imaging and Communications in Medicine, Information Object Definitions
DICOM PS 3.4, Digital Imaging and Communications in Medicine, Service Class Specifications
DICOM PS 3.5, Digital Imaging and Communications in Medicine, Data Structures and Encoding
DICOM PS 3.6, Digital Imaging and Communications in Medicine, Data Dictionary
DICOM PS 3.7, Digital Imaging and Communications in Medicine, Message Exchange
DICOM PS 3.10, Digital Imaging and Communications in Medicine, Media Storage and File Format for Data
Interchange
DICOM PS 3.11, Digital Imaging and Communications in Medicine, Media Storage Application Profiles
DICOM PS 3.14, Digital Imaging and Communications in Medicine, Grayscale Standard Display Function
DICOM PS 3.15, Digital Imaging and Communications in Medicine, Security Profiles
HL7 CDA, Health Level Seven, Clinical Document Architecture (CDA)
© ISO 2004 – Tous droits réservés 1

---------------------- Page: 6 ----------------------
ISO 17432:2004(F)
IETF RFC2045 et suivants, MIME Multipurpose Internet Mail Extension
IETF RFC2396, Uniform Resource Identifiers (URI): Generic Syntax
IETF RFC2616, Hypertext Transfer Protocol — HTTP/1.1
IETF RFC3240, Application/dicom MIME Sub-type Registration
3 Termes et définitions
Pour les besoins du présent document, les termes et définitions suivants s'appliquent.
3.1
objet persistant DICOM
instance d'un objet-données conformément à la définition de la DICOM PS 3.3 à laquelle a été attribué un
identifiant unique dans le format spécifié pour l'UID de l'instance SOP DICOM PS 3.3 et qui a été choisie
comme objet à sauvegarder de manière sûre pendant un certain laps de temps.
NOTE Dans la norme DICOM, un objet persistant DICOM est qualifié d'instance de paire d'objets de service
composite (Service Object Pair, SOP).
3.2
système Client Web
système utilisant les technologies Internet (Web, e-mail) pour récupérer des objets persistants DICOM à partir
d'un serveur Web gérant les objets DICOM, par l'intermédiaire d'un protocole HTTP/HTTPs
3.3
serveur Web gérant les objets DICOM
système de gestion d'objets persistants DICOM, capable de transmettre ces objets sur demande au système
Client Web
3.4
accès Web aux objets persistants DICOM
service permettant au système Client Web de récupérer des objets persistants DICOM gérés par un serveur
Web gérant les objets DICOM, par l'intermédiaire d'un protocole HTTP/HTTPs
4 Symboles et termes abrégés
DICOM Digital Imaging and Communications in Medicine
HL7 Health Level Seven
HTML HyperText Markup Language
HTTP HyperText Transfer Protocol
HTTPs HyperText Transfer Protocol, secured
MIME Multipurpose Internet Mail Extensions
SOP Service Object Pair
UID Unique (DICOM) Identifier
URL/URI Uniform Resource Locator/Identifier
XML eXtensible Markup Language
2 © ISO 2004 – Tous droits réservés

---------------------- Page: 7 ----------------------
ISO 17432:2004(F)
5 Exigences relatives aux transferts de données
5.1 Interaction
L'interaction doit être conforme à la Figure 1.

Figure 1 — Diagramme d'interaction
5.2 Requête HTTP
5.2.1 Méthode
La requête HTTP doit utiliser la méthode GET définie dans l'IETF RFC2616.
5.2.2 Paramètres de la requête HTTP
Les paramètres du composant «query» de l'URI de la requête à envoyer au serveur Web par la méthode
HTTP GET doivent être représentés conformément à l'IETF RFC2396.
NOTE 1 D'autres composants de l'URI de la requête dépendent de la configuration, par exemple l'emplacement et le
langage de script du serveur Web gérant les objets DICOM.
NOTE 2 La manière dont le système Client Web obtient la valeur des paramètres nécessaires à l'accès par le Web aux
objets DICOM ne relève pas du domaine d'application de la présente Norme internationale.
© ISO 2004 – Tous droits réservés 3

---------------------- Page: 8 ----------------------
ISO 17432:2004(F)
5.2.3 Liste des types de média acceptés dans la réponse
Le champ «Accept» de la requête selon la méthode GET doit spécifier le(s) type(s) de média acceptable(s)
pour le système Client Web. Ce(s) type(s) de média doivent inclure au moins les éléments de la liste de types
MIME (voir IETF RFC2045) spécifiés dans le présent Article 6 concernant les types d'objets persistants
DICOM.
NOTE En principe, le champ «Accept» sera envoyé par un Client Web sous la forme «*/*». Un paramètre optionnel
spécifie le(s) type(s) MIME que le Client Web préfère, comme un sous-ensemble de ceux spécifiés dans le champ
«Accept».
5.2.4 Liste des jeux de caractères acceptés dans la réponse
Le champ «Accept-charset» de la requête selon la méthode GET doit spécifier le jeu de caractères de l'objet
à récupérer. Si le champ «Accept-charset» de la méthode GET n'est pas présent, ou si le serveur Web gérant
les objets DICOM n'accepte pas le jeu de caractères spécifié, le jeu de caractères de la réponse sera à la
discrétion du serveur Web gérant les objets DICOM.
NOTE En principe, l'utilisateur d'un Client Web n'a pas le contrôle du champ «Accept-charset». Un paramètre
optionnel spécifie le jeu de caractères à employer dans l'objet retourné.
5.3 Réponse HTTP
5.3.1 Généralités
La réponse doit être un message de réponse HTTP conformément à l'IETF RFC2616.
NOTE Le contenu du corps du message varie en fonction du type de média, comme défini en 5.3.2.2 et 5.3.4.2.
5.3.2 Corps d'une réponse de sous-type DICOM MIME simple
5.3.2.1 Type MIME
Le type MIME doit être «application/dicom», comme spécifié dans l'IETF RFC3240 et dans la DICOM PS 3.11.
5.3.2.2 Contenu
Le contenu du corps doit être un «Fichier Partie 10» incluant un méta-en-tête de section, comme défini dans
la DICOM PS 3.10.
5.3.3 Syntaxe de transfert
L'objet DICOM retourné doit être codé selon l'une des syntaxes de transfert spécifiées dans le paramètre de
requête de syntaxe de transfert, comme défini en 7.2.12 ci-après. Par défaut, la syntaxe de transfert doit être
«Explicit VR Little Endian».
NOTE Cela implique que, par défaut, les images récupérées sont envoyées non comprimées.
5.3.4 Corps d'une réponse de type non DICOM MIME
5.3.4.1 Type MIME
Le type MIME doit être l'un des types MIME définis dans le paramètre «contentType», de préférence celui que
préfère le Client Web; dans tous les cas, il doit être compatible avec le champ «Accept» de la méthode GET.
NOTE Le HTTP renvoie une erreur (406 — non acceptable) s'il n'obtient pas le type de contenu requis.
4 © ISO 2004 – Tous droits réservés

---------------------- Page: 9 ----------------------
ISO 17432:2004(F)
5.3.4.2 Contenu
Le contenu doit être une partie MIME contenant l'objet à récupérer.
NOTE La présente Norme internationale ne traite pas d'objets multiples dans une réponse. Les paramètres
s'appliquent à l'extraction d'un seul objet. En effet, la plupart des clients Web actuels sont capables de récupérer des
objets individuels dans un corps «non composite», MIME, mais ne sont pas capables d'accepter des réponses composites
hiérarchisées ou non.
6 Types d'objets persistants
6.1 Généralités
Les dispositions concernant certains types d'objets spécifiques doivent être telles que définies de 6.2 à 6.5.
Dans tous les cas, la catégorisation dépend de la classe SOP des objets, ce qui permet à un logiciel client, ou
à une page HTML active au sein d'une application, de déterminer préalablement à la requête quelles seront
les exigences.
6.2 Objets images monotrames
6.2.1 Objets accédés
Cette catégorie regroupe toutes les instances d'objets des classes SOP définies dans la DICOM PS 3.3, qui
consistent en une seule image fixe, les instances des classes SOP multitrames qui ne contiennent qu'une
image fixe, ou des instances d'objets qui consistent en une simple trame accédée dans des instances de
classes SOP multitrames à l'aide du paramètre «frameNumber».
6.2.2 Contraintes du type MIME
Le serveur doit pouvoir envoyer une réponse dans chacun des types MIME suivants:
 application/dicom;
 image/jpeg.
Si le paramètre «contentType» n'est pas présent dans la requête, la réponse doit contenir un type MIME
image/jpeg, s'il est compatible avec le champ «Accept» de la méthode GET.
Lorsqu'un type MIME image/jpeg est retourné, l'image doit être codée à l'aide du processus JPEG de base
non séquentiel non hiérarchique codé selon le codage 8 bits de Huffman avec pertes conformément à
l'ISO/CEI 10918-2:1995.
NOTE Le choix image/jpeg par défaut pour les images couleur ou en niveaux de gris est une conséquence de leur
compatibilité avec tous les clients Web.
Il convient que le serveur accepte aussi les types MIME suivants:
 image/gif;
 image/png;
 image/jp2.
Le serveur peut également accepter d'autres types MIME.
© ISO 2004 – Tous droits réservés 5

---------------------- Page: 10 ----------------------
ISO 17432:2004(F)
6.3 Objets images multitrames
6.3.1 Objets inclus
Cette catégorie regroupe toutes les classes SOP définies dans la DICOM PS 3.3 qui sont des objets images
multitrames.
6.3.2 Contraintes du type MIME
Le serveur doit pouvoir envoyer une réponse dans le type MIME suivant:
 application/dicom.
Si le paramètre «contentType» n'est pas présent dans la requête, la réponse doit contenir un type MIME
application/dicom.
Il convient que le serveur accepte aussi les types MIME suivants:
 video/mpeg;
 image/gif.
Le serveur peut également accepter d'autres types MIME.
6.4 Objets texte
6.4.1 Objets inclus
Cette catégorie regroupe toutes les classes SOP définies dans la DICOM PS 3.3 qui inclut le module Contenu
du document SR.
NOTE Cette catégorie inclut toutes les classes SOP qui sont des documents de type SR, comme le texte narratif, les
comptes-rendus structurés, les résultats logiciels de Diagnostic Assisté par Ordinateur, les comptes-rendus de mesure et
les sélections d'objets significatifs.
6.4.2 Contraintes du type MIME
Le serveur doit pouvoir envoyer une réponse dans chacun des types MIME suivants:
 application/dicom;
 text/plain;
 text/html.
Si le paramètre «contentType» n'est pas présent dans la requête ou contient seulement des types MIME que
le serveur n'accepte pas, la réponse doit contenir un type MIME text/html.
Il est recommandé que le serveur accepte également les types MIME suivants:
 text/xml;
 application/pdf;
 text/rtf;
 un type MIME «CDA», conforme à la HL7 CDA, par exemple application/x-hl7-cda-level-one+xml.
Le serveur peut également accepter d'autres types MIME.
6 © ISO 2004 – Tous droits réservés

---------------------- Page: 11 ----------------------
ISO 17432:2004(F)
6.5 Autres objets
6.5.1 Objets inclus
Cette catégorie doit inclure tous les objets de toutes les classes SOP définies dans la DICOM PS 3.3 non
incluses dans les catégories décrites de 6.2 à 6.4 et considérées dans la DICOM PS 3.3 comme des classes
d'objets persistants.
6.5.2 Contraintes du type MIME
Le serveur doit pouvoir envoyer une réponse dans le type MIME suivant:
 application/dicom.
Le serveur peut également accepter d'autres types MIME.
Si le paramètre «contentType» n'est pas présent dans la requête, la réponse doit contenir un type MIME
application/dicom.
7 Paramètres
7.1 Paramètres disponibles pour tous les objets persistants DICOM
7.1.1 Généralités
Les paramètres spécifiés de 7.1.2 à 7.1.8 sont applicables à toutes les classes DICOM SOP acceptées.
Pour identifier un objet DICOM, un seul UID est nécessaire, car un UID est unique. Cependant, la présente
Norme internationale exige que les UID des niveaux les plus élevés du modèle d'information DICOM soient
spécifiés (à savoir Série et Examen), pour favoriser l'utilisation de dispositifs DICOM qui n'acceptent que le
modèle «requête/récupération» de la ligne de base hiérarchique (plutôt que le modèle étendu), qui requiert
que l'UID de l'instance Examen et l'UID de l'instance Série soient définis lors de l'extraction d'une instance
SOP, comme défini dans la DICOM PS 3.4.
7.1.2 Type de requête
Type de requête réalisé. Ce paramètre est REQUIS.
Le nom du paramètre doit être «requestType».
La valeur doit être «WADO».
NOTE Ce paramètre permet l'introduction future d'autres types de requêtes, avec une syntaxe similaire.
7.1.3 Identifiant unique de l'examen
UID de l'instance Examen comme défini dans la DICOM PS 3.3. Ce paramètre est REQUIS.
Le nom du paramètre doit être «UID de l'examen».
La valeur doit être codée comme une chaîne d'identifiants uniques (UID), comme spécifié dans la
DICOM PS 3.5, mais la chaîne ne doit pas être complétée par un caractère NULL pour obtenir une longueur
paire.
© ISO 2004 – Tous droits réservés 7

---------------------- Page: 12 ----------------------
ISO 17432:2004(F)
7.1.4 Identifiant unique de la série
UID de l'instance Série comme défini dans la DICOM PS 3.3. Ce paramètre est REQUIS.
Le nom du paramètre doit être «studyUID».
La valeur doit être codée comme une chaîne d'identifiants uniques (UID), comme spécifié dans la
DICOM PS 3.5, mais la chaîne ne doit pas être complétée par un caractère NULL pour obtenir une longueur
paire.
7.1.5 Identifiant unique de l'objet
UID de l'instance SOP comme défini dans la DICOM PS 3.3. Ce paramètre est REQUIS.
Le nom du paramètre doit être «objectUID».
La valeur doit être codée comme une chaîne d'identifiants uniques (UID), comme spécifié dans la
DICOM PS 3.5, mais la chaîne ne doit pas être complétée par un caractère NULL pour obtenir une longueur
paire.
7.1.6 Type MIME de la réponse
Type(s) MIME souhaité(s) par le Client Web pour la réponse du serveur, comme défini dans l'IETF RFC2616.
Ce paramètre est OPTIONNEL.
Le nom du paramètre doit être «contentType».
La valeur doit être une liste de types MIME, séparés par un caractère «,», et potentiellement associés à un
degré de préférence relative, comme spécifié dans l'IETF RFC2616.
Le Client Web doit fournir la liste des types de contenu qu'il accepte dans le champ «Accept» de la méthode
GET. La valeur du paramètre «contentType» de la requête doit être une des valeurs spécifiées dans ce
champ.
NOTE 1 En principe, le champ «Accept» sera envoyé par un Client Web sous la forme «*/*», qui est compatible avec
tous les types MIME.
NOTE 2 Lorsque ce paramètre est absent, le type de contenu par défaut de la réponse est dicté par 6.2.2, 6.3.2, 6.4.2
et 6.5.2.
7.1.7 Jeu de caractères de la réponse
Jeu de caractères avec lequel l'objet retourné doit être codé, comme défini dans l'IETF RFC2616.
Ce paramètre est OPTIONNEL.
Le nom du paramètre doit être «charset».
La valeur doit être une liste de jeux de caractères, séparés par un caractère «,», et potentiellement associés à
un degré de préférence relative, comme spécifié dans l'IETF RFC2616.
Le Client Web peut fournir une liste des jeux de caractères qu'il accepte dans le champ «Accept-charset» de
la méthode GET. Si ce champ est présent, la valeur du paramètre «charset» de la requête doit être une des
valeurs spécifiées dans ce champ.
Le serveur peut ou non accepter la conversion des jeux de caractères. S'il l'accepte
8 © ISO 2004 – Tous droits réservés

---------------------- Page: 13 ----------------------
ISO 17432:2004(F)
 les objets DICOM à base de texte récupérés autrement que sous forme de type MIME
application/dicom (par exemple text/plain) peuvent être retournés dans le jeu de caractères demandé
(après conversion si nécessaire),
 toutes les chaînes de caractères contenues dans les objets DICOM récupérés sous forme de type
MIME application/dicom sont retournées dans le jeu de caractères demandé (après conversion si
nécessaire) et le jeu de caractères spécifique (0008, 0005) est mis à jour (si nécessaire).
Les enregistrements du jeu de caractères IANA spécifient les noms et les multiples pseudonymes de la
plupart des jeux de caractères. La valeur normalisée à utiliser dans WADO est celle enregistrée auprès de
IANA comme «préférée pour MIME». Si IANA n'a pas enregistré un des pseudonymes comme «préféré pour
MIME», le nom utilisé dans DICOM doit être la valeur utilisée pour WADO.
NOTE Le Tableau D.1 indique à titre informatif les correspondances entre certaines valeurs IANA et les appellations
de jeux de caractères spécifiques DICOM.
7.1.8 Anonymat de l'objet
Retrait de l'objet DICOM de toute information permettant d'identifier le patient, si ce n'est pas déjà fait, comme
défini dans la DICOM PS 3.15. Ce paramètre est OPTIONNEL. Il doit seulement être présent si
«contentType» est application/dicom.
Ce paramètre est optionnel.
Le nom du paramètre doit être «anonymize».
La valeur doit être «yes».
Le serveur peut renvoyer un message d'erreur s'il ne peut pas rendre cet objet anonyme ou refuse de le faire.
Le serveur doit renvoyer un nouvel UID d'instance SOP si le contenu de l'objet n'a pas déjà été rendu
anonyme.
NOTE 1 La présente Nome internationale n'introduit pas d'exigences liées à la sécurité. Il est probable que les
informations contenues dans les objets DICOM permettent d'identifier le patient. Le protocole utilisé (c'est-à-dire HTTP)
peut être remplacé par HTTPs, qui est son extension sécurisée, pour protéger l'information en transit. L'application
DICOM sous-jacente décide si elle donne accès ou non à un objet DICOM particulier selon la politique ou le mécanisme
de sécurité informatique en place. Il est peu probable qu'un serveur exécute une requête émanant d'un utilisateur inconnu
(par exemple, par l'intermédiaire du protocole HTTP) s'il n'est pas certain que les données demandées ne comportent pas
d'informations permettant d'identifier le patient et qu'elles sont d'accès public.
NOTE 2 L'anonymat de l'objet permet, par exemple, aux systèmes de fichiers ou aux applications d'essais cliniques
d'autoriser l'accès à des images originales stockées dans un PACS, sans dévoiler l'identité des patients, et de demander
l'enregistrement d'une copie (rendue anonyme) de l'image originale. L'opération d'anonymat relève de la responsabilité du
serveur. Pour préserver la confidentialité du patient, il est probable que le serveur refusera de délivrer une instance SOP
anonyme à une personne inconnue ou non autorisée s'il n'est pas certain que l'instance SOP ne contient aucune
information permettant d'identifier le patient. Il faudrait notamment mettre en blanc le
...